Blog

VoP: Key insights from recent EPC documents & guidelines

4min Read · 18 Nov 2024

In the last weeks, the European Payments Council (EPC) released several key documents and guidelines with regards to the implementation of the Verification of Payee (VoP) service. Find below a recap of each document, and feel free to reach out to us should you need help in your VoP project.

VoP Scheme Rulebook

It’s on October 10^th that the much-anticipated Verification of Payee Scheme Rulebook was finally issued by the European Payments Council. It consists of a “set of rules, practices and standards to achieve interoperability for the provision and operation of verifying Payment Account Numbers and Names of the Payment Counterparties, between Participants of the Scheme prior to initiating a Payment Account-based Payment within SEPA”.

Here are some of the most important aspects:

Only PSPs in scope of VoP obligation can directly join the scheme; adherence is not limited to PSPs in the 27 EU countries but is also open to other SEPA scheme countries (3 EEA + 6 non-EEA)
Few important parts of the scheme remain to be published such as the VoP Scheme Adherence Process (to come in 2025), the Risk Management Annex (ANNEX II in the Scheme Rulebook – to come in 2025) and the requirements for the EPC Directory Service (EDS)
High-level coverage of EDS content is provided: list of participants in the scheme, their respective technical routing data to send a VoP request and their supported corporate identifiers
In addition to the main payee details matching service, the scheme allows the opportunity to provide additional optional related services
Batch VoP requests can be exchanged between a PSU and its PSP however only single requests will be allowed between PSPs
The maximum execution time of a VoP request has been increased to 5 seconds (from 3 seconds initially)
Very minor changes in the EPC recommendations for the matching process: explicit introduction of a detailed forth answer in case the matching was not possible and acknowledgement that recommendations/scenarios provided by the EPC are not exhaustive ‘rules’ but ‘guidelines’

VoP Inter-PSP API Specifications

Published on October 31^st, the Inter-PSP API Specifications document provides the rules for implementing VOP requests and corresponding response messages in the inter-PSP space, including the authentication and authorization mechanisms to protect the data exchanged via the API. The API uses ISO-20022 resource elements.

Find below, the different insights and key points we highlighted:

EDS (EPC Directory Services) will play a key role for the interoperability of the European VoP network and will have to be used to:

→ retrieve the VoP responding PSP’s URI from the Payee PSP BIC11 extracted from the Payee IBAN, confirming the Responding PSPs adheres to the scheme

→ identify if responding PSP supports Identification Code in check request

→ verify the combination of Requesting BIC and NAN in the request

API Authentication and Authorization: mutual authentication (TLS with Client Authentication):

→ VoP Requesting PSP (as Client): must use an eIDAS QWAC PSD2 certificate (containing the NAN – National Authorization Number of the PSP) based on ETSI TS 119 495 with QC statements providing: PSP role, name of NCA, PSP Identifier (NAN)

→ VoP Responding PSP (as Client): must use a TLS EV Certificate

To authorize a VoP request, the Responding PSP must verify in the EDS if the Requesting PSP is adhering to the VoP EPC scheme. This is done by applying the following steps:

→ Once the Requesting PSP is authenticated, the Responding PSP can extract a National Authorization Number (NAN) from the QWAC PSD2 used in the request

→ The Responding PSP will verify if the combination of the BIC (as received in the payload of the VoP request) and the NAN received via the QWAC PSD2 certificate of the Requesting PSP is present in the EDS

Three major use cases as positive flows are identified and supported:

→ Name/IBAN Check – can return Match (MTCH), No Match (NMTC), Close Match (CMTC) with name indication, Not Applicable (NOAP)

→ Identification code (LEI, VAT, …) / IBAN Check – can return Match (MTCH), No Match (NMTC), Not Applicable (NOAP)

→ Name (or Identification code) + additional attribute (C007)/IBAN Check – In case of Name+IBAN: Match (MTCH), No Match (NMTC), Close Match (CMTC) with name indication, Not Applicable (NOAP) / In case of IBAN+Identification code – Match (MTCH), No Match (NMTC)

Character Set and Data Types: UTF-8 encoded, limited set of Latin Characters. Additional characters can be supported by bilateral/multilateral agreements or via an agreed AOS
The newest version of the document is accompanied by an interface description. The YAML file is available HERE

API Security Framework

Just like the previous one, this document was issued by the EPC on October 31^st. As explained in the document, “although there are some differences related to how the schemes [SPAA, SRTP and VoP] operate, as well as a difference in maturity between them, and differences in naming the Participants and stakeholders, they are sufficiently similar as messaging schemes to justify a joint effort in defining a common API security framework”.

Check out the key points highlighted by the LUXHUB experts:

Purpose of sealing/signing: providing the proof that an API client has indeed submitted a given request and vice versa an API server has indeed provided a given response. This section is only relevant when the scheme has required that some messages, or part of the messages, must be protected by sealing. So far, this is only foreseen for the SRTP scheme
A Routing and Verification Mechanism (RVM), acting on behalf of Requesting PSP, will have to use QWAC certificates from the Requesting PSP:

→ RVMs are not considered as Participants in the scheme; it is always legally transparent because the liabilities and obligations stay at the level of each scheme Participant

→ It will be transparent for the Responding PSP if the requesting API gateway is operated by a RVM or directly by the Requesting PSP

→ It will be transparent for the Requesting PSP if the responding API gateway is operated by a RVM or the Responding PSP itself