“AI represents machine-native intelligence, while digital assets represent machine-native money.”
BlackRock uses that framing in The Machine-Native Economy, its September 2026 paper. It is a useful way into this discussion. If software agents are going to pay for data, compute and services, they will need money they can use at any hour, without a person stepping in to approve each small payment.
For banks, tokenized deposits are one way to meet that need while keeping the money within a familiar legal and regulatory structure.
There is already some movement here. Institutions in Asia, Europe and the United States are taking tokenization into production across payments, treasury and capital markets.
The attraction is fairly clear. A regulated deposit becomes easier to move and easier to program. The harder discussion is what that asks of the bank behind it.
A payment can settle in seconds. A contract can execute without anyone intervening. The ledger can keep going on a Sunday night. Each of those features is useful, but each changes the conditions under which the bank manages risk.
So before getting too far into the infrastructure decision, it is worth working through liquidity, operations, smart contracts, interoperability, legal finality, privacy, and the providers the bank will depend on. Much of this will be familiar territory. Some of the timing, and some of the dependencies, will be different.
Risks Tokenized Deposits Bring Compared to Traditional Deposits
A tokenized deposit is a commercial bank deposit represented as a token on a blockchain or distributed ledger. It is backed 1:1 by the underlying deposit.
So, the holder still has a claim on the issuing bank only. Deposit insurance and existing banking protections generally carry over. In the US, the Federal Reserve has clarified this already.
We have a detailed article on tokenized deposit treatment in different countries. Read it here.
But why does that matter? Banks can introduce a different way of moving deposits without asking clients to accept a completely different financial claim.
But it only answers part of the risk question.
The legal rights may be the same while the way the bank records, transfers and controls the deposit changes quite substantially. A risk assessment needs to follow those changes through.
A tokenized deposit can receive equivalent capital treatment if it retains the same legal rights, insolvency ranking and repayment terms. The bank also has to show that tokenization has not introduced hidden liquidity or operational risk.
In other words, the continuity of the claim is important evidence. There is still work to do on the infrastructure.
We have seen the IMF also stressing the same principles. Traditional systems manage failures through institutional buffers and legal processes. Tokenized systems depend more directly on the correctness, resilience, and governance of code (page 3, IMF Note, Tokenized Finance, April 2026).
Screenshot to be added.
For the bank’s review, this brings the ledger, contracts, and keys into view alongside the balance sheet. They all play a part in whether the bank can meet its obligations.
How does 24/7 settlement change liquidity and run risk?
The first issue I would spend time on is the gap between a ledger that never closes and funding arrangements that still have operating hours.
Treasury teams already manage intraday liquidity. Continuous settlement changes the rhythm around which they do it. Payment cut-offs, netting cycles and end-of-day positions give the bank points at which to assess and fund its needs. Tokenized settlement can remove some of those points.
Credit exposures may fall, while the need for liquidity at the moment of transfer rises.
A corporate client moving money between subsidiaries on a Saturday will expect Saturday settlement if that is what the product offers. The bank then needs the funds, monitoring, and escalation arrangements to support it on Saturday.
That sounds simple. Getting all three to work together outside normal hours is where it becomes difficult.
Software agents could make the pattern harder to forecast as well. Payments for data, compute and services may continue through the night, and may not follow the daily patterns treasury has learned from existing clients. The models will need actual evidence from those flows.
Run risk needs a separate look.
Confidence in the issuing bank still supports the value of the deposit. What tokenization can change is how quickly holders act when that confidence weakens.
It may also change what other participants can observe. If large redemptions are visible on a shared ledger, holders can react to the activity they see, which may encourage further redemptions.
The IMF’s Tokenized Finance report published in April 2026 stressed that tokenized markets are developing faster. So banks have less time for discretionary intervention.
Banks have meaningful buffers against this. Diversified balance sheets, deposit insurance and access to central bank contingency funding reduce the likelihood that redemptions force asset sales.
The question is how those buffers would be used in the hours when the stress occurs. A weekend scenario needs to account for the availability of funding desks, markets and central bank facilities. It is worth testing that before promising clients continuous movement of funds.
What operational risks come with instant, irreversible settlement?
Settlement delays have given operations teams some room to catch problems. In a T+1 or T+2 workflow, there may be time to identify a wrong amount, an incorrect account, or a compliance issue before settlement completes.
With instant settlement, that room gets much smaller.
Once an instant transfer settles, the bank cannot simply pull it back. The inputs need to be right before execution.
That puts more responsibility on the checks before settlement. Sanctions screening, transaction limits, fraud checks, and dual approvals need to be part of the flow before the transaction reaches the ledger.
There will still be reconciliation. It just cannot be relied on to prevent a transfer that has already become final.
And the people supporting the process need to be available when it is running. Because our existing systems and control models were not designed for 24/7 operation. This is an operating model question as much as a technology question.
Integration is another substantial piece of work. A tokenized deposit is still on the bank’s books. Minting, transfers, and redemptions have to reconcile with the core banking system and the general ledger.
In one of KPMG’s reports, they also list systems integration, reconciliation, and the integrity of on-chain and off-chain records as separate risk areas.
I would want the team to walk through an actual break between those records. Which record governs? Who takes ownership? Can the issue be resolved while the service continues to run?
Those answers tend to reveal more than a statement that the systems will be integrated.
Why do smart contracts and private keys become bank risks?
Smart contracts can control minting, burning, transfers, and the conditions attached to a payment. For a tokenized deposit service, that makes them part of the bank’s operating machinery.
The programmability feature is also useful. A payment can be released when an agreed condition is met, without someone manually processing it.
The concern is what happens when the rule, or the information feeding it, is wrong. A coding error can affect transactions quickly. A faulty data feed can also trigger a series of automated actions before the bank has time to respond.
Banks are already well versed with test software and controlled releases. Smart contracts need to be assessed within those arrangements, with additional assurance where the consequences justify it. Important contracts may need formal verification and independent audits. Changes need an agreed approval process.
Emergency powers need thought too. There needs to be predefined mechanisms for pausing or adjusting execution under specified conditions.
It is easy to agree that a pause function is definitely needed. Deciding who may use it, on what evidence, and with what effect on outstanding transactions may require some discussion.
Administrative keys carry that authority because a key can allow someone to upgrade a contract or stop a transfer or similar kind of activity. Hence, upgradeability, admin key governance, and the mint, burn, and redeem lifecycle should be treated as distinct high-priority risk areas.
Transaction-signing keys are also sensitive. A compromised key may authorize a transfer that settles before anyone notices. Losing a key may prevent access when it is needed.
Generation, storage, rotation, recovery, and destruction of those keys- everything needs control. The technical work can sit with specialists, but the authority those keys carry belongs within the bank’s payment authorization and governance framework.
Will your tokenized deposits work across banks?
An internal tokenized deposit service can solve a useful problem. But sooner or later, a client may want to pay someone at another bank.
At that point, the value of the arrangement depends on what happens beyond the issuing bank’s network.
The client will expect the payment to arrive at face value. They will also expect a workable route to ordinary deposits or cash, without a discount because of which bank issued the token.
Cross-bank use needs shared standards and governance. In many designs, it also needs central bank settlement. Where those arrangements are missing, banks can end up building separate platforms with limited use outside their own networks.
There is a liquidity consequence as well. For example, separate settlement assets and liquidity pools can weaken par convertibility. This, in turn, can make netting less efficient and complicate crisis management.
Bridges offer a way to connect ledgers also, but they add trust assumptions and governance dependencies of their own. Stablecoin markets have already shown how third-party bridging and wrapping contracts can introduce operational and technical risk. Tokenized deposits have an advantage to learn from it.
The aim is singleness of money. Bank money should be usable at face value regardless of the issuing institution.
A bank starting internally does not need every cross-bank arrangement settled on day one. It should, though, understand whether its platform choice leaves that route open. Otherwise, a successful first use case may be surprisingly difficult to extend.
Is settlement on a blockchain legally final?
A ledger may confirm a transfer in a few seconds. But the bank still needs to know whether that transfer discharges the obligation in law and what happens if one counterparty fails.
Technical finality and legal finality need to be considered separately.
The IMF’s Tokenized Finance Note of April 2026 identified the following concerns as unresolved that can hold back adoption beyond pilots (page 7, IMF Note, Tokenized Finance, April 2026).
Screenshot to be added.
Unless these are resolved, any application can quickly become almost entirely legal discussions. For example, repo. And that is understandable. Because transfer of title, netting, and close-out rights have to hold up in the jurisdictions involved.
The code completing a transaction is only one part of that.
So the approach is to work on the contract code and legal agreements together. Smart contracts set out how execution happens. Legal agreements define the rights, obligations, and dispute arrangements around it.
Legal involvement needs to come early enough to shape the design. Leaving it until the technical model is complete can mean revisiting choices that already looked settled.
Does a permissioned network keep client data confidential?
Permissioning helps control participation. It does not, on its own, determine what participants can see.
In many permissioned designs, each node holds a readable copy of the full ledger. Some systems also allow one entity to observe everything (page 7, IMF Note, The Rise of Tokenization, June 2026).
Screenshot to be added.
For a shared banking network, that deserves a close look.
Balances, counterparties, and settlement amounts can reveal client relationships and liquidity positions. A participating bank may be able to see information about another bank’s clients that would ordinarily be confidential.
There are commercial sensitivities here, and banking secrecy and client confidentiality obligations. The fact that every member has been approved to join does not resolve them.
The visibility of redemptions matters for stress as well. If participants can watch a large outflow develop in real time, that information may influence their own decisions.
So privacy and confidentiality engineering, including selective disclosure, is a precondition for institutional adoption.
Selective disclosure gives a way to define access more carefully. Supervisors and auditors can receive the transaction evidence they need under agreed rules. Other participants see what their role permits.
This needs to be designed alongside compliance. AML monitoring, enhanced due diligence and client risk classification still have to work in token-enabled workflows. The bank needs enough information to carry out those checks, and enough time to act before settlement.
How should banks manage third-party and concentration risk in tokenization?
Few banks will build every layer themselves. Providers may support node operations, custody, wallets and smart contract development.
That can be a sensible way to get access to capabilities the bank does not yet have internally. It also creates dependencies that need to be understood quite specifically.
Some providers are not regulated like banks or established market infrastructures. The SODA survey also points to a shortage of institutional-grade custody providers (page 15, SODA Survey 2026).
Screenshot to be added.
If much of the industry uses the same small group, the concern extends beyond whether one bank has chosen a sound vendor. An outage or failure may affect several institutions at once.
A phased hybrid approach is best here. Partners help with the initial deployment, the bank gains operating experience, and internal controls develop as the service grows. Strategically important components can then be brought in-house where appropriate (page 23, KPMG, June 2026).
Screenshot to be added.
That approach leaves room to learn. It still needs an exit plan from the beginning.
Due diligence should cover security certifications, financial stability, governance, deployment options, and the practicalities of moving away from the provider. For custody, SOC 2 Type II and ISAE 3000 reports need to cover the relevant custody risks.
Deployment location also matters. A bank with data residency requirements may need infrastructure in its own cloud accounts or on its own premises. It is better to establish that option while choosing the provider, rather than discovering the constraint during rollout.
Where should a bank start managing tokenized deposit risk?
I would start with a use case narrow enough to understand properly, but useful enough to justify the work.
Internal liquidity movement between the bank’s own entities is one example. The bank controls both sides of the transfer, client exposure is low, and the team can test funding, controls, and reconciliation before bringing other institutions into the arrangement.
The pilot should answer a real business question. Otherwise, it can prove that tokens move while leaving the more important questions unresolved.
These four principles of KPMG can be useful for a proof of concept.
- Keep the impact on clients and regulatory requirements minimal.
- Build on existing infrastructure where possible.
- Choose a known pain point where the liquidity benefit can be measured.
- Design the first use case so later ones can reuse it.
Before launch, I would also want clear answers to the following.
These questions become much easier to discuss when the team walks through a particular transfer, including what happens when something goes wrong.
How Zeeve helps banks build tokenized deposit infrastructure with risk controls in place
Zeeve works with banks across the tokenized deposit stack. That includes architecture advisory for permissioned, public-permissioned, and hybrid networks, managed deployment and 24/7 operations, and integration with core banking, custody and compliance systems.
Zeeve’s modular privacy layer provides controls at the application, network, asset, and ledger layers.
The infrastructure runs in ISO 27001 and SOC 2 Type II compliant environments. Bring Your Own Cloud deployment is available for banks that need workloads within their own cloud accounts. Zeeve also supports migration from legacy blockchain infrastructure.
A useful place to begin is with one proposed use case and the questions in the table above. Work through the actual transfer flow, the funding behind it, and the controls needed at each stage.
Zeeve’s team can help with that mapping and the infrastructure decisions that come out of it. Connect with Zeeve to discuss the use case.
