To VoP or not to VoP - Trade Treasury Payments

Let’s start VoPping

What the heck are we talking about here?  Those readers who pay bills in the UK might be able to guess what this abbreviation relates to. Last year the Pay.UK project on Confirmation of Payee (CoP) was implemented for online payments, enabling the payers to check whether their payment entry matched fully, closely, or not at all with a given beneficiary bank account and name.  

VoP is the Single Euro Payments Area (SEPA) payments equivalent of the UK CoP. But instead of copying their English peers outright, the folks on the continent switched the word “Confirmation” with the word “Verification” to create VoP: Verification of Payee.  

SEPA VoP is based the EU’s Instant Payment Regulation (IPR). It will start with the Eurozone and SEPA offering banks, but later extend to govern other EU area currencies, countries, and instant payment schemes as well. While the regulation has ‘Instant Payment’ in its name (the IPR), VoP will also cover standard, non-instant, SEPA payments (i.e., credit transfers) that are already almost fully processed and settled within the same day.

Instant payments need instant fraud detection

The purpose of VoP in the context of the Instant Payment Regulation is clear. There must be a mechanism to check that money is moving to the correct beneficiary when making an irreversible transfer between bank accounts that settles in ten seconds. At the same time, the IPR obliges SEPA banks to offer instant payments under the same terms and conditions (read: price) as normal, classic SEPA credit transfers.

In the case of online banking payment entry, where the VoP process is mandatory, it provides useful guidance to the payer about possible mismatches in the beneficiary details. And under the IPR’s short big bang implementation period, the previous €100k maximum amount for SEPA instant payments will also be removed.

VoP gives banks two options for making the check: IBAN account number and beneficiary name, or IBAN account number and beneficiary ID. Since the creditor ID is very rarely provided or used in payment initiation, the second option will become marginal, if used at all. The focus will therefore be on the beneficiary name, though that is not always as simple as it seems.

Checking whether a legal entity or a private person’s name matches the IBAN account holder at the responding bank will be challenging. The European Payments Council has issued recommendations on how to compare names, but ultimately, each SEPA bank will implement its own logic. Should the comparison be done using only the official registered company name, or also the trading name if it differs but is widely used? Everything will depend on the data held by the account holder’s bank.

So, the payer enters the IBAN and payee name, after which the payer’s bank sends an API request (Application Programming Interface) to the payee’s bank (possibly via central service providers). The payee’s bank must respond within five seconds with one of the following four statuses:

• Full match: the name exactly corresponds to the name registered as the account holder at the beneficiary bank.
• Close match: the name is almost the same, and in this case the responding bank is required to return the correct name to the payer.
• No match: the name is not even close to the registered account holder name, and no advice is given to the payer.
• Not available/possible: the VoP check cannot be processed for technical or other reasons. In this case, no explanation is given for the failure.

Only the first status is classified as green. The remaining three are doubtful results, although the second provides useful help in correcting the name for the current and future payments. The IPR nevertheless gives the payer the right to approve and execute the payment regardless of which of the four statuses is returned.

Batch VoP challenge

Online payment approval is a simple interactive action, regardless of the status the VoP process shows. But what happens when corporate payments are sent as a batch file to the bank?

This process is usually fully automated. A corporate end-customer creates the payment proposal according to its criteria, then, after internal approval, generates the payment file, digitally signs it with the bank-provided signature method, and sends it automatically to the bank. The bank executes the payments if there are no errors in the data.

Now add the VoP process. The bulk file is split into individual transactions per receiving bank (based on the IBAN, assuming the IBAN vs bank code logic holds). VoP requests are then sent to each relevant bank, the responses are collected by the payer’s bank, and returned to the customer in a Payment Status Report (PSR).

The problem arises when the PSR shows amber or red flags. In theory, the customer should be able to approve the payments within the same channel, regardless of the VoP statuses, as the IPR allows. But there is no “approve anyway” button. Nor is there any specific message the corporate can send to approve payments stopped by VoP. Even if such a message existed, breaking the automation to require human intervention would add another layer of risk.

So in practice, if there are VoP errors, the only way forward is to review the PSR, update the vendor master data, and resend the payments. This is a very tedious task, especially if the corporate has already paid the same account dozens or hundreds of times without issue, and now suddenly the bank stops the payment, potentially blocking the whole batch. Vendor data changes are slow, controlled processes, often requiring official documentation from the vendor. This creates a significant risk of delayed payments.

The IPR allows corporates to agree with their bank to opt out of VoP for batch (or “package”) payments, although in doing so they take full liability for fraudulent payments. There is an exception. When the package contains only one payment initiation, it is treated as equivalent to an online payment, and VoP is mandatory. This is the ultimate challenge and disruptor of automation.

