What Is Verification of Payee? Europe's Front Line Against Fraud

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.

This guide explains how Verification of Payee works, why the old IBAN-only model was so easy to exploit, what the mandate means for banks, fintechs, and businesses that receive payments, and where its limits are. If you run payment flows or simply send invoices to European customers, the details affect you directly.

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 — the same kind of standardization work that ISO 20022 has done for payment messaging more broadly. 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, like other real-time payment rails emerging globally, 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:

1. A fraudster impersonates a supplier, a landlord, a tax authority, or even a close contact via a compromised or spoofed communication channel — sometimes reinforced with AI-cloned voice calls that make the impersonation more convincing.
2. They provide a legitimate-looking invoice or payment request with a name the victim recognizes, paired with an IBAN the fraudster actually controls.
3. The victim, seeing a familiar name on the request, initiates the transfer.
4. Because the bank never checks whether that name matches the account, the payment lands in the fraudster's account regardless of the mismatch.
5. 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.

Benefits of Verification of Payee

VoP is a small step in a payment flow, but it changes the information available to payers at the moment that matters most.

Mismatches Become Visible Before Money Moves

The core benefit is timing. Under the IBAN-only model, a payer had no way to know that the familiar name on an invoice belonged to someone else's account until after the money was gone. VoP surfaces that mismatch while the payer can still stop. Many scams depend on the victim never seeing that discrepancy, so simply showing it disrupts a large class of fraud without changing anything else about how transfers work.

Instant Payments Without a Bigger Fraud Window

Instant credit transfers settle in seconds and run around the clock, which removes the delay that sometimes let banks intervene in suspicious payments. VoP restores a checkpoint before the transfer instead of after it. That makes it possible to offer faster payments without making fraud proportionally easier, which is why regulators required the two together. Speed and safety arrive as one package.

Fewer Honest Mistakes

Not every misdirected payment is fraud. Typos in an IBAN or an outdated beneficiary record can send money to the wrong account. A close-match or no-match result prompts the payer to double-check before sending, reducing the time-consuming recovery process that follows a payment to an unintended recipient.

A New Fraud Signal for Banks

Each check produces an outcome, and payers' decisions to proceed or stop add context. PSPs can analyse patterns, such as repeated overrides of no-match warnings on payments to the same account, and feed them into fraud detection alongside existing monitoring. Accounts that keep receiving payments under names that don't match their holders become easier to identify and investigate.

More Confidence in Bank Transfers Overall

When payers know names are being checked, they can trust account-to-account payments for larger and first-time transactions more readily. For businesses collecting payments, that supports bank transfers as a lower-cost alternative to cards, provided their own account names are in order. Over time, that trust can shift more everyday commerce onto account-to-account rails, which suits businesses trying to reduce card acceptance costs.

Verification of Payee Use Cases

VoP runs on every covered transfer, but its value shows most clearly in a few situations where fraud and errors tend to concentrate.

Paying Supplier Invoices

Business email compromise often involves a fraudster intercepting or spoofing a supplier's email and sending an invoice with new bank details. A finance clerk enters the supplier's familiar name and the new IBAN, and under the old model the payment went through. With VoP, the clerk sees that the name doesn't match the account holder and can call the supplier on a known number before paying. The invoice redirection is caught at the point of payment instead of weeks later when the real supplier chases.

Adding a New Payee for a Large One-Off Payment

Property deposits, vehicle purchases, and tradesperson payments are often large, first-time transfers to someone the payer hasn't paid before. Fraudsters target these because transaction monitoring has no history to compare against. A VoP check gives the payer a way to confirm that the account belongs to the person or company they expect before sending money that would be hard to recover.

Updating Payroll and Supplier Records

When an employee or supplier asks to change their bank details, HR and finance teams can run the new details through a transfer flow that performs the name check and confirm the result before saving the change. That closes a route fraudsters use to divert salaries and recurring payments. Recording the result alongside the change request also creates an audit trail.

Collecting Payments as a Business

Businesses that receive bank transfers use VoP outcomes indirectly: if customers report warnings, the registered account name doesn't match what invoices show. Aligning names reduces payment delays and support queries, and it reassures customers that they're paying the right party. Collections speed up as a result.

Fraud Analytics at PSPs

Banks and payment providers analyse match outcomes and overrides across their customer base. Accounts receiving many payments with mismatched names, or patterns of overridden warnings, become leads for fraud teams and inputs for tuning matching thresholds. The same data helps refine warning copy where overrides are unusually common.

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.

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.

Common Verification of Payee Mistakes

The mandate is in force, but the way organisations implement and respond to it still varies. These mistakes undermine the protection it is meant to provide.

Clicking Through Warnings Out of Habit

