​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.

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 consortium may want each bank to operate a validator. That creates shared verificted 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.

It has studied the available enterprise blockchain frameworks, spoken to its technology team, and finally chosen Besu. And the choice makes sense. Besu-based architecture is already being used for Swift’s shared ledger, Citi Token Services, DTCC’s collateral platform, and many others.

So, is the difficult part over?

Well, it seems the difficult part is only about to begin.

Choosing Besu gives the bank a ledger. It does not automatically give the bank institutional privacy, core banking connectivity, or security controls.

All of that must still be designed, built, and operated.

This is where the difference between deploying Besu and implementing Besu for a bank becomes important. The first can be done by a capable engineering team. The second requires a complete financial infrastructure around the chain.

And that is where Zeeve comes into the picture.

The Problem with Basic Besu Deployments

Getting a few nodes online is not terribly difficult.

A team can configure a validator set, select QBFT or IBFT 2.0 consensus, connect the peers, and watch the network produce blocks. For a demo, this may be enough. For a regulated settlement network, it is only the starting point.

The trouble begins when questions start arriving from outside the blockchain team.

Who approves a new validator? Which member can read which transaction? Where are the signing keys held? How will an event on Besu reach the core banking system?

Besu, on its own, does not answer these questions.

An in-house implementation leaves every answer with the bank. The bank must assemble the architecture, harden the infrastructure, create the governance processes, connect the legacy systems, monitor the network, plan upgrades, and maintain an incident-response team. It also owns the complete attack surface across the infrastructure and integration layers. This is the layer where most of the issues happen. 

Here’s what the BCG & Anchorage Digital 2026 report says about it,

“Security concerns are a key gating factor: stakeholders are often constrained by uncertainty around technical vulnerabilities and attack vectors, and this is further exacerbated by the fact that banks are typically not native operators or experts in this domain.

As highlighted by recent incidents, vulnerabilities often emerge in low-level infrastructure and integration layers, not just application logic. The technology agenda should therefore prioritize resilience, security-by design, and reliance on proven architectures.”

Basic node hosting with just another provider does not take the problem much further. It may place the nodes on servers and keep those servers running, but the bank is often still left to handle the rest of the things. For example, banking integrations, privacy engineering, monitoring, and incident response.

This is why the sensible division of work is not difficult to see. A bank should retain the areas in which it has a lasting advantage, like its customer relationships, internal controls, client channels, and core banking systems. For blockchain orchestration and other digital-asset-native infrastructure, it can work with an external provider with mature expertise that already knows how the pieces fit together.

Again, this excerpt from the same BCG report needs an absolute mention here. 

Zeeve is built for this part.

Below are five reasons, broken down, on why Zeeve matters for a Besu implementation.

1. Institutional Privacy and Custom Controls

The words permissioned and private are often used together. That makes them sound like the same thing.

They are not.

Permissioning decides who may enter the network. Once inside, the participants may still hold readable copies of the same ledger. For a bank, that can expose balances, counterparties, contract state, or transaction activity to institutions that have no business seeing them.

It is much like allowing only approved people into a building but giving every person inside a key to every room.

Banking secrecy and client confidentiality require something more precise. The network must control not only who may join, but also who may see what after joining.

Zeeve provides this through Tegaris, its modular privacy framework. Instead of treating privacy as one piece, Tegaris applies it at four different layers.

At the application layer, it controls access to RPC endpoints, user actions, and explorer views. At the network layer, it governs validators, peers, and node onboarding. At the asset layer, zero-knowledge proofs can keep balances, amounts, and counterparties confidential. And at the ledger layer, smart-contract state can be limited to the participants who are supposed to see it.

Read More: The Four Layers of Blockchain Privacy: What Banks & Financial Institutions Need to Know

Though we said there are four layers, the bank does not have to begin with every privacy control at once. It can apply what the first use case requires and add stronger privacy controls as the network expands.

2. Bank-Grade Compliance and Security

A familiar temptation in new technology projects is to build the product first and deal with compliance once it works.

A bank does not have that luxury.

Its Besu infrastructure is expected to meet the same security standards as the other systems on which financial operations depend. The firewalls, access controls, logs, key custody, and evidence trails therefore cannot be loose pieces added later on unless it’s under a regulatory sandbox. They must exist underneath it from day one.

Zeeve provides an environment aligned with that requirement. Its infrastructure is ISO 27001 and SOC 2 Type II compliant and follows GDPR data rules. Enterprise firewalls, DDoS protection, role-based access control, and audit-friendly logging are part of the production setup.

Then there is the matter of keys.

Validator and treasury keys are not ordinary passwords. If their custody is weak, the rest of the network’s security becomes vulnerable. Zeeve integrates with enterprise key-management systems and bank-grade Hardware Security Modules (HSM), allowing the keys to remain within the bank’s approved custody perimeter.

This does not transfer the bank’s accountability to somebody else. Nor should it.

As a result, the compliance team keeps ownership of the controls. Zeeve provides the certified operating environment and the evidence trail that allows those controls to be reviewed.

That makes the arrangement workable. The bank here is responsible for its obligations without having to invent every piece of blockchain security infrastructure for itself.

3. Deployment Flexibility with BYOC, On-Premise, and Hybrid Options

Many technology products usually can start using the provider’s cloud.

For a bank, that instruction may be impossible to follow.

Data-residency requirements may determine the country in which infrastructure must run. Outsourcing rules may also apply, which will define which party can control it. Their internal policy may also require sensitive workloads to remain inside the bank’s own cloud account or physical data center.

So, what happens if the Besu infrastructure provider supports only one deployment model?

The bank is forced to redesign its policy around the technology or abandon the technology altogether.

Zeeve brings a solution to this. With Zeeve Bring Your Own Cloud (BYOC), Besu nodes run inside the bank’s existing AWS, Azure, or GCP account, under its own governance and billing. With an on-premise setup, the nodes remain on the bank’s physical infrastructure. And with a hybrid deployment, the network can span both environments while Zeeve orchestrates its monitoring, deployment, and upgrades.

This flexibility becomes even more useful in a consortium.

One member may be permitted to use a public cloud. Another may need to keep its validator on-premises. A third may have a separate regional requirement. Each institution can operate within its own regulatory boundary without breaking the network into three separate systems.

In a multi-bank network, this small-sounding change may be the change that makes participation possible.

4. Legacy Financial Integration and Asset Tokenization

A transaction may settle perfectly on Besu and still create problems if proper reconciliation is not done.

Because the core banking system may not know that it happened. The general ledger will have to wait for a separate entry. The fraud-monitoring system will also never receive the event. And the operations team may have to reconcile the same transaction by hand.

This is why integration with a core banking system (CBS) is a high-priority task. A production blockchain ledger must communicate with these CBS through which the institution keeps accounts, checks customers, monitors risk, and reports its financial position.

Zeeve offers integrations that connect every Besu event with core banking systems, KYC and AML tracking, and fraud-monitoring tools. Any event recorded on the blockchain can therefore move into the bank’s existing operating stack without creating a parallel manual process.

There is an asset side to this problem as well.

A Besu chain can use the Cosmos tokenization engine as well. And Zeeve, as a partner of Cosmos Labs and LF Decentralized Trust, can integrate both frictionlessly, giving banks a path to issue compliant tokenized assets on their permissioned networks. For connections outside an individual network, the Inter-Blockchain Communication protocol can be used. This allows a private banking ledger to transact with other independent financial ledgers without depending on one bridge provider.

That may not look urgent when a bank is building its first network. It becomes urgent when tokenized deposit systems, asset networks, and interbank settlement ledgers begin multiplying.

Apart from this, integration with other enterprise tools and systems is also possible with Zeeve.

5. 24×7 Operations

What’s most attractive about the word ‘deployment’?

It sounds kind of complete. Right?

‘The network has been deployed’.

Feels the project has crossed the finish line. So everyone can now move to the next important thing.

Except the network that has only just started its life.

From that point onward, it must remain available and continue working as usage changes. Problems must be noticed. Someone must know what to do when the network behaves differently from what was expected. Every alert needs to be investigated also.

Zeeve reduces that load in three ways.

First, One-click provisioning of Besu nodes deploys production-ready QBFT or IBFT 2.0 consensus configurations in minutes. This saves a lot of time.

Second, full-stack dashboards monitor node health, validator performance, block production, RPC activity, logs, and alerts. They are backed by round-the-clock incident response and strict enterprise SLAs.

Third, automated upgrade orchestration handles node patching and Besu client updates across the network without any downtime or network forks.

So, How a Production Besu Architecture Changes with Zeeve’s Full-Stack Infrastructure

At the center of the architecture, Besu remains Besu. There are issuer and counterparty validators, custodian nodes, regulated member nodes, and observer nodes. They participate through a permissioned membership model and reach consensus using QBFT or IBFT 2.0.

Above that network layer, there is the platform logic layer, where smart contracts, all use cases, asset rules, and policies live. An API and integration layer connects that logic to application layers like bank portals, fintech platforms, or any partner interface.

Then there are systems that make the ledger safe and useful. Key management, HSMs, custody, KYC and AML services, identity and access management, and reporting come in this layer.

And around the complete stack sits the operating layer that brings in monitoring, alerts, incident response, logs, and SLA-backed support for BYOC or other cloud environments.

That is the architectural difference.

A basic setup places Besu on infrastructure. Zeeve places Besu inside a governed, connected, privacy-enabled, continuously operated banking system.

The result can support tokenized deposits, tokenized funds, and real-world assets, interbank settlement networks, or a Quorum-to-Besu modernization without forcing the bank to build every surrounding capability from the ground up.

Deploy Your Besu Chain with Zeeve

Besu is a sound choice for a permissioned banking network. But the client is only one part of the choice.

The network must still be designed for the institution, deployed within its infrastructure boundaries, governed across its members, and operated every hour that financial activity may occur.

Zeeve brings those responsibilities together through a four-stage model: Design, Deploy, Govern, and Operate.

Design establishes the architecture, validator model, consensus choice, privacy requirements, cloud strategy, and production plan. Deploy provisions the network across managed, BYOC, on-premise, or hybrid environments and connects the required key-management systems. Govern sets the member-onboarding process, validator approvals, permissioning rules, and network policies. Operate keeps the complete system monitored, patched, upgraded, and supported under an SLA.

So, if your bank is planning a tokenized deposit platform, an interbank settlement network, or a move from Quorum to Besu, choosing the client is a good beginning.

Choosing who will turn it into production infrastructure is the decision that follows.

Ready to map your use case to a production Besu architecture?

Talk to a Zeeve architect.

Let’s suppose five banks decide to work from the same building.

It is not an ordinary office building. It has one shared record room where every deal, payment, and movement of money is entered. Whenever one bank adds a new record, copies are made for the others too.

The banks like this arrangement because nobody can quietly change an old record. If Bank A says a payment happened and Bank B later denies it, the other copies settle the matter.

This shared record room is our blockchain.

Of course, the banks do not let anybody walk into the building. There is a guard outside with a list of approved names. Only the five banks, their chosen employees, and a few operators are allowed in.

This is a permissioned blockchain.

The building is closed to the public, so everyone calls it private. There is only one small problem. After passing the guard, a person can still see almost everything inside.

The record room is open. The screens in the hallway show recent activity. Copies of the records are kept in each bank’s office. Even a technician who came to fix one screen may find that the other screens are working perfectly well for him too.

So yes, the building has a gate. But does it have privacy?

Not really. At least, not yet.

Because permissioning answers who is allowed to enter the network? It does not answer what they can see once they are in.

That leaves four separate privacy jobs linked with different layers of blockchain architecture. 

Application level privacy, network level privacy, asset level privacy, and ledger level privacy. A bank may need two of these layers or all four. It depends on who shares the network and what kind of business is happening there.

Keep the building in mind. We will keep coming back to it.

Before privacy, understand what a blockchain exposes

A blockchain is usually spoken about like it is one machine. It is actually several things put together.

There are servers running the nodes. A network connects those nodes. Validators agree on the next block. The ledger keeps transactions and smart-contract state. Then there are all the tools people use to reach the ledger, such as wallets, RPC endpoints, APIs, explorers, indexers, and dashboards.

These tools do different jobs, but they also create different ways to see information.

A full/validator node keeps a copy of the ledger. An RPC endpoint answers questions about accounts and transactions. A block explorer puts the same information into a neat, searchable screen. An indexer copies blockchain data into another database so applications can search it faster. Smart contracts publish events, and other systems can sit there listening to them all day.

None of these tools are doing something wrong. They are built to make blockchain data available.

The trouble starts when the bank has not decided who the data should be available to.

Back to our building for a moment. Stopping strangers at the main gate is useful. But it does not help much if every room inside has a glass wall. Nor does putting a lock on one filing cabinet help if the same papers are being shown on a screen in the hallway.

Each privacy layer deals with a different opening.

Layer 1: Application privacy decides who can use which door

Suppose Bank A brings in a technology vendor to manage a payment application.

The vendor needs access to payment records. Fair enough. But it does not need to see Bank A’s treasury movements, client settlement history, and every contract being used by the other four banks.

Still, that can happen quite easily.

Most people do not interact with a blockchain by reading raw blocks. They use an explorer, a dashboard, an API, or some business software connected through an RPC endpoint. These are the doors through which ledger data is normally reached.

If every door opens into the whole building, the guard at the entrance is not doing enough.

A standard JSON-RPC endpoint may answer a query about any account or transaction. A normal block explorer may give every user the same view. An indexer may copy the complete ledger into a database. Event subscriptions may send contract activity to any system that has been connected.

No hacking is needed here. A vendor can see too much simply because nobody narrowed its access. A support engineer may be checking a failed node and end up browsing customer transactions. An analytics company hired for one report may quietly receive a copy of data from several other business lines.

Application-layer privacy is meant to stop this kind of overexposure.

Role-based access decides what each employee, vendor, application, or auditor is allowed to read. A private RPC gateway applies those rules whenever someone sends a request. The explorer can show different views to different people instead of treating every signed-in user like the owner of the place.

The same idea applies to smart contracts and event feeds. A user may be allowed to view a contract but not call an important function. An indexer may receive payment events but not treasury events. An auditor may receive a wider view, with every visit recorded in an audit log.

A simple diagram that shows the vulnerabilities and how this is being addressed. 

In our building, application privacy is the set of keys and access cards used after a person has entered. The vendor gets the key to the payment office. It does not get one giant master key because that was easier to configure.

For an internal blockchain run by one bank, this layer may do most of the privacy work. It is also important when outside vendors, auditors, support teams, or several business units use the same network.

But there is a limit.

An access card can stop someone from opening a room. It cannot make that room invisible to another bank that already has a complete copy of the records in its own office. For that, we have to look at the network and the ledger itself.

Layer 2: Network privacy decides who is allowed in the building

Most institutions start with network privacy.

The network has an approved set of validators. New nodes go through an onboarding process. Old members are removed when they leave. Peer rules decide which nodes can connect to one another, and mutual TLS helps confirm that each node is speaking to the right machine rather than an impostor.

The infrastructure can also be kept away from the public internet. Operators, cloud providers, and managed-service teams can be placed under clear access and confidentiality rules.

All of this matters. A bank should know who is running the machines that hold its records. A consortium should know which member is allowed to validate transactions. A regulator will probably want to know too.

But let’s return to the building.

The guard outside checks names carefully. He keeps strangers away. He even records what time every approved person enters and leaves.

That makes the building secure from outsiders. It says nothing about what the five banks can see about one another.

This is why the line “we use a permissioned blockchain, so the data is private” is incomplete. Permissioning is membership control. Once a member joins and runs a full node, it may receive the same ledger as everyone else.

For one bank running all the nodes (a private ledger), that may be acceptable. For five competing banks (a shared network/ consortium), it is a different story. Each member could watch the others’ activity, not because it broke any rule, but because receiving ledger data is part of running the node.

Blockchain replication is the reason members can verify the history instead of trusting one central record keeper. But replication and confidentiality pull in different directions. If every participant receives the same information, every participant can potentially study it.

Network privacy gives the building a proper gate, and no institutional blockchain should be without one. It just does not put curtains on the windows inside.

Layer 3: Asset privacy decides what is inside the payment envelope

Now suppose Bank A sends money to Bank B.

The payment record shows the sender, the receiver, the asset, and the amount. Banks C, D, and E are not part of the payment, but their nodes may still receive the record.

One payment may not tell them much. After six months, they can begin to notice patterns.

They may see that Bank A sends large amounts to Bank B every Friday. They may notice its treasury moving funds at certain times of the month. They may work out which corridors are busy, which counterparties trade often, and where liquidity appears to be tight.

The ledger slowly becomes a map of Bank A’s business.

This is where asset privacy comes in. It hides the value being moved: the balance, the amount, the type of asset, and sometimes the identities of the parties.

One way to do this is with a zero-knowledge proof.

Suppose Bank A puts a payment instruction in a sealed envelope. The other banks cannot read the amount. However, attached to the envelope is a special proof showing that Bank A has enough money, the numbers balance, and the payment follows the agreed rules.

The network only can check the proof, but can’t read any private numbers inside the envelope.

That is roughly what a zero-knowledge system does. It allows the network to confirm that a transaction is valid without showing every detail used to create it.

This can mean confidential balances, hidden transfer amounts, private counterparties, and confidential minting or burning of tokens. It can also cover deposits and withdrawals when tokenized money moves in or out of the network.

There is an obvious question here though. If the transaction is hidden, how does an auditor verify it?

The answer is selective disclosure. The envelope is not sealed forever and for everyone. A regulator, auditor, or compliance officer can be given the right to inspect particular evidence under an agreed policy following the standard messaging standards. The other banks still do not get to look inside merely because they share the network.

