Skip to content

Insight · April 2024

Tokenized deposits, explained for the people who hold the deposits

A bank deposit is a liability you owe your customer. A tokenized deposit is that same liability, programmable and settleable on a ledger. That one distinction is why the largest banks treat it differently from a stablecoin.


When a bank moves a balance over a network like Kinexys, the thing crossing the ledger is not a new asset. It is a commercial-bank deposit, a claim on the bank, recorded on a programmable ledger instead of in a core banking table. The customer's balance sheet does not change. The bank's liability does not change. What changes is where and how that liability can be instructed to move.

That single fact is the whole story, and it is the one most explainers skip. It is also the difference your risk committee will care about, so it is where this starts.

A deposit is a liability, and tokenization does not change whose

When a customer holds $10 million on deposit, the bank owes that customer $10 million. The deposit is the bank's liability and the customer's asset. It sits inside deposit insurance frameworks, inside the bank's capital and liquidity treatment, inside the supervisory relationship the bank already has with its examiner.

A tokenized deposit is the same liability represented as a transferable record on a ledger the bank controls or participates in. The customer is still a depositor. The bank is still the issuer of the claim. The legal character of the instrument, who owes whom, under what jurisdiction, with what recourse, is unchanged. The rails change. The obligation does not.

This is why the terminology carries more weight than it appears to. "Tokenized deposit" is not a marketing softening of "stablecoin." It is a precise statement that the underlying instrument is a deposit, with everything that follows from that.

Where the stablecoin comparison actually breaks

A stablecoin, even a well-run fiat-backed one under a regime like the GENIUS Act, is structurally a different instrument. It is the issuer's liability, backed by a reserve of cash and short-dated government paper, redeemable at par. The holder's claim is on the issuer and the reserve, not on a bank deposit. The token behaves like money while the economics of the float accrue to the issuer.

For a bank, the question is not which one is the better technology. Both can move around the clock, both can settle atomically, both can carry programmable conditions. The question is where the customer's money lives and whose franchise it strengthens.

When a customer converts a deposit into a stablecoin, the deposit leaves the bank. It becomes a reserve asset somewhere else, intermediated by an issuer the bank does not control. Aggregate that across a customer base and it is deposit disintermediation by another name, the same dynamic banks fought with money market funds, now with faster settlement and a better demo. The deposit migrates outside the perimeter the bank operates in, and the bank loses the funding, the relationship data, and the float.

A tokenized deposit is the defensive answer. It gives the customer the operational properties they want, programmability, instant settlement, on-chain movement, without the deposit ever leaving the bank's balance sheet or the regulated perimeter. That is why the largest US institutions are building tokenized-deposit capability through shared market infrastructure rather than issuing stablecoins. It is not enthusiasm for the format. It is deposit retention with better plumbing.

The motive is plain, and your strategy team already knows it. Tokenized deposits are how a bank says yes to on-chain money movement while keeping the deposit, the customer, and the supervisory treatment exactly where they are.

What it actually changes operationally

The instrument is familiar. The operating model is not. Several functions move from quarterly batch reality into real-time reality, and each one has an owner who needs to be in the room early.

Settlement timing becomes continuous. A tokenized deposit can settle atomically against another asset, delivery-versus-payment or payment-versus-payment, in seconds, outside business hours. That is the headline benefit. It also means intraday liquidity management, cutoff times, and end-of-day reconciliation stop being clerical and start being load-bearing controls. Settlement finality has to hold both operationally, the transfer is irreversible on the ledger, and legally, it is recognized as final under applicable insolvency and finality law. The elegance of the demo tends to obscure the second half.

Reconciliation moves to the ledger and the core at once. The token represents a deposit that also exists in the bank's system of record. Those two views must agree continuously, not at end of day. This is an ISO 20022 and API integration problem before it is a blockchain problem, and it is where most pilots quietly stall. If on-chain balances and core balances can diverge, you have built a reconciliation liability, not a settlement asset.

The compliance program extends to the wallet. Identity does not get easier. CIP, KYC, KYB, CDD and EDD still apply to the account holder; beneficial ownership under the FinCEN CDD rule, 25% ownership plus the control person, still applies to the entity. What is new is the on-chain surface. The bank now needs Know Your Transaction monitoring against laundering typologies, OFAC screening of counterparty wallet addresses and not just names, and attention to indirect exposure through transaction-graph analysis. Name-matching alone has never been sufficient; on a public or semi-public ledger it is plainly inadequate. Where a transfer crosses to another institution, the FATF Travel Rule obligation to transmit originator and beneficiary information attaches, with FATF's threshold near $1,000 and the US BSA threshold at $3,000. SAR and CTR obligations do not disappear because the rail is faster. Banks running this in earnest expect their existing analytics, Chainalysis, Elliptic, TRM Labs, to reach the on-chain leg, and they expect immutable, exportable, examiner-ready audit trails across both views.

Key control becomes a board-level question. A tokenized deposit can move because someone can authorize a transfer on the ledger. Whoever controls those keys controls the bank's ability to move its own liability. That puts MPC, HSM, and FIPS 140-3 key management, no single point of compromise, the bank holding its own keys, on the same footing as the wire room. It is not an infrastructure footnote. It is the new signing authority.

The wedge nobody designed for

Here is the part the architecture diagrams understate. Almost every large bank building tokenized deposits is building an island. The deposit is tokenized on a network the bank controls or co-owns. That is correct for control and correct for the perimeter. It is also, by construction, a closed system.

A tokenized deposit at one bank does not natively settle against a tokenized deposit at another, or against a tokenized security on a different network, or against a stablecoin a corporate treasurer happens to hold. The convergence on shared infrastructure, several of the largest efforts gravitating toward Canton and Digital Asset, others coordinating through The Clearing House, is a partial answer for the institutions inside a given consortium. It is not interoperability across the wider system, and it does not pretend to be.

So the format that keeps deposits inside the perimeter also keeps them inside a fence. The benefit a corporate treasurer actually wants, move value to any counterparty, on any rail, atomically, at any hour, runs straight into the boundary of whichever island the deposit was minted on. This is why nearly every bank that has stood up tokenized money names interoperability as the missing piece almost as soon as the pilot works. They have built real on-chain money and discovered it cannot easily reach the rest of the on-chain world.

Where this leaves the people who hold the deposits

Tokenized deposits are the right defensive move, and they are more conservative than they sound. The instrument is the deposit your customer already holds, your liability stays your liability, and the activity stays inside the framework your examiner already understands. The work is not in the token. It is in settlement finality, in continuous reconciliation, in extending the BSA/AML program to the wallet, and in deciding who holds the keys.

After that, the work is in connectivity. An island of on-chain money that cannot reach other islands solves the deposit-retention problem while quietly recreating the settlement-fragmentation problem one layer up. Finance is moving on-chain in fragments, and the institutions furthest along are the first to run into that boundary. The deposit stays yours. The question worth answering early is which networks it will eventually need to reach, and on whose terms it gets there.

We are early, and we are building toward exactly that connectivity layer: one neutral substrate between the networks an institution chooses, with the bank as principal throughout. We do not have a chain of our own to move you onto, which is the point.