A Settlement Timeout Still Leaves an Obligation

Prepared on 17 September 2026 from retained public sources and a local executable model. No live securities or payment service was exercised.

Finality belongs to a particular obligation#

In the executable model below, the provider records a completed payment before its notification reaches the adapter. A policy that returns the security on timeout then leaves the seller with both the security and the completed payment. The adapter has acted on the absence of a message while the provider has already acted on the instruction.

For a submitted payment whose outcome is unknown, keep the security committed until the settlement authority resolves the instruction. I would give the timer authority to request reconciliation. A facility that links final cash settlement to final securities settlement can take responsibility for the conditional transfer, when its rules cover both obligations.

The word final needs an object. Chain finality concerns the chain's treatment of a transaction. For this model, the local escrow state is assumed final on the chain. Settlement finality concerns the transfer or discharge required by the governing arrangement. The CPSS and IOSCO's Principles for financial market infrastructures define final settlement through an irrevocable and unconditional transfer, or discharge of an obligation, under the underlying contract. Paragraph 3.8.1 and its footnote 86 make the legal character of that moment explicit. Principle 8

The SEC staff's statement of 28 January 2026 gives a concrete reason to keep those objects separate. In one of the issuer models it describes, a blockchain transfer notifies the issuer or its agent to update a master securityholder file held offchain. The chain record and the ownership record therefore have distinct roles in that model. The same statement describes another model with the blockchain integrated into the ownership record. These are staff descriptions with no independent legal force. The actual issuance determines which record and transfer mechanism the adapter must satisfy. Statement on Tokenized Securities

The settlement cycle answers a further question, when performance is due. For transactions covered by the US standard settlement cycle, T+1 means one business day after the trade date. The SEC staff FAQ also sets out exceptions and provisions for an expressly agreed settlement date. Settlement cycle FAQ I would use that date to organise the obligation and its escalation. The evidence that releases escrow must establish what happened to the matching payment.

A facility can own the conditional transfer#

I would choose an established delivery versus payment facility when its rulebook and failure protocol cover the actual cash and security obligations. Delivery versus payment, or DvP, links final delivery of the security to final payment. Its useful property is that the framework binds the two obligations through completion and failure. A shared ledger is one way to implement that property.

Separate ledgers and sequential completion are also compatible with DvP. Principle 12 permits linked transfers to reach finality at different times, provided the legal, contractual and technical framework preserves the conditional relationship. Paragraph 3.12.4 gives the relevant sequence. A securities settlement system blocks the seller's securities, requests the cash transfer at a settlement bank, and delivers the blocked securities when it receives confirmation that the cash leg has settled. The same passage requires the interval to be minimised and the blocked securities to be protected from third party claims. Principle 12, paragraphs 3.12.3 and 3.12.4

That example matter here because the application can also reserve a security, request payment and wait for a report. The sequence becomes dependable DvP through the rights, commitments and failure arrangements that make each step effective. I would require the facility's eligibility rules to admit the actual security and cash leg, and its failure protocol to settle whether an outstanding instruction can still complete after cancellation. An application wrapping an irrevocable payment service inherits the unresolved outcome whenever that service supplies only asynchronous evidence.

The older CPSS treatment makes the remaining risk visible. Its September 1992 report separates the elimination of principal risk, the risk of losing the asset delivered in an exchange, from the liquidity and replacement costs that can remain. In its model 2 discussion, securities transfers finish before the later net cash settlement. An assured payment arrangement gives the seller an irrevocable commitment from the buyer's bank. The report then examines the exposure to the guarantor's failure. I would carry that distinction into the facility decision: the party promising completion and the arrangements supporting its promise belong in the design. CPSS, sections 2.14 and 2.15, and 3.11 through 3.13

The Eurosystem's June 2025 report supplies a concrete technical alternative across separate infrastructures. Its exploratory work demonstrated the technical and operational feasibility of atomic settlement through interoperability, with cash and assets in different technical environments. Both sides had to adopt a common technical and operational approach. The report's definition of atomicity concerns the technical dimension, while legal finality remains a separate requirement. I take the trials and experiments as evidence that separate ledgers can support the mechanism described, at the scope of those arrangements. Eurosystem exploratory work, sections 4.2 and 6

The ECB's 26 August 2026 speech described Pontes as an intended service connecting market ledgers to TARGET Services for settlement in central bank money. The speech said that the ECB intended to go live that year. An integration decision still needs evidence of availability and eligibility for its own obligations. ECB speech on Pontes

