When banks first started experimenting with blockchain, privacy appeared to have a rather simple answer.
Build a private blockchain.
But the question is, does limiting who can join a network really protect everything happening inside it?
Well, not always.
A permissioned blockchain can control which banks, institutions, or validators participate. But once they are inside, participants may still be able to read transaction records that have nothing to do with them. A competing bank may see another bank’s activity. And a regulator may either see too little or be given unrestricted access to everything.
This is where modular privacy comes in.
A modular privacy infrastructure is a collection of independent privacy controls placed between applications and the blockchain. It governs who can view data, submit transactions, call smart contracts, approve operations, and disclose information.
And unlike a privacy blockchain, it does not require a bank to move everything to a new network.
Why Is Modular Privacy Necessary?
Well, banks do not have just one privacy requirement.
Let’s suppose a blockchain network is shared by several commercial banks, a central bank, payment operators, auditors, technology providers, and regulators.
They may all participate in the same system, but they should certainly not see the same information.
A commercial bank may need to see transactions involving its own customers. Another bank should not be able to view those transactions. The network operator may need performance and settlement information without seeing customer details. An auditor may require evidence for a particular period. A regulator may need access to a specific transaction when an investigation or supervisory review takes place.
Trying to satisfy all these requirements with one fixed privacy model is difficult.
This is the problem with monolithic privacy. Privacy is built into the blockchain protocol itself, and every application must operate according to the same model. If the model no longer meets the bank’s requirements, the institution may need a migration to another blockchain.
Modular privacy takes a different approach.
The bank can add only the controls it needs. It may begin with a policy engine and private RPC access. Later, it can introduce a role-based explorer, regulatory dashboards, selective disclosure, or zero-knowledge assets.
If one module needs to be upgraded or replaced, the underlying ledger can remain unchanged.
But Who Actually Benefits From It?
Commercial banks benefit because they can issue tokenized deposits or settle assets without exposing their customers, balances, and transaction activity to every network participant.
Central banks and financial market infrastructures benefit because they can operate shared networks while giving each member a controlled view.
Payment networks benefit because competing institutions can use common infrastructure without revealing sensitive commercial data.
Regulators or auditors may benefit because this confidentiality does not prevent oversight. They can receive evidence under clearly defined disclosure rules.
Privacy in an institutional blockchain generally operates across four layers.
We have a detailed article explaining these 4 layers of privacy. Give a read to get the complete picture.
Now let’s get back to where we left.
The important thing here is that no single layer solves everything.
Permissioning the network does not automatically hide asset activity. Encrypting an asset does not decide who can call a smart contract. A private explorer does not govern raw RPC access.
Modular privacy allows these layers to work together without turning them into one inseparable system.
How Does a Modular Privacy Layer Connect to a Chain?
Well, it sits between the applications and the blockchain.
Whenever a user, wallet, internal system, or external application wants to interact with the ledger, the request first passes through a governed endpoint.
Let us say a treasury employee wants to transfer a tokenized deposit.
The employee sends the transaction from the bank’s application. Before the request reaches the blockchain, an identity-aware gateway checks who is making the request. It checks whether that person can use the selected wallet, whether the wallet can interact with that smart contract, and whether the requested function is permitted.
If the transaction crosses a predefined limit, the system may also ask for a second approval.
The read process works in a similar manner.
When a user requests blocks, transaction receipts, events, logs, or contract data, the privacy layer checks the user’s role before returning the information. An operations employee, a compliance officer, another participating bank, and a regulator may query the same network and receive four different views.
The underlying blockchain does not need to be rewritten.
There is no need to introduce a new consensus mechanism. There is no requirement to fork the network. And the bank does not have to migrate its existing contracts and assets simply to introduce better visibility controls.
When stronger confidentiality is needed, cryptographic modules can also be added. These modules can hide transaction amounts or counterparties while allowing the network to verify that the transaction is valid.
So, the blockchain continues to maintain shared truth while the modular privacy infrastructure decides how much of that truth each participant is allowed to see.
The 7 Privacy Modules Banks Need the Most
Banks may eventually use many privacy controls, but the following seven modules address the most common institutional requirements.
1. Policy and Control Plane
The policy and control plane is the brain behind the privacy infrastructure.
It defines who can read ledger data, submit transactions, call particular smart-contract functions, approve sensitive operations, change privacy rules, and access administrative tools.
Without a central policy layer, privacy rules often become scattered across wallets, applications, dashboards, and smart contracts. One application may apply a rule correctly while another may unknowingly offer a way around it.
The control plane creates one governed source for these decisions.
For example, it can allow a treasury user to initiate a transfer but require a senior officer to approve it. It can permit a regulator to inspect disclosed evidence without allowing the regulator to submit transactions.
Every other privacy module follows the rules defined here.
2. Private RPC Controls
RPC is the doorway through which applications communicate with a blockchain node.
If participants receive unrestricted RPC access, they may query blocks, logs, traces, receipts, contract states, or event streams beyond what their role requires.
A private RPC module places an identity-aware gateway in front of the node. It checks every request and decides which RPC methods, contracts, wallets, and data streams the caller can access.
One institution may be permitted to read only events connected to its own contracts. A network operator may see system health information but not confidential asset details. An approved application may submit transactions but be prevented from requesting sensitive traces.
In simple terms, the private RPC module ensures that access to the network does not automatically become access to the entire ledger.
3. Private Explorer
Block explorers make blockchain activity easy to search and understand.
That convenience can also become a privacy problem.
A standard explorer may display every address, transaction, block, token movement, and smart-contract event available on the ledger. This is acceptable for many public networks, but certainly not for a banking network where competitors and service providers share infrastructure.
A private explorer gives each user a role-based view.
A bank sees its own relevant transactions. A counterparty sees the settlement involving it. An auditor sees the records included in an audit assignment. A network operator sees operational activity. Other participants do not get access merely because the data exists on the shared ledger.
The explorer follows the same policies as the rest of the privacy stack, closing an otherwise very convenient window into confidential information.
4. Audit Dashboards
Banks cannot simply say that a transaction happened correctly.
They must be able to prove it.
Audit dashboards provide controlled and evidence-backed views for compliance teams, auditors, supervisors, and reconciliation teams.
Instead of exporting raw blockchain data and arranging it manually every time, the bank can create repeatable dashboards for specific responsibilities. A compliance officer may see transaction status, approval evidence, policy decisions, and disclosed asset information. An auditor may see records for a selected institution and period. A supervisor may see the evidence required for a regulatory review.
The information still comes from the ledger, but the dashboard presents only what the reviewer is authorized to view.
So, privacy in this case does not remove accountability. Instead, it makes accountability more structured.
5. Selective Disclosure
There are situations where transaction information must remain confidential from network participants but available to an authorized regulator.
Selective disclosure makes that possible.
The system can keep amounts, counterparties, or supporting information hidden during normal network activity. When a valid regulatory or audit requirement comes up, the designated authority can receive the necessary evidence under predefined policies.
This does not mean giving regulators unrestricted access to everything forever.
Disclosure may apply to a particular transaction, participant, asset, time period, or investigation. The request and the information released can also be recorded for accountability.
6. ZK Tokens
Access controls decide who can read data. But they do not change what is recorded on the ledger.
This becomes important when the transaction itself must remain confidential.
ZK tokens use zero-knowledge proofs to hide sensitive information such as transfer amounts or counterparties. At the same time, validators can verify that the transaction follows the rules without seeing the hidden information.
The network will verify that the sender really owns enough tokens, or no tokens were created illegally, and that the transfer is valid. But unauthorized observers do not learn the confidential details behind the proof.
ZK tokens can support private minting, transfers, deposits, withdrawals, and burning of both fungible and non-fungible assets.
ZK tokens can be useful for tokenized deposits, institutional stablecoins, treasury transfers, and cross-border settlement where exposing balances and counterparties could create serious commercial and security risks.
7. Custom ZK Circuits
Standard confidential transfers cannot address every banking workflow.
Sometimes an institution needs to prove a very specific condition without revealing the underlying information.
A bank may need to prove that a customer passed an eligibility check without publishing any of the customer’s private details. An end user may also need to prove that a transaction remains within an approved limit without revealing the exact amount. Two institutions may need to confirm that settlement conditions were satisfied without exposing every part of the agreement.
Custom ZK circuits encode these business-specific rules.
The blockchain verifies the resulting proof and confirms that the required conditions were met. The confidential information used to produce the proof does not have to be published.
This allows privacy to move beyond hiding transfers and become part of compliance, settlement, eligibility, and operational workflows.
How a Shielded Institutional Transaction Works
Now, let us put these modules together.
A bank initiates a tokenized deposit transfer to another institution on a shared Hyperledger Besu network.
The bank’s operations user begins the transfer through an internal application. The request first reaches the private RPC gateway, where the user’s identity, wallet permissions, smart contract, and requested function are checked against the policy and control plane.
Suppose the amount crosses an internal threshold. The policy engine then routes the transaction to an authorized officer for approval.
After approval, the transaction is prepared as a ZK token transfer. The shared ledger receives the transaction and its zero-knowledge proof. Validators confirm that the transfer is valid without being shown the confidential amount or unnecessary counterparty information.
Once settlement is completed, visibility is also separated according to role.
The receiving institution sees its side of the transfer. The sending bank’s operations team sees the transaction in its private explorer. The compliance team receives the required evidence in its audit dashboard. Unrelated network participants see no meaningful transaction details.
If a regulator later requests evidence, selective disclosure reveals the approved information under the established policy.
One transaction has taken place, but every participant has received a different and appropriate view of it.
Integrate Zeeve Tegaris as Modular Privacy Infrastructure
Zeeve Tegaris brings these privacy controls together as a modular infrastructure for banks, financial institutions, FMIs, and fintech companies.
It can be deployed with Hyperledger Besu, any enterprise EVM chain, private Layer 1 networks, public-permissioned chains, or ZK rollups.
A bank can begin with the policy and control plane, private RPC, and role-based explorer. It can later add audit dashboards, selective disclosure, ZK tokens, or custom circuits as its use cases become more advanced.
Tegaris addresses privacy across the application, network, asset, and ledger layers while allowing each control to remain independently adoptable.
So, institutional blockchain privacy does not have to mean building another blockchain.
It can mean keeping the network you already trust and adding the right privacy controls, module by module.
