Tokenized Deposits vs Stablecoins vs CBDC: Bank Money on Programmable Rails

Systems-architecture analysis only. This is not financial, investment, legal or regulatory advice, and regulatory status described here changes quickly.

Three different instruments are being sold as “digital dollars”, and engineers keep treating them as one thing with three logos. They are not. Tokenized deposits are ordinary bank liabilities with a programmable wrapper, stablecoins are claims on a reserve pool held by a non-bank or bank subsidiary issuer, and a central bank digital currency (CBDC) is a direct claim on the central bank. Each has a different legal creditor, a different settlement asset, and a very different answer to the question that matters most in payments: when exactly is the money final, and who has to make you whole if it is not?

That question matters now because the three are converging in production rather than in white papers. A large US bank has put a deposit token on a public chain, a US federal statute defines “payment stablecoins”, and the Bank for International Settlements (BIS) has argued for a tokenized unified ledger that puts reserves and deposits side by side.

This post gives you a mental model built on three tests (the claim, the finality asset, and fungibility across issuers), a reference architecture for a deposit-token platform, the reconciliation problem nobody puts in the keynote, and a comparison matrix you can take into a design review.

What this covers: definitions and legal claims, the three-test model, reference architecture, interoperability and unified-ledger designs, core-ledger reconciliation with runnable code, failure modes, and a practical checklist.

Context and Background

Money in a modern economy is layered. At the top sits central bank money: reserves held by commercial banks at the central bank, plus physical cash. Below it sits commercial bank money, which is what most people and companies actually hold: a deposit is a bank’s IOU, redeemable at par for central bank money on demand. This is the two-tier system, and its stability rests on a trick that economists call singleness: a dollar in Bank A and a dollar in Bank B are accepted at the same face value, because each bank promises par redemption, is supervised, and settles with the others in central bank reserves.

Programmable ledgers disturb this arrangement in three different ways, and each disturbance has produced one of our three instruments. Stablecoins arrived first from outside the banking system: a private issuer takes dollars, holds reserve assets, and issues a transferable token on a public blockchain. Central banks responded with CBDC research and pilots, which in the retail case would give households a direct claim on the central bank. Banks, meanwhile, asked the obvious question: why not keep the deposit, which is already the dominant form of money, and just make it move on the new rails? That is the tokenized-deposit answer.

The BIS has been the most explicit institutional voice on the architecture. In its 2025 Annual Economic Report chapter, summarised in its 24 June 2025 press release, it argues that stablecoins fail three tests of sound money, which it labels singleness, elasticity and integrity, and it proposes a tokenized unified ledger that combines tokenized central bank reserves, tokenized commercial bank money and tokenized government bonds. You do not have to accept the BIS conclusion to find the framing useful: it tells you which properties to check on each instrument.

Several of the pieces are already covered elsewhere on this site. For the payment-rail view, see our analysis of cross-border payments architecture across SWIFT gPI, correspondent banking and stablecoin rails. For the central-bank side, see digital euro vs e-CNY vs digital rupee. For securities and real-world assets that increasingly need a cash leg, see RWA tokenization architecture. This post takes a distinct angle: it treats all three as designs for the same job, putting a settlement-grade money leg on a programmable ledger, and compares them on liability, finality, and operational integration with the bank’s core system.

A note on vocabulary. “Tokenized deposit”, “deposit token” and “tokenized bank deposit” are used interchangeably in industry writing, though some authors reserve “deposit token” for a bank-issued bearer-style token and “tokenized deposit” for a ledger representation of an existing account. I will use them as synonyms and flag where the distinction changes the architecture.

The Three-Test Model: Claim, Finality Asset, Fungibility

The shortest accurate answer: a tokenized deposit is a claim on a commercial bank, a stablecoin is a claim on an issuer backed by a reserve pool, and a CBDC is a claim on the central bank. They differ in who owes you, which asset discharges the payment, and whether tokens from different issuers trade at par. Everything else (chain, wallet, smart-contract standard) is implementation.

Figure 1: Three instruments, three creditors. The vertical axis is the settlement hierarchy: the further down a payment settles, the closer it is to central bank money.

Figure 1 is worth reading slowly. Each of the three instruments sits in a different place relative to central bank money, and that placement, not the token format, determines its risk. Tokenized deposits sit above commercial bank balance sheets, and interbank settlement still happens in reserves. Stablecoins sit above a reserve pool whose assets are deposits, Treasury bills and similar instruments. A wholesale CBDC or tokenized reserve is the bottom layer itself.

Test 1: Who is the creditor?

The first test is the legal claim. Holding a tokenized deposit means you are a depositor of the issuing bank. In jurisdictions with deposit insurance, the insurance regime attaches to the underlying deposit, not to the token as such, so whether a given token is covered depends on how the bank structures the account and on the insurer’s rules. A secondary source describing JPMorgan’s deposit token on Base states that it is a bank liability eligible for FDIC insurance up to applicable limits; treat any such statement as something to verify against the issuer’s own terms, because coverage is a legal question about the account, and token design does not settle it.

