CyphrQ
Menu

Tokenised Assets Explained: Deposits, Bonds and the Risks to Check

Tokenised assets and deposits explained: what they are, who is piloting them (BIS Agorá, J.P. Morgan JPMD) and the security, operational and legal risks.

By CyphrQ.ai

Written with AI assistance and human editorial review. Every figure linked to its source.

12 min read

A tokenised asset is a token on a digital ledger that stands for a claim on something that exists off the ledger, such as a bond, a fund share or a bank deposit. A tokenised deposit is ordinary bank money, issued by the bank itself as a token. The appeal is faster, programmable settlement. The risks sit in the code, the keys, the links between ledgers and the legal documents behind each token.

Plain language comes first, then a section for security and IT teams. This is not investment or legal advice, and it recommends no product. Every source was read on 27 October 2026.

What does tokenisation of real-world assets mean?

Every bond, fund share or bank balance already lives in a record somewhere: a registrar's book, a central securities depository or a bank's core banking system. Tokenisation puts a representation of that claim on a ledger that can run code.

The Bank for International Settlements (BIS), the bank that central banks use, defines tokenisation in its 2025 Annual Economic Report chapter on the next-generation monetary and financial system as "the process of recording claims on real or financial assets that exist on a traditional ledger onto a programmable platform".

"Real-world asset" (RWA) is the industry label for anything whose value comes from outside the blockchain. A token is only as sound as the link back to that asset: who holds it, who keeps the official record, and what happens when the two disagree.

Two features explain the interest:

  • Programmability. Rules can be written into the token as a smart contract, a program stored on the ledger that runs by itself when its conditions are met. The BIS Financial Stability Institute's summary of the FSB tokenisation report puts it this way: smart contracts "enable automated execution of transactions (programmability)".
  • One platform for asset and payment. With the security and the money on one ledger, both legs of a trade can settle together.

What is a tokenised deposit, and how is it different from a stablecoin?

A tokenised deposit, also called a deposit token, is a claim on a commercial bank recorded as a token. It is still a deposit: a liability of a regulated bank, sitting on that bank's balance sheet.

A stablecoin is issued by a stablecoin company that holds reserve assets to back it. The rules for those issuers are covered elsewhere on this site: the US regime is in the GENIUS Act stablecoin guide, and the EU regime in the MiCA explainer.

Tokenised deposit Stablecoin
Who issues it A bank A stablecoin issuer
What the holder has A claim on the bank A claim on the issuer, backed by its reserves
Typical access Often limited to the bank's own clients Depends on the design; many circulate on public chains
Main regulator Banking supervisors Stablecoin or crypto-asset rules, by country

The BIS has taken a view on which one should anchor the system. Its 2025 chapter tested stablecoins against "the three key tests of singleness, elasticity and integrity" and concluded that they "perform poorly". It favours tokenised commercial bank money, which it says "could build on the proven two-tier system", sitting alongside tokenised central bank reserves on what it calls a unified ledger: "a new type of financial market infrastructure" that "may or may not use distributed ledger technology (DLT)".

Who is tokenising assets and deposits today?

Central banks in the BIS-led Project Agorá, banks such as J.P. Morgan with its JPMD deposit token, and sovereign, supranational and agency bond issuers are the main examples in primary sources.

In practice: central banks and banks in Project Agorá. The BIS Innovation Hub's Project Agorá page (last updated 27 May 2026) lists the project as ongoing. It says Agorá "brings together eight central banks, including those of five major reserve currencies", with "over 40 leading financial institutions" convened by the Institute of International Finance. The BIS's June 2025 chapter gave seven central banks and 43 regulated financial institutions, so the group has changed since then. Agorá is a BIS-led project, not a payment service a business can sign up to.

In practice: J.P. Morgan's JPMD deposit token. On 24 June 2025, J.P. Morgan's blockchain unit Kinexys announced a proof of concept for JPMD, which it describes as "a permissioned USD deposit token for live institutional payments on Base". Base is an Ethereum layer 2 network, which the announcement calls "the Ethereum Layer 2 blockchain built within Coinbase". The bank says JPMD will be "eventually available exclusively to J.P. Morgan institutional clients", with deposits "backed by the bank's balance sheet" and "the ability to pay interest to holders". The page describes a pilot, carries no later status update and does not mention deposit insurance.

