Verification of Payee

• 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, the Risk Management Annex 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’

• 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

• 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

• 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