OC
Open Banking Compare

Verification of Payee Open Banking: Stop Wrong Payouts Before They Leave

10 min read

Wrong IBANs, invoice fraud, and authorised push payment scams cost finance teams hours of recovery work — and sometimes the money never comes back. Verification of payee (VoP) checks whether the name your customer typed matches the account holder at the destination bank before the payment is authorised, giving payout and pay by bank flows a clear match, close match, or no match signal. This guide explains how VoP fits open banking payment initiation, what changed under the EU Instant Payments Regulation, and how to evaluate providers when you wire outbound transfers at scale.

Verification of payee open banking diagram showing payer input, name-IBAN check, and match result before payment

Verification of payee (VoP): A pre-payment check that compares the payee name you hold against the account holder name registered at the destination bank — returning match, close match, no match, or unavailable — so your team can block or confirm misdirected outbound transfers before funds leave.

What verification of payee delivers for payment teams

VoP gives operations and product teams four concrete outcomes before authorisation:

  • Fewer misdirected payouts — catch typos, swapped digits, and social-engineering redirects when the name does not align with the IBAN
  • Lower APP fraud exposure — authorised push payment scams often rely on a plausible name on a criminal account; a no-match result is a hard stop
  • Clearer customer UX — show "close match" with suggested correction instead of silent failure after settlement
  • Audit evidence — timestamped check results for disputes, insurance claims, and internal controls

VoP is not the same as instant account verification at onboarding. Account verification confirms who owns an account when you first register a counterparty. VoP runs at payment time — every time the payer sends money — and compares the payee name against what the payee's bank holds for that IBAN.

How verification of payee works in open banking flows

The check sits between data entry and payment authorisation:

  1. Payer provides payee details — name and IBAN (and sometimes BIC) in your portal, ERP, or checkout.
  2. Your PSP or open banking provider sends a VoP request — typically to the payee's payment service provider via a scheme-compliant channel.
  3. Payee bank responds — match (names align), close match (minor difference — e.g. "Jon Smith" vs "Jonathan Smith"), no match, or unavailable.
  4. Your UI surfaces the result — block, warn, or let the payer confirm before strong customer authentication and initiation.
  5. Payment proceeds or stops — only after the payer accepts the risk on a close or no match, if your policy allows.

For pay by bank checkout, the same primitive protects merchants when customers pay suppliers or when platforms route marketplace payouts. Engineering effort concentrates on UX for close matches, retry logic when VoP is temporarily unavailable, and logging — not on bilateral bank integrations, when you use a licensed provider that participates in the European Payments Council VoP scheme.

Verification of payee open banking flow from payer input through bank response to payment decision

Match outcomes your product should handle

Result Typical meaning Product response
Match Name aligns with account holder Proceed to authorisation
Close match Minor spelling or formatting difference Show suggested name; require explicit confirm
No match Name and account holder diverge Block by default or require elevated approval
Unavailable Payee bank or scheme path down Retry, queue, or fall back per policy

Treat "unavailable" as a first-class state. Hard-blocking every payment when VoP fails creates false declines; allowing all unavailable checks through removes the fraud benefit. Most B2B teams cap retries, log the skip, and apply tighter limits on high-value outbound transfers.

EU Instant Payments Regulation and VoP deadlines

Euro-area payment service providers have been required to offer payers a free verification-of-payee service for credit transfers since 9 October 2025, under Article 5c of Regulation (EU) 2024/886 as implemented in the SEPA Regulation. The European Central Bank's Instant Payments Regulation overview lists parallel deadlines: non-euro member states by 9 July 2027, with electronic money institutions and payment institutions in the euro area following the same October 2025 VoP date.

The service applies to standard and instant euro credit transfers — not only instant rails. Payers must receive the result before they authorise the payment, and PSPs cannot charge the payer extra for the check.

Liability shifts when VoP is skipped or mishandled: where the payer's PSP fails to perform the check as required, it may bear loss on transfers to unintended payees that would have been caught by a correct VoP response. That makes VoP an operational control topic for CFOs, not only a compliance checkbox.

EPC VoP scheme and the September 2026 rulebook update

Inter-PSP interoperability depends on shared rules. The European Payments Council maintains the VoP scheme rulebook, API specifications, and API Security Framework so banks and payment institutions exchange checks consistently across SEPA.

In 2026 the EPC published version 1.1 of the VoP rulebook and version 2.1 of the API Security Framework, effective 20 September 2026, following public consultation on urgent change requests. For product teams, that means:

  • Standardised API behaviour — less bespoke per-bank VoP wiring when your provider adheres to the scheme
  • Clearer certificate and security rules — mandatory API Security Framework use for scheme participants from September 2026
  • Alignment with IPR legal obligations — scheme rules track Article 5c requirements on timing, free service to payers, and response types

If you evaluate open banking providers for outbound payments, ask whether they are VoP scheme participants or route through a participant — ad-hoc bilateral checks rarely scale across EU coverage maps.

