SWIFT Shared Ledger Begins Live Trading with Tokenized USD and SGD Deposits

In September 2026, the global banking sector completed two landmark real-world transactions involving tokenized deposits. On September 2, First Abu Dhabi Bank (FAB) and Citibank executed a U.S. dollar transaction using SWIFT’s blockchain ledger. On September 10, DBS Bank, OCBC, and UOB completed Singapore’s first interbank real-world transactions in Singapore dollars based on tokenized deposits. Both transactions covered cross-border dollar and local currency payments, integrating traditional SWIFT messages, bank-issued tokenized deposits, and a shared ledger.

This means SWIFT is adding a 24/7 "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 handles the synchronization of payment commitments between banks and enables tokenized deposits to operate seamlessly across different banking systems.

From its announcement in September 2025 to initial use in July 2026, and then to live multi-currency trading in September, SWIFT Ledger achieved the transition from conceptual design to production validation in less than a year. The transformation it brings is not merely “putting payments on-chain,” but rather the emergence of traditional bank deposits into a programmable, sustainably operable, and cross-institutionally coordinated technological form. This article analyzes how this shift may reshape the institutional digital payments market, examining its technical architecture, financial impact, legal relationships, industry competition, and practical limitations.

When SWIFT first announced its shared ledger initiative in September 2025, more than 30 financial institutions participated in its design, with the project initially emphasizing real-time, 24/7 cross-border payments and interoperability between different forms of digital value. In July 2026, SWIFT announced that the ledger had reached its initial operational stage, with 17 banks from six continents preparing to conduct live transactions using tokenized deposits. At this point, the project’s focus had shifted from “whether it can connect” to “whether it can operate within real bank liabilities and compliance processes.”

The two sets of transactions in September further narrowed the gap between concept and business. FAB’s U.S. dollar transaction with Citibank validated end-to-end interoperability among existing SWIFT payment messages, tokenized deposits, and distributed ledger infrastructure. Subsequently, three Singaporean banks—DBS, OCBC, and UOB—completed domestic currency interbank transactions, demonstrating that the same architecture can address not only cross-border correspondent banking scenarios but also round-the-clock payment needs within a single country’s banking system.

It is important to note that these transactions do not use publicly traded tokens designed for anonymous holders, but rather tokenized deposits issued by banks and linked to customer deposits. Tokenized deposits represent digital expressions of commercial bank deposit liabilities on programmable ledgers. In simple terms, customers still hold claims against the bank for their deposits, but these claims can now be recorded, transferred, and embedded with automated conditions using new ledger technology.

This distinction means that SWIFT Ledger’s primary customers are not retail crypto users, but rather banks and their clients that 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; what matters most is its ability to integrate with existing account systems, identity standards, risk controls, and regulatory reporting—key factors for scalable adoption.

For a long time, SWIFT’s core function has been to transmit standardized financial messages. After the paying bank issues an instruction, the actual movement of funds occurs within the ledgers of banks, correspondent accounts, or central bank settlement systems. Message transmission and fund settlement are related but distinct processes. As a result, cross-border payments often require multiple institutions to separately verify account details, compliance status, and fund positions, and the operating hours of different systems are not fully aligned.

The SWIFT Ledger does not eliminate individual banks' internal ledgers; instead, it adds a shared, verifiable coordination record visible to all banks. Its initial purpose is to treat tokenized deposits issued by banks as interbank liabilities, using smart contracts to verify and synchronize payment commitments, and to execute customer-level value transfers only after confirming that participating parties have sufficient funds.

The core concept here is the decoupling of payment execution from final settlement. In simple terms, customer payments can be completed around the clock within a tokenized deposit network, while the final financial obligations accumulated between banks can still be settled through existing RTGS or correspondent banking channels. This approach reduces the complexity of replacing global settlement infrastructure outright 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 single payment request, whereas a programmable ledger can simultaneously verify fund availability, participant identity, transaction conditions, and state changes. In future enterprise treasury management scenarios, payments may be linked to invoices, goods status, securities settlement, or smart device commands. Funds will no longer simply transfer upon receiving an instruction, but instead execute automatically when predefined conditions are met.

