This is the third post in our series exploring on-chain banking. Read the previous entries here and here. 

On 9 July 2026, Swift announced a shared-ledger pilot built on Hyperledger Besu and involving 17 banks. The first transaction was completed on 19 August between HSBC and Standard Chartered.

To date, adoption of tokenized deposits has been slower than adoption of stablecoins. Swift’s entry could change this: it has the potential to bring tokenized deposits into the mainstream by giving banks a familiar network through which to issue them.

But the shared ledger doesn’t remove the operational work required to issue and manage tokenized money. It changes where that work happens and makes the distinction between the network’s role and the bank’s role increasingly important.

What Swift has built—and what it enables

Swift’s shared ledger is a significant development for tokenized deposits. The pilot brings together 17 banks across six continents, including HSBC, Citi, DBS, MUFG, OCBC, UOB, Standard Chartered and ANZ.

The model is designed to support the continuous movement of tokenized value, including outside traditional banking hours. The last leg of the underlying funds’ movement can then take place through established correspondent banking arrangements and existing settlement rails.

Swift’s greatest advantage is its reach. More than 11,500 institutions already use the Swift network. By introducing shared-ledger capabilities through an established global network, Swift gives banks a more familiar, conceivably less risky and more streamlined route into tokenized deposits.

That scale is likely to make the question more urgent for many institutions: if tokenized deposits begin moving through networks their counterparties already use, how will their bank participate?

What does Swift provide—and what remains the bank’s responsibility?

Swift has positioned its shared ledger as an orchestration layer for bank-issued tokenized deposits. The network connects participating institutions and enables tokenized-value instructions to move continuously between them. Swift has also partnered with Chainlink to support interoperability between the network and the blockchain environments banks choose for their tokenized deposits.

However, Swift does not issue or manage each bank’s tokens.

Individual banks remain responsible for:

• Creating and redeeming their tokens
• Managing the complete token lifecycle
• Tracking customer-level ownership
• Synchronizing token positions with the underlying funds
• Reconciling activity with the core banking platform
• Posting the appropriate entries to the general ledger
• Applying compliance, risk and operational controls

The network connects banks to one another. Each institution must still build or obtain the bank-side infrastructure required to issue and control its own tokenized money.

How does settlement work?

In the initial model, the tokenized transaction and the final settlement of funds are distinct steps.

The shared ledger can record and communicate the movement of tokenized value almost immediately, at any time of day. The underlying funds can then settle through existing correspondent banking relationships and established Swift rails.

You can view this is as a two-step process:

1. The shared ledger records the transfer and the receiving bank’s claim.
2. The underlying funds settle later through the existing banking system.

This isn’t an entirely novel concept. Most card transactions also separate the immediate authorization of a payment from the later clearing and settlement of funds.

The receiving bank is unlikely to hold another institution’s tokenized deposit indefinitely. It may redeem the incoming token and convert it to fiat, or redeem it and issue its own tokenized deposit so the value remains tokenized while moving onto the receiving bank’s balance sheet.

This creates an important operational requirement: the bank must manage the period between receiving the tokenized value and receiving the underlying funds.

How does the shared ledger work with ISO 20022?

ISO 20022 provides a rich, well-established format for exchanging payment data. It can carry information about the payer, beneficiary, purpose of payment and other details needed for compliance and processing.

However, using ISO 20022 does not by itself make the underlying payment system operate continuously. Processing still depends on the operating hours, controls and settlement arrangements of the institutions involved.

In the initial shared-ledger model, the token information and ISO 20022 message are sent at the same time on separate rails. The receiving bank needs to connect the token and ISO 20022 message to process the transaction.

Each component serves a different purpose:

• The shared ledger records the movement of tokenized value.
• The ISO 20022 message provides the payment, beneficiary and compliance information needed to process it.
• Existing rails complete settlement of the underlying funds.

Bringing these components together can improve visibility and allow tokenized-value instructions to move outside conventional processing windows. But the end-to-end process may still be constrained by its slowest component, particularly when the underlying funds settle through existing infrastructure.

This is the first iteration of the shared-ledger model. It will likely evolve as participating banks gain experience and identify where on-chain infrastructure can deliver the greatest operational benefit.

What do banks need to manage between the token transfer and final settlement?

If the shared-ledger transaction completes almost immediately but the underlying funds arrive later, banks need to address two important areas.

1. Customer attribution and funds in transit

The network may see a single aggregate position or institutional wallet for each participating bank. Internally, however, the bank must know exactly which customer owns each balance.