Banks need asset privacy when the thing on the blockchain is money, or close enough to money that its movement reveals commercial information. Tokenized deposits, settlement assets, stablecoins, cross-border payments, and treasury transfers all fall into this area.

So now our shared building has a guard, access cards, and sealed payment envelopes. It sounds quite private.

We are still missing one room.

Layer 4: Ledger privacy decides who can see the meeting

A financial deal is rarely just a payment.

Take a repo between Bank A and Bank B. First, the parties agree on terms. Then collateral is locked. Cash is settled. The position is managed for a period, and later the whole thing is unwound.

Asset privacy can hide the amount of money in this deal. But the other banks may still see that a repo contract was used, which addresses interacted with it, when the steps happened, and how the contract changed from one stage to the next.

They cannot read the payment envelope, but they can stand outside the meeting room, see who went in, hear when people move around, and watch them leave with a collateral file.

Sometimes that is enough information.

A competitor may not know the exact terms, but it now knows that Bank A and Bank B completed a certain kind of transaction at a certain time. In institutional markets, that is not harmless metadata as it can reveal a trading relationship or a funding need.

Ledger-layer privacy makes the meeting itself private. The contract state and its execution are visible only to the parties involved and to others who have a proper reason to see them.

There is more than one way to arrange this.

• A private sub-ledger lets a smaller group of participants keep a shared record that the others cannot read.

• A private Layer 1 gives a defined group its own chain or chain segment.

• A ZK rollup carries out activity away from the base chain and sends back proof that the result is correct.

• A bilateral workflow keeps contract state between the two parties doing the deal.

• Privacy-scoped execution lets the wider network verify that a contract ran correctly without giving everyone the details.

The technical design may change from one platform to another. The purpose is the same: sharing a blockchain should not mean sharing every business process happening on it.

This matters in syndicated lending, where lenders may take part in the same facility without seeing one another’s private terms. It matters in repo and collateral management. It matters in OTC trade confirmation, where two parties do not want the rest of a consortium reading the history of their deal.

Asset privacy hides what was in the envelope. Ledger privacy closes the meeting-room door.

That is the difference.

Putting the four layers together

Our imaginary bank building now looks a little more sensible.

The guard at the main gate decides who belongs to the network. That is network privacy.

Access cards decide which rooms and screens each person can use. That is application privacy.

Payment details travel in sealed envelopes that can still be checked for validity. That is asset privacy.

Private deals happen in rooms where only the relevant parties can see the process. That is ledger privacy.

Here is the same idea without the building:

Does a bank need all four layers?

Not always.

If one bank runs an internal blockchain for its own teams, application access and network controls may be enough. There are no competing banks operating nodes, so hiding every transaction with cryptography may create more work than value.

If several banks share a tokenized deposit platform, asset privacy becomes much more important. Members may trust one another to follow the network rules without agreeing to share their balances and payment history.

A consortium settlement rail carrying real volume may need all four layers. It has several node operators, many users, outside vendors, sensitive transactions, and regulators who require access of their own. A single privacy control will not cover all of that.

The blockchain platform changes the starting point too.

Networks such as Canton include privacy in the protocol. That gives institutions a ready-made privacy model, which is useful when the use case fits it. The same model may be less flexible when a bank wants very different privacy rules for different products.

Custom chains offer more freedom. A bank may build with Hyperledger Besu, a dedicated Cosmos-based Layer 1, an EVM chain, or a ZK-powered Layer 2. These networks often start with permissioned membership. The remaining privacy controls still have to be designed or added.

The better approach is to decide early which information may become sensitive as the network grows. Then the privacy layers can be added in a sensible order.

A few common questions

Isn’t a permissioned blockchain already private?

It is private from people who are not allowed to join. It may still be transparent to the approved members running nodes. Permissioning tells you who is inside the building, not what they can see there.

Can a regulator audit a confidential transaction?

Yes. Selective disclosure can give a regulator or auditor access to the required evidence without showing the same data to every network member. A zero-knowledge proof can also confirm that a transaction followed the rules while keeping its private details hidden.

Does every bank need ZK proofs?

Not really. If it’s a private ledger and the main concern is employee or vendor access, standard policy controls are sufficient. ZK is useful when it’s a shared infrastructure but should not see one another’s balances, amounts, or workflows.

Which layer should come first?

Start with the place where information is leaking. If too many employees and vendors can query the chain, begin at the application layer. If competing institutions can read one another’s payments, asset privacy is the urgent problem. Network controls are a basic requirement in both cases.

Where Zeeve Tegaris fits into this

Zeeve Tegaris, the Zeeve Privacy Layer, is built around these four separate privacy needs.

The suite is modular and can be integrated with any chain type.The modules cover access governance, identity-aware private RPC, role-scoped private explorers, and ZK-based confidential tokens. They also include selective disclosure for auditors and regulators, custom ZK circuits for business-specific workflows, and audit dashboards for oversight.

Tegaris works across EVM-based environments, including Hyperledger Besu, custom EVM chains, ZK rollups, public-permissioned networks, and hybrid architectures.

So an institution does not need to abandon the network it already has just to improve privacy. It can look at the missing walls and add them where they are needed.

And that is probably the easiest way to begin.

Who is standing at the gate? Who has keys to each room? Which payment details are exposed? Which meetings can other members watch?

Once those four questions are answered honestly, the privacy gaps are usually not difficult to find.

Talk to Zeeve blockchain experts to discuss your requirements.  

Every regulatory regime for bank-issued digital money starts with that question. Because the answer only determines whether a token qualifies for deposit insurance, how it’s treated on the balance sheet, and who is allowed to issue it.

But banks are not waiting for full global convergence. Approximately two-thirds of banks are developing or discussing tokenized deposit solutions for corporate clients, per the American Banker 2026 survey. 

At the same time, regulators from Washington, EU, UK, Singapore, Hongkong and other countries have published rules, proposals, and pilot frameworks that differ in structure and scope.

This article maps how major countries treat tokenized deposits, compares their positions on a scorecard for risk and compliance executives, examines their blind spots, and concludes with an implementation roadmap for banking leaders.

How Do Different Countries Regulate Tokenized Deposits?

United States

US has taken a technology-neutral stand for tokenized deposits with a clear boundary for stablecoins. So in the US, a deposit recorded on a distributed ledger is still a deposit, and the ledger does not change its legal character.

Source: federalregister.gov/documents

The Federal Deposit Insurance Act’s definition of “deposit” is technology-neutral, and tokenized forms do not constitute a separate category under FDIC regulation. In April 2026, the FDIC Board approved a proposed rulemaking that would codify this directly, stating that a financial product meeting the statutory definition of a deposit remains a deposit regardless of the technology used to represent or record it, and proposing that tokenized deposits receive the same deposit insurance treatment as conventional deposits. 

This is reinforced by the GENIUS Act as well. It has created a separate federal framework for payment stablecoins and excluded tokenized deposits from that category. Stablecoin holders are explicitly barred from earning yield under GENIUS; tokenized deposit holders are not, because the underlying claim is still a bank liability, not a redemption right against a reserve pool. 

But there are a few edge cases that still need clarification. For example, clarity on BSA/AML checks specific to tokenized deposit networks, or how pass-through insurance concepts apply when a wallet provider is there between the bank and the end holder. 

In practice, US banks are currently using private, permissioned networks. For internal transfers, banks like JPMorgan and Citi use their own private ledgers. For transfers between different banks, a shared platform (like The Clearing House) coordinates the transactions. But the final settlement still runs through the traditional central bank RTGS system.

European Union

The EU took a different legal approach from the US to regulate tokenized deposits. The US has updated its banking rules to fit digital tokens. But the EU has created its new crypto law (MiCA) and explicitly left tokenized bank deposits out of it. Instead, the EU keeps them under traditional banking laws. 

“Accordingly, this Regulation expressly excludes from its scope crypto-assets that qualify as financial instruments as defined in Directive 2014/65/EU, those that qualify as deposits as defined in Directive 2014/49/EU of the European Parliament and of the Council (7), including structured deposits as defined in Directive 2014/65/EU…” 

Source: eur-lex. europa.eu/legal-content (Article 2, Paragraph 4, Clause (b))

This allows tokenized deposits to skip the heavy regulatory costs and capital rules that MiCA puts on electronic money tokens and asset-referenced tokens like stablecoins.  

So how a bank designs the token will determine if it gets deposit insurance or not.

• To get Deposit Status (Protected): The token must be tied directly to a traditional bank account. When a customer moves money to the blockchain, the bank debits their regular bank account and credits their digital token balance. Because it is backed by a real account on the bank’s core system, it counts as a regular deposit and gets deposit insurance. 

• To be treated as Crypto/EMT (Not Protected): If the token exists only on the blockchain ledger, with no connection to a traditional bank account, the EU views it as a “bearer instrument” (like physical cash or a stablecoin). The EU classifies this as an Electronic Money Token (EMT). It does not get deposit protection and faces stricter crypto rules. 

This is a meaningful design constraint. If your bank wants to offer tokenized deposits that keep their regulatory deposit status and insurance in the EU, you cannot build freestanding crypto tokens. You must architect the system so every blockchain token is anchored to a traditional, off-chain bank account. 

To give banks a supervised space to test without waiting for final regulation, the EU created a legal sandbox called the DLT Pilot Regime that lets institutions trial tokenized delivery-versus-payment and settlement rails. This was started in March 2023 and will be valid for 6 years.

Source: EY

United Kingdom

UK banks are operating tokenized deposits under existing banking permissions until a separate framework is finalized. The UK is building the framework live, through the Digital Securities Sandbox (DSS),  Great British Tokenized Deposits (GBTD) pilot, and a few other initiatives mentioned below.

In the Digital Securities Sandbox, the central bank’s guidance makes it explicit that tokenized deposits can be used as a payment asset within it, alongside other low-risk, regulated forms of private money, and that this approach aligns with the CPMI-IOSCO Principles for Financial Market Infrastructures. Sixteen firms, including HSBC, Euroclear, and the London Stock Exchange Group, are preparing to launch live tokenized settlement services through this sandbox from late 2026. 

Here’s what Sarah Breeden, Deputy Governor for Financial Stability said in her May 2026 speech,

“The sandbox will enable markets in these securities to grow up to a set size over the next five years, during which time the Bank, FCA and HM Treasury intend to learn from firms’ activity and, subject to that, to determine the new, permanent regulatory regime for the trading and settlement of digital securities.”

So, this controlled, five-year window gives financial institutions the operational predictability needed to scale their digital asset testing .

On the commercial banks’ side, the main vehicle is the Great British Tokenized Deposits (GBTD) pilot, coordinated by UK Finance with Barclays, HSBC, Lloyds, NatWest, Nationwide, and Santander. It runs live transactions through mid-2026 across three use cases. These are marketplace payments, remortgaging, and digital asset settlement. 

Source: UK Finance

The GBTD pilot connects into the Bank of England’s Digital Securities Sandbox work on cross-ledger settlement.

The UK is also coordinating internationally. Very recently, HM Treasury (UK) and the US Treasury have published the first ten recommendations of the Transatlantic Taskforce for Markets of the Future. The recommendations endorse a multi-money ecosystem in which stablecoins, tokenized deposits, and other forms of digital money coexist and interoperate. They are non-binding, and they indicate the direction both regimes intend to take. 

Source:  HM Treasury / US Treasury joint publication

Switzerland

Switzerland does not have any separate law for governing tokenized deposits. Hence the 2024 FINMA guidance is used here. Under FINMA’s stablecoin guidance, a fiat-pegged token with a fixed 1:1 redemption claim against the issuer is treated as public deposit under banking law, and accepting public deposits on a professional basis requires a Swiss banking licence.

Because Switzerland uses traditional banking rules, a company that wants to issue a fiat-pegged token has only two choices:

• Option 1 : You get a full Swiss banking license. The tokens you issue are treated as tokenized bank deposits. They are fully regulated under standard banking laws and automatically covered by the Swiss deposit insurance scheme (up to CHF 100,000).

• Option 2: If you are a FinTech and don’t have a banking license, you cannot hold the customer’s cash backing the token on your own beyond a limit. You must take all that cash and deposit it into a licensed Swiss bank. That bank must then issue an irrevocable default guarantee.

If option 2 is taken, the token holders are not protected by the government’s deposit insurance scheme if the fintech goes bankrupt. Instead, the private bank’s default guarantee substitutes for deposit insurance. So the token holders have a direct legal right to go to the Swiss bank that backed the project and make a claim. 

Hong Kong

Hong Kong’s approach runs through the Hong Kong Monetary Authority’s Project Ensemble. Its current phase, EnsembleTX, moved from simulated testing into real-value transactions in late 2025 and is running through 2026 with seven commercial banks. 

Interbank settlement of tokenized deposit transactions is handled today through the existing Hong Kong Dollar Real Time Gross Settlement system, with a roadmap toward 24/7 settlement in tokenized central bank money once the infrastructure matures. 

Both regulators are treating the underlying legal claim as a standard bank liability; the innovation is in the settlement rail, not the legal wrapper. 

Hong Kong regulates stablecoins separately. The Stablecoins Ordinance, effective 1 August 2025, established a licensing regime for fiat-referenced stablecoin issuers. Tokenized deposits sit outside that regime, inside the banking perimeter.

Singapore

Singapore separates stablecoins and deposit tokens cleanly. MAS regulates single-currency stablecoins under a dedicated framework. For deposit tokens, a MAS consultation proposed that no additional reserve backing or prudential requirements should be imposed on issuing banks, on the grounds that existing capital, liquidity, AML, and technology risk requirements already protect banks and their customers.

“As to bank SCS issuers, MAS acknowledges the feedback that there are differences in the value-stabilising mechanisms used for fully reserve asset-backed stablecoins and tokenised bank liabilities, and thus the risks they pose to holders. MAS will therefore exclude tokenised bank liabilities from the scope of the SCS framework. However, MAS may impose additional requirements on tokenised bank liabilities in the future as necessary, taking into consideration the design of such tokenised bank liabilities.”

Source: MAS, August 2023 Response Paper 

Alongside this, MAS’s BLOOM initiative and the long-running Project Guardian are testing cross-border interoperability for tokenized bank liabilities with more than 40 participating institutions. 

The Regulatory and Balance Sheet Scorecard for Tokenized Deposits

How Banking Executives Should Approach Tokenized Deposit Implementation 

Given how fragmented the legal landscape still is, the sequencing of a tokenized deposit program matters as much as the technology choice itself. 

1. Start with infrastructure selection.  

The first decision is network topology. A private single-bank ledger maximizes control and the most legally safe option. A shared multibank network extends reach globally and lets banks join global or existing consortiums. 

Within permissioned architectures, the choices can be from permissioned EVM chains, ZK chains, and Hyperledger Besu deployments to custom L1s. The choice of tokenization engine is also vital as it should match requirements for mint, transfer, and burn lifecycle control, messaging standards, identity integration, and auditability. 

Whatever the choice, banks should plan for deep integration with core banking, cash management, and treasury systems, since that integration is what enables large-scale corporate adoption. 

2. Choose the first use case for demonstrable value. 

Liquidity orchestration is the strongest opening move for most institutions. Smart-contract-driven treasury services offer immediate, measurable value to multinational enterprise clients. 

Adoption today is already concentrated in corporate treasury, selected cross-border payments, and intraday financing workflows within single-bank or tightly governed environments.

3. Where a sandbox exists, use it.  

The EU DLT Pilot Regime, the UK Digital Securities Sandbox, Hong Kong’s EnsembleTX, and the ADGM framework each provide supervised environments that reduce regulatory ambiguity during testing. 

Building inside these structures also creates a documented engagement record with supervisors, which is useful when bespoke rules arrive. 

4. Design privacy and compliance from day one. 

Banks should design entire system-wide privacy instead of just network level privacy in their blockchain stack used for tokenized deposits. It can’t be limited to only participator level access control that default enterprise blockchain networks provide. Selective disclosure, custom ZK-workflow, role-based access control, confidential token transfer, and more such components are necessary in a bank-grade blockchain. 

And they need to be designed from day1 to stay compliant. 

Zeeve for Unbiased Consultation and Privacy-Enabled Blockchain Infrastructure

Zeeve provides privacy-enabled blockchain infrastructure built for exactly this kind of regulatory complexity. Zeeve’s modular privacy layer Tegaris gives institutions application layer, network layer, asset layer and ledger layer privacy that gives 360 degree controls suited to tokenized deposit architectures. 

Zeeve’s infrastructure offersISO 27001 and SOC 2 Type II compliant environments, and Bring Your Own Cloud deployment so institutions retain control over where their data and infrastructure live. For banks already running on legacy blockchain infrastructure, Zeeve also helps in migration without requiring a full rebuild. 

Zeeve has a multi-stack expertise and can help banks and financial institutions build with any kind of blockchain stack. 

Zeeve has helped a big US bank with their tokenization initiative. Talk to us to discuss yours. 

The big question now is where that token should live. Banks have spent a decade testing permissioned ledgers, consortium networks, and even public chains. A newer answer could be building a bespoke rollup, meaning a dedicated Layer 2 chain that the bank or a bank consortium controls, running the Ethereum Virtual Machine (EVM) and anchored to an external settlement layer.

This article explains why the EVM standard matters even for banks that avoid public chains, where bespoke rollups could win against the alternatives, how a tokenized deposit rollup works, what the architecture looks like, and much more.

Why Does the EVM Standard Matter Even if a Bank Is Not Using a Public Chain? 

The EVM is the execution environment that runs Ethereum smart contracts. A chain is EVM-compatible when contracts written for Ethereum run on it without modification. That definition sounds technical. The commercial consequence is simple. EVM compatibility determines which developers, audit firms, token standards, and integration tools a bank can use safely.