In practice: tokenised public-sector bonds. The BIS's June 2025 chapter says "more than 20 tokenised SSA bonds have been issued, amounting to over $4 billion across nine different currencies". SSA means sovereign, supranational and agency issuers. For scale, the chapter cites "nearly $80 trillion in outstanding amounts of government bonds". It gives no data date or named source for either figure, so treat both as the June 2025 picture.

That gap is the point the Financial Stability Board (FSB) makes in its October 2024 report on the financial stability implications of tokenisation. It finds that "the limited publicly available data on tokenisation suggest that its adoption is very low but appears to be growing", and concludes: "Owing to its small scale, tokenisation does not, therefore, currently pose a material risk to financial stability." The FSB says tokenisation could have financial stability implications in three cases:

  1. "if the tokenised part of the financial system scales up significantly"
  2. "if increased complexity and opacity of tokenisation projects lead to unpredictable outcomes in times of stress"
  3. "if identified vulnerabilities are not adequately addressed through oversight, regulation, supervision, and enforcement"

Why do banks and fintechs want tokenised money and assets?

The case rests on a few practical gains:

  • Settlement outside banking hours. A ledger that runs all day can settle when correspondent banks and batch systems are closed.
  • Fewer reconciliations. One shared record can replace several private ones that must be matched every night.
  • Programmable payments. A payment can release only when a condition is met, such as delivery of the security.

A token does not remove counterparty exposure. The questions in the cross-border payments partner-risk guide about who holds your money, and for how long, still apply when that money is a token.

What are the main risks of tokenised assets?

The FSB groups the vulnerabilities into five areas: "liquidity and maturity mismatch; leverage; asset price and quality; interconnectedness; and operational fragilities". The last one is where security and IT teams come in. The BIS FSI summary names "smart contract errors, private key mismanagement, lack of governance standards" and "the immutability of DLT transactions". Immutability means a mistaken or fraudulent transfer cannot simply be reversed on the ledger.

Risk What it looks like Who feels it first
Smart-contract A bug or a misused admin function mints, freezes or moves tokens wrongly Issuer, then every holder
Key management A stolen or lost signing key Whoever relied on that key
Oracle Wrong price or fund value fed onto the ledger Holders and lenders using the token as collateral
Interoperability A token or payment stuck between two ledgers, or between a ledger and a legacy system Operations teams and counterparties
Third-party A technology, node or custody provider fails Every client of the platform
Legal The token and the official register disagree, or the issuer fails Investors

On third parties, the FSI summary notes that "tokenisation often depends on external service providers" and that these "may affect platform functioning and token valuation". On interoperability, it flags the "lack of interoperability between DLT platforms and legacy systems".

Legal risk is a set of questions. The answers depend on the country and the product's documents:

  1. Does transferring the token transfer legal ownership, or only a record that points to it?
  2. Which record wins if the ledger and the official register disagree?
  3. What happens to token holders if the issuer, the platform or the custodian becomes insolvent?
  4. Which country's law governs the token, and which courts hear disputes?
  5. Can the issuer freeze, claw back or reissue tokens, and under what process?

What should an investor ask before holding a tokenised product?

  • What exactly does the token represent, and who is legally obliged to you?
  • Who keeps the official register, and is that firm regulated?
  • How do you redeem the token for the underlying asset or cash, and how long does it take?
  • Who holds the keys to your tokens: you, the platform or a custodian?
  • Is the product open to you under your country's rules, or only to professional investors?

Going deeper: for security and IT teams

Quotes come from the sources linked above; the control patterns are standard engineering practice, not requirements from those sources.

