A Verification of Payee solution is the service that checks a payee name against the account behind an IBAN before a payment is sent. In the EU the check is called Verification of Payee (VoP). It runs on the SEPA scheme, coordinated by the European Payments Council, and it returns a standardised answer in well under a second. If the name and the account do not belong together, you find out before the money leaves - not after.
That is the short answer. The useful answer is knowing what a VoP service actually does, who needs one, and what separates a working implementation from a demo. That is what this article covers.
What a Verification of Payee solution does
It asks a question on your behalf. Your payment service provider (PSP) sends the name you submitted and the IBAN to the PSP that holds the destination account. That bank compares the two names using the scheme's matching rules and returns a standardised result. Nothing about the amount, your balance or the payee's transactions is shared - only the name comparison.
A conversation, not a database
Verification of Payee is not a lookup in a public register of account holders. Account holder data is personal data, and only the bank that holds the account can confirm who owns it. VoP is a message between two banks, routed through the SEPA scheme - which is why reach across the scheme matters more than the elegance of any single integration.
The four outcomes a VoP service returns
- Match - the submitted name agrees with the account holder. The lowest-risk result; proceed with normal confidence.
- Close match - the name is 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 the payer 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; the payer is informed and decides.
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.
Who needs a Verification of Payee solution
There are three very different buyers, and they need three different things.
- 1 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 name-matching rules to your own account data as a responding PSP, and surfacing the outcome in your channels as a requesting PSP.
- 2 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.
- 3 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, the check 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.
Where the obligation comes from
Verification of Payee is mandated by the EU Instant Payments Regulation. Euro-area PSPs had to offer it on euro credit transfers from 9 October 2025, and PSPs in non-euro EEA states follow by 9 July 2027. The regulation sets the obligation; the European Payments Council's VoP scheme sets the mechanics. In practice that means the check is now part of the normal SEPA payment flow rather than an optional extra.
One detail is easy to miss: the obligation covers euro credit transfers the payer initiates electronically, not only instant payments. A standard SEPA credit transfer needs the same check.
What a real implementation involves
If you are a PSP, the honest answer is that this is a project, not a sprint. The pieces that have to be in place are:
- Scheme connectivity - joining the EPC VoP scheme as a requesting PSP, a responding PSP, or both.
- A real-time API that returns the four standardised outcomes, with the verified name on a close match.
- Name-matching logic applied to your own account data, so you can answer requests about your account holders.
- A clear result in every channel where a payer initiates a euro credit transfer - app, web and payment initiation.
- Logging and retention, so you can show what was checked, when, and what came back.
Building that from scratch takes months. Most PSPs reach their date faster by integrating a provider that already operates on the SEPA VoP scheme, so one connection gives reach across Europe instead of one integration per responding bank.
How to judge a VoP service
- 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 single most important number.
- 3 Test the latency in a sandbox. The check sits inside the payment flow, so it has to be fast - ask for a measured figure, not a promise.
- 4 Insist on the verified name on a close match. A result that says 'close match' without telling the payer the correct name leaves them guessing.
- 5 Look for all four outcomes. A service that cannot return 'not available' cleanly will either block payments or hide failures.
- 6 Check the audit trail. You should be able to export what was checked, when, and what came back.
The three-check test
Take a payee you know well and run three checks: the exact legal name, a shortened trading name, and a deliberately wrong name. A good service returns match, close match with the verified name, and no match - in that order, in under a second, with all three results logged.
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.