Privacy and banking are always close to each other. Quite close, in fact.
A bank cannot allow one corporate customer to see another customer’s balance. One bank cannot allow a competing bank to study its money flow. And no regulator will ever be impressed by any such architecture that exposes confidential transaction data merely because blockchain wants every validator to have a copy of the ledger.
This is partly why banks kept their early blockchain networks inside rather high walls. The bank ran the nodes. It deployed the contracts. Customers and employees only used an application sitting above the chain. The application decided what each user could see, while the ledger remained in the bank’s own infrastructure.
This arrangement protected data. But it also kept much of the blockchain potential rather unutilized.
Now banks want to use blockchains for tokenized deposits, cross-border payments, repo, collateral movement and delivery-versus-payment settlement. These use cases involve several institutions. If all the banks participate only through one application, while one operator controls the ledger underneath, they are part of a blockchain application. They are not part of the actual blockchain network.
Giving every institution a node solves this participation problem but it creates another problem. A normal node may receive the complete shared state. It may see amounts, balances, counterparties, and other activities belonging to everybody else.
So, the actual question before a bank is not whether blockchain needs privacy. Of course it does. The question is how much of the existing architecture must be changed to achieve it.
What options do banks and financial institutions have if privacy is the priority?
Well, there are three ways to approach the problem.
- A bank can move its use case to a new blockchain where privacy comes built into the protocol.
- It can build a dedicated chain and choose the privacy design itself.
- Or it can retain the blockchain already in use and add privacy to it.
These are three options because they change three different-sized parts of the architecture.
The first changes the underlying protocol. The bank accepts the new network’s privacy method, contract model, governance and ecosystem.
The second changes the complete infrastructure. The bank or consortium chooses the validators, execution environment, assets, permissioning and privacy components.
The third changes only the privacy capabilities. The chain, contracts and integrations can remain where they are, subject to the modules being added.
The right option, therefore, depends a great deal on where the bank is starting from. A greenfield project has the freedom to choose a new chain. A bank already running contracts, custody, reporting and core-banking integrations has much more sitting on the table. Rebuilding all of it to hide one part of a transaction would be rather like changing the house because the curtains are transparent.
Let us look at the three options one by one.
Option 1. Migrate to a privacy-first blockchain
A privacy-first blockchain makes confidentiality part of its native transaction, contract or data-distribution model. The bank does not have to assemble the main privacy mechanism separately. It does, however, have to accept how that mechanism works.
Canton could be an example here.
Canton distributes transaction and state data on a need-to-know basis. Smart contracts determine which parties should receive particular data. Validators store the private state of the parties they host, while synchronizers coordinate encrypted messages between the relevant parts of the network.
Put simply, every participant does not receive every transaction.
If Bank A and Bank B complete a repo transaction, Bank C does not need to receive the position, price and other confidential terms simply because it also participates in the wider network. Privacy comes from limiting distribution of the state itself.
This design fits transactions involving known parties and sensitive deal terms. Repo, collateral movement, bonds and delivery-versus-payment workflows sit rather comfortably in this arrangement. It is no surprise that much of the institutional activity around Canton has grown around capital-market assets and coordinated settlement.
But privacy always arrives with an architectural choice tucked inside it.
In Canton’s case, the transaction is not sent to and re-executed by every validator in the whole network. The entitled parties and the nodes relevant to that workflow receive and validate the private state. The network gains confidentiality by narrowing who obtains the data and who verifies that particular part of the ledger.
This is not a defect. It is how the system is designed. A bank only needs to decide whether this verification model matches the use case.
Then comes the matter of technology.
Canton applications use DAML rather than Solidity-like popular contracts. A bank with working EVM contracts cannot pick them up, place them on Canton and call it migration completed. JSON-RPC integrations, event indexers, development tools, testing processes and operational knowledge may also need to change.
The migration makes stronger business sense when the destination chain can bring more than just privacy. Perhaps the required counterparties are already there. Perhaps the assets, liquidity or settlement venues needed by the use case already operate in that ecosystem. In such cases, the bank is joining a market as much as it is choosing a technology.
But the argument is weak when a bank already has a useful Besu network, Cosmos EVM chain or enterprise rollup and only needs to hide selected data. Moving the complete application to another protocol can create a bigger project than the privacy gap itself.
Other privacy-first chains may use zero-knowledge proofs, private computation or confidential asset models. Midnight, Hyli, or Provenance kind of chains could be a few examples. Their methods differ, but the question remains the same. What does the native privacy design hide, who can still see the data, and what must the bank change to use it?
A privacy claim without these answers is only half a privacy claim.
So, yes, migration can be the correct choice for a greenfield product, a major redesign or a workflow that needs the participants and assets of a particular network. It is a less comfortable choice when the bank wants to keep its EVM contracts, integrations and operating model intact.
Option 2. Build a dedicated chain
If a bank or consortium has no blockchain infrastructure today, building a dedicated chain makes complete sense.
The institution can choose every component and parameter. Suppose who the validators are, where the data stays, what legal or governance rules apply, etc. It can use Hyperledger Besu for a permissioned EVM network. It can build a sovereign chain with Cosmos SDK, deploy a private ZK L2 rollup, or add confidential assets to an L1 that has eERC capabilities.
That is a good deal of freedom.
Yet owning the chain and achieving complete banking privacy are not the same thing. This becomes clearer when privacy is divided into four layers.
These layers are important to understand because blockchain itself doesn’t work as a monolithic architecture. It also works in layers, and every layer can have some weakness. That’s why we have four privacy layers also. A particular use case may need all four. Another may need only two. The trouble starts when one privacy control is asked to do the job of the full stack.
Take a normal permissioned chain like Besu.
Node and account permissioning can keep unknown participants outside the network. This is useful and necessary. Yet it mainly protects the network layer. Once an approved member runs a validator and stores the same shared state, it may still see the ordinary transactions of other approved members. That’s the reason why we have had permissioned chains for years but not hard use cases where multiple parties are members on the network layer and not just on the application layer.
A new consortium network therefore needs other components if validators should not see one another’s transaction data.
Now, suppose the bank adds eERC.
eERC encrypts balances and transfer amounts and allows the network to verify transfers through zero-knowledge proofs. For a tokenized deposit or settlement asset, this is a meaningful privacy feature. Sender and receiver addresses, however, can remain public. eERC does not decide which employee may query the ledger. It does not hide wider contract state. It does not separate a complete bilateral repo or payment workflow.
It solves the asset privacy problem it was designed to solve. Nothing less. Also nothing more.
A private ZK chain goes a little further. ZKsync Prividium, for instance, combines role-based application access, private execution, ledger-wide data isolation, selective disclosure, and zero-knowledge proofs anchored to Ethereum.
Here the trade-off is in the operating model.
Transaction data stays within the operator’s infrastructure. The operator also retains visibility and transaction-ordering control. Prividium currently uses a single sequencer also. Ethereum can reject an invalid proof, but it cannot force the operator to include every valid transaction.
This could be an excellent solution for one bank operating a controlled private chain. It does not automatically create a shared multi-bank ledger where several institutions run the core network and each institution sees only what its role permits.
Separate private ZK chains for separate banks provide strong boundaries around each bank. They also divide contracts, assets, data and liquidity between those environments. Interoperability and settlement must then be designed across the chains. Detailed transaction data also needs suitable regulator-access and reporting arrangements.
None of this means permissioned chains, eERC or private ZK chains provide poor privacy. Each solves a real part of the problem. Banks only get into difficulty when a part is sold as the whole.
A complete design may still need enterprise identity, node security, confidential assets, private workflows, selective disclosure, custody, key recovery, monitoring and regulatory evidence. Building a chain gives the institution the freedom to assemble these from day one. It also hands the institution the full integration and operating burden.
For a bank, consortium or FMI building long-term market infrastructure from scratch, that burden may be justified. For a bank already operating a suitable chain, building another chain can reproduce the same privacy gaps while forcing contracts, custody, monitoring and core-system integrations to be rebuilt.
New land is useful when one needs a new house. It is an expensive place to go merely to install better security or privacy.
Option 3. Add a modular privacy layer
If the existing chain works, why replace the ledger when privacy is the part that does not?
A modular privacy infrastructure adds the missing privacy capabilities around an existing blockchain. The bank can preserve contracts, custody arrangements, APIs, monitoring, reporting, and core-banking connections wherever the selected module does not require a contract change.
It can bring all four layers of privacy, and because it’s modular, banks and other financial institutions can choose which privacy layers they want.
Application controls can limit which employee, customer, system or counterparty reaches a blockchain endpoint. Private RPC and scoped explorers can show different views of the same network. Network controls can govern nodes, encrypted connections and infrastructure boundaries. Confidential assets can hide balances, amounts and transaction parties while keeping the transfer verifiable. Private execution can protect contract state and deal workflows. Selective disclosure can give a regulator or auditor the evidence required for its role.
The important difference is what this allows banks to do together.
Several institutions can operate nodes and verify a shared state without turning every sensitive commercial fact into common knowledge. Banks can take part in the core network rather than submitting instructions to somebody else’s blockchain through the application layer.
For enterprise use cases like tokenized deposits, 1st-party stablecoins, PvP, DvP, repo, collateral, and cross-border payments, this will open up true coordination capabilities. Participants can verify and coordinate on shared infrastructure, while the privacy layer controls what each participant can do.
Zeeve Tegaris is designed as this kind of modular privacy infrastructure. It brings controls across the application, network, asset, and ledger layers into one architecture. A bank may use the complete privacy stack or select the modules required for one use case.
Tegaris can work across EVM environments including Hyperledger Besu, private L1s, enterprise rollups, public-permissioned networks and even public EVM chains. Zeeve can also develop non-EVM integrations where the use case demands them.
For an institution already running Besu, an EVM rollup or another suitable chain, modular privacy is usually the more direct route. It closes the visibility gap without discarding the infrastructure built around the ledger.
A decision table
Choose Zeeve for unbiased consultancy and privacy-enabled blockchain infrastructure
Zeeve works across enterprise blockchain stacks and does not operate one chain that every customer must join. The discussion can therefore begin with the bank’s use case and present infrastructure.
For one bank, the correct answer may be a privacy-first network. For another, it may be a dedicated Besu or Cosmos-based chain designed from scratch. For a third, the chain may already be doing its job, and only the missing privacy capabilities need to be added. Some use cases may require a combination of these routes.
The engagement can begin with a privacy exposure map. It identifies which data becomes visible, who receives it, who needs to verify it, and where the privacy gap is. The bank can then see whether the gap requires a new protocol, a new chain or one additional module.
Zeeve Tegaris provides modular privacy controls across all four layers. Banks can add identity-aware access, private endpoints, network policies, confidential assets, private transactions and workflows, selective disclosure and regulator or auditor views according to the use case.
The same approach can support a private Besu deployment today, a multi-bank network tomorrow and a suitable public-chain workflow later. The institution can add privacy as participation becomes more distributed, without being pushed into a chain choice merely to obtain it.
Privacy remains the priority in all three options. The difference lies in how much the bank must change to achieve it.
Talk to a Zeeve architect today to discuss which option best suits your use case.
