← Glossary

Devancore Post-Trade Glossary

Stablecoin Hierarchy of Money

A hierarchy for comparing central bank money, tokenized deposits, money market fund shares, fiat-backed stablecoins, and crypto-backed stablecoins as settlement assets.

Definition

The stablecoin hierarchy of money is a framework for ranking settlement assets by the quality of the liability behind them.

Money is not one thing. A central bank reserve, a commercial bank deposit, a tokenized deposit, a money market fund share, a fiat-backed stablecoin, and a crypto-backed stablecoin may all be described as "cash-like" in casual language. They are not the same operating asset.

The difference matters because settlement is not only payment movement. Settlement is the point where obligations become books, cash, positions, collateral, exposure, regulatory records, and audit evidence. If the asset used to settle the obligation has issuer risk, redemption risk, liquidity risk, or uncertain legal finality, that risk moves directly into the post-trade record.

Settlement asset hierarchy

Rank digital and traditional money instruments by liability base and settlement risk.

Tier Instrument Liability base Settlement risk
Tier 1 Central bank money, reserves, wholesale CBDC Central bank liability Lowest private credit risk; strongest settlement finality where legally recognized
Tier 2 Commercial bank deposits and tokenized deposits Commercial bank liability Bank credit, liquidity, operating, and legal-account risk
Tier 3 Fiat-backed stablecoins Private issuer liability backed by reserves Reserve, redemption, custodian, run, depeg, and insolvency risk
Tier 4 Crypto-backed or algorithmic stablecoins Collateral pool, protocol mechanism, or market incentive High collateral, oracle, liquidation, governance, and peg risk

Central bank money sits at the top of the hierarchy because it is a liability of the central bank. In large-value payment systems, reserves and RTGS balances are treated as the strongest settlement base because they do not introduce private issuer credit risk. Wholesale CBDC proposals and central-bank-money trigger models are digital extensions of the same institutional logic: keep systemic settlement anchored to the apex asset.

Tokenized deposits sit below central bank money. They preserve the commercial bank deposit model but represent the deposit on a digital ledger or programmable settlement network. This can improve speed, operating hours, and interoperability, but it does not turn commercial bank money into central bank money. The holder still depends on the bank, account terms, applicable deposit law, liquidity management, and the bank's operating controls.

Fiat-backed stablecoins sit below bank deposits in the hierarchy unless their legal structure, reserves, redemption rights, supervision, and finality regime make them equivalent for a specific use case. Many fiat-backed stablecoins are closer to narrow payment instruments or money market fund-like reserve structures than to deposits. They may be useful for 24/7 payment legs and digital asset settlement, but institutional firms still need to understand who owes the money, where reserves sit, when redemption is available, and what happens under issuer, custodian, or market stress.

Tokenized deposits vs fiat-backed stablecoins

Both can support digital settlement, but the legal claim and control model differ.

Question Tokenized deposit Fiat-backed stablecoin
Who is the obligor? A regulated bank or deposit-taking institution A stablecoin issuer, trust, payment company, or other private structure
What does the holder own? A bank deposit claim, subject to account terms and law A redemption or token claim defined by issuer terms and reserve structure
How does it fit banking? Preserves commercial bank money, lending, liquidity, and account infrastructure May sit outside deposit rails and rely on segregated reserves
Main control question Can the bank liability be represented, transferred, and reconciled correctly on ledger? Can reserves, redemption, custody, and issuer controls support par settlement?
Institutional use case Bank-led tokenized cash, intraday liquidity, DvP settlement, treasury operations 24/7 payment legs, digital asset settlement, cross-platform liquidity, non-bank settlement flows

Crypto-backed and algorithmic stablecoins sit lower because the settlement asset depends on collateral value, oracle behavior, liquidation mechanics, governance, or market incentives. They may function inside crypto-native environments, but for regulated post-trade infrastructure they create risk that must be treated as collateral and protocol exposure, not as risk-free money.

How it works

The hierarchy works by separating the name of the unit from the quality of the claim. A token may say USD, but the operating question is: USD claim against whom, backed by what, redeemable when, final under which law, and recordable in which books?

The first control is issuer classification. Central bank money is a sovereign monetary liability. Commercial bank money is a bank liability. Tokenized deposits are a digital form of that bank liability. Fiat-backed stablecoins are private issuer claims supported by reserves. Tokenized money market fund shares are fund interests. Crypto-backed stablecoins are collateralized protocol instruments. These categories cannot be treated as identical simply because they reference the same currency.

The second control is finality mapping. A transaction can be technically final on a ledger while still requiring legal, accounting, cash, and regulatory treatment outside that ledger. This is the same issue addressed in settlement finality and DLT books-and-records design: the system must know when a movement is operationally accepted, legally final, economically settled, and ready for reporting.

The third control is redemption and liquidity. A stablecoin used for payment is only as strong as the issuer's ability and obligation to redeem. A tokenized fund share may have high-quality assets underneath it, but it may still settle on fund terms rather than cash terms. A tokenized deposit may move instantly on a ledger, but liquidity still depends on the bank and payment network rules.

Settlement asset risk controls

Each asset type needs explicit issuer, finality, liquidity, custody, and operating evidence.

Risk Where it appears Control requirement
Credit risk Commercial bank money, tokenized deposits, private issuer stablecoins Identify the obligor, legal claim, exposure limit, and fallback settlement rail
Liquidity risk Reserve-backed stablecoins, tokenized MMFs, large redemptions Track redemption windows, eligible reserves, liquidity buffers, and stress scenarios
Finality risk Any rail where legal finality and ledger finality diverge Map technical finality to legal finality, books, cash posting, and reversal controls
Custody risk Stablecoin reserve assets, token custody, collateral wallets Evidence reserve location, wallet authority, segregation, and access controls
Operational risk 24/7 settlement, smart contracts, bridges, or oracle-driven workflows Use maker-checker controls, monitoring, circuit breakers, and audit trails

The fourth control is operational evidence. Institutions need proof of asset type, issuer, wallet or account authority, reserve or collateral basis, sanctions screening, exception handling, and reconciliation. Smart contracts can automate part of the movement, but they do not remove the need for controls. They make the control design more important because errors can become final faster.

This is why the hierarchy connects directly to smart contract risk in financial markets and the Common Domain Model for tokenized securities. A workflow can be machine-readable, atomic, and automated, but it still needs a dependable settlement asset. Standardized lifecycle events do not eliminate money risk. They make money risk easier to identify, encode, monitor, and evidence.

In Devancore™

In Devancore, settlement asset type is treated as an operating attribute of the event, not as a generic cash label.

A post-trade record should distinguish central bank money, commercial bank deposits, tokenized deposits, fiat-backed stablecoins, tokenized money market fund shares, and crypto-backed tokens. Each has different implications for finality, reconciliation, exposure, reporting, liquidity, and controls.

This matters for dual-rail settlement architecture. A tokenized security may move on a digital rail while the cash leg settles through a bank, a stablecoin, a tokenized deposit, a tokenized money market fund share, or a central-bank-money mechanism. The platform cannot assume that every digital cash leg has the same risk profile.

Devancore's operating posture is to preserve a single record across both traditional and digital settlement environments. That means the event log, position view, cash view, control framework, and reporting base need to capture the settlement asset hierarchy explicitly.

The goal is not to declare one asset type universally correct. The goal is to prevent category mistakes. Central bank money, bank money, fund shares, stablecoins, and protocol tokens can all have roles. They should not be collapsed into one undifferentiated "digital cash" field.