A Verification of Payee service is a provider that already sits on the SEPA Verification of Payee (VoP) scheme and lets you use it without joining the scheme yourself. You send a name and an IBAN; the service asks the payee's bank whether the two belong together and returns a standardised answer in well under a second. That is the whole product in one sentence.
The rest of this article is about the part that sentence hides: what the provider takes off your plate, what it cannot take, and how to tell a working service from a convincing demo. If you want the definition of the check itself, start with what a Verification of Payee solution is; this page is about the service relationship around it.
What a Verification of Payee service actually does
Verification of Payee is not a lookup in a register of account holders. Account holder data is personal data, and only the bank that holds the account can confirm who owns it. The check is a message between two payment service providers (PSPs): yours asks, the payee's bank answers. A service provider's job is to be the well-connected end of that conversation.
- Scheme connectivity - it is already a participant on the SEPA VoP scheme, so you do not have to apply, certify and maintain that participation.
- Message handling - it builds the request and reads the response in the scheme's formats, including the fields that carry the verified name and the responding bank's BIC.
- Responding-side matching - if you hold accounts, it can apply the scheme's name-matching rules to your own account data so other PSPs get a correct answer about your customers.
- Reach - it routes to the PSPs that can answer, which is the number that decides how useful the check is in practice.
- One interface for everything - a single REST API and a dashboard, whether you check one payee or a payment file with thousands of lines.
One connection, many banks
The alternative to a service is connecting to responding banks one by one. That works, and it multiplies with every market you operate in. A service exists because the routing is the boring part and nobody wants to own it twice.
What stays with you
A service provider does not make the payment decision, and it should not pretend to. Four things remain yours, whichever provider you choose.
- 1 The decision. VoP is informative. Match, close match, no match and not available are inputs; whether the payment goes ahead is your call, or your payer's.
- 2 The payer experience. Showing the result clearly before authorisation - especially the close-match suggestion with the verified name - is design work inside your own channels.
- 3 Your own controls. What you do on a no match, who you call before releasing a changed supplier account, and how a payment file is approved are your processes, not the provider's.
- 4 The record. You need to be able to show what was checked, when, and what came back. A good service logs it and lets you export it; keeping and using that record is still your job.
Who buys a service, and who joins the scheme
The distinction is simple and worth stating plainly, because it decides the size of the project.
- Banks and PSPs have the obligation. Euro-area PSPs have had to offer VoP on euro credit transfers since 9 October 2025, and PSPs in non-euro EEA states follow by 9 July 2027. They can meet it by building scheme connectivity or by using a provider that already has it - many do the second and keep the payer-facing work in-house.
- Fintechs and software vendors embed the check. If you build payment products, VoP is a feature your customers will expect, and calling a service is usually faster than joining the scheme.
- Businesses - treasury, accounts payable, payroll, marketplaces - use it. You do not join the scheme at all. You verify a single payee in a dashboard or a whole payment file before release, and you re-verify when a supplier's bank details change.
For an individual payer there is nothing to buy. The check is the name check your own bank shows you when you set up or pay a payee, and for euro credit transfers it must be offered free of charge.
The four answers, and why the middle two matter
Every check returns one of four standardised outcomes. A service that returns only three is not finished.
- Match - the name agrees with the account holder. Proceed with normal confidence.
- Close match - the name is similar but not identical: a missing middle name, initials, 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. A valid answer, not a technical error, and 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 the scheme handing you the correct name so the next payment lines up cleanly. A no match is the check doing exactly its job. And none of the four blocks a payment by itself.
How to test a service before you sign
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. Then ask four questions.
- 1 Which scheme are you connected to? 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 How many PSPs can you reach, and what happens when one cannot answer? Reach is the number that decides how often you get a real answer instead of 'not available'.
- 3 What is your measured latency in a sandbox? The check sits inside the payment flow, so ask for a figure you can reproduce, not a promise.
- 4 Can you return the verified name on a close match, and can I export the audit trail? Those two answers separate a service you can operate from a demo you can admire.
If you are comparing options more broadly, the buyer's checklist for a Verification of Payee solution goes through the same questions in more detail, and the guide to choosing a payee checker covers the vocabulary people use for the same check.
What good looks like once you are live
A finished integration is quiet. Payers see a clear answer before they send, close matches get corrected instead of guessed at, no matches stop the payment long enough for someone to pick up the phone, and every check is on record. The check runs in well under a second, so nothing about the payment experience feels slower - which is the point: the safeguard should be invisible until the moment it matters.
RoxPay delivers scheme-compliant Verification of Payee through one REST API and a dashboard, covering both the requesting and responding directions, 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.