Verification of Payee (VoP): Everything you need to know

Verification of Payee (VoP) is the new mandatory standard for SEPA payments in Europe. Whether you are a finance team or a software editor looking to stay ahead of the curve, this guide covers everything from the basics to the technical details, including why integrating a VoP API into your product is one of the smartest moves you can make right now.

What problem does VoP solve?

Every year, billions of euros disappear from European businesses and individuals through a deceptively simple fraud: the wrong IBAN.

An invoice arrives with a bank account number that has been quietly replaced by a fraudster. A supplier update comes in through a compromised email. A finance team, under pressure, processes the payment without a second thought. The money leaves the account… and it’s gone.

This type of fraud goes by many names (‘Business Email Compromise’, invoice fraud, ‘Authorised Push Payment’ (aka APP) fraud…) but it always works the same way: the payer is tricked into voluntarily sending money to an account they believe belongs to someone they trust. Unlike card fraud, which banks can often reverse, push payment fraud is extraordinarily difficult to recover from once it’s executed.

Until recently, there was no standardized mechanism to prevent it at scale. Banks processed payments based on the IBAN alone. The account holder’s name? Purely informational. It was checked by no one. Verification of Payee changes that.

What is Verification of Payee?

Verification of Payee (VoP) is a real-time check that confirms whether the name you have provided for a payee actually matches the name registered at their bank for the given IBAN.

Put simply: before the money moves, VoP answers the question “does this name and IBAN actually belong together?”

The service returns one of four standardized results:

Result	What it means
Match	The name and IBAN belong together. You’re good to go!
Close match	A minor difference was detected: a typo, an abbreviation, an alias… Worth a second look.
No match	The details don’t correspond. Something is wrong.
Not applicable	Verification is not available for this account (e.g., the payee’s bank is not yet connected to the scheme)

The check happens in milliseconds, before the payment is initiated. For the end user, it’s invisible (unless there’s a problem worth flagging).

How does VoP work?

The VoP process follows a clean four-step flow:

Your system sends a request
You provide two pieces of information: the payee’s IBAN, and either their name or a recognized business identifier (VAT number, LEI, company registration number, etc.).
The request is routed
The VoP provider routes the request to the correct financial institution via what’s called a Routing & Verification Mechanism (RVM). This routing uses the EPC Directory Service (EDS) to identify which bank holds the IBAN.
The bank performs the check
The financial institution that issued the IBAN compares the provided name or identifier against the actual account holder on record.
You receive a response
Within milliseconds, you get a structured response: the match result, the name of the verifying institution, its BIC and a unique request ID for audit purposes.

The key point here is that the verification happens at the source, at the actual bank holding the account. This isn’t a third-party database cross-check: it’s a direct query to the institution that knows the ground truth.

Bring instant trust with VoP

Verification of Payee is now mandatory across the eurozone. Digiteal’s API confirms in real time that a name and IBAN belong together, before the money leaves.

Discover our VoP API → Talk to our team →

VoP vs Confirmation of Payee: what’s the difference?

If you’ve been following payment industry news, you may have already heard of Confirmation of Payee (CoP), the UK equivalent of VoP. They are cousins: same fundamental purpose but different regulatory frameworks.

Confirmation of Payee (CoP) was introduced in the UK starting in 2020, under the Payment Systems Regulator (PSR). It covers payments through Faster Payments and CHAPS. The UK has been a pioneer in this space, and the results have been measurable: participating banks reported significant reductions in APP fraud in the years following implementation.

Verification of Payee (VoP) is the European version, governed by the European Payments Council (EPC) under its VoP Rulebook. It covers SEPA Credit Transfers (SCT) and SEPA Instant Credit Transfers (SCT Inst), and became mandatory across the eurozone in October 2025.

Beyond these two, SWIFT also operates pre-validation services for cross-border payments but VoP’s scope within SEPA is distinct and regulation-driven.

The broader lesson is clear: across the globe, regulators are moving in the same direction. Account name verification before payment execution is becoming a universal expectation.

The regulation that makes VoP mandatory

Regulation (EU) 2024/886, commonly referred to as the Instant Payments Regulation (IPR), requires all Payment Service Providers (PSPs) operating in the EU to provide Verification of Payee for both SEPA Credit Transfers and SEPA Instant Credit Transfers.

This means:

As a PSP, you must be able to both send VoP requests (on behalf of your customers initiating payments) and respond to VoP requests (when someone is trying to pay one of your account holders)
The check must be performed before any credit transfer is executed (not after)
The regulation applies regardless of whether the transfer is standard or instant.
As an initiating PSP, If you do not perform a VoP check or if you do not present a warning to your customer in case of doubt prior to the payment, you are liable for the fraud you will need to pay back your customer.

