SEPA / Learning brief
Verification of Payee
Your notes
In simple terms / 01
What this means in plain language
Explains how Verification of Payee compares the beneficiary name a payer enters against the name held on the account before a euro credit transfer is authorised, and what a match, close match, or no match means for the payer.
Verification of Payee (VoP) is a check that runs before a euro credit transfer is authorised. The payer's payment service provider (PSP) sends the beneficiary name and account number the payer entered to the beneficiary's PSP, which compares them against the name actually held on that International Bank Account Number (IBAN) and replies. The payer sees the outcome — a match, a close match, no match, or that the check could not be performed — and then decides whether to send. VoP does not stop a payment; it informs the person making it. The point is to catch two everyday problems before money moves: a mistyped or wrong account number, and impersonation fraud where a payer is tricked into paying a criminal's account. Because the answer arrives inside the payment flow, the payer can pause on a warning rather than discovering the error afterwards.
Complete lesson / 02
Understand the full idea, step by step
You are about to send money and the app asks for a name and an account number. Until recently, only the number really mattered — type the right digits and the name was decoration. That gap is what fraudsters lived in. A check now closes it, quietly, in the second before you tap Send.
Verification of Payee (VoP) — a pre-payment check that the beneficiary name matches the account
Verification of Payee sits at the front of a credit transfer as a short, automated lookup. When the payer enters a beneficiary name and an IBAN, the payer's payment service provider (PSP) sends both to the PSP that services the beneficiary account. That responding PSP compares the submitted name against the name it actually holds and returns a result, which the payer's PSP shows before the payer authorises anything. It produces information, not a decision — the payment instruction itself is untouched.
What it is defending against
The threat is misdirection — money reaching the wrong account. Sometimes that is an honest fat-fingered IBAN. More often it is authorised push payment (APP) fraud: a payer is deceived into sending money to an account a criminal controls, believing it belongs to someone they trust. Because the payer authorises it themselves, the usual fraud defences do not fire. VoP attacks the weak point directly — it lets the payer see, before committing, that the name they believe they are paying does not match the account they are about to pay.
The check, step by step
- CUSTOMER
Riya enters the beneficiary name 'Asha Traders' and the IBAN from the invoice.
- INSTRUCTION
Bank Alfa consults a directory service to find which PSP services that IBAN, then sends the name and IBAN to it over a defined interface.
- VALIDATION
Nordbank compares the submitted name against the name it holds on the account and forms a result — match, close match, no match, or not-possible.
- NOTIFICATION
The result returns to Bank Alfa in time to sit on Riya's screen. She reads it and decides whether to proceed — the check advises, it does not block.
| Result | What it means | What the payer should do |
|---|---|---|
| Match | The entered name agrees with the account name | Proceed with ordinary confidence |
| Close match | Similar but not identical; the response may return the actual account name | Compare the returned name and judge — often innocent (Ltd vs Limited) |
| No match | The names do not correspond | Pause — this is the outcome that most deserves a second look |
| Not possible | The check could not be performed (e.g. the beneficiary PSP was unreachable) | Proceed with care; absence of a check is not a green light |
COMMON CONFUSION
“A 'no match' stops the payment, and a 'match' guarantees it is safe.”
Neither is true. VoP is advisory by design: no outcome blocks the payment, and the choice always stays with the payer. A 'no match' is a prompt to check, not a refusal. And a 'match' only confirms the name fits the account — a payer who has been tricked into paying a criminal's own genuine account will still see a clean match. VoP narrows misdirection; it does not certify that a payment is wise.
You may be wondering: if names are messy, won't honest people constantly see a scary 'no match'?
This is the real operational challenge, and it is a data problem more than a fraud one. Personal names carry diacritics, transliterations, and abbreviations; a company may trade under one name and be registered under another; joint accounts and maiden names produce honest mismatches. The responding PSP's matching logic decides how often a customer sees a close match rather than a clean one, so results differ between institutions. That is why 'close match' exists as a middle answer, and why staff must be able to explain an innocent no match without training customers to click past every warning.
STRICTLY SPEAKING
Strictly speaking, offering the check is being made mandatory and free of charge for PSPs under the European Union's Instant Payments Regulation, on a phased timetable, and the European Payments Council maintains a dedicated Verification of Payee scheme rulebook so the exchange works uniformly across SEPA. The maximum response time and the finer matching rules are set by that rulebook and the regulation, both recent and still settling — check the versions and dates in force rather than assuming them fixed.
FOR NOW, REMEMBER
- Verification of Payee checks the beneficiary name against the account before a euro credit transfer is authorised.
- It defends against misdirection and APP fraud by surfacing a name/account mismatch while the payer can still stop.
- Four outcomes: match, close match, no match, and not-possible — a close match may return the actual account name.
- It is advisory: no result blocks the payment, and a match confirms the name fits the account, not that the payment is wise.
- Most of the difficulty is data — messy names — which is why matching logic and results vary between PSPs.
TRY IT YOURSELF
Riya is deceived by a convincing email into paying a criminal, and enters the exact name and IBAN of an account the criminal genuinely controls. VoP returns 'match'. What has the check told her?
The euro area calls it Verification of Payee. The United Kingdom built the same idea first, under a different name and a different account format. Next: Confirmation of Payee.
KEEP GOINGKey takeaways / 03
Three things to remember
- 01
Verification of Payee compares the beneficiary name against the name held on the account before the payer authorises the transfer.
- 02
The result is advisory: a match, close match, or no match informs the payer's decision but does not block the payment.
- 03
The check runs inside the payment flow, so it can catch a wrong account number or impersonation fraud before money moves.
Practical use cases / 04
Where you would use this
A retail customer paying a new supplier sees whether the name and account they entered belong together before confirming.
A bank's fraud team reviews no-match and close-match rates to spot campaigns that trick payers into misdirecting funds.
A corporate treasury checks close-match responses on a supplier file to correct beneficiary records before a bulk run.
Worked example / 05
Put the idea into a real situation
Illustrative example: a payer at a fictional bank, Meridian Trust, sets up a EUR 2,450.00 transfer to 'Aldergrove Roofing Ltd'. Before authorisation, Meridian Trust asks the beneficiary's bank, which holds that account under the name 'Aldergrove Roofing Limited'. The systems return a close match and show the held name. The payer recognises the company, confirms, and the EUR 2,450.00 credit transfer proceeds. Had the reply instead been a no match — for example the account belonging to 'J. Postan' — the payer could stop and check the invoice before sending anything.
Operational sequence / 06
Follow the message and decision path
This compact sequence is a learning model. Exact routing and rulebook behavior can vary by scheme, participant, and implementation.
Read the steps as text
- 01MessageRiya sets up the paymentRiya (payer) → Bank Alfa (payer PSP)
Riya enters Arjun's name and IBAN and asks to send EUR 480.00 instantly. Nothing has moved yet — this is only the instruction being prepared for a check.
- 02MessageBank Alfa asks Nordbank to verify the nameBank Alfa (payer PSP) → Nordbank (payee PSP) · VoP request
Verification of Payee (VoP) checks the payee name against the IBAN before the payment is authorised. Bank Alfa asks Nordbank whether the name Riya typed matches the account. This is identity verification, not a movement of money.
- 03MessageNordbank returns the check resultNordbank (payee PSP) → Bank Alfa (payer PSP) · VoP response
Nordbank compares the submitted name with the name registered on the account and answers MATCH, CLOSE MATCH, or NO MATCH. It is a warning signal for the payer, separate from sanctions screening and from any movement of funds.
- 04MessageA match is shown and Riya confirmsBank Alfa (payer PSP) → Riya (payer)
The result is MATCH, so Bank Alfa tells Riya the name fits the account and she confirms the payment. VoP is a fraud and misdirection control that runs before money moves; the decision to proceed stays with the payer.
- 05PostingBank Alfa debits RiyaBank Alfa (payer PSP)
With the check passed and the payment confirmed, Bank Alfa books the debit on Riya's account. Her money has left her account, but nothing has yet moved between the banks.
- DR Riya's current account at Bank Alfa — EUR 480.00
- 06MessageBank Alfa submits the instant transferBank Alfa (payer PSP) → TIPS (instant settlement) · pacs.008
Bank Alfa converts the confirmed instruction into an interbank pacs.008 flagged for the instant scheme and sends it to TIPS, the instant settlement infrastructure.
- 07SettlementThe banks settle in central bank moneyBank Alfa (payer PSP) → Nordbank (payee PSP)
TIPS moves the amount between the banks' positions in central bank money the instant the transfer is accepted. Only now has money actually moved between Bank Alfa and Nordbank — the VoP message earlier carried no funds.
- DR Bank Alfa position at TIPS — EUR 480.00
- CR Nordbank position at TIPS — EUR 480.00
- 08PostingNordbank credits Arjun within secondsNordbank (payee PSP)
Nordbank books the credit and Arjun can use the money immediately. The transfer is complete end to end: name verified, Riya debited, banks settled, Arjun credited.
- CR Arjun's current account at Nordbank — EUR 480.00
Evidence & review / 07
Evidence & review
Verification of Payee scheme for SEPA credit transfers, euro area; a recent and still-settling control.
What this brief simplifies: Response time and matching thresholds described rather than numbered; regulatory dates summarised as a phased timetable and pointed to the source rather than quoted.
Sources for this brief3
- Scheme-specific ruleversion 1.1 (EPC218-23)
Verification Of Payee scheme rulebook ↗ — European Payments Council · VoP scheme mechanics, outcomes, response time
The first rulebook version entered into force on 5 October 2025; version 1.1 was published in March 2026 to address issues found after deployment, and the EPC has announced a version 2.0 for later in 2026.
- Official requirement
PSD2 and the RTS on strong customer authentication and secure communication ↗ — European Banking Authority · Instant Payments Regulation — mandatory, free-of-charge VoP
Referenced from the European Banking Authority's public summaries, guidelines, and technical standards on payment services.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.