Start with the legal claim and the settlement event, not the token interface. Identify the issuing bank, who can hold the deposit, whether an on-ledger transfer changes bank liabilities, how redemption and finality work, and which other banks or networks can interoperate. Then test exceptions and reconcile each ledger to the bank's books.
Short answer
A tokenized deposit is a deposit claim on a commercial bank represented through a digital ledger. That does not make it interchangeable with a stablecoin or eliminate the need to understand who owes whom money. The BIS discussion of stablecoins and tokenised deposits distinguishes the claims and settlement models; the Bank of England's Digital Securities Sandbox discussion also treats tokenized deposits and regulated stablecoins as different potential settlement assets.
For an institutional buyer, the first question is what is actually settled, where, and when. A fast transaction record is useful only if legal finality, bank liability, liquidity and reconciliation are equally clear.
Step 1: Trace the legal claim
Request the term sheet and scheme rules. Record the issuing bank, account or liability represented, eligible holders, jurisdiction, deposit-protection position if any, redemption claim and insolvency treatment. Do not infer these from the word "deposit" or from a token contract.
Ask whether a transfer moves a claim on the same bank, creates or extinguishes a claim, or triggers separate interbank payment. If two banks participate, ask which institution owes the recipient after transfer and how the banks settle between themselves. The BIS 2026 speech on tokenised deposits discusses why singleness of money and central-bank-money settlement matter in such designs; it does not certify any commercial scheme.
Step 2: Define the settlement event
Write one sentence that a lawyer, bank operator and engineer can all test: "The recipient's claim becomes final when ___." Fill it with a contractual event, not just a block confirmation. Map the network event, bank-book entry, payment-system entry and any central-bank-money leg. Include reversals, freezes and operational cutoffs.
| Question | Evidence to request | Failure case to run |
|---|---|---|
| Who can hold the claim? | Bank onboarding and scheme rules | Transfer to an ineligible recipient |
| When is transfer final? | Contractual finality rule and event log | Chain event succeeds but bank posting fails |
| How is value redeemed? | Redemption terms and operating hours | Redemption request during outage |
| How do banks reconcile? | Liability ledger and interbank records | Sender and recipient ledgers disagree |
| What crosses networks? | Interoperability design and controls | Bridge or message arrives twice |
Step 3: Map eligibility and privacy
Define which legal entities, investors, banks and wallets may participate. Decide who performs customer due diligence and sanctions screening, what identity attributes travel with a payment, what remains private, and who can halt an impermissible transfer. The control design is part of the product; a public wallet address by itself does not establish that an institution is eligible.
Step 4: Reconcile all records
Build a daily control with opening liability, credited deposits, debits, reversals and closing liability. Tie it to token balances or ledger positions and to the issuing bank's records. Separately reconcile any interbank settlement leg. Flag timing differences rather than hiding them in a net figure.
If the product also funds a tokenized fund, connect the deposit transaction identifier to the investor, order, mint or allocation and later redemption. See the investor onboarding stack and the stablecoin payment RFP for adjacent workflows. Neither article substitutes for bank scheme rules.
Step 5: Run an exception-led pilot
Test a valid transfer and redemption first. Then force an ineligible recipient, insufficient funds, duplicate instruction, delayed network message, sanctioned address, bank-side outage and rejected redemption. For each, identify the system of record, customer-facing status, operator who can resolve it and evidence retained for audit.
Do not compare tokenized deposits with stablecoins on speed alone. Compare the actual claim, permitted counterparties, settlement asset, finality, integration burden and recovery process. This is a procurement framework, not legal or banking advice.
Primary sources
- BIS: Stablecoins versus tokenised deposits
- BIS: Pushing the monetary frontier, 2026
- Bank of England: Modernising money and markets
FAQ
Is a tokenized deposit the same as a stablecoin?
No. A tokenized deposit is a commercial-bank deposit represented on a ledger; a stablecoin has a different issuer and legal claim. The exact arrangements must be read in the applicable product terms.
Does an onchain transfer automatically complete bank settlement?
Not necessarily. Ask which ledger event is legally final, when bank records change, and whether a separate central-bank-money or interbank settlement leg remains.
What should a pilot test first?
Test an eligible sender and recipient, then insufficient balance, a blocked recipient, an unavailable network, a disputed transaction, redemption and end-of-day reconciliation.
Can any wallet receive a tokenized deposit?
Do not assume so. Bank onboarding, eligibility, supported networks and transfer restrictions depend on the particular scheme and jurisdiction.
Map your settlement stack
Compare the bank, payment, custody and tokenization roles before choosing an integration. Prefer email? contact@fluidrwa.com.