Holding a stablecoin makes you a creditor of the issuer, with a claim that is only as good as the reserve pool and the legal ring-fencing around it. The US GENIUS Act, signed on 18 July 2025 according to the secondary summaries I reviewed, requires reserves of at least par value of outstanding payment stablecoins, restricts eligible reserve assets to categories such as cash, insured-bank demand deposits, short-dated Treasuries and certain repos, and excludes reserves from the issuer’s bankruptcy estate. Whether holders end up near the front of the queue in a real insolvency is, per at least one academic commentator quoted in secondary coverage, contested. For the rule-making detail, see our post on the Fed and GENIUS Act proposed rules on reserves and capital.

Holding a retail CBDC would make you a direct creditor of the central bank, which cannot become insolvent in its own currency. That is the strongest possible credit profile and also the reason retail designs come with holding limits and intermediated distribution: policymakers do not want deposits to flee banks wholesale.

Test 2: What asset finalises the payment?

The second test is settlement finality. A payment is final when it is irrevocable and unconditional, and the asset that makes it so is the settlement asset. For an on-us tokenized deposit transfer (both parties at the same bank), finality is a ledger update at that bank, and the bank’s own legal terms decide when it is irrevocable. For a transfer between two banks, a tokenized deposit does not by itself discharge the obligation: Bank A now owes less to its customer and Bank B owes more to its customer, so Bank A must transfer something to Bank B. That something is central bank money, or a claim on a settlement agent, or a netted position that settles later. The token moved quickly, but the interbank obligation still has to be settled.

A stablecoin transfer on a public chain gets technical finality from the chain’s consensus (probabilistic on some chains, deterministic after checkpointing on others), but legal finality is a separate matter that depends on the governing law and the issuer’s terms. The two can diverge, which is a recurring theme in this post.

A wholesale CBDC or tokenized reserve moves the settlement asset itself, so finality is the central bank’s own. The European Central Bank (ECB) has described a two-track approach to this: a short-term pilot called Pontes, expected to link distributed-ledger platforms to TARGET services so transactions settle in central bank money, and a longer-term initiative called Appia. The coverage I reviewed gives a Q3 2026 target for the Pontes pilot; check the ECB’s own pages for the current state before relying on dates.

Test 3: Do tokens from different issuers trade at par?

The third test, fungibility or singleness, is where architecture decisions get expensive. A dollar deposit at Bank A and a dollar deposit at Bank B are interchangeable today because of the infrastructure behind them: payment systems, par clearing rules, deposit insurance, supervision. Tokenized deposits inherit that interchangeability only if the interbank plumbing is rebuilt for tokens. If each bank issues its own token on its own ledger, you recreate a fragmented-money problem: a “Bank A token” and a “Bank B token” are different assets that happen to promise the same face value, and moving between them needs a conversion step with latency and counterparty risk.

Stablecoins have the same problem horizontally. Two fully reserved stablecoins from different issuers can trade at a spread, and history shows that spread widens under stress. The BIS makes this point under the heading of singleness. A CBDC avoids the problem by construction because there is one issuer.

Putting the three tests together

A useful way to use the model is to score any proposal on all three before discussing technology. A “bank-issued stablecoin” is an informative edge case: if it is a liability of the bank, it is a tokenized deposit under another name; if it is issued by a subsidiary holding reserves, it is a stablecoin with a bank sponsor. The marketing label does not change the legal claim. The engineering consequence is that you cannot choose a token standard first and sort out the creditor later, because the creditor determines the accounting, the capital treatment, the insurance position, and which team inside the bank owns the ledger.

Why programmability is a separate axis

Programmability is often listed as a feature of one instrument. It is not. It is a property of the ledger the instrument lives on. Conditional payment, atomic delivery-versus-payment, and scheduled or milestone-based release are all achievable with any instrument that sits on a ledger that supports smart contracts or equivalent logic. What differs is who may program the money. A bank can embed controls in a deposit token (allowlists, transaction limits, freeze for sanctions), because it is the legal issuer and has KYC on every holder. A permissionless stablecoin can be freely composed with any contract, which gives developers more reach and gives compliance teams more worry. A central bank may allow programmability in the settlement layer while forbidding it in the money itself, an important design principle in several CBDC proposals: the platform is programmable, the money is not.

Reference Architecture for a Deposit-Token Platform

If you are building or integrating a deposit-token service, the core design decision is the relationship between the token ledger and the bank’s core ledger. There are three recurring patterns, and they have very different failure profiles.

Pattern A: Mirror (the core ledger stays the book of record)

