• Tokenized deposits represent commercial bank money on a distributed ledger, preserving the existing two-tier monetary system while adding programmability and atomic settlement.
• Two primary models exist: account-based and token-based. Each carries distinct tradeoffs for regulatory treatment, interoperability, and technical architecture.
• Tokenized deposits are not a replacement for core banking infrastructure. They connect to it via APIs and event-driven workflows, extending settlement and payment rails into programmable environments.
• The primary engineering challenge is not token mechanics. It is policy enforcement, key management, and compliance integration at production scale.
• Kaleido's enterprise blockchain platform gives financial institutions the infrastructure to issue and govern tokenized deposits without rebuilding their core systems.
Banks built today's payment rails for batch processing and overnight settlement. Correspondent banking networks, SWIFT messaging, and nostro/vostro account reconciliation all reflect an architecture designed before real-time everything became the baseline expectation. The gap between what those rails deliver and what treasury teams, corporate treasurers, and central banks now want is where tokenized deposits enter.
Kaleido's Enterprise Platformgives financial institutions the infrastructure to issue and govern tokenized deposits without rebuilding their core systems. The sections below cover what tokenized deposits are, how they compare to adjacent forms of money, the two dominant structural models, concrete use cases, and what a bank actually needs to build a production-grade system.
Tokenized deposits are on-chain representations of commercial bank deposits. The underlying liability remains on the issuing bank's balance sheet, subject to the same deposit insurance frameworks and prudential regulation that govern any current account balance. What changes is the settlement layer: instead of a debit instruction traveling through correspondent networks, the deposit itself becomes a programmable token that can settle atomically with other on-chain assets.
This distinction matters for how they sit within the broader money taxonomy:
Stablecoins like USDC and USDT are reserve-backed instruments issued by non-bank entities. They sit outside the regulated deposit guarantee system. CBDCs are central bank liabilities. Tokenized deposits occupy a specific and significant position: they are bank money, issued by a regulated institution, carrying the same credit quality and insurance coverage as a conventional deposit, but able to settle programmatically on a shared ledger.
The BIS Committee on Payments and Market Infrastructures, in its 2023 report on the future of the monetary system, explicitly identified tokenized deposits as a mechanism for preserving the two-tier monetary architecture while adding programmability. The report notes that tokenized deposits allow commercial banks to remain at the center of the payment system rather than ceding that role to stablecoin issuers or non-bank digital currency providers.
For a financial institution evaluating the landscape, that framing is the starting point. Tokenized deposits are not a crypto product. They are the bank's existing liability, replatformed for a programmable settlement environment. For a broader look at how tokenization applies across asset classes, see our guide to tokenization for enterprise architects.
Two structural models dominate how institutions are approaching tokenized deposit implementation. The choice between them determines regulatory treatment, interoperability constraints, and the technical architecture of the ledger.
Account-based models maintain the ledger as a record of balances associated with identified account holders. The token on-chain is a claim against a balance entry in the bank's core system. When a payment settles, the core banking ledger updates, and the on-chain token reflects that update. Identity and authorization are embedded in the account relationship, not in the token itself.
Token-based models represent value directly in the token. Possession or control of the private key gives the holder a claim to the underlying deposit. Settlement occurs when the token transfers between wallets, not when a core banking record changes. This model more closely resembles bearer instruments and requires the bank to think carefully about how deposit insurance attaches, how KYC obligations follow the token, and how reversibility is handled in the event of fraud or error.
The right choice depends on three specific conditions:
Choose account-based when:
• Your regulatory environment requires account-holder identity to attach to every balance and transaction at the core banking layer.
• You are operating within a closed consortium where counterparties are known and permissioned at the network level.
• You need full compatibility with existing core banking reconciliation and reporting infrastructure without a parallel ledger.
Choose token-based when:
• You need atomic Delivery versus Payment (DvP) settlement with securities or other tokenized assets where a counterparty's core banking system is not on the same network.
• You are building toward interoperability across multiple institutions or chains where a shared account ledger is not feasible.
• Your jurisdiction's regulatory framework has explicit provisions for bearer digital instruments, as some jurisdictions governed by eWpRV (Germany's electronic securities registry law) already do.
In our work deploying tokenized asset infrastructure at Tier 1 and Tier 2 financial institutions, we find that most institutions start with an account-based model for regulatory simplicity and evolve toward token-based settlement for specific use cases like cross-border DvP. The architecture needs to accommodate both, because a bank that locks into one model in year one will face a costly rebuild when the second use case arrives.
The case for tokenized deposits is clearest in contexts where today's payment rails create measurable friction. Three use cases consistently surface across the institutions we work with.
Cross-Border and Cross-Currency Settlement
Correspondent banking chains introduce latency and cost that are well documented. A SWIFT cross-border payment can take one to five business days and pass through two or three correspondent banks, each adding fees and creating reconciliation obligations. The BIS has reported that correspondent banking fees on some corridors exceed 6% of transaction value, with settlement times stretching beyond 24 hours for emerging market currencies.
Tokenized deposits on a shared permissioned ledger or connected public chain allow two banks to settle directly in central bank money equivalents without a correspondent intermediary. Payment netting, FX conversion, and settlement confirmation all happen within a single atomic transaction. For a corporate treasury moving $50 million in payroll across eight jurisdictions, the difference between T+3 and T+0 settlement is a material working capital question.
24/7 Liquidity and Repo Markets
Traditional repo markets operate within fixed settlement windows. Tokenized deposits enable intraday repo: a bank can post tokenized deposits as collateral, receive tokenized securities, and unwind the position within hours rather than days. This is not theoretical. The European Central Bank's trials of wholesale CBDC settlement and the Banque de France's DL3S system have demonstrated atomic settlement of repo-style transactions between central bank accounts and commercial bank instruments, with settlement confirmed in seconds rather than overnight.
Programmable Payments and Supply Chain Finance
When payment is conditional on an event, tokenized deposits enable the condition to be enforced at the smart contract layer without a payment instruction traveling through a separate rail. A supplier receives payment at the moment a logistics oracle confirms goods delivery. An escrow releases at contract execution. A coupon payment on a tokenized bond triggers against a verified rate index. Each of these patterns removes a manual confirmation step and the operational risk that comes with it.
At the technical layer, a tokenized deposit can be represented under several token standards, and the choice has downstream consequences for compliance and interoperability.
ERC-20 is the baseline fungible token standard. It works for simple transfer and settlement but carries no native compliance enforcement. A bank issuing deposits under ERC-20 needs to enforce KYC and transfer restrictions at the contract level through custom extensions, because the standard itself does not require identity checks on sender or receiver.
ERC-1400 and its sub-standards were designed for security tokens and carry partitioned balances, forced transfer capabilities for regulatory intervention, and document attachment. They are a closer fit for deposit instruments that need built-in operator control.
ERC-3643 (T-REX) combines on-chain identity registries with transfer rules. Every transfer validates the receiver's identity claim before the token moves. For a bank that needs to ensure deposits only settle to counterparties who have passed KYC and sanctions screening, this standard enforces that check at the protocol layer rather than relying on a manual off-chain gate.
In our deployments, the standard that fits depends on the counterparty set and the regulatory obligations. A bank-to-bank wholesale deposit network with a closed set of permissioned participants may use a simpler custom standard with role-based access control. A retail-adjacent or multi-institution network where identity needs to follow the token uses ERC-3643 or an equivalent identity-linked pattern.
Regardless of standard, the representation also needs to address how the on-chain balance reconciles with the core banking ledger. The deposit token is not the deposit itself; it is a representation. Every mint event, transfer, and burn needs a corresponding entry in the issuing bank's system of record. That reconciliation loop, driven by event-driven webhooks and idempotency keys to guarantee exactly-once processing, is where most of the integration engineering sits.
A tokenized deposit program is not a smart contract project. It is an integration project. The token mechanics take a fraction of the engineering effort. The rest goes to key management, policy enforcement, compliance integration, and connecting on-chain events back to core banking systems.
The production requirements break down across four areas:
Key Management and Custody
Every wallet holding a tokenized deposit balance needs a signing key. At institutional scale, that means hundreds or thousands of wallets, each managed under a governance framework that specifies who can authorize transactions, under what conditions, and with what approval chain. Hardware Security Modules (HSMs) are mandatory for keys holding material balances. In our Key Manager, we support a Remote Signing Module (RSM) that deploys co-located with the HSM and validates policy before any signing operation reaches the hardware. Supported HSM vendors include Thales Luna, Entrust, Fortanix, IBM OSO, and all major cloud HSM providers.
Policy Enforcement
Transfer restrictions for tokenized deposits go beyond simple allowlists. A policy engine needs to evaluate source and destination wallet identity, transaction value and velocity limits, asset type, sanctions screening results, and jurisdictional classification before a transaction signs. Kaleido's Policy Manager uses Open Policy Agent (OPA) with Rego policies, evaluated at the RSM before the transaction reaches the HSM. Policy changes themselves require approval before taking effect, which means the governance layer governing the policy is auditable.
Compliance Integration
AML screening cannot be an afterthought. A tokenized deposit that settles before sanctions screening completes creates regulatory exposure. The workflow engine needs to gate transaction signing on the result of a screening call to Chainalysis, TRM Labs, or Elliptic, with a configurable hold window if the result is inconclusive. This check needs to happen within the transaction lifecycle, not as a parallel process that might complete after settlement.
Core Banking Reconciliation
Every on-chain event must write back to the issuing bank's core system. Mints, transfers, and burns each produce a ledger entry. That event stream, delivered via Apache Kafka or webhook, feeds the bank's general ledger, regulatory reporting system, and treasury management platform. The integration is not optional and it is not simple. In our work with Tier 1 banks, reconciliation architecture consistently takes longer to design and test than the smart contract layer.
Kaleido's platform covers the infrastructure layer that sits between a bank's existing systems and the blockchain network. We do not replace core banking systems. We connect to them.
A tokenized deposit program built on Kaleido gets:
• Smart Contract Manager for deploying, versioning, and managing the deposit token contract lifecycle, with auto-generated typed REST APIs from any contract ABI.
• Key Manager with HSM integration and the RSM for pre-signing policy enforcement across hot, warm, cold, and air-gapped signing tiers.
• Policy Manager with OPA/Rego-based programmable rules evaluated before any transaction signs, supporting Maker/Checker, 4-Eye, multi-level sequential, and threshold/quorum approval models.
• Workflow Engine for end-to-end transaction lifecycle management, including native gas handling, transaction retry with idempotency guarantees, and configurable pre-trade and post-trade compliance checks. ISO 20022 messaging standards are natively supported.
• Built-in AML integration with Chainalysis, TRM Labs, and Elliptic, with Notabene for travel rule compliance.
• Event streaming via Kafka and webhooks for core banking reconciliation, with GraphQL and WebSocket subscriptions for operational monitoring.
The platform is certified SOC 2 Type 2 and ISO 27001:2022 (including ISO 27017 and ISO 27018 sub-standards). It deploys as fully managed SaaS, on-premise Kubernetes-native, or hybrid for institutions that need the RSM co-located with their HSM on-premise while Kaleido manages the platform layer.
Institutions in our network have used this infrastructure to move from pilot to production on tokenized asset programs without rebuilding their custody or settlement stack. The integration pattern is augmentation: existing systems continue to operate, and the blockchain layer adds programmability and atomic settlement on top.
What is a tokenized deposit?
A tokenized deposit is an on-chain representation of a commercial bank deposit. The underlying liability stays on the issuing bank's balance sheet, subject to the same deposit insurance and prudential regulation as a conventional deposit. What changes is the settlement mechanism: the deposit becomes a programmable token that can settle atomically with other on-chain assets. Kaleido's platform gives banks the infrastructure to issue and govern tokenized deposits without replacing their core systems.
How do tokenized deposits differ from stablecoins?
Stablecoins like USDC are issued by non-bank entities and backed by reserves held outside the regulated deposit system. Tokenized deposits are issued by licensed commercial banks, carry the issuing bank's credit standing, and fall within existing deposit insurance frameworks. Regulatory treatment, counterparty risk, and balance sheet treatment differ materially between the two instruments.
What is the difference between account-based and token-based tokenized deposits?
Account-based models maintain balances in the bank's core system, with the on-chain token reflecting that balance. Identity attaches to the account relationship. Token-based models embed value directly in the token, so possession of the signing key confers the claim. Account-based models are simpler to reconcile with existing core banking and regulatory reporting. Token-based models enable atomic DvP settlement across institutions where a shared account ledger is not feasible.
What token standard should a bank use for tokenized deposits?
The choice depends on the counterparty set and regulatory obligations. ERC-20 is the simplest fungible standard but requires custom compliance extensions. ERC-1400 adds partitioned balances and forced transfer capabilities suited to regulated instruments. ERC-3643 (T-REX) enforces on-chain identity verification at every transfer, ensuring deposits only reach KYC-verified counterparties. Kaleido supports all three plus custom smart contract patterns.
What are the main infrastructure requirements for a tokenized deposit program?
A production-grade program requires HSM-backed key management with pre-signing policy enforcement, a programmable compliance policy engine evaluated before transactions sign, AML screening integrated within the transaction lifecycle, and an event-driven reconciliation loop connecting on-chain events to the core banking ledger. The token contract itself is a small fraction of the engineering effort. The integration layer is where most of the work sits.
Does tokenized deposit infrastructure need to replace existing core banking systems?
No. Kaleido's approach positions tokenized deposits as an augmentation of existing infrastructure. Core banking systems, settlement rails, and compliance platforms continue to operate. Kaleido's Web3 Middleware connects to them via REST APIs and event-driven webhooks, adding on-chain programmability and atomic settlement without requiring institutions to rebuild or replace existing systems.
Tokenized deposits are not a distant prospect. The BIS, the ECB, the Monetary Authority of Singapore, and the Bank of England have all published frameworks or run pilots examining how commercial bank money can be replatformed for programmable settlement. The two-tier monetary system is not going away, but the rails it runs on are changing.
The institutions that move from pilot to production fastest are the ones that treat this as an integration problem from day one, not a token design problem. Get the key management, policy, compliance, and reconciliation architecture right before the token contract. That is where the audit trail lives, and that is what regulators will examine.
If you are scoping a tokenized deposit program and want to understand what infrastructure decisions look like at production scale, contact the Kaleido team to discuss deployment architecture for your context.
.png)
