Banks do not need to replace their core banking systems to tokenize deposits. The core banking system should continue to do what it already does. It should manage customer accounts, deposit balances, interest, statements, regulatory reporting, and general ledger entries.
The blockchain should not become the bank’s core system.
Instead, the bank should add a digital asset overlay network beside the core system. This should be a permissioned blockchain-based ledger that connects to the legacy CBS through real-time bridges. The core should continue to own the actual deposit record. The blockchain should record token movement. A reconciliation layer should keep both aligned.
This is the practical deposit tokenization model for banks. It keeps the deposit inside the regulated banking perimeter. It gives clients programmable, always-on settlement. It avoids the cost and risk of replacing the core.
Here is how this system works across four key layers:
1. The core banking Layer
The first layer is the lock and release layer.
This is where most banks should start. The bank should not move deposits out of the core. It should mark part of the client’s existing balance as unavailable for ordinary payments. That hold becomes the funding base for token issuance.
A corporate client may hold $10 million in a normal operating account. The client asks the bank to tokenize $2 million. The core banking system validates ownership, balance, account status, sanctions status, and product eligibility. It then places a hold for $2 million. The available balance falls. The ledger balance remains unchanged. The money is still a bank deposit. It remains a claim on the issuing bank.
The hold must be precise. It should carry a tokenization reference. It should identify the customer, account, currency, amount, product type, jurisdiction, wallet, timestamp, and token contract. It should also identify whether the token is transferable only within the bank, across a consortium network, or to a whitelisted external venue.
The CBS will still calculate interest, produce statements, and feed the general ledger. If the tokenized balance is interest-bearing, the interest logic should remain in the banking system.
This protects the bank from balance sheet confusion. Without a clear hold model, the bank risks counting the same money twice. Once as a normal available deposit. Once as a tokenized spendable balance. That is not tokenization. That is uncontrolled duplication.
Another important consideration is, that the token supply must never exceed locked funds. Minting should be impossible unless the hold is confirmed. Release should be impossible unless the token has been burned or immobilized.
There are two ways to design the ledger relationship.
The first is a non-native overlay. The core remains the source of truth. The blockchain mirrors locked balances and token transfers. This is the practical starting model for most banks.
The second is a native deposit token model. The blockchain becomes the primary record for the deposit token. Native deposit tokens can unlock more functionality because they are not limited by off-chain reconciliation. That is a valid long-term direction. It is also a larger legal, accounting, audit, and operational decision. Most banks should not begin there unless their regulators, auditors, and technology teams are ready.
J.P. Morgan’s work shows the direction of travel. The earlier JPM Coin System is described as a single-bank ledger for dollar balance transfers among participating JPMorgan clients. The newer JPMD concept extends bank deposit money onto public blockchain infrastructure for institutional clients while keeping the commercial bank money credit profile and deposit regulatory framework.
Citi shows the same pattern from a transaction banking angle. Citi Token Services for Cash uses tokenized interbranch deposits for real-time USD payments and 24/7 operations. The client experience remains inside existing Citi channels. Clients do not need to hold tokens directly or manage blockchain keys. The blockchain layer runs behind the banking interface.
2. The API integration layer
The second layer is the bridge.
This is not a simple API wrapper. It is a controlled transaction orchestration layer between the core banking system and the token ledger. It must translate banking events into token events. It must also translate token events back into banking events.
The mint flow should be deterministic.
The client submits a tokenization request. The bank validates eligibility. The core confirms funds. Compliance systems approve the account and wallet. The core places a hold. The event bridge receives the hold confirmation. The bridge signs a mint instruction. The smart contract mints the token. The token ledger sends a confirmation. The client channel shows the token balance.
The burn flow is the mirror image.
The client asks to redeem tokens. The token ledger checks the token balance. The compliance engine checks the wallet and destination account. The smart contract burns or immobilizes the token. The bridge receives finality proof. The core releases the hold. The available cash balance increases. The client receives confirmation.
Every step needs a shared transaction identifier. The same identifier should appear in the core, the token ledger, the API gateway, the event bus, the reconciliation system, and the audit log.
The bridge must be bi-directional. If the core rejects a hold, the token layer must not mint. If the token layer fails to mint, the core must either release the hold or mark it as pending. If a burn occurs but the core release fails, the client should not lose access to both forms of money. The amount should move into a controlled suspense account until the release is completed.
The bridge should also standardize the message payload. Messaging standards matter. Deutsche Bank report identifies integration with treasury systems, ERP systems, reconciliation workflows, reporting workflows, and messaging standards as structural constraints for broader digital money adoption. The same issue applies to tokenized deposits. Banks should design the bridge to support ISO 20022 messages, Kafka streams, and internal ledger posting formats from day one.
The API layer is also where the bank can protect the core. The core should not manage private keys. It should not validate blockchain consensus. It should not parse smart contract state. It should receive clean banking events. The bridge should handle blockchain complexity and expose only approved transaction states to the core.
This also makes migration easier. A bank can replace the blockchain network later. It can move from a private Besu network to a consortium ledger, connect to a public permissioned environment. It can join a shared settlement network as well. But the core integration should remain stable.
3. The digital asset overlay
The third layer is the token ledger.
This ledger should be separate from the core. It should be optimized for token movement. It should record token balances, wallet permissions, smart contract states, settlement conditions, freeze orders, and transaction history.
This is where the bank gets the new functionality.
A normal deposit can move through ACH, wire, RTP, internal transfer, card settlement, or book transfer. A tokenized deposit can also move through programmable logic. It can settle only when a security token is delivered. It can release only after an invoice is approved. It can sit in escrow until a corporate treasury rule is satisfied. It can move between branch entities after local cut-off times. It can support payment versus payment in foreign exchange. It can support delivery versus payment for tokenized bonds or funds.
Any smart contract that can mint, burn, freeze, or transfer bank money should be subject to change control, access control, and emergency pause rights.
The permission model is critical.
The token should move only between approved wallets. Wallets should be linked to KYC records. Institutions should be linked to legal entity identifiers. Beneficial ownership should remain in off-chain systems. The blockchain should hold only the minimum data needed for settlement and verification.
The overlay can take three broad forms.
a. The first is a single-bank ledger. This works for intrabank treasury, branch liquidity, corporate cash pooling, and closed client networks. JPM Coin is the clearest example.
b. The second is a shared ledger. This works for interbank clearing, correspondent banking modernization, and consortium settlement. Partior and newer bank-led shared ledger projects fit this model.
c. The third is a universal or public blockchain environment. This gives broader market reach/interoperability, but it demands stronger controls around identity, permissions, privacy, transaction monitoring, and bridge risk.
The overlay should use privacy controls at multiple levels. It should support private transactions, confidential data fields, selective disclosure, role-based access, zero-knowledge style proofs where appropriate, and audit views for authorized parties.
Because a permissioned network is not automatically private. Validators may still see transaction metadata. And a multinational will not use a tokenized deposit network if competitors, counterparties, or infrastructure operators can infer cash positions, supplier flows, or acquisition activity.
Read More on: How Banks Can Enable Selective Privacy & Compliance for Tokenized Deposit Programs?
4. End of day and intraday reconciliation
The fourth layer is the safety net.
End of day reconciliation is necessary. It is not sufficient. Tokenized deposits move continuously. A bank cannot wait until midnight to discover that tokens outstanding no longer match core holds.
The reconciliation model should run in two cycles.
The first cycle is intraday control. It compares token supply, wallet balances, core holds, pending mints, pending burns, and suspense balances throughout the day. The second cycle is formal end of day reconciliation. It produces accounting files, audit evidence, regulatory reports, and general ledger postings.
The bank should reconcile three records.
The first record is the core banking record. It shows the customer deposit, available balance, held balance, and tokenization hold.
The second record is the token ledger. It shows tokens minted, tokens burned, wallet balances, frozen amounts, and pending settlement states.
The third record is the general ledger. It shows deposit liabilities, control accounts, suspense accounts, fees, interbranch positions, and settlement receivables or payables.
The core equation is simple.
Tokens outstanding must equal valid tokenization holds plus any approved settlement-in-flight amount.
If tokens outstanding are higher than holds, minting must stop. If holds are higher than tokens outstanding, the bank must identify whether tokens were burned, failed, frozen, or not yet minted. If a burn succeeded but the core release failed, the amount should sit in a pending release suspense state. If the core hold succeeded but minting failed, the amount should sit in a pending mint state or be released.
This logic should be automated.
The blockchain can help. Each token event carries a timestamp, block number, transaction hash, wallet address, smart contract address, and event type. The bank can hash reconciliation files and store proofs. It can compare blockchain state against core state.
But the blockchain cannot solve accounting by itself. The general ledger still needs clean journal entries.
Exception handling is where the architecture needs to be tested. For example, a failed mint is manageable, but a duplicated mint is serious. A burn without release is a client incident. A release without burn is a loss. Any privacy leak is a reputational incident.
The bank should define states before launch. Normal. Pending mint. Pending burn. Chain final pending core. Core posted pending chain. Frozen. Suspense. Failed. Reversed. Manually corrected.
Each state needs an owner. Each owner needs an SLA. Each correction needs maker-checker approval. Each correction needs audit evidence. Each critical mismatch needs automatic escalation.
The reconciliation layer should also feed financial crime controls. Token movements should be mapped to customer profiles, wallet risk, sanctions screening, behavioral patterns, and transaction purpose. On-chain and off-chain data must come together. BCG and Anchorage state that banks should extend risk and compliance frameworks to integrate on-chain and off-chain data for AML, sanctions, transaction monitoring, market conduct surveillance, custody governance, third-party risk, cyber resilience, and incident response.
Interoperability increases reconciliation risk. A transaction may work on one ledger and fail at the boundary with another ledger.
Below are the potential risk vectors identified in BCG and Anchorage Digital report:
So reconciliation is part of the product. Clients will trust tokenized deposits only if the bank can prove that every token maps to a valid deposit claim, every redemption maps to a valid burn, and every exception is controlled.
5. How Zeeve can help
An enterprise infrastructure provider like Zeeve fits directly into the infrastructure and orchestration layer of this architecture. It delivers the automation frameworks required to deploy, secure, and monitor the digital asset overlay without disrupting the bank’s core logic.
1. Unbiased Consultation
Different institutional use cases demand different blockchain design characteristics. Hyperledger Besu offers an optimal framework for consortium networks that require enterprise-grade permissioning, strict access controls, and standard EVM compatibility. The Cosmos SDK is highly suited for banks that require absolute sovereignty over their blockchain design, allowing them to construct an application-specific chain with custom validator rules and native interoperability.
2. Compliant Infrastructure
Deploying financial infrastructure requires adherence to rigorous global security standards. Infrastructure providers address these requirements by maintaining continuous compliance with frameworks like ISO 27001, SOC 2 Type 2, and GDPR, alongside providing 24/7 security monitoring and automated vulnerability patching.
3. Expert Lead Migration
Many financial institutions possess early blockchain pilots built on legacy versions of Quorum or similar setups. These isolated setups typically lack production-grade observability, automated accounting bridges, and robust privacy controls. Zeeve can help banks in evaluating these legacy applications and migrating them onto modern, enterprise-ready networks.
The Zeeve Privacy Layer
Because simple blockchain networks can expose sensitive transaction metadata, specialized privacy layers are necessary to protect corporate activity. A modular enterprise privacy layer is offered by Zeeve that shields transaction values, smart contract execution steps, and participant identities from unauthorized network nodes. This provides corporate clients with the total business confidentiality they require while granting selective, read-only audit keys to internal bank compliance teams and external regulators.
Schedule a call with us to start your tokenization initiative.