The bank keeps the customer deposit in its core banking system. A token ledger holds a mirrored balance. On token transfer, an orchestration service debits and credits the underlying core accounts, and the token ledger is updated afterwards or in the same atomic business transaction. The token is effectively a rail, a fast channel for instructions against the same deposit.

The advantage is that regulatory reporting, interest accrual, deposit insurance records and anti-money-laundering (AML) monitoring continue to work on the system they were built for. The disadvantage is that you inherit core-banking latency and batch windows, and you must maintain two views that can drift.

Pattern B: Escrow-and-mint (a segregated account backs the tokens)

The customer funds are moved into a segregated omnibus account at the bank, and tokens are minted one-for-one against it. Transfers happen on the token ledger; redemption burns tokens and credits the customer’s ordinary account. This looks like a stablecoin operationally even though the claim is still on the bank.

It decouples token throughput from core-banking throughput, because transfers never touch the core. The price is a reconciliation invariant that must hold at all times: total tokens outstanding must equal the balance of the segregated account. A secondary source describing the JPMD design on Base characterises it as backed one-for-one by segregated USD accounts at the bank; this is the escrow-and-mint pattern, and I could not verify the exact accounting treatment from a primary source, so treat it as reported.

Pattern C: Native (the token ledger is the book of record)

The deposit itself lives on the distributed ledger, and the core system sees a summarised balance. This is the most radical option and the one furthest from today’s banking stack. It is also the closest to the BIS unified-ledger vision in which messaging, reconciliation and settlement collapse into one process. Few banks will start here.

The control plane around the token

Whatever the pattern, a deposit-token platform needs the same surrounding components, and most of the engineering effort goes into them rather than into the token contract.

Identity and eligibility: every wallet address maps to a KYC-verified legal entity. The chain may be public but the participant set is not.
Policy engine: per-wallet and per-transaction limits, sanctions screening on counterparties, time-of-day rules, and a freeze/seize capability for legal orders.
Orchestrator: a workflow service that coordinates debits, credits, mints and burns, with idempotency keys and a durable log.
Key management: hardware-backed keys for issuer authority (mint/burn), with dual control. Loss of issuer keys is a loss of the monetary system, so this is usually the most scrutinised component.
Reconciliation service: a continuous three-way match across token ledger, core ledger, and the settlement or reserve account.
Observability and reporting: transaction monitoring, regulatory reports, and the audit trail an examiner will ask for.

Figure 2: A cross-bank tokenized deposit payment. The token moves in seconds; the interbank obligation is settled separately, and the core ledgers are updated through the orchestrator.

Figure 2 shows the sequence for a payment between customers of two different banks, using the mirror pattern. The sender’s instruction is screened, the sender’s bank debits the core deposit and burns or reserves the sender-side token, the receiving bank mints or credits the receiver-side token, and the banks settle the net obligation through a settlement asset. The central observation: the fast part (steps one to four) and the final part (the settlement asset movement) are different events. A design that conflates them will report “settled” to a customer before the banks have discharged their obligations to each other.

What the public chain does and does not change

A notable 2025 development is that a bank put a deposit token on a public network. The Block reported on 12 November 2025 that JPMorgan rolled out its JPMD deposit token on Base, an Ethereum layer-2 network, for institutional clients following a pilot that began in June 2025, with B2C2, Coinbase and Mastercard among those that completed test transactions. The reporting says settlement is near-instant and available around the clock. A secondary analysis calls this “permissioned tokens on a permissionless chain”: the settlement layer is public while holders must be verified institutional clients.

For an architect, this has concrete consequences. The bank’s token contract must enforce transfer restrictions at the contract level (only allowlisted addresses may hold or receive), because the chain will not. Chain-level risks such as sequencer outages on a layer-2, reorganisations, and bridge exposure become operational risks of the bank’s payment product. And public-chain transparency changes the privacy model: balances and counterparties may be visible on-chain unless the design uses privacy techniques, a point regulators and corporate treasurers both raise.

JPMorgan’s earlier JPM Coin, launched in 2019, ran on a private permissioned ledger. The move to a public base layer is a trade: wider reach and composability in exchange for new dependencies and exposures. Neither choice is universally better, and the same bank can reasonably run both for different client segments.

Settlement-asset options for the interbank leg

Banks that exchange deposit tokens have four broad choices for the interbank leg.

Central bank reserves on a tokenized platform. The cleanest, and the one central banks are now piloting (for example Pontes in the euro area). It is available only where the central bank offers it and only during its operating arrangements.
Reserves through the existing RTGS. The token layer is fast, the interbank leg settles over Fedwire, TARGET2-successor services and similar systems, subject to their hours. See our post on Fedwire, CHIPS and RTGS finality.
A shared bank-run ledger with a pooled settlement account. The model behind multi-bank platforms: participants hold balances in a common ledger backed by funds at a settlement agent or central bank. Partior and Fnality are platforms of this class, although their precise legal and operating structures should be checked against their own documentation.
Bilateral on-ledger netting with periodic settlement. Cheaper in liquidity but it builds credit exposure between banks between settlement cycles.

