Tokenized deposits have passed the proof-of-concept phase. Banks now know they can put deposits on a blockchain. We now have enough precedents for tokenized deposits to be used as a valid payment rail globally. But the critical challenge is selecting the production infrastructure.

The decision is not easy because tokenized deposits will still be the banks’ balance-sheet liabilities and must retain all existing legal, regulatory, and risk characteristics. Plus, add new capabilities like real-time settlement and programmable automation.

A pilot can be launched on almost any ledger. But a production-grade system requires a long-term view. A dedicated enterprise deployment partner, like Zeeve, can deliver banking-grade blockchains, absolute data privacy, and global interoperability without leaving banks’ legacy systems. 

This article helps banks make that decision more easily. It will answer all their queries, break down infrastructure decisions into 5 layers, and give architecture diagrams for tokenized deposit programs undertaken by banks. 

What are tokenized deposits? 

A tokenized deposit is our standard, commercial bank deposit represented on a bank’s blockchain. Economically and legally, it is identical to off-chain deposits and maintains a 1:1 par exchange rate with fiat currency. 

Source: Federal Register

Hence, they are a direct claim on the balance sheet of the issuing commercial bank and fall under standard deposit insurance schemes such as the FDIC in the United States. Unlike stablecoins, they support the bank’s fractional-reserve policy and credit creation.

The benefit is that by wrapping these liabilities in a blockchain interface, banks can make commercial money programmable and highly mobile. It becomes capable of settling peer-to-peer 24/7/365 (atomic settlement) without relying on centralized, batch-processed clearinghouses like the Federal Reserve’s ACH, which pauses on weekends and holidays. 

For a deeper dive into who it benefits, the use cases where tokenized deposits bring more value, and the regulatory readiness worldwide, visit our detailed article:

Why Banks Need to Tokenize Deposits? Who Benefits? 

What does a tokenized deposit infrastructure actually mean?

In a traditional bank, our balance sits inside a private SQL database or mainframe system called a Core Banking Platform. This system cannot naturally read, see, or interact with a blockchain. The tokenized deposit infrastructure is the multi-layered technology stack built to bridge this specific gap, along with addressing the key concerns that arise because of blockchain introduction. For example, privacy & compliance, custody, interoperability, etc.

Tokenized deposit infrastructure refers to the blockchain, middleware, compliance, privacy, integration, and operations stack required to issue, manage, and govern tokenized commercial bank deposits.

So if a bank asks what are the main infrastructure requirements for a tokenized deposit program, the answer  is not limited to token issuance, custody, or settlement alone. It includes the network architecture, smart contract logic, participant controls, privacy mechanisms, compliance workflows, interoperability rails, integration with core banking systems, and the operational layer required to run the system reliably.

We can divide the entire tokenized deposit infrastructure into 2 primary building blocks and 5 subcategories

Architectural Archetype:

