Digital Money Choices Are Really Dependencies

The Token Decision Nobody's Ready to Make

Fireblocks just published an analysis of how 80+ banks are building digital money infrastructure. They scored three approaches: use someone else's stablecoin, issue your own, or tokenize deposits. The table compares control, speed to market, and deposit flow impact.

Read it as a CFO and you see something else entirely: every option is a dependency decision wearing a payments costume.

I've watched this movie before. In 2008, I watched financial institutions wake up to discover their entire mortgage pipeline ran on someone else's risk models. In 2020, I watched treasurers realize their cash visibility stopped at close of business Friday, even when markets didn't. Now we're doing it again, except this time the dependency decision happens at 2am on Sunday when a tokenized transfer fails and nobody's sure whose problem it is.

The token is the easy part. The calendar isn't.

The Three Paths Banks Are Taking (And What They're Really Choosing)

Fireblocks laid out the technical options. Let me translate what each one actually means for the people who sign the audit committee reports.

Someone else's stablecoin gets you to market fast. You're essentially reselling USDC or USDP the way you might have white-labeled a prepaid card program fifteen years ago. The issuer owns the redemption promise. They set the terms. They decide what "instant" means and what happens when a transaction gets flagged at 11pm. Your liquidity runs on their rules, their compliance infrastructure, their interpretation of what constitutes suspicious activity.

Tokenized deposits keep the balance on your balance sheet. The bank retains control. It looks like a digital upgrade to existing deposit infrastructure—which is exactly why it's the slowest option to build and the hardest to explain to regulators who want to know how this is different from the checking account you already offer.

A bank-issued stablecoin lands in the middle. You control issuance and redemption, but you have to stand up reserve management, reconciliation, and a new regulatory relationship first. It's not a technology decision—it's a balance sheet decision that happens to use tokens.

What none of these options tell you: who works the failed transfer at 2am on Sunday when your blockchain doesn't stop but your ops team did.

Railroad Time for Treasury Departments

On Sunday, November 18, 1883, every US and Canadian railroad reset its clocks to standard time zones. Trains moved faster than local noon could keep up with. Cities that used to set time by the sun adopted railroad time—not because they wanted to, but because the infrastructure they depended on didn't wait for local consensus.

Railroad time became everyone's time, including people who never bought a ticket.

Now swap trains for treasury operations and the same thing happens, just with APIs instead of pocket watches and a 5pm cutoff time nobody wants to give up.

Blockchains don't take bank holidays. Your controller would like to.

I was on a call two months ago with a financial institution that had just tokenized a subset of their treasury operations. The CFO was excited about instant settlement. The controller wanted to know what "instant" meant for their month-end close process. Does instant mean the accountants need to be available at midnight? Does it mean reconciliation runs continuously? Who signs off on a balance that never stops moving?

Nobody in the room had thought about it. They'd solved the token issuance. They hadn't solved the calendar.

The Three Questions You're Not Asking Yet

Before anyone in your shop picks a token strategy, sit down with treasury and accounting and answer these out loud:

Who controls redemption? Not in theory—in practice, at 9pm on a Saturday when a high-value transaction gets flagged and someone needs to make a call. If you're using someone else's stablecoin, you're outsourcing that decision. If you're issuing your own, you're staffing for it. Be specific about which one you're choosing.

Where do the balances actually sit? On your balance sheet or someone else's? This isn't a philosophical question. It determines who holds the regulatory obligation, who takes the credit risk, and—critically—who your examiners will ask when they want to see the reconciliation.

Who handles the exceptions when settlement never closes? Traditional payment rails have defined exception processes because they have defined business hours. Blockchain infrastructure runs continuously. Your operations manual doesn't. Which part of your close process breaks first when money stops waiting for business days?

If you can't answer all three, you're not ready to pick the token. You're ready to staff a working group.

Why This Feels Different (And Why It Isn't)

The instinct I see in a lot of institutions right now is to treat tokenization as a digital channel decision—something the innovation team pilots with a small use case, learns from, and scales. That worked for mobile banking because mobile didn't change what a deposit was. It changed how customers accessed it.

Tokenization changes the operating assumptions underneath the deposit. It makes "instant" the default and "business days" the exception. It turns settlement from a batch process into a continuous one. It moves the dependency decision from "which core banking vendor" to "which token standard and whose redemption infrastructure."

This isn't a channel decision. It's an operating model decision that happens to use tokens.

I've watched banks move to real-time payment rails over the last five years. The ones that succeeded didn't treat it as a technology upgrade. They treated it as a re-negotiation of how treasury, operations, risk, and compliance work together when the system doesn't pause. The ones that struggled built the technical capability and then discovered their people, processes, and controls assumed batch windows that no longer existed.

Tokenization is the same pattern, except faster and with less regulatory clarity about who's responsible when something breaks.

What to Do Monday Morning

Here's the conversation to have this week—not with your innovation team, with your controller:

Walk through your month-end close process and identify every step that assumes settlement finality happens during business hours. Flag every reconciliation that waits for a daily file. List every exception workflow that depends on being able to call someone.

Then ask: what happens to each of those steps when tokens settle instantly, 24/7/365?

You'll find gaps. Good. Now you know what to staff for before you pick the token, not after.

The banks that get digital money right won't be the ones that move fastest. They'll be the ones that answer the dependency questions out loud, in writing, with signatures from people who'll be around to execute the answer.

The token decision looks like a technology choice. It's actually a treasury, accounting, and operational dependency choice that determines who you call when the system doesn't stop and your people need to.

Which parts of your infrastructure still assume batch processing? That's where tokenization breaks first.

But what do I know—I've only watched this dependency blindness play out three times in fifteen years.