Each option moves the liquidity burden differently. Pre-funding a shared ledger is simple and immediate but ties up capital. Netting economises liquidity but needs credit limits and a default waterfall. Anyone claiming that tokenization removes liquidity management has not looked at the interbank leg.

A worked example with illustrative numbers

Take two banks that exchange 40,000 cross-bank payments a day with an average value of 250,000 USD (illustrative figures, not drawn from any source). Gross daily flow is 10 billion USD. Suppose flows are roughly symmetric, so that the net position at day end is about 3 percent of gross, or 300 million USD, and intraday peak net exposure is 8 percent, or 800 million USD. Under real-time gross settlement on a shared ledger, the pair needs enough pre-funded balance to cover the worst intraday imbalance in each direction, which could be several times the net figure depending on arrival patterns. Under netting with end-of-day settlement, the cash needed is the 300 million net, but the banks carry up to 800 million of intraday credit exposure to each other. That trade between liquidity and credit is old; tokenization changes the speed of the customer leg, not the trade.

Interoperability: Fragmented Tokens or a Unified Ledger?

Once more than one bank issues a deposit token, the central design problem is interoperability. Three families of answer are emerging, and the evidence for each is at a different stage of maturity.

Figure 3: Three ways to make deposit tokens from different banks interoperate. Complexity moves from many bilateral links to one shared platform.

Design 1: Bilateral or framework-based bridges

Banks keep separate token ledgers and agree a protocol for moving value between them. On 11 November 2025, DBS and Kinexys by J.P. Morgan announced that they were exploring a framework to exchange and settle tokenized deposits between DBS Token Services and Kinexys Digital Payments across public and permissioned blockchains. Their stated example is a J.P. Morgan client paying a DBS client in JPMD on Base, with the recipient then exchanging or redeeming through DBS Token Services. The announcement states the principle of preserving the singleness of money but, as far as I could verify, does not describe the technical mechanism, so I will not guess at one.

The structural issue with bilateral bridges is combinatorial. With N banks the number of pairwise links grows as N(N-1)/2, so a market of 20 banks implies 190 bilateral agreements, each with its own legal terms, operational testing, and monitoring. Hub-and-spoke or network-level standards reduce the count but reintroduce a central operator.

Design 2: A shared multi-bank ledger

Participants hold balances on a common platform. Transfers between participants are internal ledger moves with immediate finality inside the platform’s rules, and the platform is funded at a settlement agent. This resembles an upgraded correspondent-banking network with a shared book. It trades the combinatorial problem for a governance problem: who runs the platform, who is liable for its failure, and how are participants admitted and removed? This is where multi-currency platforms such as Partior position themselves; verify the current participant set and legal structure from the operator, because both have changed over time.

Design 3: A unified ledger with tokenized central bank reserves

The BIS blueprint puts tokenized reserves, tokenized commercial bank money and tokenized government bonds on one programmable platform, so that messaging, reconciliation and settlement become one process. The BIS Innovation Hub’s Project Agorá is its most concrete test of the idea for wholesale cross-border payments. According to the BIS project page, it involves eight central banks and over 40 financial institutions with the Institute of International Finance, and its design uses jurisdictional ledgers for central bank reserves and a unifying ledger for deposits, with ISO 20022 messages (pacs.008, pacs.009 and camt.053) as the interface to RTGS and core banking systems. For the messaging background, see our post on ISO 20022 migration.

The BIS reports that its real-value testing covered 28 institutions, 17 scenarios and 30 transactions totalling about CHF 800,000 across six currencies, with an average initiation-to-settlement time of about 80 seconds, and that legal reviews found tokenization does not change the legal nature of reserves or deposits and that settlement finality is achievable. Three cautions apply. The test was small and controlled. The project is described as a proof of concept, not a product. And the page’s own dating of the testing is ambiguous, so check the BIS source for the current status.

The interesting conceptual point of Agorá is atomic payment-versus-payment: a euro deposit token and a dollar deposit token exchange in one indivisible step, removing the classic foreign-exchange settlement risk in which one leg pays and the other does not. That is something shared-ledger tokenization offers that sequential correspondent banking cannot.

Where stablecoins and CBDC fit in the interoperability picture

Stablecoins interoperate through market liquidity rather than through a legal framework: you swap one for another on an exchange or through the issuer’s mint and redeem channel. That works when markets are calm and is fragile when they are not. The interoperability question for banks is whether to treat a regulated stablecoin as a counterparty asset (accept it, convert it) or as a competitor (offer a deposit token instead). Our post on a bank stablecoin consortium covers one hybrid approach, and our overview of stablecoin payment infrastructure covers the rails view.

