How Tokenized Deposits Are Changing Cross-Border Payments

Key Takeaways

• Cross-border payments are the strongest early use case for tokenized deposits that remove sequential messaging, pre-funded correspondent accounts, and time-zone cut-offs.

• Tokenized deposits combine the payment instruction and the money itself into one transferable object. Banks can settle directly with each other instead of relaying instructions through correspondent chains.

• Most cross-border volume today moves inside a single bank’s global network. Like HSBC TDS. But SWIFT and Project Agorá are two viable models of cross-bank transfers.

• Most live cross-border designs, though, keep each bank on its own ledger and add a coordination layer above it. Final interbank settlement still completes through existing rails.

• The most difficult challenges to address are cross-issuer fungibility, the legal transferability of deposit claims, and multi-jurisdictional governance. These factors will determine how far this model can scale.

Cross-border payments are a primary use case for tokenization because traditional correspondent banking has long been inefficient.

The reason is well known. There are frictions in international payments that come from how the system is built. Payment instructions and the actual money travel separately through a chain of multiple banks. Each bank in that chain has its own operating hours, compliance checks, and record-matching processes. Tokenized deposits attack that structure directly by putting regulated bank money on shared ledger infrastructure, where the instruction and the value can move together.

This article explains what breaks in cross-border payments today, what tokenized deposits change, how a tokenized payment works, the architectures behind it, which implementations are live, and what still stands in the way.

Why Do Cross-Border Payments Still Take Days and Cost So Much?

A typical cross-border payment passes through a correspondent banking chain. The sending bank rarely has a direct relationship with the receiving bank, so the payment relays through one or more intermediaries. Each hop adds a compliance check, a fee, a reconciliation step, and often a day.

The aggregate cost is large. In 2020, moving US$23.5 trillion across borders cost US$120 billion and took two to three days to settle on average. Speed has improved since then. As of 2023, 89% of cross-border payments on the SWIFT network reached the beneficiary bank within one hour using ISO 20022 messaging standard and gpi tracking, which is above the G20 and FSB target of 75% by 2027.  84% of these payments were direct or used only one intermediary. 

But reaching the beneficiary bank is not the same as funds being usable by the beneficiary, and faster messaging does nothing about the capital sitting idle behind the transaction. 

For example, Wire 365 can process eligible payments continuously within J.P. Morgan’s correspondent network. Swift can deliver the payment instruction to the beneficiary bank within minutes. Domestic instant-payment systems like FedNow or RTP can complete the final local payout almost immediately. But none of these, on their own, makes the entire cross-border transaction one real-time settlement process across banks, currencies, FX systems, and jurisdictions. 

The cost of it falls unevenly across stakeholders.

• Correspondent banks fund nostro accounts across currencies and time zones. That capital is unavailable for anything else, and it must be sized for peak flow rather than average flow.
• Corporate treasurers lose access to working capital because of this same requirement to pre-fund accounts. They must also work around varying operating hours in different markets, and they often cannot see the exact foreign exchange rates or fees added along the payment path.
• Beneficiary banks absorb the downstream cost of fixing errors, process returned payments, and manually investigate issues when payment data is missing or incorrect.
• Banks in smaller economies face the sharpest version of the problem, because correspondent relationships in thinner corridors are fewer, more expensive, and more likely to be withdrawn.

None of this is caused by a lack of technology. It is caused by an operating model where value and information are held in different systems and reconciled later on. 

As per BCG estimate of B2B cross-border payment with FX settlement, addressable cross-border flows now represent an estimated US$30 trillion in annual volume, and it’s growing at around 5 percent per year. Tokenized deposits can help stakeholders tap into that pool with lower cost and friction. 

What Tokenizing Deposits Changes in a Cross-Border Payment

A tokenized deposit is a commercial bank deposit recorded and transferred on a blockchain ledger, where the token itself evidences a claim on the issuing bank.

The most significant change for cross-border payments is that the deposit token contains both the payment instruction and the financial value. Combining information and value reduces the need for third-party intermediaries to match separate data and payment flows across banking systems. Fewer matching steps lead to fewer errors and less manual work to resolve issues.

Three consequences will follow.

Availability changes. Tokenized ledgers run continuously. Transactions can process overnight, on weekends, and during holidays without waiting for standard clearing windows to open.

Liquidity requirements change. Processing funds immediately rather than over a two-day cycle reduces the cash buffer needed for delays. Institutions and corporate customers can manage treasury cash more efficiently, reducing the capital locked up during multi-day settlement periods.

Payment logic changes. Smart contracts allow conditions to be attached directly to the movement of funds, which supports payment-versus-payment execution on an FX leg or release against a delivery confirmation. This is important because the design objective of a tokenized deposit-based cross-border payments application is to test whether compliance checks, liquidity management, and settlement can occur simultaneously through programmable money, rather than sequentially through correspondent banking chains.