There are enough precedents now that indicate financial institutions are converging towards EVM standards. For example, J.P. Morgan’s tokenized deposit platform runs on a private Enterprise Ethereum stack. Deka Bank’s SWIAT ledger, used for live DLT repo transactions in the ECB trials, runs on Hyperledger Besu, a permissioned EVM chain. These are private systems. They still chose the EVM because it gave them mature contract standards and a deep talent pool.

According to the IMF’s 2026 fintech note on tokenized finance, the major new payment infrastructures, including Circle’s Arc, Stripe’s Tempo, and Coinbase’s Base, are all EVM-compatible, and even Swift’s planned blockchain infrastructure is being designed as EVM-compatible. 

Source: IMF Notes 2026/006

So we can safely say the standard is also where the wider market is converging. For a bank, this convergence changes the risk calculation. A tokenized deposit contract written for an EVM environment today can later connect to, or migrate toward, whatever infrastructure the market settles on. It does not create interoperability by itself, but it gives contracts and messages common technical assumptions.

For a contract written for a proprietary environment, it’s hard. 

There is a second reason. Regulators and auditors are building familiarity with EVM-based systems faster than with any other smart contract model, because that is where most institutional activity sits today. Hence choosing the EVM also shortens the review conversation.

EVM is therefore a standard for execution, not a decision to expose bank money to an unrestricted public network. The bank can keep the familiar application layer while choosing a more controlled infrastructure underneath it.

Why Choose a Bespoke Rollup Instead of Another Bank Blockchain Model? 

A rollup is a chain that executes transactions in its own environment, batches them, and posts the results to a settlement layer such as Ethereum. 

The IMF observes that banks have traditionally emphasized privacy, scalability, accountability, and predictable costs when evaluating ledger infrastructure. 

“…banks have traditionally favored and explored permissioned ledgers operated by themselves or by a consortium of known entities for their own purposes and clients. They have emphasized privacy, scalability, accountability, and predictable costs.”

IMF Notes 2026/006

Rollups bring all of that to banks. A bespoke chain means the bank or the consortium defines that environment and its rules. Banks buys control by choosing a custom layer2 rollup chain. 

Five things come with it.

1. Blockspace and cost. The chain carries only the bank’s traffic, so throughput and fees do not move because of unrelated activity elsewhere.

2. Throughput. It has to match payment-network volume. This requires higher transactions per second with fast finality.

3. Validator selection. The bank decides who runs the nodes and under what contractual and supervisory arrangements.

4. Rule placement. Compliance logic can sit at the protocol level, not only inside individual token contracts, so restrictions cannot be routed around.

5. Upgrade authority. Protocol changes follow the bank’s change-management process rather than an external governance vote.

Anchoring to a public settlement layer provides external verifiability of the chain’s state, a path to public liquidity when a use case requires it, and a security assumption that does not rest entirely on the bank’s own operations.

Where could it be the best alternatives to existing blockchain solutions?

Banks should choose a bespoke rollup when they’re joining a shared, multi-bank network run by an operator that isn’t already a global systemically important bank or a large pre-formed consortium. 

A single global bank running its own deposit token doesn’t need this. Its name is already the security. Take JPMC or Citi for example. A large coalition of major institutions co-governing a shared network doesn’t need it either, since trust comes from shared ownership among already-trusted parties. For example, SWIFT. 

What a bespoke rollup solves is the middle case: a neutral operator, or a smaller or regional bank without the scale to build or validate its own chain, that needs a way to get verifiable settlement without either building years of reputation or joining someone else’s consortium on someone else’s terms.

In this setup, transaction data and execution stay inside the operator’s private environment, visible only to the parties involved. But every batch of transactions produces a cryptographic proof, and that proof settles on a public chain that’s already been running securely for years. A bank doesn’t have to trust the operator’s internal controls. It can check the proof itself, or have its own risk and audit teams check it, independent of anything the operator says.

How Would a Tokenized Deposit Rollup Work?

Consider a corporate customer at Bank A paying a supplier at Bank B.

• The deposit is prepared for tokenization. Bank A authenticates the customer, runs its controls, and moves or earmarks funds in a designated deposit account. The integration layer instructs the token contract to mint the corresponding amount.

• The customer sends a payment instruction. The instruction comes through the bank’s portal, API, ERP, or treasury system. The wallet is linked to a verified customer record; the user does not need a public, self-custodied crypto wallet.

• Policy is checked before execution. Identity, sanctions, limits, available balance, and recipient eligibility are validated. The ordering service accepts approved transactions and places them in a deterministic sequence.

• The EVM contracts execute the token transfer. The deposit-token contract updates balances. Additional contracts can support escrow, conditional release, or delivery versus payment.

• The batch is proven and anchored. The rollup generates a proof or state commitment. A privacy-preserving design can publish verification material without publishing customer names, balances, or transaction details.

• Bank records and interbank obligations are completed. The integration bridge updates core systems, performs continuous reconciliation, and calculates the fiat obligation between Bank A and Bank B. That obligation is settled through the agreed settlement bank, RTGS connection, wholesale CBDC, or another legally recognized mechanism.

There are therefore two finality questions. The token transfer may be final on the rollup within seconds. The underlying interbank obligation becomes final only at the point defined by the scheme’s legal and settlement rules.

Architecture of a Rollup-Based Tokenized Deposit Network 

A bank rollup shares roughly half its stack with any other rollup. The other half does not exist in consumer designs. A production bank rollup is best understood as a stack of five layers. 

Application layer. The deposit token contracts themselves, with controlled mint and burn functions, transfer restrictions, pause and freeze capabilities for compliance events,  hooks for programmable payment logic, and the APIs through which clients and partner institutions actually use the network. 

Rollup operator layer. The execution environment itself, plus the sequencer that orders transactions, the prover that generates validity proofs, and the data availability arrangement that determines where transaction data is stored. 

The integration and orchestration layer. It translates on-chain events into message formats the bank’s systems already process, such as ISO 20022, so that deposit ledger balances update in step with token movements. It routes events between the chain, core banking, and custody infrastructure. It runs continuous reconciliation between on-chain balances and deposit records. Banks must be able to coordinate real-time on-chain updates with the settlement finality of existing systems and with conventional payment messaging standards, or clients lose reach into today’s payment networks. 

Settlement layer. A public chain, usually Ethereum, that receives proofs or batched data and provides external verifiability of the rollup’s state. 

The access and reporting layer provides segregated views by role. The operator sees network-wide flows, each bank sees its own customers’ activity and its settlement obligations, and supervisors receive a read-only audit view. This layer has no equivalent in a public rollup. 

For transfers within the same bank, the fiat rail only requires internal ledger adjustments. For transfers between banks, the token can settle immediately on the digital rail while an interbank fiat obligation is created. These obligations are accumulated and settled periodically—usually on a net basis.

Which Banks Are Already Building Deposit Rollups?

The clearest current example is the Cari Network, a consortium formed by five US regional banks including KeyBank, Huntington, First Horizon, M&T Bank, and Old National. 

It runs a permissioned Layer 2 ZK rollup anchored to Ethereum. Its architecture matches the pattern described above. Deposit tokens are issued under ERC-20. Every token is backed one-to-one by a balance in a designated deposit account at a participating bank. 

Source: Cari Network

Wallets are whitelisted and bound to KYC-verified customers. Transaction execution and data storage stay inside the network, with only validity proofs posted to Ethereum. Supervisors receive a dedicated read-only view. Net fiat obligations settle through a hub-and-spoke model administered by a settlement bank. 

Deposits represented by Cari tokens remain regulated liabilities on the banks’ balance sheets and stay covered by FDIC insurance. The network is backed by the Mid-Size Bank Coalition of America and has joined the American Bankers Association’s Premier Partner Network. The API layer covers issuance, transfer between verified parties, and redemption back into dollars. As of July 2026, the network had expanded past 30 participating banks, with around 40 more in active discussions, representing combined assets above $10 trillion. Production launch is targeted for later in 2026. 

Another Bank Projects as Useful Evidence

Deutsche Bank’s Project DAMA 2 uses a comparable architecture for a different purpose. Its architecture uses a privacy-enabled institutional ZK rollup on Ethereum with a permissioned sequencer for tokenized funds, stablecoins and other assets. It validates the same institutional logic: standard public infrastructure at the base, controlled execution above it, and a bank-friendly application layer.

Zeeve for Unbiased Consultation and Privacy-Enabled Rollup Infrastructure 

Zeeve provides institutional-grade blockchain infrastructure for launching and operating bespoke rollups, including privacy-enabled tokenized deposit infrastructure designed for regulated environments. Zeeve Tegaris, the modular privacy layer, provides system-wide privacy, including the transaction layer and entire workflow. 

The platform is ISO 27001 and SOC 2 Type II compliant, and supports Bring Your Own Cloud deployment so institutions can run rollup infrastructure within their own security and data-residency perimeter. For banks already running earlier-generation DLT platforms, Zeeve also supports migration from legacy blockchain infrastructure. 

Zeeve has helped a big US bank with their tokenization initiative. Talk to Zeeve’s team for an unbiased architecture review of your tokenized deposit program. 

“Cosmos Labs“, the company behind the Cosmos digital ledger and interoperability technology, has partnered with “Zeeve“, a privacy-enabled enterprise blockchain infrastructure platform. Together, the companies will help financial institutions bring tokenized deposits and digital assets into production.

Through the partnership, Zeeve will offer solutions built on the Cosmos stack to its enterprise customers. Cosmos will provide the ledger and token issuance technology, while Zeeve will handle deployment, migration, production architecture, and ongoing operations.

Zeeve’s services include fully managed networks, dedicated node and validator operations, 24/7 monitoring, and system-wide privacy through the Zeeve Privacy Layer.

The Cosmos stack has been running in production since 2019 and now powers more than 150 independent blockchains. It supports over 10,000 transactions per second, sub-second transactions, and native interoperability between networks. This gives financial institutions a tested foundation for issuing tokenized deposits and digital assets.

Zeeve brings the operational capabilities needed to run that technology in regulated environments. The company is ISO 27001 and SOC 2 Type II compliant and offers enterprise SLAs, 99.99 percent uptime guarantees, and privacy across both transactions and application workflows.

“Zeeve brings the operational expertise that enterprise customers need to deploy blockchain infrastructure with confidence, Institutions get a robust DLT solution that uses the Cosmos ledger and tokenization stack and Zeeve’s proven engineering and operations capabilities.”

– Barry Plunkett, Co-CEO of Cosmos Labs.

“Enterprises want blockchain infrastructure that’s proven in production and a partner who can get them there without operational risk,Cosmos gives our customers the technology foundation they need, and Zeeve brings the deployment and operations expertise to put it to work.”

– Dr. Ravi Chamria, co-founder and CEO of Zeeve.

Together, Cosmos Labs and Zeeve give a complete path from blockchain planning to production. The partnership will make it easier for financial institutions to launch and operate tokenized assets, digital deposits, payments, and other digital ledger initiatives at scale.

For more information, visit Zeeve.

About Cosmos Labs

Cosmos Labs is the company behind Cosmos, a digital ledger technology stack that powers more than 150 blockchains across finance, payments, and global business. The Cosmos stack enables institutions and governments to build sovereign and interoperable blockchain networks and applications.

Cosmos Labs is a wholly owned subsidiary of the Interchain Foundation, the nonprofit organization that supports Cosmos and its decentralized technologies.

To learn more, follow “@cosmos on X” or visit “cosmos.network“.

About Zeeve

Zeeve provides privacy-enabled enterprise blockchain infrastructure for production-grade digital asset deployments. The company helps banks, fintechs, and other institutions launch and operate blockchain systems for tokenization, stablecoins, tokenized deposits, payments, and settlement.

Built for regulated environments, Zeeve is SOC 2 Type II and ISO 27001 compliant. Its infrastructure supports more than 25 production blockchain networks that process over two billion transactions each month.

To learn more, visit Zeeve.

• Institutional treasury is one of the strongest near-term tokenized deposit use cases because a bank can deliver useful liquidity improvements within its own network today.

• It allows corporate treasurers to program money directly. Rules for sweeping, pooling, and conditional payments run automatically around the clock with no cut-off times or manual work.

• The bank’s core system remains the ultimate source of truth, while the blockchain handles fast, programmable settlement through secure APIs.

• It is much easier to launch this within a single bank. Moving money across different banks is hard because it requires shared rules and a clear way to settle interbank payments.

• To turn a test project into a full-scale commercial service, banks must address privacy issues, account reconciliation, key security, error handling, and 24/7 reliability.

If you ask banks where customers actually use tokenized deposits today, the first answer is always corporate treasury.

This is because old-school bank money costs companies the most time and money. Cash gets stuck across different subsidiaries and time zones. Strict daily cut-off times force treasurers to hold extra cash buffers they do not really need. Slow settlement ties up working capital that could be put to better use.

Tokenized deposits attack these problems directly, and they do it from inside the regulated banking perimeter. 

This article explains why treasury has become the leading enterprise use case for tokenized deposits. It covers what breaks in treasury management today, what tokenization changes, how a tokenized treasury actually works, the architectural decisions that determine success, and the challenges that remain before this scales across the banking system.

What Problems Do Treasurers Face With Today’s Infrastructure?

Institutional treasury management is the discipline of positioning a company’s or bank’s cash so that every entity can meet its obligations without holding more idle money than necessary. The current infrastructure works against that goal in three ways.

First, payment systems only run during standard business hours. Because of time zone differences, an office in Singapore cannot use funds sitting in a Frankfurt account overnight. Cash stays trapped in separate accounts, so treasurers must keep extra funds in every location.

Second, these delays create costs for everyone. Businesses lose access to their working capital and pay higher financing fees. Banks face extra operational load of reconciliation, investigations, and intraday overdrafts. This is why 53 percent of treasurers rank reducing operational costs as a top priority. Finally, suppliers and business partners experience delayed payments.

Source: HSBC Global Payment Trends Report 2026

Third, visibility is stale. According to JPMorgan’s Treasury 2.0 report, around 41 percent of senior finance executives lack real-time cash visibility because of manual reconciliation processes, and 52 percent of mid-sized firms still gather and consolidate forecasting data manually. Hence, decisions about funding, hedging, and investment are made on previous-day numbers.

What Do Tokenized Deposits Bring to Treasury Management?

A tokenized deposit is a bank deposit recorded and transferred on a distributed ledger. It remains a liability of the issuing bank, can be interest-bearing, and sits within the existing deposit-regulatory perimeter. For a treasurer, this is highly important because the instrument is familiar. What changes only is what the money can do.

The token form removes the settlement schedule. Transfers between entities or accounts can happen at any hour, which eliminates batch processing windows and cut-off times and gives treasury unified, real-time visibility of positions.

It also makes bank money programmable. Smart contracts can automate routine treasury actions such as liquidity sweeps, conditional payments, and settlement triggers, so these processes run continuously without staff on site around the clock. Conditional transfers can be executed when defined conditions are met. This capability of tokenized money can extend automation into liquidity management, collateral movement, and even reconciliation.

The financial impact will be visible in the buffers money banks used to keep. Large banks could generate efficiency savings of 10 to 30 basis points on trapped intraday liquidity, which could represent $100 to 300 million in annual savings for every $100 billion of daily internal fund flows.

Source: BCG/Anchorage Digital Assets Strategic Playbook, June 2026

How Corporate Treasury Management Works With Tokenized Deposits

Banks convert a client’s cash deposits into digital tokens on a ledger. Treasurers then program their company policies directly into this system as automated rules.

For example, a rule can automatically transfer any balance above a set limit from a local unit to the central company account as soon as the funds arrive. Another rule can transfer money to a supplier only a system records a delivery confirmation.

Because the ledger operates 24/7, these rules execute at any time, including nights and weekends.

Siemens deployment through J.P. Morgan gives a good example of what this looks like at scale. Programmable payments and real-time pooling reduced the company’s liquidity requirements by 50 percent, automated 80 percent of cash applications, cut treasury effort by 70 percent, and generated more than $20 million in annual savings.

Source: JPMorgan

The mechanics behind those savings are simple, though. When cash can move between entities instantly and automatically, each entity needs a smaller sta buffer. When application and reconciliation follow the token rather than a separate messaging flow, the manual matching work largely disappears. The treasury team shifts from executing transfers to designing and supervising the rules that execute them.

Architecture and Design Choices for Tokenized Deposit-Based Treasury Management

Three deployment models are getting tested, and each trades off control, interoperability, and market reach.

Bank-centric platforms are the most common today. Most treasury value today is captured on single-bank ledgers, because a corporation’s liquidity problem is largely internal. The bank operates a proprietary ledger that enables 24/7 settlement across its own branches and entities, supporting flexible cash pooling and automated, rules-based sweeping for corporate clients. This model is simplest to govern but confines the client to one bank’s network.

Read More: How a Private Tokenized Deposit Network Works

Multi-bank networks expand this model by placing multiple institutions on a shared ledger. These networks allow clients to move tokenized deposits between different banks instantly, 24/7. However, institutions can only scale these systems safely if they agree on multi-bank settlement assets, clear operating rules, and shared governance.

See How a Shared Tokenized Deposit Network Works?

Public blockchain issuance is the newest and next major architecture banks are exploring that can bring universal connectivity. There are very limited precedents available today, but banks are beginning to issue deposit liabilities on public chains under whitelisted, KYC-bound access, letting clients use bank money in environments where digital activity increasingly happens.

model an institution chooses, four design considerations will decide whether the deployment can deliver value. 

Integration comes first. Tokenized deposit offerings need seamless connection into core banking, cash management, and treasury systems, and into client ERP platforms, before large-scale corporate adoption becomes possible.

