You type in an IBAN, hit send, and the money moves. For decades, that has been the entire trust model behind a bank transfer: if the account number is valid, the payment goes through, regardless of whether the name on the screen matches the name on the account. Fraudsters have built an entire industry around that gap. Verification of Payee closes it — not by making transfers slower, but by making them honest about who is actually going to receive the money before you commit to sending it.
Since October 2025, every payment service provider (PSP) in the Eurozone has been legally required to offer this check on euro credit transfers. It's one of the more consequential, least glamorous fraud-prevention mandates to hit European banking in years, and it's a useful case study in how regulation can fix a structural flaw that market incentives alone never would.
What Verification of Payee Actually Does
Verification of Payee (VoP) is a real-time check that compares the name a payer enters for a beneficiary against the name actually registered on the account tied to the IBAN they're sending to. Before the payment is authorized, the payer's bank queries the receiving bank (or a shared directory) and gets back one of three answers:
- Match — the name and IBAN correspond exactly. Proceed with confidence.
- Close match — the name is similar but not identical (a misspelling, a maiden name, a shortened first name). The payer sees a warning and the actual registered name, and decides whether to continue.
- No match — the name and IBAN do not correspond at all. The payer is warned in strong terms before they can proceed.
Crucially, VoP is advisory, not blocking. The payer can still choose to send the money even after a "no match" warning — this isn't a system that freezes transactions unilaterally, because there are legitimate reasons a name might not match (a business account registered under a different legal name than its trading name, for instance). What VoP does is remove the single biggest structural excuse fraud has relied on: that ordinary people had no way to check who they were really paying.
The Technical Plumbing
Under the hood, VoP relies on each PSP exposing an API that other PSPs (or a centralized directory, depending on the national implementation) can query in near real time — typically within a couple of seconds, so the check doesn't meaningfully slow down an instant payment. The European Payments Council standardized the scheme rulebook that defines the message formats, the matching logic, and the fallback behavior when a receiving bank's system is unreachable. Name matching uses fuzzy-matching algorithms tuned to tolerate legitimate variation (diacritics, transliteration, word order) while still flagging materially different names.
This is not a new idea globally. The UK ran a similar system called Confirmation of Payee starting in 2020, and it's the closest real-world precedent for what the EU is now doing at Eurozone scale.
Why This Matters Right Now
The reason VoP is suddenly a live topic rather than a theoretical proposal is straightforward: it became mandatory. Under the EU's Instant Payments Regulation, all Eurozone payment service providers have been required to offer Verification of Payee on euro-denominated credit transfers since October 2025. This wasn't optional guidance or a best-practice recommendation — it's a binding regulatory requirement tied to the broader push to make instant SEPA credit transfers as safe as, or safer than, traditional transfers that take a day or more to settle.
That linkage matters. The same regulation that forces PSPs to offer instant transfers around the clock, 365 days a year, also forces them to offer this verification step. Regulators understood that speeding up payments without addressing the verification gap would have made fraud easier, not harder — an instant transfer to a fraudulent account is money that's gone in seconds, with none of the settlement delay that sometimes gives banks a window to intervene. VoP is the safety mechanism that had to arrive alongside instant payments, not after them.
Why the Old System Was So Exploitable
To understand why this mandate exists, it helps to look at what it replaces. In the traditional SEPA credit transfer model, the account number (IBAN) is the only field that actually matters for routing. The beneficiary name field is effectively decorative — most banks never validated it against the account holder of record. This is precisely the mechanism behind authorised push payment (APP) fraud, one of the fastest-growing fraud categories in Europe over the past several years.
A typical scam plays out like this:
- A fraudster impersonates a supplier, a landlord, a tax authority, or even a close contact via a compromised or spoofed communication channel.
- They provide a legitimate-looking invoice or payment request with a name the victim recognizes, paired with an IBAN the fraudster actually controls.
- The victim, seeing a familiar name on the request, initiates the transfer.
- Because the bank never checks whether that name matches the account, the payment lands in the fraudster's account regardless of the mismatch.
- By the time the fraud is discovered, the money has often already been moved onward or withdrawn.
The victim authorized the payment themselves, which historically made these cases much harder to get reimbursed than traditional unauthorized fraud (like a stolen card), since banks and regulators treated "the customer chose to send this money" as a mitigating factor for liability. VoP attacks the weak link directly: it makes the mismatch visible to the payer at the one moment it actually matters, before the money leaves.
What This Means for Businesses
For banks, fintechs, and payment providers, VoP is not a feature to bolt on — it's core infrastructure that touches onboarding, payment initiation flows, customer support, and compliance reporting simultaneously.
For Payment Service Providers
PSPs face both a build challenge and an operational one. On the build side, they need to expose a query-able directory of their own account holders' names (in a privacy-conscious, minimized form) and consume other PSPs' equivalent services in real time. On the operational side, they need to handle a wave of "close match" and "no match" results that will initially be noisy — common causes include recently changed names, joint accounts registered under one holder's name, and businesses that trade under a different name than their legal registration.
| Challenge | What it involves |
|---|---|
| API integration | Real-time query/response with other Eurozone PSPs or a shared directory, within a couple of seconds |
| Name-matching tuning | Balancing false positives (legitimate payees flagged as mismatches) against false negatives (fraud that slips through) |
| UX for warnings | Presenting "no match" and "close match" results clearly without training users to click through every warning out of habit |
| Data accuracy | Keeping registered account-holder names current, including trading names and recently updated details |
| Fraud team workload | Investigating patterns in mismatch data, which becomes a new fraud-signal source |
| Regulatory reporting | Demonstrating compliance with the Instant Payments Regulation's VoP provisions |
For Businesses Receiving Payments
If your company's legal name on file with your bank doesn't match what you put on invoices, customer purchase orders, or your own branding, you're about to generate a steady stream of "no match" warnings for every customer trying to pay you — even though nothing fraudulent is happening. This is a genuinely practical, non-theoretical risk: businesses that trade under a brand name different from their registered legal entity name should expect friction and should proactively communicate the discrepancy to customers, or update records where possible, rather than let confused payers second-guess a legitimate invoice.
For Everyone Sending Money
The practical shift for an ordinary payer is small but meaningful: when you add a new beneficiary or make a payment, you'll now sometimes see a warning that the name doesn't match. The correct response is to stop and verify through an independent channel — call the supplier on a known number, check with the person directly — not to dismiss the warning because you're in a hurry. Fraudsters will adapt their scripts to specifically coach victims to ignore VoP warnings ("that's just a technical glitch, please proceed anyway"), so the human element of skepticism doesn't disappear just because the technology exists.
Real Limitations and Open Questions
VoP is a meaningful improvement, not a solved problem. Several limitations are worth understanding clearly:
- It's advisory, not preventive. A payer who ignores a "no match" warning can still send the money, and social engineering will specifically target that override. VoP reduces the fraud that happens through simple oversight; it does less against fraud that involves actively coaching the victim through the warning.
- It covers euro credit transfers within the mandate's scope, not every payment rail. Card payments, direct debits, and transfers outside the covered scheme aren't addressed by this specific mechanism.
- Cross-border and non-Eurozone gaps remain. The mandate is anchored in Eurozone PSPs; payments involving providers outside that scope may not have the same guarantee, which matters for businesses with international payment flows.
- Name-matching is inherently imperfect. Legal names, trading names, transliterated names, and recently changed names all create legitimate mismatches that dilute the signal and risk desensitizing users to warnings over time.
- Liability questions are still being worked out. Regulators and industry bodies are still clarifying exactly how liability shifts when a PSP fails to implement VoP correctly, or when a payer proceeds despite a clear warning — this is an evolving area rather than a fully settled one.
- It doesn't address invoice or communication compromise itself. VoP catches the moment where the name and IBAN diverge; it doesn't prevent the initial impersonation, phishing, or business email compromise that put the fraudulent IBAN in front of the victim in the first place.
How Verification of Payee Compares to Other Fraud Defenses
VoP doesn't operate alone — it sits alongside a handful of other mechanisms banks use to control payment risk, each catching a different kind of problem. Understanding where it fits helps explain why regulators added it rather than assuming existing tools already covered the gap.
| Mechanism | What it checks | What it misses |
|---|---|---|
| Verification of Payee | Does the beneficiary name match the account holder registered to that IBAN? | Whether the payment itself is legitimate — a matched name can still be a scammer's own account |
| Strong Customer Authentication (2FA) | Is the person initiating the payment actually the account owner? | Whether the payee they're sending to is who they claim to be |
| Sanctions and AML screening | Is either party on a watchlist or exhibiting laundering patterns? | Ordinary social-engineering fraud between two clean accounts |
| Transaction monitoring / anomaly detection | Does this payment deviate from the customer's normal behavior? | New relationships and first-time payments, which look "normal" by definition since there's no history to compare against |
| Card CVV / 3-D Secure | Is the card being used by someone who has physical or digital access to it? | Doesn't apply to bank transfers at all — different rail entirely |
The pattern is clear: each layer answers a narrow, specific question, and none of the pre-existing layers answered "does this name actually belong to this account?" That's precisely the blind spot VoP was built to close, and it's also why VoP is additive rather than redundant — it doesn't replace authentication or monitoring, it fills a hole those systems structurally couldn't see.
A Brief History of How We Got Here
The gap VoP addresses isn't a recent discovery. Banking-sector fraud analysts and consumer advocates flagged the "IBAN is king, name is decorative" problem for years before any jurisdiction acted on it. The UK moved first with Confirmation of Payee, driven largely by rising APP fraud losses that were increasingly difficult to attribute to any single point of failure other than the absence of a name check. That scheme became the reference implementation the rest of Europe watched.
The EU's path took longer, partly because coordinating a shared verification mechanism across dozens of national banking systems, currencies, and legacy core-banking platforms is a materially harder engineering and legal problem than rolling it out within a single national banking sector. The breakthrough came when VoP was folded into the Instant Payments Regulation rather than treated as a standalone fraud initiative. That bundling was strategic: it meant PSPs couldn't be seen as merely inconveniencing customers with a new warning screen — VoP became the necessary counterweight to a payments product (instant, always-on transfers) that regulators were simultaneously requiring banks to offer. Selling "faster payments" without "safer payments" alongside it would have been an obviously incomplete mandate, and regulators structured the rules so the two shipped together.
What to Watch Next
A few threads are worth tracking as VoP implementation matures across the Eurozone:
- Fraud data over the first full year. Regulators and banking associations will publish figures on how much APP fraud VoP actually prevented versus cases where warnings were overridden — this will shape whether the advisory-only model holds or gets tightened.
- Convergence with the UK's Confirmation of Payee. As both systems mature in parallel, expect pressure toward interoperability standards for payments that cross the two regimes.
- Expansion beyond the Eurozone. Non-euro EU member states and other jurisdictions are watching this rollout closely as a template, and some form of extension or equivalent scheme outside the euro area is a plausible next step.
- Liability rule clarifications. Expect regulatory guidance to sharpen around who bears the loss when VoP fails technically versus when a payer knowingly overrides a warning.
- Vendor consolidation in the matching layer. A number of vendors are building shared directory and matching infrastructure so smaller PSPs don't each have to build bilateral integrations with every other bank — watch which of these becomes a de facto standard.
FAQ
Is Verification of Payee the same as Confirmation of Payee?
They're conceptually the same idea — checking a payee's name against their account before a transfer completes — but Confirmation of Payee is the UK's scheme, launched in 2020, while Verification of Payee is the EU's Eurozone-wide mandate under the Instant Payments Regulation, in force since October 2025. The mechanics are similar; the legal basis and geographic scope differ.
Does Verification of Payee block a payment if the name doesn't match?
No. VoP is advisory: it warns the payer that the name and IBAN don't correspond, but the payer can still choose to proceed. It's designed to give people the information they need to catch fraud themselves, not to unilaterally stop transfers.
Why would a legitimate payment show a "no match" warning?
Common causes include a business trading under a different name than its legal registration, a recently changed name that hasn't been updated with the bank, joint accounts registered under one person's name, or transliteration differences for non-Latin-script names. A mismatch is a prompt to verify, not proof of fraud.
Which payments does Verification of Payee cover?
It applies to euro-denominated credit transfers made by Eurozone payment service providers, as required under the EU's Instant Payments Regulation. It does not automatically cover card payments, direct debits, or transfers routed through providers outside that regulatory scope.
Can Verification of Payee stop all authorised push payment fraud?
No. It significantly reduces fraud that relies on victims not noticing a name mismatch, but it can't stop fraud where the scammer actively coaches the victim to override the warning, and it doesn't address the initial phishing or impersonation that leads to the fraudulent payment request in the first place.
Do I need to do anything as an individual to use Verification of Payee?
No action is required — the check runs automatically in the background when you make a covered transfer through your bank or payment app. Your only role is paying attention to the warning if one appears, rather than clicking through it out of habit.
What happens if my bank doesn't support Verification of Payee yet?
Since October 2025, all Eurozone PSPs are required to offer it on covered euro transfers, so a compliant bank should have it in place. If you notice it's missing, that's worth raising directly with your provider, since it may indicate a compliance gap or a payment type outside the mandate's current scope.
Teams building or integrating payment flows that need to handle VoP responses correctly — matching logic, warning UX, fraud-signal handling — can get hands-on help from Woyce Technologies.