However, it is important to distinguish that immediate execution on a ledger does not necessarily equate to immediate and final legal settlement. If interbank settlement still requires completion through existing systems, there remain legal and liquidity relationships to be managed between on-chain records, customer account changes, and final interbank settlement. SWIFT’s current approach more closely resembles a gradual transformation rather than a complete overhaul of the monetary settlement infrastructure.

Tokenized deposits are of significant interest to banks because they preserve the existing legal and balance sheet structure of deposit money. Customer deposits are already liabilities of commercial banks; tokenization primarily alters how they are recorded and transferred, without inherently creating a new issuing entity independent of the bank. In contrast, fiat-backed stablecoins are typically issued by specialized entities and backed by reserve assets, requiring separate design of holder rights, redemption mechanisms, bankruptcy isolation, and regulatory frameworks.

Second, tokenized deposits are better able to preserve "monetary unity." Monetary unity refers to the ability of different forms of money within a society to be exchanged at par and regarded as a single unit of account. One yuan in a deposit at Bank A is typically equivalent to one yuan in a deposit at Bank B not only due to bank creditworthiness, but also because deposit insurance, central bank reserves, clearing arrangements, and prudential regulation collectively maintain par value conversion. Some stablecoins, however, may deviate from par value due to differences in issuer creditworthiness, reserve quality, or liquidity.

The SWIFT solution aims to bring this institutional framework into a programmable environment. Banks remain responsible for customer due diligence, sanctions screening, transaction monitoring, and account management, and tokenized deposits remain within the regulated banking system; the shared ledger enables cross-bank collaboration without requiring each institution to join an entirely unfamiliar public blockchain economy.

Again, tokenized deposits can be integrated with banks’ existing funding sources and credit creation mechanisms. Stablecoin issuers typically back circulating tokens with highly liquid reserves, operating with a business model closer to payment instruments or narrow reserve arrangements; commercial banks, on the other hand, support the real economy by accepting deposits, extending loans, and managing maturity transformation. For large corporate clients, if programmable payments still originate from existing bank accounts and credit relationships, there is no need to permanently transfer large amounts of funds outside the system into stablecoins solely for digital settlement purposes.

However, 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 segmentation: stablecoins will continue serving native public chain use cases and certain cross-border payments, while tokenized deposits will primarily enter institutional funds, trade finance, securities settlement, and regulated digital asset markets. The focus of competition will shift from “which token is faster” to who can deliver regulatory compliance, cross-platform interoperability, and a sufficiently broad acceptance network.

For enterprise clients, the most direct change is the weakening of payment time boundaries. Cross-border fund transfers, margin top-ups, supply chain payments, and weekend transactions no longer need to be fully constrained by banking business days. DBS Bank emphasized in its public statement that enterprise operations run 24/7 and that their funds must also have corresponding continuous availability. OCBC and UOB have linked real-world outcomes to programmable, interoperable, and cross-time-zone payment capabilities.

24/7 payments may also reduce the precautionary funds businesses hold to account for delays. The more transparent the status of cross-border payments, the easier it is for businesses to determine when funds will arrive and whether they are available, allowing them to adjust their cash pools and short-term financing accordingly. For banks, shared status information also helps reduce duplicate reconciliations and anomaly investigations, shifting some operational costs from manual coordination to standardized, automated controls.

However, faster settlement does not mean lower liquidity requirements. Traditional payment systems often smooth liquidity demands through batch processing, netting, or end-of-day windows; when transactions shift to real-time, 7×24 operation, banks must continuously monitor positions during nights, weekends, and holidays. If customer payments have been settled but interbank final settlement still occurs in subsequent windows, participating banks must also manage the credit exposure and collateral arrangements that arise during this period.

In its 2026 study on tokenized finance, the International Monetary Fund found that continuous settlement alters the rhythm of liquidity management, and automated execution may accelerate margin calls and capital outflows during periods of stress. Therefore, new infrastructure must incorporate limits, pauses, human intervention, failover mechanisms, and liquidity support systems. For institutional markets, the real challenge is not enabling smart contracts to execute automatically, but determining when to allow them to stop under extreme conditions.

The cost structure will also change. Reconciliation, message matching, and intermediary steps may decrease, but network access, smart contract audits, key management, data governance, and 24/7 operations will become new fixed costs. Large banks may find it easier to absorb these investments, while smaller institutions may rely on shared service providers. This will enhance economies of scale in infrastructure while introducing new concentration risks.

