Verification of Payee:

It was a seemingly familiar path: payment transactions in Europe seemed to run smoothly and stably for years, like a ship on a calm sea. But it is precisely in this supposed security that the turning point is heralded, quietly but inevitably. In the middle of the night, the ship runs into an iceberg. So unexpected, so irrevocable: the Verification of Payee. A regulation that changes payment transactions, disrupts established processes and realigns the course for everyone involved. What initially seems like an invisible threat turns out to be a turning point that will change the everyday lives of banks, business customers and private individuals alike - and could suddenly catapult modern, automated processes back into a time of manual processes.

In this article, we will look at the regulatory framework and the challenges associated with its implementation for customers, banks and providers of treasury management systems.

On 9 October 2025, a new hour struck in European payment transactions: a new EU regulation, the Instant Payments Regulation, comes into force in the SEPA area. From 1 January 2027, the obligation to verify the payee (VoP) will also be extended to the countries of the European Economic Area. The centrepiece of this innovation is the mandatory recipient verification, which aims to prevent transfers to bank accounts from incorrect account holders and significantly increase the security of payment transactions. In future, every SEPA payment - regardless of whether it is a traditional transfer or an instant payment - will be checked to see whether the recipient's name matches the IBAN of the account holder.

All players in payment transactions are affected by the implementation: Banks and payment service providers who have to make technical adjustments to their systems and processes; business customers who submit their payments via electronic payment transactions using EBICS, SWIFT or host-to-host; private customers who make transfers using online banking or transfer slips.

Exceptions only apply in certain cases, such as transfers from or to loan, fixed-term deposit or call money accounts, transfers to recipient banks or collector files that have been transferred electronically to the banks. In the case of collector files, you can opt out, which means that no recipient check is carried out. This means that no process change is necessary, but at the same time the customer assumes the liability that could be minimised by the recipient check.

The banks were obliged to implement this by 9 October 2025 and have overcome numerous technical and organisational hurdles to do so. The requirement that the VoP check must be carried out within five seconds was particularly challenging. In addition, there were significantly higher requirements in terms of performance and the speed at which transactions had to be executed. The cost factor also played a role, as implementation was mandatory but no additional fees could be charged to the customer. At the same time, the interface specifications defined by the European Payments Council must be adhered to. These require closer networking between the banks in order to ensure a uniform standard and data exchange for verification. In addition, data protection, the review of sanctions lists and compliance with reporting obligations for real-time payments are also becoming increasingly important.

For business customers, the question now arises as to what practical impact this regulation will have on their daily payment processes. The process begins with the payer, who enters and authorises the payment data and transmits it to their bank via their Treasury Management System (TMS). This creates a VoP request with the relevant details such as IBAN, recipient name and, if applicable, a VAT ID. This information is forwarded to the recipient's bank, which compares the data with the stored information. The result is reported back in the form of a traffic light system: Match means that the name and IBAN match. Close Match indicates minor discrepancies, usually typing errors such as Bernhard Müller instead of Bernard Müller. No Match signals a clear discrepancy, such as Bernhard Müller versus Fernando Rodriguez or the complete absence of a first name.

The response to the payment file (e.g. PAIN.001) is reported back to the sending bank as a VoP response and sent by the bank as a feedback message (payment status report PAIN.002) to the company's TMS or the bank's online portal. After the feedback, the company has a choice: the payment can be rejected and recreated or authorised despite the discrepancy. The effect on incoming payments should also not be underestimated. If there is a close match or no match, this can lead to delays in crediting and therefore to a late receipt of payment.

As much as the regulation is intended to strengthen security and trust in the market, it also has a profound impact on established company processes. Payments that have already been authorised must be released twice, master data must be checked and corrected, payments must be reversed, newly created and payment files must be sent to the bank and authorised again. Collector payments are particularly complicated, as most TMS systems do not yet offer the option of cancelling individual payments. If there is only one payment with No Match in a collector, all payments must therefore be reversed and re-initiated.