The EPC has published the technical VoP Rulebook that defines the scheme rules, the supported data formats, the accepted match results and the obligations of each participant. Compliance with the EPC scheme is what gives a VoP implementation its legal and technical validity.

Which countries are affected, and when?

The rollout happens in two waves, based on currency.

Wave 1: Eurozone countries (20 member states, deadline October 9, 2025)

Austria, Belgium, Cyprus, Germany, Estonia, Spain, Finland, France, Greece, Croatia, Ireland, Italy, Lithuania, Luxembourg, Latvia, Malta, Netherlands, Portugal, Slovenia, Slovakia.

Wave 2: EU member states with non-euro currencies (7 countries, deadline July 9, 2027)

Bulgaria, Czech Republic, Denmark, Hungary, Poland, Romania, Sweden.

Beyond the EU (other SEPA countries)

Countries like the United Kingdom, Switzerland, Norway, Iceland and Liechtenstein are within the EPC VoP scheme’s scope but are not bound by the EU regulation’s deadlines. Their adoption depends on local legislation and whether their PSPs adhere voluntarily to the EPC VoP Rulebook.

In practical terms: if your business, your customers or your software users touch any payment going to or from a eurozone account, VoP is already live and mandatory.

VoP: the business benefits

Regulatory compliance is the reason VoP exists but it’s not the only reason to implement it.

1. Preventing the three most damaging payment fraud types

Business Email Compromise (BEC) and invoice fraud

A fraudster intercepts or spoofs a supplier’s email and sends a “updated payment details” message. Your finance team updates the IBAN in your system. With VoP, that update triggers an immediate check: the new IBAN doesn’t match the supplier’s registered name, and the fraud is stopped before any money moves.

Human error and misdirected payments

Not every wrong payment is fraud. IBANs are long, complex strings. Transposition errors happen. VoP catches these too: a close match or no match result before payment initiation saves the cost and embarrassment of chasing a misdirected transfer.

Social engineering targeting finance teams

Impersonation fraud (where someone poses as a CEO, a supplier or a tax authority and requests an urgent payment) becomes far harder to execute when the IBAN they provide doesn’t match the name they claim. VoP introduces an objective, automated check that human judgment alone cannot replicate under pressure.

2. Operational efficiency gains

Beyond fraud prevention, VoP reduces the volume of rejected payments, exceptions and manual investigations that cost finance teams time and money. Fewer returned payments, fewer reconciliation headaches, fewer apologetic calls to suppliers.

For teams processing large volumes of payments (accounts payable, payroll, treasury…), the cumulative benefit of verifying IBANs before they enter the system (rather than chasing errors after) is substantial.

3. A signal of trust and professionalism

Companies that build VoP into their payment processes (and software editors that offer it natively to their users) are sending a clear signal: they take payment security seriously. In a market where finance teams are increasingly sensitized to fraud risk, this matters. It builds trust with customers, with auditors and with the banks that are looking for reliable payment partners.

For software editors: why integrate a VoP API?

If you build software that touches payments, bank accounts or supplier data, VoP is not someone else’s problem: it’s yours.

Think about where IBANs enter your system:

A new supplier is onboarded in your ERP or accounts payable platform
An employee’s salary account is updated in your payroll software
A customer provides their bank details for a SEPA Direct Debit mandate
A refund or reimbursement is initiated through your platform
A payment file is prepared and exported to the bank

Every one of these is a moment where a wrong IBAN (fraudulent or accidental) can enter the system. And every one of these is a moment where a VoP check can prevent it.

Your users (finance teams, accountants, treasury managers) are not expecting to manually verify IBANs. They are trusting your software to help them work securely. Integrating VoP means your product does what they need it to do, at the right moment, without adding friction.

The value proposition for software editors is threefold:

Regulatory pull: your PSP and banking customers are already required to support VoP. If your software feeds their payment flows, you are part of that secure chain.
Commercial differentiation: offering native VoP verification is a genuine product differentiator, a feature that finance buyers will increasingly ask about.
Liability reduction: in the event of a fraud incident, the question will be asked: “Could your software have flagged this?” An integrated VoP check is the answer.

Q&A: Everything software editors ask about VoP integration

What types of software are directly in scope?

Any software that collects, stores or processes IBANs in a payment context is relevant.

The most common categories are:

