A tokenized deposit represents a deposit claim on a bank using token-based infrastructure. A stablecoin is a separate arrangement whose issuer and redemption terms determine the holder’s claim. Both can use a ledger, but the ledger alone does not tell you what kind of money you hold.
The practical question is simple: when you receive the asset, who owes you the balance, and under which terms?
Begin with the liability
In a conventional bank account, the deposit is a liability of the bank. Tokenizing its representation does not, by itself, turn that liability into a claim against a central bank or a direct holding of Treasury bills.
A reserve-backed stablecoin typically involves an issuer promising redemption under specified conditions. The issuer’s reserve assets support that promise, but holding the token is not necessarily the same as holding a bank deposit with the institution that holds the reserve cash.
The distinction is central to the BIS discussion of stablecoins and tokenized deposits. The BIS argues for deposit-based models that preserve settlement between banks in central bank money. That is the institution’s policy position, not proof that every tokenized product works identically.
What happens when the recipient banks elsewhere?
Imagine a customer of Bank A paying a customer of Bank B. In a deposit-based system, balances at the two banks and settlement between those banks have to be coordinated. A token representation can help automate parts of that process, but it does not remove the need to define settlement.
A transferable stablecoin can instead move between two wallets as the same issuer’s token. Neither wallet transfer necessarily moves money between the banks holding the issuer’s reserves. The reserve and redemption arrangements remain in the background.
This example is a simplified comparison. Real platforms can impose permissions, transfer restrictions or conversion steps. Ask what the recipient actually receives, rather than assuming that every onchain payment has the same structure.
Programmability does not settle the legal question
Software can release a payment when agreed conditions are met. That feature can be attached to different kinds of assets. It does not establish deposit protection, bankruptcy treatment or unrestricted redemption.
Those protections depend on the issuer, jurisdiction and product terms. A token being issued by a bank is not enough information to conclude that every holder receives the protections of an ordinary insured deposit. That question requires a product-specific legal analysis.
Three questions for a product announcement
Identify the liability: a bank deposit, a claim on a stablecoin issuer, or a share in another product. Then identify who may hold and transfer it. Finally, check how it becomes a spendable balance at the destination.
The last point is often where marketing descriptions become incomplete. “Instant” can describe the token leg while leaving account crediting or redemption for another stage. Our redemption guide follows that boundary.
Questions
Is a tokenized deposit a stablecoin?
The terms are sometimes used loosely, but they describe different possible claims. Read the issuer and product documents.
Does tokenization guarantee deposit insurance?
No. Protection must be established under the specific account, product and jurisdiction.
Can both types support automated payments?
Yes, programmability is a technical capability. It does not make the underlying claims or protections identical.
Sources
BIS speech on stablecoins and tokenized deposits, August 28, 2026; Circle Mint’s issuance and redemption model.
