The Verification of Payee (VOP) mandate in Europe is a critical step toward reducing fraud and improving payment accuracy across the SEPA region. As financial institutions prepare for compliance by the October 9, 2025 deadline, selecting the right Routing and Verification Mechanism (RVM) becomes essential.

RVMs are solutions that Requesting PSPs can use to send VOP requests on their behalf or that Responding PSPs can use to receive and respond to VOP requests. Relying on a third party RVM isn’t mandatory, and Requesting and Responding PSPs can choose to send, receive and respond to VOP requests by themselves, acting as their own RVM.

In this article, we explore the key factors to consider when evaluating solutions for your specific use cases.

First, let’s recap the stakes of VOP compliance. The European Payments Council (EPC) has defined strict rules for VOP compliance. PSPs obligations include:

Failure to meet these obligations can result in fraud liability and reputational damage. Therefore, an RVM should be designed to seamlessly handle these processes, ensuring end-to-end compliance.

PSPs subject to VOP must go through the EPC adherence process, and obtain electronic authentication certificates to send and receive VOP requests.

These administrative tasks can monopolise valuable resources and delay VOP projects if not managed properly. RVM providers can help you with these tasks.

The VOP Scheme sets a maximum execution time of 5 seconds (preferably 1 second or less) for the Requesting PSP to get the VOP Response.

Failing to respond in 5 seconds leads to a timeout and a “Verification check not possible” response for the payee.

If a responding PSP repeatedly fails to respond within the 5-second timeframe, its customers may therefore receive fewer payments from their counterparties, due to worrying VOP results on the payers’ side.

Contractual response time SLAs ensure PSPs that they will get compensation in case their RVM repeatedly fails to answer on time.

The scheme doesn’t mandate a specific matching algorithm to calculate the VOP response; it only provides high-level guidelines. Therefore, each RVM can implement the matching algorithm of its choice.

In addition to the matching algorithm's pure performance, the RVM should enable some level of customisation of this algorithm.

Indeed, each PSP can have different objectives regarding risk and customer experience.

For instance, a too-strict matching algorithm can result in more “Close match” than “Match,” leading to the sharing of too much recorded account data with Requesting PSPs and their payers and representing a data confidentiality risk.

It can also result in too strict “No match” results, leading to a poor user experience for its payees.

PSPs should be able to configure the matching algorithm based on their own risk policies and objectives.

Customer account data is extremely sensitive information that will be processed and sometimes stored by RVMs.

RVMs must, therefore, ensure that this data is safe at all times and support PSPs' specific security requirements.

Such measures include specific hosting options, such as a dedicated instance, proper encryption of account data at rest and in transit, or the option to synchronise account data via encrypted files.

RVMs will also manipulate PSPs QWAC PSD2 certificates to authenticate with other VOP participants.

These certificates are extremely sensitive, as they are used to represent PSPs for various open banking use cases at the European level.

PSPs must ensure their RVMs have the right measures in place to secure these certificates.

To calculate VOP responses, the RVM must have access to the Responding PSP account data. This account data is often stored in critical systems such as Core Banking Systems (CBS).

Depending on the CBS, specific integration options can be more relevant than others, such as allowing the full synchronisation of the account database into the RVM or allowing the RVM to query the Core Banking System for each VOP request.

For each model, specific channels might be more adapted, such as API, file upload via SFTP, or manual upload.

PSPs must ensure that the RVM they select provides the right integration options for their specific use case and architecture.

The Instant Payments Regulation (IPR) holds PSPs liable for VOP failures leading to fraudulent payments. Therefore, it is critical for both Requesting and Responding PSPs to demonstrate that they performed all their duties as part of the VOP process.

To do so, RVMs must offer PSPs comprehensive reporting on sent and received VOP requests and responses, including potential errors.

For Responding PSPs, reported data could include VOP request data, source data, cleaned data, and matching scores.