VOP: Deciphering the EDS Local File
On February 28th, the European Payments Council (EPC) published the first version of the (highly) anticipated EDS (EPC Directory Services) Local File specifications. With 7 months left for Payment Service Providers to (select and) implement their VOP solution, let’s have a look today at the content of this file, and at how LUXHUB intends to provide it conveniently to its Payee Verification Platform participants.
As explained by the EPC, “the EPC Directory Service (EDS) Local File is the representation of the EDS in a form of file in XML, JSON, and CSV format to be used locally by scheme participants and their technical providers (e.g. Routing and/or Verification Mechanisms for the VOP scheme)”.
The EDS Local File is generated daily and ensures up-to-date information for PSPs and RVMs, helping participants confirm API endpoints and validate payment service provider details. In more details, it contains participant identification data (participant BIC, account Holding BICs, PSD2 National Authorization Numbers), adherence data (scheme adherence and readiness dates, scheme roles assumed and options supported by respective VOP interfaces) as well as API-endpoints related information (URI, environment, version, priority -in case more than one URI is available- and effective availability dates for available versions).
The file will be available for download via an EDS dedicated portal after user authentication or obtained by qualified RVMs via an EDS API. It can then be parsed and imported in the IT system of the participants for an optimized access.
Based on an initial analysis by the Product team at LUXHUB, the first version published does not contain any surprises and will allow RVMs (and standalone PSPs) to pursue the design of their VOP solution. To note the presence of two separate information, ‘Account Holding BIC’ and ‘participant BIC’ field. This differentiation could be useful in the context of cases, such as omnibus accounts, involving two different PSPs, one holding the account (typically an E-Money Institutions and Payment Institutions) and another (a credit institution) maintaining the account (more on this case in the Q&A #108 from DG FISMA).
EDS usage for Verification of Payee
Central component of the VOP scheme, the EDS file content is intended as a discovery and validation basis for VOP Scheme participants, or their RVMs.
Based on the IBAN of the beneficiary, the VOP Requesting PSP derives the Account Holding BIC of the beneficiary PSP and uses the most recent version of the EDS to look-up the API endpoint (URI) of the VOP Responding PSP, implicitly proving the adherence of the VOP Responding PSP to the scheme.
The VOP Responding PSP verifies that the combination of the Requesting PSP BIC (received in the API payload) and the PSD2 NAN (retrieved from the PSD2 QWAC certificate of the VOP Requesting PSP) correspond to a valid entry in the EDS Local File. This will mean that the VOP Requesting party is a valid VOP Scheme participant.
Going further with the EDS Local File
LUXHUB’s Payee Verification Platform supports PSPs in their VOP challenge(s) and therefore aims at facilitating the implementation of this required matching service, as well as daily operations.
The LUXHUB team continuously works on adding several new features and functionalities to its solution, one of them strengthening the EDS Local File and obviously the matching results. Here is what LUXHUB has added to the EDS content:
➜ MORE DATA
- Scope information: to help Requesting PSPs differentiate between beneficiary PSPs that are in the IPR scope and those who aren’t but are members of the EPC VOP scheme (case of countries who will be in scope only later in July 2027 or SEPA countries that are not part of the EU).
- Reachability information: concrete information which interface is available or not (particularly useful in the months leading up to October 2025)
➜ MORE STRUCTURED AND FLEXIBLE CONSUMPTION
- LUXHUB will provide a REST API endpoint to return the providers’ information (EDS + LUXHUB additions) in real-time and in a manner that could be automatically integrated into an existing or adapted payment flow. For example, at the time of initiating a payment, the Requesting PSP can check in real-time whether the VOP check is possible and/or is required from a compliance perspective.