Second, systems must work together. Banks must align real-time blockchain updates with traditional payment networks (RTGS) and standard messaging formats like ISO 20022ird, banks need strong security and privacy. This includes protecting digital keys and wallet security through specialized hardware and software (like MPC and HSM). Or to secure the entire tokenized deposit workflow with a comprehensive privacy layer like Zeeve Tegaris.  

Fourth is the build-versus-partner decision. Banks typically build the customer interface and core system integrations themselves. Banks typically build the customer interface and core system integrations themselves. However, they partner with specialists for complex digital asset components—such as blockchain and smart contracts, wallets, custody systems, and key management.

Source: BCG/Anchorage Digital Assets Strategic Playbook, June 2026

Which Tokenized Deposit Treasury Solutions Are Already Live? 

Are tokenized deposits the same as stablecoins? 

No. Tokenized deposits are liabilities of regulated commercial banks and remain inside the deposit-regulatory perimeter, while stablecoins are typically issued by non-bank entities. For treasurers, that means familiar balance sheet treatment, an existing banking relationship, and the possibility of interest-bearing balances 

Are tokenized deposits covered by deposit insurance? 

 In the US, the FDIC has already clarified that tokenized deposits are covered by deposit insurance. As tokenized deposits are claims on the issuing bank, token holders may benefit from deposit insurance where the institution is covered and the product meets scheme requirements.

Does treasury need to replace its TMS or ERP to use tokenized deposits? 

Never. The blockchain layer is integrated with the core banking system via APIs. CBS continues to do what it does. 

Is this production-ready or still experimental? 

Both, depending on the model. Single-bank treasury use cases are live at scale, with HSBC processing roughly $28 billion in tokenized deposit payments in Q1 2026 and J.P. Morgan processing over $5 billion per day. Multi-bank and public-chain models are earlier in their development.

Zeeve for Privacy-Enabled Blockchain Infrastructure Behind Tokenized Deposits

Tokenized deposits create value for institutional treasuries when the underlying infrastructure is production-grade, private where it needs to be, and integrated with the systems banks already run. 

Zeeve provides privacy-enabled tokenized deposit infrastructure built for institutional requirements. Its institutional-grade blockchain infrastructure is ISO 27001 and SOC 2 Type II compliant, and institutions retain deployment control through Bring Your Own Cloud (BYOC). For banks already running blockchain workloads, Zeeve also supports migration from legacy blockchain infrastructure where required.

For treasury and digital asset teams evaluating this use case, the next step is an infrastructure assessment. Zeeve offers unbiased consultation on deployment models, privacy architecture, and integration choices, so the tokenized deposit program starts on foundations that can carry production volumes.

Schedule a call today to discuss your requirements. 

This decision is harder than it looks. A tokenized deposit remains a liability on the bank’s balance sheet. It must keep every existing legal, regulatory, and risk characteristic of a normal deposit. On top of that, it must add new capabilities such as real-time settlement and programmable payments. A pilot can run on almost any ledger. A production system needs a long-term view.

First, a quick definition

A tokenized deposit is a standard commercial bank deposit represented on a blockchain. It is economically and legally identical to an off-chain deposit and holds a 1:1 par exchange rate with fiat currency. It has a direct claim on the issuing bank and sits under standard deposit insurance schemes. Unlike stablecoins, tokenized deposits support fractional-reserve banking and credit creation.

By placing this liability on a blockchain interface, banks make commercial money programmable and mobile, which can settle around the clock without waiting for batch-processed clearing systems that pause on weekends and holidays.

Infrastructure means more than picking a chain

Many executives see this as a blockchain selection problem. It is not. Tokenized deposit infrastructure is a full stack. It covers the network selection, the ledger model, the smart contract and token architecture, the privacy and compliance layer, and the integration layer that connects everything to core banking, custody, and other financial networks.

The core banking platform will remain the system of record and continues to hold deposit liabilities, customer accounts, and other regulatory and compliance responsibilities. The blockchain only becomes a programmable settlement environment on top. Every mint, transfer, and burn on-chain needs a matching entry in the bank’s books. This reconciliation process has to be carefully designed between these two ledgers and often takes longer than the smart contract work itself.

The network decision, and how adoption will happen

The network layer is the most consequential choice. Banks can build private tokenized deposit networks, shared/ consortium networks, use institutional public chains, or adopt hybrid models that combine private execution with public connectivity. Each carries a different balance of control, reach, and cost.

Here is a more useful way for leaders to think about it. The market will not adopt one model. It will adopt in waves, and each wave will favor a different architecture. By “waves,” I don’t mean chronological waves. They are four adoption patterns developing at the same time. 

• The first wave has already happened. The five to seven largest global banks have launched their own private tokenized deposit networks. JPMorgan, Citi, and HSBC are the visible examples. These banks had the client volumes, the treasury flows, and the budgets to justify owning the full stack.

• The second wave belongs to the remaining G-SIBs. These institutions face the same client expectations as the first movers. They serve the same multinational corporates. They are the most likely group to launch private tokenized deposit networks next, because their scale supports it and their clients will demand parity.

• The third wave is for large regional banks, which will likely pursue both choices at once. Some will launch private chains for their own corporate treasury settlement. Others will need shared networks to meet wholesale settlement demand from clients. Corporate treasury is the segment with the highest near-term ROI for banks, so the choice depends on how much of that business each bank holds. Regional leaders can also form shared tokenized deposit networks with peer banks. These consortiums are regional and purpose-built. They are different in character from global coordination networks like SWIFT.

• The fourth category is global consortium participation. Most banks will not build. They will join. Existing global bodies built for specific purposes are strong candidates to launch consortium blockchains. Think of settlement networks like SWIFT, clearing platforms like The Clearing House, or depositories like DTCC. These organizations already hold the membership, the trust, and the rulebooks. Launching a consortium chain lets them deliver cost savings, efficiency, and client retention to existing members. This could turn out to be one of the biggest categories. 

One bank, multiple networks

There is a second insight leaders should internalize. No serious bank should believe it needs only one chain.

Look at JPMorgan. It runs Kinexys as a private network. It is a founding shareholder of Partior. It is part of the planned Clearing House consortium with its G-SIB peers. And it is integrating with the Canton Network for asset settlement. Four different networks, four different purposes, one bank.

HSBC shows the same pattern on a smaller scale. It is preparing its own corporate tokenized deposit product while also sitting inside the UK Regulated Liability Network pilot alongside five other British banks.

Large banks with significant treasury and wholesale settlement books are the most likely to end up running this kind of portfolio. A private chain handles internal flows and single-client relationships where the bank wants full control. A domestic consortium handles cost-efficient settlement with close peers. A global network handles cross-border reach without building bilateral connections to every counterparty bank. Small and mid-tier banks are more likely to skip the private chain altogether and simply join two or three consortia that together cover most of their client demand.

This is not unusual in banking. Banks already connect with several payment systems, correspondent networks, card schemes and securities infrastructures. Tokenized finance is likely to develop in a similar way. 

This changes how the infrastructure decision should be framed inside a bank. The question is not “which chain should we build.” It is “which of these four layers do we need a presence in, and in what order.”

The decisions underneath the network choice

Once the network strategy is clear, four further layers deserve executive attention.

• The blockchain ledger model matters for regulatory fit. Account-based ledgers attach identity to balances and map cleanly to existing banking records and due diligence processes. Token-based or UTXO-style models handle atomic settlement and multi-party workflows better. Many banks will end up using both, starting with account-based issuance and adding token-based settlement where delivery-versus-payment matters.

• Token standards are use-case dependent. There is no universal standard for tokenized deposits. ERC-20 works for simple transfers with added compliance controls. ERC-1400 suits regulated instruments. ERC-3643 helps where identity-linked restrictions are required. Closed consortium networks often justify custom permissioned contracts.

• Privacy is the hardest problem. Banks cannot expose counterparty identities, volumes, or pricing to other network participants. Regulators and auditors still need visibility. A permissioned chain does not automatically deliver a private workflow, because validators can still see transactions, and apart from these network-level access controls, workflow privacy is also necessary. Zero-knowledge proofs, confidential transactions, selective disclosure, or role-based access make this possible, but only if privacy is treated as a stack-wide design goal.

Read More: How Banks Can Enable Selective Privacy and Compliance for Tokenized Deposits?

Integration is the last decision, and it determines time to production. Beyond core banking connectivity, banks need oracles or institutional custody with MPC and HSM controls, policy engines that screen every transaction before settlement, and interoperability layers that will bring universal connectivity with custom networks as required. 

If any of these considerations is missing, that infrastructure cannot be called bank-grade infrastructure.

We have covered this section in great detail in a separate article. Read it here. 

How to choose the right blockchain infrastructure for tokenized deposits?

The questions worth asking now and how Zeeve helps

Financial leaders evaluating this space should press their teams and vendors on a short list. The more useful questions are which networks their largest clients are already asking to use, which consortiums their closest peers are joining, whether there are any 3rd party tool/services it is using that could lead to vendor lock-in, and whether your blockchain infrastructure partner has multi-stack expertise that can handle migration if at any point it becomes necessary.

The technology has been proven. The competitive question now is who builds infrastructure that can grow with the market. Working with an experienced enterprise deployment partner can compress that learning curve considerably, but the strategic choices described here belong to the bank’s leadership.

If your institution is weighing tokenized deposit infrastructures, Zeeve can help. We have worked with a big US bank in their tokenization initiative. Connect with Zeeve to discuss your roadmap.

Several of the world’s largest financial institutions are the pioneers of this single-bank ledger model. For example, JPMorgan runs Kinexys, and Citi operates Citi Token Services for Cash. HSBC runs its tokenized deposit service out of its Orion digital asset platform. DBS in Singapore offers DBS Token Services. In every case, the bank is the sole issuer and the sole operator. Tokens are minted internally, moved between the bank’s own clients as real-time book transfers, and burned when a client wants standard fiat back.

This model makes immense commercial sense when a single bank already moves massive value internally between its own global clients every day. 

This snippet from BCG and Anchorage Digital, June 2026 Report gives us a glimpse of what a rightly implemented private tokenized deposit initiative could do for a bank:

The Use Cases and Benefits for Every Stakeholder

The business case for a private tokenized deposit network comes down to maximizing the velocity and value of internal liquidity.

Because the network is closed and completely controlled by the bank, these use cases focus on delivering high-margin, automated services to global corporate and institutional clients.

Here are the core use cases that describe what the platform actually does:

• 24/7 Cross-Border Cash Pooling: Shifting multi-currency corporate cash balances instantly across global branches outside of standard central bank operating hours.

• Automated Conditional Escrow: Using conditional logic to automatically release funds to a vendor only when specific digital business milestones are verified.

• Intraday Repurchase Agreements (Repos): Lending or borrowing cash on an hourly basis to meet short-term liquidity or collateral mandates.

• Atomic Asset Settlement (DvP): Simultaneously exchanging bank-issued digital assets (like tokenized commercial paper) and tokenized deposits on the same ledger to ensure the trade executes flawlessly.

Now, how will these benefit different stakeholders?

How a Private Tokenized Deposit Network Use Case Works

The clearest way to see how a private tokenized deposit network works is to watch it do a real job. We will use the flagship use case J.P. Morgan built Kinexys around, the intraday repo, a collateralized loan that starts and ends the same day, timed to the minute, something legacy settlement rails cannot execute. 

Credit: Source: JP Morgan and BCG, “The Future of Distributed Ledger Technology in Capital Markets”; GFMA member inputs; BCG analysis.

Step 1. The Account Structure

Before any tokens are created, the bank sets up a dual-ledger system for each participant.

• The Core Banking Ledger. The bank’s traditional database, where the cash lender holds a standard Demand Deposit Account, a DDA, with actual fiat balances.

• The Tokenized Ledger. The bank’s private, permissioned blockchain. Each participant is mapped to a Blockchain Deposit Account, a BDA, which works exactly like a traditional deposit account except that the recordkeeping is done on blockchain rather than on legacy ledger systems. A client must hold a DDA with the bank in order to fund a BDA

Step 2. Pre-Positioning, Minting Both Legs

A repo has two legs, and both must exist on the ledger before the trade can settle atomically.

• Cash leg. The lender moves $50 million from their DDA into their BDA. The core system locks the fiat, and the blockchain simultaneously mints $50 million of deposit-token balance. No separate asset is created, and the bank’s balance sheet does not change. The liability is simply reclassified from a standard deposit to a tokenized deposit.

• Collateral leg. The borrower’s Treasuries are transferred to an account in the name of a collateral token agent at a traditional triparty agent, BNY, in the early trades. Once the collateral and its value are confirmed, a collateral token is minted on the same ledger. The bonds never leave custody. The token represents the security entitlement.

Step 3. Execution and Atomic Settlement

The repo seller submits a quote request, and the buyer accepts. The terms, covering collateral type, amount, interest, and an intraday maturity time specific to the minute, are recorded in a smart contract.

• At the agreed start time, the contract settles both legs at once. The lender receives the collateral token and the borrower receives the cash balances, settling the repo within minutes. Either both sides settle or nothing does, so leg risk disappears.

• Once confirmed on the ledger, a transaction is irreversible and final within seconds, with no concept of probabilistic settlement, and payments on the system run 24/7/365.

Step 4. Maturity and Off-Ramping, Burning

The repo unwinds automatically at the pre-set maturity, often just a few hours later. The contract returns the collateral to the borrower and the cash, with interest calculated to the minute, back to the lender. In January 2025, Santander executed two programmable intraday repos on Kinexys, one for $50 million and one for €50 million, each scheduled to redeem three hours after execution.

To exit the tokenized environment, a client requests a payout. The ledger burns the BDA balance and the core system credits standard commercial cash to the client’s DDA, a redemption into traditional deposits. Those funds can then move anywhere in the world on legacy rails.

The repo demonstrates every core mechanic of the network, lock and mint, atomic transfer, programmatic execution, burn and release, applied to a real problem, freeing intraday liquidity that overnight funding traps.

The Architecture of Single Bank Ledgers for Tokenized Deposits

In a private tokenized deposit network, the infrastructure runs inside the bank’s approved operating environment, either on-premise, in a private cloud, or through managed infrastructure under the bank’s control. Across live implementations, the architecture usually follows five layers.

The first is the core banking layer. This is the bank’s traditional system where deposit accounts, customer records, general ledger entries, statements, and reporting stay. The tokenized ledger does not replace this layer. It depends on it. Every tokenized deposit in the system is still a deposit liability that the bank already accounts for.

The second is the integration layer. This is the bridge between the traditional ledger and the blockchain ledger, and for most banks it is the hardest part of the build. Its job is simple. Whatever happens on the tokenized ledger must reconcile with the core system, and whatever the core system locks or releases must be reflected on the tokenized ledger. This is usually handled through secure APIs, event triggers, and reconciliation workflows.

The third is the private ledger layer. This is the private blockchain environment where approved clients, accounts, and applications transact. Banks can build this on EVM-compatible stacks such as Hyperledger Besu, enterprise platforms such as Hyperledger Fabric, Cosmos SDK-based chains, or dedicated EVM L2s. The bank controls the validators, sets the operating rules, and approves every participant.

The fourth is the compliance and policy layer. The advantage of a private ledger is that compliance does not need to be rebuilt at the blockchain level. The bank already knows every participant, so KYC status, limits, approvals, whitelisted accounts, and rules can plug directly into the transaction flow.

The fifth is the client access layer. Corporate clients never touch the blockchain. They keep using the same interface they already use. The ledger works behind that interface as a settlement and workflow engine. If the bank builds it well, the only thing a client notices is that approved payments, liquidity movements, or settlement workflows can now run outside normal banking hours.

This is the main architectural idea behind the single-bank ledger model.

Examples of Full Commercial Production Implementations of Private Tokenized Deposits Network

JPMorgan Kinexys

They are the largest operator of a private, single-bank tokenized ledger that has processed around $3 trillion in cumulative volume since its inception. 

Source:  BCG and Anchorage Digital, June 2026 Report

The platform runs on a private permissioned version of the Ethereum Virtual Machine (EVM) framework. Kinexys utilizes an Asynchronous Dual-Ledger Bridge Architecture. The blockchain environment sits completely parallel to JPMorgan’s core banking databases, and communicates via high-speed, event-driven APIs.

When a corporate client opens a specialized Blockchain Deposit Account (BDA), the traditional core banking system registers this and routes instructions through an API bus to lock the fiat funds. A banking smart contract then mints ERC-20-compliant digital deposit tokens directly into the client’s wallet. Corporate clients interact with the system through their standard corporate banking portal, using the blockchain purely as an automated background execution layer.

The platform supports eight major fiat currencies, including USD, EUR, GBP, AUD, HKD, JPY, CNY, and SGD, enabling global multi-currency intra-bank settlement 24/7.

Citi Token Services:

Citigroup’s architecture for Citi Token Services for Cash is a unique approach to user interaction. Rather than creating a new account type like BDA, Citi integrates tokenization directly into existing global client accounts within its Treasury and Trade Solutions business.

The technical platform is built using Hyperledger Besu, an enterprise-grade private client of the Ethereum network. A core architectural feature of Citi’s model is the complete abstraction of the blockchain layer away from the end user. Corporate treasurers do not manage cryptographic private keys, interact with Web3 wallet interfaces, or track token balances. Instead, the tokens exist strictly as a short-lived backend messaging wrapper.

​When a corporate treasurer initiates a real-time payout from a branch in London to an entity in Singapore, Citi’s internal Hyperledger Besu nodes mint, transfer, and burn the token instantly in the background. The ledger acts as an ultra-high-speed processing engine and updates the traditional fiat accounts on both ends seamlessly while providing the benefits of a programmable ledger.

HSBC Tokenized Deposit Service:

JPMorgan and Citi built their tokenized deposit networks as independent cash engines. HSBC architected its tokenized deposit system as a sub-module of its broader digital asset issuance platform (HSBC Orion). 

