A name match is not a verdict

On September 20 the European Payments Council’s Verification of Payee rulebook moved to version 1.1. It was an urgent release, fixing problems that surfaced once the service went live.

In Britain the Payment Systems Regulator is consulting on removing the expiry date from the direction that requires Confirmation of Payee, so the rule doesn’t lapse on 1 November. In the US the Federal Reserve sells banks Payee Name Verification, which checks a name against a routing and account number before the money goes.

The shared position is reasonable: checking the name on the account is fraud prevention. It is, for one kind of fraud. The trouble starts with the word the screen uses to report it.

The check does what it says

Uptake isn’t in question. Over 320 payment service providers offer the check in the UK, more than 99% of firms initiating a Faster Payment now offer it, and over 2 million checks complete every day.

It works. Pay.UK found a 59% drop in claims for payments sent to the wrong account, and losses down between 20% and 40% for some types of fraud. The regulator adds that a transaction where the name doesn’t match is 25 times more likely to be fraudulent.

A mismatch is one of the strongest single signals in retail payments. The check surfaces it before the money moves, which is why I’m not arguing against it.

What a match cannot tell you

The PSR’s own account of the rule is careful about the distinction. Confirmation of Payee “was introduced to stop misdirected payments”. Then: “There was also an expectation that it would reduce the number of authorised push payment (APP) scams.”

The first happened. The second hasn’t shown up in the totals. UK Finance reported £576.4 million lost to authorized push payment fraud in 2025, up 19%, across 248,070 cases. Banks reimbursed £354.3 million of it, about 61%.

No causal claim there. The reason the check can’t reach those scams is in the mechanism, not the rollout.

The check compares the name the payer typed with the name on the account. When someone is being talked into a payment, the same person supplies both. The fake seller gives you the name on the real account they control. The invoice arrives with new details on a letterhead you know. Both sides of the comparison come from the fraudster, so the check agrees with them.

The Federal Reserve is careful about this in its own marketing copy. Its service “may help to reduce the occurrences of Authorized Push Payment fraud where an imposter is impersonating an individual”. May help. Impersonating an individual. That’s one scam, not the category.

The rulebook stops at the screen

The European rulebook runs to 68 pages and it’s precise where it needs to be. A responding provider returns one of five outcomes: match, no match, close match with the counterparty’s actual name, identification code not supported or verification not possible.

Then it says this about the person: “It should be noted that the way the Requester is informed and the content of the notification messages are left to the discretion of the Requesting PSP.”

So the machine-to-machine part is specified to the field. The part a human reads is a matter of taste. Sixty-eight pages on the message, one sentence on the screen.

The wording carries the liability

This isn’t a copy quibble, because the European regulation already attached money to that screen. On a mismatch the payer’s provider must say that authorizing the transfer “might lead to transferring the funds to a payment account not held by the payee indicated by the payer”.

The provider also may not stop the payer going ahead. And it has to explain “the implications for PSP liability and PSU refund rights resulting from a decision by PSUs to ignore a notification”.

Read that in order. The bank warns you, can’t stop you, and your refund rights change if you continue. The sentence deciding all of that’s being written by whoever owns the string file.

Two things I would hold the screen to

The first is a labeling rule. A check gets named for what it checked, so “this account is in the name you typed” is true and boring. “Payee verified” is a claim about the payment, and it’s the screen a fraudster wants glowing behind their phone call. A name check is a fact about an account, not a judgment about a person.

The second is the no-match state, which needs something to do. Today, in RedCompass Labs’ summary of European go-live, the payer “can either proceed, amend, or stop the payment altogether”. Three doors and no help choosing between them, at the exact moment somebody may be on the phone explaining which one to pick.

My question in review is always the same. What can this person do in the next 10 seconds, and does the screen still work if they’re being coached while they read it?

I got that from the expensive end. At Best Egg I redesigned document verification so an applicant sees a status the moment a file lands, and the opportunity we sized was 7,000 fewer support calls a month. A status that doesn’t say what happens next produces a phone call. On a payment screen it produces a payment.

At Auth0 the same lesson arrived in a different vocabulary. A check that returns true is an engineering result. Turning it into “verified” is a product decision, and it’s usually made by nobody in particular.

Europe will run this check on every euro credit transfer. Britain looks set to keep its version for good, and the Fed is selling one by the transaction. None of the three specifies what the payer reads. That leaves the most load-bearing word in the flow to whoever writes it, which today is a designer working without a rulebook.