Key Takeaways
- A bank can issue tokenized deposits on its own private ledger today without joining a consortium. If the transfer is happening between clients of the same bank, the bank is dealing with systems and liabilities it already controls.
- Minting, transferring, and redeeming happen inside the bank’s existing KYC and AML perimeter, and the token is still a representation of an existing deposit liability.
- Three use cases are particularly relevant here. Treasury sweeps, programmable escrow, and the cash leg for tokenized asset settlement. None of them necessarily needs a second bank or a clearing consortium to participate.
- For large banks, the economic benefits could be substantial. Efficiency savings of 10 to 30 basis points on trapped intraday liquidity can translate into $100 million to $300 million a year for every $100 billion in daily internal fund flows.
- The more practical sequencing may be to start with intrabank use cases, learn from them, and then decide where a consortium or interbank network is actually necessary.
Banks looking at tokenized deposits often assume that the first step has to be joining any consortium. There is some logic to that. Eventually, if tokenized deposits are going to move between banks, banks will need common standards, governance, settlement rules, and interoperability.
But that does not mean a bank has to start there. A bank can tokenize its own deposit liabilities on a private, permissioned ledger and use them between clients already banking with it.
That is already happening. Citi’s tokenized deposit platform moved from testing into commercial availability in October 2024 and runs on Citi’s own infrastructure. JPMorgan’s Kinexys platform has been moving institutional client funds across the bank’s network since 2019. Neither waited for an industry-wide standard before starting.
The regulatory case is also different when the activity stays inside one bank. The token does not leave the bank’s ledger. The clients are already inside the bank’s KYC and AML perimeter. The underlying liability remains a bank deposit.
That is quite different from a shared ledger where several banks first have to agree on governance, liability, operating rules, and settlement.
This article walks through three use cases a bank can start inside its own ecosystem without a consortium, and how to weigh them against each other.
How Does a Single-Bank Tokenized Deposit Model Differ From a Consortium?
In a single-bank model, one bank issues the tokenized deposit, records it, and redeems it. Transfers happen between clients of the same institution. In a consortium model, several banks participate in a shared network, and deposits issued by different institutions move under a common set of rules.
The accounting in the single-bank case is fairly straightforward. If an institutional client converts part of an operating deposit into tokenized form, the bank is not creating a new liability. It is changing the form in which an existing deposit is represented. There is no separate reserve pool to fund. The deposit can also retain its existing Basel liquidity treatment as long as the characteristics of the underlying operating relationship remain intact.
And if we look at the live implementations today, this is largely where tokenized deposits are being used. It moves liquidity between accounts and entities that already sit within the same banking group.
A shared ledger obviously gives broader reach. But it comes with coordination. Banks need to agree on standards, governance, technical integration, liability, and operating rules.
A single-bank ledger avoids much of that at the beginning. For a large universal bank or transaction bank, this does not mean choosing between an internal model and a consortium forever. It may simply mean building the internal piece first, then connecting it to an interbank network later where the business case justifies it.
So the tradeoff is reach between the two.
A single-bank network only works between clients of that bank. If a corporate needs to send money to an entity banking elsewhere, correspondent banking or some form of shared network is still needed.
That is a real limitation, and it is also why the three use cases below are chosen specifically because they do not need to leave the bank to deliver value.
Use Case 1. Tokenized Deposits for 24/7 Cross-Border Treasury Movement Inside One Bank
Intrabank cross-border treasury means a multinational client moves funds between its own entities in different countries, all of which hold accounts at the same bank, at any hour.
The difference with tokenized deposits is that the movement does not have to be tied as closely to traditional payment windows.
The Problem Corporate Treasurers Face
Multinational companies manage treasury across subsidiaries, currencies, jurisdictions, and time zones. The cash may be there, but the ability to move it at the right time depends on bank operation timings. Because cash can move only while payment systems and bank operations are open. So each entity has to keep local buffers.
That is not because the group necessarily lacks liquidity. Often the liquidity is sitting somewhere else in the organization.
For instance, in the US, treasury trades tend to stop around 3:30 or 4:00 in the afternoon, which leaves clients pre-funding local accounts with money they would rather use elsewhere. Similarly, a corporate may have surplus liquidity in Germany while needing to fund US operations after the German market has closed.
The money exists. It is simply not where it needs to be at that moment.
How It Works Inside One Bank
Take a corporate treasurer who needs to fund a German subsidiary on Saturday evening from a US parent account.
Both entities bank with the same institution. Both have tokenized deposit wallets on the bank’s ledger.
The treasurer sends the instruction through the bank’s portal. The bank redeems the parent’s USD deposit tokens, performs the FX conversion internally, and issues EUR deposit tokens to the subsidiary’s wallet.
The transaction stays on the bank’s balance sheet. There is no correspondent bank in the middle. There is no need to wait for an external clearing system to open.
The bank updates the relevant positions across its own branches and systems.
The bank updates the relevant positions across its own branches and systems. Programmability features can also add to this. For example, the bank can offer balance-based sweeps, pooling at agreed times, automated intercompany funding, or rules that move liquidity once a threshold is reached. Instead of treasury teams constantly monitoring and manually shifting balances, some of that activity can happen under rules the client has already approved.
Let’s look at some real numbers
JPMorgan built its Onyx platform, now Kinexys, partly to reduce unsecured intraday exposure on institutional cash movements.
The platform also allowed 24/7 transfers across time zones.
The client-side impact can be meaningful.
For Siemens, programmable payments and real-time pooling through J.P. Morgan reportedly reduced liquidity requirements by 50 percent and generated more than $20 million in annual savings.
There is a bank-side benefit as well.
Large institutions can potentially save 10 to 30 basis points on intraday liquidity that would otherwise remain idle.
At $100 billion of daily internal flows, that works out to roughly $100 million to $300 million a year.
The client demand is also fairly clear.
In the SODA survey, faster cross-border settlement was the top client priority and was cited by every respondent.
What Executives Should Weigh
This is where the discussion can get too focused on the token.
The harder part is operating the service.
If a bank offers 24/7 treasury movement, its treasury, risk, liquidity, operations, and FX infrastructure needs to support that.
Weekend FX is a good example.
The bank has to decide how it prices the conversion and how it manages the position until markets reopen.
So the value is not in putting a deposit on a blockchain and calling the job done.
It comes from how the tokenized deposit fits into the rest of the bank’s treasury infrastructure and the client’s cash-management process.
It is also reasonable to ask whether blockchain is needed at all.
Deutsche Bank makes this point.
A number of these benefits could be achieved with non-blockchain systems.
That is true.
The stronger argument for tokenization comes when the bank wants programmability, a shared settlement layer for other tokenized instruments, and eventually a route into interbank networks.
There is also a commercial reason not to treat this as a technology experiment.
Corporate operating balances matter.
If another bank gives a treasurer materially better control over global liquidity, those relationships and balances can move over time.
So part of the business case is efficiency.
Part of it is also defending the transaction banking relationship.
Use Case 2. How Can Tokenized Deposits Automate Escrow and Trade Finance Payments?
Programmable escrow is another use case that works naturally inside one bank.
The bank locks tokenized funds under agreed conditions and releases payment when those conditions are verified.
The idea itself is not particularly complicated.
What changes is the amount of manual coordination required around the payment.
The Problem in Trade and Commercial Payments
Traditional escrow and documentary trade still involve a lot of manual review.
Documents come in.
Bank staff verify them.
Conditions are checked.
Buyers and sellers wait for confirmation.
Payment is then released.
That takes time, and every additional handoff creates cost and another place where errors or disputes can appear.
How It Works Inside One Bank
Consider a manufacturer buying $10 million of steel from a supplier.
Both companies already hold commercial accounts with the same bank.
The bank converts $10 million of the buyer’s deposit into tokenized form and locks those tokens in an escrow contract.
The contract contains an agreed condition.
For example, payment may be released when an approved shipping company submits a digitally signed bill of lading.
Once the signature is verified, the contract transfers the tokens to the supplier.
The supplier can continue holding the tokenized deposit or redeem it at par into a conventional deposit.
If the deadline passes and the required document is not received, the funds return to the buyer.
The same basic structure can be used for milestone payments, invoice-linked settlement, approval-based releases, and other conditional payment flows.
Deposit tokens can also support related banking functions such as conditional intraday lending and automated interest payments.
Why It Works Without a Consortium
Both parties are already clients of the bank.
They have already passed KYC and AML checks.
The bank already carries both deposit liabilities.
So when payment happens, the bank is moving value from one liability to another on its own books.
It does not need another bank to agree to the transaction.
That is different from trying to build tokenized B2B payments across a wider market.
At that point, ERP integration, legal certainty, and interoperability between institutions become much more important.
Inside one bank, the interoperability issue largely disappears for transactions where both parties bank there.
The other issues do not disappear.
ERP integration still matters.
Legal certainty still matters.
The trusted data feeding the contract still matters.
Escrow-style payments have already been tested in multi-bank settings such as Switzerland.
A single bank can apply similar logic between its own clients without waiting for that wider coordination.
There is also a fairly clear product angle here.
Conditional payment, automated release, and an auditable record are services a corporate client may be willing to pay for.
The Tradeoffs
There are four issues worth looking at before launch.
- Reach. It only works where both buyer and supplier bank with the institution. That makes it more relevant where the bank already has a strong commercial franchise in a particular supply chain, sector, or trade corridor.
- Trusted inputs. The contract is only as good as the information it receives. The bank has to decide which documents, signatures, or external data sources it is prepared to rely on and what happens when there is a dispute.
- Software risk. Automation removes some manual work but introduces dependence on software logic. A bug in a smart contract can be just as serious as a bad manual process. The contracts need to sit inside the same technology risk, review, and audit disciplines as other critical banking systems.
- Confidentiality. By default, a permissioned ledger is not private in the banking context. At the transaction and ledger level, data can be accessed by members. If contract state is visible, clients may see the counterparties, transfer amounts, or commercial terms. All of these are sensitive details.
Hence, a bank may control who joins the network and still expose more information than clients would be comfortable with.
So privacy has to be designed into the transaction model itself.
Use Case 3. How Can Tokenized Deposits Settle the Cash Leg of Tokenized Asset Trades?
The cash leg is simply the payment side of a securities transaction.
If the asset and cash can move together, the trade can settle atomically.
Either both transfers happen or neither does.
That is the ledger version of delivery versus payment.
The Problem With Tokenized Assets on Conventional Rails
Banks are already tokenizing bonds, commercial paper, fund units, and other real-world assets.
The market has grown quickly.
Tokenized real-world assets increased from around $6 billion in December 2024 to roughly $31 billion by April 2026.
But there is a fairly basic problem.
If the asset moves on a ledger in seconds and the cash still travels through a conventional wire, settlement is still dependent on the slower leg.
The asset has been tokenized.
The settlement process has only been half tokenized.
That gap brings back the same settlement risk the new infrastructure was supposed to reduce.
One party may deliver before the other pays.
The normal response is pre-funding or collateral.
And that means more liquidity gets tied up.
How It Works Inside One Bank
Suppose the bank acts as issuer and custodian of a $50 million corporate bond in tokenized form.
Client A wants to buy $5 million of that bond from Client B.
Both are clients of the same bank.
The bank places Client B’s bond tokens and Client A’s deposit tokens into the same settlement contract.
The contract executes only when both sides are present.
The asset changes ownership.
The cash changes ownership.
They happen in the same transaction.
If either side is missing, neither moves.
Because the bank issues the deposit token and operates the asset platform, it controls both legs of settlement.
It does not need an external settlement asset or a bridge to another payment network to complete the transaction.
What the Evidence Shows
JPMorgan’s Kinexys repo platform is probably the clearest live example.
The buyer’s deposit is moved into a blockchain deposit account.
At the agreed time, the collateral token goes to the buyer and the cash moves to the seller at the same time.
At maturity, the transaction can unwind automatically.
The tokens are burned, cash plus interest returns, and the collateral goes back to its owner.
By May 2026, Kinexys had reported cumulative turnover of around $3 trillion.
Another detail is worth noting.
The activity is largely between clients and affiliates already banking with JPMorgan.
So again, the model does not require the entire financial system to be on the same network before it becomes useful.
It also shows the limit.
Market depth is naturally smaller when participation is limited to clients of one institution.
For custody and markets-oriented banks, there is still a clear case for building tokenized deposits as the cash side of repo, securities financing, and other tokenized asset activity.
Where the Limits Are
The harder legal questions are often on the asset side rather than the deposit side.
The legal status of tokenized assets, ownership records, settlement finality, and the treatment of digital securities still needs more clarity in a number of jurisdictions.
So it is quite possible for the tokenized deposit infrastructure to be ready before the tokenized asset infrastructure has full legal clarity.
Atomic settlement also needs to be understood properly.
It removes the risk that one party delivers while the other does not.
It does not remove credit risk in the asset.
It does not remove market risk.
And it does not solve the issue of market depth when buyers and sellers outside the bank cannot participate.
Those issues eventually bring the discussion back to interoperability.
But again, not necessarily on day one.
Here’s a Decision Matrix. Which Single-Bank Use Case Should a Bank Start With?
Not every use case has the same level of effort or the same value for every bank.
So impact alone is not enough.
A bank needs to look at regulatory feasibility, technical integration, and then the strategic and commercial value.
The answer will also depend heavily on the franchise.
The matrix is really only useful when read alongside the bank’s own franchise.
A bank with a large multinational corporate book will naturally see more value in treasury.
A bank with a concentrated commercial or trade client base may find escrow easier to commercialize.
A custodian or markets bank already working on tokenized assets may have the clearest reason to focus on the cash leg.
There is also a practical infrastructure point.
These are not three completely separate builds.
They can run on the same ledger.
They can use the same tokenized deposit.
They can use the same wallets, identity controls, policy framework, and privacy controls.
So the first use case can create a large part of the foundation needed for the second and third.
That is why sequencing matters.
A bank does not necessarily need three pilots.
It needs one use case with enough value to justify building reusable infrastructure underneath it.
Some use cases sit outside this matrix deliberately.
Interbank retail payments are one.
Those require shared rules around liabilities and settlement between issuers.
Public permissionless networks are another.
They bring sanctions, AML, compliance, and privacy questions that many institutions will not want to take on in the first phase of a tokenized deposit program.
Those may be later decisions.
They do not need to block the intrabank use cases.
Zeeve for Privacy-Enabled Blockchain Infrastructure for Your Tokenized Deposit Program
A bank does not need a consortium before it can get value from tokenized deposits.
It needs a real use case inside its own client base, a ledger it can control, and an infrastructure model that meets the standards expected of regulated financial infrastructure.
Treasury, escrow, and tokenized asset settlement all fit that starting point.
They also have one thing in common.
They involve sensitive information.
A single-bank ledger may contain balances, transaction values, counterparties, escrow conditions, and settlement positions.
Permissioning the network is not enough by itself.
The bank also needs control over which participant can see which piece of information.
This is where Zeeve’s privacy layer is relevant.
At the application layer, access controls determine which users and systems can interact with data.
At the asset layer, zero-knowledge techniques can be used to keep balances, amounts, and counterparty information confidential.
At the ledger layer, access to contract state can be restricted so that information such as escrow conditions is visible only to the parties that need it.
The infrastructure works across permissioned EVM networks, Besu, and rollup architectures, so the bank is not forced into a single stack simply because it has chosen one privacy model.
Zeeve runs on ISO 27001 and SOC 2 Type II compliant infrastructure.
For institutions that want the infrastructure inside their own environment, Bring Your Own Cloud deployment is also available.
And there is another practical consideration.
Many banks are not starting from zero.
They already have blockchain pilots, existing vendors, internal infrastructure, or experiments running on a particular stack.
So migration matters too.
Zeeve supports migration from legacy blockchain infrastructure and can work with banks on architecture choices without requiring them to commit to one specific network from the beginning.
The sensible next step is not to begin with a consortium discussion.
Start with one use case.
Look at the clients who would actually use it.
Look at the flows involved.
Work out where the economic value comes from.
Then decide what infrastructure is required to support it properly.
The interbank question will still be there later.
But there is quite a bit a bank can do before it gets there.
