Tokenised Deposits vs Stablecoins vs CBDCs: What Is the Difference?
Compare tokenised deposits vs stablecoins vs CBDCs by issuer, redemption, settlement, programmability and risk in this practical digital money guide.
Three forms of digital money can look alike on a screen while giving holders different legal claims, redemption routes and risks.
Understanding tokenised deposits vs stablecoins vs CBDCs starts with one question: who owes you the money? A tokenised deposit is a commercial bank’s liability. A fiat-backed payment stablecoin is a private issuer’s liability. A central bank digital currency is a central bank’s liability. This difference shapes how each form keeps its value, settles payments and can fail.
The Short Version
- Tokenised deposits are digital forms of commercial-bank deposits.
- Fiat-backed payment stablecoins depend on a private issuer, its reserves and its redemption process.
- CBDCs are central-bank liabilities, with retail and wholesale forms serving different users.
- All three can support code-based features, so programmability alone does not show which is safer or more suitable.
Tokenised deposits vs stablecoins vs CBDCs
These names describe more than different technology. They identify different promises to pay. They also point to different risks for the holder. A token may move fast or follow coded instructions, but its appearance does not reveal who stands behind it.
A tokenised deposit represents money owed by an issuing commercial bank. The term is not fully standardised. It may mean a digital representation of an existing deposit. It may also refer more broadly to bank money issued or moved on a ledger. The transfer and final settlement process can therefore vary by design.
A fiat-backed payment stablecoin is a private token designed to keep a stable value against a currency. That currency might be sterling, euros or US dollars. Reserve assets and a redemption process are meant to support its value. The holder does not own a central-bank liability. The holder’s practical claim can depend on the issuer’s terms and how the token was obtained.
A CBDC is a liability of a central bank. A retail CBDC would be intended for public use. A wholesale CBDC would mainly serve eligible financial firms and settlement systems. Evidence about wholesale settlement does not prove how a future consumer wallet would work.
Digital currency does not always mean a coin on a public blockchain. A retail CBDC might use wallets and might work online or offline. Some designs need not use blockchain. The system, access rules and operating model must be checked separately from the label.
Who Owes the Holder?
The clearest comparison is the balance-sheet relationship. A commercial bank owes the holder of a tokenised deposit. A private issuer carries the relevant stablecoin obligation under its terms. A central bank owes the holder of a CBDC.
This does not mean that every product within one group offers the same protection. A tokenised deposit keeps the holder exposed to the issuing bank. It also depends on the relevant banking, liquidity and deposit-protection rules. Whether a specific UK product has statutory deposit protection requires a product-level legal check.
Stablecoin users depend on a different chain. They rely on the issuer, the reserves, the redemption process and market liquidity. A token labelled as one pound can still trade below one pound. This may happen when traders doubt redemption, face delays or cannot redeem with the issuer.
A CBDC removes commercial-bank credit exposure at the instrument level. The central bank is the debtor. Yet access rules, service failures and design limits can still matter. Wallet access, system strength, identity controls and permitted uses could affect the holder.
How Value Stays Close to Par
Par means exchanging one unit of money for one unit of the same currency. People expect a pound in one bank account to buy what a pound elsewhere buys. The Bank for International Settlements calls this wider quality the “singleness of money”.
Bearer-style stablecoins can move away from par. Their market price reflects more than the amount printed on the token. Redemption barriers, views about the issuer and market conditions can all change the price. A person without direct redemption rights may have to sell to a buyer who demands a discount.
In the BIS model, tokenised deposits that settle in central-bank money can be better placed to exchange at par. Their link to established bank settlement can support the idea that one unit remains one unit. This is a model-based comparison. It does not prove that every tokenised deposit will always hold par or use the same settlement route.
Ledger finality is a separate issue. Blockchain Finality Explained describes when a blockchain transfer becomes hard or impossible to reverse. Finality shows whether a transfer is settled under a ledger’s rules. It does not prove that the asset can be redeemed at face value.
Networks, Custody and Control
Payment stablecoins often move as bearer-style tokens on public blockchains. Control may follow possession of the private keys for an address. The token contract and issuer may still include controls. These are common features, not rules for every stablecoin.
Tokenised deposits often sit on bank-run or permissioned systems. They are commonly redeemed through the bank. Yet a given design may settle on a ledger, outside it or through another system. That system might involve tokenised central-bank money. Product documents are more reliable than assumptions based on a name.
Custody is another layer. A user may hold keys, use an exchange or wallet provider, or act through a bank service. Crypto Custody Explained compares exchange accounts, hardware wallets and multisignature arrangements. Each choice places control and failure risk in different hands.
A CBDC could use wallets or private intermediaries without becoming a public blockchain token. Its operator might set access rules. Private firms might provide services to users. A wallet alone does not mean that the money is anonymous, unrestricted or held without an intermediary.
Programmability Across All Three Forms
Tokenisation can let a payment run after set conditions are met. For example, a delivery-versus-payment trade could release money when the matching asset moves. This may cut manual checks. It may also reduce the risk that only one side completes its part.
Stablecoins are often linked with smart contracts because many run on programmable public networks. Yet programmable execution is not unique to stablecoins. Tokenised deposits and some CBDC designs can also support automated settlement or smart-contract functions.
Programmable payments and programmable money are not the same. A programmable payment uses software to decide when or how to start a transfer. Programmable money may have rules built into the instrument. That can raise wider questions about limits, control and oversight.
Code brings its own risks. A process may repeat a wrong instruction. It may depend on bad data or another system that stops working. Automation changes how risk appears. It does not remove the need to assess the issuer, reserves and legal claim.
Privacy Depends on Design
There is no sound universal privacy ranking for these three forms of money. Privacy depends on the network and whether it uses wallets or named accounts. It also depends on intermediaries, identity checks and local rules. A public address may hide a name while exposing its full payment history.
A bank-run system may hide activity from the public while showing it to the bank and authorised parties. A CBDC could give intermediaries different levels of access to payment data. Its category alone gives no clear answer. Claims about freezing, identity checks or visibility must relate to a specific product and its rules.
Compliance duties can also cause data sharing. They are separate from the ledger’s basic design. The Crypto Travel Rule explains one part of that compliance setting. It is not a complete guide to privacy for deposits, stablecoins or CBDCs.
In Plain English
Imagine three tickets that each say £10. One says a bank owes you. One says a private token company promises to repay you. The last says the central bank owes you. The tickets may appear in similar apps and move in similar ways.
Yet the promise behind each ticket is different. That promise matters more than the screen design.
A Worked Example
Imagine Sam must pay £500 to a supplier after a digital certificate confirms delivery. The parties want the payment to happen on its own. They can consider a bank’s tokenised deposit, a sterling-linked payment stablecoin or a hypothetical eligible CBDC system.
With the tokenised deposit, Sam’s £500 is a liability of the issuing bank. The system could release it when the certificate arrives. The exact settlement route would depend on the bank’s design. Sam should identify the issuing bank, how the supplier can use the money and what happens during an outage.
With the stablecoin, Sam obtains tokens meant to be worth £500. A smart contract might send them when it receives the certificate. The supplier still needs to check whether direct redemption is possible. Fees, minimum amounts and delays may apply. The token could also trade below £500 on a market.
Suppose worried buyers offer only 98 pence for each token. A nominal £500 holding might then sell for about £490 before fees. This does not prove that reserves are missing. It shows how redemption access, market conditions and trust in the issuer can affect the amount received.
With a CBDC, the money sent would be a central-bank liability. A retail model might let Sam and the supplier use public-facing wallets. In a wholesale model, ordinary firms might not be allowed to hold it directly. The design would decide whether conditional payment was possible and which services were needed.
The example has no universal winner. A tokenised deposit links the parties to a bank and its system. A stablecoin links them to a private issuer and its redemption structure. A CBDC depends on central-bank design and access. The useful choice starts with the required claim, settlement route and tolerance for failure.
What This Means For You
First, identify the legal issuer. Do not rely only on the brand or the word “token”. Ask whether you would hold a bank deposit, an issuer-based stablecoin claim or a central-bank liability. If the provider cannot explain that point, the main risk is still unclear.
Next, map the route back to ordinary money. Find out who can request redemption and where the request goes. Check what is returned and whether fees, delays or minimum amounts apply. Selling to another trader is not the same as redeeming with the issuer.
Then consider how the system could fail. Think about an issuer failure, a bank outage or an unavailable network. Also consider a frozen wallet, lost credentials, faulty code and a price below par. Each product has a different mix of these risks.
UK and EU rules should not be assumed to work in the same way across all three groups. Claims about authorisation, safeguarding, insolvency, deposit guarantees or CBDC plans need current primary legal material. They also need facts about the product and customer. This general comparison cannot prove protection for a particular service.
Practical Checklist
- Confirm the issuer and the exact liability you would hold.
- Read the redemption terms and check whether you have direct access.
- Identify the custodian, network and any party that can delay a transfer.
- Check which currency and assets support the promise of stable value.
- Separate ledger settlement from legal finality and economic redemption.
- Verify any consumer or deposit protection for the specific product and customer type.
Stablecoins differ in their reserves, networks and redemption rules. Tokenised deposits differ in their ledgers and settlement paths. CBDCs differ between retail and wholesale models. A category description is therefore only the start of careful checking.
How Each Form Can Fall Short
A tokenised deposit may face bank credit trouble, outages or access limits. Its treatment outside the bank’s normal deposit system may also be unclear. A link to banking does not ensure that every token design gets the same legal treatment. The answer must be checked for the issuer, holder and product.
A stablecoin may lose market value or restrict redemption. Users may find it hard to assess the reserves. Contract, network, bridge, exchange and custody failures can add risk. Even full reserve backing would not always give every holder instant, free redemption at par.
A CBDC can avoid commercial-bank credit exposure at the instrument level. It can still suffer service outages or apply access rules. Privacy, offline use, intermediaries and transaction controls depend on its design. A central-bank issuer answers who owes the money, but it does not answer every question about use or rights.
What the Evidence Supports
The evidence supports a clear split between commercial-bank, private-issuer and central-bank liabilities. It also supports the point that all three forms may be programmable. Stablecoin market prices can move away from par. The BIS bulletin on stablecoins and tokenised deposits discusses par exchange, the singleness of money and settlement.
The language around tokenised deposits is less settled. Brookings’ comparison of payment stablecoins and tokenised bank deposits separates a tokenised version of an existing deposit from a native deposit token. Other accounts use “tokenised deposit” more widely. Readers should therefore inspect the real design.
An Oxford Law Blogs author predicts that tokenised deposits may become the most durable model. The argument is that they could join programmable systems with established banking safeguards. This is a forecast, not a proven result. Law, markets, designs and demand may develop in another way.
No product recommendation follows from this comparison. A consumer making a payment has different needs from a bank settling securities. A developer building an automated market may have different needs again. A broad category cannot settle which product suits a particular person or task.
Recap
The key difference is the debtor. A commercial bank stands behind a tokenised deposit, a private issuer stands behind a stablecoin, and a central bank stands behind a CBDC. Network design and code affect how each instrument moves. Reserves, redemption rights, access and legal terms affect what the holder can recover. Similar-looking tokens can therefore carry very different risks.