Skip to content Skip to footer
Search
PwC

Menu

Events

Loading Results

New EBA clarifications to APIs requirements under PSD2

Philipp Rosenauer Head Data Privacy | ICT | Implementationᐩ, PwC Switzerland 10 May 2019

In April 2019, the European Banking Authority (EBA) published the second and the third set of clarifications elaborated by the Working Group on Application Programming Interfaces (APIs) under PSD2.

The Regulatory Technical Standards on strong customer authentication and secure communication (RTS on SCA & CSC), which will apply from 14 September 2019, are the key to achieving the objectives of PSD2. In view of the complexity of the RTS requirements and the demanding timeline, the EBA established a Working Group, which it will consult to identify issues arising in the upcoming months and to propose solutions. 

In this post we would like to give a short overview of the discussion output regarding the issues recently addressed by the Working Group. The EBA clarifications cover a broad variety of topics such as eIDAS certificates, API testing, performance and ongoing support as well as conditions to benefit from an exemption from the Fall-Back mechanism.

Background

At the beginning of 2019, the EBA established a Working Group on APIs consisting of 30 external stakeholders representing the Account Servicing Payment Service Providers (ASPSPs), Third Party Service Providers (TPPs), API standardisation initiatives as well as payment service users (PSU). The task of the Working Group is to support the EBA, the national authorities, the European Commission and the European Central Bank in identifying issues challenging the payment industry during its preparation for the application of the RTS on SCA & CSC. Furthermore, the external stakeholders are requested to develop solution suggestions, which will be considered by the EBA and the national competent authorities.

In April 2019, the EBA published the second and the third set of clarifications to issues raised by the Working Group on Application Programming Interfaces (APIs) under PSD2. 

Issue 4: API performance and support

Issue summary: Some industry participants were concerned about the requirement defined in Article 32 RTS on SCA & CSC. According to this Article the ASPSPs have to provide the same levels of availability, performance and support for the dedicated interface and the interface available to payment service users (PSU) for directly accessing the payment account online. The participants stressed that the two interfaces are not comparable. Due to the higher data traffic expected for the integrated interfaces, 24/7 support for APIs seems to be challenging.

The Working Group proposed the definition of specific absolute measures for the dedicated interfaces.

EBA clarification: Article 32 (1) RTS on SCA & CSC explicitly postulates that the availability, performance and support offered for the API should be the same as those for PSU interfaces. However, the different ASPSPs offer different availability, performance and support for their PSU-facing interfaces. For that reason, the EBA cannot develop universal standard requirements applicable to all dedicated platforms.

Furthermore, the ASPSPs should define key performance indicators (KPIs) and service level targets (i.e. problem resolution, out of hours support, contingency, etc.) for their dedicated interfaces that are at least as stringent as those defined for the PSU interfaces. In addition, the EBA Guidelines on the Conditions to Benefit from an Exemption from the Fall-Back Mechanism (EBA/GL/2018/07) postulate that if the ASPSPs offer more than one client interface, then the KPIs and the service level targets for the API should be aligned to the best KPIs and service level targets across all offered PSU-facing interfaces.

Issue 5: List of TPPs interested in testing

Issue summary: Some participants stressed that the ASPSPs face difficulties in identifying the TPPs interested in testing their API.

The Working Group suggested the creation of a central list of TPPs willing to test dedicated interfaces. In addition, other participants highlighted the importance of consolidated information about ASPSPs having APIs ready for testing.

EBA clarification: The EBA points out that testing is equally important for TPPs and ASPSPs. One of the four criteria according to Article 33 (6) RTS on SCA & CSC that should be met by ASPSPs wishing to benefit from the exemption of having a Fall-Back solution is that its interface has been tested in line with the requirements of Article 30 (5) RTS. Thus, the ASPSPs should provide the competent authorities with a list of the TPPs that have tested their API and the feedback received. 

However, the EBA is of the view that the industry is able to provide information about TPPs willing to test and APIs ready to be tested. The EBA highlights that there are already nine initiatives, which provide such information and support the ASPSPs and TPPs during the testing period. All of them are also represented in the Working Group.

Issue 6: Testing by entities that are not authorised TPPs

Issue summary: Several participants raised the issue as to whether ASPSPs should enable (i) entities that are not authorised Payment Service Providers (PSPs), or (ii) entities that have applied for authorisation as a TPP, to test their API. If the ASPSPs are required to offer access, then the EBA should specify the level of service to these entities. 

EBA clarification: The EBA has already provided an answer to this question in the EBA’s Q&A tool. 

In accordance with Article 30 (5) RTS, ASPSPs should provide access to the testing facility to all authorised TPPs such as Payment Initiation Service Providers (PISPs), Payment Service Providers using card-based payment instruments (CBPIIs) and Account Information Service Providers (AISPs) and to all entities that have applied for authorisation.

