A bank executing a cross-border currency transaction may have sufficient funds, an approved counterparty and valid payment instructions, yet the transaction can still fail because one participating system cannot complete its part of the exchange. In conventional financial infrastructure, this creates a familiar problem: one side of a transaction may settle while the other remains outstanding, exposing participants to settlement risk. Atomic settlement promises a different outcome by linking the movements together so that either all required transfers complete or none becomes final. The principle is straightforward, but implementing it across banks, currencies and technology platforms introduces another set of challenges. Funds may need to be reserved while systems coordinate, a temporary network failure can leave participants uncertain about transaction status, and a delay in one component can prevent an otherwise valid transaction from completing. As central banks and financial institutions experiment with tokenised deposits, programmable settlement and interconnected ledgers, the question is no longer simply whether atomic settlement is technically possible. It is how much liquidity, coordination and operational complexity financial institutions must absorb to make it work reliably at scale.
Atomic Settlement Solves One Risk but Introduces Another Set of Dependencies
Atomic settlement is designed to ensure that multiple related transfers are executed as a single indivisible transaction. In foreign exchange, this can mean that the delivery of one currency occurs only when the corresponding delivery of another currency is completed. In securities markets, it can link the transfer of an asset to the transfer of the money used to purchase it. The principle is commonly associated with payment-versus-payment and delivery-versus-payment arrangements, which aim to prevent one participant from delivering value without receiving the corresponding value in return.
The benefit is significant because settlement risk does not disappear merely because payment systems become faster. If two related transfers occur independently, there may be a period during which one participant has fulfilled its obligation while the other has not. This creates exposure to counterparty failure, operational disruption or delays between settlement systems. By coordinating both sides of the exchange, atomic settlement can reduce or eliminate the principal risk associated with one-sided completion, provided the underlying arrangement achieves legally effective and operationally reliable finality.
However, ensuring that both sides complete together requires more than placing transactions on a distributed ledger. Participating systems must agree on the conditions for execution, confirm the availability of funds or assets and coordinate the point at which settlement becomes final. Where different platforms are involved, they may have different operating rules, processing speeds, access controls and technical mechanisms for confirming transactions. The system must therefore manage not only the movement of value but also the dependencies between every component involved in that movement.
This introduces a different category of risk. Instead of accepting the possibility that one leg settles before another, the infrastructure must ensure that incomplete transactions do not create unintended final transfers. Achieving that outcome can require reserving liquidity, delaying final execution and introducing additional coordination services. The challenge is to obtain the risk reduction without creating excessive operational friction.
What Actually Happens When One Side of the Transaction Fails?
Consider a hypothetical wholesale foreign exchange transaction in which Bank A needs to deliver US dollars while Bank B delivers euros. Both institutions have sufficient funds, and the transaction has passed the necessary validation checks. Under an atomic settlement arrangement, the infrastructure coordinates the two currency movements so that neither becomes final unless both can complete.
If Bank A’s dollar transfer is ready but the euro-side system becomes unavailable, the transaction should not simply proceed with the dollar movement. Instead, the arrangement must follow its defined failure-handling rules. Depending on the architecture, the transaction may remain pending while the system waits for the unavailable component, be cancelled before settlement, or require an operational recovery process to determine whether completion is still possible. Any funds or assets reserved for the transaction must be managed according to those rules.
This sounds manageable until the failure occurs at an inconvenient point in the process. One system may have confirmed that funds are available, another may have reserved its balance, and the coordination service may lose connectivity before receiving confirmation that every required condition has been satisfied. The participants then need a reliable way to establish the transaction’s authoritative state. They must know whether settlement has occurred, whether the transaction remains pending and whether reserved liquidity can safely be released.
The precise answer depends on the settlement design. Some arrangements use a shared platform where all required state changes can be committed together. Others coordinate transactions across separate systems through synchronisation services or cryptographic mechanisms. A timeout in one architecture may trigger a safe cancellation before finality, while another design may require participants to reconcile transaction records after connectivity is restored. Atomicity is therefore a property that must be engineered and demonstrated within the relevant system boundaries, rather than assumed from the use of a particular technology.
The important distinction is between a transaction failing before settlement and a participant being uncertain about whether settlement has already become final. The first is primarily a transaction-processing problem. The second can become an operational and legal problem if the institution cannot determine which obligations have been discharged. Robust settlement infrastructure must be designed to prevent this ambiguity from producing duplicate payments, inconsistent balances or unauthorised reversals.
The Liquidity That Must Wait for Settlement
One of the less visible costs of atomic settlement is the liquidity required to support coordinated execution. Before a transaction can settle, participating institutions may need to demonstrate that sufficient funds or assets are available. In some designs, the required balances are reserved or locked until the conditions for completion have been satisfied. This prevents the same funds from being committed to another transaction while the first exchange remains pending.
Reserving liquidity is not inherently inefficient. Conventional financial market infrastructures also require participants to manage settlement balances, collateral and intraday funding. Atomic arrangements may ultimately reduce liquidity needs by shortening settlement cycles, eliminating some intermediaries and allowing transactions to complete more directly. The problem arises when the coordination process takes longer than expected or when multiple transactions compete for limited available balances.
Imagine a bank preparing a series of high-value foreign exchange transactions across several currencies. If one transaction requires funds to remain reserved while an external platform completes its validation, those balances may not be available for another payment. If the external platform experiences an outage, the bank may need to maintain the reservation until the transaction is safely cancelled or resolved. As pending transactions accumulate, the institution could face a growing difference between its total liquidity and the liquidity immediately available for new settlement activity.
This does not mean atomic settlement necessarily increases aggregate liquidity requirements. Its impact depends on transaction sequencing, reservation duration, netting opportunities, settlement speed and the design of liquidity-saving mechanisms. An efficient atomic settlement platform could reduce the time during which participants carry exposures and hold funds across multiple intermediaries. A poorly coordinated arrangement, however, could create avoidable liquidity bottlenecks.
The economic challenge is therefore to minimise the amount of time that value remains committed without being productively settled. For banks processing large transaction volumes, even modest changes in the duration of liquidity reservations can affect intraday funding strategies, operational flexibility and the capacity to execute additional payments.
When Multiple Transactions Begin Waiting for One Another
Liquidity management becomes more complicated when transactions are linked through dependencies. A bank may expect to receive one currency from an incoming settlement and use those funds to complete another payment. If the first transaction is delayed, the second may also be unable to proceed. Similar dependencies can develop when multiple participants require funds that are temporarily reserved elsewhere in the system.
In computer science, a deadlock occurs when processes cannot progress because each is waiting for resources held by another. Financial settlement systems can encounter comparable resource-allocation problems when transactions require multiple balances or assets to become available simultaneously. For example, one participant may have sufficient funds overall but not enough immediately available liquidity in a particular currency because those funds are reserved for another pending exchange.
Avoiding these situations requires careful design. Settlement engines may need to establish transaction priorities, manage queues, impose reservation time limits or identify groups of payments that can settle together. Liquidity-saving mechanisms can help by allowing transactions to offset one another or by optimising the sequence in which they are processed. These capabilities are already important in conventional wholesale payment infrastructure, and they remain relevant when settlement becomes programmable or extends across different ledgers.
Atomicity by itself does not determine how these problems should be solved. It establishes the requirement that linked transfers complete together, but it does not automatically provide the most efficient method for allocating liquidity among competing transactions. That optimisation must be implemented through the surrounding settlement architecture.
A Shared Ledger Does Not Eliminate Every Failure Scenario
One approach to reducing coordination complexity is to place the relevant settlement assets on a shared programmable platform. When tokenised deposits and central bank money can be represented within a coordinated environment, the system may be able to validate conditions and execute related transfers without relying on a long sequence of separate messages between institutions.
This is one of the ideas explored by the Bank for International Settlements through Project Agorá. In May 2026, the BIS reported that the project’s prototype had demonstrated atomic settlement of wholesale cross-border transactions using tokenised commercial bank deposits and tokenised central bank reserves. The initiative involved seven central banks in its original collaboration and more than 40 regulated financial institutions, with the Bank of Canada subsequently joining the next phase of work.
The prototype showed that transactions could be coordinated across currencies and jurisdictions while preserving the distinction between commercial bank deposits and central bank reserves. Its architecture also allowed central banks to retain control over domestic monetary operations rather than requiring every participating jurisdiction to surrender that authority to a single operator.
These findings are important, but they should not be interpreted as proof that every operational challenge has been resolved. Project Agorá remains an experimental initiative, with further work intended to examine real-value transactions and the technical, contractual and operational requirements of implementation. The prototype demonstrates that atomic cross-border settlement is feasible within a particular architecture; it does not establish that such systems can be deployed universally without additional engineering and governance arrangements.
Even on a shared platform, failures can occur in network connectivity, transaction validation, software execution or supporting infrastructure. Institutions still need clear rules governing transaction status, recovery, liquidity reservations and operational responsibilities. A common platform can reduce certain interoperability problems, but it also introduces questions about shared infrastructure dependencies and how disruptions affecting the platform would be managed.
Coordinating Settlement Across Different Ledgers Is Harder
Not every financial institution will operate on the same settlement platform. Banks may use existing real-time gross settlement systems, proprietary tokenisation networks, securities infrastructures and different forms of digital money. In this environment, atomic settlement requires a mechanism for coordinating transfers across systems that may not share a common transaction engine.
The BIS Innovation Hub’s Project Meridian FX explored this challenge through the concept of a synchronisation operator. Working with the Bank of England and several Eurosystem central banks, the project examined how foreign exchange transactions could be settled atomically across different wholesale payment infrastructures, including connections between conventional RTGS environments and distributed ledger platforms.
Published in April 2025, the project’s findings demonstrated the technical feasibility of synchronising payment-versus-payment foreign exchange settlement across distinct infrastructures. The experiments also examined liquidity-saving functionality and transaction rules, providing evidence that atomic settlement does not necessarily require every asset or currency to be held on one ledger.
The architecture nevertheless introduces a coordination dependency. A synchronisation service must obtain reliable information from participating systems, determine whether settlement conditions have been satisfied and manage execution according to the agreed protocol. If one system becomes unavailable, the coordination process needs a defined response. If communication fails during execution, participants must be able to establish whether the relevant transfers have become final.
These requirements become particularly important when connecting systems with different operating hours, processing characteristics and legal arrangements. A settlement instruction that is valid in one infrastructure may not be executable immediately in another. The coordination layer must account for these differences rather than assume that every connected platform operates under identical conditions.
Timeouts, Retries and the Risk of Duplicate Execution
One of the most important engineering questions in distributed settlement concerns what happens when a system does not receive an expected response. A missing confirmation does not necessarily mean that the underlying operation failed. The receiving platform may have completed its work but been unable to transmit the acknowledgement, or the acknowledgement may have been lost during a network interruption.
This distinction matters because blindly retrying a financial transaction can create duplicate execution if the original operation was successful. Settlement platforms therefore need mechanisms for identifying transactions uniquely, checking authoritative status and preventing repeated requests from producing unintended transfers. Idempotent processing, where repeated submission of the same instruction does not cause repeated economic execution, is an important design objective.
Timeouts also require careful treatment. A system may impose a deadline after which an incomplete transaction should no longer proceed, but the deadline must be coordinated with the settlement and finality rules of the participating infrastructures. Releasing reserved funds too early could create conflicts if another system still considers the transaction eligible for completion. Holding funds indefinitely, on the other hand, can unnecessarily constrain liquidity.
For this reason, failure recovery needs to be treated as part of the settlement protocol rather than as an operational procedure added after implementation. Institutions need reliable transaction identifiers, consistent status information, auditable state transitions and clear rules for resolving interrupted operations. These requirements may be less visible than the underlying distributed ledger technology, but they are essential to making atomic settlement dependable.
Technical Completion and Legal Finality Must Agree
A transaction can be technically recorded as complete without every legal question surrounding its finality being automatically resolved. Settlement finality determines when a transfer becomes irrevocable and unconditional under the applicable legal framework. This distinction is particularly important for cross-border arrangements involving multiple jurisdictions, currencies and financial market infrastructures.
An atomic settlement mechanism must therefore align its technical execution rules with the legal obligations of participating institutions. If a transfer is final under one system’s rules, the corresponding transfer in another system must be coordinated in a manner that preserves the intended all-or-nothing outcome. Questions can arise over insolvency treatment, participant obligations, system governance and the point at which settlement instructions can no longer be cancelled.
Project Agorá’s legal analysis found that settlement finality was achievable across the participating jurisdictions, while identifying further work needed to define appropriate technical, operational and contractual requirements. This is a useful distinction. Legal feasibility provides an important foundation, but a production system still needs detailed rules explaining how finality is established and how exceptional circumstances are handled.
For banks, these considerations affect more than legal documentation. Transaction-processing systems, reconciliation procedures and operational controls must reflect the actual point of settlement finality. A bank cannot safely treat a transaction as reversible simply because its internal application has not received a confirmation, particularly if the relevant settlement infrastructure has already completed an irrevocable transfer.
Compliance Checks Can Become Part of the Settlement Bottleneck
Programmable settlement can bring transaction validation, regulatory checks and execution closer together. In principle, this can reduce manual intervention and avoid situations where information must be repeatedly exchanged between institutions. However, it also means that a transaction may depend on multiple validation processes completing before settlement is permitted.
A cross-border payment could require sanctions screening, confirmation of participant eligibility, transaction-limit checks and other controls before the associated balances are released. If one of these checks is unavailable or returns an unresolved result, the transaction may need to remain pending or be rejected. The settlement architecture must define whether funds are reserved before or after the relevant checks and what happens if a previously valid transaction becomes ineligible during processing.
This creates a design trade-off. Reserving funds early may improve the likelihood that a transaction can complete once validation is finished, but it can tie up liquidity while compliance processing continues. Completing validation before reserving funds can reduce unnecessary reservations, although the required balances may no longer be available when the transaction becomes ready to settle.
The appropriate sequence depends on the system’s design and the regulatory requirements involved. What matters is that compliance processing, liquidity management and settlement execution cannot be designed independently if the objective is to deliver reliable atomic transactions.
The Cost of Reliability May Be Greater Than the Cost of Execution
Tokenised settlement platforms are often evaluated according to transaction speed, processing capacity and the potential reduction in intermediaries. These are important measures, but they do not fully capture the cost of operating an atomic settlement system.
Financial institutions also need to consider how frequently transactions remain pending, how long liquidity is reserved, how often failures require intervention and what infrastructure is needed to maintain availability. A platform capable of completing transactions almost instantly under normal conditions may still impose significant operational costs if exceptional cases are difficult to resolve.
There is also the question of resilience. Coordinated settlement may depend on multiple systems being available at the same time, which can create additional requirements for redundancy, monitoring and recovery. Shared platforms can simplify certain transaction flows but may concentrate operational dependencies. Cross-ledger architectures can preserve existing infrastructures but introduce more coordination points. Neither approach is inherently superior in every circumstance.
The economics therefore depend on the full transaction lifecycle, including unsuccessful and interrupted transactions. Banks need to understand not only the cost of a completed settlement but also the resources consumed by transactions that are delayed, cancelled or require recovery.
This is particularly relevant for technology providers developing tokenisation platforms and settlement orchestration systems. Demonstrating successful transactions is an important milestone, but commercial deployment will require evidence that the infrastructure behaves predictably under adverse conditions and does not create unacceptable liquidity or operational burdens.
Why Atomic Settlement May Not Be Necessary for Every Payment
Atomic settlement is particularly valuable when multiple transfers must be linked to prevent one participant from delivering value without receiving the corresponding asset or currency. Foreign exchange and securities settlement are natural applications because the relationship between the two legs creates a direct settlement-risk exposure.
Not every financial transaction has the same characteristics. A straightforward domestic payment may already settle efficiently through established infrastructure without requiring a separate cross-ledger coordination mechanism. Introducing additional dependencies where they are not needed could increase complexity without delivering a proportionate benefit.
Financial institutions therefore need to assess where atomic settlement provides meaningful improvements over existing arrangements. The relevant factors include counterparty exposure, the number of participating systems, the type of settlement assets, transaction value, liquidity requirements and the operational costs of coordination.
The objective should not be to make every financial transfer atomic simply because the technology allows it. It should be to apply coordinated settlement where the reduction in risk and processing friction justifies the associated infrastructure and liquidity requirements.
The Next Challenge Is Making Atomic Settlement Operationally Efficient
Research by the BIS and participating central banks has moved atomic settlement beyond a purely theoretical concept. Project Meridian FX demonstrated that synchronised settlement could work across different wholesale payment infrastructures, while Project Agorá showed how tokenised commercial bank deposits and central bank reserves could support atomic multi-currency settlement within a programmable architecture. These experiments provide an important foundation for future financial infrastructure.
The next stage is likely to involve closer examination of the conditions under which such systems can operate reliably at scale. This includes liquidity optimisation, failure recovery, interoperability, legal finality and the governance of infrastructure shared by multiple financial institutions. Real-world transaction volumes, unexpected outages and changing market conditions may expose challenges that are difficult to reproduce in controlled experiments.
For banking technology providers, the opportunity lies in developing settlement systems that do more than coordinate successful transfers. They must be able to manage reservations efficiently, resolve interrupted transactions, maintain consistent records and provide institutions with reliable information about settlement status. These capabilities may ultimately determine whether atomic settlement delivers the operational benefits anticipated by its proponents.
Atomic settlement addresses a longstanding weakness in financial markets by preventing linked transfers from completing independently. But the guarantee that everything settles together comes with an obligation to manage everything that happens before completion, particularly when one component cannot proceed. The financial institutions that benefit most will be those that understand the cost of that coordination and design their infrastructure to minimise it.
What this means for the industry
- Atomic settlement reduces principal risk but does not eliminate operational risk. Financial institutions still need robust mechanisms for managing outages, transaction uncertainty and recovery.
- Liquidity efficiency will be a critical measure of success. The time funds remain reserved and unavailable for other transactions can influence the economics of atomic settlement.
- Failure handling must be part of the architecture. Timeouts, transaction retries, cancellation rules and authoritative status checks are essential to preventing duplicate or inconsistent execution.
- Interoperability will determine how widely atomic settlement can be adopted. Banks and financial market infrastructures will need ways to coordinate transactions across different ledgers, currencies and settlement systems.
- Legal finality must align with technical execution. Atomic settlement arrangements require clear rules governing irrevocability, participant obligations and exceptional circumstances.
- Banking technology vendors face a new engineering challenge. Settlement orchestration, liquidity optimisation, monitoring and recovery capabilities could become important differentiators.
- Atomic settlement should be applied selectively. Its benefits are strongest where coordinated execution materially reduces settlement exposure or operational friction.
