Mechanics: what changes vs traditional deposits
A traditional bank deposit moves through a hierarchy of payment systems: cheque, ACH, wire, real-time gross settlement, card rails. Tokenisation collapses several of these layers into a single ledger operation while preserving the legal character of the underlying deposit.
The differences that matter are programmability, on-chain transferability among permissioned holders, atomic delivery-versus-payment (DvP) and payment-versus-payment (PvP) settlement (covered in Chapter VI), conditional payments triggered only when a specified condition is met, and 24/7 availability subject to the bank's internal operating-hour rules. The MAS Project Orchid framing of "purpose-bound money (PBM)" sits at the conditional-payments end: a tokenised cash unit can carry programmatic restrictions binding use to a specific purpose, closer to a cash voucher with on-chain enforcement than to free-flowing money.
The 24/7 point deserves a footnote. The chain can run 24/7. The bank cannot, not in the sense of having staff on-call to handle every reconciliation exception. Most production systems define explicit operating windows, with off-window transactions queued for the next window. Selling a 24/7 product when the bank's reconciliation team is on weekends is a recipe for a month-end outage.
What does not change
The deposit is still bank money. It is still a liability of the bank, recorded on the balance sheet, subject to deposit insurance where applicable, subject to anti-money-laundering and counter-financing-of-terrorism (AML/CFT) and know-your-customer (KYC) obligations at the bank level, and subject to the same prudential capital and liquidity treatment as any other deposit on the same balance sheet.
This is the part the Web3 instinct underestimates. Putting the deposit on a chain does not change the banking law treatment of the underlying liability. The depositor has a claim against the bank, not against a token. In an insolvency, the deposit insurance scheme covers the depositor up to the relevant cap on the same terms as for any other deposit at the same bank. The chain is a transfer mechanism. The bank is still the bank.
For a tokenisation product team, the implication is that the regulatory work on the deposit token is largely already done, because the deposit is already regulated. The new questions are about the ledger, the smart contract, the reconciliation logic, and the operational risk of the chain. The deposit law is settled. This is one reason tokenised deposits have shipped faster than novel stablecoin perimeters in several jurisdictions.
Issuance models
Four issuance models are visible in production today.
The single-bank ledger is the simplest. A bank issues tokens against its own deposit liabilities on a chain it operates. The customer's claim moves on the chain; the bank's general ledger reconciles continuously; if the two diverge, the books govern. Kinexys Digital Payments is the worked example. JPMorgan operates the chain (a Quorum-derived stack, see Permissioned blockchains) and supports intraday and cross-border movements among institutional clients. One ledger, one bank, operationally clean. The limitation is that it cannot, by itself, handle inter-bank flows.
The consortium ledger is the multi-bank generalisation. Several banks issue tokens against their respective deposit liabilities on a shared ledger. Partior is the worked example for cross-currency interbank settlement among DBS, JPMorgan, and Standard Chartered, on a Quorum-derived stack. Each bank's tokens represent its own deposit liabilities; cross-bank transfers settle through PvP, with netted-out exposure handled at the settlement bank or correspondent layer.
The central-bank-coordinated tiered ledger sits a layer up. Commercial banks issue tokenised deposits at the deposit layer; the central bank operates a wholesale CBDC at the settlement layer; inter-bank settlement of tokenised deposit movements happens against the wCBDC. Project Ensemble in hong kong, run by HKMA, is the production-grade APAC example. The HKMA's Phase 2 sandbox progress release sets out the live use cases under the tiered architecture. The model handles the cross-bank transferability problem cleanly because the settlement asset is genuinely central bank money rather than a netting promise.
The Fnality model is the genuinely hybrid case. A separate-licensed institution holds central bank reserves at a participating central bank and issues a tokenised settlement instrument on a permissioned chain against those reserves. It looks like a tokenised deposit (token representing a claim against an issuer holding the underlying cash), a wholesale CBDC (underlying cash is central bank money), and a stablecoin (non-bank issuer, 1:1 redemption). The legal characterisation in each jurisdiction is bespoke. Fnality has accounts at multiple central banks (notably the Bank of England via the Omnibus Account regime) and operates a sterling settlement product in production. The category-defying nature is the point: a deliberate attempt to put central bank money into a tokenised form without a full wCBDC programme.
A picking guide for which model fits which problem. If the flow is intraday, intra-bank, and the counterparties are already customers of the same institution, the single-bank ledger is overwhelmingly the right answer; this is most of the Kinexys volume. If the flow crosses banks but stays within a small consortium with a shared correspondent or settlement bank, a consortium ledger like Partior collapses correspondent steps without requiring a central-bank rail. If the flow needs to cross banks at scale with finality at the central bank's books, the tiered ledger is the right architecture and the live work is in Hong Kong via Ensemble. If the jurisdiction has not yet built a wCBDC programme but wants central-bank-money settlement on programmable rails, the Fnality construction is the fallback. The choice is rarely a technology question. It is a question about which inter-bank arrangement the participants can actually sign.