A wholesale CBDC interoperates by being the common denominator: every bank has an account at the central bank, so a CBDC-based settlement layer is the one asset all participants already accept. Retail CBDCs are a different design problem, with offline use, privacy tiers and distribution through intermediaries, and are covered in the digital euro comparison linked earlier.

Stablecoins and CBDC Architecture in Brief

A fair comparison needs the other two architectures stated just as concretely.

Fiat-backed stablecoin. The issuer takes in dollars through a mint channel (typically limited to verified institutional customers), holds reserve assets at custodians, and issues tokens against them. The token is transferable between any addresses that the chain permits, with issuer controls that usually include blocklist and freeze functions. Holders outside the primary channel access liquidity through exchanges and market makers. The architecture has three trust anchors: the reserve custodian, the issuer’s legal structure, and the chain.

Regulatory regimes now define the category. In the US, the GENIUS Act, as summarised in secondary sources I reviewed, sets 1:1 reserve backing, prohibits issuers from paying interest or yield solely for holding the token, defines three issuer pathways (a subsidiary of an insured depository institution, a federal nonbank issuer, or a state-qualified issuer with a size cap), and phases in implementation with regulations due around mid-2026 and enforcement by early 2027 at the latest. The same sources reported that as of May 2026 no agency had finalised its rules; check current status. In the EU, the Markets in Crypto-Assets Regulation (MiCA, Regulation (EU) 2023/1114) treats fiat-referenced stablecoins as e-money tokens, which may be issued only by credit institutions or electronic money institutions, must be redeemable at par on request, and may not pay interest.

An implication that engineers sometimes miss: the no-interest rule for stablecoins and the interest-bearing nature of deposits mean that, at the same face value, a tokenized deposit can pay interest and a payment stablecoin cannot. That is a product-design difference, not just a legal footnote. It also means the policy question of whether banks may pass yield through to deposit-token holders is separate from the stablecoin prohibition, and I have not verified a unified position on it across jurisdictions.

Wholesale CBDC and tokenized reserves. The central bank operates the ledger or a platform connected to its RTGS. Participants are supervised financial institutions only. Money creation and redemption follow existing reserve operations. The ECB’s exploratory work in 2024 settled close to 1.6 billion euros in central bank money using DLT, according to the coverage reviewed, which informed the Pontes and Appia tracks. For retail CBDC, my companion post on the digital euro covers design; the short version is that the central bank typically avoids interacting with individual users directly and relies on supervised intermediaries for wallets and KYC.

UK and other tokenized-deposit initiatives. In the UK, banks including Barclays, Lloyds and HSBC were reported to have begun a pilot of tokenized sterling deposits through UK Finance, with reported use cases including a mortgage remortgage, and the Bank of England’s public positioning on systemic stablecoins has been more cautious than its stance on bank-issued tokens. I could not verify detailed terms from primary documents for this post, so treat the specifics as reported.

The comparison matrix

Dimension	Tokenized deposit	Fiat-backed stablecoin	Wholesale CBDC / tokenized reserves	Retail CBDC
Legal creditor	Issuing commercial bank	Issuer, via reserve pool	Central bank	Central bank
Backing	Bank balance sheet, fractional	Reserve assets per regime	Central bank itself	Central bank itself
Interest-bearing	Possible, as a deposit	Barred in US and EU regimes	Policy choice	Policy choice, often limited
Deposit insurance	Depends on account and scheme	Generally not as a deposit	Not applicable	Not applicable
Settlement asset	Reserves or shared-ledger balance	Chain consensus plus issuer redemption	The token itself	The token itself
Who may hold	KYC-verified clients	Often anyone on chain, with issuer controls	Supervised institutions	Public via intermediaries
Cross-issuer fungibility	Needs interbank framework	Market-based, can depress	Single issuer	Single issuer
Programmability owner	Issuing bank	Issuer plus open composability	Platform, not money	Platform, not money
Typical status in 2026	Live and piloting, mostly institutional	Live and regulated in some regions	Pilots, with euro-area track dated Q3 2026	Varies by country
Main architectural risk	Core-ledger drift, fragmentation	Reserve, run and depeg risk	Central bank platform scope	Disintermediation controls

Read the matrix by row rather than by column. The “legal creditor” and “settlement asset” rows decide most of the others.

Reconciling the Token Ledger to the Core Ledger

The least glamorous and most decisive part of a deposit-token programme is reconciliation. A token is only as trustworthy as the invariants that tie it to the bank’s books. Auditors, supervisors and your own treasury team will ask the same question: at any instant, can you prove that tokens outstanding equal the liability recorded in the general ledger?

Figure 4: A continuous three-way reconciliation pipeline. Breaks route to an exceptions queue with a policy that can halt minting.

The invariants

