Tokenised Deposits

Bank deposit claims represented on programmable platforms

The deposit remains the claim

A tokenised deposit represents a claim on a commercial bank recorded or transferred using a token arrangement. The holder's money is still a bank liability; the platform is a way to record and move that claim. The precise legal structure matters. A bank should show how a token maps to a named depositor, account or register, and what event changes the bank's liability.

A tokenised deposit is not automatically a stablecoin or a central bank digital currency (CBDC). A stablecoin can be a claim on a non-bank issuer or other reserve arrangement. CBDC is a central bank liability. The stablecoin and CBDC chapters examine those models separately. The labels and protections of a real product depend on its contracts and local law.

Two ways value can move

In an on-us transfer, both customers hold claims on the same bank. The bank can debit one depositor and credit another while updating the token records. The bank must make the token state and its deposit book agree under one posting rule.

In an interbank transfer, the payer and payee may hold deposits at different banks. Their bank liabilities change, and the banks need a settlement asset or other arrangement to discharge what they owe each other. A token moving between wallet addresses does not by itself settle the interbank obligation. BIS analysis highlights the role of central bank money and the two-tier monetary system in preserving the singleness of money. The transfer design must therefore identify both the customer deposit legs and the bank-to-bank settlement leg.

Customer deposit claims and interbank settlement as separate legs of a tokenised deposit transfer.

Why programmability matters

A programmable platform can bind a payment to a condition, such as delivery of a tokenised security. It may allow the asset and payment legs to execute together. That can reduce reconciliation and principal-risk exposure when the conditions and legal effect are sound. It also creates new operating questions: who can set or change the condition, which data source triggers it, whether an instruction can be cancelled, and what happens if one leg fails.

Project Agorá, a BIS-led public-private project, has tested a shared programmable platform combining tokenised commercial bank deposits with tokenised central bank reserves for wholesale cross-border payments. Its reported prototype is evidence of a possible design, not proof that a particular bank can deploy the same model or that every payment is now available around the clock. A product team should separate prototype capability from production permission, participant eligibility and service commitments.

Worked example: two-bank supplier payment

A buyer at Bank A owes a supplier at Bank B. Bank A verifies the buyer's authority and available funds, then prepares the deposit debit and token instruction. The arrangement must identify when Bank B accepts a corresponding deposit obligation to the supplier and how Bank A and Bank B settle between themselves, perhaps using tokenised central bank money in a design that supports it.

The customer-facing state has at least three stages: instruction accepted, interbank settlement completed, and supplier deposit available. If Bank B rejects the supplier credit after the bank-to-bank leg, the arrangement needs an exception path. If the token instruction is rejected before settlement, Bank A should not show the supplier as paid. Durable identifiers should join the customer instruction, token event, settlement event and deposit postings for reconciliation and investigation.

The example is simplified. Real scheme rules, settlement finality and posting order must be taken from the actual arrangement. The bank should test duplicate instructions, cut-off differences, an unavailable participant and a disputed beneficiary before promising “instant” to a corporate customer.

The bank's books and liquidity

Issuance, transfer and redemption should be explainable against the bank's deposit ledger. If a bank converts an existing deposit balance into a token representation, it must decide whether the deposit account remains the authoritative record, whether a separate sub-ledger is used, and how double counting is prevented. If a token is redeemed into an ordinary account balance, the token state and deposit posting should change under a controlled process. The bank should be able to prove outstanding tokens against the matching deposit liability.

Interbank transfers can move liquidity earlier or more continuously than existing batch patterns. Treasury needs visibility into prefunding, intraday exposures, settlement assets and any limits set by the arrangement. Operations needs a queue for pending and failed transfers rather than treating every network event as a final deposit movement. Finance needs reconciliations between platform positions, deposit accounts, settlement accounts and the general ledger.

The right measure is not token throughput alone. Track unmatched liabilities, aged reconciliation breaks, customer instructions still pending after network action, failed conditional transfers, liquidity usage and time to restore a correct customer state.

Controls and customer protection

The bank should document who may mint, burn, transfer, freeze or recover a tokenised deposit claim. Signing controls, segregation of duties, key recovery and platform-change approvals need evidence. The authority to reverse or correct an error may be limited by the network and the legal arrangement; the bank must not promise an unconditional reversal.

The deposit's legal and prudential treatment must be checked for the actual jurisdiction, entity and instrument. Tokenisation does not automatically preserve every feature of an ordinary deposit if the holder, transferability, contractual claim or insolvency treatment has changed. A launch file should contain legal analysis, customer terms, operational rules, accounting treatment and a tested failure path.

Takeaway

Tokenisation changes how a bank deposit claim can be recorded and transferred. It does not remove the bank liability or the need for interbank settlement. A credible design joins the holder's right, token state, deposit book and settlement asset under rules that operations can test.

Sources and review scope

The sources below explain design principles and project learning. They do not determine the legal or prudential treatment of a particular product.