Settlement is the point at which a trade becomes an exchange of completed obligations rather than an agreement to exchange later. In a securities transaction, one party delivers the asset and the other delivers payment. If either leg completes without the other, the exposed party faces principal risk. Delivery-versus-payment, or DvP, is the arrangement that links the two legs so delivery occurs if and only if payment occurs. Distributed ledgers can coordinate those states with programmable logic, but the word “atomic” should be used carefully. Technical simultaneity is not automatically legal finality, and a single transaction does not guarantee adequate liquidity or operational recovery.
This article explains the main DvP patterns, the finality questions behind them, and the controls needed when asset and cash exist on different systems. It complements the settlement chain guide and the architecture overview in Digital Asset Chain Explained. The focus is not a particular protocol; it is the sequence of states that market participants must be able to observe and trust.
Define the two legs before designing the link
The asset leg may be a natively issued digital security, a token representing an asset held elsewhere, a fund share, a collateral claim, or an internal ledger position. The cash leg may be commercial-bank money, central-bank money, a tokenized deposit, an e-money claim, a stable-value token, or another settlement asset. Each has different credit, liquidity, legal, and operational characteristics. A fast cash token is not equivalent to risk-free settlement money, and an on-chain asset representation may not itself be the authoritative ownership record.
The parties should name the unit being delivered, the party obligated on each leg, the record that proves completion, and the moment after which the transfer cannot be unilaterally reversed. They should also identify fees and intermediate balances. If a transaction moves through a bridge, omnibus wallet, or prefunded account, the end-to-end result may depend on more than the visible asset and cash transfers. Those dependencies belong in the settlement model.
Three broad DvP patterns
Single-platform atomic exchange
Both asset and cash are represented on the same execution environment, and one contract changes both states in a single transaction. This can minimize sequencing risk because either all required state changes are accepted or none are. The model still depends on the legal meaning and quality of the cash representation, the authority behind the asset token, contract correctness, and network finality. A contract failure or governance intervention can affect both legs at once, so shared infrastructure reduces some risks while concentrating others.
Coordinated settlement across connected systems
The asset and cash remain on separate ledgers or payment systems. An orchestrator, message protocol, hashed condition, or trusted gateway coordinates them. The systems may lock both legs, confirm readiness, and then release. This pattern preserves existing rails but introduces timing, messaging, and dependency risk. The design must specify what happens if one system confirms while the other is delayed, if messages arrive out of order, or if the coordinating service becomes unavailable.
Conditional or probabilistic synchronization
Some arrangements accept that the legs cannot be perfectly atomic. They use prefunding, guarantees, limits, insurance, or contractual rules to manage the interval. A platform might transfer the asset after a payment message reaches a defined status, even though the underlying payment can still fail in exceptional circumstances. This can be operationally reasonable, but the residual exposure should be measured and assigned. Calling it atomic does not remove the gap.
Finality has several meanings
Protocol finality describes when the network treats a transaction as irreversible or sufficiently unlikely to be reorganized. Operational finality describes when systems stop treating the instruction as pending. Legal finality describes when the transfer is recognized as effective and protected against reversal, including in insolvency. Accounting finality describes when books and records recognize the position and cash. These moments can differ. A credible DvP design records each state rather than compressing the process into a single “settled” flag.
Public chains may use economic or probabilistic finality. Permissioned networks may use deterministic consensus but retain administrative powers to pause or correct activity. Payment systems may issue an immediate confirmation while final settlement occurs later. Internal systems may update only after reconciliation. Participants should agree on confirmation thresholds, cutoffs, and the evidence required for each business action. For example, a custodian may display a pending balance before it is available for withdrawal or reuse.
Liquidity and funding do not disappear
Shortening settlement can reduce the time that exposure remains open, yet it can increase the need to have cash and assets available at the exact moment of execution. Netting reduces funding needs by offsetting obligations; gross atomic settlement may require more prefunding. Programmable liquidity tools can help sequence transactions or mobilize collateral, but they add rules and dependencies. A settlement design should model peak liquidity, failed trades, market stress, operating hours, and the cost of holding the settlement asset.
- Measure cash and asset availability under gross, bilateral-net, and multilateral-net scenarios.
- Define queues, priorities, partial fills, and deadlock resolution when multiple transactions compete for limited balances.
- Separate settlement speed from the ability to source funding during stress.
- Plan for interest, fees, or opportunity cost associated with prefunded positions.
- Specify who provides intraday liquidity and what happens when that provider reaches a limit.
Timeouts, retries, and exception states
A cross-system process needs a finite state machine. Common states include initiated, reserved, matched, cash locked, asset locked, committed, released, expired, cancelled, and under review. Every transition should have an authorized actor, a time condition, and an idempotent message. If an instruction is retried, it must not duplicate delivery. If a timeout occurs after one leg is locked, the system needs a safe release or escalation path. Operators should be able to distinguish a delayed confirmation from an actual failure.
Manual intervention is sometimes necessary, but it should not be invisible. Emergency actions require dual control, reason codes, timestamps, and post-event review. The system should preserve original instructions and corrective entries instead of rewriting history. Client communications should use the same status definitions as internal operations so a transaction is not described as complete while teams are still resolving the cash leg.
Smart contract and governance controls
DvP contracts control valuable state and should be narrowly scoped. Asset addresses, cash instruments, price parameters, timeouts, administrators, and upgrade paths require validation. The contract should reject unexpected token behavior and handle fees or transfer hooks deliberately. Governance must define who can pause settlement, update supported assets, or migrate contracts. If an administrator can move funds or bypass conditions, that power should be disclosed and protected with multi-party authorization and monitoring.
A settlement-readiness checklist
- Define the legal and operational finality point for each leg and each connected system.
- Document residual principal, credit, liquidity, custody, bridge, and operator risks.
- Test delays, message duplication, network reorganization, payment rejection, and participant default.
- Reconcile the asset register, cash record, transaction state, and internal books after every cycle.
- Provide portable evidence showing the instruction, approvals, matching, locks, release, and final result.
- Confirm that wind-down and migration preserve claims without creating duplicate assets or cash.
Conclusion
Distributed ledgers can make DvP more explicit and programmable, particularly when asset and payment states are visible to one workflow. The strongest designs resist the temptation to treat a fast transaction as the whole settlement solution. They define both legs, map every finality threshold, fund the process realistically, and make exception states recoverable. With those foundations, programmability can reduce sequencing risk and operational ambiguity instead of merely moving them into code.
Primary reference: For broader context on changing securities-settlement models, technology, and trade-offs, read the BIS analysis on the future of securities settlement.
