The real problem with international transfers is not speed — it's recovery

The whole sector sells the same thing: speed. Seconds instead of days, real time instead of two business days. It is an easy promise to understand and an easy one to measure, which is why it fills every home page. But after years building product on top of financial infrastructure, my conclusion runs against the sales pitch: speed is almost never what decides whether a user trusts a payments product again. What decides it is what happens on the day a transaction doesn't arrive.

An average is not an experience

Speed is an average, and averages hide precisely what matters. A product can settle 98% of its transactions in seconds and still be remembered for the remaining 2%, because it is that 2% that generates the phone call, the email at three in the morning and the review. The perceived quality of a financial product is not set by its median: it is set by its worst transaction.

That has an uncomfortable consequence for anyone designing one. The most valuable work is not shaving two seconds off the happy path, but building the path almost nobody shows in a demo: the one for a transaction that has stalled halfway.

Where the time is really lost

In international operations I have seen transfers settle in thirty seconds and transfers take nine days. The difference was rarely the rail. It was how long it took someone to know where the money was: whether it was still with the sending institution, whether it had been held at an intermediary pending a check, or whether it had reached the beneficiary but was not yet visible at their end.

That gap — the time between “something has gone wrong” and “we know exactly what has gone wrong and who is accountable” — is the real product. When it lasts twenty minutes, the user says there was an incident and it got resolved. When it lasts four days, the user tells a different story, and tells it to everyone.

A protocol for the first 24 hours

This is the framework I use to think about recovering a failed transaction. It is not a regulatory procedure and it does not replace any provider's: it is a product discipline, designed so that recovery time doesn't depend on who happens to be on call.

1. 0 – 1 h · Detect and classify Name the failure before explaining it

   The transaction stops being «in progress» and moves to an explicit state: held, rejected, pending verification or not located. An ambiguous state for an hour costs more than a clear rejection in ten minutes.

2. 1 – 4 h · Locate Answer «where is the money»

   Every incident comes down to a single question: at what point in the chain has the value stopped, and which institution is holding it right now. Without an end-to-end traceable reference, that question turns into a chain of emails between operations teams.

3. 4 – 8 h · Communicate with evidence A message the user can forward

   Flagging that there is a problem is not enough. The user needs something usable: reference, date, amount, point in the chain and expected next step. If they have to forward it to their bank or their client, that message is the product.

4. 8 – 24 h · Decide Retry, return or escalate — but decide

   Past a certain threshold, keeping a transaction «under review» stops being prudence and becomes a decision not taken. Every case must leave the 24-hour window with an assigned route and a date, even if that route is returning the funds to source.

5. Afterwards · Record Turn every incident into a rule

   The case is documented with its cause and its resolution, and that cause is translated into an upfront check, a better message or a change of provider. An incident that changes nothing will happen again under another name.

What this changes in product design

• States are named by where the money is, not by which provider is involved. «Pending at provider B» is no use to the user; «received by the beneficiary's institution, pending credit» is.
• The traceable reference is a feature, not a technical detail. If a transaction's identifier doesn't travel end to end, every enquiry starts from zero.
• The public commitment is about communication, not settlement. Promising a settlement time that depends on third parties is fragile; promising a time to first useful response depends only on you, and it is what the user is actually measuring.
• Degradation is a product state, not an exception handled over chat.

How it is measured

If I had to reduce the health of a payments product to four metrics, average speed would not be among them. I would include: time to first useful response; percentage of incidents with the value located in under four hours; resolution time at the 95th percentile — not the average; and percentage of cases resolved without the user having to ask twice. That last metric is the one that best predicts whether someone will still be using the product a year from now.

Speed can be bought: you sign a better rail. Recovery has to be built, and that is why it is a far harder advantage to copy.

Note: informational and educational content based on product experience. It does not constitute legal, regulatory, tax or financial advice, nor an offer of services, and it does not describe the obligations of any particular provider. Verify every obligation with qualified advisers and the competent authority.

Sources

• BIS · Committee on Payments and Market Infrastructures (CPMI) — programme on cross-border payments.
• Financial Stability Board — G20 roadmap for cross-border payments.
• ISO 20022 — messaging standard that underpins end-to-end traceability.