Confirmation of Payee SEPA, formally called Verification of Payee (VoP), lets a payer's bank check whether an IBAN matches the named account holder before a SEPA credit transfer goes through. It stopped being optional on October 9, 2025, when the EU Instant Payments Regulation made VoP checks mandatory for SEPA Credit Transfers and SEPA Instant Credit Transfers. The result is fewer misdirected payments, but also a real integration burden for every payment service provider in the scheme.
TL;DR:
- Confirmation of Payee checks match the entered IBAN against the account holder’s recorded name, returning match types like full, close, or no match, but does not verify identity.
- The verification process relies on a secure inter-bank API with mutual TLS, using ISO 20022 data and a shared registry, with response times under two seconds across 20 eurozone countries.
- As of October 9, 2025, VOX checks are mandatory for all PSPs offering SEPA payments, with updates to the scheme rules expected to refine processes and address operational issues.
- Implementing VoP requires careful architecture choices, strict certificate management, and thorough testing, including negative scenarios and ongoing monitoring of mismatch and timeout rates.
- Human decision-making during close match alerts is critical, as clicking through without verification can undermine fraud prevention efforts that VoP aims to enhance.
Table of Contents
- What Does Verification of Payee Actually Check?
- How Does the VoP Check Flow Between Banks?
- When Did Confirmation of Payee Become Mandatory in SEPA?
- What Should PSPs and Payers Build Before Go-Live?
- How Should Finance Teams Handle VoP in Day-to-Day Payments?
- How Does Vopify Apply Real-Time Payee Verification?
- What Fraud Risks Does Confirmation of Payee Actually Address?
- What GDPR Rules Apply to Payee Name Checks?
- How Do Cross-Border SEPA Payments Change VoP Requirements?
- What Happens When a Payee Verification Result Is Wrong?
- Where Should Compliance Teams Focus First?
- Get SEPA Payee Verification Running Without the Integration Headache
- Sources
- FAQ
What Does Verification of Payee Actually Check?
VoP compares two pieces of data: the IBAN the payer enters and the name they believe belongs to that account. The requesting bank sends both to the account-holding bank, which checks them against its own records and sends back a verdict. Some implementations also pass optional identifiers like a VAT number or Legal Entity Identifier (LEI), which sharpens matching for business accounts where trading names and registered names often differ.
The EPC's VOP scheme defines four canonical response types. A Match means the name and IBAN line up exactly. No match means they don't, full stop. Close match sits in between: the account exists, but the name is off, so the bank returns a matchedName field showing what's actually on file, letting the payer decide whether to proceed. Verification not possible covers scenarios where the responding bank can't complete the check, often due to a technical outage or an unsupported account type.
None of this proves identity in a legal sense. VoP validates a name-IBAN pairing against what a bank has on record, not a person's actual identity or right to the funds. A fraudster who's already renamed a mule account to match a stolen invoice will still clear the check. That's a limitation worth remembering before anyone treats a Match response as a fraud guarantee.
How Does the VoP Check Flow Between Banks?
The mechanics behind SEPA account verification run through a defined inter-PSP handshake, not a public API anyone can query directly.
Here's the sequence in practice:
- The requesting PSP (the payer's bank) initiates a check and first consults the EDS directory, a shared registry that maps IBANs or bank identifiers to the correct responding endpoint.
- Once the endpoint is found, the requesting PSP opens a connection secured by mutual TLS client authentication, meaning both sides present certificates before any data moves.
- The requesting PSP sends a
POSTrequest to the responding PSP's VOP endpoint, structured around ISO 20022 data elements, with a defined maximum execution time so payers aren't left waiting. - The responding PSP checks its own account records and returns a JSON payload with fields like
partyNameMatch,matchedName(only populated on a close match), and standardized reason codes.
Every request carries required headers, including an X-Request-ID for traceability and a timestamp, per the EPC VOP API specifications. PSPs keep a local cached copy of the EDS directory rather than querying it live on every transaction, both for speed and resilience if the central directory has downtime. Scheme adherence checks confirm a responding endpoint is actually certified before a requesting PSP trusts its answer, which matters given how much fraud prevention rides on that trust chain holding up.
When Did Confirmation of Payee Become Mandatory in SEPA?
October 9, 2025 is the date that matters most: it's when the Instant Payments Regulation required PSPs offering SEPA Credit Transfers and SEPA Instant Credit Transfers to also offer VoP checks to their customers. The Eurosystem helped close a coordination gap ahead of that deadline, confirming that solutions built by Banco de Portugal and Latvijas Banka could give participating banks SEPA-wide reach without every institution building its own connectivity from scratch.
The scheme itself isn't static. The EPC published VOP scheme rulebook v1.0 to take effect alongside the October 2025 mandate, then followed with v1.1, effective September 20, 2026, incorporating urgent fixes and clarifications that surfaced once banks started running checks in production. Expect this pattern to continue: rulebook updates driven by real operational friction rather than theoretical design.
A second wave of deadlines applies to PSPs operating outside the eurozone but still within SEPA's geographic scope, with a later compliance point marking key obligations for some non-euro areas under the regulation. Any compliance calendar built around VoP needs to track both the euro-area dates and this second tier, since a PSP's obligations depend on which currency and which side of the mandate it sits on.
What Should PSPs and Payers Build Before Go-Live?
Getting SEPA payment verification live isn't just a coding task. It's a sequence of architecture decisions, certificate management, and UX calls that determine whether the rollout actually reduces fraud or just adds friction.
- Choose an architecture path. Decide whether to connect directly as a Requesting and Responding PSP, or route through a service provider that already holds scheme certification. Direct connection gives more control; routing through a provider cuts the certification timeline.
- Lock down authentication. Mutual TLS with QWAC or PSD2-grade certificates is non-negotiable for scheme participation, and certificate renewal cycles need their own monitoring so a lapsed cert doesn't silently break verification.
- Design the payer-facing message. A Match should clear with minimal friction. A Close match needs a clear prompt showing the matched name and letting the payer confirm or cancel. A No match should stop the transfer by default, not just display a soft warning.
- Test beyond the happy path. Sandbox connectivity tests are the starting point; run end-to-end latency tests against the maximum execution time, and deliberately test negative and malformed inputs to see how gracefully the integration fails.
- Instrument for ongoing monitoring. Track response-time percentiles, mismatch rates by counterparty bank, and alerting for endpoints that start timing out or returning "verification not possible" more than usual.
Pro Tip: Sending the exact registered legal name, not a trading name or abbreviation, meaningfully improves match rates. Payment processors that document this pattern consistently find that most "close match" results trace back to a payer typing a shortened or informal business name rather than an actual account discrepancy.
How Should Finance Teams Handle VoP in Day-to-Day Payments?
Confirmation of Payee changes supplier onboarding as much as it changes the payment moment itself. Capturing the canonical legal name and, where available, a VAT number or LEI at onboarding time, rather than pulling whatever name appears on an old invoice, prevents a wave of avoidable close matches down the line.
Before a payment run, bulk-checking the supplier master file against current IBAN and name records catches data drift early. Suppliers change banks, merge, or get acquired, and a supplier list that hasn't been reverified in a year is a list full of latent mismatches waiting to surface mid-payment-run.
When a check comes back anything other than a clean Match, treasury and accounts payable teams need a documented decision path rather than an ad hoc judgment call:
- A Close match should trigger a direct confirmation call or email to the supplier's known contact, never a reply to the invoice email itself, since that's a common fraud vector.
- A No match should hold the payment entirely until the supplier confirms new banking details through a verified channel.
- Repeated verification not possible results on one counterparty bank should get logged and escalated, since it may signal a connectivity issue worth flagging to that bank rather than repeatedly retrying.
Every check result, decision, and override needs a timestamped record. When a dispute or audit lands months later, that log is the only thing standing between "we followed procedure" and a costly reconstruction exercise.
How Does Vopify Apply Real-Time Payee Verification?
A real-time payee verification service can provide instant name-and-IBAN matching covering multiple Eurozone countries with fast response times. Such platforms may support both single lookups and bulk CSV uploads, which matters for AP teams cleaning an entire supplier file rather than checking one payment at a time.
Teams running occasional international payments can work through the dashboard directly. High-volume AP departments running weekly payment cycles typically lean on bulk CSV uploads to clear a supplier batch before a run, while PSPs and larger finance operations needing verification inside their own payment workflow are the intended audience for Vopify's planned API access. Choosing between the three usually comes down to volume and how tightly verification needs to sit inside an existing payment pipeline, rather than any difference in the accuracy of the check itself.
What Fraud Risks Does Confirmation of Payee Actually Address?
Confirmation of Payee SEPA exists mainly to counter one specific fraud pattern: invoice redirection, also called authorized push payment fraud, where a criminal intercepts or spoofs an invoice and swaps in their own account details. Without a name check, the payment clears because the IBAN is technically valid, it's just valid for the wrong person.
VoP closes part of that gap by forcing a name comparison at the moment of payment, not after. A No match or Close match response gives the payer a last chance to catch a swapped account before funds leave. That's meaningfully different from post-transaction fraud monitoring, which can flag suspicious activity but usually can't claw back money that's already moved through a mule account chain.
It's not a complete fix. VoP doesn't verify that the person requesting payment is who they claim to be, only that the name and IBAN pair match a bank's records. A sophisticated fraud operation that opens an account in a name matching a targeted supplier will still pass the check cleanly. That's why the EPC frames VoP as a valuable addition to the payment order rather than a standalone fraud solution, useful layered alongside sanctions screening, transaction monitoring, and supplier verification at onboarding.
The security value also depends on payer behavior. A Close match that gets clicked through without reading the matched name defeats the entire purpose. Any rollout plan needs to treat the human decision point at Close match as seriously as the technical check itself, since that's where most of the real-world fraud prevention actually happens or doesn't.
What GDPR Rules Apply to Payee Name Checks?
Verification of Payee moves personal data, specifically a payee's name, between two banks, which puts it squarely inside GDPR's scope. The EPC's scheme design deliberately limits what gets disclosed: a matched name is only returned on a Close match result, not on every check, and the raw comparison logic stays inside the responding bank rather than exposing full account-holder details to the requesting side.
That minimal-disclosure design isn't accidental. It reflects data protection's core principle that only the information necessary for the stated purpose should move at all. A bank running VoP checks needs a documented legal basis, typically legitimate interest or contractual necessity tied to payment execution, and needs to be able to explain to a data subject why their name was shared with another institution during a transaction they may not have even known was happening.
Retention is the part compliance teams underestimate. Logging every VoP request and response for audit purposes is good practice, but that log itself becomes personal data subject to GDPR's storage limitation principle. A retention policy that keeps verification logs indefinitely "just in case" creates its own compliance exposure separate from the payment itself.
Cross-border SEPA transfers add another layer, since the requesting and responding PSPs may sit in different EU member states with slightly different national interpretations of data protection obligations around financial data sharing. Building a VoP integration with a single, well-documented data flow diagram, showing exactly what moves, when, and why, makes it far easier to answer a regulator's question later than trying to reconstruct the logic after the fact.
How Do Cross-Border SEPA Payments Change VoP Requirements?
SEPA's whole premise is that a euro payment from Ireland to Estonia should work the same as one from Dublin to Cork, and VoP is designed to hold that promise together across borders. The EDS directory and shared API specification exist precisely so a French bank doesn't need a bespoke integration with every other SEPA-participating bank individually.
In practice, cross-border checks still surface friction points domestic-only rollouts don't. Character encoding is a real issue: a payee name with diacritics common in one country's records can render differently in another bank's system, occasionally tipping a true match into a false Close match. Response latency also compounds slightly on cross-border checks simply because more network hops sit between requesting and responding PSPs, which is exactly why the scheme specifies a maximum execution time rather than leaving timeout behavior to each bank's discretion.
The non-euro deadline split adds a practical wrinkle for cross-border flows involving PSPs outside the eurozone. A payment from a euro-area account to a non-euro SEPA country may involve a responding bank operating under a different compliance timeline, which is part of why the July 9, 2027 date for some non-euro obligations matters beyond just that PSP's own domestic operations. Treasury teams running international payment corridors should map which counterparty banks fall under which deadline, rather than assuming uniform VoP support across every SEPA country from day one.
What Happens When a Payee Verification Result Is Wrong?
A wrong result usually falls into one of two categories: a false No match on a legitimate, correctly entered payee, or a false Match that let a fraudulent account slip through despite a name mismatch that should have been caught. Both need a defined resolution path, not an improvised one.
For a suspected false No match, the first step is checking the exact string entered against the supplier's registered legal name, since minor formatting differences (a missing legal suffix, an abbreviated first name) account for a large share of disputed results. If the name is confirmed correct and the mismatch persists, the payer's PSP can raise the discrepancy with the responding PSP through the scheme's established inter-bank channels rather than the payer contacting the receiving bank directly.
A false Match is more serious, since it typically means the underlying account data itself is wrong, not the comparison logic. That scenario belongs with the responding bank's account data team, and depending on the amount involved, may also trigger a fraud investigation if a mismatch was overridden or ignored during the payment.
Documentation is what turns a dispute into a resolvable case rather than a standoff. Keeping the original request payload, the response payload including any reason codes, and a timestamp of the payer's decision gives both sides something concrete to work from instead of relying on memory or reconstructed logs weeks after the fact.
Where Should Compliance Teams Focus First?
Data hygiene beats API sophistication every time. A perfectly built integration returning accurate results against a stale supplier database still produces bad outcomes, so cleaning and bulk-verifying supplier records before go-live should come before any UX polish.
Design the Match experience to be nearly invisible and the Close match experience to demand a real decision, not a reflexive click. Track mismatch rates by counterparty bank from day one, since a spike there often signals a data issue worth fixing rather than a fluke. And build in the assumption that the rulebook will change again after 2026's v1.1 update. It already has once.
— David
Get SEPA Payee Verification Running Without the Integration Headache
Vopify gives you the same instant name-and-IBAN check the EU mandate requires, without months spent building direct EDS connectivity or managing your own certificate infrastructure. You get results with just a name and an IBAN, whether you're checking a single payment before it goes out or running an entire supplier file through a bulk CSV upload ahead of a payment cycle.
Coverage currently spans 20 Eurozone countries with sub-two-second response times, and API access is planned for finance teams that want verification embedded directly into their existing payment workflow rather than run as a separate step. If your accounts payable team is still manually double-checking supplier bank details or waiting on a slow legacy verification contract, try Vopify on your next payment run and see how a check clears in under two seconds.
This article is general information, not a substitute for advice from a qualified financial advisor. Consult a qualified financial professional about your own circumstances before acting on anything here.
FAQ
How Does Confirmation of Payee Work?
The payer's bank sends the entered IBAN and payee name to the account-holding bank, which checks both against its records and returns a Match, No match, Close match, or verification-not-possible response before the transfer completes.
Is SEPA the Same as a Bank Transfer?
No. SEPA is a payment scheme that standardizes euro transfers across participating European countries, while a bank transfer is the general act of moving money between accounts, which SEPA rules govern for euro-denominated payments within its zone.
How Do I Track a SEPA Transfer?
Most banks provide a transaction reference or SEPA payment status through online banking, and instant SEPA transfers typically settle within seconds, while standard SEPA Credit Transfers usually settle within one business day.
Which Banks Use Confirmation of Payee?
Under the Instant Payments Regulation, every PSP offering SEPA Credit Transfers or SEPA Instant Credit Transfers must offer VoP checks as of October 9, 2025, so coverage spans essentially all participating SEPA banks rather than a select few.
Can a Vendor Like Vopify Handle VoP-Style Checks Outside My Bank's System?
Yes. Tools like Vopify perform the same instant name-and-IBAN comparison independently of your bank's own VoP rollout, which is useful for accounts payable teams verifying suppliers before initiating a payment rather than waiting on the receiving bank's response.