Verification of Payee: The Check That Runs Before the Payment

Verification of Payee compares the beneficiary name the payer typed against the name on the account, before the payment is sent. Four outcomes, not two: match, close match with the real name offered, no match, and verification not possible. The payer can proceed anyway, so the record of what they were shown is what decides liability. And warning fatigue is how the whole thing quietly fails.

A finance clerk receives an email that appears to come from a known supplier, advising new bank details. The invoice is genuine, the amount is expected, the supplier name is correct. The account belongs to a fraudster.

Every control downstream of that moment fails, because the payment is authorised, correctly formatted, and sent to a valid account. Sanctions screening will not catch it. Instant settlement makes it irrecoverable. The only place to intervene is before the payer confirms.

That is what Verification of Payee is for. This continues the scheme track of The ISO 20022 Reference, after SEPA Instant.

What the check actually does

Before the payment is submitted, the payer’s bank asks the beneficiary’s bank a question: does the name I have been given correspond to the account holder for this IBAN?

The beneficiary bank answers, and the payer sees the answer before confirming. The whole interaction happens in the payment initiation journey, not inside settlement, which matters for instant payments because it does not consume the execution budget.

The UK implemented an equivalent, Confirmation of Payee, some years earlier, and its experience is the best available evidence for what works. The European scheme, driven by the Instant Payments Regulation and specified by an EPC scheme rulebook, extends the same idea across euro payments. The design lessons transfer almost completely.

Four outcomes, not two

This is the design decision that determines whether the control works, and the one most often simplified into uselessness.

Outcome	Meaning	What the payer should see
Match	The name corresponds	Quiet confirmation, no friction
Close match	Similar but not identical	The actual account name, so they can judge
No match	Does not correspond	A clear, specific warning
Not possible	Could not be checked	An honest statement that no check happened

Collapsing these into “verified” and “not verified” destroys the value. The three non-match outcomes mean completely different things to a payer, and they warrant different actions.

Close match is the most valuable and the hardest. The payer typed J Smith Plumbing and the account is John Smith Plumbing Limited. Returning the actual name lets the payer recognise their supplier instantly and proceed with confidence. It also discloses the account holder’s name to someone who only had an IBAN, which is a real privacy consideration and the reason schemes constrain when and how the name is returned.

Your specification needs a documented position on disclosure: when the real name is shown, when only a similarity indication is given, and what protections exist against someone probing account names by submitting guesses. Rate limiting on verification requests is part of that answer.

Verification not possible is the outcome teams forget. The beneficiary bank did not respond in time, the account type is out of scope, or the beneficiary opted out where permitted. Showing the payer nothing, or showing a generic warning, is wrong in both directions. They need to know that no check happened, because that is materially different from a check that passed.

It informs, it does not block

The payer can proceed after any outcome. This is deliberate, and it is worth explaining to stakeholders who want the check to be a hard stop.

Legitimate mismatches are common: a business trading under a name different from its registered one, an account held in a former name, payments to a third party at the beneficiary’s request, joint accounts where only one holder was named. Blocking all of those would break more payments than it prevents fraud.

What changes instead is the evidential position. A payer who was clearly warned and chose to continue is in a different situation, for liability and for reimbursement, from one who was never told. That makes the record a first-class requirement rather than an audit afterthought.

Record, per verification:

• the name and IBAN submitted,
• the outcome returned,
• exactly what was displayed to the payer, including the wording,
• what the payer chose,
• the timestamp.

That third item is the one systems miss. “Outcome: no match” is not enough when a dispute arrives eight months later and the question is whether the warning was noticeable. Store the message, not just the code. This is the same provenance discipline as the audit trail in the AI guardrails: keep what was actually shown, not a reconstruction.

Warning fatigue is how this fails

The dominant failure mode is not technical. It is behavioural.

If matching is too strict, most legitimate payments produce a close-match warning. Payers see warnings on routine payments to suppliers they have paid for years. Within weeks they learn that the warning means nothing, and they click through it automatically. When the one genuine fraud warning appears, it is dismissed in the same reflex.

The control is then worse than absent, because everyone believes it is working.

So matching quality is the product, not a configuration detail. The legitimate variations that must be handled:

• Abbreviations and initials: J Smith against John Smith.
• Legal entity suffixes: Ltd, Limited, GmbH, SARL, BV.
• Trading names against registered names.
• Word order, including cultures where family name comes first.
• Diacritics and transliteration, which interacts directly with the SEPA character set: the payer types Müller, the account is held as Mueller, and a naive comparison calls that a mismatch.
• Joint accounts, where the payer names one holder.

And measure it after launch. The metrics that tell you whether the control is alive:

Metric	What it tells you	Warning sign
Close match rate	How much friction legitimate payments get	Rising above a few percent
Proceed-after-warning rate	Whether payers still read warnings	Approaching 100 percent
Verification not possible rate	Counterparty responsiveness	Rising, meaning less coverage
Fraud prevented	Whether it works	Falling while close matches rise

That second row is the one to put on the dashboard. A proceed-after-warning rate near 100 percent means the warnings have become noise, and the fix is matching tuning, not a louder warning.

What to specify

1. The four outcomes, each with its exact customer-facing wording, reviewed by someone who understands how people read screens under time pressure.
2. The disclosure rule for close matches, including rate limiting against name probing.
3. The timeout on the verification call, and the fact that a timeout resolves to verification not possible rather than to a silent pass.
4. Coverage: which payment types, channels, and beneficiary types are in scope, and what happens outside scope.
5. Bulk and file payments, which is the case usually deferred and which matters enormously, because a payroll file of eleven thousand beneficiaries cannot produce eleven thousand individual warnings. The pattern that works is verifying at beneficiary setup rather than at payment, with re-verification when details change.
6. The record: fields captured, retention period, and how a dispute retrieves it.
7. The matching rules, owned by a named person, with a tuning review scheduled rather than hoped for.

What to test

• Each of the four outcomes end to end, asserting the exact customer-facing message.
• A close match returning the real name, asserting disclosure follows the documented rule.
• A beneficiary bank timeout, asserting the outcome is verification not possible and the payer is told so.
• Names differing only by diacritics, asserting the transliteration rule and the matching rule agree.
• A legal entity suffix difference, asserting it does not produce a warning.
• Repeated verification requests against one IBAN with varied names, asserting rate limiting fires.
• A bulk file, asserting the defined behaviour rather than a wall of warnings.
• The record: after a proceed-after-warning, assert the stored evidence contains the displayed wording, not just the outcome code.

That last one is the test nobody writes and the one a dispute will depend on.

The takeaway

Verification of Payee is the only control positioned where authorised push payment fraud can actually be stopped: before the payer confirms. Design it around four outcomes rather than two, because close match and verification not possible mean entirely different things from no match, and treating them alike wastes the control.

It informs rather than blocks, which makes the record of what the payer was shown into the evidence that decides liability. Store the wording, not the code. And watch the proceed-after-warning rate, because warning fatigue is how this control dies quietly while everyone believes it is working.

Next: RTGS on ISO 20022, where settlement stops being a scheme and becomes a central bank. The full map is on The ISO 20022 Reference.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: Payments, Fraud Prevention, SEPA, Functional Analysis, Banking