Information about the entities that have applied for authorisation as TPPs may be provided by the national competent authorities (NCAs). The entities may receive an application confirmation by the NCA and hand it in when requesting access to the testing facilities. Alternatively, the ASPSPs may check the status of a TPP by considering the information provided by the NCA.

The EBA clarifies that the relationship between ASPSPs and entities that are not authorised as TPPs is outside the scope of PSD2. In general, there are no legal requirements preventing ASPSPs from making the testing interface also accessible for the referred entities. However, if the ASPSPs decide to do so, they may grant the entities a different level of service and support from these market participants. Furthermore, the EBA specifies that ASPSPs are not required to include information about non-authorised entities when providing the NCAs with a summary of the testing results. 

Issue 7: Timelines for the Fall-Back exemption process

Issue summary: The participants requested more transparency with regard to timelines for the process until 14 September 2019 for ASPSPs wishing to apply for an exemption from the Fall-Back mechanism. 

EBA clarification: The EBA provides an overview with the indicative timelines across the 28 EU Member States. 

Issue 8: Portability of “wide-usage” data between Member States

Issue summary: One of the participants asked if the data proving wide usage of the API for at least 3 months collected in one Member State can be used as evidence in a further Member State by another ASPSP using the same dedicated interface and belonging to the same ASPSP Group. 

EBA clarification: The question has already been answered by the EBA in the EBA’s Q&A tool. 

Many corporate groups decide to implement the same API across different entities and different Member States, i.e. a dedicated interface is developed as a single group solution. 

Each legal entity has to apply separately for an exemption from the contingency mechanism in the Member State where it has been authorised. Thus, each competent authority (CA) has to check if the four conditions specified in Article 33 (6) RTS on SCA&CSC are met by the ASPSP. The CA is not obliged to consider whether the condition of wide usage is met solely based on evidence provided by other ASPSPs in other markets.

In the event that the API has not been used in the Member State, for example due to the absence of TPPs in the respective Member State or due to a limited customer base, the CA may consider the data obtained for the same interface in another Member State as evidence of the wide usage of the API.

Issue 9: Passporting and eIDAS certificates

Issue summary: Considering the fact that eIDAS certificates do not contain any information on passporting, a participant in the Working Group raised the issue as to whether ASPSPs should check whether TPPs are authorised to operate in their Member State under the free provision of services or the right of establishment. 

EBA clarification: The question has already been answered by the EBA in the EBA’s Q&A tool. 

The EBA is of the view that the ASPSPs are not required to carry out any additional checks. Since the eIDAS certificates do not provide any information on passporting and the ASPSPs are not obliged to check this information, the EBA states that ASPSPs should not block the access to an account based on the absence of information as to whether the TPP is allowed to provide services in the host Member State or not. 

Issue 10: Use of eIDAS certificates during the wide-usage period prior to 14 September 2019

Issue summary: Some participants asked whether the TPPs are obliged to use an eIDAS certificate when accessing an API during the 3 month wide-usage period prior to the application date of the RTS on SCA&CSC on 14 September 2019.

EBA clarification: This question has also already been answered by the EBA in the EBA’s Q&A tool. 

According to Article 34 RTS the PSPs should use eIDAS certificates for the purpose of identification. Furthermore, Article 38 specifies that the RTS apply from 14 September 2019. Consequently, the ASPSPs should rely on eIDAS certificates for identification purposes from the date of application of the RTS, i.e. 14 September. 

However, to fulfil the conditions for obtaining an exemption from the obligation to build a Fall-Back as specified in Article 33, the testing API should technically be the same as the one provided from 14 September 2019 onwards. In other words, it should include eIDAS certificates for the purpose of identification. Furthermore, the EBA stresses that the early adoption of eIDAS certificates is beneficial for all market participants, i.e. ASPSPs, AISPs, PISPs and CBPIIs.

Issue 11: The use by TPPs of agents and outsourcers for accessing payment account data 

Issue summary: The Working Group raised various issues regarding the TPPs’ use of agents or technical service providers (TSPs) for accessing customers’ payment accounts. The participants stress that, in their view, due to the fact that agents and TSPs are not PSPs and as such not subject to eIDAS certificates, the ASPSPs should only be required to identify the principal TPP stated in the eIDAS certificate. 

The Working Group highlighted that for the purpose of transparency and greater clarity for the customer, the TPPs should be encouraged to declare whether an agent is acting on their behalf. Furthermore, they argue that if this information is transported by the API, the ASPSPs should be encouraged to inform the customer (i.e. PSU) that their account information is accessed by TPP’s agent.

In addition, the Working Group stressed that, since the TPP is liable for all agents and TSPs acting on its behalf, there should be an automated refund mechanism in the event that the agent or the TSP is fraudulent. In the absence of such mechanism, the ASPSPs should be allowed to warn the PSU and potentially to block the transaction.

