EU-wide

Verification of Payee under the Instant Payments Regulation

Fintech Passport

April 29, 2026 · 6-min read

Verification of Payee under the Instant Payments Regulation

Verification of Payee — VoP — is the name-check the Instant Payments Regulation requires every euro-area PSP to perform before a SEPA credit transfer reaches the network. The deadline for euro-area PSPs is 9 October 2025. The check happens before authorisation, runs in well under a second, and shifts the loss for a misdirected payment to whichever side fails to perform it. This piece walks through what VoP is, what the technical exchange looks like, the operational tradeoffs, and what every PSP needs to have in production.

1. What VoP is, in one paragraph

The Instant Payments Regulation — Regulation (EU) 2024/886, amending Regulation (EU) 260/2012 — introduces a payee-name verification check on every SEPA credit transfer (regular and instant) made between euro-area PSPs. Before the payer authorises the payment, the payer’s PSP must check that the IBAN entered by the payer matches the name of the intended payee, by querying the payee’s PSP. The result — match, close-match or no-match — is shown to the payer before they confirm. The mechanism is colloquially called Verification of Payee, abbreviated VoP. It is an EU equivalent of the United Kingdom’s Confirmation of Payee, with stricter scope.

2. Who must offer it

Every PSP based in a euro-area member state that offers SEPA credit transfers — credit institutions, electronic-money institutions, payment institutions, post office giro institutions.
For non-euro-area EU PSPs, the IPR applies on a phased basis with a later deadline.
For non-EU PSPs participating in SEPA via correspondent arrangements, the obligation flows through the EU counterparty.

There is no de-minimis threshold. A PSP that offers a single SEPA credit transfer in scope must offer VoP on it.

3. The data flow, end to end

The exchange follows the European Payments Council’s VoP scheme, layered on top of an ISO-20022-style message structure. The payer’s PSP sends a verification request including the IBAN and the name as entered. The payee’s PSP looks up the IBAN in its customer master, compares the supplied name with the registered account holder, and replies with one of:

Match — the supplied name equals the registered name within tolerance.
Close match — partial match; the response includes the registered name where confidentiality permits, allowing the payer to confirm visually.
No match — the supplied name does not align with the registered name.
Cannot verify — the payee’s PSP cannot complete the check (account closed, technical failure, etc.).

The whole exchange is expected to complete in under five seconds end to end, including UI rendering on the payer’s screen.

4. The liability shift

Where the payer’s PSP fails to perform VoP — or performs it but does not display the result to the payer — and the payment is later disputed as misdirected, the loss sits with the payer’s PSP. This is a meaningful change. Historically a SEPA credit transfer authorised by the payer was final; the IBAN was the binding identifier and the name was for human reference only. The IPR makes the name a check that the PSP must run.

The flip side: where the payer is presented with a no-match or close-match warning and proceeds anyway, the payer carries the consequences. The check is not a guarantee — it is a duty of due care discharged by the PSP and a duty of attention shifted to the payer.

5. Implementation tradeoffs

Three operational questions every PSP needs to answer:

Latency budget. The 5-second envelope is end-to-end. Inside it, the payer’s PSP needs to render the form, send the request, wait, render the result. That leaves a small window for the lookup itself — a few hundred milliseconds. Customer-master lookups need to be on a fast path.
Match tolerance. “Equal within tolerance” is interpreted at the payee’s PSP. Too strict produces false negatives (payer abandons the payment); too loose erodes the check’s value. Most PSPs implement a name-similarity engine — Levenshtein distance, token-based comparison, transliteration handling.
Privacy — when responding “close match”, the payee’s PSP discloses the registered name. The legal basis sits inside the IPR and the relevant national data-protection guidance; the response is permitted but bounded.

6. VoP and instant payments — the timing problem

VoP is mandatory on both standard and instant SEPA credit transfers. For instant credit transfers under the SCT Inst scheme, the entire transaction must complete in under 10 seconds — and VoP fits inside that envelope. In practice that means:

VoP request → response: under 5 seconds.
Payer confirms.
SCT Inst transaction: under 10 seconds.

For PSPs whose customer-master systems are not built for sub-second lookup, the IPR is an architectural prompt — not just a regulatory one.

7. Exemptions and edge cases

The regulation accommodates a small number of cases:

Trusted-payee lists. A payer can opt out of VoP for payees the payer has whitelisted (for example, recurring transfers to a known counterparty). The opt-out is per-payee and revocable.
Bulk payments. Payment-initiation services and bulk-file uploads have specific provisions for VoP responses to be aggregated.
Non-account counterparties. Where the payee identifier is not an IBAN (rare in SEPA), VoP does not apply.

8. Getting ready — checklist

Customer-master integration — the payee’s PSP needs an in-process lookup against its own account-holder data.
Name-similarity engine — a pluggable comparison logic with a documented tolerance configuration.
Payer-side UI — display match / close-match / no-match results clearly, with explicit user confirmation before proceeding.
Logging and audit — every VoP exchange must be persisted with timestamps, the result, and the payer’s response.
SLA monitoring — alerting on response times above the latency budget; a slow VoP is a failed VoP for IPR-compliance purposes.

9. FAQ

Is VoP mandatory only for instant payments?

No. The IPR makes VoP mandatory for all SEPA credit transfers between euro-area PSPs — standard and instant. The 9 October 2025 deadline applies to all of them.

What if the payee’s PSP does not respond?

The payer’s PSP receives a “cannot verify” result and must display it. The payer can choose to proceed at their own risk; the payer’s PSP has discharged its duty by performing the check.

What about transfers to non-euro-area PSPs?

The IPR’s VoP obligation is on euro-area PSPs. Transfers to non-euro-area PSPs are subject to the receiving country’s rules; some non-euro-area EU member states are bringing in equivalent requirements with a later deadline.

Does the payee see the request?

No. VoP is a back-office check between the two PSPs. The payee’s PSP does not surface the lookup to the payee.

Are there fees?

The IPR prohibits charging the payer for VoP itself. Fee-parity rules in the IPR also prevent charging more for an instant credit transfer than for an equivalent standard one — see our IPR reporting piece.

How does VoP interact with sanctions screening?

VoP runs before the IBAN-name check is finalised — in parallel with sanctions screening at the payer’s PSP. The two are independent. A VoP match does not waive sanctions obligations; a sanctions hit blocks regardless of VoP outcome.

10. What to do, today

Confirm 9 October 2025 is on your IPR roadmap as a hard deadline.
Audit your customer-master lookup latency and rebuild for sub-second response if needed.
Decide your name-similarity policy and document it for audit.
Design the payer-side UI for match / close-match / no-match outcomes — do not bury the warning.
Coordinate with your sanctions-screening engine so the two checks run in parallel within the 10-second SCT Inst envelope.