Blockchain privacy has become a real issue today because the ledger now has to carry financial information.
A payment amount is not just a payment amount. It can say a lot about liquidity. A series of payments may tell you who a company buys from, how often, and at what scale. That is where things get uncomfortable.
Permissioning the blockchain helps, but only up to a point. A permissioned blockchain can control who joins the network. It does not automatically control everything those participants can see once they are inside it. Because data still gets replicated in all the nodes. It can still appear through RPC endpoints, explorers, indexers, event streams, and sometimes simply through people having more access.
So privacy is not one question. And I do not think the useful question is whether the blockchain should be private. The more useful question is what exactly needs to stay private in a transaction, who should not see it, and who still needs access.
That changes quite a lot by use case. Capital markets and tokenized deposits can require very deep confidentiality because positions, counterparties, and liquidity are sensitive in themselves. Payments can expose transaction graphs and commercial flows. Stablecoins also have another set of problems. Asset management is different again. So there is no single privacy model that works cleanly across all of this.
In this article, we will see how some of these privacy problems can be tackled for enterprise use cases.
Why Do Tokenized Deposits Need Privacy on a Shared Ledger?
A tokenized deposit is still a commercial bank deposit. The difference is that the deposit is recorded and transferred on a blockchain. It remains a claim on the issuing bank and sits inside the existing banking framework.
Today, most tokenized deposit initiatives are still fairly contained. They may operate inside one bank or inside a closed group, with transfers staying within the issuing bank’s customer base.
That makes the privacy issue look manageable. But even inside one bank, it is not quite that simple. A large bank has corporate banking, markets, retail, treasury, and other businesses sitting around the same infrastructure. Just because somebody works for the bank does not mean they should be able to see activity belonging to another arm of the bank. Agree? The same applies to vendors, operators, and support engineers. If somebody has broad node access or unrestricted RPC access, they may see far more than their role actually requires.
The bigger challenge comes when tokenized deposits become genuinely multi-bank. Once several banks share the same ledger, the privacy problem gets much bigger. Because if every participating bank runs a node on that network, one institution may be able to see another bank’s client balances, counterparties, and transaction activity.
That is a big issue. A competing bank could potentially see which corporates maintain large balances with you. It could see those clients moving funds elsewhere. Over several days, it may even start seeing patterns in your own net outflows.
The current banking system does not normally work that way. Banks see the accounts and payment legs relevant to them. They do not receive a replicated view of everybody else’s business even if they are a part of the same consortium.
The bank’s first response to this issue could be wallet allowlisting and role-based access. Those controls are definitely useful. Banks already use whitelisting to decide who can hold and transfer certain tokens on public networks. But this solves a different problem. It only answers who is allowed to transact. It does not necessarily answer who can read the transaction after it happens. Right?
How Banks Can Close This Privacy Gap
There could be a few ways to do this.
For internal control, it makes sense to start at the application layer. A policy and control plane can define which users, wallets, and systems are allowed to read certain states or invoke certain contract functions. Private RPC controls can apply those policies every time an application asks a node for information. A role-scoped explorer can then give different teams different views of the same underlying network. This is relatively easy to do, and it deals with a large part of the internal access problem without changing anything in the token contract itself.
But confidentiality between banks is hard because now there needs to be asset-layer privacy. For example, the deposit can be issued as a ZK token. Validators can then verify that a transfer is valid without necessarily learning the transfer amount or counterparties. Selective disclosure can sit alongside that, so a supervisor, auditor, or other designated party can still access transaction evidence when the rules require it.
Here is one more aspect worth paying attention to. Even if the transfer itself is shielded, the workflow around it may still leak information. Because asset transfers are not the only transactions that happen in any network. An interbank transfer may involve a proposal, approval, and then asset movement. If those contract calls remain visible, another participant may still be able to infer which banks are doing business together. Correct? That is where bilateral workflows or privacy-scoped contract execution become relevant.
The point is not to make everything invisible. But our goal is to stop the ledger from giving every participant the same view simply because they participate in the network.
What Privacy Problems Do Stablecoins Create for Issuers and Corporate Users?
Stablecoins start from the exact opposite position to tokenized deposits.
A stablecoin is a privately issued token designed to maintain value against a reference currency, most often the US dollar. Roughly $300 billion is outstanding, according to BCG’s 2026 report.
Unlike tokenized deposits, stablecoins are usually bearer instruments. A wallet can hold the token without the issuer approving every transfer in advance. They also tend to operate on public permissionless networks. That is attractive for reach and interoperability.
It is also where the privacy problem starts. Because anyone can inspect balances and transfers. For a corporate treasury team, one identified wallet address can reveal a surprising amount. Suppliers may see what other suppliers are being paid. Competitors may see cash balances. Payment timing becomes visible. In some cases, the entire transaction history of a treasury wallet becomes available to anybody who wants to analyse it.
J.P. Morgan has already pointed to privacy as one of the conditions that digital currencies need to meet before they are useful at scale for corporate treasury. That is not surprising. Corporate treasurers do not generally want their liquidity and payment relationships published simply because settlement has moved onto a blockchain.
But stablecoins have another problem as well. The market sees too much, while supervisors can sometimes see too little. Here, the wallets are pseudonymous if it’s a public permissionless network. That means transaction activity may be transparent, yet it is not always obvious who the economic parties are. BIS has pointed out that this makes even cross-border stablecoin activity difficult to measure accurately.
So an issuer is trying to solve two problems at the same time.
- Hide commercially sensitive information from people who have no reason to see it.
- Still give regulated parties the information they are supposed to have.
There is also no single correct view. The issuer needs one view. A distributor may need another. Network operators should probably see less. Supervisors may need something different again. That is the design problem.
How Issuers Can Close the Gap
Most of this work happens at the asset layer. The stablecoin itself can be issued as a ZK token so transfers, minting, and burning can happen without exposing all transaction details to the wider network. Validators still verify the transaction. They just do not need all the underlying information in readable form.
Compliance can also move into ZK proofs.
For example, a holder may need to prove that onboarding has been completed or that the wallet meets a particular eligibility requirement.
The proof can show that the requirement is satisfied without putting the underlying identity data directly on the ledger.
Similar approaches are already appearing in early production environments.
Selective disclosure then gives compliance teams and designated authorities access to the transaction evidence they actually need.
Audit dashboards can provide the operational and reconciliation view around that.
There is also an infrastructure leak that is easy to overlook.
Even when the token itself is private, institutions still query the network through RPC endpoints, explorers and indexers.
The operators of those services may be able to see which wallets or contracts the institution is looking at.
Private RPC infrastructure and role-scoped explorers bring those reads under the institution’s own access policies.
For regulated stablecoins, I would settle the disclosure model before trying to maximise confidentiality.
A stablecoin that is very private but impossible for the appropriate supervisor to inspect is probably not going very far in a regulated market.
Which Privacy Risks Come With Cross-Border, Peer-to-Peer and DvP Payments on Blockchain?
Payments get complicated when a shared ledger brings the payment instruction and the settlement much closer together. Because putting payments on a shared ledger changes who can see the information around that movement.
Let’s take cross-border payments. Correspondent banking today is fragmented. Liquidity is distributed across institutions. So naturally, compliance checks have to happen in sequence. Settlement can take time. All of that is inefficient. But the fragmentation also creates privacy almost by accident.
Each institution in the chain generally sees its own part of the transaction. A shared ledger removes that separation. Unless the design deliberately puts some of it back. The addressable cross-border flow is roughly $30 trillion a year according to a recent BCG report.
The banks processing those flows are competing corridor by corridor. That makes seemingly harmless network transparency commercially meaningful.
There are a few different cases here. Let’s see them.
Cross-border payments
A shared ledger can expose corridor volumes, customer flow patterns, and liquidity by currency. If a competitor can see how much volume your bank is moving through a corridor, it learns something about your franchise.
Similarly, if a counterparty can see your prefunded balance, it may learn something about your immediate liquidity position. There is also a jurisdiction issue. Replicated ledger data may end up sitting on nodes in countries that have nothing to do with either side of the transaction. That violates the data residency rules in countries like the EU. So it can be difficult where such localization rules exist.
Peer-to-peer payments
This is more directly a personal data issue.
If names, account details, or other personal information are written into an immutable ledger, correcting or removing them later becomes difficult.
Banks operating under correction or erasure requirements need to think about this before customer information gets anywhere near the shared state.
Delivery versus payment
DvP brings the asset leg and the payment leg together. That is a super useful feature that solves many standing challenges. But if both legs are visible to other network participants, they may be able to infer the price and size of the trade.
There is also the compliance leg. Sanctions and AML processes need originator and beneficiary information. That information may need to move with the payment. It does not follow that every participant on the network should see it.
The infrastructure is still developing here. In a 2026 survey of investment banks, no respondent said its internal infrastructure was ready for tokenized cross-border payments at scale. All respondents placed external market infrastructure somewhere between one and three years away. So these design decisions are still being made.
How Privacy-Enabled Payment Networks Can Close the Gap
The settlement asset can use ZK technology so amounts, counterparties, and transaction graphs remain confidential across the network.
Custom ZK circuits can deal with payment-specific conditions. A sending bank could prove that its required compliance checks have been completed without publishing the customer’s underlying information to every other participant.
For DvP or payment-versus-payment, the two parties could also prove that both legs satisfy the agreed terms without publishing those terms more broadly.
Supervisory access can sit outside that through selective disclosure. A designated authority will receive the evidence it needs. Everybody else sees only what they are supposed to see.
There could be two more types of controls to address the structure. Bilateral workflows or private sub-ledgers can keep corridor activity between the institutions actually involved. Node onboarding and peer governance can determine who is allowed to operate infrastructure and where ledger copies are held.
Then there is some application access problem again. Event streams and logs can expose activity in real time to all participants. Right? If every connected system can subscribe to payment events, the network may leak commercially useful information even when other controls are in place. Private RPC controls can intercept those requests by identity and policy.
How Does Tokenization Expose Investor Data in Asset Management?
A tokenized fund is a fund whose shares are issued and transferred as tokens on a ledger. The ledger then carries the information a shareholder register holds today.
The potential scale here is good. Global money market fund assets are roughly $8 trillion. If 5 to 10 percent moved into tokenized structures, that would mean somewhere between $0.4 trillion and $0.8 trillion sitting on-chain, and private credit funds are already one of the larger categories in tokenized funds.
So, what’s the privacy issue here? In a traditional fund, the shareholder register is held by the transfer agent. Investors generally do not see one another’s positions. A transparent shared ledger changes that. The holder list may become readable. Other participants may be able to work out how concentrated the fund is and how large individual positions are. Subscriptions and redemptions can become visible in real time too.
Does it matter? Well, yes. Automated redemptions can already accelerate outflows under stress, particularly in open-ended funds holding less liquid assets. Making every redemption visible to every other holder could add another signal into that behavior.
There is also a distributor problem. If several distributors use the same platform, one distributor should not automatically see another distributor’s client activity. The ledger may make that possible unless access is designed carefully.
Fund tokens are also used outside the fund. Investment banks are exploring tokenized money market funds as collateral. In a 2026 survey, 40 percent said they were exploring that use case, and another 40 percent were already piloting it.
That means the privacy boundary has to move. When an investor pledges fund tokens as collateral, it may disclose both the fund holding and part of its funding activity.
Private funds introduce another challenge. Loan terms, borrower information, and other details inside private credit portfolios are commercially confidential. Putting the fund on-chain does not make that information any less sensitive. Managers sometimes deal with investor eligibility by allowing only approved wallets to hold the fund token.
Maybe that helps, but again, eligibility is not the same thing as privacy. You can restrict who owns the token and still expose the owners and their positions to everybody else on the network.
How Asset Managers Can Close the Gap
Fund shares can be issued as ZK tokens. Holdings and transfers then remain confidential while the network still verifies minting, transfers, and burns.
Eligibility can also move into ZK proofs. An investor proves that it meets the qualification rules without publishing the documents or identity information behind that qualification onto the ledger.
Fund operations are slightly different because some parties really do need broad visibility. The transfer agent may need the complete register. The auditor also needs a different view. The regulator has separate requirements. A distributor should probably see its own clients, not everybody else’s.
Selective disclosure can support the parties that require evidence. A role-scoped explorer can narrow the operational view for each distributor. Audit dashboards can give administrators the reconciliation view they need. Lifecycle events such as distributions can also use privacy-scoped contract execution so the details are visible only to the parties involved.
One important point has to be mentioned here. Part of the appeal of tokenized funds is their direct use in digital asset markets. Managers should confirm how a confidential share class will work with the trading venues, collateral platforms, and custodians where they expect the token to be used
There is not much value in solving privacy perfectly and then discovering the asset cannot move through the rest of the market structure.
Where Are Capital Markets Workflows Most Exposed From Issuance to Repo and Custody?
In capital markets, privacy is most complicated. The reason is not that one piece of information is uniquely sensitive. It is that there are so many pieces.
Tokenized capital markets may put the security, the cash leg, and the workflow around both onto connected shared infrastructure. The obvious benefit is better coordination and greater transparency over ownership and transaction history.
Supervisors can benefit from that. Trading desks may feel differently if their competitors receive the same transparency. The exposure appears at almost every stage.
Issuance
The order book and final allocation can show which investors wanted the security and how much each received.
That is valuable information.
Trading and positions
If inventory and position movements are visible on a shared ledger, another participant may begin to infer a desk’s strategy.
In some cases, it may also be possible to trade ahead of a large position change.
Repo and collateral
This can get very sensitive.
Of the DLT repo tests and transactions cataloged through 2025, 83 percent were intraday. Repeated intraday borrowing says something about liquidity. The repo rate and haircut are also bilateral commercial terms. Collateral movements tell the network which assets a bank is able or required to post.
That is more information than most institutions would willingly publish today. Right?
Custody
Client holdings on a shared ledger may become visible to other participants unless the custody model deliberately separates them.
Internal access matters as well. A custodian does not want every employee seeing every client position simply because everybody happens to use the same infrastructure.
Repo creates another problem because it is not one transaction. It is a lifecycle. Collateral gets allocated. Margin calls happen. Assets are substituted. Eventually the trade unwinds.
Every one of those steps can become a contract call. If privacy only applies to the token movement, the surrounding workflow can still remain visible.
Some platforms have handled confidentiality partly through centralization. Broadridge DLR, the largest DLT repo platform by volume, hosts all client nodes. The DLT and Repo Report describes that structure as effectively centralized.
That solves one type of information sharing problem. But it creates another one. The platform operator can potentially become the party that sees everything.
There is also a scaling question around closed networks. Several banks are increasingly skeptical that private chains and consortium structures can scale cleanly across the whole market.
The alternative is a shared network where institutions can operate their own infrastructure, but confidentiality is built into the transaction and workflow design.
That is a harder architecture. It is probably closer to what institutions actually need if these networks become market infrastructure.
How Capital Markets Participants Can Close this Privacy Gap
Capital markets might need all four layers of privacy.
At the ledger layer, bilateral workflows and private sub-ledgers can keep the repo lifecycle between the two counterparties and any relevant tri-party agent. Privacy-scoped contract execution can limit visibility of margin calls and substitutions.
At the asset layer, ZK tokens can protect collateral and cash movements. Custom ZK circuits can go further. For example, a borrower could prove that collateral is eligible and sufficient under the agreed haircut without revealing the rest of its portfolio.
At the application layer, the policy and control plane can enforce information barriers between desks. It can also add approval workflows around sensitive actions. Custodians can use the same model to separate client views.
At the network layer, permissioned validators and node onboarding controls determine who is allowed to run infrastructure. When that is combined with asset-layer confidentiality, institutions can run their own nodes without automatically exposing all their trades to every other member.
Supervisors and auditors still need access. Selective disclosure and audit dashboards can provide that without giving the same view to everybody else.
So Which Use Case Needs Privacy the Most?
There is no very clean ranking here because the risks are different. But capital markets probably require the broadest set of controls. The exposure sits in the asset, the workflow, internal access, and the network structure at the same time.
Multi-bank tokenized deposits and payment networks may carry some of the most commercially sensitive information per transaction. Balances, counterparties, and liquidity movements are all meaningful.
Stablecoins start from the most exposed architecture because public blockchains are transparent by default.
Asset management is somewhat narrower, but the information is sensitive in a different way. It includes investor identities, holdings, subscriptions, redemptions, and sometimes underlying private asset data.
A simple way of looking at it is below.
For a bank designing its own roadmap, I think the useful starting point is asking who else shares the ledger. Privacy requirements increase very quickly once another institution, especially a competitor, runs a node on the same network.
At that point it becomes part of the market design.
FAQs
Is a permissioned blockchain private enough for regulated digital assets?
Usually no. Permissioning controls who gets onto the network.
Once somebody is on the network, they may still be able to read transactions that have been replicated to their node. Confidentiality needs another set of controls that a modular privacy layer can bring.
Can regulators still see transactions on a privacy-enabled network?
Yes. Selective disclosure can give designated authorities access to specific transaction evidence under defined rules.
Which privacy control should an institution deploy first?
If the main concern is employees, vendors, operators, or RPC access, start at the application layer.
If the concern is competitors sharing the network, confidential assets and selective disclosure become more important.
Different problems need different controls.
Does adding privacy mean moving to another blockchain?
Never.
Modular privacy controls can be added around EVM environments that institutions already use, including Besu networks, rollups, and private or public-permissioned chains.
Do zero-knowledge proofs make regulated transactions harder to audit?
They do not have to.
The network can use the proof to confirm that the transaction is valid.
An authorized party can separately receive the underlying evidence through selective disclosure.
Choose Zeeve for Privacy-Enabled Blockchain Infrastructure
Zeeve’s privacy offering is modular in nature. Hence, any financial institution doesn’t have to integrate all four modules from the start. It can choose what’s required.
These modules can work across EVM environments including Besu networks, enterprise rollups, private L1s and public-permissioned chains.
So the institution does not need to make its privacy decision dependent on one blockchain stack.
Zeeve operates this infrastructure in ISO 27001 and SOC 2 Type II compliant environments, including Bring Your Own Cloud deployment where banks need nodes and infrastructure inside their own environment.
Zeeve is also a certified Besu service provider and a member of LFDT. Zeeve is also an official partner of Cosmos Labs and can help you implement its tokenization engine and IBC.
Talk to us to discuss your requirements.
