Verification of Payee Solution: A Buyer's Checklist

A Verification of Payee solution is the service that checks a payee name against the account behind an IBAN before a SEPA 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.

That is the definition. The decision in front of you is different: which service to use, and how to tell a working one from a demo. This article is the checklist for that decision - the questions to ask, the answers that should worry you, and the ones that should not.

First, be clear about what a VoP service is not

It is not a lookup. Account holder data is personal data, and only the bank that holds the account can confirm who owns it. A VoP service does not search a register of names - it asks the payee's bank whether the name you supplied matches the account holder, and returns the answer. Any service that claims to reveal the owner of an IBAN from a search box is guessing, reselling leaked data, or selling something else.

The buyer's checklist

1. 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. 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. Ask how many PSPs are reachable and what happens when one is not.
3. 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, and test it yourself before you commit.
4. 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 exactly what the check exists to remove.
5. 5 Look for all four outcomes, not three. Match, close match, no match and not available. A service that cannot return 'not available' cleanly will either block payments or hide failures.
6. 6 Check the audit trail. You should be able to export what was checked, when, and what came back - per payment, and retained for as long as your own controls require.
7. 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.
8. 8 Confirm who answers the phone. The check runs inside a payment flow, so support is part of the product, not an afterthought.

The three-check test

Before you sign anything, run three checks on a payee you know well: 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. If any of the three comes back vague, slow or unlogged, you have your answer.

Who is buying, and what they actually need

• 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.
• 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, 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. 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 good looks like once you are live

A finished implementation 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, 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.