Atomic Settlement With Delivery-Versus-Payment on Distributed Ledgers
Making Both Legs Move Together, or Neither Move at All
Delivery-versus-payment is not a new idea and atomic settlement is not a new objective. Securities settlement systems have managed principal risk for decades by ensuring that delivery and payment either both happen or neither does. What distributed ledger technology changes is the mechanism, the timing, and crucially the range of things that can be settled against each other.
That makes the engineering question narrower and more interesting than the usual framing suggests. Designing atomic settlement DvP DLT systems is mostly about two decisions: what the cash leg is, and what happens when something fails halfway. The distributed ledger part is the easier half.
What problem does atomic settlement actually solve?
Principal risk, meaning the exposure created when one party performs and the other does not.
In a non-simultaneous exchange, one side delivers securities and waits for cash, or pays and waits for delivery. In between, the full value is at risk. Existing infrastructure addresses this through central securities depositories and settlement systems that coordinate both legs, which is why the CPMI-IOSCO Principles for financial market infrastructures, published in April 2012, apply to central securities depositories and securities settlement systems alongside payment systems, central counterparties, and trade repositories. Tokenisation offers a different route to the same objective, potentially with a shorter cycle and a wider set of assets.
What does atomicity add over existing DvP?
Composability and timing, rather than a fundamentally new guarantee.
The material gains are that settlement can occur continuously rather than in cycles, that assets not currently served by an efficient depositary can participate, and that settlement can be composed with other actions in one transaction, such as a repo leg or a collateral substitution. Be precise about which of those benefits you are pursuing, because a programme justified as removing principal risk is solving a problem existing infrastructure already handles for mainstream instruments.
Which specific benefit is your tokenisation programme pursuing: timing, asset coverage, or composability?
What are the architectural options?
Four, with a clear trade-off between coordination complexity and platform reach.
| Option | How it works | Strength | Weakness |
|---|---|---|---|
| Single ledger, both legs | Cash and asset tokens on one platform, one transaction | Simplest atomicity, no protocol needed | Requires both on the same platform |
| Cross-ledger with hash-locked contracts | Conditional locks with a shared secret and timeouts | Works across platforms | Timeout risk, liquidity locked, complexity |
| Cross-ledger with a trusted coordinator | A coordinating party sequences both legs | Simpler than cryptographic protocols | Reintroduces a trusted intermediary |
| Hybrid with existing payment system | Asset leg on ledger, cash leg via RTGS with confirmation | Uses proven cash infrastructure | Not truly atomic, needs bridging design |
Why is single-ledger both simplest and hardest?
Because atomicity is free within one transaction and getting cash onto the platform is the whole problem.
If tokenised cash and tokenised assets exist on the same ledger, delivery-versus-payment is one atomic state transition with no coordination protocol, no timeout, and no partial state. Every other option exists because that condition is difficult to satisfy, since the cash leg needs to be something participants accept as settlement. That is why the interesting experimentation focuses on putting central bank and commercial bank money onto shared platforms rather than on the settlement mechanics themselves.
What are the trade-offs of hash-locked approaches?
They work without a trusted coordinator and they impose timeout risk and locked liquidity.
Conditional locks release both legs on revelation of a secret, with timeouts to unwind if it never arrives. That achieves atomicity across platforms and introduces new operational realities: assets are locked while the protocol runs, timeouts create a window where one party can choose whether to proceed based on market movement, and the failure path leaves participants with unwound trades they need to re-execute. Those are manageable and they are real, and they should be modelled operationally rather than treated as protocol detail.
What is the cash leg, and why is it the real decision?
Because it determines the legal character of settlement, the operating hours, and who bears what risk.
| Cash leg | Character | Considerations |
|---|---|---|
| Tokenised central bank money | Settlement in central bank money | Availability depends on central bank arrangements |
| Tokenised commercial bank deposits | Claim on a bank | Credit and concentration considerations, bank issuance |
| Regulated stablecoin | Claim on an issuer with reserves | Redemption, reserve quality, run risk |
| Off-ledger payment with on-ledger confirmation | Existing rails plus a bridge | Not atomic, operating hours constrain settlement |
The choice is not primarily technical. Settling against a claim on a commercial bank is economically different from settling against central bank money, and both differ from settling against an issuer's stablecoin. Take that analysis to treasury, risk, and legal before selecting a platform, because retrofitting a different cash leg late is close to a rebuild. The design of the bank-issued options is the subject of tokenised deposits and stablecoin infrastructure.
What does live experimentation actually show?
That multi-currency atomic settlement with tokenised reserves and deposits works, at modest scale and useful speed.
The BIS Innovation Hub's Project Agorá, a public-private collaboration involving eight central banks and more than forty financial institutions, is testing a multi-currency shared programmable platform for wholesale cross-border payments, combining tokenised central bank reserves with tokenised commercial bank deposits to enable atomic settlement. Its real-value testing in July 2026 involved 28 institutions completing approximately CHF 800,000 in transactions across multiple currencies, with average settlement of approximately 80 seconds from initiation, covering payment-versus-payment among other use cases, and demonstrating interoperability with existing real-time gross settlement and core banking systems using ISO 20022.
What does 80 seconds actually tell us?
That the constraint is coordination and operational process, not ledger throughput.
Eighty seconds is far slower than a ledger can technically confirm and far faster than a conventional cross-border settlement cycle, which locates the real cost precisely: it sits in authorisation, screening, coordination between participants, and the operational steps around the transaction. That is useful information for anyone designing a platform, because it means optimising consensus mechanics is not where the time is. It also means the operational model, including who is available to act at any hour, matters more than the technology choice.
Is your programme optimising ledger performance or the coordination steps around the transaction?
Where does legal finality come from?
From governing law, the rules of the arrangement, and insolvency treatment, not from the ledger.
This is the point where technology programmes most often assume too much. A state transition recorded irrevocably on a ledger is technically final, and whether it is legally final, meaning it cannot be unwound by a court or an insolvency administrator, depends on the legal framework surrounding the arrangement. The PFMI framework treats settlement finality as a matter for rules and law rather than mechanism. So the engineering deliverable includes a legal analysis: which law governs, what the rules of the arrangement say about finality and reversal, how insolvency of a participant is handled, and what happens if a token is transferred in error. Build the unwind capability the law requires rather than asserting that irreversibility is a feature.
Why is the code settled it not sufficient?
Because participants need certainty enforceable outside the platform.
If a transfer occurred through operational error, fraud, or a defect, someone will seek redress, and the platform's rules must say how that is handled. Designs that treat immutability as absolute end up with either no remedy or an ad hoc one improvised under pressure, and neither is acceptable in a regulated settlement context. Define the correction mechanism, restrict who can invoke it, log it comprehensively, and make it rare by design rather than impossible. The audit trail patterns that support this are the ones in event sourcing and audit trails.
How do you handle failure modes?
With explicit timeouts, a defined unwind path, and an operational process for the aftermath.
| Failure | Consequence | Required design |
|---|---|---|
| One leg unavailable at settlement | Neither leg should settle | Conditional execution, no partial state |
| Timeout expiry in a cross-ledger protocol | Unwind with locked assets released | Defined timeout, monitoring, re-execution path |
| Participant system unavailable | Settlement cannot complete | Queuing, retry, deadline management |
| Smart contract defect | Potential incorrect state | Upgrade path, pause capability, formal review |
| Key loss or compromise | Assets unreachable or at risk | Key management, recovery arrangements, revocation |
| Ledger fork or reorganisation | Ambiguous state | Finality rules, permissioned design choices |
| Erroneous transfer | Wrong party holds an asset | Rules-based correction with governance |
The operational aftermath deserves as much attention as the technical unwind. A trade that failed to settle leaves participants with market exposure they expected to close, so the platform needs to notify quickly, state the position clearly, and support re-execution, which is the same discipline required when a payment fails on an instant rail as described in FedNow and RTP participation.
How does it interoperate with existing infrastructure?
Through standard messaging and deliberate bridges, because replacement is not on the table.
Agorá's testing specifically demonstrated interoperability with existing RTGS and core banking systems using ISO 20022, which is the right model: the tokenised platform participates in the existing ecosystem rather than expecting it to migrate. Practically that means mapping to and from standard messages, reconciling ledger state against depositary and core banking records continuously, and accepting that operating hours differ between the platform and the systems it connects to. Consistent structured data is what makes the mapping viable, which is why the CPMI's harmonised ISO 20022 data requirements matter here as much as in payments. Multi-party platform governance brings its own considerations, as covered in multi-party data sharing and consortium models.
What operational model does continuous settlement need?
Coverage, liquidity, and change management for a platform that does not close.
A settlement platform available continuously creates the same obligations as an instant payment rail: someone must be available to act at any hour, liquidity must be positioned without a funding window, and changes must be deployable under live traffic. Those requirements are frequently discovered late in tokenisation programmes because the pilot ran during business hours. Plan the operating model alongside the architecture, and note that clearing and collateral processes connected to the platform inherit the same constraints, as discussed in CCP clearing connectivity architecture.
How should a programme be sequenced?
Legal and cash leg first, then a narrow asset class, then interoperability, then scale.
| Phase | Duration | Deliverable |
|---|---|---|
| Legal and finality analysis | 2 to 4 months | Governing law, rules, insolvency treatment, correction mechanism |
| Cash leg decision | 2 to 3 months | Selected instrument with treasury, risk, and legal sign-off |
| Narrow asset class pilot | 4 to 6 months | One instrument type, one settlement pattern, real participants |
| Failure path engineering | 2 to 3 months | Timeouts, unwind, notification, re-execution, rehearsed |
| Interoperability | 3 to 5 months | ISO 20022 mapping, reconciliation to depositary and core |
| Operating model for continuous settlement | 2 to 3 months | Coverage, liquidity, live change capability |
| Scale and additional asset classes | Ongoing | Incremental, with reconciliation maintained throughout |
Legal analysis first is not caution, it is the requirement that determines the architecture. A design that cannot be unwound in the circumstances the law requires will not be approved, and discovering that after the platform is built is the most expensive possible sequencing. The honest framing about where distributed ledger technology genuinely helps and where it does not is set out in this assessment of blockchain use cases versus hype.
Which metrics matter?
Settlement success rate, time to settlement, failed leg incidence, unwind execution, and reconciliation breaks.
Report settlement success rate and, separately, the incidence of failures where one leg was ready and the other was not, since that distinguishes counterparty readiness from platform capability. Track time from instruction to final settlement at the median and the tail. Measure unwind executions and their operational aftermath, including time to re-execute. Report reconciliation breaks against depositary, core banking, and participant records, which is where a tokenised platform quietly diverges from the rest of the estate. And track availability across the full calendar rather than business hours, because continuous settlement is the property being claimed.
Atomic settlement on distributed ledgers is now demonstrably feasible, and the evidence suggests the hard parts are exactly where they always were: the cash leg, the legal framework, and what happens when something fails. Programmes that treat those three as the deliverable and the ledger as an implementation detail are the ones likely to reach production.
Frequently Asked Questions
What problem does atomic settlement solve?
Principal risk, meaning the risk that one party delivers and the other does not. Atomicity makes both legs conditional on each other so neither completes alone.
Is delivery-versus-payment new?
No. Existing infrastructures already deliver DvP through central securities depositories and settlement systems. Tokenisation changes the mechanism and the timing, not the objective.
What is the hardest design decision?
The cash leg. Whether you settle against tokenised central bank money, tokenised deposits, a stablecoin, or an off-ledger payment determines your legal and operational model.
Why is single-ledger settlement simplest?
Because both legs move in one transaction with no coordination protocol. It is also hardest to achieve, since it requires cash and securities on the same platform.
Does technical settlement give legal finality?
Not by itself. Finality depends on governing law, the rules of the arrangement, and insolvency treatment, so the legal analysis has to accompany the engineering.
What has live experimentation shown?
That multi-currency atomic settlement using tokenised reserves and deposits is feasible. BIS Project Agora's July 2026 real-value test settled in around 80 seconds on average.
What happens when one leg fails?
Nothing should settle. The design needs explicit timeouts, a defined unwind path, and an operational process for participants left with positions they expected to close.
Should this replace existing settlement infrastructure?
Not initially. Interoperability with RTGS, core banking, and existing depositories is what makes these platforms usable, and Agora tested exactly that using ISO 20022.
