Where you are. Eight lessons of stablecoin: a claim on a non-bank issuer, backed by segregated reserve assets, moving on a shared ledger. Banks have been watching this and have built something else.
A bank looks at all of this and asks an obvious question. Its customers already hold balances. Those balances already move. Why does moving them faster require a new issuer, a new legal entity and a portfolio of bills?
So the bank tokenises the deposit instead. Your balance is still a deposit, still on the bank’s balance sheet, still covered by whatever deposit protection applies. What changes is that it now moves as a token on a shared ledger, with the settlement finality and the programmability that brings.
The idea in one paragraph
A tokenised deposit is commercial bank money in token form: the token is the bank’s liability, the same liability a deposit always was, and holding one makes you a creditor of that bank exactly as before. It differs from a stablecoin in what stands behind it, which is the bank’s whole balance sheet rather than a segregated portfolio, and usually in where it can go, since most implementations move only inside one bank’s network or a consortium’s. It is a competing design rather than a variation on the same one, and the choice between them is the module-1 question in new clothes: whose failure are you exposed to, and what stands behind the claim when it happens?
Failing the bank
The exercise models both claims and fails the bank holding them.
A tokenised deposit is a claim on the bank, so when the bank fails the holder’s recovery is whatever the bank’s assets support, plus deposit insurance up to its limit. A stablecoin holder’s claim is on segregated reserve assets that the bank’s failure does not touch, unless of course some of those reserve assets happen to be deposits at that same bank, which lesson 5 warned about and which is exactly what happened in the March 2023 episode.
| instrument | what stands behind it | recovery when the bank fails |
|---|---|---|
| tokenised deposit | the bank’s whole balance sheet, plus insurance to its limit | partial, then insured up to the cap |
| stablecoin | segregated reserve assets in a separate entity | unaffected, unless reserve assets sat at that bank |
n = 2 trials · the holding bank fails, recovery per unit
Why banks prefer it
Three reasons, all of them structural rather than technological.
It keeps the deposit on the bank’s balance sheet, which is where the bank’s funding comes from; a customer moving money into a stablecoin is a customer withdrawing funding from the bank. It stays inside the existing regulatory perimeter, so no new licence is needed. And it lets the bank offer the settlement properties customers are asking for without conceding that a non-bank should be doing this at all.
The same map
Put both on module 1’s two-tier picture and the argument becomes clear.
A tokenised deposit sits exactly where a deposit always sat: tier two, a commercial bank’s liability. A stablecoin sits outside the tiers entirely, a non-bank’s liability backed by assets it holds. Neither is central bank money, so neither is the top tier, and both settle finally only when whatever stands behind them is actually paid.
That is the shape of the whole argument between banks and issuers, and it is a fight about which tier the public’s money should sit on rather than about technology.
Check yourself
1. What is a tokenised deposit a claim on?
The bank that issued it. It is the bank’s liability, exactly as an ordinary deposit is, and the holder is the bank’s creditor. Tokenising changes how the balance moves rather than what the balance is.
2. Which is safer, a tokenised deposit or a stablecoin?
Neither in general. Against the issuing bank failing, the stablecoin holder is better placed, unless the reserve assets happened to sit at that bank. Against the stablecoin issuer failing, the insured depositor is better placed. The question has no answer until you name the failure being considered.
3. Why do banks prefer this design?
Because the deposit stays on their balance sheet as funding, the product stays inside the regulatory perimeter they already occupy, and they can offer the settlement properties customers want without conceding the business to non-banks. All three reasons are structural rather than technical.
4. What is the limitation, and what does overcoming it require?
Reach. A token that moves only within one bank’s network is an improvement on that bank’s own transfers, which were already instant. Making it useful means banks accepting each other’s tokens, which is the interoperability problem the rails of module 2 spent decades on, arriving again in a new form.
Do this
Fail the bank and compare.
python3 code/deposit_vs_coin.pyThe starter models a tokenised deposit as a claim on one bank and a stablecoin as a claim on segregated reserve assets, then fails the bank. You write the recovery calculation for each. The assertions check that the deposit holder’s recovery depends on the bank’s assets and its insurance cap, and that the stablecoin holder is untouched when the reserve assets sat elsewhere.
The completed version is in solutions/deposit_vs_coin.py.
What you can now do. You can place both instruments on the two-tier map, say whose failure each exposes you to, and explain why the comparison has no answer without naming the failure. The next lesson goes to the top tier and asks what central bank money in token form would mean.