Map three records, not one. A tokenised asset usually has a legal register (transfer agent, central securities depository or the bank's core ledger), the on-chain token state, and an off-chain cash or reserve position. Most of the serious failure modes live in the gaps between them. Run a reconciliation that proves token supply equals the registered or deposited amount, on demand and on a schedule, and alert on any difference.

Smart-contract risk is mostly about privileged functions. Issuer contracts typically carry mint, burn, pause, freeze, allowlist and upgrade functions. An upgradeable contract (a proxy pointing at replaceable logic) means the code you audited may not be the code running next month. Controls to evidence: separate roles for mint, freeze and upgrade; multi-party approval for each; a time delay on upgrades so monitoring can react; an independent review of every new logic version; and a check that the deployed bytecode matches the reviewed source. Test with invariant checks (total supply never exceeds the registered amount) and fuzzing before each release.

Oracle risk is an input-validation problem. An oracle is the service that writes off-chain data, such as a fund's net asset value or a reference rate, onto the ledger. The FSI summary warns that "opaqueness in smart contracts and reliance on unregulated oracles could impair price discovery and asset valuation". Use more than one data source where you can, reject stale values, bound how far a value may move per update, and pause dependent functions when those checks fail. The oracle's own signing key is one more privileged key to protect.

Key management decides who can move value. Issuer admin keys, operator keys and client keys need different treatment. Custody tiers, multi-party signing and key ceremonies are in the crypto custody security guide. One point specific to tokenised assets is lifetime. A token for a 20- or 30-year bond may outlive the signature scheme protecting it. Ethereum and the networks built on it sign transactions with elliptic-curve signatures, which a large quantum computer could break. Plan crypto-agility now, as the Q-Day explainer sets out.

Settlement finality has a technical and a legal meaning. On many public chains finality is probabilistic or depends on a later step: a layer 2 network such as Base orders transactions itself and settles them to Ethereum afterwards. Your rulebook needs to state the exact moment a transfer is final, and that moment must match what the law and your contracts say. The BIS chapter argues that "settlement finality in central bank reserves" is how "the full benefits of tokenisation can be harnessed in a unified ledger", which is why tokenised deposits and reserves matter more than the asset token alone.

Interoperability adds trust domains. The FSI summary describes bridges as protocols "that allow the exchange of tokens on one DLT platform with tokens on another". Treat a bridge or cross-chain messaging service as a counterparty with its own keys and failure modes. In delivery-versus-payment across two ledgers, design for the case where one leg settles and the other does not, with a defined unwind.

Permissioning changes the threat model, it does not remove it. The FSI summary notes that "most projects use permissioned DLT platforms with centralised control". Centralised control means the operator's administrators and identity system become the target. Apply privileged access management and phishing-resistant authentication to node, allowlist and admin consoles.

Operational resilience. A ledger that runs around the clock needs people and runbooks that do too. Exercise a chain halt, a layer 2 sequencer outage, the loss of your RPC (node access) provider, an oracle failure and an emergency contract pause. EU financial entities should place node, oracle, custody and tokenisation-platform providers within their DORA programme; the DORA guide covers incident reporting and the register of information.

Detection and evidence. Index your own contracts' events and alert on role grants and revocations, upgrades, pauses, allowlist changes, and mints or burns above a threshold or without a matching off-chain instruction. Keep the instruction-to-transaction trail as audit evidence.

What to ask a tokenisation platform or issuer:

  1. Who holds each admin role, and how many approvals does a mint, freeze or upgrade need?
  2. Is the contract upgradeable, and what delay and review apply to an upgrade?
  3. Which oracles do you use, who signs their updates, and what happens when they fail?
  4. At what moment is a transfer final, and where is that written down?
  5. How often do you reconcile token supply to the register, and can you show the last result?
  6. Which third parties run nodes, custody and bridges for you, and what is your exit plan for each?

What should a bank or fintech check before launching a tokenised product?

  • Write down what each token legally represents and which record is authoritative.
  • List every privileged contract function and who controls it.
  • Put admin and oracle keys under multi-party control in hardware-backed storage.
  • Automate supply-to-register reconciliation and alert on any break.
  • Define settlement finality in your rulebook and check it against your contracts.
  • Add every tokenisation supplier to your third-party risk register.
  • Run one outage exercise per quarter for the ledger, the oracle and the node provider.
  • Record the cryptographic algorithms each token depends on, for post-quantum planning.

Key takeaways

  • Tokenisation records a claim on an off-ledger asset as a programmable token; the token is only as sound as its legal link to that asset.
  • A tokenised deposit is bank money issued as a token by a regulated bank; a stablecoin is a claim on a separate issuer.
  • Activity is real but small: the FSB said in October 2024 that tokenisation did not yet pose a material financial stability risk.
  • The operational risks to manage are smart contracts, keys, oracles, interoperability, finality and third parties.

Read more digital assets explainers.

Sources