In September 2026, the global banking industry successively completed two representative sets of live transactions using tokenized deposits. On September 2, First Abu Dhabi Bank (FAB) and Citibank executed a US dollar transaction via SWIFT's blockchain ledger. On September 10, DBS Bank, OCBC Bank, and UOB completed the Singapore banking sector's first interbank live transactions in Singapore dollars based on tokenized deposits. These two transaction sets covered cross-border US dollar and domestic currency payments, respectively, and both connected traditional SWIFT messages, bank-issued tokenized deposits, and the shared ledger.
This indicates that SWIFT is adding a 24/7 operational "value orchestration layer" on top of the traditional payment system: participating banks continue to manage their own customers, deposits, and compliance relationships, while the shared ledger is responsible for synchronizing payment commitments between banks and enabling tokenized deposits to operate collaboratively across different banking systems.
From its announcement in September 2025 to initial use in July 2026 and live transactions in different currencies by September 2026, SWIFT Ledger progressed from concept design to production environment validation in less than a year. The change it brings is not merely "moving payments onto the chain," but rather traditional bank deposits acquiring a technological form that is programmable, capable of continuous operation, and allows for cross-institutional collaboration. This article will analyze how this change might reshape the institutional-grade digital payments market from the perspectives of technical architecture, financial impact, legal implications, industry competition, and practical limitations.
1. From Proof-of-Concept to Live Transactions
When SWIFT first announced its shared ledger plan in September 2025, more than 30 financial institutions participated in the design. The initial project emphasis was on real-time, 24/7 cross-border payments and interoperability between different forms of digital value. In July 2026, SWIFT announced that the ledger was ready for initial use, with 17 banks across six continents prepared to conduct live transactions using tokenized deposits. By this point, the project's focus had shifted from "can we connect" to "can it operate within the context of real bank liabilities and compliance processes."
The two transaction sets in September further shortened the distance between concept and business operations. The US dollar transaction between FAB and Citibank validated the end-to-end interaction between existing SWIFT payment messages, tokenized deposits, and distributed ledger infrastructure. Subsequently, the interbank transaction in Singapore dollars by the three Singaporean banks demonstrated that the same architecture could handle not only cross-border correspondent banking scenarios but also the 24/7 domestic payment needs within a country's banking system.
It is noteworthy that these transactions did not use public chain tokens targeted at anonymous holders, but rather tokenized deposits issued by banks and linked to customer deposit relationships. So-called tokenized deposits are a digital representation of commercial bank deposit liabilities on a programmable ledger. Simply put, customers still hold a claim on the bank's deposit, but this claim can now be recorded, transferred, and embedded with automatic execution conditions via new ledger technology.
This distinction determines that the primary customers of SWIFT Ledger are not retail crypto users, but banks and their clients who need to handle corporate funds, trade payments, institutional settlements, and cross-border liquidity. For these entities, whether the technology is novel is not the primary concern; the key to large-scale adoption is its ability to integrate with existing account systems, identity standards, risk controls, and regulatory reporting.
2. What Does the Shared Ledger Actually Change?
For a long time, SWIFT's core role has been transmitting standardized financial messages. After a paying bank issues an instruction, the actual movement of funds occurs within individual bank ledgers, correspondent accounts, or central bank settlement systems. Message transmission and fund settlement are interrelated but not the same thing. Therefore, cross-border payments often require multiple institutions to separately reconcile accounts, compliance statuses, and funding positions, and the operating hours of these different systems are not fully aligned.
SWIFT Ledger does not eliminate the internal ledgers of individual banks but adds a commonly visible, verifiable coordination record between banks. Its initial purpose is to use bank-issued tokenized deposits as interbank liabilities, verify and synchronize payment commitments via smart contracts, confirm that participating parties have the corresponding funds, and then execute the value transfer at the customer level.
The core concept here is "decoupling payment execution from final settlement." Simply put, customer payments can be completed first on a 24/7 tokenized deposit network, while the final net funding obligations accumulated between banks can still be settled through existing RTGS or correspondent channels. This reduces the difficulty of the new system directly replacing the global settlement infrastructure and allows banks to test new payment capabilities while retaining their existing capital, credit, and liquidity control frameworks.
This design goes beyond simply increasing message speed. Traditional messages can only describe a payment request, whereas a programmable ledger can simultaneously check fund availability, participant identity, transaction conditions, and state changes. In future corporate treasury management scenarios, payments could be linked to invoices, goods status, securities delivery, or smart device instructions. Funds would no longer just be transferred upon receiving an instruction but could be automatically executed when agreed-upon conditions are met.
However, it's important to distinguish that immediate execution on the ledger does not necessarily equate to immediate legal finality of settlement. If interbank settlement still relies on existing systems, there remain legal and liquidity relationships to be managed between the on-chain record, customer account changes, and final interbank settlement. The path SWIFT currently adopts is closer to incremental transformation than a one-time rebuild of monetary settlement foundations.
3. Why Tokenized Deposits Became Banks' Preferred Entry Point
Tokenized deposits have gained importance for banks, first because they extend the existing legal and balance sheet structure of deposit money. Customer deposits are already liabilities of commercial banks; tokenization primarily changes their recording and transfer methods and does not necessarily create a new issuing entity independent of the bank. In contrast, fiat-backed stablecoins are typically provided by specialized issuers with reserve assets backing their value, requiring separate designs for holder rights, redemption arrangements, bankruptcy remoteness, and regulatory frameworks.
Secondly, tokenized deposits more easily preserve "monetary fungibility." Monetary fungibility refers to the ability of different forms of money in society to be exchanged at face value and be regarded as the same unit of account. The reason why one dollar deposit at Bank A is typically equal in value to one dollar deposit at Bank B is not only due to bank credit but also because deposit insurance, central bank reserves, clearing arrangements, and prudential regulation collectively maintain conversion at face value. Some stablecoins may deviate from par due to issuer credit, reserve quality, or liquidity differences.
SWIFT's approach attempts to bring this institutional foundation into a programmable environment. Banks remain responsible for customer due diligence, sanctions screening, transaction monitoring, and account management; tokenized deposits remain within the regulated banking system. The shared ledger provides cross-bank collaboration without requiring each institution to join a completely unfamiliar public chain economic system.
Thirdly, tokenized deposits can integrate with banks' existing funding sources and credit creation mechanisms. Stablecoin issuers typically back circulating tokens with highly liquid reserves, with a business logic closer to payment instruments or narrow reserve arrangements. Commercial banks, however, serve the real economy by taking deposits, issuing loans, and managing maturity transformation. For large corporate clients, if programmable payments still originate from existing bank accounts and credit relationships, they would not need to transfer large amounts of funds out of the system into external stablecoins long-term just to use digital settlement.
Nevertheless, tokenized deposits will not automatically replace stablecoins. Stablecoins still hold advantages in public blockchains, global accessibility, on-chain transactions, and developer ecosystems. A more likely scenario is market stratification: stablecoins continue to serve native public chain scenarios and some cross-border payments, while tokenized deposits enter institutional funds, trade, securities settlement, and regulated digital asset markets first. The focus of competition will shift from "which token is faster" to who can simultaneously provide compliance usability, cross-platform interoperability, and a sufficiently broad acceptance network.
4. Financial Efficiency and Liquidity Constraints Both Increase
For corporate clients, the most apparent change is the weakening of payment time boundaries. Multinational groups' fund transfers, margin calls, supply chain payments, and weekend transactions need not be entirely constrained by bank business days. DBS Bank emphasized in its public statement that corporate businesses operate 24/7, and their funds require corresponding continuous availability; OCBC and UOB linked the live results to programmable, interoperable, and cross-timezone payment capabilities.
24/7 payments may also reduce preventive liquidity that companies hold to cope with delays. The more transparent the status of cross-border payments, the easier it is for companies to determine when funds will arrive, whether they are usable, and adjust cash pools and short-term financing accordingly. For banks, shared status can also help reduce duplicate reconciliation and exception investigation, shifting some operational costs from manual coordination to unified standards and automated controls.
However, faster settlement does not necessarily mean lower liquidity requirements. Traditional payment systems often smooth funding needs through batch processing, net settlement, or end-of-day windows; when transactions shift to real-time and 7x24 operation, banks need to continuously monitor positions during nights, weekends, and holidays. If customer-layer payments are already complete while final interbank settlement occurs in subsequent windows, participating banks must also manage the resulting credit exposures and collateral arrangements during that interval.
The International Monetary Fund noted in its 2026 study on tokenized finance that continuous settlement changes the rhythm of liquidity management, and automated execution may also accelerate margin calls and fund outflows during stress periods. Therefore, new infrastructure needs to simultaneously possess mechanisms for limits, suspensions, manual intervention, fallback procedures, and liquidity support. For institutional markets, the real difficulty is not making smart contracts execute automatically but deciding when to allow them to stop executing under extreme conditions.
Cost structures will also change. Reconciliation, message matching, and intermediary steps may decrease, but network access, smart contract auditing, key management, data governance, and 24/7 operations become new fixed costs. Large banks may more easily bear these investments, while smaller institutions may rely on shared service providers. This increases the scale effects of the infrastructure while raising new concentration concerns.
5. Legal Questions Shift from "What is a Token" to "When Does a Record Become Effective"
While tokenized deposits are built upon existing deposit relationships, it doesn't mean all legal issues are resolved. First, it must be clarified which record—the on-chain record or the bank's core ledger—constitutes the legally effective definitive record. If discrepancies arise due to system failure, network fork, or manual correction, determining which record governs customer rights requires contracts, business rules, and applicable law.
Second is settlement finality. Settlement finality refers to the point at which a fund transfer becomes legally irrevocable and cannot be unconditionally reversed. Simply put, a technical system displaying "success" is not sufficient; a bankruptcy administrator, court, and other participating institutions must also acknowledge that the transfer is complete. Cross-border transactions simultaneously involve different banks, ledger operating rules, correspondents, and settlement systems, and finality may occur at multiple points.
Third is jurisdiction and conflict of laws. A client may be located in one country, the deposit bank in another, shared ledger nodes distributed across multiple regions, and final settlement may use a third country's currency. In cases of erroneous execution, asset freezes, or institutional bankruptcy, the laws of which country determine the nature of tokenized deposits, set-off rights, and priority of claims cannot be answered by technical protocol alone. Large-scale cross-border use requires clearer participation rules and legal opinions.
Fourth is AML, sanctions, and data governance. Permissioned networks can restrict participating institutions but cannot replace transaction monitoring. 24/7 and programmable payments compress manual review time, placing higher demands on sanctions list updates, beneficial owner identification, abnormal transaction blocking, and false positive correction. Simultaneously, shared ledgers need to balance verifiability with bank secrecy, personal information, and cross-border data transfer restrictions.
Finally, code governance. Once smart contracts participate in fund control, programming errors can become a source of financial risk. Who can upgrade contracts, suspend transactions, correct erroneous records, whether upgrades require collective participant approval, and whether regulators can timely obtain audit information are all governance issues. Risks in traditional financial institutions are mainly recorded on balance sheets and in processes; in a tokenized system, some risks begin to concentrate in platform rules, interfaces, and code.
6. How Stablecoins, Banks, and Financial Infrastructure Will Redivide Labor
The industrial significance of SWIFT Ledger lies in the global banking network beginning to respond to the 24/7 payment pressure brought by stablecoins using its own liability instruments. In the past, one of stablecoins' most apparent advantages was the ability to transfer on-chain unrestricted by bank operating hours. As tokenized deposits also acquire continuous operational capability, institutional clients choosing payment tools will focus more on credit structure, regulatory treatment, balance sheet efficiency, and integration with existing bank services.
For commercial banks, this is both defensive and a new business entry point. Banks can reduce incentives for client funds to leave the deposit system and combine programmable payments with cash management, trade finance, forex, and securities services. For SWIFT, the shared ledger extends its role from message standards and connectivity networks to transaction state coordination. Its competitive advantage is not owning a particular blockchain but its existing institutional identity, global connectivity, message standards, and compliance collaboration network.
Traditional payment infrastructures are also simultaneously researching both forms of digital currency. In September 2026, Nacha, responsible for rules governing the US Automated Clearing House network, announced the formation of a project team specifically to study the impact of stablecoins and tokenized deposits on various payments. This indicates that industry discussion has moved beyond competition between "banks and the crypto industry" to a phase where clearing organizations, card networks, financial market infrastructures, and software service providers are collectively adjusting.
For fintech companies, opportunities may lie more in the application layer. Enterprises won't change financial processes merely due to an underlying ledger update; they need cross-bank fund views, automated receivables/payables, compliance orchestration, on-chain/off-chain reconciliation, and conditional payment tools. Those who can encapsulate new tokenized payment capabilities into the finance, trade, and asset management software that enterprises actually use are more likely to gain sustainable revenue.
However, infrastructure concentration requires vigilance. If many banks rely on the same orchestration layer, identity service, or smart contract templates, the impact of a single point of failure is amplified. Network effects can reduce fragmentation but also increase the importance of platform governance and operational resilience. Future regulatory focus may not only target banks issuing tokens but gradually cover technology and infrastructure providers critical to transaction execution.
7. Boundaries Still Present in Current Live Transactions
First, successful transactions at this stage do not equal global commercial coverage. 17 early participating banks and a few currencies can prove the technical path is feasible but cannot prove that all time zones, jurisdictions, and long-tail correspondents already have access conditions. The complexity of cross-border payments often stems from the last mile, local compliance, and liquidity, not the core ledger itself.
Second, the decoupling of payment execution from final settlement is a pragmatic design but also a constraint that hasn't disappeared. As long as final interbank funds still rely on existing RTGS and correspondent channels, transactions occurring on weekends or at night require credit limits, prefunding, or deferred settlement arrangements. The shared ledger can improve coordination efficiency but won't automatically eliminate currency, term, and counterparty risks.
Third, interoperability needs to move from technical connection to unified business rules. Different banks may adopt different tokenized deposit platforms, data models, and privacy technologies. Even if interfaces can transmit instructions, parties still need unified asset identification, state definitions, error handling, compliance responsibilities, and dispute resolution procedures. Truly scalable interoperability is not just about systems "understanding" each other but also institutions forming a consistent legal understanding of the same transaction's consequences.
Fourth, client demand still requires validation. How much cost are enterprises willing to pay for 24/7 payments, which businesses truly need second-level execution, whether new processes can improve working capital, and whether banks can offer competitive pricing all require more real transaction data. Technology supply has emerged, but business models are still forming.
8. What to Observe Next
Corundum believes that in the coming period, the most important observations are not single transaction speeds but three institutional indicators.
First, whether participation expands from bilateral or small bank groups to multi-currency, multi-region networks. If each new institution joining requires significant custom development, the network effects of the shared ledger will be limited; if existing SWIFT connections and standards can significantly reduce onboarding costs, its expansion may accelerate.
Second, whether final settlement assets change. The current path preserves existing RTGS and correspondent settlement, reducing initial transformation risk. If future steps gradually connect to tokenized central bank reserves, wholesale CBDCs, or other regulated on-chain settlement assets, the distance between payment execution and final settlement may shorten further, but corresponding central bank access and legal issues will also increase.
Third, whether regulators begin establishing specific operational, code, and recovery requirements for shared ledgers. As transaction volumes rise, smart contract auditing, key recovery, transaction suspension, data access, and cross-border crisis collaboration will shift from project governance issues to financial stability issues. Who is responsible for making exceptional decisions at machine speed will become a more important institutional arrangement than automatic execution under normal conditions.
From an industry evolution perspective, SWIFT has not chosen to directly compete with public blockchains for all scenarios but is starting from banks' most familiar deposit liabilities, identity networks, and settlement systems, gradually adding digital capabilities. The advantage of this path is compliance and institutional coverage; the disadvantage is that progress speed is subject to multi-party coordination. Whether it can become the common connectivity layer for institutional-grade tokenized finance depends on the project's ability to maintain trust while avoiding forming new closed silos.
Conclusion
The US dollar and Singapore dollar live transactions in September 2026 indicate that tokenized deposits have begun moving beyond pure proof-of-concept into real bank liabilities and production processes. What SWIFT Ledger demonstrates is not a sudden shift of traditional finance to a specific blockchain, but the banking system's attempt to incorporate 24/7 operation, programmability, and shared state—digital asset capabilities—into the existing regulatory structure.
This path may weaken some of the advantages stablecoins held in institutional payments based on operational hours and may also drive banks, clearing organizations, and fintech companies to re-divide responsibilities. However, it currently still retains existing final settlement channels and faces issues of liquidity, legal finality, cross-border jurisdiction, code governance, and infrastructure concentration.
This article is intended solely for legal, policy, and industry research exchange, aiming to objectively analyze digital finance, stablecoins, digital assets, and related regulatory dynamics. It does not constitute any form of investment advice, legal opinion, tax opinion, or other professional advice, nor does it constitute recommendation, promotion, or solicitation of any financial product, digital asset, or commercial project. The regulatory rules, market data, and institutional information involved are primarily sourced from publicly available materials and may change due to laws, regulations, regulatory policies, market environments, and project developments. Readers are advised to make independent judgments based on the latest public information and comply with applicable laws and regulations in their country or region. The author and publishing platform assume no responsibility for any investment, trading, or other business decisions made based on reliance on this article's content.