Three invariants cover most of the surface. First, supply conservation: for the escrow-and-mint pattern, the sum of all token balances must equal the balance of the segregated backing account, and total mints minus total burns must equal outstanding supply. Second, posting parity: each token transfer event must correspond to exactly one set of core postings (in the mirror pattern) or to none (in the escrow pattern, where only mint and burn touch the core). Third, settlement parity: the net of cross-bank token transfers over a settlement window must equal the movement in the settlement account.

Each invariant has a failure signature. A supply mismatch with extra tokens is the most severe, because it implies unbacked money, and the control response is to halt minting until resolved. A supply mismatch in the other direction (more backing than tokens) is less urgent and usually a timing artefact. Posting parity breaks usually come from retries without idempotency, or from a core system that rejected a posting after the token side had already moved.

Runnable example: a three-way match in Python

The following script is a minimal, self-contained illustration of the first two invariants. It uses plain dictionaries in place of real ledgers, so you can run it as-is and adapt the structure. It is a teaching sketch, not production code: it has no persistence, concurrency control or authentication.

from collections import defaultdict
from decimal import Decimal

# Token-ledger events: (event_id, kind, wallet, amount)
token_events = [
    ("t1", "mint",     "wallet_a", Decimal("1000.00")),
    ("t2", "transfer", "wallet_a->wallet_b", Decimal("250.00")),
    ("t3", "mint",     "wallet_c", Decimal("500.00")),
    ("t4", "burn",     "wallet_b", Decimal("100.00")),
]

# Core-ledger postings against the segregated backing account:
# (posting_id, ref_event_id, direction, amount)
core_postings = [
    ("c1", "t1", "credit_backing", Decimal("1000.00")),
    ("c2", "t3", "credit_backing", Decimal("500.00")),
    ("c3", "t4", "debit_backing",  Decimal("100.00")),
]

def replay_balances(events):
    bal = defaultdict(Decimal)
    for _, kind, who, amt in events:
        if kind == "mint":
            bal[who] += amt
        elif kind == "burn":
            bal[who] -= amt
        elif kind == "transfer":
            src, dst = who.split("->")
            bal[src] -= amt
            bal[dst] += amt
    return bal

def backing_balance(postings):
    total = Decimal("0")
    for _, _, direction, amt in postings:
        total += amt if direction == "credit_backing" else -amt
    return total

def reconcile(events, postings):
    breaks = []
    bal = replay_balances(events)
    supply = sum(bal.values())
    backing = backing_balance(postings)

    # Invariant 1: supply conservation
    if supply != backing:
        breaks.append(("SUPPLY_MISMATCH", f"tokens={supply} backing={backing}"))

    # Invariant 2: every mint or burn has exactly one core posting
    needs_posting = {e[0] for e in events if e[1] in ("mint", "burn")}
    posted = defaultdict(int)
    for _, ref, _, _ in postings:
        posted[ref] += 1
    for ev in sorted(needs_posting):
        if posted[ev] != 1:
            breaks.append(("POSTING_PARITY", f"{ev} has {posted[ev]} postings"))
    for ref in posted:
        if ref not in needs_posting:
            breaks.append(("ORPHAN_POSTING", ref))

    # Control: never allow negative wallet balances
    for w, v in bal.items():
        if v < 0:
            breaks.append(("NEGATIVE_BALANCE", f"{w}={v}"))
    return breaks, supply, backing

breaks, supply, backing = reconcile(token_events, core_postings)
print("supply:", supply, "backing:", backing)
print("breaks:", breaks or "none")

# Inject a fault: a mint with no core posting (unbacked tokens)
token_events.append(("t5", "mint", "wallet_d", Decimal("75.00")))
breaks, _, _ = reconcile(token_events, core_postings)
print("after fault:", breaks)

Run it and the first reconciliation reports no breaks, because 1,000 plus 500 minus 100 gives 1,400 outstanding against 1,400 backing. After the injected fault, the script reports both a supply mismatch (1,475 tokens against 1,400 backing) and a posting-parity break for event t5. A production version would stream events from the chain and the core system, compare on a rolling window, and carry a policy table that maps each break type to an action (alert, hold, or halt minting).

Timing: why you need two clocks

The match has to tolerate legitimate timing differences. The chain finalises on its own schedule, the core system posts in business-day sequences, and the settlement account may only update during RTGS hours. A robust design keeps two clocks: the business-effective time (when the customer’s money moved) and the book time (when each system recorded it). This is the same discipline as bitemporal modelling in ledgers; see our post on event sourcing and bitemporal data for financial audit trails and the broader ledger database architecture post. For the data store itself, see TigerBeetle vs Postgres for financial ledgers.

Practically, define tolerance windows per leg and treat a break as real only after the window has elapsed. A mint that has been confirmed on-chain but not yet posted at the core is a pending item, not an error, for as long as the core’s posting SLA allows. Beyond that window it becomes an exception with an owner and a clock.

