Fraud controls were built to buy time — instant payments deleted it
For decades, the quiet ally of every fraud function was latency. Card payments could be charged back. Batch transfers sat in a window where a flagged transaction could be held, reviewed, recalled. The float between initiation and settlement was where investigations happened, where a suspicious transfer could be stopped before the money was truly gone. Controls were designed around that pause.
Instant payment rails removed the pause. A transfer now initiates, clears and settles in seconds — and once settled, it is irrevocable. There is no chargeback on a push payment, no batch window, no comfortable interval in which to second-guess. The money is in the beneficiary account, often moved onward, before a human analyst has even seen an alert.
This is not a marginal speed-up. It is a change in the physics of the control. Anything that has to happen before money moves now has milliseconds, not minutes, to happen in. And the fraud that exploits this — authorised push payment fraud, where the victim is socially engineered into sending the money themselves — sails straight past every control that was watching for a stolen credential or an unauthorised login.
"The float was never just a delay. It was where the control lived. Instant settlement didn't speed up the payment — it deleted the place fraud teams did their work."
FINX Insights — Payments & Fraud series, 2026Mandatory, instant, and irreversible — all at once
The shift isn't theoretical. Across Europe, instant payments and a name-check on every transfer are now a legal baseline — and in markets like the UK, the cost of getting it wrong has been reassigned to the institutions that move the money.
Who pays for the fraud has moved — and that changes the build
For most of the card era, a defrauded customer had a path to be made whole, and the mechanics of reversal absorbed the rest. Push-payment fraud broke that: if you authorised the transfer, you were told, the loss was yours. Regulators have now rejected that answer — shifting reimbursement onto the payment institutions and, in doing so, turning fraud from a customer problem into a balance-sheet line.
The strategic consequence is blunt: when you cannot reverse the payment and you must reimburse the victim, every pound of fraud you fail to stop in advance is a pound off your own P&L. Detection-after-the-fact, the model the card era could afford, stops adding up. The only lever left is the one that acts before settlement — and Verification of Payee is its leading edge.
A name-check sounds simple. At scale, it is anything but
Verification of Payee asks a deceptively easy question: does the name on the account match the name the payer typed? The intent is to break the social-engineering script — to warn a customer that the "HMRC" or "supplier" account they are about to pay belongs to someone else entirely. The mechanics of answering it well, on every payment, in under a second, are where it gets hard.
"Verification of Payee is not a feature you bolt on. It's a real-time decision — fuzzy, latency-bound, and only useful as one signal inside a control that fires before the money does."
FINX Insights — Payments & Fraud series, 2026What a pre-settlement fraud control actually has to do
If the only economics that work are preventive, the institution needs a set of capabilities that all execute in the same sub-second window, on every payment. Six of them turn an irreversible transfer into a governed one.
None of these are useful in isolation. A name-check without risk scoring is theatre; risk scoring without the pre-settlement window is just a faster alert; evidence without a consistent decision is an unwinnable dispute. They only work as one decision, made once, before the money moves — which is an architecture question, not a feature list.
The control has to live in the payment path, not beside it
The industry already learned this with compliance and onboarding: capabilities embedded at the moment of action are worth far more than the same capabilities bolted on afterward. Instant payments make it non-negotiable. A fraud control that runs in a separate system, on a separate clock, will always be answering a question the payment has already finished asking. The durable pattern is a control layer sitting in the payment path — verifying the payee, scoring the risk, applying the right friction and sealing the evidence, once, before settlement.
"A fraud control on a separate clock is always answering a question the payment has already finished asking. It has to live in the path, or it lives too late."
FINX Insights — Payments & Fraud series, 2026The institutions that treat Verification of Payee as a compliance checkbox will ship a name-match, satisfy the mandate, and keep eating the fraud losses that the check alone never stops. The ones that treat it as the visible edge of a pre-settlement control layer will turn a regulatory requirement into the thing that actually moves their fraud line — and a liability shift into an advantage.
Instant payments didn't just speed up money. They moved the deadline for every control
Every control built in the card era assumed a second chance — a reversal, a recall, a window. Instant, irrevocable, reimbursable payments take all three away at once. The deadline for stopping fraud has moved from "sometime after the alert" to "before the customer hits send," and no amount of faster investigation closes that gap. Only prevention in the payment path does.
Verification of Payee is the first regulation to make that explicit, but it is not the last word — it is the leading edge of a broader truth: that in a real-time world, the control has to be as fast and as final as the payment. Treat it as a name-match and you meet the letter of the rule. Treat it as the front of a pre-settlement control layer and you meet the actual threat.
Money is now instant and final. The institutions that make their controls instant and final too won't just comply with the liability shift — they'll be the ones it rewards.