Deemed Status

A timeout tells the caller nothing about whether the operation occurred. In a payments rail spanning many institutions of varying reliability, this is not an occasional edge case but a continuous, high-volume condition — a bank may have debited an account and failed to respond, or may never have processed the request at all, and the two are indistinguishable from outside.

The transaction cannot simply remain unknown. A customer's money is involved, a beneficiary is waiting, and settlement must occur on a schedule. So the rail assigns a deemed status by rule — deemed success or deemed failure — and treats it as provisional until reconciliation establishes the truth.

Why it matters

The choice of default is a business and regulatory decision with asymmetric consequences, not a technical one:

• Deemed success risks crediting a beneficiary for a debit that never occurred, leaving the rail short.
• Deemed failure risks a customer being debited with no corresponding credit — the customer is out of pocket, which is the outcome supervisors care about most, and it is therefore the one the rules are usually written to remedy quickly.

The deeper architectural point is that the system is designed around the assumption that a meaningful fraction of transactions will end in an uncertain state, requiring resolution afterwards. That inverts the assumption most distributed systems are built on, and it is why reconciliation is a first-class subsystem rather than a back-office task.

Implementation patterns

• Rules defined per transaction type and per leg, agreed with participants and with the regulator rather than chosen by engineers.
• The deemed state explicitly represented in the data model, distinct from confirmed success and confirmed failure — conflating deemed with final is the error that produces wrong customer messaging.
• A status-query API as a first-class operation, so the correct action after a timeout is to ask rather than to retry.
• End-to-end idempotency with a unique reference per transaction, so a retry returns the original outcome. Without it, retrying a timeout is how double-spending occurs.
• A durable record written before any external call, so a crash mid-flight leaves something to reconcile.
• Reversal as a defined, idempotent, auditable transaction type, traceable to the original.
• A time-bounded resolution commitment, so a customer's money is returned within a stated window.
• Customer messaging that reflects the deemed state honestly: never "failed", because if the debit occurred the customer sees money gone alongside a failure message.

Industry example

India's UPI operates at billions of transactions per month across hundreds of participating banks, and its handling of this condition is central to its design: defined deemed statuses, mandatory reconciliation cycles, reversal obligations, and regulated timelines for returning funds where a debit occurred without a corresponding credit.

The same structure appears in every large payments network — card schemes, real-time gross settlement systems, cross-border rails — because the underlying problem is unavoidable wherever an operation crosses an organisational boundary and the network can fail mid-flight.

Failure scenarios

• Retrying on timeout without idempotency, producing duplicate debits.
• Deemed status conflated with final status, so a provisional outcome is reported to the customer as definitive.
• "Failed" shown to a customer whose account was debited, which is the interaction that destroys confidence.
• No status-query capability, leaving retry as the only option.
• Reconciliation as a periodic manual process, so resolution takes days and breaches the commitment.
• Discrepancies counted but not classified, producing a number nobody can act on.
• Reversals performed as ad hoc corrections, without audit trail or idempotency.
• No durable record before the external call, so a crash leaves nothing to reconcile.

Trade-offs

Deemed status accepts temporary incorrectness in exchange for liveness: the system commits to an answer it may have to reverse, because leaving the transaction unresolved is worse for everyone.

That means reversals are a normal operational event rather than an exception, and the organisation must be built for them — with support processes, customer communication, accounting treatment and regulatory reporting all designed around a steady stream of corrections rather than around their absence.

The trade is provisional wrongness and a permanent reconciliation obligation in exchange for bounded resolution times and a rail that keeps moving. For a payments system it is not optional. For an ordinary distributed system it is a useful reminder that "unknown" is a real state, and pretending every operation resolves to success or failure is what produces the silent divergences discovered months later.

Interview question

"Our payment request times out after the remitting bank has debited the customer. Tell me what state the transaction is in, what we tell the customer in the next five seconds, and what has to happen in our system over the following two hours."