ERP systems: supplier master data, payment runs
Accounts payable / P2P platforms: invoice processing, payment approval workflows
Payroll software: employee bank account management
Treasury management systems: bank account repositories, payment initiation
E-invoicing platforms: supplier portals, remittance management
Subscription and SaaS billing: SEPA Direct Debit mandate creation
Marketplace and payout platforms: seller disbursements, affiliate payments

If your product has a field that says “IBAN”, VoP has a use case.

My software doesn’t initiate payments directly. Does VoP still apply?

Yes, and this is an important point to understand. VoP’s value isn’t only at the moment of payment execution. It’s equally valuable when an IBAN first enters your system.

If your software stores a supplier IBAN, an employee’s bank account or a customer’s mandate details, you are the first line of defense. By the time a payment is initiated (whether by your software or by an external bank), the IBAN is already in the system, often trusted implicitly.

Integrating VoP at the onboarding and data-capture stage means you are catching fraudulent or incorrect IBANs before they become problems, not after.

What data is needed to make a VoP request?

A VoP request requires two pieces of information:

1. The payee’s IBAN

The bank account number that will receive the payment.

2. A verification reference

Either:

The payee’s name (individual’s full name or company name)
Or a recognized business identifier, such as:
- VAT number (TXID)
- Legal Entity Identifier (LEI)
- Bank Identifier Code (BIC)
- SIREN / SIRET (France)
- Certificate of Incorporation Number
- D-U-N-S number

Name-based verification is the most widely supported and recommended approach. Identifier-based verification can be useful when the exact name is uncertain (for example, when onboarding a new B2B supplier using their VAT number as the primary reference).

What does the API response look like in practice?

Here is a simplified example of what a VoP API call and response look like with Digiteal’s API:


Request:

```bash
POST /api/v1/ibanAccountHolderVerification
{
"iban": "BE03130000000184",
"name": "Digiteal SA"
}
```
Response — Match:
```json
{
"vopMatchResult": { "result": "MATCH" },
"bankAccountHolder": { "name": "Digiteal SA" },
"bank": { "bic": "DIGEBEB2", "name": "DIGITEAL SA" }
}
```
Response — Close match (name provided: "Digiteal", missing the "SA" suffix):
```json
{
"vopMatchResult": { "result": "CLOSE_MATCH" },
"bankAccountHolder": { "name": "Digiteal SA" },
"bank": { "bic": "DIGEBEB2", "name": "DIGITEAL SA" }
}
```
Response — No match (name provided: "John Doe"):
```json
{
"vopMatchResult": { "result": "NO_MATCH" },
"bank": { "bic": "DIGEBEB2", "name": "DIGITEAL SA" }
}
```

Each response also includes a timestamp and a unique ‘request-id’ in the response headers for audit trail purposes.

How should we handle each response in our UX?

The recommended approach balances security with usability. VoP is designed to inform, not to automatically block.

Result	Recommended UX pattern
MATCH	Proceed automatically: no friction needed.
CLOSE_MATCH	Display a warning with the discrepancy. Ask the user to confirm or review before proceeding.
NO_MATCH	Block the action or require mandatory manual review, and clearly explain why.
NO_AP	Note that verification was not possible for this account. Apply alternative verification methods if available.

A critical design principle: never block silently and never scare unnecessarily. A close match on a company name (because a user typed “Acme Corp” instead of “Acme Corporation”) is not a fraud signal. It’s an invitation to review. Your UX should make that distinction clear.

Equally important: always log the VoP result, even when the payment proceeds. This creates an audit trail that demonstrates due diligence, which becomes critical in the event of a dispute or investigation.

How does VoP handle approximate names, abbreviations and special characters?

This is where the intelligence of a good VoP implementation shows.

The matching algorithm at the issuing bank’s side handles a range of common variations:

Legal form abbreviations (“SA”, “SRL”, “GmbH”, “Ltd”) that may be present or absent
Common typos and transposition errors
Accented characters and their unaccented equivalents
Trade names vs. legal names (depending on what the bank has on record)
First name / last name inversion for individuals

When such a variation is detected, the response is `CLOSE_MATCH` rather than `MATCH`, allowing your system to surface the discrepancy to a human reviewer rather than blocking outright.

A practical note: the quality of your outbound data matters. If your supplier master data is poorly maintained (truncated names, old trade names, missing legal suffixe…), you will see more close matches than necessary. VoP integration is also an opportunity to review and clean your reference data.

Can we verify an entire supplier database in bulk?

Yes. Bulk verification is one of the most powerful use cases for software editors.

The typical scenario: a company has thousands of IBANs stored in their ERP or accounts payable platform. They have never been systematically verified. Integrating a VoP API allows you to offer a one-time (or periodic) bulk check of the entire database, flagging suspect records before they ever reach a payment run.