Idempotency and ordering

Most posting-parity breaks trace to duplicate delivery. Chains can reorganise, event listeners can replay on restart, and orchestrators can retry after timeouts. The standard defence is an idempotency key derived from the chain’s transaction hash and log index, written to a durable store before any core posting is attempted, and checked on every retry. For ordering, process events by block number and log index, and hold reorganisation-sensitive events until the chain’s finality rule for that network is satisfied. On networks with soft finality that means waiting; on networks with deterministic finality it means waiting for the checkpoint. Either way, “confirmed” in the chain explorer is not the same as “final” in the bank’s books.

Reporting and the audit trail

Supervisors will want evidence rather than assurances. That means immutable reconciliation snapshots (end-of-day supply, backing, and break counts), retained exception histories with resolution notes, and a reproducible method for re-deriving any historical balance from raw events. If the token ledger is public, the on-chain history becomes part of the evidence but not the whole of it: the bank’s internal records, the policy engine decisions, and the approvals for issuer-key operations also matter. Treat the reconciliation system as a regulated control, with change management and segregation of duties, rather than as a monitoring dashboard.

Trade-offs, Gotchas, and What Goes Wrong

Fragmentation is the default outcome. Unless banks coordinate, each issues a token on its preferred chain with its own controls, and you get a tokenized version of the pre-par-clearing era. The DBS and Kinexys announcement exists precisely because the singleness principle does not emerge by itself. Plan for conversion paths, and price the latency and credit risk of crossing between issuers.

Fast customer leg, slow bank leg. The most common design failure is telling a customer “settled” at the token event while the banks have not yet discharged their obligation. The customer-facing status model needs distinct states (accepted, token-final, bank-settled, reconciled), and the legal terms must say which one is irrevocable. If your platform settles interbank only during RTGS hours, weekend token activity builds an exposure that surfaces on Monday.

Public-chain dependency risk. Putting a bank product on a public layer-2 imports sequencer downtime, congestion-driven fee spikes, upgrade risk in the base protocol, and bridge or cross-chain risk when tokens move between networks. A bank can mitigate with multi-chain deployment and fallback rails, but each additional chain multiplies the reconciliation surface. The roadmap items reported for JPMorgan, such as further chains and a euro deposit token, are plans rather than delivered facts, and I could not verify them from primary sources.

Run dynamics differ. A bank deposit is backed by the whole balance sheet plus lender-of-last-resort access and, where applicable, deposit insurance. A stablecoin is backed by a reserve pool with no lender-of-last-resort, which is why the redemption-at-par promise and the quality of reserves carry so much weight. Stablecoin runs can be faster than bank runs because redemption and secondary-market selling can happen at machine speed around the clock. Tokenized deposits do not remove run risk either: a 24/7 settlement rail with a bank balance sheet behind it means a run can also happen at weekends, when central bank liquidity facilities are normally closed. Treasury teams need intraday and weekend liquidity plans.

Compliance does not become simpler. Sanctions screening, AML monitoring and the Travel Rule obligations for transfers apply regardless of the ledger. A permissioned-holder model makes this tractable for deposit tokens, because every address maps to a known client. Permissionless stablecoins push the burden to issuers and intermediaries, and on-chain analytics become a core control. Either way, freeze and seize capability is a legal requirement in practice, and it is also a point of centralised power that must be governed.

Privacy versus transparency. Public ledgers expose transaction graphs. Corporates will not accept their supplier payments being traceable, so any production design needs a privacy layer, permissioned execution environments, or off-chain settlement of sensitive details. This is an unresolved area, and claims that it is “solved” deserve scepticism.

Capital and accounting treatment. How the prudential rules treat a tokenized deposit versus a stablecoin exposure affects the business case. My understanding is that the Basel Committee’s cryptoasset standard distinguishes tokenized traditional assets, which are intended to be treated like their underlying, from stablecoins, which face their own conditions, and that parts of the standard were under review; I did not verify the current text for this post, so consult the Basel Committee’s publications and your regulator.

Smart-contract and key risk. Whatever the legal wrapper, the token contract is software. Upgradeable proxies are convenient and introduce admin-key risk. Immutable contracts remove that and make fixing bugs hard. A reasonable middle path is a minimal, audited core with narrow, timelocked, multi-party upgrade rights, and an operational runbook for pausing transfers. Issuer-key ceremonies, key rotation and disaster recovery are as important as the contract itself.

Anti-pattern: choosing the chain first. Teams often pick a network because of a vendor relationship or a developer preference, then discover that their legal, settlement and reconciliation requirements point to a different design. Decide the claim, the finality asset and the interoperability model first, then pick technology that supports them.

Anti-pattern: treating the token as the product. The token is a thin layer. The product is the combination of onboarding, policy, orchestration, liquidity management, reconciliation and reporting. Budget accordingly: the token contract is usually a small fraction of the engineering effort.

