A payee checker is the tool that answers one question before money moves: does the name I have match the account behind this IBAN? In the EU the check is called Verification of Payee (VoP), it runs on the SEPA scheme, 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 you send - not after.
That is the simple version. The useful version is knowing what a payee checking service can and cannot do, because the phrase is used loosely and some of what it promises is not technically possible.
What a payee checker can and cannot do
It cannot look up who owns an IBAN. Account holder data is not public, it is personal data protected under GDPR, and the only institution that can say with certainty who holds an account is the bank that holds it. Any website claiming to reveal account holder names from a search box is guessing, reselling leaked data, or selling something else entirely.
What a real payee checker does is ask. Your payment service provider (PSP) sends the submitted name 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 shared register of account holders. It is a message between two banks, routed through the SEPA scheme. That is why coverage across the scheme matters more than the elegance of any single integration.
The four results a payee checking 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.
Who actually needs one
For an individual payer, the payee checker is 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.
For a bank or PSP, it is a scheme obligation with a deadline, and the work is a scheme project rather than a feature sprint: 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.
For a business - treasury, accounts payable, payroll, marketplaces - it is a service you call. You do not join the scheme. You verify a single payee in a dashboard, or you verify a whole payment file before release, and you re-verify when a supplier's bank details change. That is the pattern that catches invoice redirection, where a fraudster emails a 'new account' and the next payment follows it.
How to choose a payee checking 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 coverage. The responding PSP is the only party that can answer, so reach across the scheme is the single most important number. Ask how many PSPs are reachable and what happens when one is not.
- 3 Test the latency. The check sits in the payment flow, so it has to be fast. Ask for a measured figure, not a promise, and test it in a sandbox before you commit.
- 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 - and guessing is what the check exists to remove.
- 5 Look at the four outcomes, not three. 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 show what was checked, when, and what came back - per payment, exportable, and retained for as long as your own controls require.
- 7 Ask how it handles volume. A single payment in an app and a 20,000-line supplier file are different problems; you want one integration that does both.
The demo 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.
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.
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.