Skip to main content
Marsh logo

Article

Tokenisation of deposits and securities: What traditional financial institutions need to know

Tokenisation is moving into live banking products, but the real challenge is risk. Learn how banks can build a framework for governance, custody, finality, and insurance.
Person's name and title

By Dhiren Harji , 

Digital Assets and Fintech Client Executive

03/11/2026 · 5 minute read

Tokenisation has moved from concept to commercial reality. Major global banks have progressed beyond proof-of-concept into live product across tokenised deposits, securities, and settlement infrastructure. Citi projects the tokenised asset market could reach $5.5 trillion by 2030.

For traditional financial institutions, particularly banks, the strategic case is clear. The risk picture is considerably less so.

The institutions best positioned to capture the value of tokenisation are not necessarily those with the most advanced technology. They are those that have established the risk framework to move with greater confidence — a risk framework that can withstand regulatory scrutiny, operational stress, and the questions that counterparties, auditors, and boards will inevitably ask. Getting that framework right is what separates strategies that scale from those that stall.

What the current regulatory landscape actually means

Regulators across major jurisdictions have adopted a principle of technology neutrality: the legal and regulatory character of a financial instrument does not change because it is represented on a distributed ledger. In the US, the Office of the Comptroller of the Currency (OCC) the Federal Deposit Insurance Corporation (FDIC), and the Federal Reserve have each confirmed that banks may engage in tokenisation activities. Regulatory proposals from the OCC and FDIC further indicate that tokenised deposits may retain their character as deposits — including potential eligibility for FDIC insurance — where the structure satisfies the statutory definition of a deposit, though implementing guidance continues to develop.

In the UK, prudential regulators have set out their expectation that qualifying tokenised deposits are treated as deposits for prudential purposes, with further detail on capital treatment, collateral eligibility, and custody yet to come. In the EU, Markets in Crypto-Assets Regulation (MiCAR) carves out tokenised bank liabilities, leaving them under existing banking law, while the distributed ledger technology (DLT) Pilot Regime provides the relevant framework for tokenised securities trading and settlement.

Technology neutrality does not necessarily mean simplicity.

Technology neutrality means that existing supervisory expectations apply — capital, liquidity, conduct, operational resilience, and anti-money laundering. Critically, it does not mean all tokenised structures are treated equally: the regulatory outcome follows the structure, and two instruments built differently can land in different regulatory categories, with different capital, conduct, and depositor protection consequences.

Across a number of major jurisdictions, regulators have indicated that the public or private nature of the underlying distributed ledger does not, of itself, alter the capital treatment of a tokenised traditional asset — what drives the regulatory treatment is the legal character of the claim, the structure of the instrument, and how settlement and intermediation are arranged. This position is not yet universal, and the Basel Committee's ongoing review of its cryptoasset framework means the treatment of assets on permissionless infrastructure in particular remains an active area of regulatory development.

The open question for most banks is not whether they are permitted to tokenise, but whether their risk and control infrastructure can demonstrate compliance with those obligations in a DLT environment. Regulators are watching closely, and early engagement with supervisory expectations, rather than waiting for intervention, will likely define which institutions lead.

Risk categories that warrant closer attention

The standard risk categories banks use to classify operational exposures — from execution and process failures to business disruption and fraud — all apply. But tokenisation also introduces failure modes that are categorically different from those in traditional banking, and which existing enterprise risk frameworks do not always address . These include:

Who controls protocol upgrades and the rules of the network? Can the bank exit or veto changes? Who controls the admission and removal of validators, and can transactions be censored or reordered? What is the legal consequence of a ledger rollback for settlement finality? For permissioned networks, governance of the infrastructure itself is a material risk that belongs in the design phase, not the audit phase.

It spans the full development lifecycle, from code defects and deployment errors through to upgrade governance and access controls. Unlike traditional software failures, errors in a live contract may execute automatically and at scale before they are detected. The question for banks is not only whether smart contracts can be governed, but whether the processes, testing standards, and oversight surrounding them are commensurate with the financial exposure.

Where private keys are held, by whom, under what operational controls, and with what recovery mechanisms, determine not only operational risk exposure but also where legal liability sits in the event of loss. The distinction between self-custody, third-party custody, and multi-party computation arrangements carries implications for segregation, insolvency treatment, and the bank's ability to evidence control at the point of a claim. Unlike most operational failures in traditional banking, there is no reconciliation, reversal, or recovery mechanism once control of a private key is lost.