In this entire setup, what does not change is the regulatory treatment. Tokenized deposits remain a bank liability inside the existing deposit-regulatory perimeter, and they can be interest-bearing. For a corporate treasurer, that means the balance behaves like the bank money already on the books. So it doesn’t require a separate reserve structure, unlike stablecoins. 

How a Cross-Border Payment Works With Tokenized Deposits

This can be easily understood from a single bank ledger example. The end-to-end flow has five steps.

1. Instruction. The corporate initiates a payment from its ERP or treasury management system through the bank’s channel, the same way it does today.
2. Mint. The bank debits the conventional deposit account and issues an equivalent tokenized deposit to the client’s wallet on a permissioned ledger. The deposit claim is still the same. Only the record and the transfer method have changed.
3. Control. Compliance check happens at the token level instead of at every transfer step. Transfer restrictions are written into the token contract and the transaction protocol, so tokens interact only with approved addresses.
4. Transfer. The token moves to the beneficiary’s wallet. Where an FX leg is involved, the two currency legs can be linked so that neither settles unless both settle.
5. Redeem. The beneficiary either holds the token or redeems it, at which point the token is burned and a conventional account is credited.

The simplest single bank tokenized deposit network example could be HSBC’s Tokenized Deposit Service, which is live in five markets with six currencies available and further expansion to key hubs planned. Clients processed approximately US$28 billion in tokenized deposit payments through the service in the first quarter of 2026, according to HSBC Global Payment Trends Report 2026.

Their TDS uses a single-bank ledger, so a payment from a corporate’s Singapore entity to its UK entity settles in HSBC’s own internal records only. No external rulebook has to be negotiated, and legal finality is governed by their own terms only. This kind of single-bank model reached production first, and adoption today is concentrated where parties operate within a single-bank environment or a tightly governed bank network.

The harder problem is a payment between clients of two different banks in two different jurisdictions. Three such examples we have covered in the sections below, along with how all three are structurally different. 

What Architecture Is Needed for Tokenized Cross-Border Payments?

A production architecture must connect the token to the issuing bank’s balance sheet, coordinate transfers across institutions, complete interbank settlement, and preserve compliance.

The ledger design is the first major factor. A single-bank ledger only handles transfers between customers of that one institution. A shared or compatible ledger allows multiple banks to transact using the same technical standards. In that setup, assets stay on separate ledgers, and an orchestrating entity sends transfer instructions to both systems at the same time. A public/common ledger can reach more users, but it requires extra controls for user identity, data privacy, and asset transfers. These different ledger designs will likely be used alongside each other.

An orchestration layer coordinates the transaction. When banks use separate but compatible ledgers, the money stays on each bank’s own system while the orchestrator sends matching instructions to both networks at the same time. When banks use a shared ledger, the tokenized deposits and settlement assets are recorded on a single system that all participating banks can access.

The first model can preserve institutional autonomy. The second can make atomicity easier but creates more demanding governance and concentration questions. SWIFT, Agora, or Partior-like examples below are building this layer.

Integrations will decide whether the infrastructure is usable. The ledger must connect with core banking, RTGS, and wholesale-CBDC systems (if available) and follow ISO 20022 messaging standards. A blockchain transaction has little business value if existing bank systems cannot work with it.

Privacy and governance must be designed into the system. Banks need confidential balances and transaction details, while regulators and compliance teams require appropriate access. The framework therefore needs permissioned identity, selective disclosure, key management, audit records, smart-contract controls, incident response, and predefined override procedures that only network-level access control can’t provide. It requires a system-wide privacy approach. Zeeve Tegaris brings this. Learn about it here.

Which Cross-Border Implementations Are Live Now

SWIFT’s shared ledger. According to SWIFT, its blockchain-based ledger became ready for initial use as of July 2026, with 17 banks from six continents preparing to pilot live transactions using tokenized deposits. SWIFT is using an EVM-compatible architecture based on Hyperledger Besu to build this shared network. 

Their ledger is designed as an orchestration layer for bank-issued tokenized deposits held on each bank’s own ledger, allowing funds to move for customers overnight and on weekends before final settlement completes through existing systems.

So SWIFT here doesn’t create a new settlement asset. Banks retain authority over keys, assets, funding, and final settlement through RTGS systems and existing correspondent arrangements.

Project Agorá. Coordinated by the BIS and the IIF with seven central banks and more than 40 banks and private enterprises, Agorá is designing a unified ledger where tokenized deposits interoperate with wholesale CBDC for atomic cross-border settlement. 

Its specific test is whether compliance checks, liquidity management, and settlement can run simultaneously through programmable money rather than sequentially through correspondent banking chains. 

