Two live tokenized-deposit transactions in September 2026 marked a notable shift for global banking payments. On Sept. 2, First Abu Dhabi Bank (FAB) and Citibank completed a U.S. dollar transaction through SWIFT’s blockchain-based ledger. On Sept. 10, DBS, OCBC and UOB completed Singapore’s first live interbank Singapore dollar transactions based on tokenized deposits.
Those deals covered both cross-border U.S. dollar payments and domestic-currency transfers. In both cases, traditional SWIFT messaging, bank-issued tokenized deposits and a shared ledger were linked in the same flow. What SWIFT is building is not a full replacement for the existing payment stack, but a value-orchestration layer that can run around the clock. Participating banks continue to manage clients, deposits and compliance relationships, while the shared ledger synchronizes payment commitments between banks so tokenized deposits can work across different banking systems.
From the project’s announcement in September 2025, to initial use in July 2026, to live transactions in multiple currencies by September 2026, SWIFT Ledger moved from concept design to production validation in less than a year. The change is broader than simply putting payments on-chain. It gives traditional bank deposits a programmable form that can operate continuously and coordinate across institutions.
From proof of concept to production use
When SWIFT first unveiled its shared-ledger plan in September 2025, more than 30 financial institutions were involved in the design stage. The early focus was real-time, 24/7 cross-border payments and interoperability across different forms of digital value.
By July 2026, SWIFT said the ledger had reached an initial-use phase, with 17 banks from six continents preparing to conduct live transactions using tokenized deposits. By then, the central question had shifted. The issue was no longer whether systems could connect. It was whether the model could function inside real bank liabilities and real compliance workflows.
The September transactions narrowed that gap even more. The FAB-Citibank dollar trade showed end-to-end interaction between existing SWIFT payment messages, tokenized deposits and distributed-ledger infrastructure. The DBS-OCBC-UOB transaction then showed that the same architecture can support not only correspondent-banking use cases across borders, but also always-on payment needs inside a single domestic banking system.
These transactions did not use public-chain tokens designed for anonymous holders. They used tokenized deposits issued by banks and tied directly to customer deposit relationships. In practical terms, a tokenized deposit is the digital representation of a commercial bank deposit liability on a programmable ledger. The customer still holds a claim on the bank. What changes is the way that claim is recorded, transferred and linked to automated execution conditions.
That distinction matters because SWIFT Ledger is not primarily aimed at retail crypto users. Its target users are banks and bank clients that handle corporate treasury, trade payments, institutional settlement and cross-border liquidity. For those participants, novelty is secondary. The real test is whether the technology can plug into existing account structures, identity standards, risk controls and regulatory reporting.
What the shared ledger changes
SWIFT’s core role has long been the transmission of standardized financial messages. Once a paying bank sends an instruction, the actual movement of funds takes place on bank books, correspondent accounts or central-bank settlement systems. Messaging and settlement are linked, but they are not the same function. Cross-border payments often require multiple institutions to reconcile accounts, compliance status and liquidity positions, while operating hours differ across systems.
SWIFT Ledger does not eliminate each bank’s internal ledger. It adds a shared, verifiable coordination record between banks. Its initial use case is to represent bank-issued tokenized deposits as interbank liabilities, validate and synchronize payment commitments through smart contracts, and then execute customer-level value transfers after confirming that the participating parties have the required funds.
The central feature here is the separation of payment execution from final settlement. Customer payments can be processed on a tokenized-deposit network on a 24/7 basis, while the final obligations that build up between banks can still be settled through existing real-time gross settlement, or RTGS, systems and correspondent-banking channels. That lowers the difficulty of introducing a new layer without asking it to replace global settlement infrastructure from day one. It also lets banks test new payment capabilities while keeping their existing capital, credit and liquidity-control frameworks in place.
This goes beyond making message transmission faster. Traditional messages can describe a payment request. A programmable ledger can also check fund availability, participant identity, transaction conditions and state changes in the same process. In future corporate treasury settings, payments may be linked to invoices, cargo status, securities delivery or even device-triggered instructions. Money would not move only after an instruction is received. It could move automatically once agreed conditions are satisfied.
Still, immediate execution on a ledger does not automatically mean immediate legal finality. If interbank discharge still depends on current systems, then legal and liquidity relationships remain between the on-ledger record, the customer account update and the final clearing step between banks. SWIFT’s present route is closer to gradual modernization than a full rebuild of monetary settlement infrastructure.
Why tokenized deposits are emerging as banks’ preferred entry point
Banks are paying close attention to tokenized deposits because they preserve the legal structure and balance-sheet treatment of existing deposit money. A customer deposit is already a commercial bank liability. Tokenization changes how that liability is recorded and transferred, but it does not automatically create a separate issuer outside the banking system. By contrast, fiat-backed stablecoins are usually issued by dedicated entities that support token value with reserve assets, which means holder rights, redemption terms, bankruptcy remoteness and regulatory treatment all need separate design.
Tokenized deposits are also better positioned to preserve what the article calls the singleness of money. That means different forms of money in an economy can trade at par and be treated as the same unit of account. A deposit at Bank A and a deposit at Bank B are normally treated as equal not just because of bank credit, but because deposit insurance, central-bank reserves, clearing arrangements and prudential supervision support par convertibility. Some stablecoins may trade away from par because of issuer risk, reserve quality or liquidity differences.
SWIFT’s model is trying to carry that institutional foundation into a programmable environment. Banks remain responsible for customer due diligence, sanctions screening, transaction monitoring and account management. Tokenized deposits stay inside the regulated banking system. The shared ledger provides interbank coordination without requiring each institution to move into a public-chain economy it does not already operate in.
There is also a funding and credit angle. Stablecoin issuers usually back circulating tokens with highly liquid reserves, which makes the business resemble a payment instrument or narrow-reserve structure. Commercial banks, by contrast, fund lending and maturity transformation through deposits. For large corporate clients, if programmable payments can still be initiated from their existing bank accounts and credit lines, they do not need to move large pools of cash outside the banking system just to access digital settlement.
That does not mean tokenized deposits will displace stablecoins altogether. Stablecoins still hold advantages in public blockchain reach, global accessibility, on-chain activity and developer ecosystems. A layered market is more plausible: stablecoins continue serving public-chain-native use cases and some cross-border payments, while tokenized deposits move first into institutional treasury, trade, securities settlement and regulated digital-asset markets. Competition would then focus less on which token is faster, and more on which model offers usable compliance, interoperability and a broad acceptance network.
Higher efficiency, but tighter liquidity demands
For corporate clients, the most immediate change is a weaker time boundary around payments. Intraday and cross-border cash movements, margin top-ups, supply-chain payments and weekend transactions would no longer be tied as tightly to bank opening hours. DBS said in a public statement that businesses operate around the clock, and their funds need continuous availability as well. OCBC and UOB linked the live results to programmable, interoperable and cross-time-zone payment capability.
Always-on payments may also reduce precautionary cash buffers that companies hold against delays. The more transparent cross-border payment status becomes, the easier it is for companies to estimate when funds will arrive and when they become usable. That can affect cash pooling and short-term funding decisions. For banks, a shared state can reduce repeated reconciliation and exception handling, shifting part of the operating burden from manual coordination to common standards and automated controls.
But faster settlement does not automatically mean lower liquidity needs. Traditional payment systems often smooth funding demands through batch processing, net settlement or end-of-day windows. Once activity moves to real-time, 24/7 operation, banks need to monitor positions overnight, on weekends and during holidays. If the customer-side payment is already executed while final interbank discharge is deferred to a later window, participating banks must manage the resulting credit exposure and collateral arrangements in the meantime.
The International Monetary Fund, in its 2026 research on tokenized finance, said continuous settlement changes the rhythm of liquidity management and that automated execution could accelerate margin calls and outflows during stress periods. That is why new infrastructure needs limits, pause functions, manual intervention, fallback procedures and liquidity-support tools alongside automation. In institutional markets, the hard problem is not just getting a smart contract to execute. It is deciding when it must be stopped.
The cost structure changes too. Reconciliation, message matching and some intermediate steps may shrink, but network connectivity, smart-contract audits, key management, data governance and 24/7 operations become new fixed costs. Large banks may be better able to absorb them. Smaller institutions may depend on shared service providers. That would increase scale effects in infrastructure and raise fresh concentration questions.
Legal questions are shifting toward when records take effect
Tokenized deposits sit on top of existing deposit relationships, but that does not settle every legal issue. One immediate question is which record has legal priority: the on-ledger record or the bank’s core ledger. If the two diverge because of a system failure, a network fork or a manual correction, contracts, operating rules and applicable law need to determine which record governs customer rights.
Settlement finality is another issue. A system status marked as successful is not enough on its own. Insolvency administrators, courts and other counterparties also need to recognize that a transfer is legally complete and cannot be unconditionally unwound. In a cross-border transaction involving different banks, ledger rules, correspondent banks and settlement systems, finality may arise at several distinct points rather than one.
Jurisdiction and conflict of laws add another layer. A customer may be in one country, the deposit bank in another, the shared-ledger nodes across multiple regions, and final settlement in a third-country currency. If an execution error, asset freeze or institutional failure occurs, the legal nature of the tokenized deposit, set-off rights and priority ranking cannot be settled by technical design alone. Large-scale cross-border use would need clearer participation rules and stronger legal opinions.
Anti-money laundering, sanctions compliance and data governance remain central as well. A permissioned network can limit who joins, but it cannot replace transaction monitoring. Around-the-clock programmable payments compress the time available for manual review and raise the bar for sanctions-list updates, beneficial-ownership identification, blocking suspicious activity and correcting false positives. At the same time, a shared ledger must balance verifiability with bank secrecy, personal-data protections and restrictions on cross-border data transfer.
Then there is code governance. Once smart contracts are involved in controlling money flows, a software flaw becomes a financial-risk issue. Questions such as who can upgrade a contract, pause transactions or correct an erroneous record, whether upgrades require joint approval from participating banks, and whether regulators can obtain timely audit information are all governance issues. In traditional finance, much of the risk sits in balance sheets and processes. In tokenized systems, part of that risk moves into platform rules, interfaces and code.
How banks, stablecoins and infrastructure providers may divide the market
The broader industry significance of SWIFT Ledger is that the global banking network is responding to the pressure stablecoins created around always-on payments by using its own liability instruments. One of stablecoins’ clearest advantages has been the ability to move on-chain without bank-hour constraints. If tokenized deposits can also run continuously, institutional users are likely to compare tools by credit structure, regulatory treatment, balance-sheet efficiency and integration with existing banking services.
For commercial banks, this is both a defensive move and a new entry point for business. Banks can reduce incentives for clients to move cash out of the deposit system and can bundle programmable payments with cash management, trade finance, foreign exchange and securities services. For SWIFT, the shared ledger extends its role beyond messaging standards and network connectivity into transaction-state coordination. Its competitive edge is not ownership of a particular blockchain. It is the institutional identity framework, global connectivity, messaging standards and compliance cooperation network it already has.
Traditional payment infrastructure is examining both forms of digital money at the same time. In September 2026, Nacha, which oversees rules for the U.S. automated clearing house network, said it had formed a project team to study how stablecoins and tokenized deposits could affect multiple kinds of payments. That signals a wider transition. The debate is no longer just about banks versus the crypto sector. Clearing organizations, card networks, financial-market infrastructure groups and software providers are all adjusting.
For fintech firms, the bigger opportunity may sit at the application layer. Companies will not redesign treasury operations simply because the underlying ledger changes. They need cross-bank cash views, automated receivables and payables, compliance orchestration, on-chain and off-chain reconciliation, and conditional-payment tools. The firms that package tokenized-payment capability into software that treasury, trade and asset-management teams already use may be the ones that build recurring revenue.
Concentration risk, however, cannot be ignored. If a large number of banks depend on the same orchestration layer, identity service or smart-contract template, the impact of a single point of failure grows. Network effects can reduce fragmentation, but they also make governance quality and operational resilience far more important. Over time, regulatory scrutiny may widen from token-issuing banks to the technology and infrastructure providers that play a critical role in transaction execution.
The current limits of live adoption
First, successful live transactions do not mean global commercial coverage is already in place. Seventeen early participating banks and a small number of currencies can show that the route works technically, but they do not prove that all time zones, jurisdictions and long-tail correspondent relationships are ready to connect. Cross-border complexity often comes from the last mile, local compliance and liquidity, not just the core ledger.
Second, separating payment execution from final settlement is practical, but it remains a constraint. As long as final interbank funds still move through existing RTGS and correspondent-banking channels, transactions that occur at night or over weekends will need credit limits, prefunding or deferred settlement arrangements. A shared ledger can improve coordination. It does not remove currency risk, maturity risk or counterparty risk on its own.
Third, interoperability must move from technical connectivity to common business rules. Different banks may adopt different tokenized-deposit platforms, data models and privacy tools. Even if interfaces can pass instructions back and forth, participants still need common asset identifiers, state definitions, error-handling rules, compliance allocation and dispute-resolution procedures. Scalable interoperability means more than systems understanding one another. It means institutions sharing the same legal reading of a transaction’s consequences.
Fourth, client demand still needs to be tested. It remains unclear how much companies are willing to pay for always-on payments, which use cases truly require second-level execution, whether new workflows improve working capital, and whether banks can offer competitive pricing. The technology supply is here. The business model is still taking shape.
What to watch next
According to Corundum, the most useful indicators in the next phase will not be the speed of a single transaction but three institutional measures.
The first is whether participation expands from bilateral arrangements or small-bank groups into multi-currency, multi-region networks. If each new institution requires heavy customization, network effects will be limited. If existing SWIFT connectivity and standards materially reduce onboarding costs, expansion could accelerate.
The second is whether the final settlement asset changes. The current design keeps RTGS and correspondent settlement in place, reducing early transition risk. If tokenized central-bank reserves, wholesale central bank digital currencies or other regulated on-chain settlement assets are added later, the gap between payment execution and final discharge could narrow further. That would also bring more central-bank access questions and more legal complexity.
The third is whether regulators begin setting dedicated operational, code and recovery requirements for shared ledgers. As volume grows, smart-contract audits, key recovery, transaction pauses, data access and cross-border crisis coordination may move from project governance issues into financial-stability issues. In that environment, deciding who is authorized to make exceptions at machine speed could matter more than normal-state automation itself.
From an industry perspective, SWIFT is not trying to fight public blockchains for every use case. It is starting from what banks already know best: deposit liabilities, identity networks and settlement systems, then adding digital functionality in stages. The strength of that route is compliance and institutional reach. The weakness is that progress depends on coordination across many parties. Whether it becomes a common connectivity layer for institutional tokenized finance will depend on whether the project can preserve trust without creating a new closed silo.
The live U.S. dollar and Singapore dollar transactions in September 2026 show that tokenized deposits are moving beyond pure proof-of-concept work and into real bank liabilities and production workflows. What SWIFT Ledger demonstrates is not a sudden migration of traditional finance onto one blockchain. It is a banking-system attempt to bring 24/7 operation, programmability and shared state into the existing regulatory structure.
That path could weaken part of stablecoins’ time-based advantage in institutional payments and push banks, clearing groups and fintech firms to redraw their responsibilities. Even so, it still relies on existing final-settlement channels and still faces open questions around liquidity, legal finality, cross-border jurisdiction, code governance and infrastructure concentration.