Stablecoins still get most of the attention, but the bigger institutional shift is happening inside banks. McKinsey estimates that tokenized deposit infrastructure already facilitates more than $4 trillion in annual transfers, far more than stablecoin payments.
But scale for banks will not come only from speed and programmability. Banks need to solve a harder question first.
How can they enable privacy and compliance in tokenized deposits at the same time?
Because a tokenized deposit is different from most crypto-native assets. It is part of a regulated customer relationship. At the same time, banks cannot make tokenized deposits completely opaque. Regulators and auditors still need visibility. AML checks must run. KYC rules must apply. Suspicious activity must be reviewable.
So the real challenge is not whether tokenized deposits should be private or transparent. They need both.
In this article, we will discuss how this can be done? What regulations apply to tokenized deposits? What all options bank has to design their privacy and compliance infrastructure and how Zeeve can help.
What Privacy and Compliance Rules Apply to Tokenized Deposits?
Tokenized deposits will generally follow the same core rules as normal bank deposits because the issuance model does not change the underlying asset class.
These mandates ensure that traditional deposits are not used to launder money, evade taxes, or finance illicit activities.
1. Compliance and Anti-Financial Crime Rules
Banks will still need to meet the standard compliance duties that apply to deposit accounts and electronic transfers.
- Know Your Customer (KYC): Banks must legally verify the identity, date of birth, address, and legal status of every individual or corporate entity opening a deposit account.
- Customer Due Diligence (CDD): Ongoing monitoring to understand the source of a depositor’s wealth. High-net-worth clients, politicians, or cross-border companies face Enhanced Due Diligence (EDD).
- Transaction Monitoring & SARs: Automated systems must scan all inbound and outbound deposit movements for anomalies (e.g., sudden, large cash injections).
Any highly unusual activity must trigger a mandatory, confidential Suspicious Activity Report (SAR) to be submitted to financial intelligence units such as FinCEN in the US.
- Sanctions: Every transaction must be screened against the US OFAC and UN blacklists. No tokens can move to or from restricted people or countries.
- The FATF Travel Rule: For electronic funds transfers, the originating bank must securely transmit specific customer identity data, such as name, account number, and address, alongside the payment to the receiving bank.
2. Data privacy and financial secrecy rules
Banks have to protect customer confidentiality. That obligation does not disappear when deposits move to a blockchain ledger.
- Client confidentiality. A customer’s balance and transaction history are sensitive financial information. These details should not be exposed through block explorers, APIs, validators, or shared node access.
- Data privacy regulations. Rules such as GDPR, GLBA, and CCPA can affect how personal information is collected and used.
- Data minimization. Banks should avoid putting raw PII (tax IDs, IDs, KYC docs) on-chain.
- Purpose limitation. Data collected for KYC, AML, sanctions, or settlement should not be reused for unrelated commercial purposes unless the bank has the right legal basis.
- Right to erasure and legal retention. GDPR Article 17 gives data subjects a right to erasure in certain cases, but it also includes exceptions where processing is needed for legal obligations or legal claims.
This is why tokenized deposit systems should keep PII off-chain and put only hashes, credentials, commitments, or proofs on-chain.
The main point is not that every jurisdiction will use the same rulebook. The point is that tokenized deposits will be judged as banking infrastructure only.
Why are banks so stressed about privacy and compliance with tokenized deposits?
Banks are stressed because blockchain design and banking design start from opposite assumptions.
1st, Banks are legally mandated to protect client confidentiality under laws like GDPR and GLBA. On standard blockchains, wallet balances and transaction histories are public. But uploading standard deposit data to a shared ledger can trigger immediate compliance failures and multi-million dollar fines.
2nd, Corporations will not use a payment system that broadcasts their financial movements. Full visibility in public chains will allow competitors to see corporate payroll, supplier payouts, and mergers in real time. If enterprise clients refuse to adopt the platform because of this, it will permanently cap the deposit volume at retail levels.
3rd, Public financial trails could allow malicious actors to exploit liquidity flows. Because when large capital movements are visible before final settlement, arbitrageurs can front-run trades. If Institutions face slippage and financial losses for this, it will destroy trust in the tokenized ecosystem.
4th, Regulators will veto any un-auditable, completely anonymous financial system. Purely private, anonymous networks cannot fulfill AML or Counter-Terrorism Financing (CTF) obligations. If banks cannot verify the source of funds, it will result in regulatory shutdown of the pilot program.
Permissioned chains solve part of the problem. That’s why regulated finance is moving toward permissioned or semi-permissioned networks. They restrict who can join the network. They can gate users, limit validators, and enforce governance. But permissioned does not automatically mean private. A validator may still see too much. And that creates the issue of interoperability.
This excerpt from the Deposit Tokens report by Oliver Wyman and Onyx by J.P. Morgan, could be a best add-on here:
“Achieving economic fungibility among deposit tokens and/or off-chain deposits is not meaningful without sufficient technical interoperability to make actual exchange between different forms of money possible.
Technical interoperability will most likely occur between the issuing bank’s deposit tokens and its non-tokenized deposits, as a bank would naturally integrate its redemption process with its core banking system. This interoperability then extends to cash and other payment rails available through non-tokenized deposits.
The challenges of interoperability will be most pronounced in the exchange of tokens with different issuers, or the redemption of tokens for non-tokenized money by a bank that is not the original issuer….”
So one thing is clear: data privacy, data localization, interoperability, and asset leakage are key challenges for corporate blockchain adoption, and we need to find solutions.
How to enable selective privacy and compliance for banks if they issue tokenized deposits?
Banks have two options. Though we believe many banks will need both.
The first model is to choose a chain architecture that already gives the bank the right level of control, privacy, and interoperability.
The second model is to add a modular privacy layer that can sit between the banking application layer and the blockchain layer.
Model 1. Choose the right institutional chain structure
The market is moving toward three main corporate blockchain structures for tokenized deposit networks.
1. Third party institutional networks
The first path is to join or build on a third party institutional network. Networks like Canton, Rayls, Midnight, Hyli, and Provenance could be a few examples.
For example, Canton is a privacy-enabled, interoperable network for institutional applications and tokenized assets. Rayls positions itself as blockchain infrastructure for banks, RWAs, CBDCs, cross-border payments, and regulated liquidity. These two are public chains with your public nodes.
On the other hand, Midnight focuses on privacy-preserving applications with selective disclosure and zero-knowledge proofs. Hyli also describes itself as a privacy layer for private and compliant financial applications. We can call them privacy-first public chains.
Joining a third party network is best when a bank wants faster access to an existing ecosystem. It is also perfect for pilots where banks want to test how tokenized deposits interact with other tokenized assets, institutional money, or private settlements without building a whole network alone.
But don’t look at this as your permanent strategy for your core deposit infrastructure.
A third-party network means less control over roadmap, validator policy, governance, data visibility, privacy design, incident response, and commercial dependencies. It may also raise harder questions around legal finality, deposit liability transfer, jurisdiction, and supervisory comfort.
Source: Deutsche Bank: Digital Money Perspective
In short, third-party networks are for quick reach, testing, and access to the ecosystem. But if control, unique features, and true ownership of infrastructure is required, banks need to build their own bank chain or form a consortium network.
3.Consortium networks
A consortium network is the right fit when tokenized deposits need to move across multiple banks or institutions and follow common rules and standards.
Project Agorá is a good example of how this model works. Agorá is a BIS and IIF initiative with seven central banks and more than 40 banks and private enterprises. The goal is a unified ledger where tokenized deposits can interoperate with wholesale CBDC for policy aware, atomic cross-border settlement while preserving the two-tier banking system.
Then there’s Partior, which is already live and handles real-time international settlements with built-in checks to stop payment errors before they happen. Swift is doing something similar too, working on a shared ledger to help regulated banks move tokenized value at a massive scale.
The privacy and compliance logic for consortia is different from a 3rd party and bank-owned chains.
In a consortium, the challenge is not only whether the network is permissioned. The harder question is what each member can see.
- Bank A shouldn’t be able to spy on Bank B’s customer transactions.
- A validator should not automatically see every deposit movement.
- A corporate client should not expose supplier payments to other institutions.
- Regulators will obviously need to see data, but only through a strictly agreed-upon supervision model.
This is why consortium networks are complex to implement. Multi-bank tokenized deposit platforms depend on settlement assets, governance, rulebooks, and deep integration across messaging, controls, booking, and liquidity.
Zeeve can support consortium networks by helping design and operate the shared infrastructure layer. managing member nodes, setting up role-based access, running validators, and building the privacy tech that automatically enforces the network’s rulebook through code.
3.Bank-owned custom chains
This is the best fit when a bank wants maximum control.
A bank-owned custom chain gives the institution full control of the permissioning model, validator set, data residency, wallet eligibility, smart contract rules, compliance integrations, regulator views, and operating procedures.
Credit: Deutsche Bank
This is why large banks often start with internal or proprietary networks. This is the option J.P. Morgan Kinexys has also taken.
From a privacy angle, this model is attractive because the bank can reduce the number of parties who ever see transaction data. Client balances, treasury movements, liquidity sweeps, and internal settlement flows do not need to be exposed to a wider consortium or third-party network.
From compliance angle, banks can map the tokenized deposit system to their existing control stack. KYC data stays safely inside banks’ existing systems. They can run AML and sanctions checks before any transaction settles, and choose exactly how and when to give regulators or auditors access.
The limitation is interoperability and fungibility. If banks don’t plan for connectivity from day one, tokenized deposits won’t be able to talk to other banks, traditional RTGS networks, central bank wholesale money (CBDCs), or digital asset platforms.
Source: McKinsey: The emerging architecture of on-chain money
This is where Zeeve can help directly. For banks that want to own the chain, Zeeve can support custom blockchain infrastructure, managed nodes, validators, access control, monitoring, integrations, and production operations around the bank’s own privacy and compliance policies.
Model 2. Zeeve Privacy Layer as the modular privacy and compliance layer
The network model creates the first boundary. But it does not solve everything.
Even on a private network, sensitive balances can still leak through node data, APIs, and transaction logs. On a consortium, banks can accidentally see each other’s metadata. On a public network, it’s possible to map out your transaction history.
Honestly, Institutional privacy cannot be handled by isolated tools for only tokens, identity, contracts, or the ledger. It needs a system-wide approach.
This is where a modular privacy layer becomes important. That Zeeve brings, and it can be integrated with any chain type.
Read More: What does Privacy in Blockchain mean for Financial institutions?
Zeeve Privacy Layer sits between the banking application and the blockchain network. It is designed as middleware across asset transactions, smart contract execution, identity validation, role based access control, observability, and selective disclosure. It can work with permissioned networks, enterprise rollups, and public blockchain networks.
For tokenized deposits, each component of it solves a specific privacy and compliance problem.
Confidential transaction privacy
A tokenized deposit transaction can reveal more than an amount. It can reveal payroll timing, supplier relationships, treasury positioning, collateral stress, acquisition activity, or liquidity movement.
Confidential transactions stop that data leakage. In a tokenized deposit system, the bank can allow a transfer to be validated without showing transaction details to every network participant. Only authorized parties should see the amount, counterparties, and metadata. Zeeve Privacy Layer is built for this exact use case, with transaction details and counterparties visible only to authorized parties for tokenized deposit like use cases.
Private smart contract execution
Tokenized deposits are not just payments. They can trigger automated actions like intraday credit, automated cash sweeps, margin top-ups, and interest payments.
If the smart contract logic is visible to everyone, the bank may still leak sensitive information even if the token balance is hidden.
Netting rules, collateral management, and request for quote terms should not be visible to every bank in a consortium. Private smart contracts keep the business logic and private data visible only to the parties involved, while only posting the final proof of settlement to the ledger.
This is important for tokenized deposits because workflow privacy is as important as payment privacy.
Decentralized identity and policy gated wallets
A tokenized deposit should not move to an unknown wallet.
The stronger model is to bind wallets to verified identities, institutions, accounts, or approved agents without placing raw KYC data on-chain. Project Guardian gives a very relevant example. In the FX pilot, J.P. Morgan issued SGD deposit tokens on a public blockchain, but the token and protocol were designed to restrict unknown parties. The smart contract only interacted with known blockchain addresses, and authorized parties had to attach a verifiable credential from the issuer.
That is the compliance model banks need. Keep PII inside bank systems. Put only credentials, proofs, and eligibility checks on-chain.
Zeeve Privacy Layer supports decentralized identity, so eligibility and compliance conditions can be checked without exposing sensitive private or institutional data.
Role based access at the infrastructure layer
Banks cannot rely only on front-end permissions. Data can leak through RPC calls, node access, internal tools, analytics dashboards, and explorers.
Role based access control needs to sit closer to the infrastructure. Zeeve supports secure RPC level access control, authentication, and role based permissions. This allows a bank to define different views for treasury users, compliance teams, auditors, technology teams, external counterparties, and regulators.
This is important in consortium networks where multiple banks may run or access infrastructure.
Selective disclosure and auditability
Total privacy will not satisfy regulators. Total transparency will not satisfy banks.
The right model is selective disclosure. A bank should be able to reveal specific transaction data to a regulator, auditor, or compliance team under defined rules. That disclosure can be limited by transaction type, time window, threshold, role, investigation, or audit request.
Zeeve Privacy Layer supports selective disclosure and auditability through defined mechanisms for regulators, auditors, and compliance teams.
This is the heart of privacy and compliance in tokenized deposits. The system stays private by default, but it is not blind to supervision.
Observability for compliance evidence
At the end of the day, you have to prove to auditors that the right compliance checks actually happened before money moved.
Zeeve includes observability as part of the privacy layer, not as a separate afterthought. This matters because production banking infrastructure needs to prove that privacy controls and compliance controls are working continuously.
How can Zeeve help with both or help decide what’s most optimal for banks?
Zeeve can help banks evaluate these choices and build the right infrastructure. We are the only provider that has multi-stack expertise. The Zeeve Privacy Layer is designed to support permissioned/ consortium networks, custom enterprise rollups, and public blockchain networks.
For production, infrastructure maturity matters as much as privacy design. Tokenized deposits need reliable nodes, secure validators, key management, monitoring, incident response, disaster recovery, compliance reporting, and continuous support. Zeeve offers hardened environments for regulated industries, multi-cloud and hybrid deployment options, SOC 2 Type II, ISO 27001, and GDPR-compliant infrastructure, a 99.9 percent uptime SLA, and 24×7 NOC support.
Zeeve can help them choose the right network model, build or manage the infrastructure, integrate privacy controls, and operate the system with the reliability expected in regulated finance.
Book a call today to discuss how we can help with your tokenized deposit initiative.