Tokenized deposits are built upon existing deposit relationships, but this does not mean all legal issues have been resolved. First, it must be clearly established whether the on-chain record or the bank’s core ledger constitutes the legally binding final record. In the event of discrepancies due to system failures, network forks, or manual corrections, the customer’s rights must be determined by the contract, business rules, and applicable law.

Second is settlement finality. Settlement finality refers to the point at which a fund transfer is legally irreversible and cannot be unconditionally reversed. In simple terms, it is not enough for the technical system to show “success”; bankruptcy administrators, courts, and other involved parties must also recognize that the transfer has been completed. Cross-border transactions involve different banks, ledger operating rules, correspondent banks, and settlement systems, and finality may occur at multiple distinct points in time.

Third is jurisdiction and conflict of laws. Customers may be located in one country, the depositing bank in another, shared ledger nodes distributed across multiple regions, and final settlement potentially using a currency from a third country. In cases of erroneous execution, asset freezes, or institutional insolvency, the laws of which country determine the nature of tokenized deposits, setoff rights, and priority of claims cannot be resolved by technical agreements alone. Scalable cross-border usage requires clearer participation rules and legal guidance.

Fourth is anti-money laundering, sanctions, and data governance. Permissioned networks can restrict participating institutions but cannot replace transaction monitoring. Around-the-clock and programmable payments reduce the time available for manual review, placing higher demands on updating sanctions lists, identifying beneficial owners, blocking suspicious transactions, and correcting false positives. Meanwhile, shared ledgers must strike a balance between verifiability and banking secrecy, personal information protection, and cross-border data transfer restrictions.

Finally, there is code governance. Once smart contracts are involved in fund control, programming errors can become sources of financial risk. Issues such as who can upgrade the contract, pause transactions, or correct erroneous records; whether upgrades require joint approval from participating parties; and whether regulators can promptly access audit information—all fall under governance. In traditional financial institutions, risks are primarily documented in balance sheets and processes; under tokenization systems, some risks begin to concentrate in platform rules, interfaces, and code.

The industry significance of the SWIFT Ledger lies in the global banking network beginning to respond to the round-the-clock payment pressures posed by stablecoins with its own liability instruments. Previously, one of the most obvious advantages of stablecoins was their ability to transfer on-chain without being constrained by banking hours. As tokenized deposits also gain continuous operational capability, institutional clients will increasingly prioritize credit structure, regulatory treatment, balance sheet efficiency, and integration with existing banking services when choosing payment tools.

For commercial banks, this represents both a defense and a new business entry point. Banks can reduce the incentive for customer funds to leave the deposit system and integrate programmable payments with cash management, trade finance, foreign exchange, and securities services. For SWIFT, a shared ledger extends its role from messaging standards and connectivity networks to transaction state coordination. Its competitive advantage lies not in owning a specific blockchain, but in its existing institutional identities, global connectivity, messaging standards, and compliance collaboration network.

Traditional payment infrastructures are also actively researching both forms of digital currencies. In September 2026, Nacha, which governs the rules for the U.S. ACH network, announced the formation of a dedicated project team to study the impact of stablecoins and tokenized deposits on various payment systems. This indicates that industry discussions have moved beyond the competition between banks and the crypto sector, and are now entering a phase where clearing organizations, card networks, financial market infrastructures, and software providers are jointly adapting.

For fintech companies, opportunities are more likely to emerge at the application layer. Enterprises won’t change their financial processes simply because the underlying ledger has been updated—they need cross-bank cash visibility, automated accounts receivable and payable, compliance orchestration, on-chain and off-chain reconciliation, and conditional payment tools. Whoever can package new tokenized payment capabilities into the financial, trade, and asset management software that enterprises actually use will be the one to generate sustained revenue.

However, centralization of infrastructure also requires caution. If a large number of banks rely on the same orchestration layer, identity services, or smart contract templates, the impact of a single point of failure will be amplified. Network effects can reduce fragmentation, but they also increase the importance of platform governance and operational resilience. Future regulatory focus may extend beyond banks issuing tokens to include technology and infrastructure providers critical to transaction execution.

