Tokenized Deposits and Stablecoin Infrastructure for Banks
Issuing Bank Money That Moves Like a Token
Banks approaching tokenised money usually frame the question as which network to use. That is the least consequential decision. The consequential ones are what the instrument legally is, how a holder converts it back into ordinary money, and whether the bank ends up with two systems that each believe they hold the authoritative balance for the same customer.
Getting tokenized deposits stablecoin infrastructure right starts with the distinction between the two things in that phrase, because they are not variations on a theme. They are different instruments with different holders, different risks, and different regulators.
What is the actual difference?
A tokenised deposit is a claim on a bank. A stablecoin is a claim on an issuer against reserves.
| Dimension | Tokenised deposit | Stablecoin |
|---|---|---|
| Legal claim | On the issuing bank, as a deposit | On the issuer, against reserve assets |
| Balance sheet | Bank's own liability | Issuer's liability, reserves as assets |
| Deposit protection | Generally applies as for deposits | Generally does not apply in the same way |
| Redemption | At par, as a deposit withdrawal | At par where the arrangement provides it |
| Holder base | Typically the bank's own customers | Potentially open, depending on design |
| Regulatory frame | Banking regulation | Stablecoin-specific and payments regimes |
| Run dynamics | Bank deposit dynamics | Depends on reserve quality and redemption terms |
Why does the distinction matter more than the technology?
Because it decides who bears loss if the issuer fails, which is the only question holders ultimately care about.
A tokenised deposit is the bank's existing liability represented differently, so the holder's protection is broadly that of a depositor. A stablecoin holder's position depends on the legal claim over reserves and the redemption mechanism, which is precisely why the FSB's July 2023 final report on global stablecoin arrangements recommends a robust legal claim to all users against the issuer or the underlying reserve assets with timely redemption, and that single-currency stablecoins be redeemable at par into fiat. Decide which instrument you are issuing before any architecture work, because the answer changes the accounting, the capital, the disclosure, and the customer proposition.
Are you issuing a claim on your bank or a claim against a reserve pool?
What does the FSB expect of a stablecoin arrangement?
Governance, risk management, transparency, redemption, and authorisation before operating.
The FSB's ten high-level recommendations include a comprehensive governance framework with clear and direct lines of responsibility, comprehensive risk management covering operational resilience, cyber security, and anti-money laundering and counter-terrorist financing, comprehensive and transparent information on governance, conflicts of interest, operations, and financial condition, a robust legal claim with timely redemption and par redemption for single-currency arrangements, stabilisation mechanisms and prudential requirements to mitigate run risk, and confirmation that all regulatory requirements are met before commencing operations. Read as an engineering brief, that means the platform must produce evidence continuously rather than assert compliance, and that reserve and redemption mechanics are product design rather than treasury detail.
What must the platform do?
Issue, redeem, transfer, hold balances, integrate with the core, screen, and report.
| Function | Requirement |
|---|---|
| Issuance | Mint against a funded deposit or reserve contribution, with controls and limits |
| Redemption | Convert back at par, within a stated time, under stress as well as normally |
| Transfer | Move between eligible holders with controls applied |
| Balance and ledger | Authoritative record with full history and as-at querying |
| Core integration | One customer balance view, reconciled continuously |
| Screening and controls | Sanctions and AML at transfer, freeze and seize capability |
| Reserve management | Where applicable, composition, custody, and reporting |
| Reporting and attestation | Position, reserve, and transaction reporting |
Why is redemption the critical path?
Because the instrument's value rests entirely on convertibility, and stress is when it is tested.
Design redemption first: who can redeem, through which channel, within what time, up to what daily capacity, and what happens when requests exceed normal volume. Then model the stressed case explicitly, including concentrated redemption from a few large holders, redemption outside business hours, and redemption when the underlying settlement rail is closed. An instrument that redeems reliably on a Tuesday afternoon and not on a Sunday night has a redemption promise that is narrower than its transfer capability, and holders will discover the gap at the worst moment.
How does it integrate with the core ledger?
With one authoritative balance, never two.
This is the central design risk. If a customer's deposit is represented both in the core banking ledger and on the token ledger, and both can be updated, then the bank has two sources of truth for one liability. Pick one authoritative record and derive the other. The common pattern is that the core remains authoritative for the deposit, with the token ledger as a controlled representation and every token movement producing a corresponding core entry, reconciled continuously with breaks alarmed. The alternative, making the token ledger authoritative, is coherent and requires the core to accept it as such, including for accounting, reporting, and interest. Whichever you choose, the reconciliation is permanent rather than transitional, and it needs an owner, as with any dual-representation arrangement described in this guide to payment reconciliation.
What does the accounting need?
Entries that satisfy the general ledger and an audit trail that reconstructs any balance at any time.
Token movements are economic events requiring accounting treatment, and auditors will ask how a balance at a point in time was derived. Keep an append-only event history with the ability to reproduce any balance as at any moment, tie every movement to a core accounting entry, and retain lineage from reported figures back to the transaction. That lineage requirement is the same one in this guide to data lineage and audit trails.
What about interoperability between banks?
The hard part, and the area where the most useful evidence now exists.
A deposit token that only moves between one bank's customers is a closed-loop product with limited value. Interoperability requires either a shared platform, a bridging mechanism between bank platforms, or settlement through central bank money. The BIS Innovation Hub's Project Agorá is testing precisely this: a multi-currency shared programmable platform for wholesale cross-border payments involving eight central banks and more than forty financial institutions, combining tokenised central bank reserves with tokenised commercial bank deposits to enable atomic settlement. Its real-value testing in July 2026 involved 28 institutions completing approximately CHF 800,000 across multiple currencies, with average settlement of approximately 80 seconds, covering payment-versus-payment among other use cases, and demonstrating interoperability with existing RTGS and core banking systems using ISO 20022.
What should a bank take from that evidence?
That the mechanism works and that interoperability with existing infrastructure is the design target.
Two lessons are directly actionable. First, ISO 20022 bridging to existing RTGS and core systems is achievable and is the right assumption rather than a migration to a wholly new rail. Second, settlement measured in tens of seconds indicates the constraint is coordination and operational processing rather than ledger performance, so invest accordingly. The atomic settlement mechanics around this are covered in atomic settlement and delivery-versus-payment.
Is your tokenised money designed to interoperate, or to work inside your own customer base?
Talk to Digiqt about interoperability and core integration design
How do AML and transfer controls work?
Screening at transfer, restricted transferability, freeze capability, and transfer information where rules apply.
Screen both parties at transfer against current lists rather than at onboarding only, since transfers occur continuously and listings change. On a permissioned network, restrict transferability to verified holders, which is far simpler than trying to control an open network. Retain the ability to freeze holdings and to prevent transfers where legally required, and be explicit in the product terms that this capability exists. Where transfers fall within crypto-asset transfer rules, originator and beneficiary information obligations apply, which is the subject of travel rule compliance for virtual asset transfers. Design for the awkward case early: a transfer to an address you cannot attribute to a verified holder should be blocked rather than investigated afterwards.
What prudential and liquidity treatment applies?
A dedicated cryptoasset framework, plus a rethink of deposit outflow behaviour.
The Basel Committee's standard on the prudential treatment of cryptoasset exposures, published in December 2022 with implementation from 1 January 2025, creates a Basel Framework chapter covering three categories including tokenised traditional assets and stablecoins. For a bank holding or issuing these instruments, classification affects capital, which affects the economics of the product.
Why does continuous transferability change liquidity assumptions?
Because deposits that can leave at any hour behave differently from deposits constrained by business hours.
Conventional deposit outflow modelling assumes payment rails and customer behaviour bounded by operating hours and processing cycles. A deposit token transferable at three in the morning on a Sunday removes that boundary, which affects intraday liquidity monitoring, buffer sizing, and the assumptions behind stress scenarios. Treat it as a new outflow channel with its own behavioural assumptions, monitor it continuously, and connect it to the intraday liquidity picture rather than reporting it separately. The mechanics of funding a continuously available obligation are covered in instant payment liquidity management and the monitoring in intraday liquidity monitoring.
What operational model does this require?
Continuous coverage, live change capability, and someone able to act on redemption and freeze requests at any hour.
A token transferable continuously creates an operation that never closes. Redemption requests, freeze instructions, screening alerts, and incidents can arrive at any time, and each needs a person with authority. Plan the coverage model alongside the architecture, rehearse the scenarios that require a fast decision, particularly a suspected compromise of issuance keys or a sanctions freeze, and accept that deployment must be safe under live traffic since there is no maintenance window. Where distributed ledger technology genuinely helps and where it adds complexity for its own sake is worth being candid about internally, which is the framing in this assessment of blockchain in practice.
How should delivery be sequenced?
Instrument decision, then redemption, then core integration, then transfer, then interoperability.
| Phase | Duration | Deliverable |
|---|---|---|
| Instrument and legal design | 3 to 5 months | Deposit token or stablecoin, claim structure, regulatory path |
| Redemption mechanism | 2 to 3 months | Channels, capacity, timing, stressed-case modelling |
| Core ledger integration | 4 to 6 months | One authoritative balance, continuous reconciliation, accounting |
| Issuance and controls | 2 to 3 months | Minting controls, limits, key custody, freeze capability |
| Screening and transfer controls | 2 to 3 months | Transfer-time screening, eligibility, transfer information |
| Closed-loop pilot | 3 to 4 months | Real customers, narrow use case, full operational model |
| Interoperability | 4 to 8 months | Bridging or shared platform, ISO 20022 mapping, reconciliation |
| Continuous operating model | 2 to 3 months | Coverage, live change, rehearsed incident paths |
Redemption before transfer is the sequencing that matters most. A token that moves beautifully and redeems unreliably is a liability rather than a product, and the redemption design constrains everything from reserve composition to operating hours.
Which metrics matter?
Reconciliation breaks, redemption performance under load, screening coverage, transfer failure causes, and continuous availability.
Report reconciliation breaks between token ledger and core with ageing, targeting zero, since any break means a customer balance is ambiguous. Measure redemption time and capacity utilisation, including the worst observed period, because that is the promise being tested. Track screening coverage at transfer and the age of the lists used. Report transfer failures by cause, separating control blocks from technical failures. Measure availability across the full calendar rather than business hours. And track the value transferred outside business hours as a share of the total, since that number quantifies how much your liquidity assumptions need to change.
Tokenised bank money is one of the few areas in this domain where the evidence has moved ahead of the debate: wholesale atomic settlement using tokenised reserves and deposits has now been demonstrated with real value across multiple currencies. What remains genuinely hard is unglamorous and internal, namely never letting two ledgers believe they hold the same balance, and being able to redeem at par at three in the morning.
Frequently Asked Questions
What is the difference between a tokenised deposit and a stablecoin?
A tokenised deposit is a claim on a bank recorded differently, sitting on the bank's balance sheet. A stablecoin is a claim on an issuer backed by reserves, with a different legal and regulatory position.
Why does the distinction matter more than the technology?
Because it determines the legal claim, deposit protection, balance sheet treatment, regulatory regime, and who bears risk if the issuer fails. The ledger mechanics are secondary.
What does the FSB expect of stablecoin arrangements?
Ten recommendations covering governance with clear responsibility, risk management including operational resilience and AML, transparency, and a robust legal claim with timely redemption at par.
Why is redemption the critical path?
Because the token's value rests on the ability to convert back at par reliably. Redemption capacity, timing, and behaviour under stress define whether the instrument holds.
What is the central design risk in core integration?
Two representations of the same deposit. If the token ledger and the core banking ledger can disagree about a customer's balance, you have created a reconciliation liability.
Does live experimentation show this works?
For wholesale use, yes. BIS Project Agora combined tokenised central bank reserves and commercial bank deposits, with real-value testing in July 2026 settling in around 80 seconds.
How do AML controls work on token transfers?
Screening at transfer against current lists, transfer restrictions on permissioned networks, freeze capability, and originator and beneficiary information where transfer rules apply.
How does continuous transferability change liquidity risk?
Deposits that can move at any hour behave differently from ones constrained by business hours, so outflow assumptions and intraday liquidity monitoring need revisiting.