Verification of payee scheme timeline showing IPR October 2025 deadline and EPC rulebook 1.1 September 2026

How VoP relates to PSD3 and open banking payment initiation

VoP existed before the PSD3 and Payment Services Regulation package finishes adoption. The Instant Payments Regulation created the near-term obligation; PSD3 open banking extends verification-of-payee expectations across credit transfers on a longer implementation horizon once the package enters force in the Official Journal.

For buyers, the practical split is:

  • Today — wire VoP into instant and SEPA credit transfers using IPR timelines and EPC scheme APIs
  • Next — map PSD3/PSR VoP generalisation into your payment initiation roadmap when entry-into-force dates firm up (~21–27 months after OJ publication for different provisions)

Open banking payment initiation (pay by bank, platform payouts) benefits from VoP at the same choke point: after the user enters payee details, before SCA. Providers that combine initiation with VoP reduce vendor count and keep match results in one webhook stream.

Provider evaluation criteria for VoP-enabled open banking

When you shortlist infrastructure for verification of payee open banking flows, score these dimensions:

Criterion Why it matters
Scheme participation Direct or indirect EPC VoP adherence — affects coverage and response consistency
Coverage map Which payee banks return VoP vs unavailable in your target markets
Latency Sub-second checks so checkout and payout UX does not stall
Close-match UX helpers Suggested corrections reduce false blocks
Webhook / API clarity Structured match codes for your risk engine
Unavailable handling Retry policy, idempotency, and logging for audit
Initiation bundle Same provider for VoP + pay by bank initiation simplifies integration

Run a sandbox test matrix: exact match, deliberate typo, completely wrong name, and payee bank outside VoP coverage. Compare how each provider surfaces close match and whether they support bulk payout files with per-row VoP.

VoP complements — does not replace — income verification open banking and affordability checks on the inbound side. Outbound VoP protects who you pay; inbound verification confirms who pays you.

Frequently Asked Questions

What is verification of payee in open banking?

Verification of payee (VoP) is a pre-payment check that compares the payee name your user entered with the account holder name held at the destination bank for that IBAN. The payer's payment service provider requests the check, receives match, close match, no match, or unavailable, and shows the result before the customer authorises the transfer. In EU open banking payment flows, VoP reduces misdirected payouts and authorised push payment fraud without replacing strong customer authentication.

Is verification of payee mandatory in the EU?

Yes for in-scope payment service providers. Under the EU Instant Payments Regulation (Regulation (EU) 2024/886), euro-area PSPs must offer payers a free verification-of-payee service for credit transfers from 9 October 2025. Non-euro EU member states have until 9 July 2027. Electronic money institutions and payment institutions in the euro area follow the October 2025 VoP deadline. The service must complete before the payer authorises the payment.

What is the difference between verification of payee and account verification?

Verification of payee runs at payment time and checks whether the payee name matches the IBAN holder before a specific transfer. Account verification confirms account ownership during onboarding or before storing bank details for future use. Open banking teams often need both: account verification when registering suppliers, VoP on every outbound payment — especially when payee details change or amounts are high.

What should we do when VoP returns "close match"?

Show the payer the suggested correct name, highlight the difference, and require explicit confirmation before authorisation. Many fraud patterns produce close matches — similar spellings on mule accounts — so policy teams often treat close match as higher risk than exact match. Log the user's decision for dispute and audit trails. Do not auto-correct silently without payer consent.

Does verification of payee work with pay by bank checkout?

Yes. Pay by bank initiation can call VoP after the customer enters or selects payee details and before redirecting to bank authentication. The same match outcomes apply. Providers that bundle pay-by-bank initiation with VoP reduce integration work and keep fraud signals in one API flow — useful for marketplaces, B2B portals, and refund rails where wrong-IBAN errors are costly.

How does the EPC VoP scheme relate to open banking providers?

The European Payments Council publishes the VoP scheme rulebook and API specifications so PSPs exchange checks interoperably across SEPA. Open banking providers that initiate payments or offer payout APIs typically connect through scheme participants rather than building bilateral bank links. Version 1.1 of the rulebook and API Security Framework 2.1 take effect on 20 September 2026, tightening standardisation for participants.

Will PSD3 change verification of payee requirements?

PSD3 and the Payment Services Regulation extend verification-of-payee concepts across credit transfers on timelines tied to Official Journal publication — generally after the Instant Payments Regulation deadlines already in force. Teams should implement IPR and EPC VoP requirements now and track PSD3/PSR entry into force for harmonised long-term rules. See our PSD3 open banking guide for the adoption timeline.

Conclusion

Verification of payee turns "did we pay the right person?" from a post-settlement recovery problem into a pre-authorisation decision. Euro-area PSPs already owe payers a free VoP path on credit transfers; the EPC scheme update in September 2026 tightens interoperability for participants. Product and finance teams wiring open banking payouts or pay-by-bank checkout should treat match, close match, and unavailable as first-class UX states — and shortlist providers on coverage, latency, and initiation bundle fit before committing to a integration.