That requires customer-level attribution behind the bank’s network position.

The bank must also account for funds in transit. It receives a token before the underlying funds settle, it needs policies governing how that token can be used during the gap.

Those policies may depend on:

• 
  The bank’s bilateral relationship with the originating institution
• The creditworthiness of the originating bank
• The type of tokenized deposit involved
• The status of the underlying settlement
• The bank’s liquidity and counterparty-risk policies

The receiving bank also needs controls that prevent value from being spent twice or made available before the corresponding position is sufficiently secured.

2. Redemption, conversion or reissuance

Once the transaction is complete, the receiving bank must determine what happens to the incoming token.

It could:

• 
  Redeem it for fiat
• Convert the incoming token and issue its own Tokenized Deposit

If the bank redeems the incoming token and mints its own, the deposit can remain tokenized while moving from the originating institution’s balance sheet to the receiving institution’s balance sheet.

That process requires coordinated lifecycle management. The bank must know when the incoming token has been redeemed, when the new token can be issued, and how both actions correspond to the underlying movement of funds.

What operating model does a bank need?

Supporting the Swift shared ledger requires more than connecting to a network endpoint.

On the sending side, a bank must be able to:

• 
  Confirm the customer’s funds
• Issue or transfer the token
• Update the customer’s balance
• Create and release the corresponding ISO 20022 message
• Record the transaction for reconciliation and reporting

On the receiving side, the bank must be able to:

• 
  Ingest the ledger state change
• Receive and match the ISO 20022 message
• Identify the beneficiary
• Screen the incoming credit in real time
• Decide how to treat the token before final settlement
• Reconcile the token position when the funds arrive
• Redeem, hold or reissue the value according to its operating model

These processes must remain aligned even when the bank’s core is running batch processes or is otherwise unavailable.

That creates a need for an always-on, bank-side system that can maintain the authoritative customer and token positions between the core, the network and the underlying settlement rails.

Where does the E6 Token Control Ledger fit?

Swift has built the network and given the industry a credible path toward interoperable tokenized deposits.

But the network does not provide each participating bank with its issuance, lifecycle-management, customer-attribution and reconciliation capabilities. Those responsibilities remain on the bank side.

The E6 Token Control Ledger™ is designed to provide that bank-side operating layer.

Positioned between the bank’s core platform and the wallets or networks it connects to, it can:

• 
  Track customer-level ownership behind the bank’s aggregate network position
• Manage token creation, holding, transfer, redemption and retirement
• Maintain an always-on system of record when the core is offline or processing in batches
• Reconcile tokens held in wallets with customer balances, the bank’s network position and the funds backing them
• Support funds-in-transit controls
• Connect the bank to multiple products, networks, rails and consortiums through a consistent operating model
• Orchestrate token activity across currencies and supported blockchain networks

This allows the bank to adopt tokenized deposits without requiring its core to become a real-time token platform.

The bank can retain its existing processes, controls, reconciliation practices and keys while adding the infrastructure needed to operate continuously across token networks.

The network is only one part of the model

Swift’s shared ledger could give tokenized deposits the global connectivity needed to move from pilot programs to wider adoption. But connectivity alone is not enough.

Every participating bank still needs to issue and control its own tokens, track customer ownership, manage funds in transit and reconcile token activity with its core, general ledger and underlying settlement position. Swift provides the interbank network. The issuance and control layer remains the bank’s responsibility.

The banks best prepared for this model will be those that can build that layer once—and use it across whichever tokenized-deposit networks emerge next.

Coming up next in this series is an insight into best practices around approach.  

About the Author 

AJ Taylor is Senior Director of Emerging Payments at Episode Six. Since entering the cards and payments industry in 2005, he has created the world’s first airline multicurrency card and is now focusing on the next horizon of payment innovation. 

About Episode Six 

 Episode Six is The World’s Local Processor ®. As a global provider of enterprise-grade card issuing and ledger infrastructure for financial technology companies, banks, and brands,  Episode Six delivers the innovative capabilities needed to compete with disruptors and lead the market. Flexibility, adaptability, and resilience are built into the core of Episode Six's platform, ensuring clients maintain a market-leading position. Episode Six operates in over 50 countries, powering millions of accounts and billions in payments globally, with an  expanding team located in the US, Canada, UK, Europe, Japan, Singapore, Hong Kong, Australia, and India. Investors include HSBC, Mastercard, SBI Investment Co Ltd, Anthos Capital, Avenir, and Japan Airlines.