Verification of Payee on SEPA is a name check that happens between two banks before a payment moves. You enter a payee name and an IBAN; your payment service provider (PSP) asks the PSP that holds that IBAN whether the name matches the account holder; the answer comes back in a standardised format, usually in under a second. Nothing about the amount, your balance or the payee's transactions is shared - only the name comparison.
That is the whole idea. What makes it work across dozens of countries and thousands of banks is that it is a scheme, not a product: a common rulebook, common message formats and a common set of outcomes that every participating PSP agrees to speak.
Why 'SEPA' is the important word
SEPA - the Single Euro Payments Area - is the payment area where euro credit transfers, direct debits and instant payments follow one set of rules. Verification of Payee was built for that same area, on IBANs, and is coordinated by the European Payments Council (EPC), the body that maintains the SEPA rulebooks. The EPC's VoP scheme defines how a request is formatted, how a response is formatted, which outcome codes exist and how PSPs find each other.
This is why VoP is not the same thing as a UK-style name check, and why a provider connected to one scheme is not automatically connected to the other. If your payments are euro payments inside SEPA, the SEPA scheme is the one that applies to you.
A scheme, not a database
There is no central list of account holders to look names up in. The only bank that can authoritatively say who holds an IBAN is the bank that holds it. VoP is therefore a conversation between PSPs, routed through the scheme - not a lookup against a shared register.
How the check travels between two banks
- 1 The payer enters a payee name and an IBAN in their banking app or in their ERP payment file.
- 2 The requesting PSP sends a verification request containing the submitted name and the IBAN.
- 3 The scheme routes the request to the PSP that holds the account - the responding PSP - using the routing information published in the scheme directory.
- 4 The responding PSP compares the submitted name with the name held on the account, using the scheme's name-matching rules.
- 5 A standardised response returns to the requesting PSP, which shows the payer the outcome before the payment is authorised.
Two details matter in practice. First, the responding PSP is the only party that can answer - which is why coverage across the scheme matters more than the elegance of any single integration. Second, the request and response are machine-to-machine messages, so the check can run on a single payment in an app or on every line of a supplier payment file.
The four outcomes you get back
- Match - the submitted name matches 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 responding PSP could not answer at that moment. The payment is not blocked; the payer is informed and decides.
The middle two are where the value sits. A close match is not a failure - it is the scheme handing you the correct name so the next payment matches cleanly. A no match is not a system fault - it is the check doing exactly its job.
What 'payee checker' and 'payee checking service' really mean
People search for a payee checker or a payee checking service expecting a website where they can type a name and an IBAN and get an answer. That is not how it works, and it is worth being clear about why: account holder data is not public, and no third party can authoritatively confirm who holds an IBAN. The check is bank-to-bank by design. What you can do as a payer is use the verification your own PSP offers at the moment you set up or pay a payee. What you can do as a business is run that same check across a whole payment file before releasing it.
What implementation actually involves
For a PSP, implementing VoP on SEPA is a scheme project, not a feature sprint. In outline it means connecting to the scheme's 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. The work is well understood, but it touches core payment flows, so it is usually planned in phases rather than switched on in one go.
For a business - treasury, accounts payable, payroll - implementation is much lighter. You do not join the scheme. You call a VoP service that is already connected to it, either through your bank or through an API, and you wire the result into the point where payments are approved. The practical pattern is to verify the whole payment file before release and re-verify when a supplier's bank details change, rather than checking every saved payee on every run.
Where the obligation comes from
The EU Instant Payments Regulation made Verification of Payee mandatory for PSPs in the euro area from 9 October 2025, and for PSPs in non-euro EEA states by 9 July 2027. The regulation sets the obligation; the EPC scheme sets the mechanics. In practice that means the check is now part of the normal SEPA payment flow rather than an optional extra - and it must be offered to payers free of charge.
RoxPay delivers Verification of Payee on the SEPA scheme 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 so payers can confirm rather than guess.