Payroll accounting is a particularly critical area. Payroll payments are usually processed as a collective file without an itemised view. If even one payment falls into the Close Match or No Match categories, the entire payment file for salaries would have to be stopped. In most cases, the HR system excludes a new payroll run. How is the payment file then recreated? This could lead to manual interventions in salary files, which should be avoided for compliance and data protection reasons. In addition, stopping payments could result in all salary payments being delayed.

Many companies will therefore refrain from using VoP for collective payments due to these challenges. A cautious start with individual payments can make sense, while internal processes are gradually adapted to ensure smooth workflows.

The most important question is therefore how an optimised process should be designed in technical and organisational terms. In principle, it makes sense to start at several points. On the one hand, the business partner master data can be validated when it is created in the system. When an invoice is received, care should be taken to ensure that an account holder is specified and the business partner should be contacted if necessary. This ensures that new business partners are entered correctly from the outset and that payments are not delayed later. An additional security factor can also be built in by integrating external service providers into the process. They can check all master data in the ERP for matches before payments are initiated. By using such third-party providers, the number of close-match and no-match responses can be significantly reduced, as the master data is cleansed and corrected before the actual payment chain.

On the other hand, the process can also be strengthened in organisational terms. A proven model is to set up a dedicated master data team or integrate it into master data governance to continuously cleanse and update business partner data. This team not only corrects master data based on VoP responses, but also actively processes close or no matches. Additional measures such as penny tests for new suppliers or regular data cleansing can also be introduced. The system must be able to process and read the VoP response provided by the bank. In addition to establishing the master data team, the process of reversing and recreating payments should be clearly defined in organisational terms and all parties involved should take on precisely defined tasks within the new payment process.

As already mentioned, the technical implementation plays just as important a role as the organisational and procedural adjustments. Collaboration between TMS providers, banks and companies is particularly important here. This is because the VoP process can only be mapped in a robust and automated manner with the technical support of the systems. We are observing the following topics on the roadmap of TMS providers:

1. The development of pre-validation services,
2. the extraction and handling of individual transactions from collector files and
3. the expansion of reporting options.

One improvement from a company perspective is the removal of individual transactions from collective files. There is no provision for the targeted removal of individual transactions directly at the bank, which makes it necessary to recreate the file in the TMS.

Pre-validation services offer the possibility of automatically checking payments before they are actually transferred to the bank in order to intercept close-match or no-match cases at an early stage. Many systems are currently still in the design or development phase, meaning that external pre-validation services are often the only practicable solution. Companies have to work with interim solutions here.

Last but not least, reporting also plays a central role. Extended reporting functions that enable detailed insights at transaction level are still being developed in many places.

It can be said that there is still a need for development at all levels. For corporates, this means that they should closely monitor ongoing developments, seek dialogue with their providers at an early stage and secure possible gaps through organisational measures or external solutions until the systems are fully available.

The introduction of the Instant Payments Regulation and the mandatory Verification of Payee mark a far-reaching change in European payment transactions. The aim of increasing security and trust is clear, but the practical implementation poses considerable challenges for companies. In particular, the close interlinking of master data quality, internal processes and technical system support will determine whether the transition goes smoothly or whether inefficiencies and delays will have a negative impact on payment transactions.

In the short term, the introduction of VoP primarily means additional work for many companies. The feedback from the banks must be processed and embedded in the existing payment reversal process or the process must be redefined. Especially at the beginning, this can lead to delays if payments are blocked because master data is not consistently maintained. In addition, the necessary tools and interfaces of many TMS and banking systems are not yet available across the board.

In the long term, however, the advantages outweigh the disadvantages. VoP increases the quality of master data, as master data is necessarily well maintained and errors are eliminated. At the same time, recipient verification makes an important contribution to fraud prevention by reliably cross-checking bank details. In addition, the regulation creates future security, as it introduces a development that has long since gained international significance and is already a legal requirement in other countries.