Reconciliation is more than matching numbers: when a transfer stops halfway

A transfer can appear as “sent” in one system and remain unresolved in another. That is not a paradox: each system sees a different part of the journey. The provider knows what it received and processed; the internal ledger knows the intent and the state we recorded; the bank statement confirms — or has not yet confirmed — what happened in the account.

Reconciliation is not choosing the number we prefer. It is naming the discrepancy, preserving the evidence and assigning someone the next step.

Three versions of one operation

When a transfer stops halfway, I put three sources next to each other:

• Provider status: what it received, processed and referenced externally.
• Internal ledger: the operation we intended to run, for which amount and with which local state.
• Bank statement: the movement that actually appears, with value date, reference and amount.

No source is universally sufficient. The authoritative source depends on the question and the point in the flow. What matters is writing that decision down instead of resolving it from memory in a chat.

The minimum record that keeps context intact

A useful runbook does not need a novel, but it does need a record another person can continue:

• internal identifier and external reference;
• amount and currency, retaining original precision;
• timestamps and time zone for each change;
• last confirmed state and the source confirming it;
• masked account or destination according to the privacy policy;
• current owner, next action and next-update time;
• evidence link, restricted when appropriate.

The point is not to collect more data. It is to let an exception move from operations to support, compliance or a provider without losing its context.

What to do when a timeout arrives

The most expensive error is retrying because the interface cannot tell whether the first attempt finished. On a timeout, I freeze ambiguous retries first. Then I correlate references and classify the case as pending, partial, returned or unknown. “Unknown” does not mean the money is lost; it means there is not yet enough evidence to say where it is.

Idempotency is the technical guardrail that keeps one intent from becoming two movements. An exception queue is the operational guardrail that keeps a case from closing simply because it disappeared from the screen.

Communicate facts, uncertainty and the next step

A useful message to a user or partner has three layers: what we know (reference, amount, last state), what we do not yet know (for example, whether the bank has credited it), and what happens next (owner and next update). I avoid promising a settlement time that depends on third parties; I can commit to a time for a useful response.

Closure needs evidence

A transfer closes when there is evidence of credit, return or reversal, and the internal ledger reflects the same conclusion. An email saying “it should be done” is a lead, not closure. That discipline feels slow until you compare it with the cost of duplicating a payment or explaining a figure nobody can prove.

In the public compliance documentation I try to apply the same idea: separate facts, statements and original documents. In products that rely on providers, the interface can be simple; responsibility cannot be ambiguous.

Note: informational content based on product experience. It is not legal, regulatory, tax or financial advice, nor an offer of services. Specific obligations depend on the relevant entity, provider and jurisdiction.

Sources

• BIS · CPMI — work on cross-border payments.
• Financial Stability Board — G20 roadmap.
• ISO 20022 — financial messaging and structured references.