Tokenized Deposits vs Stablecoins: What Banks and Fintechs Should Build in 2026

On a blockchain explorer, a tokenized deposit and a stablecoin look exactly the same. Same dollar. Same 24/7 transfer. Same few seconds to settle. But only one of them is covered by a deposit guarantee scheme if the issuer fails. Pick the wrong one for your clients and you will not find out in the pilot. You will find out when a regulator asks who owns the money, or when a payment stalls between two ledgers at 2 a.m. on a Sunday.

In the past twelve months the choice stopped being theoretical. J.P. Morgan put deposit tokens on a public blockchain. A consortium of European banks is launching a euro stablecoin. UK regulators set 2027 as the start of their stablecoin regime, and in Feedback Statement FS26/1 banks and asset managers asked them to move faster on both.

The short answer: a tokenized deposit is a bank deposit recorded on a blockchain. It stays a liability of a licensed bank, keeps deposit protection and can pay interest. A stablecoin is a token issued by a regulated issuer and backed one to one by reserve assets, redeemable at par. They differ in who owes you the money and what protects it.

This guide is written by people who build this. At Neti we designed the money model and financial core for Damisa, a UK cross-border payments company that now settles over $25 million a month across 70+ currencies. We built USDC payouts for MaxxChain without drivers ever touching a wallet. And we are an XRPL Partner contributing to the XRP Ledger core. Below is what we tell banks and fintechs in the first call: the differences that matter, which one to build, and where projects actually get stuck.

What is the difference between tokenized deposits and stablecoins?

Tokenized deposits (in UK usage, tokenised deposits) and stablecoins look identical on a blockchain explorer. Legally and operationally, they are different instruments. For a short definition, see our tokenized deposits glossary entry on NetiRails.

The European Banking Authority put the core point plainly: tokenising a deposit "does not per se alter the fundamental nature of the claim". A deposit on a blockchain is still a deposit. A stablecoin is a different product with a different risk profile, even when a bank stands behind it.

What did regulators decide in 2026, and what does it mean for you?

The rules now point in a clear direction: deposits for bank customers, regulated stablecoins for reach beyond them.

• UK banks: retail innovation should stay a deposit. A PRA Dear CEO letter of 18 May 2026 (summary) says tokenised deposits for retail customers must meet FSCS depositor protection rules. Firms that issued e-money or stablecoins and then become banks should move UK customers to deposits "as soon as practicable". What it means: if you are a bank serving retail clients, plan for tokenized deposits, not your own stablecoin.
• UK stablecoin issuers: rules are final, go-live is 2027. The FCA published its stablecoin issuance rules (PS26/10) on 30 June 2026, with backing assets held on statutory trust. The full crypto regime starts on 25 October 2027. For systemic sterling stablecoins, the Bank of England allows up to 70% of backing in short-term gilts, the rest in central bank deposits, with a temporary £40 billion issuance guardrail. What it means: a UK stablecoin launch has a fixed date to build towards.
• Wholesale markets want both, faster. In FS26/1, firms asked for faster progress on tokenised deposits and for stablecoins to be allowed as settlement assets. The authorities have since confirmed stablecoins can settle trades in the Digital Securities Sandbox, subject to conditions, and the Bank is considering stablecoins as eligible collateral. What it means: stablecoins are becoming usable inside regulated capital markets, not only in payments.
• EU: two separate regimes. Tokenized deposits sit under banking law. Stablecoins are e-money tokens under MiCA, issued by banks or e-money institutions. What it means: a European bank can do both, but through different legal wrappers and often different entities.

Which one should a bank or fintech build?

Choose by who you serve and where the money has to go. For most institutions the honest answer is both, connected.

• A bank serving its own corporate clients: tokenized deposits. Treasury moves, intra-group liquidity and 24/7 payments between clients of the same bank. You keep the balance sheet, interest and deposit protection. The limit is reach: a tokenized deposit works best inside your own network.
• A bank or fintech that needs reach beyond its own network: stablecoins. Cross-border payouts, B2B payments to counterparties at other banks, settlement on digital asset venues. You either issue through a regulated entity, join a consortium such as Qivalis, or accept third-party regulated stablecoins.
• A licensed payment or e-money institution: stablecoins. You cannot issue deposits. Your route is regulated stablecoins, issued or integrated.
• Everyone else: an orchestration layer. Clients will pay in bank transfers, tokenized deposits and several stablecoins. Your system has to route between them and settle each one correctly. That is the problem we solve in payment orchestration.

The Bank for International Settlements argues tokenized deposits are the sounder form of money. Its General Manager, Pablo Hernández de Cos, said at Jackson Hole in August 2026 that for stablecoins "there is no mechanism that enforces singleness". He has a point. But today stablecoins win on reach, and your clients will not wait for the debate to end.

Not sure which model fits your clients? Most teams we speak to are choosing between two or three options with different licences, partners and settlement paths. In one call we map your client types, money flows and regulatory position to a recommended model. Book a free consultation with our payments architects.

The hard part: settlement between the two

Issuing a token is the easy part. Settling it against other forms of money is where projects stall.

