Three weeks after the publication of its Verification Of Payee rulebook, the European Payments Council kept its words and published the Verification Of Payee API specifications on October 31, 2024.

The rulebook was much anticipated by the industry so that PSPs and their providers (or RVMs, Routing and Verification Mechanisms) could refine the design of their VOP solutions, and answered key questions.

These final API specifications enable all parties to actually develop their VOP APIs while ensuring scheme compliance and therefore interoperability across all PSPs.

In this blog, we explore the main API flows involved in VOP and their payloads, how the security of critical data involved in VOP will be ensured, and how VOP will work when either Requesting or Responding PSPs use RVMs.

Before jumping into the actual API specifications, we must understand the different actors involved in VOP and their interactions.

The requester is the payer. It can be a natural or a legal person.

The Payment Counterparty is the payee. It can be a natural or a legal person.

The Requesting PSP is the PSP of the payer, or Requester, who will have to send a VOP request and provide the result to its Requester.

The Responding PSP is the PSP of the payee, or Payment Counterparty, that will have to respond to VOP requests.

The EPC Directory Service is a central directory that will store all the required data for Requesting PSPs to send VOP requests to Responding PSPs. On a high level, the EDS will provide the right URL to call to send a VOP request for a given IBAN.

While the VOP Rulebook defines what attributes should be included in all VOP messages, including those between Requesters and Requesting PSP, the Verification Of Payee API specifications are precisely “Inter-PSP” API specifications.

They don’t specify how APIs should be designed between PSPs and their RVMs, or PSPs and their customers who would benefit from programmatic VOP requests and responses. But we expect the structure and content of such APIs to be close, if not similar, to the inter-PSP ones.

The VOP API specifications cover the API sequences for 3 different use cases:

We will first cover the sequence for the first use case, then break down the main differences between the sequences of the second and third use cases and the first one.

The sequence diagram below shows the different steps of a Verification Of Payee workflow using a natural or legal person’s name.

In this section, we highlight the main tasks Requesting and Responding PSPs have to perform for this workflow to take place.

The table below describes the different elements required in a Requesting PSP to Responding PSP API request for name-based Verification of Payee request.

In addition to attributes filled by the Payer when initiating a VOP request (Payment Counterparty Name and Payment Counterparty IBAN), and to trivial attributes (Request timestamp, Requesting PSP’s reference number, …), the Requesting PSP must perform some processing in order to complete a Requesting PSP to Responding PSP API request.

The Responding PSP BIC is a required attribute in Requesting PSP to Responding PSP API requests.

It is also the routing key to provide to the EPC Direct Service (EDS) in order to obtain the right Responding PSP VOP API host url to send the VOP request to.

BICs cannot be directly calculated from IBANs. PSPs or their RVMs will therefore have to call services allowing the retrieval of BICs from IBANs to obtain this information.

The EPC designed the Verification Of Payee scheme as a decentralised scheme, based on interoperability of participants’ systems rather than a central infrastructure.

This design means that there won’t be a unique endpoint to connect to in order to send VOP requests, but up to as many endpoints as participating PSPs.

To ensure interoperability between all participating PSPs, and ensure the success of each VOP requests, the EPC will maintain a central directory, the EDS, that will provide the right Requesting PSP with the right endpoint to call in order to reach a given Responding PSP.

When preparing a VOP API request, a Requesting PSP must therefore call the EDS with the Responding PSP BIC to obtain the Responding PSP VOP API host url.

Requesting PSPs or their RVMs will need to make local copies of the EDS and rely on these local copies for this processing.

Before the Requesting PSP can send the VOP request to the Responding PSP, both Requesting and Responding PSPs need to mutually authenticate. We cover the reasons why the rulebook requires this mutual authentication and how it works in a section below.

Once both PSPs are mutually authenticated and the Requesting PSP has retrieved all the data required in a Requesting PSP to Responding PSP API request, it can be sent following the JSON format defined in the API specifications document.

As part of the VOP scheme security mechanisms, the Responding PSP must ensure that the Requesting PSP is a legitimate VOP scheme participant.

We cover this flow in details below in this article.

Before the verification response calculation itself starts, the Responding PSPs can, as recommended by the EPC Recommendations for the Matching Processes under the VOP Scheme Rulebook, clean-up the name provided in the Payment Counterparty Name attribute of the VOP API request.

It consists in cleaning the name strings to ensure the calculating workflow can process said strings. For instance ignoring casing, removing accents or removing honorifics and titles if the responding PSP doesn’t record them in its account holders database.

Once the request data has been cleaned-up, the Responding PSP must calculate the VOP response, meaning assessing the correspondence of the provided Payment Counterparty Name with its account holder name for the provided IBAN.

Based on the result of this analysis, the Responding PSP can answer with one of the following answers:

With the calculated VOP answer, the Responding PSP has all the elements to prepare the Responding PSP to Requesting PSP API response.

No further authentication is required for the Responding PSP to send the response to the Requesting PSP. The Responding PSP can send the response following the JSON format defined in the API specifications document.

Below is an example of a Match response:

And below is an example of a Close Match response:

This step isn’t specified in the EPC API specification, however PSPs will have to manage it properly to comply with the VOP rulebook and IPR regulation.

Whenever a Requesting PSP sends a Requesting PSP to Responding PSP request, it must start counting the time from the Request timestamp.

If this time reaches 5 seconds, the VOP request is considered timed out and should lead to a “Verification not possible” response to the Requester.

Requesting PSPs must inform their Requesters of the VOP response, meaning extracting the relevant information from the received VOP response and either:

