Verification of Payee Implementation: A Practical Guide

Verification of Payee (VoP) implementation is the work of making a name check part of your normal payment flow: the requesting PSP asks the PSP that holds the payee's account whether the submitted name matches the account holder, and gets a standardised answer back in well under a second. The check itself is small. Everything around it - scheme roles, integration, what the payer sees, and what you can prove afterwards - is what an implementation project actually manages.

This guide sets out the four workstreams, the build-versus-buy decision, a phased plan you can put in front of a steering committee, and the mistakes that most often push a go-live back. For the mechanics of the check itself, see how Verification of Payee works on the SEPA scheme.

First, decide which project you are running

There are two very different implementations, and mixing them up is the fastest way to over-scope a plan.

• A PSP implementation is a scheme project. You connect to the scheme's routing and directory infrastructure, implement the request and response messages, apply the name-matching rules to your own account data as a responding PSP, and surface the outcome in your channels as a requesting PSP.
• A business implementation is an integration project. Treasury, accounts payable, payroll or a marketplace does not join the scheme. It calls a VoP service that is already connected - through its bank or through an API - and wires the result into the point where payments are approved.

The four workstreams

1. Scheme and compliance

Confirm your deadline and your roles. Euro-area PSPs have had to offer VoP on euro credit transfers since 9 October 2025; PSPs in non-euro EEA states follow by 9 July 2027. If you hold customer accounts, other PSPs will ask about them, so you are likely a responding PSP as well as a requesting one. The check must be offered to the payer free of charge, and the obligation sits on euro credit transfers in scope of the regulation.

2. Integration

This is the part engineers own: credentials stored as secrets, a stable external id per request for idempotency and reconciliation, and clean handling of all four scheme outcomes - match, close match, no match and not available. Error paths matter as much as the happy path: an invalid IBAN, a timeout, or a responding PSP that cannot answer must all resolve to a defined behaviour rather than a stuck payment.

3. Payer experience

Offering the check means showing a clear result before the payer authorises - not burying it in a log. Two screens carry most of the value: the close-match suggestion, where the verified name is offered so the payer can confirm or correct rather than guess, and the no-match warning, which has to be firm enough to stop a payment without being so alarming that people click through it.

4. Operations and audit

Log every verification: the request, the outcome, the responding bank's BIC and the timestamp. That record is what lets you answer a customer query, evidence a control to an auditor, and review your own false-positive rate over time. Decide retention up front, because retrofitting a log is far more expensive than writing one.

Build or buy

Building scheme connectivity yourself gives you full control and no third-party dependency. It also means owning the directory, the message formats, the matching rules and the ongoing rulebook changes - and it is measured in months. Buying means you integrate one API and inherit the scheme connection, but you should test the things that actually matter: reach across PSPs, measured latency, whether the verified name comes back on a close match, and whether all four outcomes are supported cleanly.

A middle path is common: build the payer-facing experience and the internal controls, buy the scheme connectivity. Most teams find that the differentiating work is the UX and the audit trail, not the routing.

A phased plan that works

1. 1 Weeks 1-2: confirm scope, deadline and roles; pick build, buy or a hybrid; agree who owns each of the four workstreams.
2. 2 Weeks 2-4: integrate in a sandbox and exercise every outcome, including no match and not available, plus the error paths.
3. 3 Weeks 4-6: design and test the payer-facing screens with real users - especially the close-match suggestion.
4. 4 Weeks 6-8: pilot with a small population or a single payment channel, and watch the outcome mix and the support queue.
5. 5 Then: roll out channel by channel, and re-verify payee data when a supplier's bank details change rather than re-checking every saved payee on every run.

The mistakes that delay go-live

• Treating coverage as a detail. The responding PSP is the only party that can answer, so reach across the scheme is the number that decides how useful the check is in practice.
• Shipping a close match with no verified name. The payer is left guessing, which is exactly what the check exists to remove.
• No 'not available' path. A service that cannot return it cleanly will either block payments or hide failures.
• Leaving logging to the end. Audit and dispute handling depend on records you did not write.
• Switching on for everyone at once. A phased rollout costs a little more planning and saves a lot of incident management.

What good looks like when 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.