VoP stands for Verification of Payee. It is the EU name check that runs on the SEPA scheme before a euro credit transfer is sent: your payment service provider (PSP) asks the PSP that holds the payee's account whether the name you entered matches the account holder, and gets a standardised answer back in well under a second. If the two do not belong together, you find out before the money leaves.
That is the whole idea in two sentences. The rest of this article is about the parts people get wrong: what the acronym covers, what a VoP check actually confirms, and what it deliberately leaves to you.
What the letters stand for, and where they come from
VoP is short for Verification of Payee. The obligation comes from the EU Instant Payments Regulation, which required PSPs in the euro area to offer the check on euro credit transfers from 9 October 2025. PSPs in non-euro EEA states follow by 9 July 2027. The mechanics - the messages, the matching rules, the four outcomes - come from the Verification of Payee scheme run by the European Payments Council (EPC), the same body that coordinates the SEPA credit transfer and direct debit rulebooks.
So there are two layers, and it helps to keep them apart. The regulation says you must offer the check. The scheme says how the check is performed and what the answer looks like. When people say 'the VoP scheme', they mean the second layer.
One obligation, many names
You will see the same check called VoP, Verification of Payee, a payee name check, an IBAN name check or a payee checker. They describe one thing: a bank-to-bank question about whether a name matches an account. The UK's Confirmation of Payee (CoP) is the equivalent scheme for UK sort codes and account numbers.
What happens during a VoP check
- 1 You enter a payee name and an IBAN, or your system reads them from a payment file.
- 2 Your PSP sends the submitted name and the IBAN to the PSP that holds the destination account - the responding PSP.
- 3 That bank compares the two names using the scheme's matching rules and returns one of four standardised outcomes.
- 4 Your PSP shows you the result before you authorise. The payment is not sent until you decide.
Only the name comparison travels. Nothing about the amount, your balance or the payee's transactions is shared, and no account holder data is exposed to you. This is a conversation between two banks, not a lookup in a public register.
The four outcomes, in plain terms
- Match - the submitted name agrees with the account holder. The lowest-risk result; proceed with normal confidence.
- Close match - the names are similar but not identical: a missing middle name, initials instead of a full first name, a trading name against a registered name. The response carries the verified name so you can confirm or correct it.
- No match - the name does not belong to that IBAN. This is a valid answer, not a technical error, and it is the classic signal of a mistyped account or an invoice-redirection scam.
- Not available - the payee's bank could not answer at that moment. The payment is not blocked; you are informed and you decide.
The middle two carry most of the value. A close match is not a failure - the scheme is handing you the correct name so the next payment lines up cleanly. A no match is not a system fault - the check is doing exactly its job. And none of the four outcomes blocks a payment: VoP informs the payer, who keeps the decision.
What VoP does not tell you
A match confirms that the account belongs to the party you named. It does not confirm that the party is honest, that the invoice is genuine, or that the person instructing you is who they claim to be. A fraudster who has taken over a genuine supplier's email account can still point you at a genuine account with a genuine name - and that payment will match.
VoP removes account-detail risk. It does not remove social-engineering risk. Treat a match as one strong signal, not a full clearance, and keep the habit of confirming a change of bank details through a channel you already trusted.
Who has to offer VoP, and who just uses it
There are three very different positions, and they are worth separating before you plan anything.
- Banks and PSPs - a scheme obligation with a deadline. The work is a scheme project: connecting to the routing and directory infrastructure, implementing the request and response messages, applying the matching rules to your own account data as a responding PSP, and surfacing the outcome in your channels as a requesting PSP.
- Fintechs and software vendors - an embedded capability. If you build payment products or payment software, VoP is a feature your customers will expect, and it is usually faster to call a provider than to join the scheme yourself.
- Businesses - treasury, accounts payable, payroll and marketplaces - a service you use. You do not join the scheme. You verify a single payee in a dashboard, or verify a whole payment file before release, and you re-verify when a supplier's bank details change.
For an individual payer, VoP is simply the name check your own bank shows you when you set up or pay a payee. You do not buy it, you use it - and for euro credit transfers it must be offered free of charge.
A short checklist before you rely on VoP
- 1 Check the scheme, not the label. If your payments are euro payments inside SEPA, you need the SEPA VoP scheme - a provider connected to a different national name-check scheme is not automatically connected to yours.
- 2 Ask about reach. The responding PSP is the only party that can answer, so coverage across the scheme is the number that decides how useful the check is in practice.
- 3 Insist on the verified name on a close match. A result that says 'close match' without telling you the correct name leaves you guessing - and guessing is what the check exists to remove.
- 4 Look for all four outcomes. A service that cannot return 'not available' cleanly will either block payments or hide failures.
- 5 Keep the audit trail. You should be able to show what was checked, when, and what came back.
RoxPay delivers scheme-compliant Verification of Payee through one REST API and a dashboard, returning the standardised outcomes - match, close match, no match and not available - in well under a second, with the verified name on a close match and the responding bank's BIC, for a single payment or a whole payment file.