Practical considerations for bulk verification:

The payment intent principle still applies. Bulk checks are typically justified as a risk management exercise in the context of upcoming payment operations.
Rate limits and volume pricing should be discussed with your VoP provider.
The output of a bulk check should feed a review workflow, not trigger automatic deletions. Human judgment is still needed for edge cases.

This is a particularly compelling feature for ERP vendors and accounts payable platforms, where a “clean your supplier bank data” workflow can be a premium offering in its own right.

What is the geographic coverage? What about IBANs outside the eurozone?

As of October 2025, VoP is operational for eurozone IBANs (the 20 EU member states whose currency is the euro). This covers the vast majority of SEPA payment volume.

For IBANs from non-euro EU member states (Poland, Denmark, Czech Republic, etc.), mandatory compliance comes in July 2027, but some banks in these countries may already support VoP.

For IBANs from non-EU SEPA countries (UK, Switzerland, Norway, etc.), availability depends on the individual bank’s participation in the EPC VoP scheme.

When a VoP check is requested for an IBAN whose issuing bank is not yet connected to the scheme, the response will be ‘NO_AP’ (not applicable). Your system should handle this gracefully (it doesn’t mean the payment is suspect, it means verification is currently unavailable for that account).

How long does integration take? What’s the real technical effort?

The short answer: a few days maximum.

Digiteal’s VoP API is a simple REST/JSON interface with Basic Authentication. The core integration (a single POST endpoint) can be implemented in any modern development stack.

SDKs are available for Java, .NET, Python, and PHP, among others.

What makes VoP complex to build from scratch is not the API call itself. It’s everything around it: registering with the EPC scheme and the EDS Directory Service, implementing the RVM routing logic to find the right bank for any given IBAN, staying compliant with the EPC VoP Rulebook as it evolves, submitting quarterly statistical reports to the EPC, managing the certification and conformance testing process…

By integrating Digiteal’s API, you get all of that handled for you. Your engineering team writes the API call and the UX logic. We handle the regulatory plumbing.

A sandbox environment is available from day one for integration testing. The path to production is straightforward, with dedicated developer support.

What’s the business model? Can we monetize this for our own clients?

VoP integration can be structured in several ways depending on your product model:

As an included feature: you absorb the API cost and position VoP as a trust-and-security feature included in your standard offering. This strengthens your product’s competitive position and can reduce churn by making your platform stickier for finance-sensitive customers.
As a premium module: you offer VoP as an optional add-on for customers who want enhanced payment security. This is particularly relevant for ERP and AP platform vendors whose enterprise clients are under pressure from their own compliance and risk teams.
As a usage-based feature: for platforms with variable payment volumes (marketplaces, payroll providers, payout platforms), per-verification pricing can be passed through to clients, with or without a markup.

The ROI calculation is straightforward: a single prevented fraudulent transfer (typically worth tens of thousands of euros) covers years of VoP API costs. When you frame it that way in a conversation with a CFO, the question stops being “is this worth it?” and starts being “why haven’t we done this already?”

How Digiteal’s VoP API works

Digiteal is a payment institution certified by the National Bank of Belgium and ISO/IEC 27001:2022 certified for information security management.

Our VoP service is compliant with the European Payments Council (EPC) VoP Rulebook and operates on a live production environment with an SLA-backed uptime guarantee.

The verification flow

1
API call
Your system calls our REST API with the payee’s name (or identifier) and IBAN.
2
Request routing
Digiteal routes the request to the relevant financial institution via the Routing & Verification Mechanism (RVM).
3
Bank verification
The issuing bank performs the verification against their account holder records.
4
Instant response
You receive a response within milliseconds: Match / Close Match / No Match / Not Applicable, plus the verifying bank’s BIC, name and a unique request reference.

Four integration points in your payment lifecycle

During onboarding or data capture
Validate IBAN ownership the moment a supplier, customer or employee provides their account details. Prevent incorrect or fraudulent data from entering your system in the first place.
Before payment initiation
Execute a final check before releasing funds (especially important for high-value transfers, bulk payment runs, or updated beneficiary details).
As a regulatory control layer
For regulated entities, automatic compliance with the IPR. For non-regulated entities, voluntary adoption of bank-grade verification standards that demonstrate due diligence.
Within automated decision flows
Build intelligent payment workflows: Match → proceed automatically. Close Match → apply internal review rules. No Match → block and escalate. No AP → log and apply alternative controls.

Ready to integrate Verification of Payee?

Contact our team via the contact form on our website to request access to the sandbox environment, receive your API credentials, and discuss your integration requirements.