A securities trade has two linked obligations: deliver the asset and pay for it. Delivery versus payment, or DvP, makes final completion of one conditional on final completion of the other. The point is to prevent a party delivering its principal while receiving nothing in exchange. A system's failure behaviour is the clearest test of whether it achieves that result.
The CPMI-IOSCO principles for financial market infrastructures describe that conditional relationship for exchange-of-value settlement. Atomic execution is one technical method for implementing it. Institutions should test the actual relationship between obligations, rather than accept the word atomic as a complete risk description.
A failed transfer inside one transaction
On a programmable ledger, a contract can attempt both transfers inside one transaction. If the required cash transfer fails and the transaction reverts as designed, the securities transfer also reverts. The business state returns to its pre-transaction position, subject to the ledger's execution rules. The sender can still incur a network fee for the failed attempt.
This outcome depends on the actual contract and token behaviour. A token transfer can fail because an address is ineligible, a token is paused, an allowance is insufficient or an external check rejects the action. The settlement code must detect the failure and enforce the agreed all-or-nothing result. Ignoring a transfer's failure indication can undermine the intended exchange.
Neither party has completed the trade in this case. That protects principal, but it does not eliminate the obligation to settle, the cost of finding replacement funding or the market exposure of an outstanding trade. The operations record should say failed with no delivery, rather than settled and reversed, if no final delivery occurred.
Separate ledgers need a coordination process
When securities and cash sit on different ledgers, they cannot simply share one local transaction. A coordinator, locking mechanism or other protocol must connect their outcomes. The analysis then includes when each asset becomes unavailable, what evidence releases it and which conditions allow cancellation.
A lock prevents an asset being spent elsewhere while settlement is pending. That can protect an exchange, but it also ties up liquidity. A timeout can eventually release assets if completion does not occur. Its timing must account for message delays and finality on both sides. Two independent timers with superficially matching durations are not enough evidence that an adversarial or delayed sequence is safe.
The BIS discussion of a unified ledger and atomic settlement explains both the coordination benefit and the possible increase in liquidity demands. That tradeoff matters: eliminating an exposed principal transfer can require funds to be available earlier or remain unavailable longer.
Walk through a hypothetical failure
Assume a hypothetical buyer purchases $5 million of securities using a designated payment token. The securities are reserved at 10:00, and the payment tokens are locked at 10:01. Completion requires both systems to recognise the same settlement instruction and produce the required finality evidence.
At 10:02, the buyer's receiving securities address fails an eligibility check. Under the assumed design, the exchange does not commit, the securities reservation is cancelled and payment tokens are released through the cancellation path. Neither asset has been finally delivered to the other party. The desk still has an unsettled $5 million trade and a period during which its payment tokens were unavailable.
Now change one fact. The cash was sent as an ordinary final bank payment before the eligibility check, rather than locked under a linked process. The securities rejection leaves the seller holding cash and owing performance or a return payment. Calling the later refund a rollback does not make the original two transfers atomic.
The hypothetical illustrates why screenshots of two successful transfers are weak evidence. The proof lies in whether one final delivery can occur without the other under the failure conditions that the system claims to handle.
Finality and legal discharge must line up
Technical finality describes when the ledger treats a result as irreversible under its rules. Legal finality concerns when the transfer and associated obligations become effective under the governing arrangements. A settlement design needs an analysis connecting them, especially where an onchain token represents a security maintained on another register.
An internal token movement might not itself transfer the legal security. Equally, a contract can successfully exchange two tokens while a freeze, claim or eligibility restriction affects what the recipient can do afterward. Those questions belong in the definition of what has been delivered. Our article on blockchain finality and provisional settlement provides the surrounding distinction.
Cash quality is another boundary. Receiving a stablecoin removes the seller's claim against the buyer only to the extent provided by the trade arrangements. It leaves the seller holding the chosen settlement asset and its dependencies. DvP does not transform private token money into central bank money or guarantee subsequent redemption.
Compensation creates another exposure
A compensation process repairs an outcome through new transactions. A payment return, securities redelivery or indemnity can restore value, but each requires authority, available assets and cooperation or enforceable rights. It is a different protection from preventing one-sided final delivery in the first place.
That distinction should appear in incident records. If an intermediary advances missing cash, report the advance and resulting claim. If a party accepts substitute securities, record the substitution and valuation. A completed economic repair can still leave a temporary funding exposure, fees or a dispute over market movements.
The same principle applies to operator powers. An administrator able to intervene may improve recovery, but the intervention itself needs constraints and a documented effect on finality. A claim that settlement is irreversible should not coexist unexplained with a discretionary power to rewrite the relevant ownership record.
Recovery evidence should include the authority used and the claim extinguished, so finance can distinguish restored assets from a new receivable against an intermediary.
Measure the waiting state
Institutions need to observe assets reserved, assets locked, exchanges committed, cancellations pending and failed obligations still open. A binary success indicator misses the liquidity consumed between instruction and completion. Report the age and value of pending locks alongside settlement volumes.
Test deliberate failures at different points: before either reservation, after one lock, after both locks and while evidence is delayed. Include a coordinator outage and a receiving-address rejection. The expected state should identify who owns each asset, who can move it and what event releases it. Our discussion of interoperability across ledgers and legacy rails explains why that evidence must span the whole route.
A credible DvP design can describe its boundary in one precise sentence and reproduce its failure outcomes in a controlled test. Outside that boundary, funding, replacement cost and recovery risks still need owners. The institution gains more from that explicit allocation than from a broad promise of instantaneous settlement.