Agorá is the more ambitious architecture, because it puts commercial bank money and central bank money on shared infrastructure while preserving the two-tier system.

Partior. Founded out of Project Ubin by J.P. Morgan, DBS, and Temasek, Partior operates live for real-time cross-border settlement of tokenized deposits, adding pre-validation and atomic settlement to reduce breaks and investigations. Partior acts as the interoperability and clearing layer here, and the tokenized deposits never technically leave the bank perimeter. 

If we consider a JPMC USD to a DBS SGD tokenized deposit transfer, the moment your JPMC USD token is locked or destroyed on the Partior network, the smart contract automatically forces DBS’s node to instantly mint and release an equivalent amount of DBS SGD tokens to the receiver.

So there is zero settlement risk. The trade clears instantly because both banks’ internal ledgers are bound by the same piece of smart contract code running on Partior.

Read together, all of them tell a consistent story. Nobody is trying to replace the settlement system. They are building coordination layers above it.

Here’s a side-by-side comparison of SWIFT Vs. Project Agora Vs. Patrior with their blockchain initiatives.

Feature	Swift Shared Ledger	Project Agorá (BIS)	Partior
Asset Type	Tokenized Commercial Deposits	Both Commercial Deposits & Central Bank Reserves	Tokenized Commercial Deposits
Settlement Speed	Asynchronous: Messaging is instant (24/7), settlement happens later.	Real-Time Atomic: Simultaneous delivery of payment and settlement assets.	Real-Time Atomic: Immediate Payment-versus-Payment (PvP) settlement. (Cross-currency)
Who Runs It?	Swift (A global bank-owned cooperative).	Central Banks (BIS) alongside private commercial banks.	Private Consortium (Founded by J.P. Morgan, DBS, Temasek, Standard Chartered). It’s a FinTech.
Primary Technology	Hyperledger Besu (EVM-compatible network).	Multi-chain / Interoperable Unified Ledger blueprints.	Proprietary Private Enterprise DLT.
Main Goal	Stop banks from building fragmented networks; secure SWIFT’s role as the global coordinator.	Create a unified, programmable global monetary platform backed by central banks.	Commercial efficiency; provide instant multi-currency clearing for corporate banking.

If the network scales, SWIFT could expand its role from financial messaging and payment tracking into ledger-based transaction orchestration.

Its advantage is that it already connects more than 11,000 institutions across over 200 countries and territories. That reach could help banks coordinate tokenized deposit payments without joining a different network for every corridor.

However, adoption will depend on whether banks can align on common operating rules, privacy, and legal standards. This leaves room for networks such as Partior to gain adoption in specific currencies and corridors where the participants can move faster.

Challenges of Tokenized Deposit-Based Cross-border Payments

Legal transferability is the binding constraint. Moving a deposit token beyond the issuing bank’s own client base requires explicit legal treatment and appropriate disclosures, and institutions must evidence the deposit-law basis of the instrument. Until that is settled corridor by corridor, tokenized deposits will stay inside individual banks or closed consortia.

Interoperability is the second. Banks have said that each institution running its own private chain makes interoperability the single biggest challenge they face globally. A network of isolated tokenized ledgers reproduces the fragmentation it was meant to remove.

Liquidity management is the third, and it is often underestimated. Continuous settlement and 24/7 availability reduce a bank’s ability to smooth liquidity through end-of-day cycles, which raises the importance of real-time liquidity management and effective central bank backstops. Treasury teams built for a batch world will need different tooling and different intraday limits.

Zeeve for Unbiased Consultation and Privacy-Enabled Blockchain Infrastructure

Cross-border payments will be improved by moving value and information together, under bank-grade controls, with settlement still anchored in central bank money. That is what every pilot implementation in 2026 is building toward, and it is why the infrastructure decisions made now will determine which corridors a bank can serve later.

The decision that carries the most weight is whether the architecture can hold permissioning, privacy, and integration with existing settlement systems at the same time.

Zeeve works with financial institutions on exactly that layer. This includes privacy-enabled tokenized deposit infrastructure, institutional-grade blockchain deployment on ISO 27001- and SOC 2 Type II-compliant infrastructure, Bring Your Own Cloud so institutions retain control of their environment, and migration support where legacy blockchain infrastructure needs to be replaced.

Zeeve is an LF Decentralized Trust member with deep experience in Hyperledger Besu and Fabric. It is also an official implementation partner of Cosmos Labs for the Cosmos Tokenization Suite. This gives banks access to a purpose-built tokenization stack with support for capabilities such as ISO 20022 signing and integration with existing payment systems. Zeeve has also supported a large US bank on its tokenization initiative.

Schedule a call with Zeeve to discuss the right architecture for your cross-border payment requirements.