Instant rails, instant irreversibility: what RTP and FedNow remove

Every corporate fraud response plan has a step that reads contact the bank immediately. On an instant rail that step has no effect, and the plan's dependence on it is usually undocumented.

Part of Payment release authorization

I moved us onto instant rails and did not do this analysis

We enrolled in instant credit transfers because our suppliers wanted them and our working capital position improved. The treasury case was straightforward and I approved it in a meeting that took twenty minutes.

What I did not do was ask what our fraud response plan assumed. It assumed, in three separate places, that we would call the bank and attempt a recall. On the rail we had just adopted, that step does nothing.

Nobody misled me. The question simply was not asked, because the payments decision and the fraud response plan lived in different parts of the organisation.

What the rails actually differ on

The distinction that matters is in the last column. On instant rails, a request for return of funds is exactly that — a request. The receiving participant may act on it; the funds are not clawed back by operation of the rail.

In a fraud scenario the receiving account is controlled by the attacker or by a mule, and consent is not forthcoming.

The expected loss calculation

This is the version of the argument that belongs in front of a board, because it is arithmetic rather than assertion.

expected_loss = P(fraudulent payment) × amount × (1 − P(recovery))

Wire:     recovery sometimes achievable if reported within hours
Instant:  P(recovery) ≈ 0 in an adversarial scenario

∴ moving the same payment population onto an instant rail
  raises expected loss by the recovery fraction, with no change
  in the probability of fraud

That is the whole point. Adopting instant rails does not make fraud more likely. It makes each instance cost more, and the increase equals whatever your recovery rate was.

Most organisations do not know their recovery rate, which means they cannot compute the change. Finding out is a half-day exercise with your bank.

Why detection cannot absorb the difference

The instinctive response is to strengthen detection: better scoring, tighter rules, more review.

Detection on an instant rail has to be pre-execution, because there is no post-execution remedy. That collapses the time available for evaluation from hours to the moment of submission, and the rail's value proposition is that the payment arrives in seconds.

A detection system tight enough to catch sophisticated fraud pre-execution will also hold legitimate payments, which removes the reason you adopted the rail.

What survives

If recall is unavailable and detection cannot be tightened without destroying the product, the remaining control point is authorisation — requiring something at submission that a fraudulent instruction cannot produce.

A signature bound to the payment's material terms costs the approver a second and costs an attacker everything, because they do not hold the credential. It is the only control whose cost falls entirely on the illegitimate path.

The three questions to ask before enrolling

1. What is our current recovery rate on fraudulent payments, by rail, over the last three years? Ask the bank; they have it.
2. Where in our fraud response plan do we depend on recall, and what replaces that step?
3. What payment population are we moving onto the instant rail, and what is its value distribution? Moving high-value vendor payments is a different decision from moving payroll.

I would have answered all three differently if anyone had asked me them in that twenty-minute meeting.

What moves to the front

This is the argument for moving spend from detection to authorisation in a sentence: on an irrevocable rail, everything that happens after the send is documentation.

Objections and honest limits

“We will just not use instant rails for large payments.” Reasonable today, and the pressure runs the other way. Counterparties increasingly expect instant settlement, and the exception list tends to shrink.

“Confirmation of Payee covers this.” It checks the name against the account. It cannot see intent or coercion, which is why mandatory reimbursement regimes moved the argument to what the customer was shown.

Preparing for irrevocable settlement

1. Move the control before the send. Anything after it is documentation.
2. Gate beneficiary creation and amendment. Not just the transfer.
3. Require payer confirmation above a threshold. Rendered from the payment that will execute.
4. Set velocity limits as containment. They become the primary bound, not the backstop.

Terms used here

Irrevocability

Settlement that cannot be reversed by the sending institution once complete.

Recall

A request to return funds after sending. Available on traditional rails, discretionary, and absent on instant ones.

Confirmation of Payee

Checking that the account name matches the intended payee before sending. Useful, and blind to intent.

Frequently asked questions

Are instant rails riskier? They do not change the probability of fraud. They remove the recovery step, which raises the expected loss per incident by whatever your recovery rate was.

Can funds be recovered on RTP or FedNow? A request for return of funds can be sent, and the receiving participant may act on it. In an adversarial scenario the receiver does not consent, so recovery should be planned as unavailable.

Should we avoid instant payments? No. The working capital and supplier relationship benefits are real. The point is to move the control from post-execution recovery to pre-execution authorisation before you enrol, not after.

How do we find our recovery rate? Ask your bank for your own history by rail over three years. Most treasury teams have never requested it and it takes them a day to produce.

Do instant rails create new fraud? No. They remove the recovery step that used to absorb some of it, which changes where the control must sit.

What becomes the primary containment? Velocity limits, plus authorisation before the send. Post-send monitoring becomes reporting.

Is Confirmation of Payee enough? It verifies the name against the account. It cannot see intent or coercion, which is the remaining gap.

Sources and further reading

• Federal Reserve — FedNow Service
• Fedwire and CHIPS funds transfer finality provisions.
• FBI IC3 2025 Internet Crime Report
• Nacha Operating Rules