Payers who see occasional false mismatches learn to dismiss every warning, including the one that signals real fraud. Fraudsters exploit this by telling victims in advance that a warning is a technical glitch. Every no-match result on a new or changed payee deserves independent verification through a known contact, not a quick override.

Leaving Trading and Legal Names Out of Sync

Businesses whose bank account is registered under a legal entity name, while invoices show a brand name, generate mismatch warnings for honest customers. That slows collections, creates support queries, and teaches customers to ignore warnings. Showing the exact registered account name on invoices, or updating records, removes the friction.

Tuning Matching Too Strictly or Too Loosely

PSPs that set fuzzy-matching thresholds too strictly flood users with false mismatches for diacritics, word order, or abbreviations, which erodes trust in the warnings. Thresholds that are too loose let materially different names pass. Matching needs testing against real name variation and ongoing adjustment based on outcomes.

Writing Vague Warning Copy

A generic message that doesn't show the registered name, or doesn't explain what to do next, leaves payers unsure whether to worry. Clear copy that displays the actual account name and tells the payer to verify through an independent channel turns the check into a useful decision point.

Assuming VoP Covers Every Payment

Treating VoP as complete protection leads teams to relax other controls. It doesn't cover card payments, direct debits, or rails outside the mandate, and it doesn't stop the phishing that delivers a fraudulent request. Approval workflows and staff training still matter. VoP is one layer of defence.

Verification of Payee Best Practices

Most of the work falls on PSPs, but businesses that receive payments have homework too. A practical sequence:

Step 1 – Audit the names your customers see

Compare the legal account-holder name your bank has on file with the name on your invoices, website, checkout pages, and email signatures. Any gap between a trading name and a registered legal name is a likely source of "close match" or "no match" results for your payers.

Step 2 – Align records or explain the difference

Where possible, update bank records or invoice templates so the names agree. Where they legitimately can't (a brand that trades under a different name than its holding company), print the exact registered account name on invoices so payers can enter it correctly the first time.

Step 3 – Prepare support for mismatch questions

Give finance and support teams a short script for customers who report a VoP warning. The answer should always point the customer to verify through an independent, known channel, never "just ignore it," because that is exactly the line fraudsters use.

Step 4 – For PSPs, treat mismatch data as a signal

Log match, close-match, and no-match outcomes alongside override decisions. Patterns in overridden warnings are a useful input for fraud teams and for tuning both matching thresholds and warning copy.

Step 5 – Design warnings people actually read

For PSPs and fintechs building payment flows, show the registered name returned by the check, explain in plain language what a mismatch means, and add friction proportional to the risk: a simple confirmation for a close match, a stronger interruption with an explicit prompt to verify independently for a no match. Avoid generic pop-ups that look like every other notice, because users learn to dismiss them.

Step 6 – Tighten internal controls on new and changed payees

Inside finance teams, require a second approver whenever a new beneficiary is added or an existing supplier's bank details change, and record the VoP result alongside the approval. Treat any request to change payment details that arrives by email as unverified until confirmed through a known phone number or contact.

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.

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 — echoing how instant payment systems are being interlinked globally more generally.
• 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. That design choice reflects the many legitimate reasons names differ, but it also means fraudsters will try to talk victims past the warning, so the payer's own skepticism still matters.

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. Confirm details with the recipient using contact information you already trust.

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. Businesses with mixed payment flows should check which of their rails are actually covered rather than assuming every transfer gets a name check.

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. If you see a "no match" result on a payment you weren't expecting to be unusual, pause and confirm the details with the recipient using contact information you already trust.

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.

Is Verification of Payee relevant to small businesses?

Yes, mostly on the receiving side. A small business whose bank account is registered under a legal name that differs from its trading name can trigger warnings every time a customer pays an invoice, which slows collections and makes customers nervous. The fix is usually cheap: show the exact registered account name on invoices, update bank records where the name is outdated, and tell regular payers about the change before they see a warning.

Conclusion

The weakness Verification of Payee fixes is simple: for decades, banks routed transfers on the IBAN alone and ignored the name, which let fraudsters pair a familiar name with an account they controlled. With instant payments making transfers irreversible within seconds, that gap became too expensive to leave open, so the EU tied the two mandates together.

VoP doesn't stop fraud on its own. It is advisory, it only covers euro credit transfers within the regulation's scope, and fuzzy name matching produces legitimate mismatches that can train users to click through warnings. Its value is that it puts the right information in front of the payer at the one moment it can change the outcome, and it gives PSPs a new fraud signal to work with.

For businesses, the practical takeaway is to get your own names in order so honest customers aren't scared off. For PSPs and fintechs, the harder work is matching quality, warning design, and feeding mismatch data into broader fraud detection.

If you're building payment flows that need to handle VoP responses cleanly, from API integration to warning UX, our API development team can help you scope and ship it.