Besu, as a permissioned enterprise blockchain framework, has been a prominent choice among banks and financial institutions for years now. In 2026, we have so many big names across the use cases.
But why Besu, and what are banks actually using it for?
Well, before we get into the use cases, let us understand why Besu is relevant to financial infrastructure in the first place.
Has Anybody Used Besu for Financial Use Cases
Well, yes.
Besu was originally contributed by ConsenSys to the Hyperledger community in 2019. Today, the project sits under LF Decentralized Trust and is known simply as Besu, although many people still call it Hyperledger Besu.
Its relevance to finance comes from a useful combination of features.
First, a bank can run Besu as a private, permissioned network. This means that the network does not have to be open to anonymous participants. Only approved institutions can operate nodes or submit transactions.
Second, Besu supports consensus mechanisms such as QBFT and IBFT 2.0 that provide deterministic finality. In simple words, once the required validators agree on a transaction, the transaction is final. A bank does not have to wait and wonder whether the ledger might reorganize itself later.
Third, Besu is compatible with the Ethereum Virtual Machine. This allows institutions to use smart contracts, token standards, development tools, and a much larger technical ecosystem than they would get from a completely isolated platform.
So, has this infrastructure moved beyond just pilot use cases?
Yes.
Citi Token Services for Cash has been commercially live in select jurisdictions since October 2024. It uses a private Besu network for near real-time transfers of tokenized interbranch deposits.
Swift has also built its shared ledger on an EVM-compatible architecture based on Besu. The ledger became ready for live use by participating banks in July 2026.
In the same month, DTCC converted assets held at DTC into tokens and processed real production trades on its private Besu network.
The Eurosystem has also tested DLT-based wholesale settlement in central bank money, while central banks in markets like Thailand and Australia have used Besu in sovereign digital-currency experiments.
So, yes, Besu has moved beyond the stage where its only achievement is a successful proof of concept.
But what exactly are these institutions building?
These implementations cover different areas of finance, but they are solving a related problem. They are trying to make assets, money, and transaction rules work together on infrastructure that can operate continuously.
Let us look at the five most relevant use cases.
Use Case 1
24 by 7 Interbank Cross-Border Settlement
Cross-border payments pass through several institutions before reaching the beneficiary. Each institution maintains its own ledger, applies its own controls, and updates its own records. The payment may also be affected by local operating hours and market cut-off times.
The result is a process in which the payment message can move quickly, but the actual settlement and reconciliation can take much longer.
Besu can provide a common transaction layer for tokenized commercial bank deposits. Instead of waiting for separate systems to update one after another, participating institutions can share a synchronized record of the transaction as it progresses.
Citi Token Services for Cash is a working example of the model inside a global bank. Citi represents deposits held at participating branches as tokenized interbranch deposits and moves them on its private Besu network. This allows value to be transferred across branches and time zones on a 24×7 basis.
The client does not have to hold any deposit token or interact directly with a blockchain. The client continues to use the bank through existing channels. The change takes place within the settlement infrastructure behind those channels.
Another big example is SWIFT. They are working on the interbank version of this idea. Its shared ledger connects tokenized deposits issued by participating banks on their own ledgers. It gives those banks a synchronized view of payment obligations and helps coordinate the movement of funds before final settlement takes place through existing systems.
This is an important point.
The shared ledger does not have to replace every payment system already used by a bank. It can coordinate those systems and remove the delays created when each institution processes the same transaction separately.
So what’s the benefit for banks here? Continuous settlement and better liquidity visibility. For corporate clients, the benefit is that international payments can be completed outside the narrow operating windows that still influence correspondent banking today.
Use Case 2
Digital securities and their secondary market
Suppose a bank owns a US Treasury security held at a traditional depository.
The bank wants to trade it, lend it, or use it as collateral on a digital platform. Does the security have to abandon the regulated custody system and begin a completely new life on a blockchain? Not necessarily.
A digital twin model can avoid that problem. What’s that?
Well, under this model, a token represents a security that continues to be held at a traditional depository. The token carries the same economic interest and ownership rights as the underlying asset. It can then be used in digital trading, settlement, lending, and collateral workflows without removing the original security from its existing legal and custody framework.
DTCC is the pioneer here. They have converted some assets held at the Depository Trust Company into tokens and used them in real production trades. More than 30 firms participated.
The tested transactions included equity transfers, equity DvP, equity delivery-versus-delivery, securities lending, collateral pledges, a US Treasury repo DvP trade, and CCP margin workflows. They were processed across DTCC’s private Besu network and a public chain as well.
Why is Besu relevant here?
Because a digital asset needs more than a record of ownership. It also needs rules.
A smart contract can check whether an investor is eligible to hold the asset. It can enforce transfer restrictions, connect a securities transfer to its payment, and support the asset through events such as pledging, lending, and settlement.
The traditional depository continues to protect the legal ownership of the security. Besu provides the programmable transaction layer through which its digital twin can be used.
This allows institutions to modernize secondary market activity without discarding the market structures on which they already rely.
Use Case 3
Wholesale Central Bank Money and DvP Settlement
A securities transaction is not complete merely because the buyer and seller have agreed to it. The security must be delivered, and the corresponding payment must be settled.
Delivery versus payment, or DvP, links these two actions. The security should move only if the payment moves, and the payment should move only if the security is delivered.
This becomes more complicated when the asset and money exist on different systems. A tokenized bond may sit on a Besu network, while the cash used to settle it remains on a central bank payment system.
The two systems must therefore exchange a reliable confirmation of final settlement.
The Eurosystem tested this model between May and November 2024. According to the European Central Bank, 64 market participants explored 58 use cases involving nearly €1.6 billion in central bank money settlement.
One of the participating platforms was SWIAT, the financial market network initiated by DekaBank and built on Besu. SWIAT was connected to the Deutsche Bundesbank’s Trigger Solution. The security was processed through the DLT platform, while the corresponding cash leg was handled through the central bank settlement environment.
This is where deterministic finality becomes very important.
Before central bank money can be released, the payment system must know that the asset transfer is final. Besu can provide that certainty once the required validators have approved the transaction.
The confirmation from the Besu network can then trigger the cash movement. In this way, a transaction taking place across two systems can still be settled as one coordinated process.
The central bank does not have to move its entire payment infrastructure onto Besu. The DLT network does not have to create a private substitute for central bank money. Each system performs its own role, while the connection between them provides synchronized DvP settlement.
Use Case 4
Intraday Repo and Collateral Mobility
A repurchase agreement, or repo, is a short-term secured loan.
One institution sells a security for cash and agrees to buy it back later at a higher price. The security acts as collateral, and the price difference is the financing cost.
Many repo transactions are arranged overnight or for a longer period. However, banks frequently need liquidity for only a few hours during the business day.
Intraday repo allows a bank to borrow for that shorter period. To make this efficient, the collateral must be identified, valued, transferred, and returned without depending on several disconnected and manually reconciled systems.
Smart contracts can automate much of this workflow. They can check whether the proposed security is eligible, apply the required haircut, release the cash after the collateral is transferred, and reverse the transaction at the agreed time.
DekaBank and NatWest Markets tested this model during the ECB trials. They completed two DvP intraday repo transactions through the Besu-based SWIAT network and the Bundesbank’s Trigger Solution.
DekaBank and LBBW also completed a bilateral repo in which a traditional security was tokenized on SWIAT. The cash leg was settled in central bank money.
DTCC later included Treasury repo DvP, collateral pledging, and margin activity in its July 2026 production transactions that we mentioned above.
But why is this considered one of the most valuable financial use cases for tokenization?
Well, collateral is only useful when an institution can move it to the place where it is needed. Correct?
If the same asset can move between custody, trading, lending, repo, and margin workflows through a programmable representation, the bank does not have to repeatedly record and reconcile that asset across different systems.
This can reduce the amount of time collateral remains locked, improve its availability during the day, and help a bank manage short-term funding more efficiently.
Therefore, the value of a Besu-based repo platform does not come merely from placing repo transactions on a blockchain. It comes from making collateral programmable and mobile throughout its financial lifecycle.
Use Case 5
Retail and Wholesale Sovereign CBDCs
Until now, we have mostly discussed commercial-bank money and privately issued financial assets.
A central bank digital currency, or CBDC, is different.
A tokenized deposit remains a liability of a commercial bank. A CBDC is a direct liability of the central bank. So legally and financially, they are not the same thing.
Wholesale CBDCs are designed for transactions among banks and other eligible financial institutions. Retail CBDCs are intended for broader use by households and businesses through regulated intermediaries.
Both of these models require controlled participation. They need a careful balance between confidentiality and regulatory visibility.
Besu has been used in several sovereign digital currency experiments because a central bank can operate it as a permissioned network while retaining smart contract programmability.
Thailand and Hong Kong used Besu during the second phase of Project Inthanon LionRock. This work later developed into the multi-CBDC initiative known as mBridge. According to Atlantic Council data, they have processed 55.5 billion dollars in payments till November last year.
The Bank of Thailand said that Besu was selected because of its open Ethereum foundation and its ability to connect with other DLT systems.
The project tested how financial institutions could transfer wholesale central bank digital currencies across borders without depending on the existing chain of correspondent banking relationships.
Australia also used Besu in Project Atom, which examined the use of wholesale CBDC for the settlement of tokenized assets.
These projects show that Besu can support sovereign digital money infrastructure. They also reveal one of the most important requirements that must be addressed before such infrastructure can operate at scale.
A permissioned network controls who can participate. It does not automatically ensure that every participant can see only the transactions relevant to them.
This distinction matters in both wholesale and retail CBDC systems. Banks should not be able to view the positions and transactions of competing institutions. Retail users must not have their financial activity exposed to unrelated network participants. At the same time, central banks and regulators must retain the access required for supervision and compliance.
Therefore, permissioning alone is not enough. A financial Besu network also needs selective privacy.
Choose Zeeve for Your Besu Implementation with Privacy Layer Integration
Besu provides several of the capabilities required for modern financial infrastructure. It supports permissioned participation, deterministic settlement finality, smart contracts, tokenized assets, and integration with the wider EVM ecosystem.
But the Besu client alone does not provide a complete banking infrastructure.
A production network must also address validator governance, node security, key management, monitoring, disaster recovery, regulatory reporting, data residency, core banking integration, and transaction privacy.
Privacy is also important in a consortium network. The participating institutions may trust one another to validate the ledger, but they are still competitors. Right? Customer balances, payment amounts, collateral positions, and commercial terms cannot be visible to every member.
Zeeve helps banks and financial institutions design, deploy, and operate Besu networks across managed cloud, Bring Your Own Cloud, on-premises, and hybrid environments. Its infrastructure is aligned with ISO 27001 and SOC 2 Type II controls and allows institutions to deploy the network within their approved security and compliance perimeter.
Zeeve also provides Tegaris, a modular privacy framework that adds controls across four areas of the blockchain infrastructure.
At the application layer, it controls access to applications, RPC endpoints, and explorers. At the network layer, it manages validator, peer, and node participation. At the ledger layer, it restricts access to sensitive smart contract states. At the asset layer, zero-knowledge proofs can protect details such as transaction amounts, balances, and counterparties while allowing authorized parties to validate the transaction.
Zeeve can help an institution define these requirements, select the right Besu architecture, integrate the required privacy controls, and operate the network at institutional scale.
Zeeve has helped a big US bank with their tokenization initiative. Schedule a call with our experts to discuss your use case.
