Verification of Payee (VoP) One Year On: What It Changes for Your ERP Vendor Master Data

Since 9 October 2025, every SEPA credit transfer in euros sent from the euro area can be checked for a match between the payee’s name and their IBAN. A year later, Verification of Payee (VoP) is no longer a distant banking topic: it exposes, without mercy, the quality of the vendor master data in your ERP. This one-year review is for CFOs, treasurers and CIOs, and ends with an eight-point checklist.

Reminder: what the regulation requires and what applies

VoP comes from Regulation (EU) 2024/886, the Instant Payments Regulation that amends the SEPA Regulation. It requires payment service providers (PSPs) to offer a payee verification service for euro credit transfers, including standard transfers and not only instant ones. According to Deutsche Bank, the service applies from 9 October 2025 in the euro area, and the regulation requires it to be offered free of charge. The timeline for non-euro-area member states is staggered: if you pay suppliers outside the euro area, check with your banks which date applies to each country.

The technical framework rests on the European Payments Council (EPC) VoP scheme, which took effect in early October 2025 according to the information published by the EPC. The scheme defines the dialogue between the payer’s bank and the payee’s bank. For a company, what matters is what its bank sends back and what its ERP does with it.

Note that the text covers credit transfers, not direct debits or card payments. Your scope is therefore the outbound flow of euro transfers: suppliers, expense reports, payroll, customer refunds.

What the company sees: match, close match, no match

The payer’s bank receives one of four outcomes, described notably by Deutsche Bank:

• Match: the name provided corresponds to the account holder.
• Close match: the name is similar, and the bank gives the payer the actual account holder name.
• No match: the name differs from the one registered for that IBAN.
• Verification not possible: bank unavailable, account not found or technical outage.

A key governance point: on a “no match” or “close match”, the payer can still send the payment, but then bears the fraud risk, as the same source reminds us. This shift of liability turns every exception into a documented decision, and therefore into an audit topic.

Bulk payments and payment files

Companies rarely pay one item at a time. They send pain.001 files from the ERP or the treasury system. Two things to know:

• The opt-out: according to Deutsche Bank, corporates (not consumers) can opt out of VoP for bulk payment files. Zanders specifies that this option applies only to batches, not to a file containing a single payment, and that it must be agreed contractually with the bank.
• Returning the results: Zanders points to new ISO 20022 status codes (RCVC, RVCM, RVNA, RVNM, RVMC) that the bank must return. At Deutsche Bank, detailed results are available in a portal or in pain.002 v.10 depending on the channel.

Zanders also flags a timing constraint: for a file of 100,000 transactions, full verification would take on the order of 4 minutes, which has to be set against your payment cut-off times. The same article notes that, because exceptions could not be handled cleanly within the flows, CGI-MP initially recommended opting out of VoP for files. Opting out is possible, but it removes a free control against IBAN fraud: the question deserves an explicit decision, not a default you drift into.

ERP impacts: from master data to reconciliation

VoP compares a name and an IBAN. Your ERP must therefore supply a usable name next to every IBAN.

1. Quality of the vendor name. Many vendor records carry a trade name, an acronym or a legacy entry, whereas the bank compares against the account holder, often the legal entity name. Cleaning up the master data is the most rewarding workstream: legal name, account holder name, and a clear distinction between the two fields. If your ERP has a single “name” field, you may need to add an “account holder” field to the bank details record.

2. IBAN change workflow. A change of bank details must follow a dedicated path: logged request, independent check, approval by someone other than the person who enters the data. The ERP must prevent one user from creating the vendor, changing the IBAN and releasing the payment.

3. Dual approval. Above a threshold you set, a bank account change triggers a second approval. That threshold is a matter for your internal policy, not for the regulation.

4. History. For each IBAN, keep the creation date, author, approver, supporting document, date of last change, and the result of the latest VoP check if your bank returns it. This history helps in a fraud dispute, since liability depends on what was done at the time of payment.

5. Bank responses and reconciliation. Verification statuses come back through file responses. If your ERP or bank connector can only ingest a simple “accepted / rejected”, close matches will be invisible. Have your integrator map the statuses received into the payment log, and check what your vendor actually supports, based on its official documentation, before committing to a development. I cite no vendor feature here: coverage varies by version and bank connector, and it must be validated in your own test environment.

These workstreams extend the treasury work described in our SEPA Instant and ERP treasury module guide, notably on round-the-clock execution and payment data quality.

Supplier processes: close matches, exceptions, deadlines

The main risk is not technical, it is operational. When a payment comes back as a close match, someone has to decide quickly, with a clear rule.

A simple protocol works well:

• Close match on a known, stable supplier (legal form difference, abbreviation, accent): check the name given by the bank against the company registration extract, the contract or the invoice, then approval by a senior accounts payable clerk, with the vendor record updated.
• Close match on a recently changed IBAN: systematic escalation, call-back to the supplier on a number already on file, manager approval.
• No match: payment blocked by default. Released only after verification through an independent channel, with the decision documented.
• Verification not possible: treated as an unverified payment under internal policy, with enhanced control above a threshold.

On timing, an unhandled exception delays the payment. And late-payment rules are tightening: see our analysis of the B2B late payment reform and ERP configuration. An unmanaged VoP exception queue can turn an anti-fraud control into a source of penalties. Plan for indicators: number of exceptions per payment run, average age of exceptions, share resolved within 24 hours.

Fighting IBAN fraud: the controls that remain essential

VoP is a safety net, not a complete solution. A fraudster who controls an account opened in the right name (or a shell company with a credible name) can get a “match”. Preventive controls therefore remain necessary:

• Call-back: every request to change an IBAN is confirmed by a call to a number already held in the ERP, never the one given in the request email.
• Segregation of duties: the person who changes bank data is neither the one who approves payments nor the one who reconciles statements. Our guide to the SoD controls to implement before the annual audit details the conflict matrix to configure.
• Anomaly alerts: an IBAN change followed by a payment within days, an IBAN from a country different from the supplier’s, an IBAN shared by several suppliers.
• Access control: limit the number of users allowed to change bank details and review their rights regularly.

The point of combining VoP with these controls: the first catches keying errors and crude fraud at scale, the second deal with targeted fraud that passes the automatic check.

One-year review: 8-point CFO/CIO checklist

1. Decide the scope: VoP enabled or opt-out for files, bank by bank, with the decision written down and signed by treasury.
2. Clean up the master data: legal name and account holder name kept separate, duplicates removed, inactive suppliers blocked.
3. Review the IBAN change workflow: logged request, call-back, approval by a third party.
4. Check SoD: no user combines vendor creation, bank detail changes and payment release.
5. Connect bank responses: VoP statuses readable in the ERP or treasury system, not only in the bank portal.
6. Write the exception procedure: rules for close match, no match and verification not possible, with owners and deadlines.
7. Measure: match rate, exception volume, resolution time, fraud attempts detected.
8. Test capacity: confirm with the bank that processing times for large files remain compatible with your cut-off times.

One year on, VoP has mostly shown that third-party data is an internal control asset. Companies that already had a clean vendor master experienced it as a formality; the others are discovering the cost of neglected master data.

To go further on adapting your ERP to the new payment flows, read our SEPA Instant and ERP treasury guide and get the next regulatory analyses by subscribing to the newsletter.