Architectures for Tokenized Deposits: Three Paths, One Core Question
- All, Insights
Tokenization isn’t about creating a new type of money. It’s about giving existing deposits the ability to move instantly, reduce reconciliation work, automate financial flows, and operate beyond traditional banking hours – all while staying within familiar regulatory frameworks.
The core question
Three architectural paths have emerged, each answering this question differently — and each leading to very different long-term outcomes.
1. The Bank-Specific Token Model
Where this model works well
This approach is a natural first step for banks because it keeps everything familiar. The deposit doesn’t change; the token simply upgrades how it moves. It’s useful for:- improving internal settlement flows,
- enabling real-time transfers within a bank’s perimeter,
- operating outside traditional banking hours,
- supporting treasury automation, cash pooling, and intraday liquidity.
It also fits cleanly into today’s regulation, since the deposit remains exactly what it has always been.
Where limitations appear
The challenge is scale — not technical, but business scale. A token from one bank works extremely well inside that bank. But once it needs to circulate across institutions, other banks must decide whether they want to accept another bank’s liability. This becomes a question of:- trust,
- counterparty risk,
- competition,
- and business incentives — not code.
Even with partner networks or bilateral agreements, the token’s reach is naturally limited by the perimeter of its issuing bank. This also affects long-term cost: launching a bank-specific token is relatively inexpensive, but every new external integration requires separate agreements, risk assessments, and technical onboarding. As a result, the model scales slowly and becomes increasingly expensive to maintain as the network grows.
Net effect
A strong upgrade for internal efficiency and extended operating hours, but it modernizes one bank, not the system.2. The Multi-Bank or Pooled Token Model
Why this model is attractive
It solves one of the biggest drawbacks of single-bank tokens: fragmentation. If enough banks join, the token becomes more uniform, easier to use, and more valuable as a shared settlement unit. In spirit, it resembles a bank-backed stablecoin: familiar regulatory grounding, wider usability, and stronger network effects.Where the real complexity lies
The difficulties here are not technical — they are structural. If many banks issue a shared token, fundamental questions appear:- Whose balance sheet stands behind the token at any moment?
- How is insolvency handled?
- How does deposit insurance apply when multiple issuers are involved?
- Who governs monetary behavior inside this shared system?
- How do regulators classify the instrument?
These questions require legal redesign, supervisory adjustments, and shared governance that many institutions are not yet ready to adopt. The operational overhead also grows quickly: shared governance, coordinated compliance, cross-bank audits, and joint decision-making increase the cost of running the system. Scalability depends not on technology but on political alignment, making expansion slow and expensive. The bottleneck is not engineering; it’s aligning incentives and regulatory viewpoints.
Net effect
A promising way to reduce fragmentation — but heavy, slow to coordinate, and at risk of drifting into “new currency” territory rather than simply modernizing deposits.3. The Interoperability-First Model (The DCM View)
The core idea
Unify the settlement infrastructure, not the money. A JPM deposit stays a JPM deposit. A regional bank deposit stays on that bank’s balance sheet. But transfers happen through a shared execution layer that enables:- real-time clearing between institutions,
- synchronized reconciliation,
- atomic settlement,
- interoperability with stablecoins,
- and programmable movement — without rewriting any core banking logic.
In DCM’s Twin-Core model, each bank keeps full control of its own accounting, risk, compliance, and insured deposit logic. A digital twin of the core simply allows those deposits to move in a digital-native way.
Why this solves the hard parts
This model avoids the limitations of the other two paths:- It doesn’t trap value inside single-bank silos.
- It doesn’t require shared balance sheets, pooled reserves, or complex governance.
- It doesn’t force regulators to redefine what a deposit is.
Banks remain independent — but interoperable. Because each bank keeps its own balance sheet and deposit logic intact, the cost of adoption and maintenance stays low. New institutions can join without triggering structural changes for existing participants, making scalability linear rather than exponential — a key advantage over pooled or single-bank designs.
Real-world evidence
This is not a theoretical model. Within the Transparent Network, several different core banking systems were integrated in just 3–5 weeks each. No core rewrites. No new liability structures. No changes to deposit classification or insurance. Full banking logic remained intact — while settlement and movement became real-time.Net effect
Clear regulatory alignment, strong scalability, and minimal operational disruption. Rather than redefining the banking system, this model extends it — making deposits programmable and interoperable across banks without altering the underlying monetary framework.Summary: Three Models, Three Futures
- Bank-specific tokens: great for internal modernization, but limited by the reach of a single institution.
- Pooled multi-bank tokens: solve fragmentation but introduce deep governance and monetary challenges.
- Interoperability-first models: keep deposits exactly where regulators want them — on bank balance sheets — while enabling real-time, cross-bank digital settlement.
In practice, tokenized deposits succeed not when they become uniform, but when the systems beneath them become interoperable.
Tokenized deposits succeed not by being identical, but by having the systems behind them work together.