1. Network Infrastructure (Private Chains/permissioned, Public chains, Hybrid Networks
2. Ledger Model / Data Structure
3. Smart Contract & Token Architecture

Other Infrastructure Decisions:

4. Privacy & Compliance: Selective Disclosure, ZK 
5. Integration Layer: with legacy core banking system through APIs + other enterprise connectivity (like Oracle, Digital asset custody stack like MPC, HSM, Account Abstraction, etc.), and interoperability with other banks and financial networks using Hyperlane-like integrations. 

Now lets look into each of them one by one. 

Network infrastructure:

Network infrastructure is the most important decision. Banks can use private or permissioned chains, public chains with institutional controls, or other hybrid models that combine public verifiability with private execution. 

Each model has a different tradeoff between control, interoperability, cost, and ecosystem access. 

1. Complete Public chains

Public networks offer open infrastructure, broad developer ecosystems, liquidity, and composability. They are attractive when the bank wants to support multi-party settlement, tokenized securities, institutional DeFi, or open network connectivity.

The challenge here is control. Tokenized deposits cannot behave like permissionless bearer assets by default. Banks need allowlists, identity checks, sanctions screening, transaction limits, and issuer controls. 

MAS Project Guardian showed that even when deposit tokens are used on a public blockchain, banks can restrict interactions to known addresses and require verifiable credentials. 

Source: Onyx by J.P. Morgan Analysis

So, Public chains can work when controls are built at the token, application, wallet, and RPC layers. They are best suited when interoperability and ecosystem reach matter more than full infrastructure ownership. But banks must plan for transaction fee volatility, public metadata exposure, chain governance risk, and finality assumptions.

A public-chain strategy should never start with the chain alone. It should start with the permissioning model.

2. Private and permissioned chains

Private and permissioned chains give banks more control over participants, validators, access rules, and data visibility. These networks are easier to align with internal risk, audit, and compliance requirements. They also give more predictable performance and cost.

This model works well for internal treasury settlement, closed-loop corporate payments, interbank consortium networks, and wholesale settlement among known institutions. Single-bank ledgers can support intra-bank transfers, and shared ledgers allow multiple institutions to interact on common rules and assets.

The tradeoff is network reach. A private network may solve the bank’s internal settlement problem. It may not solve cross-bank interoperability unless other banks join or external bridges are built.

Private infrastructure is the safest starting point for many banks. It is not always the best end state. The end state depends on how much external settlement the bank expects.

3. Hybrid networks / Custom-built public-permissioned chains

Hybrid networks try to combine institutional control with broader connectivity. 

So a hybrid chain could be 

• Public chains with permissioned applications, 
• Private execution with public anchoring, 
• Privacy nodes connected to public liquidity, or 
• Institutional networks with selective disclosure.

J.P. Morgan’s JPMD/JPM Coin rollout on Base is a useful example. The asset runs on a public Ethereum Layer 2, but is available to institutional clients and designed for regulated, permissioned use.

Source: JP Morgan

Let’s take an example of privacy-first public chains like Midnight or Hyli, which combine public-chain verifiability with confidentiality. They use zero-knowledge proofs, selective disclosure, or proof-based settlement to let institutions prove validity without revealing underlying data like balances, counterparties, business logic, or transaction metadata. 

Most of the examples in the market point in this direction. 

Another example could be public chains with private institutional nodes like the Canton network or Rayls. These architectures give institutions private execution, private ledgers, or controlled nodes, but also connect them to a broader shared settlement or interoperability layer.

For tokenized deposits, hybrid infrastructure is useful when banks need privacy, auditability, and institutional governance, but also want future connectivity to public ecosystems. This can be a strong fit for interbank settlement, tokenized securities settlement, cross-border liquidity, and regulated digital cash networks.

If you want to understand how any of these models works or which could be best suited for your bank, schedule a no-cost discussion call with Zeeve experts. 

Ledger model and data structure:

They are primarily two types.  ‘

1. Account-based ledgers

Account-based ledgers are best for regulatory simplicity. Identity is attached to balances at the ledger or account layer. This maps well to existing banking records, account ownership, customer due diligence, reconciliation, reporting, and internal controls.

This model is useful when the bank needs every balance to map cleanly to a customer, corporate account, omnibus structure, or internal ledger. It is also useful for closed networks where participants are known and permissioned.

2. Token-based or UTXO-style ledgers

Token-based ledgers represent value more directly in the token. In UTXO-like models, settlement can be structured around discrete spendable units. These models can be better for atomic settlement, DvP, PvP, and complex multi-party workflows where counterparties do not share the same account architecture.

Blockchain deposits can also be native or non-native. Native records are blockchain records that act as the primary source of truth. Non-native records are on-chain mirrors of off-chain records. Native deposit tokens are promising because they are not limited by off-chain reconciliation processes and can use new blockchain functionality.

A bank architecture may need both patterns. They can start with account-based issuance, where regulatory clarity matters most. Add token-based settlement where DvP, PvP, or cross-network atomicity matters.

Smart Contract & Token Architectures:

The smart contract layer defines how tokenized deposits behave. They are not simple fungible token deployments.

For tokenized deposits, smart contracts should support pre-settlement controls. These may include KYC status, sanctions results, wallet eligibility, transaction value, velocity limits, user role, geography, product type, and issuer approval.

They must also support operational controls. These include maker-checker approvals, emergency pause, audited upgrades, key rotation, admin role separation, contract monitoring, and formal review.

What token standard should a bank use?

The following token standards can be used but one thing we need to keep in mind is, there is no universal token standard for tokenized deposits. The right standard depends on the use case type. 

ERC-20

Good for simple fungible transfers, but compliance must be added through custom controls.

ERC-1400

More suitable for regulated financial instruments because it supports partitions, operator controls, and forced transfers.

ERC-3643 / T-REX

Useful where identity-linked transfer restrictions are required.

Custom permissioned token contracts

Often appropriate for bank-led or consortium-led networks where the participant set is closed, and role-based controls are more important than public composability.

Other Infrastructure Decisions

Privacy and compliance Infrastructure

Privacy and data localization are one of the biggest corporate adoption challenges and one of the hardest parts of tokenized deposit infrastructure. Because, 

• Banks cannot expose sensitive metadata of counterparties, volumes, pricing, and supply chain information. Jurisdictions may restrict also where data can reside and who can see it.
• At the same time, regulators, auditors, compliance teams, and internal control teams need visibility.

That creates a design dilemma.

The infrastructure must keep transaction data confidential from unauthorized parties and also make the right data available to the right supervisory and control functions.

For tokenized deposits, privacy must operate across multiple surfaces.

It has to cover 

• asset transfers. 
• balances. 
• smart contract execution.
• identity checks. 
• API access. 
• RPC endpoints. 
• observability logs and dashboards. 
• disclosure workflows.

This is the right framing because institutional privacy cannot be solved only at the token level.

Zeeve’s Privacy Layer is a perfect solution to institutional privacy and compliance challenges. It treats privacy as modular middleware and can be integrated with any blockchain type below your application layer. 

Learn More: how confidential transactions (ZK), role based access, selective disclosure and private smart contracts work in Zeeve Privacy Layer.

These features of Zeeve privacy layer are useful here to keep sensitive data private without losing on-chain utility of tokenized deposits. 

Because a private chain is not automatically a private workflow, privacy must be designed across the full system. Because even if your network is private, the validators can still see the transactions and participants. 

Integration layer

Core banking integration infrastructure

Tokenized deposit infrastructure does not replace core banking. It integrates with it.

The core banking system remains the system of record for deposit liabilities, customer accounts, interest treatment, regulatory reporting, treasury management, and balance sheet controls. The blockchain layer becomes the programmable settlement environment.

This needs API-based integration with legacy systems like, FIS, Finastra, Temenos, Mambu, in-house cores, treasury platforms, and compliance systems. REST APIs, webhooks, message queues, and event streams can connect on-chain actions with off-chain banking records.

Every mint, transfer, and burn needs a corresponding entry in the bank’s system of record. This reconciliation architecture can take longer to design and test than the smart contract layer.

This is why banks should design reconciliation before choosing token standards.

Integration with external enterprise tools

Tokenized deposits also need enterprise connectivity beyond core banking.

• For example, institutional custody is critical. Banks need MPC, HSM, remote signing, key rotation, quorum approval, transaction policies, and recovery workflows. 
• For corporate users, account abstraction can improve wallet usability, delegated approvals, role-based signing, and pre-programmed payments.
• The policy engine should do KYC/AML screening before any transaction settlement. The rules may include sender identity, receiver identity, balance, value threshold, velocity, sanctions result, jurisdiction, instrument type, business purpose, and approval status.
• Oracles can be important when payment depends on external data like, any rates or prices, delivery confirmation, securities settlement status, collateral values, or any corporate workflow events.
• Observability also matters. Banks need dashboards, logs, alerts, SLA monitoring, incident runbooks, transaction tracing, audit exports, and compliance evidence.

And all these together builds the regulated financial infrastructure for tokenized deposits.

Interoperability with other banks and financial networks

Tokenized deposits create the most value when they can move across counterparties.

A single-bank token can improve internal treasury movement. A shared ledger can improve settlement within a consortium. A broader interoperable network can support cross-bank payments, tokenized securities settlement, cross-border treasury, collateral mobility, and liquidity management.

Interoperability will be needed between traditional finance systems and blockchains, across different chains, and with other assets on a given blockchain. But multiple bridging and wrapping can introduce operational and technical risk.

This is where Hyperlane-like integration concepts become relevant. Hyperlane is an interoperability framework that supports asset bridging and message passing across many chains and virtual machines and Zeeve enable this for its enterprise customers.

A bridge that moves value but breaks compliance is not bank-grade interoperability. A messaging layer that carries instructions without legal finality is not enough either.

KYC, AML, privacy and control has to be there in every layer. 

Banks should ask early whether every new counterparty requires a custom integration or whether the platform supports standardized connectivity from the start.

A decision table: What Questions Banks Should Ask a Tokenized Deposit Blockchain Infrastructure Provider?

So when banks evaluate tokenized deposit infrastructure, they are really evaluating a full-stack infrastructure requirements:

How Zeeve helps banks deploy tokenized deposit infrastructure

Zeeve helps banks design, deploy, and operate tokenized deposit settlement infrastructure across private, permissioned, public-permissioned, and hybrid architectures.

The value starts with infrastructure advisory. Banks do not need to choose a stack in isolation. They need to match architecture with use case, privacy needs, regulatory obligations, transaction volume, finality needs, and interoperability goals.

Zeeve can support banks across the full stack.

• Multi-stack advisory across permissioned, public-permissioned, rollup, appchain, and hybrid architectures
• Managed blockchain network deployment and operations
• Zeeve Privacy Layer
• API and event integration with core banking, treasury, custody, and compliance systems
• Interoperability support with other banks, financial networks, and cross-chain messaging layers
• 24 by 7 monitoring, upgrades, observability, SLAs, and operational support

The goal is to help banks launch tokenized deposits without forcing them into a single chain, a single architecture, or a disruptive replacement of core systems. If your bank is looking to launch a tokenized deposit program, connect with Zeeve to discuss how we can help!