Practical Recommendations

If you are an architect at a bank, a fintech, or a corporate treasury evaluating these instruments, the decision is rarely “which one wins”. It is “which one for which flow”. Deposit tokens fit bank-to-corporate and bank-to-bank flows where counterparties already hold accounts, where interest and deposit-insurance treatment matter, and where regulated KYC is a feature. Regulated stablecoins fit flows that must reach counterparties outside the banking perimeter, accepting issuer and reserve risk in exchange for reach. Wholesale central bank money on a tokenized platform fits the final settlement leg, where its availability and legal scope allow.

For a platform team, the build order matters more than the instrument choice. Start with the control plane and the reconciliation service, because they are needed under every instrument and because a token without them is a liability. Add the token contract next, with transfer restrictions enforced in code. Add interoperability last, once you know which counterparties and which settlement asset you will actually use. Teams that reverse this order tend to ship a demo that cannot be audited.

For a corporate treasurer, the questions to put to a provider are practical. Who is my legal counterparty? What settles the payment, and when is it irrevocable under the governing terms? Does the balance earn interest, and is it covered by deposit insurance? What happens if the chain is unavailable? Can I redeem at par outside business hours? Can I move value to a counterparty at another bank, and by what mechanism? If the answer to the last question is “convert through an exchange”, you are holding a different asset than you think.

Pre-launch checklist

Write down the legal creditor, the settlement asset and the finality moment for each instrument in scope, and get legal sign-off on the wording.
Choose a ledger-to-core pattern (mirror, escrow-and-mint, or native) and document the invariants it must satisfy.
Implement idempotency keys from chain transaction hash and log index before connecting the core system.
Enforce holder allowlists and transfer restrictions in the token contract, not only in the application layer.
Build the three-way reconciliation with explicit tolerance windows and a halt-minting control for unbacked-supply breaks.
Define customer-facing status states and map each to a legal meaning.
Plan weekend and intraday liquidity, including behaviour when the interbank settlement leg is closed.
Run a key-ceremony and recovery drill for issuer authority before go-live.
Decide the interoperability route, and price the conversion cost between issuers.
Re-verify regulatory status for every jurisdiction in scope within 30 days of launch, since several regimes are still being implemented.

Frequently Asked Questions

What is the difference between tokenized deposits and stablecoins?

A tokenized deposit is a digital representation of a bank deposit, so the holder has a claim on a commercial bank, which can pay interest and may fall under deposit insurance depending on structure. A stablecoin is a claim on an issuer backed by a reserve pool of assets such as cash and short-dated government securities. The creditor, the backing, and the regulatory regime differ, and in the US and EU regimes described above, stablecoin issuers may not pay interest for holding the token.

Are tokenized deposits the same as a CBDC?

No. A CBDC is a liability of the central bank, whereas a tokenized deposit is a liability of a commercial bank. Both can sit on programmable ledgers and the BIS vision places them on the same unified platform, but the credit risk and settlement role differ. Interbank settlement of deposit tokens still ultimately relies on central bank money, whether through existing real-time gross settlement systems or through tokenized reserves such as the euro-area Pontes pilot.

Is JPMorgan’s JPMD a stablecoin?

Reporting describes JPMD as a deposit token, a representation of JPMorgan deposits for institutional clients on the Base network, not a stablecoin issued by a separate entity. It was rolled out in November 2025 after a pilot beginning in June 2025, according to The Block. Because the claim is on the bank, the regulatory and insurance treatment follows deposit rules rather than payment-stablecoin rules, but you should confirm exact terms in the issuer’s documentation.

Do tokenized deposits settle instantly?

The customer-facing transfer can be near-instant and available around the clock, but instant token movement is not the same as final interbank settlement. If two banks hold separate token ledgers, they still need to settle the net obligation using central bank money, a shared-ledger balance or another settlement asset. Whether that leg is instant depends on the chosen design. BIS Agorá testing reported an average of about 80 seconds from initiation to settlement for wholesale cross-border payments.

Why do banks prefer tokenized deposits over stablecoins?

Banks keep the deposit on their balance sheet, so funding, lending capacity and customer relationships are preserved, while stablecoin growth could pull deposits into reserve pools outside the bank. Tokenized deposits can also pay interest, fit into existing deposit-insurance and supervisory frameworks, and use KYC the bank already holds. The trade-off is fragmentation: separate bank tokens must be made interoperable to preserve singleness, which stablecoins attempt through market liquidity instead.

What is the BIS unified ledger?

It is the BIS vision of a programmable platform combining tokenized central bank reserves, tokenized commercial bank money and tokenized government bonds, so that messaging, reconciliation and settlement collapse into one process. Project Agorá applies the idea to wholesale cross-border payments with central banks and over 40 financial institutions. It is a research and prototyping effort, not a deployed market infrastructure.