Singleness. One JPMD is not automatically one USDC, and one bank's tokenized deposit is not automatically another bank's. Conversion at par needs a settlement path, ideally in central bank money. The BIS puts it directly: "settlement in central bank money preserves singleness". In the UK, the Great British Tokenised Deposits pilot brought seven banks, including Barclays, HSBC and NatWest, onto shared rails, and the Bank of England's synchronisation service will link token ledgers to central bank settlement.

Chains. "Even the 'same' stablecoin on different chains is not interoperable without risky or costly workarounds," the BIS speech notes. Every chain you support adds a liquidity pool, a bridge risk and a reconciliation stream.

Core banking. The token ledger has to agree with the deposit ledger or the reserve account at all times. Burns must match withdrawals through a redemption engine, supply must match reserves through proof of reserve, and on-chain events must reach systems that speak ISO 20022.

How the main interbank settlement options compare:

We wrote about the integration layer in B2B stablecoin settlement middleware and why ledgers are becoming the core problem in financial ledgers for the tokenized economy.

What we learned connecting stablecoins to bank rails

The token type is rarely what breaks a project. Ownership and reconciliation are. Two published Neti projects show why.

Damisa: "Whose money is it right now?"

Damisa is a UK cross-border payments company moving money across banking and stablecoin rails. Its hardest question came before any code: "A payment stops halfway. The money has left one place and not arrived at the other. Whose is it right now?"

A single transfer passed through five balance positions: wallet, master wallet, liquidity provider, customer account, external bank. Bank rails settle on T+1. Blockchains settle on confirmation thresholds. Payments could arrive on the wrong chain. Without clear ownership at every hop, reconciliation was impossible.

We designed the money model before the code: what each object may own, and every transfer broken into hops with an owner, a ledger entry and an exception path. Stablecoins run through MPC wallets, and a self-hosted double-entry ledger ties them to virtual IBANs and FX providers. The entity model was built for client-money segregation before regulation required it. A six-person team shipped the MVP in four and a half months. Damisa now settles over $25 million a month across 70+ currencies. Read the Damisa case study.

MaxxChain: drivers waiting weeks to get paid

US truck drivers finished a shipment and then waited weeks for payment, while fuel, insurance and payroll kept running. Factoring helped, but still depended on manual document checks and approvals. We made USDC the payout rail and kept the stablecoin invisible: invoices and payouts run through smart contracts, while KYC and documents stay in a private backend. Drivers never touch a wallet. See the freight factoring case study.

In both cases the stablecoin worked from day one. The value came from designing who owns the money at every step.

Checklist before you launch tokenized deposits or stablecoins

1. Legal claim. Is the holder's claim on a bank or on an issuer, and what protects it?
2. Holders. Who can hold the token, and how are identity checks enforced at transfer level?
3. Redemption. Can every token be redeemed at par, how fast, and who funds it outside banking hours?
4. Reconciliation. Does token supply match the deposit ledger or reserves at all times, and who fixes a break?
5. Settlement path. How does your token settle against other banks' tokens, other stablecoins and fiat?
6. Timeline. Does your launch plan match the rules: UK systemic stablecoins from 2027, the FCA regime from 25 October 2027, MiCA already in force in the EU?

Most teams can answer two or three of these on day one. The rest are where launches slip by quarters. We go through all six with you in a free consultation, and you leave with clear answers, not a sales deck.

Why banks and fintechs choose Neti for digital money projects

Plenty of firms can deploy a token. Few can make it settle cleanly against bank rails, reconcile to the penny and stand up to a regulator's questions. That is the work we do.

• We design the money model before the code. As our stablecoin team puts it: "in DLT, the most expensive thing is not the bug, it is the wrong foundation." For Damisa we defined who owns the funds at every hop before writing a line of code. That is why fund ownership is provable at every stage.
• We speak both languages. Bank architects know SWIFT, IBANs, T+1 and ISO 20022. Blockchain teams know wallets, confirmations and chains. Your project needs both in the same room, and our team has built on both sides of that line.
• We work at protocol depth. As an XRPL Partner and contributor to the XRP Ledger core, we know how ledgers settle under the hood, not only how to call their APIs.
• We build compliance into the flow. Identity-bound transfers with ERC-3643, transaction monitoring hooks, client-money segregation and zero-knowledge selective disclosure when data must stay confidential but auditable.
• We get to production. 16+ years in software delivery, 120+ delivered projects, and a six-person team that took Damisa from MVP to production in four and a half months.
• You do not start from zero. NetiRails, our stablecoin payment orchestration platform, runs on your own infrastructure and connects custody, FX, compliance and reconciliation into one flow, with no lock-in to any single provider.

What we will not do: we will not recommend a blockchain when your existing bank rails already solve the problem, and we will not pretend to replace your licence. You stay accountable to your regulator. We design the controls that make that accountability easy to prove.

Your next step. Book a free consultation on stablecoin payments and settlement. In one conversation you get:

1. A recommendation: tokenized deposits, stablecoins or both, for your specific client types.
2. The settlement path your model needs, including how it reconciles with your core systems.
3. The top risks to design out before launch, mapped to UK and EU rules.

If you are still at the architecture stage, start with blockchain architecture design.