First, successful transactions at this stage do not equate to global commercial coverage. The participation of 17 early-stage banks and a limited number of currencies demonstrates the feasibility of the technical approach, but does not prove that all time zones, jurisdictions, and correspondent banks in the long tail are ready for integration. The complexity of cross-border payments often stems from the last mile, local compliance, and liquidity—not the core ledger itself.

Second, separating payment execution from final settlement is a pragmatic design and remains an enduring constraint. As long as interbank funds still rely on existing RTGS and correspondent banking channels, transactions occurring on weekends or at night require credit limits, pre-funding, or deferred settlement arrangements. A shared ledger can improve coordination efficiency, but it does not automatically eliminate currency, maturity, or counterparty risk.

Third, interoperability must evolve from technical connectivity to uniform business rules. Different banks may use distinct tokenized deposit platforms, data models, and privacy technologies. Even if interfaces can transmit commands, all parties must align on asset identification, state definitions, error handling, compliance responsibilities, and dispute resolution procedures. True scalable interoperability requires not only that systems can “understand” each other, but also that institutions share a consistent understanding of the legal implications of the same transaction.

Fourth, customer needs still require validation. More real transaction data is needed to determine how much businesses are willing to pay for 24/7 payments, which processes truly require second-level execution, whether new workflows can improve working capital, and whether banks can offer competitive pricing. While the technological supply is already available, the business model is still in development.

Corundum believes that over the coming period, the most important indicators to watch are not single transaction speeds, but three institutional metrics.

First, has the scope of participation expanded from bilateral or small groups of banks to a multi-currency, multi-region network? If each new institution requires significant custom development to join, the network effects of the shared ledger will be limited; if existing SWIFT connections and standards can substantially reduce onboarding costs, the pace of expansion could accelerate.

Second, whether the final settlement asset changes. The current path retains existing RTGS and correspondent bank settlement, reducing initial transformation risks. In the future, if tokenized central bank reserves, wholesale central bank digital currencies, or other regulated on-chain settlement assets are gradually integrated, the gap between payment execution and final settlement could be further reduced; however, corresponding central bank access and legal issues would also increase.

Third, regulators are beginning to establish specific operational, code, and recovery requirements for shared ledgers. As transaction volumes rise, smart contract audits, key recovery, transaction suspension, data access, and cross-border crisis collaboration will shift from project governance issues to financial stability concerns. Who is responsible for making exception decisions at machine speed will become a more critical institutional arrangement than automatic execution under normal conditions.

From an industry evolution perspective, SWIFT has not chosen to directly compete with public blockchains across all scenarios; instead, it has gradually enhanced its digital capabilities by starting with areas banks are most familiar with—deposit liabilities, identity networks, and settlement systems. This approach offers advantages in compliance and institutional coverage, but its progress is constrained by the need for multi-party coordination. Whether SWIFT can become a public connectivity layer for institutional tokenized finance depends on whether the project can maintain trust while avoiding the creation of new closed silos.

Real-world trading of USD and SGD in September 2026 demonstrates that tokenized deposits have moved beyond mere proof-of-concept into actual bank liabilities and production workflows. What SWIFT Ledger illustrates is not a sudden shift of traditional finance toward a single blockchain, but rather the banking system’s effort to integrate digital asset capabilities—such as 24/7 operation, programmability, and shared state—into existing regulatory frameworks.

This path may erode some of the advantages that stablecoins have gained through uptime in institutional payments and could prompt banks, clearing organizations, and fintech companies to redefine their roles. However, it still retains existing final settlement channels and faces challenges related to liquidity, legal finality, cross-border jurisdiction, code governance, and infrastructure centralization.

This article is intended solely for legal, policy, and industry research purposes, aiming to provide an objective analysis of digital finance, stablecoins, digital assets, and related regulatory developments. It does not constitute any form of investment advice, legal opinion, tax advice, or other professional guidance, nor does it constitute any recommendation, promotion, or solicitation of financial products, digital assets, or business projects. The regulatory rules, market data, and institutional information referenced in this article are primarily sourced from publicly available materials and may be subject to change due to evolving laws, regulations, market conditions, or project developments. Readers are advised to independently assess the information in light of the latest public disclosures and to comply with applicable laws and regulations in their respective jurisdictions. The author and the publishing platform assume no responsibility for any investment, trading, or other commercial decisions made based on the content of this article.