Where an available facility supplies that binding arrangement, I would put conditional settlement under its control. Where the cash service can complete independently and report later, the adapter needs an explicit state for the obligation it cannot yet resolve.

Keep the provider outcome separate from adapter knowledge#

The model applies Principle 12's conditional settlement requirement to a narrower decision: what the local adapter may do with an escrowed security after a submitted payment loses its notification. Its provider can hold an instruction as pending, paid or cancelled. The adapter holds its own decision as unknown until a terminal report arrives. Unknown is compatible with a payment that has already completed.

The delayed report trace starts with the security in escrow and the payment instruction authorised. The provider accepts the instruction and records paid. The notification is delayed. When the adapter times out, the unsafe policy gives the security back to the seller. The guarded policy keeps the security in escrow and requests reconciliation. Once the paid report arrives, the guarded adapter can deliver to the buyer. The missing message has changed the adapter's knowledge without changing the provider's completed payment.

For a submitted instruction in the executable model, delivery requires a paid report for the exact trade and return requires a terminal cancelled report. Here cancelled is a terminal provider commitment that excludes later payment for that instruction. A request to cancel still needs that outcome. The provider object enforces a single terminal result, and the adapter rejects a report that conflicts with its recorded terminal decision.

The state names needs a little care. In the intended state contract, submitted means that sending the payment has been durably authorised. The submit event makes that transition locally. Dispatch then sends the instruction. The authorised state therefore covers a crash before the send as well as a lost acknowledgement after the provider has accepted it. I would persist the original instruction identity and trade tuple before permitting that external action.

The excerpt includes the transition function, the dispatch guard and the checkpoint encoding used by the executed model. The complete harness supplies the provider and the event schedules. The Python dictionaries and JSON checkpoint represent durable state; a real integration must supply the common serialised durable boundary that orders authorisation, expiry and every admitted dispatch.

Role: reduced executable model, exact excerpt from the executed state machine.

def advance(state, event):
    s = dict(state)
    if event['kind'] == 'submit':
        if s['phase'] != 'reserved':
            raise ValueError('reservation cannot authorise submission')
        s['phase'] = 'submitted'
        return s
    if event['kind'] == 'timeout':
        if s['phase'] == 'reserved':
            s['phase'] = 'cancelled'
            s['asset'] = 'seller'
        else:
            s['needs_reconcile'] = True
        return s
    if event['kind'] == 'report':
        if s['phase'] != 'submitted':
            raise ValueError('no submitted instruction')
        if event['authority'] != 'bank' or event['trade'] != s['trade']:
            raise ValueError('report does not bind this obligation')
        result = event['result']
        if result not in ('paid', 'cancelled'):
            return s
        if s['decision'] not in ('unknown', result):
            raise ValueError('conflicting terminal reports')
        s['decision'] = result
        s['needs_reconcile'] = False
        if result == 'cancelled':
            s['asset'] = 'seller'
        return s
    if event['kind'] == 'deliver':
        if s['decision'] != 'paid':
            raise ValueError('payment evidence absent')
        if event['available'] and s['asset'] == 'escrow':
            s['asset'] = 'buyer'
            s['deliveries'] += 1
        return s
    raise ValueError('unknown event')
 
 
def dispatch(store, provider):
    current = store['state']
    if current['phase'] != 'submitted' or current['decision'] != 'unknown':
        raise ValueError('current durable state forbids dispatch')
    provider.submit(current['instruction'], current['trade'])
 
 
def checkpoint(state):
    return json.dumps(state)
 
 
def restore(payload):
    state = json.loads(payload)
    state['trade'] = tuple(state['trade'])
    return state

The constructed delayed report trace

Provider result:       paid
Adapter knowledge:     unknown -> timeout -> reconcile -> paid report
Unsafe timeout asset:  seller
Guarded timeout asset: escrow -> retained -> retained  -> buyer after delivery

The report check is categorical. It accepts the authority value bank and requires equality with the stored trade tuple, which contains the trade identity, seller, buyer, security and cash obligation. Substituting an outsider or another trade fails that check in the executed cases. The authority check and trade match are implemented policy. Cryptographic authentication is an integration requirement.

Instruction binding has a further dependency. The harness obtains a report by looking up the stored instruction in the provider. The reducer receives the authority, trade and result produced by that lookup. Its report event carries no separate instruction identifier. Exact lookup of the original instruction is therefore a premise at the integration boundary. I would make that binding explicit in the provider contract, especially if successive instructions can refer to the same trade.