The possible responses to Requesters are the following:

The sequence diagram below shows the steps of a VOP workflow for a legal entity payee leveraging an identification number. As defined in the VOP rulebook, this identification number can be a VAT number, a SIREN, a SIRET or any other valid identifier.

In this section, we highlight the main differences between the VOP workflow with a name and the VOP workflow with a legal entity’s identification number.

Preparing Requesting PSP to Responding PSP request

The main difference to highlight versus a name-based VOP request is the need to populate the identification number in the API request.

This identification number is provided by the Requester when they initiate their VOP request, however the API specifications adds a step to ensure success of identification number-based VOP requests.

Before sending an identification number-based VOP request, the Requesting PSP must query the EDS to check which types of identification numbers the Responding PSP supports.

The Requesting PSP can, therefore, leverage this information to dynamically suggest to the Requester the different VOP methods available to verify a legal entity payee: whether with name only or with an identification number and, in this case, which type of identification number.

Identification number-based VOP doesn’t introduce any change in this step.

Compared to name based-VOP, this step is simpler for the Responding PSP with the identification number-based VOP.

There is no request data clean-up required, as identification numbers should follow standardised formats and a Responding PSP should not receive identification numbers it doesn’t support.

The identification number-based method only allow for perfect match between the provided and recorded identification, or no match at all, leading to the following possible responses:

Here again, this step is simpler as it only involves answering with the VOP answer.

The Verification of Payee requirement stated in the IPR applies equally to banks and payment and electronic money institutions (PIs and EMIs). Therefore, so does the Verification Of Payee rulebook.

However, PIs and EMIs don’t always have their own BIC code, which is the routing key used by the VOP scheme. Indeed, PIs and EMIs can operate as SEPA indirect participants, in which case they have their own BIC, or banks’ corporate customers, in which case their payment accounts are under their partner banks’ BIC.

In the SEPA indirect participant setup, VOP will work similarly for PIs and EMIs than for banks.

In the corporate customer setup, the API specifications plan that the VOP requests are sent to the PI/EMI’s bank, which can then leverage an “unstructuredRemittanceInformation” additional attribute to identify the right payee and calculate the VOP response accordingly.

This workflow is described in the sequence diagram below.

With the current information available in the VOP rulebook and the VOP API specifications, the only solution we see realistically feasible for PIs and EMIs operating as banks’ corporate customers to fulfil their VOP obligations is the following:

The EDS documentation to be published in November 2024 might provide further information on this use case, including potential direct VOP request routing to PIs and EMIs operating as banks’ corporate customers.

We will publish dedicated content on this scenario when the EDS documentation is available, and are actively exchanging with our bank network to understand how they are foreseeing to answer this scenario.

In any case, at Mambu Paymentswe are committed to support all our customers, no matter their setup, to comply with the regulation.

Verification Of Payee allows the exchange and verification of potentially sensitive information between PSPs. In this section, we explore what are the risks introduced by VOP and how the scheme mitigates them.

The Verification Of Payee scheme will enable any customer of a European PSP to query the correspondence of any account holder and an account number, and in the case of the “Close Match” scenario, receive from the Responding PSP the actual name of the account holder.

Without the right projections, it is theoretically possible, even though very unlikely, for a malevolent party to bruteforce the scheme to obtain the account numbers of European citizens or companies.

The most likely threat comes from the “Close Match” scenario, where malevolent parties could leverage a misconfigured, too loose matching algorithm of a PSP to easily leak its account holders.

To prevent these potential leaks, the scheme plans several mechanisms.

The first layer of protection comes from how PSPs will obtain the VOP API host urls to query. These host urls will only be available in the EDS, which will only be accessible by PSPs participating in the VOP scheme.

The EPC API Security Framework document further specifies how Requesting and Responding PSPs should mutually identify prior to exchanging VOP messages.

PSPs can rely on third-party providers to perform all or part of the Verification Of Payee workflows. The third-party providers are called Routing and Verification Mechanisms (RVMs) in the case of the VOP scheme.

RVMs must perform these tasks on behalf of PSPs according to the rulebook, and therefore following these API specifications. So the use of RVMs doesn’t introduce any change in the inter-PSP workflows described above, they will simply send or receive answers on behalf of PSPs.

The only differences will be in the VOP request URLs and management of EV and QWAC PSD2 certificates.

In the case of a Responding PSP leveraging an RVM, the RVM will have the possibility to expose one unique request URL per PSP customer, or one common URL for all PSP customers. The RVM will be required to record these URLs accordingly in the EDS to ensure proper routing of VOP requests.

The RVM will then leverage its PSP customers' EV certificates to authenticate itself to the Requesting PSP.

In the case of a Requesting PSP leveraging an RVM, the Requesting PSP will have to provide the RVM with its QWAC PSD2 so the RVM can authenticate the VOP Request as coming from the PSP to the Responding PSP.

Additional requirements might be raised by the EDS documentation when published.

With the publication of these API specifications, the last missing piece for full VOP readiness is the EDS specifications or requirements documentation, which should be published in November 2024, alongside potential clarifications for PIs/EMIs operating as corporate customers.

In any case, these API specifications now enable all industry actors, whether RVMs or PSPs that are building their own solutions, to finalise the design of their solutions and start or pursue the development of their VOP API.

Numeral already enables customers to verify counterparty accounts, including account holder names, account status and legal entity identifiers, at any time.

Do not hesitate to contact us to get ready for Verification Of Payee or solve your account verifications needs today.