Verification Of Payee API specifications: all you need to know

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.

A quick reminder on the Verification Of Payee scheme model

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

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

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

The Requesting PSP – 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 – The Responding PSP is the PSP of the payee, or Payment Counterparty, that will have to respond to VOP requests.

The EPC Directory Service (EDS) – 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.

Routing and/or Verification Mechanisms (RVMs) – 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.

RVMs aren’t mandatory, and Requesting and Responding PSPs can choose to send, receive and respond to VOP requests by themselves.

RVMs can be provided by any type of entity, such as independent software vendors, existing providers of SEPA payment infrastructure, PSPs themselves, or any other entity.

Verification Of Payee API sequences, requests and responses

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:

• Name / IBAN check: the “classic” verification of payee for a natural person, also works for a legal entity

• Identification Code / IBAN check: the verification of a legal entity payee leveraging an identification code.

• Name (or Identification Code) / IBAN + Additional Attribute check: the verification of a natural person or legal entity payee when said payee is a customer of a payment or electronic money institution

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.

Natural or legal person’s name-based Verification Of Payee

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.

Preparing Requesting PSP to Responding PSP request

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.

Responding PSP BIC

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 (such as Numeral) to obtain this information.

Responding PSP VOP API host URL

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.

Sending Requesting PSP to Responding PSP request

Mutual authentication

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.

Formatting and sending the API request

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.

Processing Requesting PSP to Responding PSP request

Verifying Requesting PSP scheme participation

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.

Request data clean-up

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.

Calculating VOP response

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:

Preparing the Responding PSP to Requesting PSP API response

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

Sending Responding PSP to Requesting PSP 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

Processing Responding PSP to Requesting PSP 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.

Timeout

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.

Response to Requester

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

• Display it in the UI used by the Request to initiate a VOP request, before initiating a payment

• Most likely for corporates, pass the VOP responses programmatically via API or files

The possible responses to Requesters are the following:

Legal entity’s identification number-based Verification of Payee

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.

Checking Responding PSP-supported identification numbers

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.

Sending Requesting PSP to Responding PSP request

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

Processing Requesting PSP to Responding PSP request

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

No request data clean-up

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.

Easier VOP response calculation

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:

Preparing the Responding PSP to Requesting PSP API response

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

Sending Responding PSP to Requesting PSP response

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

Processing Responding PSP to Requesting PSP response

Response to Requester

As for the previous steps, this step is simplified as the Requesting PSP only has to inform the Requester of the VOP response: “Match”, “No Match” or “Verification not possible” and the associated warning messages.

Verification Of Payee on a PI/EMI-held payment accounts

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 PI/EMI shares with its sponsor banks all its customers attached to the bank accounts the PI/EMI holds at the bank

• The bank considers all these customers as account holders for the respective accounts, and answers VOP requests accordingly

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 Numeral we are committed to support all our customers, no matter their setup, to comply with the regulation.

Verification Of Payee protection mechanisms

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 risk of leaking sensitive information

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.

VOP protection mechanisms

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

1. EDS based routing.

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.

2. Mutual Authentication.

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

The mutual authentication relies on certificates issued by trusted third parties, including already in use “QWAC PSD2” or “Qualified Web Authentication Certificate issued for use in the PSD2 Open Banking context”.

3. Authorisation of the Requesting by the Responding PSP.

Once the Requesting PSP is authenticated by the Responding PSP, the Responding PSP must verify the Requesting PSP adherence to the VOP scheme in the EDS.

To do so, it must extract a National Authorization Number (NAN) from the QWAC PSD2, and verify that the Requesting PSP NAN-BIC pair matches the records of the EDS.

4. Additional protection mechanisms.

To prevent abuse usage of the VOP scheme, both Requesting and Responding PSPs can implement further protections such as:

• Rate limiting when sending or receiving VOP requests

• Answering the matching algorithm doesn’t allow too loose “Close Match” answers

Verification Of Payee when relying on a Routing and Verification Mechanisms (RVMs)

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.

Responding PSP leveraging an RVM

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.

Requesting PSP leveraging and RMV

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.

Getting ready to comply with Verification of Payee on time

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 toda