The checkpoint preserves the instruction identity and original trade tuple across restart. In the execution, a restart before the send submits that original instruction. Replaying the same checkpoint after the provider has already accepted the instruction reaches the provider's duplicate check. The provider recognises the existing identity and rejects reuse of that identity with another trade. Local delivery also checks that the asset is still in escrow before moving it to the buyer. Together these checks keep duplicate submissions and repeated reports from creating a second settlement effect in the model.

A completed payment can leave delivery work outstanding. In the recovery case, the harness restores a checkpoint carrying the paid decision, attempts delivery while the asset is unavailable, then permits delivery when it becomes available. The blocked attempt preserves the paid decision and escrow position. The successful attempt moves the asset to the buyer once. I would retain that paid obligation across delivery failures and resume against it with the same identity.

The cancellation tests in this investigation exposed a defect in the test itself. A constructed faulty version accepted the first terminal cancellation and recorded the decision as cancelled while leaving the asset in escrow. Repeating the cancelled report returned the asset to the seller. The original test checked only the final cancellation state, so a duplicate report concealed the failed first return. The strengthened assertion requires the asset to be with the seller in every recorded state whose decision is cancelled. It therefore rejects the first cancelled state even though the later return satisfies the original final state check. I would check the relation between terminal decision and asset position at the transition that promises the return.

These executions establish local behaviour for the constructed schedules, with the provider and escrow under the model's assumptions. Truthful reports, mutually exclusive terminal outcomes and continued control of the escrowed security are part of that environment. The integration must also preserve the serial order and durability represented by the local state. If dispatch merely carries a worker's old permission after expiry, the return branch has lost the condition that made it safe.

The executed model contains no live payment rail or securities register. I use the trace to decide which evidence a local release requires. Whether the security transfer has legal effect, whether the provider will answer, and how the durable boundary survives actual failures remain questions for the real arrangement.

What the model leaves open#

This analysis uses a reduced settlement model with truthful terminal reports, durable local state and a security that stays under escrow control. It does not test a bank integration, determine legal ownership, establish recovery times or model insolvency. If the provider can revise a terminal outcome, or an outside authority can remove the locked security, the model no longer supplies the required guarantee.

The unresolved instruction has an owner#

The seller carries an unavailable security while the submitted payment remains unresolved. The buyer can already have paid while a technical delivery failure keeps that security in escrow. The operator carries the reconciliation work and the evidence needed to resolve the instruction.

If the provider never supplies a terminal outcome, this model can retain the security indefinitely. I would require an operational recovery arrangement and an admission limit before accepting further obligations. An operator needs a named case owner, the age of the oldest unresolved instruction and the inventory still committed to those instructions. The provider's authoritative result and the adapter's observed result need separate fields wherever an operator decides what to do next.

The Eurosystem report gives this operational cost a specific setting. Participants described manual contingencies for timeout errors in some scenarios using hashed timelock contracts during the trials and experiments. Those contracts condition transfers on a secret and a deadline. The report records the manual work and the demand for better automation within the tested arrangements. Eurosystem report, section 6

I would set a reservation limit from the inventory the seller can leave unavailable and the operator's capacity to resolve outstanding cases. This investigation supplies neither provider delay measurements nor a workload from which to derive a recovery time or a numerical limit.

Expiry can close a reservation before authorisation#

Before submission is durably authorised, expiry can return the reserved security if that same transition prevents every later payment submission.

The execution exercises both orders. Expiry first returns the reservation and rejects a later attempt to authorise submission. Authorisation first leaves escrow committed when expiry follows. Dispatch reads the current state, including after a restart, so a worker's cached permission cannot reopen the expired reservation in the model. I would put that decision and all admitted dispatches under the common serialised durable boundary. Reading a state and saving permission to send later would leave another ordering to resolve.

The change of recommendation follows the disappearance of the possible external obligation. Before authorisation, the expiry transition can close its only permitted creation path. After authorisation, reconciliation must recover the outcome of the original instruction.

Release a committed asset only on evidence from the authority that can make the matching obligation final. In the SEC's offchain ownership model, that means establishing the required effect in the issuer's ownership record. At the payment boundary modelled here, it means resolving the authorised instruction with its provider. The timer can start that work. The paid or terminal cancelled result determines the disposition of escrow.

Abdel KIARI

I’ve owned the EVM side of a DeFi protocol with $110M+ in funding, including backing from Coinbase Ventures. I redesigned its architecture from scratch and built the Solidity infrastructure end to end.

Always happy to talk about interesting opportunities

abdel.kiari@gmail.com