On 9 July 2026, the Society for Worldwide Interbank Financial Telecommunication (Swift) announced that its blockchain-based shared ledger was ready for initial use, with 17 banks preparing to pilot live transactions. Its first use case leverages bank-issued tokenised deposits to support cross-border payments around the clock, including overnight and on weekends. Crucially, the announcement noted that after customer funds are moved, banks will complete final settlement through existing systems.[1]
Throughout August and September, participating banks began announcing successful live transactions. As the shared ledger enters real-world operational testing, its underlying settlement arrangements offer a clear window into its actual functionality and intended use cases.
While Swift is extending its services into the coordination of interbank transaction states, payment commitments, and execution conditions, what money customers actually hold, what assets banks use for interbank discharge, and precisely when discharge achieves legal finality remain outside the scope of what the shared ledger itself resolves.
Therefore, we must examine where the shared ledger is truly added in the payments stack, which problems it solves, and which responsibilities must still be handled by commercial banks, correspondent banks, and central banks.
I. Swift Connects Financial Messages; Money Is Booked on Bank Ledgers
The primary role of traditional Swift has always been enabling financial institutions to exchange standardized financial messages securely and reliably. It provides a messaging network, technical standards, and related services; it does not hold funds on behalf of customers, nor does it manage bank accounts.[4]
Banks send payment instructions across Swift. Those instructions are then processed by the relevant institutions, triggering corresponding debits and credits on their respective books. Message delivery, bank acceptance of a payment order, beneficiary access to available funds, and the ultimate interbank discharge of obligations can all occur at different points in time.
Suppose Company A holds an account with Bank A in Country A, and wishes to pay US$100 to Company B, which holds an account with Bank B in Country B. Assume there is no direct account relationship between Bank A and Bank B, but both institutions hold US dollar accounts with Correspondent Bank C. For simplicity, this stylized example excludes foreign exchange conversion and transaction fees.
Bank A transmits a payment instruction to the relevant institutions. The subsequent sequence of ledger entries can be summarized as follows:
- Bank A debits Company A's deposit account by US$100, while crediting (reducing) its own deposit balance held at Bank C by US$100.
- Bank C debits Bank A's account by US$100 and credits Bank B's account by US$100 on its own books.
- Bank B debits (increases) its asset balance held at Bank C by US$100, and credits Company B's deposit account by US$100.
From Bank A's perspective, the account it maintains with Bank C is a Nostro account ("our account at your bank"). From Bank C's perspective, that exact same account is a Vostro account ("your account on our books"). They describe identical account relationships from two reciprocal viewpoints.
In this payment, Bank C reduces its liability to Bank A while expanding its liability to Bank B. Provided both institutions agree under their correspondent account agreements to accept this book transfer as valid discharge, the interbank obligation is settled across Bank C's balance sheet without necessarily triggering a transfer of central bank reserves.
If the two banks used different correspondent banks, or settled across central bank accounts, the process would further involve the transfer of central bank reserves. Reserves represent central bank money held by commercial banks—an entirely different tier of value from the commercial bank deposits held by end customers.
Thus, a cross-border payment entails three distinct layers of activity: the transmission of payment instructions (messaging), clearing and processing, and settlement. Clearing generally encompasses message transmission, reconciliation, verification, and netting; settlement discharges the outstanding obligation through the transfer of an agreed settlement asset.
Receiving a payment message merely proves that an instruction has arrived. It does not prove that all relevant accounts have been updated, let alone that interbank settlement has taken place.
II. The Shared Ledger Adds a Mutually Recognized Transaction State Among Banks
When Bank A and Bank B operate their own separate tokenised deposit systems, interbank payments still require tight coordination between the two parties.
Bank A may have accepted the customer's instruction and dispatched a payment order to Bank B, while Bank B is still validating beneficiary details. Payment conditions might already be satisfied, yet the interbank position remains unadjusted. If a confirmation message arrives late or duplicates, the institutions must determine whether to execute, pause, or initiate an exception workflow.
A shared ledger attempts to provide participating banks with a synchronized, mutually recognized environment to verify which payment commitments have been validly formed and how far execution can safely proceed.
To compare these two architectures, Luminale categorizes this process into three interconnected dimensions:
| Dimension | Scope of Operation | Significance to a Payment |
|---|---|---|
| Message | Transmits instructions, confirmations, and structured data | Informs counterparties of payment requirements and processing outcomes |
| State | Records the active lifecycle phase and enforceable commitments | Enables participants to determine their next operational step with certainty |
| Execution | Executes actions according to authorization and pre-conditions | Coordinates disparate banking systems to complete corresponding workflows |
Maintaining a synchronized state on a shared ledger reduces repetitive bilaterally exchanged messages and reconciliation overhead. However, banks must still establish rigorous rules governing identity permissions, state transition logic, exception management, and the technical interfaces bridging internal systems with the shared ledger.
In its minimum viable product (MVP) design unveiled in March 2026, Swift described the shared ledger's role as recording and validating interbank payment commitments while orchestrating transaction workflows. Built on Hyperledger Besu with an Ethereum Virtual Machine (EVM)-compatible architecture, the ledger is operated by Swift, while participating banks retain full authority over their private keys, assets, liquidity funding, and settlement methods.[5]
This division of responsibilities means the shared ledger validates and synchronizes interbank payment commitments, but customer deposits and bank settlement assets remain under the direct custody and control of the participating institutions.
As of 8 September 2026, public announcements from Swift, HSBC, and Citi[1][2][3] indicate the following milestones:
| Announcement Date | Disclosed Milestone | Structural Significance |
|---|---|---|
| 9 July 2026 | Swift announced the ledger was ready for initial use, with 17 global banks preparing to pilot live transactions | The initial use case targets cross-border payments via tokenised deposits, with final settlement handled via existing systems |
| 20 August 2026 | HSBC and Standard Chartered executed the first live interbank transaction on the ledger | Both banks synchronized tokenised deposit payment obligations on the shared ledger; the ledger matched and netted commitments before final settlement via existing rails |
| 2 September 2026 | Citi announced live transactions with First Abu Dhabi Bank (FAB) and OCBC | Completed live transactions in US dollars connecting partner banks across the Middle East and Southeast Asia |
HSBC's disclosure sheds light on the granular workflow: the resulting obligations were recorded as tokenised deposit obligations on HSBC's Tokenised Deposit Service (TDS) and Standard Chartered's tokenised deposit infrastructure, with Swift's shared ledger acting as an orchestration layer to match and net commitments between the two institutions prior to final settlement through existing systems.[2]
The core business value of a shared ledger is enabling banks to manage mutual obligations against a single, synchronized record. This minimizes fragmented internal ledgering, eliminates post-trade reconciliation frictions, and provides an authoritative foundation for subsequent settlement.
III. Tokenised Deposits Are Liabilities of the Issuing Bank: Is Interbank Settlement Still Required?
Tokenised deposits are commercial bank deposits represented on a programmable or tokenised ledger. They remain the legal liabilities of the issuing commercial bank, and customers hold a claim against that specific institution.[7]
When a customer holds US$100 in tokenised deposits issued by Bank A, the debtor remains Bank A. Swift provides the shared orchestration infrastructure, but it does not assume any liability or provide endorsement for the tokenised deposits recorded across the network.
Tokenisation alters how deposits are recorded and transferred, but on a bank's balance sheet, tokenised deposits remain classified as deposit liabilities. If a bank establishes dedicated tokenised deposit accounts and a client transfers US$100 from an ordinary deposit, the bank simply debits its conventional deposit liability by US$100 and credits a tokenised deposit liability by US$100; total balance sheet assets remain unchanged.
Can Tokenised Deposits Achieve "Payment as Settlement" Through Blockchain Circulation?
In a conventional commercial bank transfer, if Company A pays Company B and the funds end up as a deposit in Bank B, Company A's claim against Bank A decreases, Company B's claim against Bank B increases, and the two banks must adjust their interbank positions accordingly.
When tokenised deposits are transferred, could they circulate like stablecoins—transferring direct ownership across a blockchain without requiring interbank position settlement? For instance, could Company A simply transfer a digital token issued by Bank A to Company B, leaving Company B with a claim against Bank A? The institution against which the final recipient ultimately asserts a claim dictates whether and how interbank positions must be settled.
In its research on tokenised deposits, the Bank for International Settlements (BIS) noted that while circulating a direct bearer claim against the original issuer removes the need for interbank position settlement, such a model fractures the traditional two-tier monetary architecture governing bank-customer relationships. Furthermore, it undermines the singleness of money maintained through settlement in central bank money.[8]
As discussed in our earlier analysis of the singleness of money, commercial bank deposits denominated in the same currency exchange at par because end payees do not discount money based on the creditworthiness of the payer's bank. Par convertibility across the financial system is sustained by central bank money settlement, prudential banking regulation, and institutional backstops. It does not mean every commercial bank carries identical credit risk.[8]
Stablecoins can also circulate in programmable environments, but holders'legal claims depend entirely on the issuer's corporate structure, reserve composition, and redemption mechanisms. Lacking the institutional anchor of central bank money settlement, different stablecoins do not inherently trade at a guaranteed 1:1 par value, and even redemption into sovereign fiat can face secondary-market discounts during stress.[7]
Tokenised deposits preserve the fundamental debtor-creditor relationship between banks and depositors. Bypassing interbank settlement by forcing end recipients to hold claims against unfamiliar foreign institutions would represent an institutional step backward for the modern two-tier monetary system.
To date, Swift's shared ledger does not alter this structure: it does not settle interbank positions directly, nor does it incorporate central bank money onto the ledger. The responsibility for interbank settlement remains with the participating commercial banks.
IV. How Does the Shared Ledger Support 24/7 Customer Payments?
Swift's public design outlines a clear functional division: customer funds can move around the clock—including overnight and on weekends—using tokenised deposits, while interbank final settlement is subsequently completed through existing financial infrastructure. Swift has reiterated that banks retain full custody of assets and liquidity, with final settlement occurring off-ledger.[1][6]
The Shared Ledger Records Payment Commitments Across Banks
Returning to our earlier example: Company A banks with Bank A, Company B banks with Bank B, and both institutions hold US dollar accounts with Correspondent Bank C.
Suppose Bank B accepts a validated payment commitment from Bank A on the shared ledger and immediately credits Company B's account with US$100 in usable funds, while the two banks agree to settle their interbank obligation via Correspondent Bank C at a later stage.
Let T₀ represent the moment customer-facing payment execution occurs and an interbank commitment is formed on the shared ledger; let T₁ represent the subsequent moment when the interbank obligation is discharged across agreed settlement accounts. These represent distinct operational phases rather than fixed timeframes.
| Phase | Institution | Asset Changes | Liability Changes |
|---|---|---|---|
| T₀ | Bank A | No change | Company A Deposit: −100; Payable to Bank B: +100 |
| T₀ | Bank B | Receivable from Bank A: +100 | Company B Deposit: +100 |
| T₁ | Bank A | Due from Bank C: −100 | Payable to Bank B: −100 |
| T₁ | Bank B | Receivable from Bank A: −100; Due from Bank C: +100 | No change |
| T₁ | Bank C | No change | Bank A Account: −100; Bank B Account: +100 |
At T₀, Bank A substitutes its deposit liability to Company A with an interbank payable to Bank B. Bank B books an interbank receivable from Bank A and simultaneously expands its deposit liabilities by crediting Company B.
At T₁, Correspondent Bank C executes the book transfer, discharging the mutual payable and receivable between Bank A and Bank B. Bank B's asset shifts from an unsecured claim on Bank A into a commercial bank deposit held at Bank C.
Between T₀ and T₁, whether Company B can immediately spend its funds is operationally decoupled from whether Bank B has received the final settlement asset. If Company B transfers those funds to a third institution during that window, Bank B must provide the necessary outgoing liquidity from its own reserves.
In this example, the ultimate settlement asset is commercial bank money issued by Bank C; therefore, Bank A and Bank B remain exposed to the credit and liquidity profile of Bank C.
By tracking the state of these asset and liability transitions, the shared ledger enables banks to confirm commitments and advance workflows with cryptographic certainty. However, the ledger itself does not dispatch settlement instructions to external accounts.
In cross-border banking, not all institutions enjoy direct access to a common central bank account; correspondent banks are frequently required to clear and settle interbank positions. If both institutions hold direct accounts with the central bank of issue and settle via a Real-Time Gross Settlement (RTGS) system, T₁ corresponds to a debit to the sending bank's central bank reserve account and a credit to the receiving bank's reserve account.
Multilateral Netting Conserves Intraday Liquidity
Public disclosures from HSBC and Standard Chartered explicitly highlighted multilateral netting capabilities on the ledger.[2]
Suppose within the same settlement cycle, Bank A owes Bank B US$100, while Bank B owes Bank A US$80. Provided these obligations meet legal offset requirements and netting arrangements are enforceable, the total cash transfer required to discharge the debt can be compressed to a net payment of US$20 from Bank A to Bank B.
A shared ledger allows counterparties to verify which obligations qualify for netting in real time. Offsetting mutual obligations substantially reduces gross liquidity requirements. However, netting calculations, the legal enforceability of novated net obligations, and the transfer of final settlement assets still depend on binding scheme rules; the shared ledger serves as an enabling technical mechanism.
Off-Hours Payment Execution Requires Liquidity Backstops
The operating hours of large-value payment systems typically dictate wholesale clearing schedules. For example, the Federal Reserve Financial Services publishes that the Fedwire Funds Service operates 22 hours per business day, from 9:00 p.m. ET on the preceding calendar day to 7:00 p.m. ET, closing on weekends and designated holidays.[9]
For large-value or urgent wholesale transfers, interbank gross settlement typically precedes customer account crediting. If customer funds are credited around the clock while interbank settlement waits for underlying systems to open, banks must deploy specific liquidity arrangements to manage daylight credit and liquidity exposures:
| Liquidity Mechanism | Operational Role | Key Trade-offs |
|---|---|---|
| Prefunding | Funds are positioned in dedicated accounts in advance | Traps liquidity and requires clear asset-control rules |
| Credit Lines | Interbank payables and receivables accrue within agreed limits | Exposes the creditor to counterparty risk; limits can be exhausted |
| Collateral / Pledging | Collateral is posted to mitigate daylight settlement exposure | Demands haircut valuation, operational mobility, and legal enforceability |
| 24/7 Correspondent Book Transfers | Balances are transferred across shared correspondent books | Relies on the correspondent's operational availability and balance-sheet capacity |
Swift noted that the orchestration layer validates funded payment commitments and verifies funding availability prior to execution.[6] Detailed operational mechanics have yet to be disclosed, and critical questions remain regarding where committed liquidity resides, whether funds are legally encumbered, and whether such commitments are enforceable across relevant jurisdictions.
"Transaction Complete" on Ledger Does Not Equal Settlement Finality
Settlement finality defines the exact legal moment when the transfer of an asset or discharge of an obligation becomes irrevocable and unconditional.
Principle 8 of the CPSS-IOSCO Principles for Financial Market Infrastructures (PFMI) requires clear rules defining the point of settlement finality. Principle 9 dictates that an FMI should conduct money settlements in central bank money where practical and available, and strictly control credit and liquidity risks when commercial bank money is employed.[10]
Evaluating payments on a shared ledger requires determining whether on-chain states are legally irrevocable, whether customer balances are unencumbered, and whether interbank obligations have been definitively discharged with designated settlement assets. Terminology such as "real-time execution" or "cryptographic confirmation" cannot substitute for formal legal finality. Furthermore, exception management must be addressed: if an executed transaction must be reversed, it generally requires a new compensatory transaction, as immutable distributed ledgers cannot simply overwrite historical state.
V. Functional Re-layering of Cross-Border Payment Infrastructure
Placing the Swift shared ledger within the broader lifecycle of cross-border payments reveals four complementary layers:
| Layer | Functional Scope | Primary Carrier |
|---|---|---|
| Connectivity & Data Standards | Exchanges structured, machine-readable instructions | Financial messaging, ISO 20022 standards, APIs |
| Shared Execution & Orchestration | Validates payment commitments, synchronizes state, orchestrates workflows | Swift shared ledger and internal bank systems |
| Commercial Bank Money | Records customer claims against deposit-taking banks | Conventional deposit ledgers and tokenised deposit ledgers |
| Interbank Settlement | Discharges mutual interbank obligations using settlement assets | Central bank accounts, RTGS systems, correspondent accounts |
Swift's historical role in messaging and standards is expanding into cross-institutional transaction orchestration. Commercial banks must integrate tokenised deposit ledgers, core banking platforms, liquidity management systems, and settlement accounts. Joining a shared ledger alone cannot resolve balance-sheet liquidity constraints, compliance screening, or exception processing.
While a synchronized ledger reduces information asymmetry and post-trade reconciliation frictions, core banking services—such as foreign exchange liquidity, credit facilities, and local clearing access—must still be provided by capable correspondent institutions.
Comparing Swift Shared Ledger with the BIS Unified Ledger Blueprint
The BIS blueprint for a Unified Ledger envisions integrating tokenised central bank reserves, commercial bank money, and tokenised securities on a common programmable platform. Its 2025 framework explores how this "trilogy" of assets can unlock new efficiencies across cross-border payments and financial markets.[11]
Swift's architecture connects digital transaction orchestration with existing settlement infrastructure. Conversely, Project Agorá—convened by the BIS and the Institute of International Finance (IIF)—explores embedding tokenised commercial bank deposits alongside wholesale tokenised central bank reserves to achieve atomic settlement across currency legs.[12]
Project Agorá does not strip central banks of monetary sovereignty; it pairs a unifying ledger for commercial bank deposits with dedicated jurisdictional ledgers for central bank reserves. Each central bank maintains exclusive control over its domestic reserve liabilities while the platform orchestrates cross-border atomic execution.[12] The project successfully completed real-value testing in July 2026, validating operational feasibility, though commercial rollout requires substantial regulatory and technical groundwork.[12]
The structural difference between the Swift shared ledger and the BIS unified ledger lies in how settlement assets participate in the execution lifecycle. Under Swift's pragmatic approach, settlement assets remain off-ledger in established systems and rely on synchronization mechanisms. Under a unified ledger approach, central bank money is tokenised directly on-ledger, requiring unified rules governing central bank reserve access, redemption, and legal finality.
Looking Ahead
Public disclosures confirm that Swift and its partner banks have moved from concept to live interbank transactions, clarifying the division between on-chain orchestration and off-chain settlement.
Key variables to observe as the project advances include: which currency corridors achieve scale, the duration of the lag between customer availability and interbank discharge, the legal enforceability of prefunded commitments, netting legalities across jurisdictions, and contingency procedures when an external settlement system is offline. These metrics will reveal how much liquidity the shared ledger truly unlocks and how residual risks are distributed.
Swift's shared ledger extends cross-border payment infrastructure into synchronized interbank state and commitment orchestration. The established monetary system continues to anchor settlement assets, correspondent relationships, and legal finality.
Digital technology is fundamentally reshaping the execution of cross-border payments. Yet determining who pays whom, with what settlement asset, and at what precise moment legal finality occurs remains the bedrock of global financial architecture.
References
[1]: Swift. (9 July 2026). Swift's blockchain ledger ready for use as 17 banks set to pioneer tokenised cross-border payments on trusted global infrastructure. https://www.swift.com/news-events/press-releases/swifts-blockchain-ledger-ready-use-17-banks-set-pioneer-tokenised-cross-border-payments-trusted-global-infrastructure ↩
[2]: HSBC. (20 August 2026). HSBC and Standard Chartered execute first live tokenised deposit transaction on Swift's blockchain-based ledger. https://www.about.hsbc.com.hk/news-and-media/hsbc-and-standard-chartered-execute-first-live-tokenised-deposit-transaction-on-swifts-blockchain ↩
[3]: Citi. (2 September 2026). Citi's Services Business Pioneers Live Transactions on Swift's Ledger, Collaborating with FAB and OCBC to Redefine Always-On Global Payments. https://www.citigroup.com/global/news/press-release/2026/citi-services-pioneers-live-transactions-swift-ledger-fab-ocbc-redefine-always-on-global-payments ↩
[4]: Swift. What we do. Retrieved 8 September 2026, from https://www.swift.com/about-us/what-we-do ↩
[5]: Swift. (30 March 2026). Swift's blockchain-based shared ledger progresses to MVP implementation. https://www.swift.com/news-events/news/swifts-blockchain-based-shared-ledger-progresses-mvp-implementation ↩
[6]: Swift. Faster payments, smarter standards and Swift's blockchain-based shared ledger: The road ahead for global finance. Retrieved 8 September 2026, from https://www.swift.com/news-events/newsletters/faster-payments-smarter-standards-and-swifts-blockchain-based-shared-ledger-road-ahead-global-finance ↩
[7]: Nagel, J. (22 June 2026). New forms of money and the transmission of monetary policy. Speech delivered at the International Conference on Payments and Securities Settlement, Eltville am Rhein. Bank for International Settlements. https://www.bis.org/speeches/20260622-new-forms-money-and-transmission-monetary-policy ↩
[8]: Bank for International Settlements. (11 April 2023). Stablecoins versus tokenised deposits: implications for the singleness of money. BIS Bulletin No. 73. https://www.bis.org/publications/bulletin-73-stablecoins-versus-tokenised-deposits-implications-singleness-money ↩
[9]: Federal Reserve Financial Services. Wholesale Services Operating Hours and FedPayments Manager Hours of Availability. Retrieved 8 September 2026, from https://www.frbservices.org/resources/financial-services/wires/operating-hours.html ↩
[10]: Committee on Payment and Settlement Systems, & Technical Committee of the International Organization of Securities Commissions. (April 2012). Principles for Financial Market Infrastructures. Bank for International Settlements. https://www.bis.org/committees/cpmi/pfmi/overview ↩
[11]: Bank for International Settlements. (24 June 2025). Next-generation monetary and financial system takes shape, based on a tokenised unified ledger: BIS. https://www.bis.org/media-releases/20250624-next-generation-monetary-and-financial-system-takes-shape-based-tokenised-unified-ledger-bis ↩
[12]: Bank for International Settlements. Project Agorá. Retrieved 8 September 2026, from https://www.bis.org/project/agora ↩
Originally published by Luminale Fintech Observer: https://luminale.cn/articles/from-messaging-to-execution-swift-shared-ledger-en