Technical confirmation on a distributed ledger is not the same as legal settlement finality — the point at which a transfer becomes irrevocable and enforceable under applicable law. For banks, it is legal finality that matters, and in most jurisdictions, that question remains partially unresolved for tokenised instruments. The speed and automation that make tokenised settlement efficient also compress the window for fraud intervention, mistaken transfer recovery, and dispute resolution. These capabilities need to be designed in from the outset, not retrofitted.

Corporate actions, income distributions, and other lifecycle events require processes that are well-established in traditional securities infrastructure but remain unstandardized across tokenisation platforms. Where these are automated through smart contracts, errors can affect all holders simultaneously and at speed. Where they rely on manual processes or off-chain triggers, the accuracy and auditability of those inputs become risk considerations in their own right.

Traditional deposit beta assumptions, intraday liquidity buffers, and stress-outflow models were calibrated for systems with settlement windows. Tokenised deposits do not pause on weekends or overnight. The CFO and treasury implications of this require deliberate recalibration. Fragmentation across platforms, and questions of convertibility between tokenised and traditional forms, compound these pressures further.

Any instrument that relies on off-chain data inputs, including rate resets, corporate actions, pricing, and counterparty identity data, introduces a dependency that  risk frameworks may have not yet incorporated. More broadly, reliance on third-party infrastructure for data, connectivity, and computation creates concentration risks that warrant the same scrutiny as the on-chain components.

The ability to transact across different chains, platforms, and settlement systems cannot be assumed. Fragmentation of tokenisation infrastructure means assets issued or held on one platform may not be transferable or settleable on another. Liquidity positions that appear adequate within a single platform may prove illiquid at the point of cross-platform settlement. For banks operating across multiple counterparties and jurisdictions, these are not isolated risks — they interact with custody, finality, and counterparty exposure in ways that require careful assessment rather than assumption. 

Identifying these risks is the starting point. The more consequential questions are at what stage of planning and design they are addressed, and by whom.

Risk transfer considerations

Underwriters assessing tokenisation activities do not simply ask whether controls exist. They assess design choices and their reasoning, including the custody architecture, the governance model, and the operating model for key management. These decisions determine where legal liability sits and form the evidence base that underwriters rely on when assessing exposure and coverage. Institutions that build without risk considerations in mind can arrive at placement with structural coverage gaps.

The relevant coverage lines each respond differently to tokenisation loss scenarios, and the intersections between them are complex. Whether a smart contract failure is a crime loss, a professional liability loss, or a cyber loss is not a theoretical question. It determines the relevant policy and directly shapes limit purchasing decisions and the way coverage should be structured — enabling risk transfer to complement broader risk management and supporting optimal capital deployment. The answer varies by wording, by structure, and by what the business can evidence at the time of a claim.

Insurance market treatment of tokenisation is not yet uniform. Across the market, tokenisation as an operational efficiency tool within regulated financial institutions is not always assessed separately from crypto asset management — a distinct activity with a different risk profile. For traditional financial institutions, inconsistent treatment by underwriters can result in coverage and capacity limitations and pricing that may not be reflective of the risk. Part of the advisory value in this space is presenting tokenisation activities to underwriters clearly and accurately — distinguished from other activities that carry a different risk profile.

Institutions that embed risk management from the outset are likely to access broader capacity at better terms. Those that treat it as a secondary consideration will likely find that the insurance market's assessment of them reflects that.

What this means in practice

Tokenisation strategies that scale successfully share a common characteristic: risk management is treated as a foundational input, not a review conducted after the product is built.

The sequence matters. Custody model, smart contract governance, and operating model decisions all carry risk and insurance consequences. So does the stage at which those decisions are addressed.

Getting the sequence right and understanding underwriters’ likely focal points from the outset requires specialist risk advisory capabilities from professionals who sit at the intersection of financial institution risk, digital asset risk, and the insurance market, and have the experience to understand what currently gets written, what gets declined, and why

Marsh works with financial institutions at every stage of their tokenisation journey, bringing a holistic, risk-first view that spans initial risk framework design and regulatory navigation through to insurance market navigation and risk transfer strategy. 

To explore how we can support your strategy, contact your Marsh Financial Institutions relationship team or complete the contact us form below.