In HSBC’s design, the tokenized deposit ledger shares the exact same cryptographic environment as tokenized bonds and commercial paper. This allows for native Delivery-versus-Payment (DvP) atomic swaps. The asset token and the cash token sit side-by-side, executing on a single shared state ledger, ensuring that security transfers and cash clearances happen as a single, indivisible cryptographic event.

HSBC Tokenized Deposit Service is commercially operational and facilitates real-time transactions specifically in Hong Kong Dollars (HKD) and US Dollars (USD).

The Limitations of Private Tokenized Deposit Networks

Credit: Deutsche Bank

A private ledger is, by definition, a walled garden, and that creates several linked problems.

1. If a corporate client needs to pay a vendor who banks with a competitor, the tokenized money cannot follow. The bank has to burn the token, release traditional cash, and send it out through the same slow rails the network was built to avoid.
   
   This limitation caps the network’s usefulness. A tokenized deposit is only as valuable as the number of counterparties who can receive it, and on a single-bank ledger, that number is capped at the bank’s own client base. Smaller mid-market businesses are largely excluded.
   

2. Corporate treasurers also tend to dislike concentration risk. A single-bank network effectively asks a client to hold oversized balances at one institution to make full use of its automated features, which works against normal treasury diversification practices.

3. Finally, the bank bears the full cost of building and running the system alone. There is no consortium to share infrastructure, cybersecurity, or audit costs with, unlike a shared multi-bank network.

So when do private ledgers still make sense? 

• When the bank already controls a massive intra-bank ecosystem. 

• When trades are so sensitive that total confidentiality behind the bank’s own firewall is worth the tradeoff. 

• And when time to market matters, since a bank can launch privately now and join shared networks later. 

The winning institutions will likely run both. A private ledger for internal processing power, plus shared or universal connectivity for external reach, much as banks today pair internal core systems with SWIFT-like coordination networks.

Zeeve for Privacy Enabled Blockchain Infrastructure for Tokenized Deposits

Zeeve is a managed blockchain infrastructure and privacy middleware layer that lets a bank deploy tokenized deposit networks without replacing legacy core systems or building a chain from scratch.

Zeeve addresses the three limitations above directly. 

• First, multi-stack orchestration. From one dashboard, a bank can manage intra-bank, inter-bank, and universal ledgers built using Besu, Fabric, Cosmos CTS, or custom EVM L2 stacks.  

• Second, system-wide privacy through Zeeve Tegaris. This modular privacy layer brings workflow privacy along with network-level privacy offered by permissioned networks. ZK proofs and role-based selective disclosure keep balances and counterparties confidential on shared networks, while giving regulators dedicated audit visibility.

• Third, legacy protection. Zeeve provides APIs to connect core banking systems with digital asset infrastructure. So the book of record continues to function while digital asset infrastructure handles real-time settlement.

Zeeve infrastructure is used by enterprises including Vodafone, Deutsche Telekom, and Siemens Energy. Zeeve has multi-stack expertise. It is a certified Besu partner and enterprise implementation partner of Cosmos Labs, for CTS and other products. It holds SOC 2 Type II and ISO 27001 certifications, complies with GDPR, and backs its 24/7 operations center with 99.9 percent uptime SLAs.

For a bank weighing the single ledger opportunity against its walled garden limits, Zeeve offers a way to capture the first without being trapped by the second.

Schedule a call with Zeeve today!

The blockchain should not become the bank’s core system.

Instead, the bank should add a digital asset overlay network beside the core system. This should be a permissioned blockchain-based ledger that connects to the legacy CBS through real-time bridges. The core should continue to own the actual deposit record. The blockchain should record token movement. A reconciliation layer should keep both aligned.

This is the practical deposit tokenization model for banks. It keeps the deposit inside the regulated banking perimeter. It gives clients programmable, always-on settlement. It avoids the cost and risk of replacing the core.

Here is how this system works across four key layers:

1. The core banking Layer

The first layer is the lock and release layer.

This is where most banks should start. The bank should not move deposits out of the core. It should mark part of the client’s existing balance as unavailable for ordinary payments. That hold becomes the funding base for token issuance.

A corporate client may hold $10 million in a normal operating account. The client asks the bank to tokenize $2 million. The core banking system validates ownership, balance, account status, sanctions status, and product eligibility. It then places a hold for $2 million. The available balance falls. The ledger balance remains unchanged. The money is still a bank deposit. It remains a claim on the issuing bank.

The hold must be precise. It should carry a tokenization reference. It should identify the customer, account, currency, amount, product type, jurisdiction, wallet, timestamp, and token contract. It should also identify whether the token is transferable only within the bank, across a consortium network, or to a whitelisted external venue.

The CBS will still calculate interest, produce statements, and feed the general ledger. If the tokenized balance is interest-bearing, the interest logic should remain in the banking system.

This protects the bank from balance sheet confusion. Without a clear hold model, the bank risks counting the same money twice. Once as a normal available deposit. Once as a tokenized spendable balance. That is not tokenization. That is uncontrolled duplication.

Another important consideration is, that the token supply must never exceed locked funds. Minting should be impossible unless the hold is confirmed. Release should be impossible unless the token has been burned or immobilized.

There are two ways to design the ledger relationship.

The first is a non-native overlay. The core remains the source of truth. The blockchain mirrors locked balances and token transfers. This is the practical starting model for most banks.

The second is a native deposit token model. The blockchain becomes the primary record for the deposit token. Native deposit tokens can unlock more functionality because they are not limited by off-chain reconciliation. That is a valid long-term direction. It is also a larger legal, accounting, audit, and operational decision. Most banks should not begin there unless their regulators, auditors, and technology teams are ready.

J.P. Morgan’s work shows the direction of travel. The earlier JPM Coin System is described as a single-bank ledger for dollar balance transfers among participating JPMorgan clients. The newer JPMD concept extends bank deposit money onto public blockchain infrastructure for institutional clients while keeping the commercial bank money credit profile and deposit regulatory framework.

Citi shows the same pattern from a transaction banking angle. Citi Token Services for Cash uses tokenized interbranch deposits for real-time USD payments and 24/7 operations. The client experience remains inside existing Citi channels. Clients do not need to hold tokens directly or manage blockchain keys. The blockchain layer runs behind the banking interface.

2. The API integration layer

The second layer is the bridge.

This is not a simple API wrapper. It is a controlled transaction orchestration layer between the core banking system and the token ledger. It must translate banking events into token events. It must also translate token events back into banking events.

The mint flow should be deterministic.

The client submits a tokenization request. The bank validates eligibility. The core confirms funds. Compliance systems approve the account and wallet. The core places a hold. The event bridge receives the hold confirmation. The bridge signs a mint instruction. The smart contract mints the token. The token ledger sends a confirmation. The client channel shows the token balance.

The burn flow is the mirror image.

The client asks to redeem tokens. The token ledger checks the token balance. The compliance engine checks the wallet and destination account. The smart contract burns or immobilizes the token. The bridge receives finality proof. The core releases the hold. The available cash balance increases. The client receives confirmation.

Every step needs a shared transaction identifier. The same identifier should appear in the core, the token ledger, the API gateway, the event bus, the reconciliation system, and the audit log.

The bridge must be bi-directional. If the core rejects a hold, the token layer must not mint. If the token layer fails to mint, the core must either release the hold or mark it as pending. If a burn occurs but the core release fails, the client should not lose access to both forms of money. The amount should move into a controlled suspense account until the release is completed.

The bridge should also standardize the message payload. Messaging standards matter. Deutsche Bank report identifies integration with treasury systems, ERP systems, reconciliation workflows, reporting workflows, and messaging standards as structural constraints for broader digital money adoption. The same issue applies to tokenized deposits. Banks should design the bridge to support ISO 20022 messages, Kafka streams, and internal ledger posting formats from day one.

The API layer is also where the bank can protect the core. The core should not manage private keys. It should not validate blockchain consensus. It should not parse smart contract state. It should receive clean banking events. The bridge should handle blockchain complexity and expose only approved transaction states to the core.

This also makes migration easier. A bank can replace the blockchain network later. It can move from a private Besu network to a consortium ledger, connect to a public permissioned environment. It can join a shared settlement network as well. But the core integration should remain stable.

3. The digital asset overlay

The third layer is the token ledger.

This ledger should be separate from the core. It should be optimized for token movement. It should record token balances, wallet permissions, smart contract states, settlement conditions, freeze orders, and transaction history.

This is where the bank gets the new functionality.

A normal deposit can move through ACH, wire, RTP, internal transfer, card settlement, or book transfer. A tokenized deposit can also move through programmable logic. It can settle only when a security token is delivered. It can release only after an invoice is approved. It can sit in escrow until a corporate treasury rule is satisfied. It can move between branch entities after local cut-off times. It can support payment versus payment in foreign exchange. It can support delivery versus payment for tokenized bonds or funds.

Any smart contract that can mint, burn, freeze, or transfer bank money should be subject to change control, access control, and emergency pause rights.

The permission model is critical.

The token should move only between approved wallets. Wallets should be linked to KYC records. Institutions should be linked to legal entity identifiers. Beneficial ownership should remain in off-chain systems. The blockchain should hold only the minimum data needed for settlement and verification.

The overlay can take three broad forms.

a. The first is a single-bank ledger. This works for intrabank treasury, branch liquidity, corporate cash pooling, and closed client networks. JPM Coin is the clearest example.

b. The second is a shared ledger. This works for interbank clearing, correspondent banking modernization, and consortium settlement. Partior and newer bank-led shared ledger projects fit this model.

c. The third is a universal or public blockchain environment. This gives broader market reach/interoperability, but it demands stronger controls around identity, permissions, privacy, transaction monitoring, and bridge risk.

The overlay should use privacy controls at multiple levels. It should support private transactions, confidential data fields, selective disclosure, role-based access, zero-knowledge style proofs where appropriate, and audit views for authorized parties.

Because a permissioned network is not automatically private. Validators may still see transaction metadata. And a multinational will not use a tokenized deposit network if competitors, counterparties, or infrastructure operators can infer cash positions, supplier flows, or acquisition activity.

Read More on: How Banks Can Enable Selective Privacy & Compliance for Tokenized Deposit Programs?

4. End of day and intraday reconciliation

The fourth layer is the safety net.

End of day reconciliation is necessary. It is not sufficient. Tokenized deposits move continuously. A bank cannot wait until midnight to discover that tokens outstanding no longer match core holds.

The reconciliation model should run in two cycles.

The first cycle is intraday control. It compares token supply, wallet balances, core holds, pending mints, pending burns, and suspense balances throughout the day. The second cycle is formal end of day reconciliation. It produces accounting files, audit evidence, regulatory reports, and general ledger postings.

The bank should reconcile three records.

The first record is the core banking record. It shows the customer deposit, available balance, held balance, and tokenization hold.

The second record is the token ledger. It shows tokens minted, tokens burned, wallet balances, frozen amounts, and pending settlement states.

The third record is the general ledger. It shows deposit liabilities, control accounts, suspense accounts, fees, interbranch positions, and settlement receivables or payables.

The core equation is simple.

Tokens outstanding must equal valid tokenization holds plus any approved settlement-in-flight amount.

If tokens outstanding are higher than holds, minting must stop. If holds are higher than tokens outstanding, the bank must identify whether tokens were burned, failed, frozen, or not yet minted. If a burn succeeded but the core release failed, the amount should sit in a pending release suspense state. If the core hold succeeded but minting failed, the amount should sit in a pending mint state or be released.

This logic should be automated.

The blockchain can help. Each token event carries a timestamp, block number, transaction hash, wallet address, smart contract address, and event type. The bank can hash reconciliation files and store proofs. It can compare blockchain state against core state.

But the blockchain cannot solve accounting by itself. The general ledger still needs clean journal entries.

Exception handling is where the architecture needs to be tested. For example, a failed mint is manageable, but a duplicated mint is serious. A burn without release is a client incident. A release without burn is a loss. Any privacy leak is a reputational incident.

The bank should define states before launch. Normal. Pending mint. Pending burn. Chain final pending core. Core posted pending chain. Frozen. Suspense. Failed. Reversed. Manually corrected.

Each state needs an owner. Each owner needs an SLA. Each correction needs maker-checker approval. Each correction needs audit evidence. Each critical mismatch needs automatic escalation.

The reconciliation layer should also feed financial crime controls. Token movements should be mapped to customer profiles, wallet risk, sanctions screening, behavioral patterns, and transaction purpose. On-chain and off-chain data must come together. BCG and Anchorage state that banks should extend risk and compliance frameworks to integrate on-chain and off-chain data for AML, sanctions, transaction monitoring, market conduct surveillance, custody governance, third-party risk, cyber resilience, and incident response.

Interoperability increases reconciliation risk. A transaction may work on one ledger and fail at the boundary with another ledger.

Below are the potential risk vectors identified in BCG and Anchorage Digital report:

So reconciliation is part of the product. Clients will trust tokenized deposits only if the bank can prove that every token maps to a valid deposit claim, every redemption maps to a valid burn, and every exception is controlled.

5. How Zeeve can help

An enterprise infrastructure provider like Zeeve fits directly into the infrastructure and orchestration layer of this architecture. It delivers the automation frameworks required to deploy, secure, and monitor the digital asset overlay without disrupting the bank’s core logic.

1. Unbiased Consultation

Different institutional use cases demand different blockchain design characteristics. Hyperledger Besu offers an optimal framework for consortium networks that require enterprise-grade permissioning, strict access controls, and standard EVM compatibility. The Cosmos SDK is highly suited for banks that require absolute sovereignty over their blockchain design, allowing them to construct an application-specific chain with custom validator rules and native interoperability.

2. Compliant Infrastructure

Deploying financial infrastructure requires adherence to rigorous global security standards. Infrastructure providers address these requirements by maintaining continuous compliance with frameworks like ISO 27001, SOC 2 Type 2, and GDPR, alongside providing 24/7 security monitoring and automated vulnerability patching.

3. Expert Lead Migration

Many financial institutions possess early blockchain pilots built on legacy versions of Quorum or similar setups. These isolated setups typically lack production-grade observability, automated accounting bridges, and robust privacy controls. Zeeve can help banks in evaluating these legacy applications and migrating them onto modern, enterprise-ready networks.

The Zeeve Privacy Layer

Because simple blockchain networks can expose sensitive transaction metadata, specialized privacy layers are necessary to protect corporate activity. A modular enterprise privacy layer is offered by Zeeve that shields transaction values, smart contract execution steps, and participant identities from unauthorized network nodes. This provides corporate clients with the total business confidentiality they require while granting selective, read-only audit keys to internal bank compliance teams and external regulators.

Schedule a call with us to start your tokenization initiative.

But scale for banks will not come only from speed and programmability. Banks need to solve a harder question first.

How can they enable privacy and compliance in tokenized deposits at the same time? 

Because a tokenized deposit is different from most crypto-native assets. It is part of a regulated customer relationship. At the same time, banks cannot make tokenized deposits completely opaque. Regulators and auditors still need visibility. AML checks must run. KYC rules must apply. Suspicious activity must be reviewable.

So the real challenge is not whether tokenized deposits should be private or transparent. They need both.

In this article, we will discuss how this can be done? What regulations apply to tokenized deposits? What all options bank has to design their privacy and compliance infrastructure and how Zeeve can help. 

What Privacy and Compliance Rules Apply to Tokenized Deposits?

Tokenized deposits will generally follow the same core rules as normal bank deposits because the issuance model does not change the underlying asset class.

These mandates ensure that traditional deposits are not used to launder money, evade taxes, or finance illicit activities.

1. Compliance and Anti-Financial Crime Rules

Banks will still need to meet the standard compliance duties that apply to deposit accounts and electronic transfers.

• Know Your Customer (KYC): Banks must legally verify the identity, date of birth, address, and legal status of every individual or corporate entity opening a deposit account.

• Customer Due Diligence (CDD): Ongoing monitoring to understand the source of a depositor’s wealth. High-net-worth clients, politicians, or cross-border companies face Enhanced Due Diligence (EDD).

• Transaction Monitoring & SARs: Automated systems must scan all inbound and outbound deposit movements for anomalies (e.g., sudden, large cash injections).

Any highly unusual activity must trigger a mandatory, confidential Suspicious Activity Report (SAR) to be submitted to financial intelligence units such as FinCEN in the US.

• Sanctions: Every transaction must be screened against the US OFAC and UN blacklists. No tokens can move to or from restricted people or countries.

• The FATF Travel Rule: For electronic funds transfers, the originating bank must securely transmit specific customer identity data, such as name, account number, and address, alongside the payment to the receiving bank.

2. Data privacy and financial secrecy rules

Banks have to protect customer confidentiality. That obligation does not disappear when deposits move to a blockchain ledger.

• Client confidentiality. A customer’s balance and transaction history are sensitive financial information. These details should not be exposed through block explorers, APIs, validators, or shared node access.

• Data privacy regulations. Rules such as GDPR, GLBA, and CCPA can affect how personal information is collected and used.

• Data minimization. Banks should avoid putting raw PII (tax IDs, IDs, KYC docs) on-chain.

• Purpose limitation. Data collected for KYC, AML, sanctions, or settlement should not be reused for unrelated commercial purposes unless the bank has the right legal basis.

• Right to erasure and legal retention. GDPR Article 17 gives data subjects a right to erasure in certain cases, but it also includes exceptions where processing is needed for legal obligations or legal claims.

This is why tokenized deposit systems should keep PII off-chain and put only hashes, credentials, commitments, or proofs on-chain.

The main point is not that every jurisdiction will use the same rulebook. The point is that tokenized deposits will be judged as banking infrastructure only.

Why are banks so stressed about privacy and compliance with tokenized deposits?