EBA clarification: All TPPs are required by Article 34 RTS to identify themselves through an eIDAS certificate when accessing the PSU’s payment account. Even if the TPPs are represented by an agent or a TSP acting on their behalf, the eIDAS certificate should clearly identify the primary TPP. If technically feasible, the name of the agent or TSP may be included in the eIDAS certificate in addition to the principal PSP’s name. However, this is not a legal requirement.

As clarified in the EBA Opinion on the use of eIDAS certificates under the RTS on SCA & CSC, the TPP is fully responsible for the actions of its agents and outsourced providers and for updating the eIDAS certificate used by them.

The EBA stresses that, according to Title III of PSD2, the payment institutions should ensure that the agents acting on their behalf inform the PSUs. Thus it is not the responsibility of the ASPSPs to inform the customers that their account is accessed by an agent.

With regard to the ability of the ASPSPs to warn the PSU and/or block the access, the EBA refers to Article 68 (5) RTS. According to this Article, the ASPSPs are allowed to block the access in case of objectively justified and duly evidenced reasons. In such case, the ASPSPs are supposed to report the incident immediately to the NCA. It is up to the ASPSPs to decide whether also to inform the PSU.

Issue 12: “Widely used” and “design to the satisfaction of the TPPs” conditions

Issue summary: One participant expressed concerns that the requirements for the involvement of TPPs in the process of granting an exemption for a dedicated interface has been toned down. According to the participant, this is extremely apparent with regard to design and testing to the satisfaction of TPPs and the wide-usage conditions. In the participant’s view, this could lead to mandatory use of inappropriate APIs.

EBA clarification: The EBA explains that these concerns have been addressed during the consultation phase of the EBA Guideline on the conditions to benefit from an exemption from the Fall-Back mechanism, and that the Guidelines have been respectively amended so that the involvement of TPPs has been strengthened.

For example, the ASPSPs have to report to the NCA the feedback they received from the TPPs that have tested their APIs as well as measures they have taken to address the reported issues. Furthermore, in order to meet the “design” condition, the ASPSPs have to prove that their dedicated interface complies with the legal requirements. The “wide-usage” condition also considers the number of TPPs that took part in the testing of the API. 

Issue 13: ASPSPs relying on eIDAS certificates

Issue summary: Several industry participants expressed concerns that there could be discrepancies between the information contained in the eIDAS certificates and the information contained on the EBA and national registers. In case of revoked authorisation the risk for information mismatch is extremely high.

They also raised concerns about a potential time gap between the withdrawal of the authorisation and the updating of the registers. According to these participants, the NCAs should inform the qualified trust service provider (QTSP) that issued the eIDAS certificate when the authorisation of a TPP has been withdrawn. 

One representative of the Working Group queried whether there is a reasonable time for providing account data to a TPP with revoked authorisation according to the registers, but with a still active eIDAS certificate.

EBA clarification: According to the RTS on SCA & CSC, when TPPs identify themselves to the ASPSPs via an eIDAS certificate the ASPSPs should grant the TPPs access to account data. The ASPSPs are not legally required to rely on any other sources of information for the purpose of identification of TPPs.

The ASPSPs may, however, conduct additional checks to prove the authorisation of a TPP, for example by checking the registration status of the TPP in the EBA or national register. The EBA stresses that these further checks should not create obstacles to the provision of account data as required in Article 32 (3). 

In case of a revocation of authorisation, Article 13 (3) PSD2 requires the NCAs to make the information public and to update not only their national register but also the EBA PSD2 register. The EBA argues, however, that the updating of the information in industry directories is not to be done by the EBA or NCAs.

With regard to the proactive role of NCAs in the withdrawal of eIDAS certificates, the EBA points out that, in the EBA Opinion on the use of eIDAS certificates under the RTS on SCA & CSC (EBA-Op-2018-7), a process for NCAs requesting the revocation of the eIDAS certificate has been suggested. However, the process is on a voluntary basis and is intended to assist the NCAs in notifying the QTSPs that the authorisation status or the scope of authorised activities of a TPP has been changed. 

The EBA notes that the QTSPs remain responsible for the reliability and the accuracy of the issues certificates. The PSPs, in turn, are responsible for the reliability of the certificates they use for identification purposes. It should be noted, that Member States shall prohibit natural or legal persons that are neither explicitly excluded from the PSD2 scope nor PSPs from providing payment services. This means that requesting access to a payment account without authorisation is a breach of the PSD2 and of the respective national legislation implementing the Directive.

In order to increase transparency with regard to NCAs, which will follow the suggested process for requesting a revocation of an eIDAS certificate, the EBA provides an overview of the NCAs’ indications as per 2 May 2019.

How we can help

PwC team brings extensive legal, regulatory and compliance experience in financial services to help clients negotiate the risks and capitalise on the opportunities created by the new rules. 

Our service offering is available here.

A brief overview of the first set of clarifications can be found in our first blog post.


Ihre Ansprechpartner

Philipp Rosenauer

Head Data Privacy | ICT | Implementationᐩ, Zurich, PwC Switzerland

+41 58 792 18 56

Email