Verification of Payee under the Instant Payments Regulation
Verification of Payee — VoP — is the IBAN-name check the Instant Payments Regulation requires every euro-area PSP to run before a SEPA credit transfer is authorised. The euro-area deadline was 9 October 2025, so VoP is now a live production obligation, not a roadmap item. The check happens before the payer confirms, completes in seconds, and shifts the loss for a misdirected payment onto whichever side fails to perform or display it. This piece walks through what VoP is, the four possible outcomes, the liability mechanics, worked examples of the cases your operations team will actually see, and the implementation points that separate a compliant setup from a nominal one.
1. What Verification of Payee is
The Instant Payments Regulation — Regulation (EU) 2024/886, amending Regulation (EU) 260/2012 — introduces a payee-name verification check on SEPA credit transfers, standard and instant alike, between euro-area PSPs. Before the payer authorises the payment, the payer’s PSP must verify that the IBAN entered matches the name of the intended payee by querying the payee’s PSP, and must show the result to the payer before confirmation. The mechanism is the EU counterpart of the United Kingdom’s Confirmation of Payee, with broader mandatory scope.
2. Who must offer it
- Every euro-area PSP offering SEPA credit transfers — credit institutions, EMIs, payment institutions, post-office giro institutions.
- Non-euro-area EU PSPs follow on a phased basis with a later deadline.
- Non-EU PSPs reaching SEPA through correspondents see the obligation flow through their EU counterparty.
There is no de-minimis threshold: offer one in-scope SEPA credit transfer and you must offer VoP on it.
3. The data flow and the four outcomes
The exchange follows the European Payments Council’s VoP scheme on an ISO 20022-style message structure. The payee’s PSP looks up the IBAN in its customer master, compares the supplied name against the registered holder, and returns one of four results:
| Result | Meaning | What the payer sees |
|---|---|---|
| Match | Supplied name equals registered name within tolerance | Positive confirmation; proceed normally |
| Close match | Partial match | Warning plus the registered name (where disclosure is permitted) for visual confirmation |
| No match | Supplied name does not align with the registered name | Clear warning; proceeding is at the payer’s own risk |
| Cannot verify | Check could not be completed (closed account, technical failure) | Notice that verification was impossible |
The whole exchange is designed to complete within seconds end to end, including rendering on the payer’s screen — which leaves the payee-side account lookup a budget of a few hundred milliseconds.
4. The liability shift
Historically, a SEPA credit transfer authorised by the payer was final: the IBAN was the binding identifier and the name was decorative. The IPR changes the allocation. If the payer’s PSP fails to perform VoP — or performs it but does not properly display the result — and the payment turns out misdirected, the loss sits with the payer’s PSP. Conversely, a payer who is shown a no-match or close-match warning and proceeds anyway carries the consequences. VoP is a duty of due care discharged by the PSP, which converts into a duty of attention on the payer once the warning is on screen.
5. Worked example — the transposed surname
Facts: A retail payer sends €2,400 to a landlord, typing “Ana Marria Lopez” against an IBAN registered to “Ana María López García”.
What comes back: The payee PSP’s similarity engine scores the supplied name as a partial match — spelling deviation plus a missing second surname — and returns close match with the registered name.
What the practitioner does: The payer’s PSP displays the registered name and requires an explicit choice: amend or proceed. The design decision that matters is friction calibration — the warning must be unmissable without training users to click through it. Logging the displayed name and the payer’s choice is what protects the PSP if the payment is later disputed.
6. Worked example — invoice fraud caught by a no-match
Facts: A small company pays a €18,000 supplier invoice. The invoice PDF was intercepted and the IBAN swapped for an account held by an unrelated individual. The clerk types the supplier’s legal name against the fraudster’s IBAN.
What comes back: The registered holder of the IBAN bears no resemblance to the supplier’s name — no match.
What the practitioner does: On the payer side, this is VoP working exactly as intended: the warning stops the classic invoice-redirection fraud before authorisation. On the payee-PSP side, a no-match on a sizeable inbound corporate payment is also a fraud-monitoring signal worth feeding into transaction-monitoring — mule accounts collect exactly these payments. If the clerk overrides the warning and pays anyway, the loss allocation has shifted to the payer.
7. Worked example — bulk files and trusted payees
Facts: A corporate customer uploads a monthly salary file of 900 credit transfers, most to the same employee IBANs as last month.
What the rule says: The IPR contains specific provisions for bulk submissions, where verification results are handled in aggregate rather than interrupting each line, and it allows payers to opt out of VoP for payees they have designated — an opt-out that is per-payee and revocable.
What the practitioner does: Offer the corporate channel an aggregated results view — the customer needs to see which lines failed verification before releasing the file, not 900 sequential pop-ups. For genuinely recurring counterparties, the documented opt-out keeps the flow efficient while preserving the audit trail showing the customer made that choice.
8. Implementation tradeoffs
- Latency budget. The envelope is end-to-end, so the payee-side lookup must sit on a fast path against the customer master — batch-synchronised copies and slow API hops do not survive it.
- Match tolerance. “Within tolerance” is interpreted by the payee’s PSP. Too strict floods payers with false close-matches and abandoned payments; too loose erodes the check. A documented similarity policy — token comparison, edit distance, transliteration handling — is both an engineering artifact and an audit artifact.
- Privacy. Returning the registered name on a close match is a deliberate, legally bounded disclosure under the IPR — implement it as specified, not more generously.
- Instant payments. VoP must fit ahead of the SCT Inst execution window, which itself runs in seconds — the two budgets stack, and both are hard.
9. FAQ
Is VoP mandatory only for instant payments?
No. It applies to all SEPA credit transfers between euro-area PSPs — standard and instant. The 9 October 2025 euro-area deadline covered both.
What happens if the payee’s PSP does not respond?
The payer’s PSP shows “cannot verify” and the payer may proceed at their own risk. The payer’s PSP has discharged its duty by performing the check and displaying the outcome.
What about transfers to non-euro-area PSPs?
The immediate obligation sits on euro-area PSPs; non-euro-area EU member states follow on a phased timeline under the IPR. Outside the EU, VoP does not apply.
Does the payee know a VoP check was run?
No. It is a back-office exchange between the two PSPs; the payee’s PSP does not surface lookups to the account holder.
Can PSPs charge for VoP?
No — the IPR prohibits charging the payer for the verification itself, and its fee-parity rule stops PSPs pricing instant transfers above equivalent standard ones. See our IPR reporting piece.
Is a VoP match a sanctions check?
No. VoP matches the payee name to the IBAN; sanctions screening matches persons against designation lists. They run independently, and a sanctions hit blocks the payment regardless of the VoP result.
Who bears the loss if a payment is misdirected despite VoP?
If the PSP performed and displayed the check correctly and the payer proceeded past a warning, the payer. If the PSP failed to perform or display it, the PSP. The audit log of what was shown is decisive.
10. What to do, today
- Product owner: verify your live VoP flow displays all four outcomes distinctly and that no UI path lets a payer authorise without seeing the result.
- Engineering lead: monitor payee-side lookup latency with alerting — sustained “cannot verify” rates are a compliance metric, not just an ops one.
- Compliance: document the name-matching tolerance policy and keep the change history; it will be requested in any misdirection dispute.
- Corporate-channel owner: implement aggregated VoP results for bulk files and the per-payee opt-out with a recorded customer decision.
- MLRO: feed no-match patterns on inbound payments into fraud and mule-account monitoring — VoP data is a detection asset.
Related: What is the IPR report? · Sanctions screening at instant-payment speed · What is CESOP reporting? · SCA exemptions under the PSD2 RTS · The EU Digital Identity Wallet · PSD2 fraud reporting under Article 96(6) · Payment Accounts Directive — fees and switching