Banks are stressed because blockchain design and banking design start from opposite assumptions. 

1st, Banks are legally mandated to protect client confidentiality under laws like GDPR and GLBA. On standard blockchains, wallet balances and transaction histories are public. But uploading standard deposit data to a shared ledger can trigger immediate compliance failures and multi-million dollar fines.

2nd, Corporations will not use a payment system that broadcasts their financial movements. Full visibility in public chains will allow competitors to see corporate payroll, supplier payouts, and mergers in real time. If enterprise clients refuse to adopt the platform because of this, it will permanently cap the deposit volume at retail levels.

3rd, Public financial trails could allow malicious actors to exploit liquidity flows. Because when large capital movements are visible before final settlement, arbitrageurs can front-run trades. If Institutions face slippage and financial losses for this, it will destroy trust in the tokenized ecosystem.

4th, Regulators will veto any un-auditable, completely anonymous financial system. Purely private, anonymous networks cannot fulfill AML or Counter-Terrorism Financing (CTF) obligations. If banks cannot verify the source of funds, it will result in regulatory shutdown of the pilot program.

Permissioned chains solve part of the problem. That’s why regulated finance is moving toward permissioned or semi-permissioned networks. They restrict who can join the network. They can gate users, limit validators, and enforce governance.  But permissioned does not automatically mean private. A validator may still see too much. And that creates the issue of interoperability. 

This excerpt from the Deposit Tokens report by Oliver Wyman and Onyx by J.P. Morgan, could be a best add-on here:

“Achieving economic fungibility among deposit tokens and/or off-chain deposits is not meaningful without sufficient technical interoperability to make actual exchange between different forms of money possible.

Technical interoperability will most likely occur between the issuing bank’s deposit tokens and its non-tokenized deposits, as a bank would naturally integrate its redemption process with its core banking system. This interoperability then extends to cash and other payment rails available through non-tokenized deposits.

The challenges of interoperability will be most pronounced in the exchange of tokens with different issuers, or the redemption of tokens for non-tokenized money by a bank that is not the original issuer….”

So one thing is clear: data privacy, data localization, interoperability, and asset leakage are key challenges for corporate blockchain adoption, and we need to find solutions. 

How to enable selective privacy and compliance for banks if they issue tokenized deposits?

Banks have two options. Though we believe many banks will need both. 

The first model is to choose a chain architecture that already gives the bank the right level of control, privacy, and interoperability.

The second model is to add a modular privacy layer that can sit between the banking application layer and the blockchain layer.

Model 1. Choose the right institutional chain structure

The market is moving toward three main corporate blockchain structures for tokenized deposit networks.

1.Third party institutional networks

The first path is to join or build on a third party institutional network. Networks like Canton, Rayls, Midnight, Hyli, and Provenance could be a few examples.

For example, Canton is a privacy-enabled, interoperable network for institutional applications and tokenized assets. Rayls positions itself as blockchain infrastructure for banks, RWAs, CBDCs, cross-border payments, and regulated liquidity. These two are public chains with your public nodes.

On the other hand, Midnight focuses on privacy-preserving applications with selective disclosure and zero-knowledge proofs. Hyli also describes itself as a privacy layer for private and compliant financial applications. We can call them privacy-first public chains.

Joining a third party network is best when a bank wants faster access to an existing ecosystem. It is also perfect for pilots where banks want to test how tokenized deposits interact with other tokenized assets, institutional money, or private settlements without building a whole network alone.

But don’t look at this as your permanent strategy for your core deposit infrastructure.

A third-party network means less control over roadmap, validator policy, governance, data visibility, privacy design, incident response, and commercial dependencies. It may also raise harder questions around legal finality, deposit liability transfer, jurisdiction, and supervisory comfort.

Source: Deutsche Bank: Digital Money Perspective

In short, third-party networks are for quick reach, testing, and access to the ecosystem. But if control, unique features, and true ownership of infrastructure is required, banks need to build their own bank chain or form a consortium network.

2. Consortium networks

A consortium network is the right fit when tokenized deposits need to move across multiple banks or institutions and follow common rules and standards.

Project Agorá is a good example of how this model works. Agorá is a BIS and IIF initiative with seven central banks and more than 40 banks and private enterprises. The goal is a unified ledger where tokenized deposits can interoperate with wholesale CBDC for policy aware, atomic cross-border settlement while preserving the two-tier banking system.

Then there’s Partior, which is already live and handles real-time international settlements with built-in checks to stop payment errors before they happen. Swift is doing something similar too, working on a shared ledger to help regulated banks move tokenized value at a massive scale.

The privacy and compliance logic for consortia is different from a 3rd party and bank-owned chains.

In a consortium, the challenge is not only whether the network is permissioned. The harder question is what each member can see.

• Bank A shouldn’t be able to spy on Bank B’s customer transactions.

• A validator should not automatically see every deposit movement.

• A corporate client should not expose supplier payments to other institutions.

• Regulators will obviously need to see data, but only through a strictly agreed-upon supervision model.

This is why consortium networks are complex to implement. Multi-bank tokenized deposit platforms depend on settlement assets, governance, rulebooks, and deep integration across messaging, controls, booking, and liquidity.

Zeeve can support consortium networks by helping design and operate the shared infrastructure layer. managing member nodes, setting up role-based access, running validators, and building the privacy tech that automatically enforces the network’s rulebook through code.

3. Bank-owned custom chains

This is the best fit when a bank wants maximum control.

A bank-owned custom chain gives the institution full control of the permissioning model, validator set, data residency, wallet eligibility, smart contract rules, compliance integrations, regulator views, and operating procedures.

Credit: Deutsche Bank

This is why large banks often start with internal or proprietary networks. This is the option J.P. Morgan Kinexys has also taken.

From a privacy angle, this model is attractive because the bank can reduce the number of parties who ever see transaction data. Client balances, treasury movements, liquidity sweeps, and internal settlement flows do not need to be exposed to a wider consortium or third-party network.

From compliance angle, banks can map the tokenized deposit system to their existing control stack. KYC data stays safely inside banks’ existing systems. They can run AML and sanctions checks before any transaction settles, and choose exactly how and when to give regulators or auditors access.

The limitation is interoperability and fungibility. If banks don’t plan for connectivity from day one, tokenized deposits won’t be able to talk to other banks, traditional RTGS networks, central bank wholesale money (CBDCs), or digital asset platforms.

Source: McKinsey: The emerging architecture of on-chain money

This is where Zeeve can help directly. For banks that want to own the chain, Zeeve can support custom blockchain infrastructure, managed nodes, validators, access control, monitoring, integrations, and production operations around the bank’s own privacy and compliance policies.

Model 2. Zeeve Privacy Layer as the modular privacy and compliance layer 

The network model creates the first boundary. But it does not solve everything.

Even on a private network, sensitive balances can still leak through node data, APIs, and transaction logs. On a consortium, banks can accidentally see each other’s metadata. On a public network, it’s possible to map out your transaction history.

Honestly, Institutional privacy cannot be handled by isolated tools for only tokens, identity, contracts, or the ledger. It needs a system-wide approach.

This is where a modular privacy layer becomes important. That Zeeve brings, and it can be integrated with any chain type.

Read More: What does Privacy in Blockchain mean for Financial institutions?

Zeeve Privacy Layer sits between the banking application and the blockchain network. It is designed as middleware across asset transactions, smart contract execution, identity validation, role based access control, observability, and selective disclosure. It can work with permissioned networks, enterprise rollups, and public blockchain networks.

For tokenized deposits, each component of it solves a specific privacy and compliance problem.

Confidential transaction privacy

A tokenized deposit transaction can reveal more than an amount. It can reveal payroll timing, supplier relationships, treasury positioning, collateral stress, acquisition activity, or liquidity movement.

Confidential transactions stop that data leakage. In a tokenized deposit system, the bank can allow a transfer to be validated without showing transaction details to every network participant. Only authorized parties should see the amount, counterparties, and metadata. Zeeve Privacy Layer is built for this exact use case, with transaction details and counterparties visible only to authorized parties for tokenized deposit like use cases.

Private smart contract execution

Tokenized deposits are not just payments. They can trigger automated actions like intraday credit, automated cash sweeps, margin top-ups, and interest payments.

If the smart contract logic is visible to everyone, the bank may still leak sensitive information even if the token balance is hidden.

Netting rules, collateral management, and request for quote terms should not be visible to every bank in a consortium. Private smart contracts keep the business logic and private data visible only to the parties involved, while only posting the final proof of settlement to the ledger.

This is important for tokenized deposits because workflow privacy is as important as payment privacy.

Decentralized identity and policy gated wallets

A tokenized deposit should not move to an unknown wallet.

The stronger model is to bind wallets to verified identities, institutions, accounts, or approved agents without placing raw KYC data on-chain. Project Guardian gives a very relevant example. In the FX pilot, J.P. Morgan issued SGD deposit tokens on a public blockchain, but the token and protocol were designed to restrict unknown parties. The smart contract only interacted with known blockchain addresses, and authorized parties had to attach a verifiable credential from the issuer.

That is the compliance model banks need. Keep PII inside bank systems. Put only credentials, proofs, and eligibility checks on-chain.

Zeeve Privacy Layer supports decentralized identity, so eligibility and compliance conditions can be checked without exposing sensitive private or institutional data.

Role based access at the infrastructure layer

Banks cannot rely only on front-end permissions. Data can leak through RPC calls, node access, internal tools, analytics dashboards, and explorers.

Role based access control needs to sit closer to the infrastructure. Zeeve supports secure RPC level access control, authentication, and role based permissions. This allows a bank to define different views for treasury users, compliance teams, auditors, technology teams, external counterparties, and regulators.

This is important in consortium networks where multiple banks may run or access infrastructure.

Selective disclosure and auditability

Total privacy will not satisfy regulators. Total transparency will not satisfy banks.

The right model is selective disclosure. A bank should be able to reveal specific transaction data to a regulator, auditor, or compliance team under defined rules. That disclosure can be limited by transaction type, time window, threshold, role, investigation, or audit request.

Zeeve Privacy Layer supports selective disclosure and auditability through defined mechanisms for regulators, auditors, and compliance teams.

This is the heart of privacy and compliance in tokenized deposits. The system stays private by default, but it is not blind to supervision.

Observability for compliance evidence

At the end of the day, you have to prove to auditors that the right compliance checks actually happened before money moved.

Zeeve includes observability as part of the privacy layer, not as a separate afterthought. This matters because production banking infrastructure needs to prove that privacy controls and compliance controls are working continuously.

How can Zeeve help with both or help decide what’s most optimal for banks?

Zeeve can help banks evaluate these choices and build the right infrastructure. We are the only provider that has multi-stack expertise. The Zeeve Privacy Layer is designed to support permissioned/ consortium networks, custom enterprise rollups, and public blockchain networks.

​For production, infrastructure maturity matters as much as privacy design. Tokenized deposits need reliable nodes, secure validators, key management, monitoring, incident response, disaster recovery, compliance reporting, and continuous support. Zeeve offers hardened environments for regulated industries, multi-cloud and hybrid deployment options, SOC 2 Type II, ISO 27001, and GDPR-compliant infrastructure, a 99.9 percent uptime SLA, and 24×7 NOC support.

Zeeve can help them choose the right network model, build or manage the infrastructure, integrate privacy controls, and operate the system with the reliability expected in regulated finance.

Book a call today to discuss how we can help with your tokenized deposit initiative.

​

1. How do tokenized deposits comply with existing KYC and AML regulations?

Tokenized deposits comply through the same controls banks already use for deposit relationships and payments.

The bank verifies the customer and does due diligence through their core banking system.

The blockchain layer only enforces the compliance result. For example, only wallets linked to verified customers should be allowed to hold or transfer tokenized deposits. Smart contracts can reject transfers where the sender or receiver does not meet policy rules.

2. Do banks need a new banking license to issue tokenized deposits?

A licensed bank usually does not need a new banking license just because it represents its own deposits on blockchain rails.

Banks should still engage regulators early. Even when a new license is not needed, the bank may need approvals, notifications, model risk review, technology risk review, or changes to product governance.

3.How do you do sanctions screening on a blockchain transaction?

Sanctions screening should not rely only on wallet addresses.

A bank should screen the legal customer during onboarding, screen beneficial owners, map wallets to verified parties, screen counterparties, monitor wallet activity, and rescreen customers when sanctions lists change.

OFAC notes that its sanctions compliance expectations apply to virtual currency activity. It also provides tools and guidance for sanctions list screening.

OFAC +1

In a tokenized deposit system, the smart contract should enforce the decision. The compliance system should make the decision.

The decision is not easy because tokenized deposits will still be the banks’ balance-sheet liabilities and must retain all existing legal, regulatory, and risk characteristics. Plus, add new capabilities like real-time settlement and programmable automation.

A pilot can be launched on almost any ledger. But a production-grade system requires a long-term view. A dedicated enterprise deployment partner, like Zeeve, can deliver banking-grade blockchains, absolute data privacy, and global interoperability without leaving banks’ legacy systems. 

This article helps banks make that decision more easily. It will answer all their queries, break down infrastructure decisions into 5 layers, and give architecture diagrams for tokenized deposit programs undertaken by banks. 

What are tokenized deposits? 

A tokenized deposit is our standard, commercial bank deposit represented on a bank’s blockchain. Economically and legally, it is identical to off-chain deposits and maintains a 1:1 par exchange rate with fiat currency. 

Source: Federal Register

Hence, they are a direct claim on the balance sheet of the issuing commercial bank and fall under standard deposit insurance schemes such as the FDIC in the United States. Unlike stablecoins, they support the bank’s fractional-reserve policy and credit creation.

The benefit is that by wrapping these liabilities in a blockchain interface, banks can make commercial money programmable and highly mobile. It becomes capable of settling peer-to-peer 24/7/365 (atomic settlement) without relying on centralized, batch-processed clearinghouses like the Federal Reserve’s ACH, which pauses on weekends and holidays. 

For a deeper dive into who it benefits, the use cases where tokenized deposits bring more value, and the regulatory readiness worldwide, visit our detailed article:

Why Banks Need to Tokenize Deposits? Who Benefits? 

What does a tokenized deposit infrastructure actually mean?

In a traditional bank, our balance sits inside a private SQL database or mainframe system called a Core Banking Platform. This system cannot naturally read, see, or interact with a blockchain. The tokenized deposit infrastructure is the multi-layered technology stack built to bridge this specific gap, along with addressing the key concerns that arise because of blockchain introduction. For example, privacy & compliance, custody, interoperability, etc.

Tokenized deposit infrastructure refers to the blockchain, middleware, compliance, privacy, integration, and operations stack required to issue, manage, and govern tokenized commercial bank deposits.

So if a bank asks what are the main infrastructure requirements for a tokenized deposit program, the answer  is not limited to token issuance, custody, or settlement alone. It includes the network architecture, smart contract logic, participant controls, privacy mechanisms, compliance workflows, interoperability rails, integration with core banking systems, and the operational layer required to run the system reliably.

We can divide the entire tokenized deposit infrastructure into 2 primary building blocks and 5 subcategories

Architectural Archetype:

