Banks have run blockchain networks in production for years now. JPMC and Citi’s private ledgers are good examples. But most of that activity has involved one institution and simple use cases where money movement is mostly internal.
That has changed now. SWIFT’s blockchain-based shared ledger is ready for use with seventeen banks preparing for live tokenized deposit transactions. A group of large US banks has also built a network to clear tokenized deposits, which The Clearing House will operate from early 2027. Very recently, it was announced that around 21 global major financial institutions from five regions are launching a USD stablecoin in H1 2027.
Networks like these need several competing institutions to transact on the same infrastructure. But that raises a question a single-bank ledger never had to answer before. How is privacy handled for each institution? Not permissioning. Permissioning is something we solved years ago.
Zeeve Tegaris is a modular privacy infrastructure built to answer that question. This article covers the problem Tegaris solves, its main features, the four privacy layers it works across, and a lot more.
What Problem Does Tegaris Solve? Why Do Banks Need a Privacy Solution Like This?
Okay, so what we were saying is most bank blockchain deployments to date have improved efficiency inside one institution. They deploy the ledger, run every node themselves, and give clients or internal teams access through an application. That bank is the only real party on its own network. But honestly, a network like this has stronger integrity guarantees, but it gives no second institution independent assurance, because there is no second institution actually on it.
Banks accepted this for years because the use cases in front of them did not require more, and this pattern is still the majority of live activity, concentrated where the parties involved sit inside a single bank or a tightly governed bank-run network.
Source: BCG and Anchorage Digital Report, June 2026
That is changing. Multi-bank tokenized deposits, stablecoins, tokenized funds, repo, and cross-border settlement all require more than one institution transacting on shared infrastructure. If you’re thinking about interoperability problems, banks have largely answered that by forming consortium networks, where an FMI, ACH, or a group of leading banks stands up a shared chain, and everyone uses it.
But what does “participating” on that network actually mean for each bank?
It is easy to assume a consortium network already gives its member banks the privacy they need, since the network is permissioned and every member appears involved. But permissioning decides who is allowed to join; it says nothing about what each member can see once inside. In most live multi-party deployments today, participating banks hold application-layer access only. They log in, submit instructions, and view their own activity through an interface, while the entity operating the network runs the nodes, the validator set, and the ledger itself.
There is a reason banks accept this. On a standard shared ledger, every institution that runs a node sees every transaction written to it, and no bank will accept that exposure. Permissioned systems were designed so that one entity can observe everything on the ledger. Here’s what the IMF July 2026 Note says about it,
“It is also fair to say that permissioned systems do not really solve privacy-related questions. They are often designed such that one entity can observe everything, and users must trust that this entity neither exploits its privileged position nor becomes compromised by a malicious third party.”
To capture blockchain’s real potential, banks need true network-layer access. What we mean by this is they will run validators themselves, hold an independent copy of the ledger, and verify transactions directly, without losing the confidentiality and compliance a regulated institution requires.
That is the gap Tegaris closes. It gives each participating institution the controls needed to hold a genuine network-layer position, with confidentiality and supervisory access built into the deployment.
What Are the Key Features of Zeeve Tegaris?
The first feature of Tegaris is full-stack privacy. Because blockchain does not follow a single, monolithic architecture, each layer of the stack carries its own risk. Application access, infrastructure participation, transaction contents, and contract execution each expose different risks if left uncontrolled. Tegaris is built with dedicated controls at each of these layers. We will come to this shortly.
The second feature is modularity. Every bank doesn’t need the same privacy setup. Even one bank may need different controls for different projects. An internal asset registry may require strict application access but no confidential token transfer. On the other hand, a multi-bank settlement use case may need private balances, hidden amounts, selective disclosure, and private contract execution. Tegaris lets an institution select the required modules as the needs arise. It can begin at the application layer, add asset privacy when token transfers start, and introduce ledger layer privacy controls when more complex workflows move on-chain. So privacy can grow with the use case.
The third one is policy-driven confidentiality. Tegaris is built for banks, regulated fintechs, and AMCs, where privacy cannot turn into opacity. These institutions need confidentiality from competitors and unauthorized participants. But they also need transparency to stay compliant with regulations. Tegaris uses roles, permissions, ZK proofs, and selective disclosure, to name a few, to create these separate views.
The fourth feature is EVM-agnostic deployment. Tegaris works across all EVM environments. Whether it’s a Besu chain, enterprise rollups, a ZK chain, private L1S, any public-permissioned chain, or even a public chain, Tegaris can integrate with all of them. So a bank can adopt privacy without locking into one blockchain stack, vendor, or deployment model.
How Does Tegaris Work? The Four Layers, Various Modules, and Stack-Agnostic Deployment
Tegaris divides institutional blockchain privacy into four layers. The layers complement one another, but an institution does not need to deploy all four on day one.
| Privacy Layers | What it controls | Tegaris Enabled Requirements |
| Application layer | Who can communicate with the ledger, what they can read and which actions they can perform | Role-based access, private RPC, scoped explorer views, contract access policies, event filtering, approval workflows and audit trails |
| Network layer | Who can operate infrastructure, join the peer network and participate in consensus | Permissioned validators, peer governance, node onboarding, mTLS, private infrastructure access and operator-level controls |
| Asset layer | Which details about value transfers become visible and under what policy | Confidential balances, hidden amounts and counterparties, private token transfers, selective disclosure and policy-controlled assets |
| Ledger layer | Which parties can see workflow state and smart-contract execution | Private sub-ledgers, privacy-scoped contracts, bilateral workflows, private L1 domains and ZK rollups |
Different modules apply these controls at required access points. For example, Tegaris Policy and Control Plane defines who can read state, submit transactions, or call contract functions. Private RPC controls work as an identity-aware gateway that enforces those rules on every JSON-RPC request before it reaches a node. The Private Explorer gives each participant a role-scoped operational view.
The ZK Tokens module covers confidential minting, burning, and transfers for any asset. Selective Disclosure module makes it easy to share proofs for audit and reporting. Custom ZK Circuits can extend this same approach for eligibility checks, private settlement logic, and workflow validation when required because standard transfers do not cover them.
Because these controls sit above the chain, the architecture decision and the privacy decision are always separated. An institution can run application-layer privacy on a base permissioned network and add asset-layer privacy on an L2. It can deploy all four layers on a single Besu network instead if that’s required. If changing the underlying chain later becomes necessary, that can also be done, since the privacy layer was never permanently tied to one protocol.
And none of these layers require every layer on day one. Application-layer first suits networks whose immediate need is controlling access. Asset-layer first suits programs where the token itself must be confidential from the start. Base-layer-plus-L2 privacy suits architectures where different tiers carry different visibility requirements. Full-stack privacy suits shared networks where every single boundary has to be airtight, which is usually the final goal for a mature group of partner banks.
Let’s Visualize an Example of What Tegaris Can Enable
Let’s suppose three banks are using a shared network for tokenized deposit settlement. Bank A, B, and C.
In a conventional sponsor-operated model, the network operator runs the blockchain infrastructure. Each bank logs into an application, submits instructions, and receives the information that the application permits it to see.
As mentioned before, in this model, banks use a blockchain-based service, but they do not independently validate the underlying ledger. Every participating bank here has a governance seat in the consortium to make the arrangement look democratic.
| A restricted-access model | A Tegaris-enabled model |
| The FMI/network operator runs the blockchain infrastructure. Banks connect through applications or APIs. | The FMI/network operator can remain the network coordinator while approved banks operate nodes or validators where the governance model requires it. |
| The operator provides curated views and centrally manages participant access. | Each institution receives private RPC access, a role-scoped explorer and policy-controlled contract permissions. |
| Privacy depends heavily on centralized data handling and limited infrastructure participation. | Asset and ledger controls restrict transaction details even when more institutions participate at the network layer. |
| Regulators receive reports or access through a separate process. | Selective disclosure and audit dashboards provide policy-based supervisory views. |
A consortium may want each bank to operate a validator. That creates shared verification, but it can also replicate sensitive records across the member nodes.
With a Tegaris-enabled design, the consortium can separate verification from unrestricted visibility.
Now assume a corporate client of Bank A sends a tokenized-deposit payment to a corporate client of Bank B.
- The Policy and Control Plane authenticates the submitting user or workload and checks whether it may call the payment contract.
- The Private RPC gateway filters the request and blocks ledger data if the caller is not allowed to query.
- A ZK token workflow protects the amount, balances, and other defined transaction details. Validators verify the proof instead of reading the protected values.
- The ledger layer controls will restrict transaction data strictly to Bank A, Bank B, and approved operators. Bank C cannot see any details here just because it runs the same infrastructure.
- The permitted explorer views show each bank only what it needs to see, while auditors get read-only access to specific proof according to the disclosure policy.
To be clear, Tegaris here does not decide how many validators a consortium must run or which party should operate them. It only provides privacy controls that make a more distributed operating model practical.
Some Use Cases Tegaris Can Support
Tokenized deposits
Tokenized deposits represent commercial bank money on programmable infrastructure. Their usefulness increases when they can move across institutions and connect with other tokenized assets.
That shared nature can expose sensitive information. For example, payment amounts, counterparties, etc which should never be visible to every member of the group. Tegaris keeps these details strictly private while still letting internal bank teams and approved regulators see what they need.
Cross-border payments and remittance
International transfer networks reveal sensitive business clues, like which banks work together, customer activity spikes, or total cash flow. Competitors can easily use those trends to gain an edge.
Tegaris keeps the payment details strictly between the banks involved. Everyone on the network sees only what matches their specific role in the transaction.
Stablecoin use cases
Issuers, distributors, banks, payment providers and supervisors do not require identical visibility, right? A retail user may need privacy from other users. An intermediary may need information for compliance. A central bank or regulator may require a governed supervisory view.
Tegaris can support these layered responsibilities through policy-based access, confidential assets, and selective disclosure.
Tokenized funds and RWAs
Tokenized investment products carry investor information, allocation details, subscription and redemption activities. Putting the asset on a shared ledger should not publish the private business surrounding it.
Tegaris can protect investor and transaction data while allowing approved issuers, distributors, custodians, auditors and regulators to perform their respective functions.
Repo and collateral workflows
Repo transactions expose positions, funding behavior, collateral choices, pricing conditions, and counterparty relations. Some of this information must also be verified across institutions. Not every member of the network should see it. Right?
Tegaris uses private workflow state, hidden asset transfers, and selective data sharing. This makes the deal fully auditable for the two trading banks and their watchdogs, without putting sensitive deal terms in front of bystander banks.
Apart From Tegaris, What Else Does Zeeve Provide?
Privacy is one part of building institutional blockchain infrastructure. A very important part, yes, but still one part.
The institution must first choose an architecture. It must decide whether the use case belongs on Besu, an enterprise EVM rollup, a private Layer 1, or a hybrid kind of architecture. If an older blockchain network already exists, migration may be a bigger concern too.
Zeeve works with banks, financial market infrastructures, asset managers, and regulated fintech companies across these decisions. It provides architecture consultancy without forcing every institution towards one preferred protocol. The selected network can run in Zeeve-managed infrastructure, inside the institution’s own cloud account through Bring Your Own Cloud, on-premises, or in a hybrid environment.
Zeeve also supports the deployment and management of blockchain nodes and networks along with monitoring and ongoing operations support. Its infrastructure operates within ISO 27001 and SOC 2 Type II compliant environments. Expert-led migration support can help institutions move from legacy blockchain setups to a new infrastructure more easily.
Zeeve has years of experience deploying and managing blockchain networks for enterprises.
Talk to us for unbiased consultancy and privacy-enabled blockchain solutions.
