When teams plan for Verification of Payee, they picture the requesting side: a customer enters a name and IBAN, and the bank checks it before sending. But that check only works because the payee's bank answers. That bank is the responding PSP — and under the scheme, most institutions need to play both roles.
Requesting vs responding
The requesting PSP asks 'does this name match this IBAN?' on behalf of a payer. The responding PSP receives that question about one of its own account holders and replies with a standardised outcome. If you hold customer accounts, other banks will be asking you — so you must be able to respond.
Compliance is usually two-sided
Offering VoP to your payers (requesting) and answering requests about your customers (responding) are different builds. Plan for both, not just the user-facing one.
What a responding PSP must implement
- 1 Securely receive verification requests from other PSPs on the scheme.
- 2 Match the requested name against your account-holder records, including handling close matches.
- 3 Return the standardised outcome (match, close match, no match, not applicable) with the right scheme code.
- 4 Respond fast and reliably — latency and availability are part of the obligation.
Doing both through one connection
Building and maintaining responder infrastructure — matching logic, uptime, scheme messaging — is significant. Operating on a provider already connected to the SEPA VoP scheme lets you cover both requesting and responding through one integration. RoxPay operates on the SEPA scheme and returns standardised outcomes with the responding bank's BIC, so a single connection reaches verification across Europe.