Key Takeaways
- Most bank blockchains work well inside one institution. They struggle once a second bank joins, because on a plain shared ledger, every node can read the same data.
- Permissioning only decides who joins a network. It says nothing about what each member can see after joining, and that is where most of the commercial risk sits.
- On most private chains, at least one party can see everything. Supervisors may need that view, but competitors and vendors should never get it by default.
- Insider access gets the least attention of the three. When every department shares the same RPC access, teams can reach contracts and transactions that have nothing to do with them.
- Banks can address these flaws in layers. Application controls and asset privacy can sit on top of an existing EVM network, so a new chain is rarely the first step.
A bank can put transactions on a blockchain and still struggle to get much value from it.
That might sound a little strange when you look at the big numbers, such as Citi processing close to $1 billion a day on its Besu-based platform, or J.P. Morgan’s Kinexys doing about $2 billion a day in repo. Even so, these networks mostly work like ‘walled gardens’, because most of this activity stays inside one bank or a tightly run bank network. So banks are moving money, sure. They just aren’t doing it across a ledger they share with other banks, which was the whole point.
A shared ledger only pays off when other institutions actually join it, and that’s where things get difficult. We keep seeing the same three problems with the enterprises and banks we work with. Data on the chain isn’t private. At least one party ends up knowing everything. And inside the bank, access is often wide open.
So we’ll go through each flaw and see what a bank can do about it.
Why Are Banks Running Into These Limits Now?
For years, a chain run by one bank was enough. That is changing now. Swift’s Besu-based shared ledger went live as a minimum viable product in July 2026 with 17 pilot banks. A group of large US banks plans a tokenized deposits clearing network from early 2027. There are quite a few examples like this. The pressure to share is growing anyway.
These projects put competing banks on shared infrastructure. That is where all three flaws show up.
Flaw 1: The Fear of Exposing on-chain data
A blockchain keeps every node in sync, so every node holds the same record. For a bank, that is the problem.
On a plain private chain, any bank running a node can read what is on the ledger. That includes transfers, contract calls, and the addresses involved. If Bank A invites Bank B onto its network, Bank B can work out who Bank A settles with, how often and for how much. So can every other member.
No bank wants a competitor to have that view. According to Institutional Adoption of LF Decentralized Trust Technologies 2026, by Ledger Insights, the industry’s default answer has been for each institution to run its own ledger and connect to others through conventional messaging.
“Without a privacy solution, the industry defaults to what it already has: every institution runs its own ledger and connects to others through conventional messaging. The blockchain adds a different kind of programmability, but reduces the desired privacy level.”
We see the same pattern also. The bank wants to keep the chain to itself. They want others to get onboarded, but that raises other concerns that are non-negotiable.
It’s easy to assume permissioning deals with this. It doesn’t. Permissioning decides who can join. Wallet allowlists decide who can transact. Neither one decides what a member can read once it is inside.
In our view, a bank needs to keep three things confidential from other members on a shared ledger. These are who its partners are, what volumes it does with them, and what those transactions are worth. The assets on the chain need the same protection.
If a consortium can’t protect these, it has two options. It stalls, or it hands everything to a single operator. The second option leads straight to the next flaw.
Flaw 2: An operator who can see everything
Say the consortium picks a single operator. A lead bank or a market infrastructure runs the nodes, and members connect through an application. Members can no longer see each other’s data. But the operator still can.
The IMF, in its Rise of Tokenization notes, raises this issue directly. Permissioned systems don’t really solve privacy, it says, because they are often designed so that one entity can observe everything. Users then have to trust that entity not to exploit its position and not to get compromised by a malicious third party. A shared ledger can replace dozens of bilateral links, and it also becomes a critical node whose failure could disrupt the whole market. The IMF’s risk matrix ties permissioned access to single-point failures and centralized governance to concentration.
Source: Global Financial Stability Report 2026, IMF
There is a second cost here. Members in this setup hold application access only. And members with application access can’t check the ledger for themselves. Or simply, not every participant will become a validator. They are relying on the operator’s records, which is what they did before blockchain.
The third is reach. The full view extends beyond the operator to node administrators and infrastructure vendors. These node admins and infrastructure vendors can get hold of the data set too. But many specialist vendors are not regulated like banks or core market infrastructures, and regulators are likely to ask why core workflows depend on them.
For a bank, that means its trading relationships and flows sit with one party, protected mainly by contracts and trust. If that party is compromised, every member is exposed at the same time. And it’s often more than one party. Node admins and infrastructure vendors can get hold of the data set too.
So some visibility has to exist. Supervisors need access. For example, in Project Agorá, the token issuer has full visibility because they wanted to keep oversight simple. So a bank needs to know who holds it, how much of it they hold, and whether that access can be proven later. Selective disclosure helps here. It lets a bank show a specific transaction to a specific auditor or regulator and keep the rest of the ledger closed.
Flaw 3: Poorly restricted insider access
The first two flaws involve other institutions. This one sits inside your own bank.
A single chain often serves several departments. RPC is the interface applications use to talk to a blockchain node. When one chain serves several departments, everyone ends up with the same RPC access. Anyone with that access can reach pretty much anything on the chain, from a smart contract to native transactions.
Take a bank with a forex team and a cross-border settlement team on one network. Nothing stops one team from reading the other’s activity. A vendor brought in for one application can see data meant for another. An indexer built for one team can pull events that belong to a different team.
We’ve seen these concerns wth our own work with banking partners. Access goes unrestricted and under-governed, and that leads to security friction and operational problems. This isn’t only about someone misusing access on purpose. Verizon’s 2025 breach data shows that when insiders are behind a breach, plain mistakes happen about twice as often as deliberate misuse.
Compare this with how the rest of the bank runs. Maker-checker, access management, and transaction limits are foundational treasury controls against insider fraud and role abuse. A raw RPC endpoint knows none of these rules. It can’t tell that a payment above $1 million needs a second approver. And these rules can’t be set in smart contracts, as different banks have different restrictions, and once a new bank joins, or someone exits, it’s hard to modify the smart contracts every time.
Three things make the gap more serious on a ledger than in a legacy system.
- Finality. Instant settlement removes the buffer of a T+1 or T+2 cycle. Once it’s gone, it’s gone. A wrong call by an insider can’t be caught in overnight reconciliation. It has to be instant.
- Custody of assets. Client protection will depend partly on who can reach smart contract functions and who controls the credentials that move clients’ assets. So in tokenized systems, the key levers of control will be governance keys and smart contract logic. So when an auditor asks who could call a given function for an audited transaction, your team should have a clear answer.
- Hidden dependencies. One contract method often calls others. An admin can grant access to one method and unknowingly open a path into a second or third contract.
Hence, the threat is also getting sharper. The state actors, ransomware groups, and insiders now have access to more powerful tools. And the human element shows up in about 60% of breaches.
How Can Banks Fix These Flaws Without Changing Chains?
We find it easiest to think of privacy as layers. Each layer has a job, and each has a limit.
Most real use cases, tokenized deposits or cross-border payments, for example, need a combination of these. The BIS argues for combining hard privacy through cryptography with soft privacy through institutional controls.
“Technology also has an important role to play for soft, institution-based privacy. For soft privacy, data protection policies and technologies can curb access to payment data, authorizing only entities that require it to facilitate the mechanics of a payment and minimizing secondary uses, as well as establishing strictly enforced retention periods. On balance, we hence argue that better technological solutions offering hard privacy need to emerge, and that development efforts should also focus on building payment systems that combine hard and soft approaches. This means limiting the amount of data that is accessible in the first place via hard privacy, as well as making data abuse harder, via the use of technologies such as privacy-enhanced identity management, tokenization, technology-enforced limits on retention periods, and audits of data holders.”
Source: BIS working paper, 1242
Application privacy can be that soft privacy. Privacy groups, ZK circuits, ZK tokens, and other ledger or asset layer privacy solutions can be hard privacy solutions.
Learn More: The Four Layers of Blockchain Privacy: What Banks and Financial Institutions Need to Know
Zeeve Privacy-suite for Bank-Grade Privacy on the Chain You Already Run
A blockchain pays off when more than one institution can trust it and use it. All three flaws get in the way of that.
This is the problem we built Zeeve privacy suite to solve. It is a modular privacy suite for EVM environments, including Besu. A bank can start with application-layer controls for roles, RPC access, contract methods, events, and approvals. Asset-layer privacy is the planned next phase. Zeeve’s infrastructure is ISO 27001 and SOC 2 Type II compliant, and a bank can adopt the privacy solution without moving off the network it already runs.
Talk to our experts to discuss your use case.