As mentioned earlier, some banks offer interactive interfaces for corporates to log in and approve stopped payments, but this is not widely available. I have personally worked on large corporate multibanking payment and reporting automation solutions for over thirty years, and I concluded already in autumn 2024 that this problem cannot be solved feasibly without breaking automation, rolling the process back by some twenty years.

You could argue that not many payment batches consist of just one transaction, and most batches will be processed automatically. However, in May 2025, the European Banking Association, via EBA Clearing, collected real-life statistics showing that across SEPA countries, the proportion of single-payment batches ranges from 2% to 80% of all batches. This is again a dead end for automation.

Once the market realised the risk, particularly for corporates reliant on mass payment automation, urgent action began.

The EU regulator’s IPR Q&A clarification paper (point #123) states that VoP must take place before final approval. For corporates using host-to-host or SWIFT channels, payment files are already approved electronically when sent, so VoP no longer applies. This triggered a wave of bank- and community-specific interpretations in June and July 2025, leading to a full VoP opt-out interpretation (including single-payment batches) for pre-approved corporate files. Problem solved. But then comes the challenge of timelines and the risk of diluting VoP’s fraud-prevention benefits.

Risks for incoming payments

There is one area where corporates cannot opt out: responding to other banks’ VoP requests.

This means invoices must include the exact company name registered as the account holder with the corporate’s bank. If the name is even slightly different, the VoP response will flag amber or red. Even if the payer can still approve the payment, they may hesitate, contact the invoicer, or ask why the details don’t match.

This could delay incoming flows and disrupt liquidity, especially when the bank account is not held by the invoicing entity but by the corporate group (Collections On Behalf Of – COBO), or when invoices are sold to a factoring provider. In such cases, the invoice name must still match the actual bank account holder’s name.

In summary, incoming flow hiccups could cause serious problems for corporate liquidity management.

Tight timeline with a big bang approach

We now have only a few days until the 5 October 2025 scheme release and the 9 October 2025 final big bang deadline. After that, all SEPA banks must be able to handle VoP – both sending and responding – using APIs or centralised routing/verification mechanisms (RVMs).

The “financial internet air” will be filled with millions, even tens of millions, of API calls daily. Yet end-to-end testing with all participants, using production-like flows, will only begin between 5 and 9 October. Personally, I believe this is a major technical and functional risk, and I do not expect everything to go smoothly.

At the same time, corporates will need to update master vendor and invoicing data after discussions with their banks and software vendors, adapt payment file creation, VoP reporting, and file transfer protocols for opt-in/opt-out flagging, and prepare for possible hiccups in both incoming and outgoing SEPA flows.

Not only problems

I should not focus only on the problems. A Europe-wide Verification of Payee system is a major improvement for ensuring accurate data across SEPA. The addition of SEPA Instant payments to all participating banks will also enhance corporates’ cash and liquidity management.

But to be safe, here are some guidelines for corporates:

• Discuss with banks and vendors what Instant Payment and VoP features will be available at go-live and soon after.
• Check incoming SEPA payment flows and review the names customers use (available in ISO 20022 camt.05x reporting). Correct discrepancies by consulting your clients using the most deviating payee name.
• Use the correct legal entity name of the account holder on invoices, and inform clients well in advance if any changes are required. Be prepared to provide proof.
• Opt out of VoP for outgoing payments, at least initially, as recommended by the Common Global Implementation Market Practice group, and use VoP separately for vendor onboarding and maintenance.
• Activate VoP opt-in cautiously, only for selected use cases.
• Prepare your systems to receive Payment Status Reports (ISO 20022 pain.002) and display VoP results for updating vendor data.
• Confirm that your payment and invoicing vendors are ready, keeping in mind that VoP implementations will vary significantly across banks.

The way forward

The time after 9 October will be very interesting. We will not avoid technical or functional failures across banks, vendors, and corporates. Time and effort will be needed to tackle these challenges quickly, while also collaborating with peers to share best practices.

SEPA instant payment regulation and VoP will not be the last changes. With the geopolitical situation, fraud detection and prevention requirements will spread to more currencies and payment infrastructures. The Wire Transfer Regulation (FATF Recommendation 16) will make structured address data (at least town name and country code) mandatory for SEPA and international payments by November 2026.

While regulatory actions can feel like they fragment payment processing, more and more infrastructures are adopting ISO 20022 data standards. This will ultimately harmonise processes and create a stronger foundation for analytics, business intelligence, and even generative AI in treasury operations.

I wanted to end on a positive note: these changes, though complex, will help make payments faster, more secure, and more transparent, with richer data for all parties involved.