1. Network Infrastructure (Private Chains/permissioned, Public chains, Hybrid Networks

2. Ledger Model / Data Structure

3. Smart Contract & Token Architecture

Other Infrastructure Decisions:

4. Privacy & Compliance: Selective Disclosure, ZK 

5. Integration Layer: with legacy core banking system through APIs + other enterprise connectivity (like Oracle, Digital asset custody stack like MPC, HSM, Account Abstraction, etc.), and interoperability with other banks and financial networks using Hyperlane-like integrations. 

Now lets look into each of them one by one. 

Network infrastructure:

Network infrastructure is the most important decision. Banks can use private or permissioned chains, public chains with institutional controls, or other hybrid models that combine public verifiability with private execution. 

Each model has a different tradeoff between control, interoperability, cost, and ecosystem access. 

1. Complete Public chains

Public networks offer open infrastructure, broad developer ecosystems, liquidity, and composability. They are attractive when the bank wants to support multi-party settlement, tokenized securities, institutional DeFi, or open network connectivity.

The challenge here is control. Tokenized deposits cannot behave like permissionless bearer assets by default. Banks need allowlists, identity checks, sanctions screening, transaction limits, and issuer controls. 

MAS Project Guardian showed that even when deposit tokens are used on a public blockchain, banks can restrict interactions to known addresses and require verifiable credentials. 

Source: Onyx by J.P. Morgan Analysis

So, Public chains can work when controls are built at the token, application, wallet, and RPC layers. They are best suited when interoperability and ecosystem reach matter more than full infrastructure ownership. But banks must plan for transaction fee volatility, public metadata exposure, chain governance risk, and finality assumptions.

A public-chain strategy should never start with the chain alone. It should start with the permissioning model.

2. Private and permissioned chains

Private and permissioned chains give banks more control over participants, validators, access rules, and data visibility. These networks are easier to align with internal risk, audit, and compliance requirements. They also give more predictable performance and cost.

This model works well for internal treasury settlement, closed-loop corporate payments, interbank consortium networks, and wholesale settlement among known institutions. Single-bank ledgers can support intra-bank transfers, and shared ledgers allow multiple institutions to interact on common rules and assets.

The tradeoff is network reach. A private network may solve the bank’s internal settlement problem. It may not solve cross-bank interoperability unless other banks join or external bridges are built.

Private infrastructure is the safest starting point for many banks. It is not always the best end state. The end state depends on how much external settlement the bank expects.

3. Hybrid networks / Custom-built public-permissioned chains

Hybrid networks try to combine institutional control with broader connectivity. 

So a hybrid chain could be 

• Public chains with permissioned applications, 

• Private execution with public anchoring, 

• Privacy nodes connected to public liquidity, or 

• Institutional networks with selective disclosure.

J.P. Morgan’s JPMD/JPM Coin rollout on Base is a useful example. The asset runs on a public Ethereum Layer 2, but is available to institutional clients and designed for regulated, permissioned use.

Source: JP Morgan

Let’s take an example of privacy-first public chains like Midnight or Hyli, which combine public-chain verifiability with confidentiality. They use zero-knowledge proofs, selective disclosure, or proof-based settlement to let institutions prove validity without revealing underlying data like balances, counterparties, business logic, or transaction metadata. 

Most of the examples in the market point in this direction. 

Another example could be public chains with private institutional nodes like the Canton network or Rayls. These architectures give institutions private execution, private ledgers, or controlled nodes, but also connect them to a broader shared settlement or interoperability layer.

For tokenized deposits, hybrid infrastructure is useful when banks need privacy, auditability, and institutional governance, but also want future connectivity to public ecosystems. This can be a strong fit for interbank settlement, tokenized securities settlement, cross-border liquidity, and regulated digital cash networks.

If you want to understand how any of these models works or which could be best suited for your bank, schedule a no-cost discussion call with Zeeve experts. 

Ledger model and data structure:

They are primarily two types. 

1. Account-based ledgers

Account-based ledgers are best for regulatory simplicity. Identity is attached to balances at the ledger or account layer. This maps well to existing banking records, account ownership, customer due diligence, reconciliation, reporting, and internal controls.

This model is useful when the bank needs every balance to map cleanly to a customer, corporate account, omnibus structure, or internal ledger. It is also useful for closed networks where participants are known and permissioned.

2. Token-based or UTXO-style ledgers

Token-based ledgers represent value more directly in the token. In UTXO-like models, settlement can be structured around discrete spendable units. These models can be better for atomic settlement, DvP, PvP, and complex multi-party workflows where counterparties do not share the same account architecture.

Blockchain deposits can also be native or non-native. Native records are blockchain records that act as the primary source of truth. Non-native records are on-chain mirrors of off-chain records. Native deposit tokens are promising because they are not limited by off-chain reconciliation processes and can use new blockchain functionality.

A bank architecture may need both patterns. They can start with account-based issuance, where regulatory clarity matters most. Add token-based settlement where DvP, PvP, or cross-network atomicity matters.

Smart Contract & Token Architectures:

The smart contract layer defines how tokenized deposits behave. They are not simple fungible token deployments.

For tokenized deposits, smart contracts should support pre-settlement controls. These may include KYC status, sanctions results, wallet eligibility, transaction value, velocity limits, user role, geography, product type, and issuer approval.

They must also support operational controls. These include maker-checker approvals, emergency pause, audited upgrades, key rotation, admin role separation, contract monitoring, and formal review.

What token standard should a bank use?

The following token standards can be used but one thing we need to keep in mind is, there is no universal token standard for tokenized deposits. The right standard depends on the use case type. 

ERC-20

Good for simple fungible transfers, but compliance must be added through custom controls.

ERC-1400

More suitable for regulated financial instruments because it supports partitions, operator controls, and forced transfers.

ERC-3643 / T-REX

Useful where identity-linked transfer restrictions are required.

Custom permissioned token contracts

Often appropriate for bank-led or consortium-led networks where the participant set is closed, and role-based controls are more important than public composability.

Other Infrastructure Decisions

Privacy and compliance Infrastructure

Privacy and data localization are one of the biggest corporate adoption challenges and one of the hardest parts of tokenized deposit infrastructure. Because, 

• Banks cannot expose sensitive metadata of counterparties, volumes, pricing, and supply chain information. Jurisdictions may restrict also where data can reside and who can see it.

• At the same time, regulators, auditors, compliance teams, and internal control teams need visibility.

That creates a design dilemma.

The infrastructure must keep transaction data confidential from unauthorized parties and also make the right data available to the right supervisory and control functions.

For tokenized deposits, privacy must operate across multiple surfaces.

It has to cover 

• asset transfers. 

• balances. 

• smart contract execution.

• identity checks. 

• API access. 

• RPC endpoints. 

• observability logs and dashboards. 

• disclosure workflows.

This is the right framing because institutional privacy cannot be solved only at the token level.

Zeeve’s Privacy Layer is a perfect solution to institutional privacy and compliance challenges. It treats privacy as modular middleware and can be integrated with any blockchain type below your application layer. 

Learn More: how confidential transactions (ZK), role based access, selective disclosure and private smart contracts work in Zeeve Privacy Layer.

These features of Zeeve privacy layer are useful here to keep sensitive data private without losing on-chain utility of tokenized deposits. 

Because a private chain is not automatically a private workflow, privacy must be designed across the full system. Because even if your network is private, the validators can still see the transactions and participants. 

Integration layer

Core banking integration infrastructure

Tokenized deposit infrastructure does not replace core banking. It integrates with it.

The core banking system remains the system of record for deposit liabilities, customer accounts, interest treatment, regulatory reporting, treasury management, and balance sheet controls. The blockchain layer becomes the programmable settlement environment.

This needs API-based integration with legacy systems like, FIS, Finastra, Temenos, Mambu, in-house cores, treasury platforms, and compliance systems. REST APIs, webhooks, message queues, and event streams can connect on-chain actions with off-chain banking records.

Every mint, transfer, and burn needs a corresponding entry in the bank’s system of record. This reconciliation architecture can take longer to design and test than the smart contract layer.

This is why banks should design reconciliation before choosing token standards.

Integration with external enterprise tools

Tokenized deposits also need enterprise connectivity beyond core banking.

• For example, institutional custody is critical. Banks need MPC, HSM, remote signing, key rotation, quorum approval, transaction policies, and recovery workflows. 

• For corporate users, account abstraction can improve wallet usability, delegated approvals, role-based signing, and pre-programmed payments.

• The policy engine should do KYC/AML screening before any transaction settlement. The rules may include sender identity, receiver identity, balance, value threshold, velocity, sanctions result, jurisdiction, instrument type, business purpose, and approval status.

• Oracles can be important when payment depends on external data like, any rates or prices, delivery confirmation, securities settlement status, collateral values, or any corporate workflow events.

• Observability also matters. Banks need dashboards, logs, alerts, SLA monitoring, incident runbooks, transaction tracing, audit exports, and compliance evidence.

And all these together builds the regulated financial infrastructure for tokenized deposits.

Interoperability with other banks and financial networks

Tokenized deposits create the most value when they can move across counterparties.

A single-bank token can improve internal treasury movement. A shared ledger can improve settlement within a consortium. A broader interoperable network can support cross-bank payments, tokenized securities settlement, cross-border treasury, collateral mobility, and liquidity management.

Interoperability will be needed between traditional finance systems and blockchains, across different chains, and with other assets on a given blockchain. But multiple bridging and wrapping can introduce operational and technical risk.

This is where Hyperlane-like integration concepts become relevant. Hyperlane is an interoperability framework that supports asset bridging and message passing across many chains and virtual machines and Zeeve enable this for its enterprise customers.

A bridge that moves value but breaks compliance is not bank-grade interoperability. A messaging layer that carries instructions without legal finality is not enough either.

KYC, AML, privacy and control has to be there in every layer. 

Banks should ask early whether every new counterparty requires a custom integration or whether the platform supports standardized connectivity from the start.

A decision table: What Questions Banks Should Ask a Tokenized Deposit Blockchain Infrastructure Provider?

So when banks evaluate tokenized deposit infrastructure, they are really evaluating a full-stack infrastructure requirements:

How Zeeve helps banks deploy tokenized deposit infrastructure

Zeeve helps banks design, deploy, and operate tokenized deposit settlement infrastructure across private, permissioned, public-permissioned, and hybrid architectures.

The value starts with infrastructure advisory. Banks do not need to choose a stack in isolation. They need to match architecture with use case, privacy needs, regulatory obligations, transaction volume, finality needs, and interoperability goals.

Zeeve can support banks across the full stack.

• Multi-stack advisory across permissioned, public-permissioned, rollup, appchain, and hybrid architectures

• Managed blockchain network deployment and operations

• Zeeve Privacy Layer

• API and event integration with core banking, treasury, custody, and compliance systems

• Interoperability support with other banks, financial networks, and cross-chain messaging layers

• 24 by 7 monitoring, upgrades, observability, SLAs, and operational support

The goal is to help banks launch tokenized deposits without forcing them into a single chain, a single architecture, or a disruptive replacement of core systems. If your bank is looking to launch a tokenized deposit program, connect with Zeeve to discuss how we can help!

As a result, to date, they have not been able to control unpredictability in payments , compliance duplicity, operational opaqueness  and  settlement delays. 

Fintech players see this as an opportunity and they are using the flexibility they get to innovate quickly  which this Visa Report justified since they have already captured 53% of the market share.

Now adding stablecoins in their operations has the potential to further amplify their already existential  dominance in the  cross border payment market. 

This blog will highlight how these Fintechs are intending to use stablecoins in this arrangement to make sure that they take this dominance to the next level; 

How Top Fintech Players Plan to Use Stablecoins In Cross Border Payments?

For fintech leaders, stablecoins for cross-border payments can be grouped into four useful templates.

• Consumer remittances and P2P transfers

• B2B supplier and merchant settlements

• Payroll, contractor, and gig-economy

• Corporate treasury and liquidity management 

Let’s look into them.

1.Stablecoins As An  Integration Layer For Compliance and Legacy System Integration/ Consumer Remittances

A research survey was conducted by EY, involving  80% of the corporations. Out of them,   52% and 45% who  participated said that  fast cross border transfers  and reduced payments costs  excite them the most to use stablecoins since it can provide them with a competitive edge over their peers.

But the toughest part is to natively introduce  it in their business because they face the following challenges; 

• Integrating   Stablecoins with Traditional ERP is Highly Complex: Corporates are widely using the ERP system, which means, to use stablecoins, they need to make their own arrangements to handle reconciliation. Which boils down to setting up a manual process for the same or building their own infrastructure to support the transition.

• That’s why from corporates to financial institutions, as per the 2025 EY Report, they have explicitly said that if something can be done in stablecoin integration which can let them  seamlessly migrate or integrate with their existing infrastructure using API/ or any other means,  they would be eager to adopt it. 

• Regulatory Ambiguity & Compliance: Regularity ambiguity and compliance hurdles are a few notable  challenges that  businesses are forced to go through  who are eager to use stablecoins. Why?  Because regulations are not uniform across regions, thereby, forcing businesses to respond to every jurisdictional requirement, which could be hard  considering the fact that for such enablement, they would have to create custom infrastructure from the ground up for the same. 

That’s why more than 3 out of 4 CFOs refrain from using stablecoins due to regulatory concerns as per 2026 Payments report. 

As a result, businesses are looking for ways through which they can bypass these challenges while making stablecoins native to operation. But that can only happen when they get a smooth integration option with the integration partner managing infrastructure and compliance, while the respective business just having to pay for the use of the infrastructure. 

Fintechs are slowly emerging as a panacea  to help fulfill this demand. For example, Stripe, which is already a prominent payment platform, has provided infrastructure rails  as an integration layer through which businesses can natively introduce  stablecoins in their operations in cross border payments  and they do not have to create  an infrastructure for the same. 

Stripe is providing an integrated infrastructure layer known as bridge through which stablecoins could be used for payments and settlements.

So far, Felix, and Shopify  have used this benefit of Stripe to use stablecoins in cross border payments.  Stripe facilitates the operations in the following manner using the bridge layer; 

How the business works with blockchain?

A remittance provider can use a stablecoin rail in five steps.

• The sender pays in fiat through card, ACH, bank transfer, or wallet balance.

• The provider performs KYC, sanctions checks, fraud checks, and quote locking.

• The provider converts fiat to a stablecoin through an issuer, exchange, treasury desk, or infrastructure partner.

• Stablecoins move on-chain to a payout partner, treasury wallet, or recipient wallet.

• The final mile happens through local bank deposit, cash payout, mobile wallet payout, or direct stablecoin delivery.

Is any other company / service provider doing the same?

1. PayPal and Xoom

PayPal added PYUSD as a funding option for U.S. Xoom users. Users can fund eligible cross-border transfers by converting PYUSD to USD, and PayPal said Xoom recipients could receive funds in local currency in about 160 countries with no Xoom transaction fee for eligible transfers.

2. Felix and Circle

Félix uses USDC as an alternative to SWIFT for U.S. to Mexico and Latin America remittances. Circle’s case study says Félix uses Circle Mint, Stellar, and Bitso to convert USDC into Mexican pesos, enabling near-instant payout and reducing the need to prefund large peso balances.

2. Stablecoins for Settlements in  B2B Supplier & Merchant Payments 

B2B appears to be the largest real payment category for stablecoins today.

B2B stablecoin payments move money between businesses, merchants, platforms, acquirers, payout networks, and suppliers. The stablecoin can be visible to the receiver, or it can operate as a settlement rail while the business still sees fiat balances.

CoinDesk’s North America stablecoin landscape report says B2B payments accounted for 62.9 percent of total stablecoin payment activity at the end of 2025. 

Juniper Research projects cross-border B2B stablecoin transaction value to grow from 13.4 billion dollars in 2026 to 5 trillion dollars by 2035.

How the business works with blockchain?

A B2B stablecoin settlement flow usually works like this.

• A buyer, platform, or payment company initiates a supplier or merchant payout.

• The payment orchestration layer checks invoice data, beneficiary data, risk rules, and corridor rules.

• Fiat is converted into a stablecoin, or an existing stablecoin balance is used.

• The stablecoin is transferred to a merchant acquirer, supplier wallet, payout partner, or settlement account.

• The receiver either holds stablecoin, converts to local currency, or receives fiat through an off-ramp.

• ERP, accounting, and compliance systems receive a transaction ID, timestamps, wallet data, and settlement status.

Despite banks’ massive control over the  B2B payment markets for suppliers and merchants, a whopping 77% of the B2B suppliers and 49% of merchants have shown interest to abstract away and  use faster rails for settlement, if available,  to overcome the following  challenges; 

• Float Time Delay: Float time delay is the inability to access the funds because the ACH/Wire transfers cannot be completed on holidays and weekends. As a result, financial impact is massive with an average firm/business losing $39,406 because of late payments. 

• Interchange fees: Merchants have to incur very high interchange fees revolving around 1.5–3.5% per transaction. Which can be grossly offsetting for businesses working  with thin profit margins. 

• Operational inefficiency: Operational inefficiency is a major burden on businesses because their financial teams  have to match different invoices with the funds that have been credited to them. Which results in a significant loss of working hours and inflates the operational expenses. 

So, sablecoins are gradually emerging as noble solutions. For example, have a look at how stablecoins perform in comparison to other payment rails that B2B suppliers and merchants are using at the moment. 

That’s why Fintechs are closely working with  stablecoins because   regulatory clarity is maturing  in the US and Europe and this is the opportunity that Fintechs don’t want to miss. Why? Because at the moment, the US and EU account for  43% of global GDP and 30% of global cross-border trade, a fintech innovation enabling B2B supplier & merchant payments could instantly open the door of opportunities. 

Let’s take the example of BVNK. They are a prominent name innovating to provide an edge to B2B suppliers & merchants through the introduction of stablecoins as a Fintech  for undertaking faster payment processing at a fraction of the cost. 

They have rolled out the following features:  

(i) Enhanced fiat payment traceability with tracking references 

(ii) Recurring wallet transaction reports 

(iii) Treasury Rules Engine 

(iv) Rewards: Earn passive income on idle funds 

(v) Clear verification failure reasons for individual onboarding, which B2B suppliers are merchants can harness. 

And when B2B and merchant use  BVNK platform, their settlement experience transforms as shown in the image below because of the use of stablecoins; 

Due to their instant settlements in fiat/stable advantage that merchants and B2B suppliers are getting,  the BVNK platform has processed  $30B in annualized stablecoin payment volume spread across 2.8 million transactions so far.

Are there any other players using stablecoins for settlements? 

1. Visa and BVNK

BVNK announced that it is powering stablecoin services inside Visa Direct, which is Visa’s 1.7 trillion dollar money movement network. 

The integration supports stablecoin funding for fiat payouts and stablecoin wallet payouts. BVNK contributes stablecoin infrastructure, compliance tooling, and settlement capability, while Visa provides the global money movement network.

2. Visa, Worldpay, and Nuvei

Visa expanded stablecoin settlement with Circle’s USDC, added pilots with Worldpay and Nuvei, and used Solana and Ethereum for settlement between partners. 

Visa had already moved millions of USDC between partners to settle fiat-denominated payments authorized over VisaNet.

3. Stablecoins For Automation and Compliance Management in  Payroll and Gig Economy 

Payrolls are not broken; rather, they are stuck with the technology meant for the 80’s & 90’s while operating in the age where settlements are required to be instantaneous and automated. That’s why many business organizations are facing imminent risks like; 

• Operational Inefficiencies: Since the business has to manage multiple bank accounts, they have to additionally hire employees for processing these transactions, which can put pressure on their cost of operation. 

• Compliance and Penalty Costs: With business enterprises having to operate in different jurisdictions with  different  rules and regulations, it  becomes harder to instantly settle payments despite the payments reaching the respective correspondent bank. As a result, despite the  fault of their own, more than   53% of the businesses are forced to pay penalties for failing to meet the compliance requirements. 

• Inflation Burden: Gig workers/ freelancers who are working in emerging economies like Nigeria have to face major hurdles when they are getting remitted for their services. For example, as per the Nigeria Tax Act (NTA) 2025, the gig workers are forced to report their earnings in native currencies like Naira, exposing them to the risk of inflation. That’s why the majority of freelancers/ gig workers  are looking forward to alternatives to help them protect from this vulnerability.  Which means, businesses are increasingly pressurized to either transform or look out for  smart ways to resolve this problem,

Stablecoins are playing a major role in solving these problems by integrating natively with the payroll processing systems to answer compliance challenges, manage inflation by allowing users to hold their earnings in stablecoins in their wallets and even allow businesses to skip the hassles of managing multiple bank accounts by streamlining payments in stablecoins. 

So far, Rise has been the most prominent and successful name to mention because they have allowed payment processing in stablecoins from day one. They are supporting payments in USDC and USDT across Arbitrum, Ethereum, Polygon, Optimism, and Avalanche. Stablecoin payouts typically settle in 15–90 seconds. 

With Rise, the Employers can deposit the payrolls in one chain and the contractors have the discretion to withdraw it from the same or any other chain in their preferred mode from crypto assets to even fiat money. 

In 2026, Rise hit $1 B in payroll processing with the platform processing payroll in the following manner; 

Are there any other players using stablecoins for Payroll settlements? 

Alongside Rise, Request Finance, Niural/EMMA and Khazna are also other key players with Khazna specially designed to meet the needs of gig workers in emerging economies. While Request Finance handled normal payrolls with the track record of touching $1 M in 2026. 

4. Corporate Treasury & Liquidity Management

As per JP Morgan’s report, corporates are moving across $23.5 trillion in value using traditional means like ACH  and incurring $120 billion in fees. But despite paying such a huge fees, they face considerable challenge in managing their treasury and ensuring optimum liquidity because of the following issues with traditional payment rails; 

1. Fragmented Cash Management: Since corporations have to keep cash  dispersed across multiple bank accounts spread across jurisdiction, it is very hard to bridge communication with all such accounts due to correspondent banking networks  and inability to establish quick communication to initiate payment and transfers for goods and services or payrolls. 

2. Trapped liquidity: The corporates are forced to hold cash in non productive accounts just to meet operational efficiencies in different regional operations. Which results in trapping a lot of liquidity which they could have used for taking productive business decisions and expanding operations. 

3. High Transaction Cost: They have to further incur high transaction cost as well because for keeping cash in different banks located in different locations, they have to incur the expense of the compliance like KYC and AML imposed  on them. 

However, this can change upon the availability of fast mover money rails that can instantly help corporates and businesses manage their liquidity  and treasury in real time without having to wait for days for settlements. 

stablecoins are perfectly aligned because they use blockchain ledgers  which enable corporations to instantly manage liquidity while remaining compliant in the process. But the problem with corporates handling stablecoins is the heavy lifting that they have to do to set-up the infrastructure to enjoy faster settlements and quick money movement. 

That said, Fintechs are trying to fill up that void where corporations can quickly get all the benefits of faster settlements and better ways to manage investments without having to set-up an infrastructure for the same. 

And in this orchestration, Circle has launched the Circle Payments Network (CPN), which is a stablecoin settlement solution allowing businesses to handle their treasury and liquidity without the burden of managing the compliance. 

With this, not only corporations are able to get faster payment rails for undertaking cross border payments but also other trade-offs like Yield-Bearing Liquidity for treasuries. Which means, now corporations can keep their liquidity in high yield bearing accounts and instantly settle payments for business supplies or other activities using Circle as a payment layer in the following way; 

So far the Circle Payment Network has reached $3.4 billion annualized transaction volume and is expected to reach $5.7 billion by Q1 2026.  New corridors are also opening up  in Brazil, Nigeria, China, Colombia, Hong Kong, Mexico, India, the Philippines, Singapore, and the EEA with 100+ participating companies spread across multiple sectors using Circle’s CPN Network for corporate treasury and liquidity management. 

Are there any other players using stablecoins for Corporate Treasury & Liquidity Management?

Anchorage Digital,  and Coinshift are other few names who are also innovating in the treasury and liquidity management space with stablecoins alongside Circle. Though they haven’t achieved such high trade volume, they are making sizable contributions nonetheless as Fintech players using stablecoins. 

Since we know that stablecoins have moved from experimentation to real payment infrastructure, a bigger question emerges now,  who actually controls the cross-border payment stack in this new model if you wish to explore this?

The Emerging Stablecoin Payment Stack: Who Controls the Rails and Captures Value?

1. Issuance Layer (Money Creation)

• Controlled by players like Circle (USDC), Tether (USDT)

• Providing:

  • Liquidity

  • Trust

  • Regulatory alignment

With time, this layer is becoming the equivalent of central banks in digital dollars. 

2. Infrastructure & Orchestration Layer

• Stripe (Bridge), BVNK, Circle CPN, Zero Hash

• Providing:

  • Wallets

  • Compliance

  • On/off ramps

• This is where maximum developer and enterprise adoption is happening

Thereby making it  the  “AWS of payments” for decentralized operations. 

3. Application Layer (Fintechs & Platforms)

• Shopify, Rise, fintech apps, payroll platforms

• Providing:

  • User experience

  • Distribution

  • Customer relationships

This  layer is ending up as the front line face of Fintech innovation

4. Settlement Layer (Blockchains)

• Ethereum, Polygon, Arbitrum, Stellar

• Providing:

  • Finality

  • Speed

  • Cost efficiency

Emerging as a commoditized layer to build Fintech solutions with stablecoins, value shifts upwards with time. 

So, how would you like to progress, in case, if you are not aware, let a technology partner  help you and that’s where Zeeve leaves no stones unturned. 

Build Your Fintech Solutions using Stablecoins with Zeeve For Cross Border Payments

With a SOC2 and ISO-aligned operating posture, Zeeve is well positioned to help bring enterprise rigor to Web3 infrastructure. With expertise across multi-stack:  public, private, hybrid, and ZK-enabled systems, we can help you build your Fintech  product  using stablecoins to revolutionize the  B2B supplier, payment, merchant, payroll, cash management or any other segment that you wish to disrupt. 

With Zeeve’s Privacy Layer, we also ensure that while undertaking product innovation, you do not have to compromise with compliance and regulations and fail later. So, if you have an idea in mind where you want to integrate stablecoins for resolving industry problems , we are here to help 

Zeeve has already powered 20+ production chains processing 2B+ transactions monthly, and we have the capability to generate the same results for  you too! Schedule a call today if you are looking for a reliable technology partner that can help you innovate while staying compliant!

Early projects simultaneously sparked excitement about tokenization’s potential and exposed weaknesses in a piecemeal approach. A 2024 Deloitte article discussed projections that "tokenization in financial services could generate trillions of dollars in new value this decade" and proofs of concept from several financial institutions. It also outlined key challenges to widespread tokenization, including regulatory compliance risks, transparency and privacy conflicts and a lack of interoperability standards. ​

PROMOTED

The early token implementations I’ve seen don’t include payment and settlement functionality. They either use stablecoins across the board or deploy a system that combines tokenized assets and traditional payment rails. But tokenizing assets without modernizing the payment infrastructure creates a broken process. Part of the process uses blockchain fintech while the rest is still rooted in legacy banking. ​

An IBM report stated that “2026 will be a turning point for tokenization.” Yet traditional banks are still falling behind: “Most incumbent institutions are saddled with core banking systems and processes built for a pre-tokenized economy. Despite billions invested, most banks remain mired in protracted modernization programs.”​

It’s now time to modernize the industry’s entire financial infrastructure, from assets and payments to treasury operations and cross-border remittances. I predict that the financial services industry is on the cusp of a massive change; in the next couple of years, we will see the tokenization of assets quickly picking up steam, followed by the tokenization of payments and settlements. ​

My Web3 infrastructure company works with a customer that has investments from five large banks. Through my work, I see clear signs that institutions are moving from implementing individual use cases to completely upgrading their tech stacks. Major banks are launching tokenized deposits as a programmable alternative to stablecoins, capable of handling payments and settlements while operating within current privacy and regulatory frameworks. ​

But leaders at many midsize banks that I have conversations with are still oblivious to this trend. This puts leaders at a disadvantage. There is a window of opportunity with tokenization, but it won’t stay open forever. I want enterprise leaders to understand the opportunities and obstacles of a tokenized financial infrastructure while there is still a first-mover advantage.

The video player is currently playing an ad.

Understanding Public Chains Versus Blockchains

A common misconception I hear about tokenization is that it is a privacy risk. Bank leaders often fear that assets are tokenized on a public blockchain—which would expose their customer data and violate compliance regulations. But this isn't the case at all. ​

My team and I teach leaders that most use cases at the bank level require them to develop their own custom chain. I encourage leaders to build privacy and compliance into their infrastructure from the beginning, so they can stay competitive with new technologies without compromising any regulatory rules.

Seeing The Business Case For Tokenization

Major banks are already moving trillions of dollars in tokenized deposits within the traditional banking system. The world's largest asset manager has tokenized billions of dollars of treasury funds to trade on-chain. ​

We’re already seeing the benefits of tokenization being realized in the financial services industry, and I believe we will soon see the same transformation in enterprises across other sectors. A fully tokenized, on-chain financial infrastructure would enable true 24-hour markets with real-time transactions, unlock greater liquidity and facilitate cross-border payments without intermediaries.

Finding The Right Starting Point

For banking leaders unsure where to begin, I recommend focusing on tokenized deposits first. By tokenizing existing deposits for corporate customers, where the transaction size is higher, they can focus on managing the corporate treasury as well as customer retention and new customer acquisition. Once a deposit layer is in place, banks can expand into payments. ​

I frequently meet with tech teams and business teams that have distinct perspectives on building a tokenization infrastructure. These are the critical questions I think they should be asking: ​

Tech Teams

• How will this process work with our core banking systems?

• How can we manage privacy at an infrastructure level?

• How can we manage operations from a risk perspective?​

Business Teams

• How will this implementation affect our bottom line?

• How will this help us acquire and retain more corporate customers?

• How can we use this infrastructure to develop new products and services?

I think it's a mistake to wait for the perfect time to build a tokenized infrastructure. There is no perfect time. There will always be challenges to overcome. But it is the right moment to get started. It's not an exaggeration to say that in a few years, the entire financial services infrastructure will be modernized using blockchain. Banks that take the lead now have an opportunity to keep that lead in the long run.

Both sides are partly right. However, framing this as a zero-sum game is a fundamental misunderstanding of how global finance works. The market is entirely distracted by a format war that simply does not exist. 

Banks multiply money. Stablecoins move it. Institutional finance requires both to function at scale, and the ongoing arguments miss this thin line.

This article will break down exactly how these two technologies serve entirely different but complementary purposes. We will discuss the origins of this debate, analyze the unique features of both instruments, and outline a clear framework for how financial institutions can leverage both. 

To understand why the industry is so divided, we must look at how these two technologies evolved from completely different ecosystems

Stablecoins were born out of necessity in the unregulated markets of early crypto trading. Because banks were initially hesitant to interface with digital asset exchanges, traders needed a digital dollar substitute that could move instantly across borders. Over time, these instruments grew from niche trading tools into massive global settlement layers. DefiLlama showed a total stablecoin market capitalization of about 320 billion dollars in late April 2026. 

The Stablecoin proponents view legacy banking rails as inherently slow, expensive, and burdened by unnecessary intermediaries. 

On the other side of the aisle, financial institutions recognized the undeniable efficiency of blockchain as a technology but could not accept the counterparty risks associated with private, non-bank stablecoin issuers. Banks are heavily regulated, subject to strict capital requirements, and backed by deposit insurance frameworks. To bring commercial bank money on-chain safely, they developed tokenized deposits. 

Their belief is that everyone will naturally prefer heavily regulated banks the moment those banks tokenize their own liabilities. Many central banks and other financial institutions may favor this narrative because it preserves the existing two-tier monetary system. 

Both of these rigid viewpoints completely miss the point. They fail to recognize that the global economy relies on two distinct functions that cannot be handled by a single instrument in the 21st century. 

The table below from Citi’s Stablecoins 2030 report makes the different money formats clear:

Tokenized Deposits as the Credit Multiplier Inside Bank Perimeters

To understand the true value of tokenized deposits, we must return to the foundational business model of commercial banking. Banks do not hold money in a vault. Banks create cheap credit.

When a corporate client deposits funds into a traditional bank, those funds enter a fractional reserve system. A $100 deposit allows the bank to generate $90 in new loans to other participants in the economy. This multiplier effect is the engine of global economic growth and the core driver of commercial banking profitability. If a Fortune 500 company parks $500 million at a major tier-one bank, they get huge credit lines in return at highly favorable, below-market interest rates. 

Tokenized deposits keep this economic multiplier on-chain. When a bank issues a tokenized deposit, it is creating a programmable, digital representation of a commercial bank liability. The bank retains the underlying capital and can continue to lend against it. The corporate client gains the ability to move that value instantly on a blockchain, but the underlying liquidity remains safely inside the bank’s regulatory perimeter.

The table below, from the Federal Reserve and Citi Institute, points out the deposit substitution risks banks are trying to mitigate with Tokenized deposits. 

This model is incredibly powerful, but it comes with a strict limitation. Tokenized deposits are designed for bank customers operating within known, regulated environments. They are the perfect instrument for institutional treasury management, internal liquidity optimization, and automated corporate finance. CitiGroup’s estimates that bank token transaction volumes could reach $100 to $140 trillion annually by 2030, driven almost entirely by these massive institutional flows.

The strongest argument for tokenized deposits is elasticity. They can expand and contract the money supply through lending. Stablecoins fail this test by design. When a digital asset is backed by cash and short-term Treasuries, it moves value efficiently but creates absolutely zero credit.

Stablecoins as Portable Cash Outside Traditional Rails

While tokenized deposits are good at credit creation, stablecoins are built for pure portability. They function exactly like digital cash in the open market.

Major stablecoin issuers operate on a 100 percent reserve model. For every digital dollar issued on a blockchain, the issuer holds a dollar equivalent in a highly liquid reserve, like holding massive quantities of short-term government debt. A major issuer might hold $200 billion in Treasury Bills and capture a 4 to 5 percent yield on those assets while paying the actual token holder zero percent interest.

Because stablecoins are fully backed, the credit multiplier effect disappears entirely. The trade-off is unmatched global mobility. Users get programmable money that operates far outside the perimeter of any single bank.

This portability solves problems that traditional correspondent banking cannot touch. Stablecoins work anywhere there is an internet connection. They can settle transactions 24/7/365 days a year. Nobody has to ask a centralized clearinghouse for permission. This is why over $9 trillion moved cross-border via stablecoins in 2025 alone.

Below is a great example of Stablecoin Sandwich model from OpenFX report, where fiat remains on both ends of the transaction, and stablecoin settlement in the middle. 

Why the Stablecoin Vs Tokenized Deposit Fight Is a Distraction?

The debate over stablecoin vs. tokenized deposits is a costly distraction because it forces builders to choose between credit creation and global mobility. The truth is that the institutions that are building the future of enterprise finance must build for both.

A tokenized deposit user wants regulated rails only, which severely limits the reach of digital money across open global networks. A stablecoin user wants to completely kill banks, which would destroy the fractional reserve lending system that funds the vast majority of global business operations.

Smart financial institutions see these not as mortal enemies but as two distinct revenue streams. Banks and FinTechs are uniquely positioned to dominate the entire tokenized money bucket by absorbing both technologies into their infrastructure.

Instead of resisting the change, tier-one institutions could pivot to a dual strategy. 

• First, they issue tokenized deposits to serve their massive institutional clients who demand yield, regulatory certainty, and credit creation. 

• Second, they provide the essential banking infrastructure required to make the public stablecoin economy function.

Stablecoin issuers absolutely need regulated banks for custody, reserve management, and fiat conversion. By offering these services, banks could change what was once considered a threat into a highly profitable fee-generating business line. FinTechs play a crucial role here by building the agile software layers that connect legacy banking systems to public blockchains.

Below is an interesting take from OpenFX report on Visa’s Airport Strategy. It highlights how integrating all stablecoins into a network makes the institution the airport rather than just another airline. It proves that institutions that try to pick a single winner will miss out on half the market.

The CXO Blueprint for Mapping Assets to Outcomes

To build this composable future, banks and fintech CXOs must stop arguing over formats and start mapping business requirements directly to the optimal asset. The institutions that win this decade will be those that provide the seamless connective tissue between these distinct environments.

Consider the following implementation blueprint

This framework proves we do not need a single winner. When you map the right asset to the right problem, the results are undeniable. 

For example, corporate treasuries using tokenized deposits are already executing fully automated foreign exchange transactions outside of traditional banking hours. Implementations of these on-chain solutions have helped enterprises cut bank accounts in half and capture over 20 million dollars in annual savings. Furthermore, as autonomous agentic commerce goes mainstream, software agents will absolutely require this exact blend of programmable money to execute supply chain payments.

The banks and FinTechs taking action are not waiting for the dust to settle. They are building the infrastructure to support this matrix of use cases right now.

Build Your Stablecoin Or Tokenized Deposit Use Case with Zeeve

With a SOC2 and ISO-aligned operating posture, Zeeve is well-positioned to help bring enterprise rigor to Web3 infrastructure that you need to build your custom use cases driven exclusively by stablecoins or tokenized deposit money rails. 

Our expertise to work across public, private, hybrid, and ZK-enabled systems ensures that no matter the use cases that you want to target, you can easily get the technology infrastructure that can fill up the demand. 

In addition to this, Zeeve is also providing privacy preservation while launching your stablecoins or tokenized deposit solutions through the  Privacy Layer.  So, if you have an idea in mind where you want to integrate stablecoins for resolving industry problems, or you want to launch tokenized deposits to fulfill institutional demand,  we are here to help 

Zeeve has already powered 20+ production chains processing 2B+ transactions monthly, and we have the capability to generate the same results for you, too! 

Schedule a call today if you are looking for a reliable technology partner that can help you innovate while staying compliant!