EBA/GL/2018/07
4 December 2018

EUROPEAN BANKING AUTHORITY

Final report

Guidelines on the conditions to benefit from an exemption from the contingency mechanism under Article 33(6) of Regulation (EU) 2018/389 (RTS on SCA & CSC)

1. Executive Summary 3

2. Abbreviations 5

3. Background and rationale 6

4. Guidelines 14

5. Accompanying documents 26

5.1 Cost-benefit analysis / impact assessment 26

5.2 Feedback on the public consultation and on the opinion of the BSG 26

1. Executive summary

Directive (EU) 2015/2366 on payment services in the internal market (PSD2) entered into force on 12 January 2016 and applies as of 13 January 2018. In fulfilment of the objectives of PSD2, Article 98(1) of PSD2 mandated the EBA to develop regulatory technical standards (RTS) on strong customer authentication and common and secure communication. The RTS were submitted and published by the EBA on 23 February 2017 and regulate the access by account information service providers (AISPs), payment information service providers (PISPs) and card-based payment instrument issuers(CBPIIs) to the customer payment accounts held with account servicing payment service providers (ASPSPs).

The final version of the RTS, which was subsequently published on 13 March 2018 as an EU Regulation in the Official Journal of the EU and will become applicable as of 14 September 2019, contained several amendments that the EBA had not originally submitted to the Commission. In particular, Article 33(6) of the RTS sets out the conditions that must be met by an ASPSP that wishes to provide access via a dedicated interface in order to be exempted from the obligation to implement the contingency mechanism (fall back) in Article 33(4) of the RTS. The RTS calls for competent authorities (CAs), ‘after consulting EBA’, to exempt ASPSPs from the requirement to implement the fall back mechanism if the ASPSP can show that it meets the four conditions in Article 33(6) of the RTS.

In reviewing the amendments introduced in the RTS, the EBA has identified a need to provide additional clarity regarding the conditions that need to be met to benefit from an exemption, in order to ensure a consistent application of these conditions across the 28 EU Member States. On 13 June 2018, the EBA therefore issued a Consultation Paper (CP) with draft Guidelines (GL) for a 2-months consultation period. The EBA received 64 responses to the CP, representing a wide range of market participants. The EBA has assessed these responses and identified approximately 170 different issues and requests for clarification that respondents had raised.

The EBA agreed with some of these proposals, and their underlying arguments, and has made a number of changes to the GL as a result. To address the concerns raised by respondents regarding the involvement of third-party payment service providers (TPPs) in the exemption process, the EBA has amended GL 6 so that ASPSPs are required to provide the CA, as part of the results of the testing, with the feedback the ASPSP has received from TPPs that have participated in the testing, together with an explanation of how the ASPSP has addressed any issues identified during the testing.

Furthermore, the EBA has amended GL 8 and has also clarified that ASPSPs are required to provide the CA with an explanation of the problems reported by TPPs regarding the ASPSP’s production interface that have not been resolved by the ASPSP in accordance with the service level targets under GL 2.1.

In addition, the EBA has added a new GL 6.7 which provides that CAs may also take into account, when assessing the ASPSP’s compliance with the design condition in Article 33(6)(b) of the RTS, any problems reported by TPPs to the CA in relation to the elements to be tested in accordance with GL 6.5. In addition, the EBA has amended GL 6.5 (new 6.1(b)), so that all ASPSPs are required to provide the CA with information on their engagement with TPPs, regardless of whether the ASPSP has implemented a market initiative standard or not.

In order to address the concerns raised by respondents regarding the ‘wide usage’ condition, the EBA has amended GL 7.1 and 7.2 to clarify that, in assessing whether or not an ASPSP meets this condition, CAs should not only consider the number of TPPs that have used the ASPSP’s production interface for offering services to their customers during the period referred to in Article 33(6)(c) of the RTS, but also take into account the number of successful requests sent by TPPs via the dedicated interface during that period, the number of TPPs available in their jurisdiction to use the interface, the steps that the ASPSP has taken to achieve ‘wide usage’, and the evidence submitted to the CA in the context of GL 6 and 8 regarding the results of the testing and the resolution of issues raised by TPPs.

Furthermore, in order to increase the transparency about the availability and performance of the ASPSPs’ dedicated interfaces and to facilitate monitoring by CAs, the EBA has amended GL 3 so that ASPSPs are required to publish data on the availability and performance of their dedicated interface, and to do so in a way that enables TPPs and PSUs to compare the daily availability and performance of the dedicated interface with the availability and performance of each of the interfaces made available by the ASPSP to its own PSUs. Moreover, the EBA has clarified in GL 2 the calculation of the KPIs for measuring the availability and performance of the dedicated interface, and has introduced a new KPI in GL 2.3(d) for measuring the ASPSP’s error response rate in the transmission of data to TPPs via the dedicated interface.

The EBA also made a number of changes to GL 5 to provide more clarity regarding the assessment of obstacles to the provision of account information services (AIS) and payment initiation services (PIS). These changes include the requirement in GL 5.1(b) for all ASPSPs to explain to the CA why the method(s) of carrying out the authentication procedure of the PSU do(es) not create obstacles to the provision of AIS or PIS, irrespective of whether the ASPSP has implemented one or several methods of access (redirection, decoupled, embedded or a combination thereof). Finally, the EBA has amended GL 5.2(d) (new 5.1(b)), so that ASPSPs are required to provide the CA with evidence that their dedicated interface does not give rise to unnecessary delay or friction in the customer journey when accessing their account via an AISP or PISP that would directly or indirectly dissuade the customer from using the services of an AISP or PISP.

Next steps

The GL will be translated into the official EU languages and published on the EBA website. The deadline for CAs to report whether or not they comply with the GL will be two months after the publication of the translations. The GL will apply from 1 January 2019.

2. Abbreviations

AIS	account information services
AISP	account information service provider
API	application programming interface
ASPSP	account servicing payment service provider
BSG	Banking Stakeholder Group
CA	competent authority
CBPII	card-based payment instrument issuer
CP	Consultation Paper
CSC	common and secure communication
EBA	European Banking Authority
EBA Opinion	Opinion of the European Banking Authority on the implementation of the RTS on SCA and CSC (EBA-Op-2018-04) of 13 June 2018
eIDAS	electronic identification, authentication and trust services
GL	Guidelines
IA	impact assessment
KPI	key performance indicator
PIS	payment initiation services
PISP	payment initiation service provider
PSC	personalised security credentials
PSD2	Directive (EU) 2015/2366 on payment services in the internal market
PSP	payment service provider
PSU	payment service user
RTS	Commission Delegated Regulation (EU) 2018/389 with regard to regulatory technical standards for strong customer authentication and common and secure open standards of communication
SCA	strong customer authentication
TPP	third party payment service provider

3. Background and rationale

3.1 Background

1. Directive (EU) 2015/2366 on payment services in the internal market (PSD2) entered into force on 12 January 2016 and applies as of 13 January 2018. PSD2 enshrined the right of the newly regulated account information service providers (AISPs), payment information service providers (PISPs) and card-based payment instrument issuers (CBPIIs) to access customer payment accounts held with account servicing payment service providers (ASPSPs), based on the customers’ explicit consent.

2. In fulfilment of the objectives of PSD2 of enhancing competition in the EU payments market, facilitating innovation, protecting consumers, increasing security and contributing to a single EU market in retail payments, Article 98(1) of PSD2 mandated the EBA to develop regulatory technical standards (RTS) on strong customer authentication (SCA) and common and secure communication (CSC). The RTS provide detail on the new security requirements under PSD2 and regulate the access of AISPs, PISPs and CBPIIs to the customer payment account data held with ASPSPs.

3. The final version of the RTS, which was subsequently published on 13 March 2018 as an EU Regulation in the Official Journal of the EU and which will become applicable as of 14 September 2019, contained several amendments that the EBA had not originally submitted to the Commission. In particular, Article 33(4) of the RTS requires ASPSPs that have opted to offer access to payment accounts via a dedicated interface to set up a contingency mechanism (the fall back) to allow AISPs, PISPs and CBPIIs to make use of the ASPSP’s customer-facing interface in the event that the dedicated interface does not perform in accordance with the levels of availability and performance provided for in Article 32 of the RTS. Article 33(6) of the RTS provides that CAs, ‘after consulting EBA’, shall exempt ASPSPs from the requirement to implement the fall back if the ASPSP can show that it meets the four conditions in Article 33(6) RTS.

4. In reviewing the amendments and additional requirements that were introduced in the RTS, the EBA has identified a need to provide additional clarity regarding the conditions that need to be met by ASPSPs in order to benefit from an exemption from the fall back. Against this background and in order to ensure that these conditions are consistently applied across the 28 EU Member States, the EBA has decided to issue Guidelines (GL) on the conditions and elements that CAs should consider in order to determine whether or not an ASPSP qualifies for an exemption under Article 33(6) of the RTS.

5. On 13 June 2018, the EBA published a Consultation Paper (CP) with the draft GL for a 2-months consultation period. The EBA received 64 responses to the CP representing a wide range of market participants, including ASPSPs, third party payment service providers (TPPs), technology service providers and consumer representatives.

6. The EBA has reviewed and assessed the responses and has identified in the process approximately 170 different issues and requests for clarification that the respondents had raised. The rationale section later in this chapter provides details on the assessment of the six main concerns that were raised, while the feedback table in section 5.2 provides an exhaustive and comprehensive assessment of all of the issues and requests that the EBA received as well as the changes that the EBA decided to make to the GL, where applicable, as a result. Chapter 4 presents the final GL themselves.

3.2 Rationale

7. Overall, the respondents supported the EBA in developing these GL to provide a consistent application of the conditions to be met to benefit from an exemption across all Member States.

8. The main concerns that arose during the consultation and that resulted in the EBA making changes to the GL related to: (1) the measuring of the availability and performance of the dedicated interface and the comparison of said performance with the interface(s) made available to the payment service user (PSU); (2) the involvement of TPPs in the exemption process; (3) the assessment of the design condition; (4) the assessment of obstacles; (5) the ‘widely used’ condition; and (6) the timelines for meeting the conditions to benefit from an exemption ahead of the 14 September 2019 deadline. Each of these concerns is addressed below in turn.

The measuring of the availability and performance of the dedicated interface

9. Respondents expressed diverging views regarding the benchmark against which the availability and performance of the dedicated interface should be compared, reflecting the general diversity of the stakeholders that submitted the comments. Some respondents were of the view that the benchmark should be the customer interface with the highest level of availability and performance, while other respondents were of the view that the availability and performance of the dedicated interface should be benchmarked against the ‘equivalent’ customer interface for the channel chosen by the customer for accessing their account. The latter respondents argued that the customer-facing interfaces may offer access to a different scope of data and different service level targets, and that, therefore, it would not be appropriate to compare the dedicated interface with the best performing PSU interface.

10. Having considered these comments, the EBA arrived at the view that, in line with Article 32(2) of the RTS, the key performance indicators (KPIs) and service level targets for the dedicated interface should match the best KPIs and service level targets across all the ASPSP’s customer-facing interfaces. This is because the availability and performance of the dedicated interface should be the same regardless of the channel used by the PSU. This clarification is provided in the revised GL 2.1.

11. As a result, and in accordance with Article 32(4) of the RTS, the EBA also amended GL 3.1(b) (new 3.2) such that ASPSPs are required to publish data on the availability and performance of the dedicated interface and of each of the interfaces made available to the PSUs for directly accessing their accounts online, and to do so in a way that enables TPPs and PSUs to compare the availability and performance of the dedicated interface with each of the said PSU interfaces.

12. The EBA acknowledges that it is not within the scope of the RTS, and therefore also not within the scope of the GL, to prescribe KPIs for the PSU interface(s). Consequently, the GL prescribe only a minimum set of KPIs for the dedicated interface.

13. Most respondents agreed with the KPIs proposed in the draft GL 2, but a number of respondents had comments on the calculation of these KPIs and were of the view that more KPIsshould be added to measure the performance of the dedicated interface. The EBA agreed with some of the arguments put forward by respondents and made a number of changes to the draft KPIs. These changes include simplifying the KPIs used for measuring the availability of the dedicated interface, which no longer distinguish between ‘planned’ and ‘unplanned’ unavailability, given that the availability of the dedicated interface should be calculated on a 24 hour basis.

14. In addition, the EBA has clarified the calculation of the downtime KPI in GL 2.4(c) and also that the KPI on the ASPSP’s response time for providing TPPs with all the information required in accordance with PSD2 and the RTS should be calculated as a daily average.

15. The EBA also introduced a new KPI on the error response rate in the new GL 2.3(d), to address the concerns raised by a number of respondents, who were of the view that more KPIs measuring performance should be added. The EBA concluded that other KPIs suggested by some respondents, such as a KPI measuring the retention rate of TPPs’ customers, could not be measured by the ASPSPs and could not, therefore, be plausibly added. The EBA also clarifies that the calculation of the KPIs in GL 2 should take into account any unavailability, network latency or errors that are within the ASPSP’s responsibility, including where the ASPSP has outsourced certain components related to the implementation of the dedicated interface to a technical service provider.

The involvement of TPPs in the exemption process

16. An overarching comment that was raised by a large number of TPPs that responded to the consultation was that the GL should establish mechanisms to allow TPPs to be more involved in the exemption process and to offer them an opportunity to provide the CA with feedback regarding their own assessment of the ASPSP’s test or production interfaces.

17. Having assessed these comments and the underlying reasoning, the EBA has made a number of changes to the GL to clarify that, for the purpose of the exemption, ASPSPs will need to demonstrate TPPs’ involvement in the design and testing of the dedicated interface. These changes include the new GL 6.6, which requires ASPSPs to provide the CA, as part of the results of the testing, with the feedback received from TPPs that have participated in the testing, together with an explanation of how the ASPSP has addressed any issues identified during testing. Furthermore, the EBA has amended GL 8 and has also clarified that ASPSPs should provide the CA with an explanation of the problems reported by TPPs regarding the ASPSP’s production interface that have not been resolved by the ASPSP in accordance with the service level targets under GL 2.1.In addition, the EBA has added a new GL 6.7 which provides that CAs may also take into account, when assessing the ASPSP’s compliance with the design condition in Article 33(6)(b) of the RTS, any problems reported by TPPs to the CA in relation to the elements to be tested in accordance with GL 6.5.

18. Furthermore, the EBA has extended the requirement in GL 6.5 (new 6.1(b)) for ASPSPs to provide the CA with information on their engagement with TPPs, such that it now applies to all ASPSPs, regardless of whether they have followed an API market initiative standard or not.

19. Moreover, the EBA has amended GL 7.1 and 7.2 so as to require all ASPSPs to demonstrate to the CA that they have made all reasonable efforts to achieve ‘wide usage’ of their dedicated interfaces by TPPs, including by communicating the availability of the dedicated interface and encouraging its use by TPPs.

20. In addition, in order to increase the transparency about the availability and performance of the ASPSPs’ dedicated interfaces, the EBA has amended GL 3.1(b) (new 3.2) to require ASPSPs to publish data on the availability and performance of the dedicated interface in a way that enables TPPs, PSUs and also CAs to compare the daily availability and performance of the dedicated interface with the availability and performance of each of the interfaces made available by the ASPSP to its own PSUs for accessing their accounts online. This requirement, together with the obligation in GL 2.1 for the ASPSP to define service level targets for the dedicated interface that are at least as stringent as those for its customer-facing interfaces, will facilitate the monitoring by CAs of the ASPSPs’ on-going compliance with the levels of availability and performance mandated by Article 32 of the RTS, which will be part of the general supervisory activity of CAs.

21. The EBA strongly encourages TPPs to test and use the ASPSPs’ dedicated interfaces as well as provide feedback to ASPSPs, in order to allow the ASPSP to correct the problems identified, with the end goal of supporting the development of high-performing dedicated interfaces that facilitate innovation and competition and deliver positive consumer outcomes.

The assessment of the design of the dedicated interface

22. Respondents generally agreed with the proposals in GL 6 on the design of the dedicated interface and many were of the view that the EBA should encourage market participants to make use of standardised specifications for application programming interfaces (APIs) developed by API initiatives. However, some respondents were of the view that the GL should clarify that following an API market initiative standard does not ‘guarantee’ an exemption and that ASPSPs that claim compliance with such standards should still have to demonstrate their compliance with the RTS. Respondents also suggested that tools developed by API market initiatives to carry out what is commonly referred to as ‘conformance testing’ of the ASPSPs’ conformance with the standards of the initiative could be a helpful and pragmatic way to evidence this.

23. The EBA shares the respondents’ view that API standardised specifications developed by market initiativesin accordance with the requirements in PSD2 and the RTS, potentially reduce the fragmentation of the API landscape across the EU, facilitate market entry for new PSPs, allow easy upscaling of the activities of those market entrants, and foster competition and innovation. This being said, the EBA also agrees that following such industry standards is not a guarantee that an ASPSP would meet the design condition under Article 33(6) of the RTS and therefore obtain an exemption. Furthermore, while conformance tools may assist ASPSPs when demonstrating to their CAs that they meet the requirements for an exemption, this can only be indicative to the CA as a useful piece of evidence, on the basis that those standards are intended to comply with the requirements in PSD2 and the RTS. However, conformity with those standards is not a guarantee that the dedicated interface itself, as implemented in the ASPSP’s systems, ultimately complies with the requirements in PSD2 and the RTS.

24. As a result of the above, the EBA has made a number of changes to GL 6. These changes include the clarification that all ASPSPs should provide their CA with evidence that the dedicated interface meets the legal requirements for access and data in PSD2 and the RTS (see new GL 6.1(a)). Where the ASPSP has implemented an API standard that has been developed by an API market initiative, the GL also now state that the information required under GL 6.1(a) may consist of information regarding the standard that the ASPSP has implemented, whether or not the ASPSP has deviated in any specific aspect from such standard and, if so, how it has deviated and how it meets the requirements in PSD2 and the RTS (see new GL 6.3(a)). Finally, the GL also specify that, where available, the ASPSP, in support of its application, may provide the CA with the results of the conformance testing developed by the API initiative, attesting compliance of the dedicated interface with the standard implemented (see new GL 6.3(b)).

The assessment of obstacles to the provision of AIS and PIS

25. On GL 5, a number of respondents were of the view that what is commonly referred to as ‘redirection’ (i.e. where a PSU using the services of an AIPS, PISP or CBPII is redirected to the ASPSP’s website for authentication before being redirected back to the AIPS, PISP or CBPII) is an obstacle. The EBA reiterates the view expressed in the EBA Opinion from June 2018 that redirection is not, in itself, an obstacle to AIS or PIS, but that it ‘may’ be so, if the ASPSP implements it in a manner that creates delay or friction in the customer experience that would dissuade PSUs from using the services of AISPs or PISPs.

26. This being said, the EBA agrees that the customer experience is of primary importance and therefore sees merit in providing further detail in the amended GL 5.1(b). The amended GL 5.1(b) requires ASPSPs to provide the CA with evidence that the dedicated interface does not give rise to unnecessary delay or friction in the customer experience when accessing their account via a PISP, AISP or CBPII, such as unnecessary or superfluous steps, or the use of unclear or discouraging language, that would directly or indirectly dissuade the PSUs from using the services of a PISP, AISP or CBPII. The EBA is of the view that the evidence required under GL 5.1(b) may include, but is not limited to, the results of customer testing, examples of customer experience journeys when using an AISP or PISP (for instance using screenshots), or other types of evidence that CAs may choose to require in support of GL 5.1(b).

27. The EBA has also amended GL 5.1 to require all ASPSPs to explain to their CA why the method(s) of carrying out the authentication procedure of the PSU do(es) not create obstacles, irrespective of whether the dedicated interface supports only one or several methods of access (redirection, decoupled, embedded or a combination thereof). This is reflected in the amended GL 5.1(b).

The ‘widely used’ condition

28. While some respondents agreed with the approach in GL 7, a number of respondents were of the view that the GL should be more specific on what ‘widely used’ entails. In addition, some respondents disagreed with GL 7.2 and were of the view that it dilutes the ‘widely used’ condition in Article 33(6)(c) of the RTS to ‘widely available’. The latter respondents argued that, if the interface is not ‘widely used’, ASPSPs should not be exempted.

29. The EBA reiterates that the assessment of the ‘widely used’ condition in Article 33(6)(c) of the RTS will be challenging, particularly in the crucial period leading up to 14 September 2019. This is because of a number of factors, including the fact that, in some Member States, there are, to date, either few or no authorised PISPs, AISPs or CBPIIs operating that would be in a position to use the dedicated interfaces developed by ASPSPs.

30. Furthermore, there is no obligation on PISPs, AISPs or CBPIIs to use the dedicated interface of an ASPSP prior to the application date of the RTS, because no legal obligation arises for market participants to comply with the RTS prior to its application date, which, in line with Article 115(4) of PSD2 and Article 38(2) of the RTS, is 14 September 2019. As a result, some TPPs may choose not to do so until the RTS apply and may instead prefer to continue screen scraping until then. Others may simply not have the necessary resources to test with multiple ASPSPs at the same time and may therefore need to select which dedicated interfaces to test and subsequently use for offering services to their customers, without this necessarily being reflective of the quality of the dedicated interfaces that are offered by ASPSPs and that the TPPs have chosen not to use.

31. For these reasons, the EBA remains of the view that it is not feasible to set a one-size-fits-all numerical threshold of what ‘widely used’ entails.

32. This being said, the EBA acknowledges that the draft GL 7.2 that was proposed in the CP would benefit from further clarifications. The EBA has therefore amended both GL 7.1 and 7.2 to clarify that CAs should take into account a broader range of factors when assessing the ‘widely used’ condition, including:

the number of TPPs in their jurisdiction available to use the ASPSP’s dedicated interface and those that have used it for offering services to their customers;
the number of successful requests sent by those TPPs via the dedicated interface during the period referred to in Article 33(6)(c) RTS;
the steps that the ASPSP has taken to achieve ‘wide usage’ and to encourage TPPs to use its dedicated interface; and
if there are any large discrepancies between the number of TPPs that have participated in the testing and those that have used the ASPSP’s production interface for offering services to their customers and, if so, the reasons for such discrepancies, that may indicate to the CA whether or not the conditions in Article 33(6) of the RTS are met.

33. In addition, the EBA has clarified in the new GL 7.2 that CAs should also consider, in their assessment of whether an ASPSP meets this condition, the evidence submitted in the context of GL 6 and 8, including the results of the testing and how the ASPSP has addressed any issues reported by TPPs.

34. This means that if the dedicated interface has not been used because there are no authorised TPPs in the market to use it, an ASPSP may still be granted an exemption if the CA is of the view, taking into account all input it has received, that the ASPSP took every reasonable step to achieve wide usage and that the fact that the dedicated interface was not used was due not to the ASPSP, nor to the quality of the interface, but simply to the absence of TPPs in the market.

35. The EBA also reminds respondents that the condition in Article 33(6) of the RTS should be assessed in relation to the production interface, i.e. where real PSU data are used for TPPs to provide services to their customers. By contrast, and as clarified in GL 6.5, non-real PSU data should be used during the testing referred to in Article 30(5) of the RTS.

The timelines for meeting the conditions to benefit from an exemption ahead of 14 September 2019

36. Many respondents were concerned that the timelines for meeting the conditions for an exemption ahead of the 14 September 2019 deadline are very tight.

37. The EBA reiterates that the RTS require all ASPSPs that have opted to offer access via a dedicated interface to implement the fall back mechanism, unless they receive an exemption from their CAs in accordance with Article 33(6) of the RTS by the date of application of the RTS. The EBA acknowledges that the timelines for meeting the conditions for an exemption ahead of the September 2019 deadline are indeed tight, but notes that it is not within the EBA’s power to change the timelines imposed by Article 115(4) of PSD2 and Article 38(2) and (3) of the RTS. The EBA strongly encourages ASPSPs to start testing and to launch the production interface as soon as possible ahead of the September 2019 deadline, and to engage with their CA as soon as possible before the September 2019 deadline. In so doing, they should take into account that CAs will also require time to carry out the assessments of a potentially large number of applications from ASPSPs and that the RTS require CAs to also consult with the EBA. This means that CAs may need to require ASPSPs to submit requests well in advance of the September 2019 deadline, which implies that ASPSPs would need to launch their testing facility before 14 March 2019 and the production interface earlier than 14 June 2019 in order to be able to provide evidence for each of the four criteria detailed in these GL.

38. The EBA would also like to remind respondents that, while Article 30(5) of the RTS requires ASPSPs to make their testing facility available to TPPs at least 6 months before the application date of the RTS, i.e. at the very latest by 14 March 2019, the RTS do not require ASPSPs to wait a certain period before launching their production interface. This means that an ASPSP does not need to wait a period of 6 months before launching the production interface. The ASPSP may choose to launch it at any time it deems appropriate after having considered the feedback from TPPs and made any relevant changes.

39. The EBA has therefore clarified in GL 7.3 that the testing referred to in Article 30(5) of the RTS may run concurrently with the 3-month period referred to in Article 33(6)(c) of the RTS, during which ASPSPs should ensure that their production interface is ‘widely used’ by TPPs for providing services to their customers. The EBA acknowledges that the reference to the ‘6- month’ testing in GL 7.3 that was proposed in the CP may not have been clear given that, as explained above, the testing period may be longer or shorter than 6 months and has therefore removed this reference.

EBA EUROPEAN BANKING AUTHORITY

4. Guidelines

EBA/GL/2018/07
4 December 2018

Guidelines

on the conditions to benefit from an exemption from the contingency mechanism under Article 33(6) of Regulation (EU) 2018/389 (RTS on SCA & CSC)

1. Compliance and reporting obligations

Status of these guidelines

1. This document contains guidelines issued pursuant to Article 16 of Regulation (EU) No 1093/20101 . According to Article 16(3) of Regulation (EU) No 1093/2010, competent authorities and financial institutions must make every effort to comply with the guidelines.

2. Guidelines set out the EBA’s view of appropriate supervisory practices within the European System of Financial Supervision or of how Union law should be applied in a particular area. Competent authorities as defined in Article 4(2) of Regulation (EU) No 1093/2010 to whom the guidelines apply should comply by incorporating them into their practices as appropriate (e.g. by amending their legal framework or their supervisory processes), including where guidelines are directed primarily at institutions.

Reporting requirements

3. According to Article 16(3) of Regulation (EU) No 1093/2010, competent authorities must notify the EBA that they comply or intend to comply with these Guidelines, or give reasons for non-compliance, by ([dd.mm.yyyy]). In the absence of any notification by this deadline, competent authorities will be considered by the EBA to be non-compliant. Notifications should be sent by submitting the form available on the EBA website to compliance@eba.europa.eu with the reference ‘EBA/GL/2018/07’. Notifications should be submitted by persons with appropriate authority to report compliance on behalf of their competent authorities. Any change in the status of compliance must also be reported to the EBA.

4. Notifications will be published on the EBA website, in line with Article 16(3) of Regulation No 1093/2010.

[1] Regulation (EU) No 1093/2010 of the European Parliament and of the Council of 24 November 2010 establishing a European Supervisory Authority (European Banking Authority), amending Decision No 716/2009/EC and repealing Commission Decision 2009/78/EC, (OJ L 331, 15.12.2010, p.12).

2. Subject matter, scope and definitions

Subject matter

These Guidelines specify the conditions, set out in Article 33(6) of Commission Delegated Regulation (EU) 2018/3892 (the RTS), to exempt the account payment service providers that have opted for a dedicated interface from the obligation to set up the contingency mechanism described in Article 33(4) of the RTS.

These Guidelines further provide guidance on how competent authorities should consult the EBA for the purposes of the exemption in accordance with Article 33(6) of the RTS.

Scope of application

These Guidelines apply in relation to the contingency measures for a dedicated interface set out in Article 33 of the RTS and, in particular, to the exemption from the obligation to set up a contingency mechanism in accordance with Article 33(4) of the RTS.

Addressees

These Guidelines are addressed to competent authorities as defined in point (i) of Article 4(2) of Regulation (EU) 1093/2010 and to payment service providers as defined in Article 4(11) of Directive (EU) 2015/2366 (PSD2) 3 .

Definitions

Unless otherwise specified, terms used and defined in PSD2 and the RTS have the same meaning in these Guidelines.

Date of application

These Guidelines apply from 1 January 2019.

[2] Commission Delegated Regulation (EU) 2018/389 of 27 November 2017 supplementing Directive (EU) 2015/2366 of the European Parliament and of the Council with regard to regulatory technical standards for strong customer authentication and common and secure open standards of communication, OJ L 69/23 (13.3.2018).

[3] Directive (EU) 2015/2366 of the European Parliament and of the Council of 25 November 2015 on payment services in the internal market, amending Directives 2002/65/EC, 2009/110/EC and 2013/36/EU No 1093/2010, and repealing 2007/64/EC, OJ L 337/36 (23.12.2015).

3. Guidelines

Guideline 1: Fulfilment of the conditions set out in Article 33(6) of Delegated Regulation (EU) 2018/389

1.1. Competent authorities should assess an account servicing payment service provider (ASPSP) as having fulfilled the four conditions set out in Article 33(6) of the RTS where the ASPSP is compliant with the requirements set out in Guidelines 2 to 8, subject to compliance with the requirements set out in PSD2 and the RTS.

1.2. ASPSPs should provide competent authorities with such information as is necessary to satisfy the competent authority that the requirements in Guidelines 2 to 8 are met.

Guideline 2: Service level, availability and performance

2.1. The ASPSP should define key performance indicators (KPIs) and service level targets, including for problem resolution, out of hours support, monitoring, contingency plans and maintenance for its dedicated interface, that are at least as stringent as those for the interface(s) made available to its own payment service users (PSUs) for directly accessing their payment accounts online.

2.2. The ASPSP should define at a minimum, the following KPIs of the availability of the dedicated interface:

a. the uptime per day of all interfaces; and

b. the downtime per day of all interfaces.

2.3. In addition to the KPIs on availability in Guideline 2.2, the ASPSP should define, at a minimum, the following KPIs for the performance of the dedicated interface:

a. the daily average time (in milliseconds) taken, per request, for the ASPSP to provide the payment initiation service provider (PISP) with all the information requested in accordance with Article 66(4)(b) of PSD2 and Article 36(1)(b) of the RTS;

b. the daily average time (in milliseconds) taken, per request, for the ASPSP to provide the account information service provider (AISP) with all the information requested in accordance with Article 36(1)(a) of the RTS;

c. the daily average time (in milliseconds) taken, per request, for the ASPSP to provide the card-based payment instrument issuer (CBPII) or the PISP with a ‘yes/no’ confirmation in accordance with Article 65(3) of PSD2 and Article 36(1)(c) of the RTS;

d. the daily error response rate – calculated as the number of error messages concerning errors attributable to the ASPSP sent by the ASPSP to the PISPs, AISPs and CBPIIs in accordance with Article 36(2) of the RTS per day, divided by the number of requests received by the ASPSP from AISPs, PISPs and CBPIIs in the same day.

2.4. For the purpose of calculating the availability indicators set out in Guideline 2.2 for the dedicated interface, the ASPSP should:

a. calculate the percentage uptime as 100% minus the percentage downtime;

b. calculate the percentage downtime using the total number of seconds the dedicated interface was down in a 24-hour period, starting and ending at midnight;

c. count the interface as ‘down’ when five consecutive requests for access to information for the provision of payment initiation services, account information services or confirmation of availability of funds are not replied to within a total timeframe of 30 seconds, irrespective of whether these requests originate from one or multiple PISPs, AISPs or CBPIIs. In such a case, the ASPSP should calculate downtime from the moment it has received the first request in the series of five consecutive requests that were not replied to within 30 seconds, provided that there is no successful request in between those five requests to which a reply has been provided.

Guideline 3: Publication of statistics

3.1 For the purpose of Article 32(4) of the RTS, the ASPSP should provide its competent authority with a plan for publication of daily statistics on a quarterly basis on the availability and performance of the dedicated interface as set out in Guidelines 2.2 and 2.3, and of each of the interfaces made available to its own PSUs for directly accessing their payment accounts online, together with information on where these statistics will be published and the date of first publication.

3.2 The publication referred to in Guideline 3.1 above should enable PISPs, AISPs, CBPIIs and PSUs to compare the availability and performance of the dedicated interface with the availability and performance of each of the interfaces made available by the ASPSP to its PSUs for directly accessing their payment accounts online on a daily basis.

Guideline 4: Stress testing

4.1 For the purpose of the stress tests referred to in Article 32(2) of the RTS, the ASPSP should have in place processes to establish and assess how the dedicated interface performs when subjected to an extremely high number of requests from PISPs, AISPs and CBPIIs, in terms of the impact that such stresses have on the availability and performance of the dedicated interface and the defined service level targets.

4.2 The ASPSP should undertake adequate stress testing of the dedicated interface including but not limited to:

a. the capability to support access by multiple PISPs, AISPs and CBPIIs;

b. the capability to deal with an extremely high number of requests from PISPs, AISPs and CBPIIs, in a short period of time without failing;

c. the use of an extremely high number of concurrent sessions open at the same time for payment initiation, account information and confirmation on the availability of funds requests; and

d. requests for large volumes of data.

4.3 The ASPSP should provide the competent authority with a summary of the results of the stress tests, including the assumptions used as a basis for stresstesting each of the elements in letters (a) to (d) of Guideline 4.2 above and how any issues identified have been addressed.

Guideline 5: Obstacles

5.1 The ASPSP should provide the competent authority with:

a. a summary of the method(s) of carrying out the authentication procedure(s) of the PSUs that are supported by the dedicated interface, i.e. redirection, decoupled, embedded or a combination thereof; and

b. an explanation of the reasons why the method(s) of carrying out the authentication procedure(s) referred to in paragraph (a) is/are not an obstacle, as referred to in Article 32(3) of the RTS, and how such method(s) allow(s) PISPs and AISPs to rely on all the authentication procedures provided by the ASPSP to its PSUs, together with evidence that the dedicated interface does not give rise to unnecessary delay or friction in the experience available to the PSUs when accessing their account via a PISP, AISP or CBPII or to any other attributes, including unnecessary or superfluous steps or the use of unclear or discouraging language, that would directly or indirectly dissuade the PSUs from using the services of PISPs, AISPs and CBPIIs.

5.2 As part of the explanation referred to in letter (b) of Guideline 5.1, the ASPSP should provide the competent authority with a confirmation that:

a. the dedicated interface does not prevent PISPs and AISPs from relying upon the authentication procedure(s) provided by the ASPSP to its PSUs;

b. no additional authorisations or registrations are required from PISPs, AISPs or CBPIIs, other than those imposed in Articles 11, 14 and 15 of PSD2;

c. there are no additional checks by the ASPSP on the consent, as referred to in Article 32(3) of the RTS, given by the PSU to the PISP or the AISP to access the information on the payment account(s) held with the ASPSP or to initiate payments; and

d. no checks on the consent given by the PSU to the CBPII in accordance with letter (a) of Article 65(2) of PSD2 are performed.

Guideline 6: Design and testing to the satisfaction of PSPs

6.1 For the purpose of evidencing compliance with the requirement in letter (b) of Article 33(6) of the RTS regarding the design of the dedicated interface, the ASPSP should provide the competent authority with:

a. evidence that the dedicated interface meets the legal requirements for access and data in PSD2 and the RTS, including:

i. a description of the functional and technical specifications that the ASPSP has implemented; and

ii. a summary of how the implementation of these specifications fulfils the requirements in PSD2 and the RTS; and

b. information on whether, and if so how, the ASPSP has engaged with PISPs, AISPs and CBPIIs.

6.2 For the purpose of these Guidelines, a ‘market initiative’ means a group of stakeholders that have developed functional and technical specifications for dedicated interfaces and, in doing so, have obtained input from PISPs, AISPs and CBPIIs.

6.3 Where the ASPSP is implementing a standard developed by a market initiative:

a. the information referred to in point (i) of letter (a) of Guideline 6.1 may consist of information regarding which market initiative standard the ASPSP is implementing, whether or not it has deviated in any specific aspect from such standard, and if so, how it has deviated and how it meets the requirements in PSD2 and the RTS;

b. the information referred to in point (ii) of letter (a) of Guideline 6.1 may include, where available, the results of the conformance testing developed by the market initiative, attesting compliance of the interface with the respective market initiative standard.

6.4 For the purpose of the requirement in letter (b) of Article 33(6) of the RTS regarding the testing of the dedicated interface, the ASPSP should make the technical specifications of the dedicated interface available to authorised PISPs, AISPs and CBPIIs or payment service providers that have applied to their competent authorities for the relevant authorisation in accordance with Article 30(3) of the RTS including, at a minimum, publishing a summary of the specification of the dedicated interface on its website in accordance with the third sub-paragraph of Article 30(3) of the RTS.

6.5 The testing facility should allow ASPSPs, authorised PISPs, AISPs and CBPIIs or payment service providers that have applied to their competent authorities for the relevant authorization to test the dedicated interface in a secure, dedicated testing environment with non-real PSU data, for the following:

a. a stable and secure connection;

b. the ability of ASPSPs and authorised PISPs, AISPs and CBPIIs to exchange the relevant certificates in accordance with Article 34 of the RTS;

c. the ability to send and receive error messages in accordance with Article 36(2) of the RTS;

d. the ability of PISPs to send, and of ASPSPs to receive, payment initiation orders and the ability of ASPSPs to provide the information requested in accordance with letter (b) of Article 66(4) of PSD2 and letter (b) of Article 36(1) of the RTS;

e. the ability of AISPs to send, and of ASPSPs to receive, requests for access to payment account data, and the ability of ASPSPs to provide the information requested in accordance with letter (a) of Article 36(1) of the RTS;

f. the ability of CBPIIs and PISPs to send, and of ASPSPs to receive, requests from CBPIIs and PISPs and the ability of the ASPSP to send a ‘yes/no’ confirmation to CBPIIs and PISPs in accordance with letter (c) of Article 36(1) of the RTS; and

g. the ability of PISPs and AISPs to rely on all the authentication procedures provided by the ASPSP to its PSUs.

6.6 The ASPSP should provide the competent authority with a summary of the results of the testing referred to in Article 30(5) of the RTS for each of the elements to be tested in accordance with letters (a) to (g) of paragraph 6.5 above, including the number of PISPs, AISPs and CBPIIs that have used the testing facility, the feedback received by the ASPSP from these PISPs, AISPs and CBPIIs, the issues identified and a description of how these issues have been addressed.

6.7 For the purpose of assessing whether the ASPSP meets the requirements in letter (b) of Article 33(6) of the RTS, the competent authority may also take into account any problems reported to it by PISPs, AISPs and CBPIIs in relation to Guideline 6.5 above.

Guideline 7: Wide usage of the interface

7.1 For the purposes of evidencing compliance with the requirement in letter (c) of Article 33(6) of the RTS, the ASPSP should provide the competent authority with:

a. a description of the usage of the dedicated interface for the period referred to in letter (c) of Article 33(6), including but not limited to:

(i) the number of PISPs, AISPs and CBPIIs that have used the interface to provide services to customers; and

(ii) the number of requests sent by those PISPs, AISPs and CBPIIs to the ASPSP via the dedicated interface that have been replied to by the ASPSP.

b. evidence that the ASPSP has made all reasonable efforts to ensure wide usage of the dedicated interface, including by communicating its availability via appropriate channels, including, where relevant, the website of the ASPSP, social media, industry trade bodies, conferences and direct engagement with known market actors.

7.2 In addition to the evidence referred to in Guideline 7.1, the competent authority should take into account the information received in the context of Guidelines 6 and 8 when assessing whether or not the ASPSP meets the requirement in Article 33(6)(c) of the RTS.

7.3 The 3-month period referred to in letter (c) of Article 33(6) of the RTS may run concurrently with the testing referred to in Article 30(5) of the RTS.

Guideline 8: Resolution of problems

8.1 For the purpose of Article 32(1) and letter (d) of Article 33(6) of the RTS, the ASPSP should provide the competent authority with:

a. information on the systems or procedures in place for tracking, resolving and closing problems, particularly those reported by PISPs, AISPs and CBPIIs; and

b. an explanation of the problems, particularly those reported by PISPs, AISPs and CBPIIs, that have not been resolved in accordance with the service level targets set out in Guideline 2.1.

Guideline 9: Consultation with the EBA

9.1 When consulting the EBA in accordance with Article 33(6) of the RTS, competent authorities should submit to the EBA the Assessment Form set out in Annex 1 in relation to each request for an exemption that they intend to grant. Competent authorities should not take any decision in relation to the exemption until the earlier of receiving the EBA’s comments on the request or one month from the date that the competent authority consulted the EBA. Competent authorities should take due account of the EBA’s comments when taking any decision on the request.

9.2 In derogation from Guideline 9.1, until 31 December 2019, competent authorities that have notified the EBA that they comply with these Guidelines can proceed to grant an exemption provided that they have consulted the EBA by informing it of their intention to grant the exemption using the Assessment Form set out in Annex 1. In such a case, the competent authorities may submit the Assessment Form covering one or more ASPSPs.

9.3 Competent authorities that have refused to exempt an ASPSP from the obligation to set up the contingency mechanism referred to in Article 33(4) of the RTS because its dedicated interface does not comply with the conditions set out in Article 33(6) of the RTS and with the requirements of Guidelines 2 to 8 should submit to the EBA the Assessment Form in Annex 1 without undue delay. The negative assessment should be provided for all denied requests to grant an exemption in accordance with Article 33(6) of the RTS.

9.4 Where an ASPSP is part of a group with subsidiaries in different Member States that will use the same dedicated interface, each of the competent authorities of those Member States should:

a. inform the other relevant competent authorities without undue delay if it intends to refuse to grant an exemption; and

b. on request from the other competent authorities and without prejudice to any confidentiality obligations, inform the other competent authorities of its reasoning why it intends to refuse to grant an exemption and, where relevant, of the issues reported by PISPs, AISPs and CBPIIs to the competent authority.

Annex 1 - Assessment Form

Assessment Submission

1)	Member State
2)	Name of the competent authority in the Member State
3)	Where the ASPSP is part of a group with subsidiaries in different Member States that will use the same dedicated interface	Confirmation that the competent authority has complied with Guideline 9.4 Yes No
4)	Contact person within the competent authority
5)	Date of submission to the EBA	DD/MM/YY
6)	Name(s) of the ASPSP(s) and its/their unique identification number, as shown in the relevant national register for credit institutions, payment institutions and e-money institutions
7)	Type(s) of ASPSP(s)	Credit Institution Payment Institution E-Money Institution
8)	Decision of the competent authority	Grant an exemption Refuse to grant an exemption
9)	If applicable, rationale for the refusal to grant an exemption

5. Accompanying documents

5.1 Cost-benefit analysis / impact assessment

Introduction

Article 16(2) of the EBA Regulation4 provides that the EBA should carry out an analysis of ‘the related potential costs and benefits’ of any guidelines it develops. The cost-benefit analysis should be part of a wider impact assessment analysis, according to the guidelines of the European Commission. This analysis should provide an overview of the findings regarding the problem to be dealt with, the options identified to remove the problem and their potential impacts.

This section presents the impact assessment (IA) with cost-benefit analysis of the provisions included in the GL. Given the nature of the study, the IA is high-level and qualitative in nature, respecting the principle of proportionality in conducting impact assessments.

Problem identification and baseline scenario

Article 33(6) of the RTS on strong customer authentication and common and secure open standards of communication (the RTS), sets out the conditions that must be met by an account servicing payment service provider (ASPSP) that has opted for a dedicated interface to benefit from an exemption to set up the contingency mechanism described in Article 33(4) of the RTS. However, these conditions are stated in relatively high-level terms and may be subject to different interpretations and outcomes across Member States. In addition, the timeline is tight for ASPSPs that intend to request an exemption before the RTS apply in September 2019. Unless an ASPSP that has opted for a dedicated interface receives an exemption from the obligation to set up the fall back mechanism by 14 September 2019, the ASPSP should implement the fall back mechanism (i.e. adapt the customer-facing interface to allow TPPs access in accordance with Article 33(4) of the RTS) by 14 September 2019.

Under the baseline scenario − the status quo – CAs, after consulting with the EBA in line with the requirement under Article 33(6) of the RTS, can exempt ASPSPs from the requirement to set up the contingency mechanism if they satisfy the conditions under Article 33(6) of the RTS.

The use of these Guidelines set the ground for common interpretation and assessment of these conditions, allowing CAs to consider different criteria when determining whether or not an ASPSP qualifies for the exemption laid down in the RTS. This process could potentially be time-consuming and resource-intensive for the EBA in assessing the consistent implementation of the conditions across the EU for each ASPSP, delaying the decision for an exemption.

[4] Regulation (EU) No 1093/2010 of the European Parliament and of the Council of 24 November 2010 establishing a European Supervisory Authority (European Banking Authority), amending Decision No 716/2009/EC and repealing Commission Decision 2009/78/EC

The lack of common and consistent application of the four criteria under Article 33(6) of the RTS can lead to a number of problems, including:

an uneven playing field for payment services providers in the EU; for example two ASPSPs with similar dedicated interfaces located in different Member States may be subject to different regulatory treatment − for example one benefiting from the exemption and the other not − if the conditions are not consistently assessed across Member States;
lack of a level playing field leading to distortions to the competition in the EU internal market regarding access by TPPs to payment account data;
regulatory arbitrage, i.e. ASPSPs may apply for an exemption in those Member States where the interpretation of the conditions to benefit from an exemption is more permissive;
increased uncertainty and potential costs for ASPSPs for developing the dedicated interface due to a lack of transparency surrounding the interpretation of the conditions for benefiting from the exemption; and
additional operational burden for cross-border groups due to different treatment of various entities belonging to the same group as a result of different supervisory practices.

Overall, such problems may hamper the effective and efficient functioning of the EU-wide single market for payments.

Policy objectives

The main objective of the present Guidelines is to ensure a common, uniform and consistent implementation of the conditions in Article 33(6) of the RTS in order to benefit from an exemption from the obligation to have a fall back mechanism in place.

More specifically, these Guidelines aim to ensure a level playing field across Member States, by establishing consistent supervisory practices regarding the interpretation and assessment of the aforementioned conditions. Common supervisory practices are also expected to facilitate cooperation between CAs with regard to cross-border groups. The Guidelines further aim to improve transparency and comparability, by providing explanations, clarifications and examples on how the relevant conditions to benefit from an exemption should be fulfilled.

The Guidelines are drafted taking into account the tight timeline for ASPSPs to meet all the necessary conditions for obtaining an exemption ahead of the 14 September 2019 deadline. They seek to provide clarity to ASPSPs regarding the conditions to benefit from an exemption and assist CAs in assessing a request for exemption. They also aim to propose a pragmatic approach regarding the interaction between CAs and the EBA and provide a practical solution for CAs in meeting their own obligation to consult with the EBA before granting the exemption, taking into account the large expected number of applications for exemption.

In general, the Guidelines aim to promote a more integrated and efficient European payments market, in line with the objectives of PSD2. They also contribute to the EBA’s objectives of enhancing supervisory convergence, and protecting payment services users in the EU.

Options considered and cost-benefit analysis

The Guidelines will affect primarily CAs and ASPSPs as well as other related parties, including thirdparty payment service providers that make use of the dedicated interface. In the light of the main objectives of these Guidelines, the following assessment aims to explain the costs and benefits of the available options considered.

General

Option 1a: Status quo (i.e. no intervention)

Option 1b: Issuing the Guidelines

Under Option 1a, CAs will need to develop a national assessment procedure for exempting ASPSPs from the contingency mechanism described in Article 33(4) of the RTS in accordance with the conditions set out in Article 33(6) of the RTS. This may create an inconsistent application of the exemption conditions across the EU and distort competition. It may also lead to uncertainty among payment system providers and a lack of confidence in the consistency of exemption decisions.

Under Option 1b, the Guidelines will provide CAs with a common set of criteria for assessing the exemption from the contingency mechanism under Article 33(6) of the RTS. The harmonisation of assessment criteria will bring several benefits. It will ensure a level playing field, minimise the risk of regulatory arbitrage and contribute to providing consistency across EU Member States. In return, this will support the growth of cross-border payment services and foster the development of a more efficient, competitive and integrated EU payment services market.

Providing more clarity regarding the assessment criteria can also increase transparency and legal certainty for payment service providers, ultimately contributing to enhance confidence in the EU payment market and facilitate sufficient protection of consumers. In addition, it can reduce the administrative burden for both CAs and payment service providers, allowing better resource allocation.

On the other hand, the implementation of these Guidelines would imply compliance costs for both CAs and payment service providers. It is reasonable to assume that most of the costs will be oneoff costs mainly referring to the set-up of a new assessment process, without disregarding the costs arising from the obligations introduced by the GL for ASPSPs, such as the quarterly publication of statistics (GL 3 requirement), which is based on the requirement in Article 32(4) of the RTS. However, ASPSPs will have experienced similar costs, even in the absence of the guidelines, in order to fulfil the conditions to benefit from an exemption under Article 33(6) of the RTS and, more generally, to satisfy the requirements in the RTS related to dedicated interfaces. The incremental costs of implementing the Guidelines are therefore expected to be minimal.

In conclusion, the estimated benefits from the application of Option 1b of the Guidelines are expected to be higher than the estimated costs that both CAs and payment service providers could face. Thus, Option 1b is retained.

The EBA consultation

As mentioned above, the process of consulting the EBA could become time-consuming and resource-intensive. Consequently, the EBA has considered three different options relating to the consultation of the CAs with the EBA.

Option 2a: Consultation on a firm-by-firm basis with EBA comments (or one month period).

Option 2b: Consultation only for complex cases that CAs wish to discuss with the EBA.

Option 2c: Consultation by informing the EBA of the intention to grant an exemption for one or more ASPSPs.

Option 2a reflects the general rule in which the EBA would fulfil its consultation role, with an obligation for CAs to notify the EBA for each request for an exemption received, where the CA intends to grant an exemption, in addition to compliance with the Guidelines. Such consultation would enable the EBA to determine if the application of the conditions is consistent between CAs. Such an approach should therefore be preferred under normal circumstances. CAs are expected to incur one-off costs for setting up the process, as well as on-going costs for providing the relevant information to the EBA on a firm-by-firm basis.

Given the large number of requests for assessments that are expected to be needed, as well as market expectations of an expeditious processing of the applications for exemption, the EBA has considered two additional alternatives, adopting a pragmatic approach.

Under Option 2b, provided that CAs have submitted a compliance notification to the EBA, the consultation would take place only if a CA would like to discuss a complex case of granting an exemption. A CA would not need to inform the EBA in advance if it were to refuse an exemption. This approach would allow CAs to have flexibility. However, this would not enable the EBA to have any visibility or information on all the ASPSPs for which a CA intends to grant an exemption. This would therefore make it difficult for the EBA to identify if the conditions are applied in a consistent manner between CAs. For that reason, the EBA has concluded that this would not meet the consultation requirement in Article 33(6) of the RTS. This option has therefore been discarded.

Under option 2c, provided that CAs have submitted a compliance notification to the EBA, CAs would comply with the requirement to consult the EBA by informing it of their intention to grant an exemption for one or several ASPSPs. CAs would not need to wait for comments from the EBA or for a certain period to elapse. CAs would also be able to provide a notification for more than one ASPSP at any given time, which would alleviate the burden for ASPSPs and enable CAs and the EBA to satisfactorily manage the high volumes of requests for an exemption expected in the short period leading up to September 2019. This would also enable the EBA to have an overall view of the exemptions being granted and take a view on the consistency of application of the conditions set out in Article 33(6) of the RTS. CAs are expected to incur one-off costs for implementing the Guidelines with limited on-going costs for interacting with the EBA.

Option 2a is retained as the general applicable rule and the pragmatic Option 2c is retained as a derogation from the principle until 31 December 2019 in order to enable CAs and the EBA to manage the large volume of applications for an exemption expected and the tight deadlines set in the RTS to be able to meet the conditions for an exemption ahead of 14 September 2019.

5.2 Feedback on the public consultation and on the opinion of the BSG

The EBA publicly consulted on the draft proposal contained in this paper.

On 13 June 2018, the EBA published a CP, for a 2-month consultation period that closed on 16 August 2018. The EBA received 64 responses to the CP, 46 of which were published on the EBA website. The EBA also held a public hearing that took place at the EBA’s premises on 25 July 2018 and was attended by around 50 representatives of various market participants.

The EBA has reviewed and assessed the responses received to the CP and has identified in the process approximately 170 different issues and requests for clarification that respondents had raised, submitting proposals to address the issues. The EBA agreed with some of these proposals and their underlying rationale, and has made a number of changes to the GL as a result.

In many cases several industry bodies made similar comments or the same body repeated its comments in response to different questions. In such cases, the comments and the EBA analysis are included in the section of this paper where the EBA considers them most appropriate.

Changes to the draft GL have been incorporated as a result of the responses received during the public consultation.

The section below includes the EBA’s response to the submission from the EBA’s Banking Stakeholder Group. In addition, in the feedback table that follows (pages 36 to 116), the EBA has summarised the comments received from all respondents and explained which responses have or have not led to changes and the reasons for the decision.

The EBA’s response to the Banking Stakeholder Group’s submission

1. The Banking Stakeholder Group (BSG) made a number of comments on the draft GL and also expressed some conflicting views between BSG members. These are addressed below.

2. The BSG agreed with the EBA’s assessments of KPIs and of the ASPSPs’ submission of a plan to publish statistics on the availability of their dedicated and PSU interfaces, set out in draft GL 2 and 3. However, the BSG expressed concerns about the commercial impact that the obligation to publish data may have on ASPSPs, and argued that this information is commercially

sensitive, that it is outside the scope of PSD2 and that its calculation is not harmonized. The BSG was of the view that the EBA should provide harmonized criteria to calculate the performance of all PSU interfaces so that the publication of these KPIs does not generate confusion and inappropriate comparisons.

3. The EBA reiterates that Article 32(4) of the RTS requires ASPSPs to publish statistics on the availability and performance of their dedicated and PSU interfaces. The EBA considers that the requirement in GL 3 to publish data on the availability and performance of the ASPSP’s dedicated and customer-facing interfaces is in line with the requirement in Article 32(4) of the RTS and is necessary in order to monitor compliance with the levels of availability and performance mandated by Article 32(1) and (2) of the RTS. The EBA also notes that it is not within the scope of the RTS, and therefore also not within the scope of these GL, to prescribe how the KPIs for the PSU interface(s) should be calculated. Consequently, these GL cannot provide harmonized criteria to calculate the performance of the PSU interfaces. However, in accordance with Article 32(4) of the RTS, ASPSPs should publish the data regarding the availability and performance of their dedicated and PSU interfaces in a way that allows the comparison of the daily availability and performance of the dedicated interface with those of each of the PSU interfaces. This is reflected in the new GL 3.2.

4. The BSG also suggested a number of other changes, such as:

a. including in GL 2.1 performance metrics that benchmark the ASPSP’s ability to resolve issues/errors with the dedicated interface that are raised by TPPs;

b. including in GL 2.3(b) performance metrics on the scope and accuracy of data made available to TPPs over the dedicated interface;

c. including a mechanism/channel for TPPs to report to CAs any availability and performance issues experienced while accessing ASPSPs test or production interfaces; and

d. stating that the ASPSP cannot be made responsible for factors that are outside its control, as a basis for granting an exemption.

5. On suggestion (a), the EBA has amended GL 2.1 to clarify that the service level targets for resolving problems related to the dedicated interface that are raised by TPPs should be at least as stringent as those for resolving issues related to the PSU interface(s).

6. On suggestion (b), the EBA acknowledges that the scope and accuracy of the data delivered through the dedicated interface are extremely important for both TPPs and PSUs. However, the scope of the data that ASPSPs are required to share with TPPs is already defined in PSD2 and the RTS, and ASPSPs need to comply with these provisions, including in order to be eligible for an exemption, as clarified in the amended GL 1.1 and 6.1. Furthermore, the EBA notes that a performance KPI, such as the one suggested, would be typically measurable by AISPs and PISPs, rather than the ASPSP, as the ASPSP will not necessarily be aware of if there has been an issue with the level of data provided. The EBA is also of the view that the new KPI on the ASPSP’s error response rate introduced in the new GL 2.3(d) may provide some information regarding errors on the ASPSP’s side in the transmission of data.

7. On suggestion (c), while TPPs can always come to the CA directly, the EBA strongly encourages TPPs to participate in the testing and to communicate any issues they experience with the test or production interfaces to the ASPSP, as a first port of call, so that the ASPSP can address the issues in a timely manner and develop a high-performing dedicated interface. As explained in more detail in paragraphs 17-20 of section 3.2 above, and in the feedback table, the EBA has made a number of changes to the GL in order to clarify that, for the purpose of the exemption, ASPSPs will need to demonstrate TPPs’ involvement in the design and testing of the dedicated interface. These changes include the requirement in the new GL 6.6 for the ASPSP to provide the CA with the feedback it has received from TPPs that have participated in the testing, together with an explanation of how the ASPSP has addressed any issues identified in the testing. Furthermore, the EBA has amended GL 8 and has also clarified that ASPSPs should provide the CA with an explanation of the problems reported by TPPs regarding the ASPSP’s production interface that have not been resolved by the ASPSP in accordance with the service level targets under GL 2.1. In addition, the EBA has added a new GL 6.7 which provides that CAs may also take into account, when assessing the ASPSP’s compliance with the design condition in Article 33(6)(b) of the RTS, any problems reported by TPPs to the CA in relation to the elements to be tested in accordance with GL 6.5.

8. The EBA notes that it is not clear to which Guideline suggestion (d) refers. The EBA is of the view that the calculation of the KPIs in GL 2 should take into account any unavailability, network latency or errors that are within the ASPSP’s responsibility, including where the ASPSP has outsourced certain components related to the implementation of the dedicated interface to a technical service provider.

9. On stress testing (GL 4), the BSG suggested that ASPSPs should stress test the dedicated interfaces in a way that proves that the dedicated interface is able to handle a peak load of currently used bank channels. The BSG also suggested expanding GL 4.3 to require ASPSPs to provide CAs with a summary of the results of stress testing of all access interfaces.

10. In line with GL 4.1, stress testing should establish and assess how the dedicated interface performs when subjected to an extremely high number of requests from PISPs, AISPs and CBPIIs. In this context, an ‘extremely high number’ of requests means that the number of requests goes significantly beyond what the interface has been designed for, which should be determined based on the ASPSP’s forecasts of the level of uptake of the dedicated interface by TPPs. The EBA notes that the usage pattern of the dedicated interface may differ from the customer-facing interface(s), in particular during the initial roll-out period of the dedicated period, and thus the volumes going through the two channels may not be comparable. As a result, the EBA considers that benchmarking the stress test results across all access interfaces may not be appropriate in all circumstances. This being said, the EBA has amended GL 4.3 to require ASPSPs to provide the CA with the assumptions used for stress testing, allowing the CA to verify the basis on which the stress testing of the dedicated interface has been conducted.

11. On GL 5 and in particular on the topic of redirection, the BSG expressed diverging views, with some members agreeing with the EBA’s proposals, and others disagreeing. The EBA reiterates the view expressed in the EBA Opinion from June 2018 that redirection is not, in itself, an obstacle to AIS or PIS, but that it ‘may’ be so, if the ASPSP implements it in a manner that creates delay or friction in the customer experience that would dissuade PSUs from using the services of AISPs or PISPs. The EBA agrees that the customer experience is of primary importance and has, to that end, provided further detail in the amended GL 5.1(b). In fact, as some BSG members also pointed out, the EBA understands that a number of consumers feel more secure and confident with redirection. The EBA understands that a number of TPPs also favour redirection and are of the view that it simplifies the process for them, as they do not need to securely transport credentials. This being said, as customers’ views and expectations may differ depending on personal experiences and the existing market within the EU, ASPSPs may wish to consider if it may be beneficial to offer more than one method of access, above and beyond the legal requirement, to cater for the diversity of markets and consumer expectations.

12. Some BSG members also expressed concerns that in some Member States consumers are likely to have to continue to share their personal security credentials with TPPs so that TPPs can access data on other (non-payment) accounts via screen scraping, so they can continue using these TPP services. The EBA considers that this is not something related to these GL, as access to non-payment accounts is not within the scope of the RTS or of these GL.

13. On the topic of obstacles, the BSG was also of the view that actions taken by the PSU to limit certain payment functionalities (i.e. spending limits) should not be considered obstacles. The EBA notes that, in line with Recital 69 of PSD2, the terms and conditions or other obligations imposed by PSPs on PSUs should not be drafted in a way that prevents PSUs from taking advantage of the services offered by PISPs and AISPs, or contain any provisions that would make it more difficult, in any way, to use the services of PISPs or AISPs. Furthermore, the EBA reminds respondents that the reasons for which an ASPSP may deny an AISP or PISP access to a payment account are set out in Article 68(5) of PSD2 and have to be objective, duly justified and related only to unauthorised or fraudulent access to the payment account. The response to comment 88 in the feedback table below provides more details on a similar comment raised by respondents.

14. Regarding GL 6, the BSG was of the view that the condition set out in Article 33(6)(b) of the RTS should be interpreted to require some involvement of consumer representatives and of TPPs in the design and testing of the interface. The EBA is of the view that input from consumer representatives could be helpful in the design and testing of the interface, in particular in the assessment of whether or not the interface creates obstacles from the perspective of the customer experience in line with the new GL 5.1(b). However, the EBA is not of the view that this should be mandatory.

15. The EBA also agrees that ASPSPs should engage with TPPs in the design and testing of the dedicated interface and, as explained in more detail in paragraphs 17-20 of section 3.2 above and in the feedback table, the EBA has made a number of changes to the GL to clarify that, for the purpose of the exemption, ASPSPs will need to demonstrate TPPs’ involvement in the design and testing of the dedicated interface.

16. On GL 7, the BSG generally agreed with the EBA’s assessment of the ‘widely used’ condition, but raised concerns that the ‘alternative’ in GL 7.2 does not require any evidence of usage to be provided or obtained. The BSG suggested that, alternatively, the GL could require ASPSPs to demonstrate that a regulator/API standardisation initiative has assessed the availability of a testing environment for an extended period and that it has been tested with demonstrable TPP engagement.

17. As explained in more detail in paragraphs 29-34 of section 3.2 above, the EBA has amended both GL 7.1 and GL 7.2 in order to clarify that CAs should take into account a broader range of factors when assessing the ‘widely used’ condition. The EBA also clarified in GL 7.1 that the obligation in the new GL 7.1(b) for the ASPSP to provide evidence that it has taken all reasonable efforts to achieve ‘wide usage’ applies to all ASPSPs and is not an ‘alternative’. Furthermore, the EBA has clarified in the new GL 7.2 that, in addition to the evidence submitted in accordance with the amended GL 7.1, CAs should also consider the evidence submitted in the context of GL 6 and 8 in assessing whether or not the ASPSP meets the ‘wide usage’ condition, including the results of the testing and how the ASPSP has addressed any issues reported by TPPs.

18. On GL 8, the BSG broadly agreed with the EBA’s assessment but was of the view that the information in GL 8 should be supplemented by information from complaints received from PSPs, TPPs and consumers. The BSG was also of the view that GL 8.1(b) should require ASPSPs to provide error resolution performance statistics, including volume-based information and resolution timelines for errors of different levels of severity.

19. The EBA is of the view that, while customer complaints data are an important source of information and are very helpful and relevant in many cases, it is unlikely that customers would be aware of any problems related to the dedicated interface, given that they do not use it directly. Therefore, customer complaints data are likely not to be a reliable indicator of issues related to the dedicated interface being resolved in a timely manner. As regards issues reported by TPPs, GL 8 already provides that ASPSPs should explain to the CA whenever a problem reported by a TPP is not resolved in accordance with the service level targets in GL 2.1. In addition, the EBA has clarified in the amended GL 6.6 that the ASPSPs should provide the CA with the feedback received from TPPs, together with an explanation of how the they have addressed any issues identified during testing. The EBA considers that this level of information is sufficient to allow CAs to determine if the ASPSP meets the requirements in Article 33(6) of the RTS. If the CA considers that it needs more data, it can request that the ASPSP provide more information.

20. The BSG was also of the view that the tight timelines for meeting the conditions for an exemption give ASPSPs a motivation to build the fall back, as ASPSPs are concerned that they may not obtain an exemption by 14 September 2019. The BSG was of the view that this ultimately reduces the incentive for ASPSPs to develop high-performing, customer-focussed APIs, and shifts the risks associated with the fall back onto the consumer. The EBA acknowledges these concerns, but, as explained in more detail in paragraph 37 of section 3.2 above, the timelines that ASPSPs should meet in order to be eligible to receive an exemption are determined by the date of application of the RTS, and it is not within the EBA’s power to change the timelines imposed by the RTS and PSD2. This being said, the EBA strongly encourages ASPSPs to start testing and launch the production interface as soon as possible, to meet the four conditions in Article 33(6) of the RTS ahead of 14 September 2019.

21. Finally, the BSG suggested that, given the pace of change, the EBA should consider a review of these GL sooner than the 2 to 3 year review cycle. The EBA agrees with this suggestion and will consider a review of the GL sooner.

Summary of responses to the consultation and the EBA’s analysis

Ref. no.	GL reference	Summary of responses received	EBA analysis and feedback	Amendments to the proposal
		Feedback on responses to question 1
1.	GL 2.1 and 3.1(b) (new 3.2)	Several respondents were of the view that the dedicated interface should be compared with the equivalent PSU interface for the channel chosen by the PSU for accessing its account (e.g. the online banking or the mobile banking interface). These respondents argued that PSU interfaces may provide different access scope (e.g. the mobile app may allow only a limited access to the account, compared with the full online banking interface) and different service levels to different customer segments (e.g. retail versus corporate customers). Other respondents were of the opposite view, namely that the dedicated interface should be compared with the best performing PSU interface. One respondent suggested clarifying this in GL 2.1.	The EBA is of the view that the dedicated interface should not be compared with the ‘equivalent’ customer interface, given that the data and availability of the dedicated interface should be the same regardless of the channel used by the PSU for accessing the services of the AISP or the PISP. Instead, the EBA believes that, in accordance with Article 32(2) of the RTS, if the ASPSP offers more than one customer interface and has different KPIs and service level targets for the said customer interfaces, the KPIs and service level targets for the dedicated interface should match the best of the KPIs and service level targets across all the interfaces made available by the ASPSP to its PSUs for directly accessing their payment accounts online. By the same token, if the ASPSP offers different KPIs and service levels for its customer-facing interfaces differentiated by customer segments (e.g. retail versus corporate customers), and one dedicated interface servicing all its customers, the KPIs and service level targets for the dedicated interface should match the best KPIs and service level targets across all the interfaces made available by the ASPSP to its PSUs for directly accessing their payment accounts online. If however the ASPSP offers different dedicated interfaces servicing different customer segments (e.g. one dedicated interface servicing its retail customers and a separate dedicated interface servicing its corporate customers), the KPIs and service level	GL 2.1 and 3.1(b) (new 3.2) have been amended as follows: GL 2.1 ‘The ASPSP should have in place the same define key performance indicators (KPIs) and service level objectives and targets, including for problem resolution, out of hours support, monitoring and, contingency plans and maintenance for its dedicated interface that are at least as it has in place stringent as those for the interface(s) used by made available to its own payment service users (PSUs) for directly accessing their payment accounts online’. GL 3.1(b) (new 3.2): ‘from the date of first The publication publish the comparison of referred to in Guideline 3.1 above should enable PISPs, AISPs, CBPIIs and PSUs to compare the availability and performance of its the
dedicated interface with its best-performing PSU interface with the availability and performance of each of the interfaces made available by the ASPSP to its PSUs on a daily basis for directly accessing their payment accounts
2.	GL 2.1 and 3.1(b) (new 3.2)	Two respondents argued that the dedicated interface should be compared with the interface that is most comparable in functionality. These respondents argued that it would not make sense to compare the dedicated interface with a mobile banking application that has reduced functionality, assuming the latter will always perform better than a dedicated interface with more features.	targets for each of these dedicated interface should match the best KPIs and service level targets across all the interfaces made available by the ASPSP to the respective customers for accessing their payment accounts online. The EBA has amended GL 2.1 to reflect that the best KPIs are to be assessed across all customer interface(s). The revised text has also been amended to be more aligned to Article 32(2) of the RTS. As a result and in accordance with Article 32(4) of the RTS, GL 3 has also been amended to ensure that ASPSPs publish data on the availability and performance of the dedicated interface and of each interface made available to its own PSUs for directly accessing their payment accounts online, in a way that enables TPPs and PSUs to compare the availability and performance of the dedicated interface and of each of the said PSU interfaces.	online’.
		The EBA acknowledges that differences in performance and availability may stem from differences in terms of functionality. That being said, and as expressed in more detail in response to comment 1 above, Article 32(2) of the RTS states that the KPIs and service level targets for the dedicated interface should be at least as stringent as those for the interface(s) made available by the ASPSP to its own PSUs. Article 32(1) also states that the dedicated interface should offer the same level of availability and performance as the interfaces made available to the PSU for directly accessing its payment account online. The EBA has therefore concluded that the KPIs and service level targets of the dedicated interface should be aligned with the best KPIs and service level targets across all PSU interfaces. This means that, if the PSU mobile interface has the most stringent KPIs and service level targets, the KPIs	No change.
			and service level targets of the dedicated interface should match those of the mobile interface.
3.	GL 2.1 and 3.1(b) (new 3.2)	Several respondents suggested that the GL should allow some margin for differences in terms of the availability and performance of the dedicated interface compared with the best performing PSU interface. Some respondents suggested that the GL should allow a fine-tuning period after the initial roll-out of the dedicated interface, during which ASPSPs can have larger planned downtimes during off-peak hours for the dedicated interface than for the PSU interface.	The EBA notes that the RTS require that the dedicated interface offer the same level of availability and performance as the interfaces made available to the PSU for directly accessing its payment account online. The RTS do not lay down any margin for differences between the availability and performance of the dedicated interface and those of the PSU interface(s). Therefore, the EBA is of the view that such a margin cannot be granted in the GL either.	No change.
4.	GL 2.1 and 3.1(b) (new 3.2)	One respondent suggested that the availability expected of an ASPSP’s dedicated interface should be compared with the targeted level, as opposed to the actual level. The respondent argued that, if for example, the PSU mobile interface achieves 100% availability against a target of 99% availability, the ASPSP should not be expected to achieve 100% availability for the dedicated interface during the same reference period.	The EBA notes that, in accordance with Article 32(1) of the RTS, ASPSPs should ensure that the dedicated interface offers at all times the same level of availability and performance as the interfaces made available to the PSU for directly accessing its payment account online. Therefore, the availability of an ASPSP’s dedicated interface should be compared with the actual level of availability achieved by the PSU interface(s). This is separate from the requirement in Article 32(2) of the RTS and GL 2.1, for the ASPSP to ensure that the targeted levels of availability of the dedicated interface are at least as stringent as those for the PSU interface(s).	No change.

5. GL 2.1	Some respondents were of the view that the dedicated interface should be compared with the ASPSP’s ‘private’ dedicated interfaces (i.e. the ASPSPs’ internal dedicated interfaces whose role is to display data to the PSU from the back-end system of the ASPSP). These respondents argued that these ‘private’ interfaces are directly comparable with the PSD2 dedicated interfaces and that data on the performance of these ‘private’ dedicated interfaces are available in the market, because at least two companies reverse-engineer ASPSPs’ ‘private’ dedicated interfaces.	According to Article 32(1) and (2) of the RTS, the dedicated interface should be compared with the interface(s) made available to the PSU for directly accessing its payment account online. Therefore, the EBA does not agree with the suggestion that the benchmark for comparison should be the ASPSPs’ ‘private’ internal interfaces.	No change.
6. GL 2.1	Some respondents interpreted GL 2.1 as requiring ASPSPs to use the same monitoring plans and measurement methods for monitoring the dedicated interface as they would use for monitoring the PSU interface(s), and suggested that the amount of monitoring should be the same but the method can be different. One respondent was of the view that ASPSPs will not be able to achieve the same monitoring plans across all interfaces, because the technology that underpins them is different.	The EBA is of the view that in line with Article 32(2) of the RTS, the KPIs and service level targets for monitoring the dedicated interface should be at least as stringent as those for the PSU interfaces. This does not suggest that the monitoring method, plans or measurements should be the same; they may in fact differ as long as the targets and indicators set are at least as stringent. The EBA however agrees that the terminology used in GL 2.1 may have been somewhat confusing and has therefore redrafted the GL to make this clearer.	The EBA has amended GL 2.1 as follows: ‘The ASPSP should have in place the same define key performance indicators (KPIs) and service level objectives and targets, including for problem resolution, out of hours support, monitoring and, contingency plans and maintenance for its dedicated interface, that are at least as it has in place stringent as those for the interface(s) used by made available to its own payment service users (PSUs) for directly accessing their payment accounts online’.
7. GL 2.1	One respondent suggested to replace ‘out of hours support’ with ‘support’ in GL 2.1, on the grounds that extending ‘support’ to ‘out of hours support’ goes beyond the requirements in the RTS, which refer only to ‘support’ in Articles 30(5) and 32(1). The respondent also argued that the out of hours support necessary for a payment initiation, AIS activity without a PSU present or AIS activity with a PSU directly accessing its account information is not comparable.	The EBA notes that Article 32(1) of the RTS expressly states that the dedicated interface should offer, at all times, the same level of availability and performance, including support, as the PSU interface(s). The EBA is of the view that this means that the level of support offered has to be the same at all times and therefore includes out of hours support. The respondent does not provide a rationale for suggesting that support differs depending on the service, and whether a customer is directly involved or not. The RTS do not include requirements on the type	No change.
			of support that may be needed but simply require that the level of support should be the same as the level provided for the customer interface(s).
8.	GL 2.2 and 2.3	One respondent suggested that TPPs should be allowed to request additional KPIs, if necessary for TPPs to function properly, such as the number of successful and erroneous requests, the average response time, the average processing time for retrieving information from an account or executing a payment, and the general availability of the interface.	The EBA notes that the suggestion on response time is already covered in GL 2.3. The EBA has however considered if any other suggested KPIs should be added and has concluded that a KPI on the ASPSP’s error response rates would be a helpful addition to measure the performance of the dedicated interface. The EBA included the new indicator in GL 2.3(d).	The EBA introduced a new KPI in GL 2.3(d): ‘d. the daily error response rate – calculated as the number of error messages concerning errors attributable to the ASPSP sent by the ASPSP to the PISPs, AISPs and CBPIIs in accordance with Article 36(2) of the RTS per day, divided by the number of requests received by the ASPSP from AISPs, PISPs and CBPIIs in the same day’.
9.	GL 2.2 and 2.3	One respondent requested clarification of whether or not, in the case of several ASPSPs sharing the same dedicated interface, the performance KPIs will be measured based on the individual reaction times of the individual ASPSPs being approached through the dedicated interface. Some respondents also requested clarification of whether or not the KPIs in GL 2 can be calculated at group level, where several ASPSPs within a group offer the same dedicated interface within the EEA.	The EBA clarifies that the KPIs in GL 2.2 and 2.3 should be calculated at the level of each individual ASPSP seeking an exemption. This means that the response time in GL 2.3 should be calculated based on each ASPSP’s response time to the requests it receives from a PISP, AISP or CBPII through the dedicated interface.	No change.
10.	GL 2.2 and 2.4	Several respondents suggested that the KPIs on the availability of the dedicated interface should distinguish between ‘prime-time’ (6 a.m. to 1 a.m.) and ‘non-prime’ time (1 a.m. to 6 a.m.). The respondents argued that availability during prime-time is much more important to the market in terms of user experience and overall business value, and therefore more critical than during non-prime-time hours. These respondents suggested that this distinction would remove the need to refer to debatable metrics, such as ‘planned’ versus ‘unplanned’ downtime, and	The EBA has considered whether or not a distinction between prime- and non-prime-time availability could be introduced. The EBA understands that not all ASPSPs make such a distinction for the purpose of their customer interface(s). The EBA has therefore concluded that imposing such a distinction for the dedicated interface would not be possible.. The EBA acknowledges that the distinction between ‘planned’ and ‘unplanned’ downtime may give rise to divergent interpretations of what represents ‘planned’ downtime. The EBA has therefore decided to remove	The EBA amended GL 2.1, 2.2 and 2.4 as follows: GL 2.1 ‘The ASPSP should have in place the same define key performance indicators (KPIs) and service level objectives and targets, including for problem resolution, out of hours support, monitoring and, contingency plans and maintenance for its dedicated interface that are at least as it has in

	that, from a customer’s experience point of view, it does not matter whether the downtime is planned or unplanned. Other respondents requested clarification of what ‘planned’ downtime means and, in particular, what would be the required pre-notification time to qualify as ‘planned’ downtime.	this distinction from GL 2.2 and 2.4. Instead, in order to address the concern that the availability of the dedicated interface may be affected by maintenance work during peak hours (whereas for the PSU interfaces this could be planned during off-peak hours), the EBA has amended GL 2.1 to clarify that the service level targets for the dedicated interface should be at least as stringent as those for the PSU interface, including in terms of maintenance.	place stringent as those for the interface(s) used by made available to its own payment service users (PSUs) for directly accessing their payment accounts online’. GL 2.2 ‘The ASPSP should have define at a minimum, the following key performance indicators KPIs of the availability of the dedicated interface as well as each of the interface used by its payment service users (PSU): 40. the uptime per day of all interfaces; and 41. the downtime per day of all interfaces (planned); c. the downtime of all interfaces (unplanned); GL 2.4 ‘For the purpose of calculating the values of the availability indicators set out in Guideline 2.2 for the dedicated interface, the ASPSP should: 1. calculate the percentage planned and unplanned by uptime as 100% minus the percentage downtime; 2. calculate the percentage downtime using the total number of seconds the dedicated interface was down in a 24 - hour period starting and ending at midnight; 3. calculate the percentage Uptime as 100% minus the percentage downtime count the interface as ‘down’ when the conditions in Article 33(1) of the RTS are met, that is: when five consecutive requests for access to
			information for the provision of payment initiation services, or account information services or confirmation of availability of funds are not replied to within a total timeframe of 30 seconds [...]’.
11.	GL 2.2 and 2.4	Several respondents argued that the calculation of downtime should not include ‘planned’ downtime, to avoid a negative impact on the percentage uptimes of the interface.	The EBA disagrees and remains of the view that all downtime, whether planned or unplanned, should be included in the calculation of the downtime KPI in GL 2.4, on the basis that, whether planned or not, the interface would be down in both cases. See also the response to comment 27 below.	No change.
12.	GL 2.2, 2.3 and 2.4	Several respondents argued that ASPSPs should use the same metrics for the dedicated interface, including the same definition of ‘downtime’, as they currently use for their customer-facing interfaces, on the grounds that it would be unduly impractical and costly to introduce new metrics.	The EBA believes that the minimum set of KPIs required in GL 2 for the dedicated interface are necessary in order to monitor the availability and performance of the dedicated interface in accordance with Article 32(1) and (2) of the RTS. Regarding in particular the downtime KPI in GL 2.4, the EBA notes that this KPI is based on the benchmark in Article 33(3) of the RTS. The EBA also acknowledges that it is not within the scope of the RTS, and therefore also not within the scope of these GL, to prescribe how the KPIs for the PSU interface(s) should be calculated. However, in accordance with Article 32(4) of the RTS and GL 3.2, the data regarding the availability and performance of the PSU interface(s) should be published in a way that allows comparison between the daily availability and performance of the dedicated interface and those of each of the PSU interfaces.	No change. See, however, the changes made to GL 3, highlighted in the response to comment 1 above.
13.	GL 2.3	Several respondents requested clarifications of whether or not the response times in GL 2.3 should be calculated as averages and, if so, over what period. Some respondents were of the view that the response times should be calculated as an average over a longer time horizon, such as a month, and not as daily	The EBA has considered these proposals and has come to the view that a monthly average would not give sufficient visibility of variations in performance and availability over time. Instead, the EBA considers that calculating response times as a daily average would enable transparency of	The EBA has amended letters (a)-(c) of GL 2.3 as follows: ‘a. the daily average time (in milliseconds) taken, per request, for the ASPSP to provide to the payment initiation service provider (PISP) with
	averages. These respondents argued that the dedicated interface could register under-performing metrics in a 24-hour period, although it may significantly exceed the service levels for the PSU interface over a longer time horizon.	the performance and availability of the dedicated interface over time. The EBA also considers that this is necessary for the purpose of monitoring compliance with the requirements in Article 33(1) of the RTS and Article 33(7) of the RTS regarding the revocation of the exemption where the conditions in letters (a) and (d) of Article 33(6) are not met for more than 2 consecutive calendar weeks. Consequently, the EBA has concluded that a daily average would be the most representative and would enable monitoring for the purpose of Article 33(1) and (7) of the RTS.	all the information on the initiation of the payment transaction as required by letter (b) of requested in accordance with Article 66(4)(b) of Directive(EU) 2015/2366 (PSD2) and by letter (a) of Article 36(1)(b) of the RTS; b. the daily average time (in milliseconds) taken, per request, for the ASPSP to provide to the account information service provider (AISP) with all payment related data as required by letter (b) of the information requested in accordance with Article 36(1)(a) of the RTS; c. the daily average time (in milliseconds) taken, per request, for the ASPSP to provide to the card-based payment instrument issuer (CBPII) as or the PISP with a ‘yes/no message confirmation as required by in accordance with Article 65(3) of PSD2 and by letter (c) of Article 36(1)(c) of the RTS’.
14. GL 2.3	A few respondents suggested that the GL should define KPIs for response times in specified percentiles.	The EBA considered different methods of calculating the response times in GL 2.3 and arrived at the view that they should be calculated as daily averages and in milliseconds, instead of defining specific percentiles, as the latter option may be unduly burdensome.	No change. See, however, the changes made to GL 2.3, highlighted in the response to comment 13 above.
15. GL 2.3	A few respondents suggested that the calculation of the response times in GL 2.3 should include only the time elapsed between the request received by an ASPSP from a TPP whose authorisation/ registration has been verified, and the response sent by the ASPSP. These respondents argued that the response times should not include the verification of the TPPs’	The EBA clarifies that the response time in GL 2.3 includes the interval between the point in time when a request is received by the ASPSP from a PISP, AISP or CBPII and the point in time when all the information requested (or where relevant the yes/no confirmation) has been sent back by the ASPSP. The EBA also notes that, from the date of application	No change. See, however, the changes made to GL 2.3, highlighted in the response to comment 13 above.
	authorisation/ registration via the Qualified Trust Service Providers or the relevant national registers.	of the RTS (14 September 2019), ASPSPs should rely on the eIDAS certificates, as referred to in Article 34 of the RTS, in order to identify PISPs, AISPs and CBPIIs. The time it takes for any checks that the ASPSP may choose to make on the authorisation/registration of these TPPs, provided these are not considered as obstacles to the provision of PIS or AIS, should be included in the calculation of response times. See also the response to comment 77 below.
16.	GL 2.3	A few respondents were of the view that the calculation of the response times in GL 2.3 should not include downtime periods due to hacker attacks (e.g. distributed denial of service (DDOS)).	As stated in the response to comment 15 above, the response time in GL 2.3 includes the interval between the point in time when a request is received by the ASPSP from a PISP, AISP or CBPII and the point in time when all the information requested (or where relevant the yes/no confirmation) has been sent back by the ASPSP. If a request is not received by the ASPSP, this will not be counted in the response time. This is without prejudice to any other requirements that may be applicable under other legal instruments, such as reporting of security incidents.	No change. See, however, the changes made to GL 2.3, highlighted in the response to comment 13 above.
17.	GL 2.3	One respondent suggested that the response times in GL 2.3 (a) and (b) should take into account the fact that some responses require more than one step, such as requests for access to account information for a large number of accounts.	The EBA notes that the response time in GL 2.3 (a) and (b) takes into account the time taken by the ASPSP to respond to a request received from a PISP or AISP, regardless of whether or not the amount of information to be sent back may differ and potentially have an impact on the time it takes to provide the response to the AISP or PISP. The EBA has clarified in GL 2.3 that these response times are calculated as daily averages.	No change. See, however, the changes made to GL 2.3, highlighted in the response to comment 13 above.
18.	GL 2.3	Several respondents suggested that the GL should define additional performance KPIs regarding the scope and accuracy of data made available to TPPs over the dedicated interface. These respondents argued that data is the crucial element to be delivered via the dedicated interface and that Article 32(2) of the RTS requires ASPSPs to define transparent KPIs and	The EBA acknowledges that the scope and accuracy of the data delivered through the dedicated interface are extremely important for both TPPs and PSUs. That being said, the scope of the data that ASPSPs are required to share with TPPs is already defined in PSD2 and the RTS, and ASPSPs will need to comply with these provisions, including in order to be eligible for	The EBA has amended GL 1.1 and 6.1 and added a new KPI in GL 2.3(d): GL 1.1 ‘Competent authorities should assess an account servicing payment service provider (ASPSP) as having fulfilled the four conditions set out in Article 33(6) of
	service level targets ‘both in terms of availability and of data provided in accordance with Article 36’ of the RTS.	an exemption. The EBA has amended GL 1.1 and 6.1 to clarify this. In addition, a KPI such as the one suggested by the respondent would be typically measurable by AISPs and PISPs, rather than the ASPSP, as the ASPSP will not necessarily be aware if there was an issue with the level of data provided. The EBA is also of the view that the new KPI on the ASPSP’s error response rate introduced in GL 2.3(d) may provide some information regarding errors on the ASPSP’s side in the transmission of data.	the RTS where the ASPSP is compliant with the requirements set out in Guidelines 2 to 8, subject to compliance with the requirements set out in PSD2 and the RTS’. GL 6.1 ‘For the purposes of evidencing compliance with the requirement in letter (b) of Article 33(6) of the RTS regarding the design of the dedicated interface, the ASPSP should provide the competent authority with: a. evidence that the dedicated interface meets the legal requirements for access and data in PSD2 and the RTS [...]’ GL 2.3(d) ‘d. the daily error response rate – calculated as the number of error messages concerning errors attributable to the ASPSP sent by the ASPSP to the PISPs, AISPs and CBPIIs in accordance with Article 36(2) of the RTS per day, divided by the number of requests received by the ASPSP from AISPs, PISPs and CBPIIs in the same day’.
19. Paragraph 21 of the CP	A few respondents requested clarification on what is meant by ‘accuracy of information provided’ in paragraph 21 of the CP.	Paragraph 21 of the CP was intended to refer to the performance KPIs in letters (a)-(c) of GL 2.3, regarding the time taken by an ASPSP to provide all the information requested in accordance with Article 36 of the RTS in response to a request received from a PISP, AISP or CBPII. The EBA acknowledges that the reference to ‘accuracy’ of information may have been unclear. See also the response to comment 18 above.	No change.

20. GL 2.3	A few respondents were of the view that due consideration has not been given to ‘degraded services’. In particular, one TPP mentioned that, in some cases, it was not able to access account data through the dedicated interface for a given cohort of PSUs but that this would not be accurately reflected by the ASPSP in the uptime/downtime calculations.	The EBA understands that the concern of the respondent is on the level of detail of the indicators, and more specifically that an interface may be down only for a given cohort of PSUs. It is not clear to the EBA when this would be the case, given that all data is shared through the same dedicated interface. The EBA notes that in accordance with GL 2.4, the interface should be counted as ‘down’ whenever five requests received by the ASPSP are not answered in a 30-second period, irrespective from which TPP(s) or customers the request originates.	No change.
21. GL 2.3	Some respondents were of the view that the GL should define additional KPIs based on the TPPs’ conversion rates (i.e. the number of successful PSU authentications/the total authentication attempts) or retention rates, compared with the current methods of access by screen scraping.	The EBA does not agree with the suggestion that TPPs’ conversion or retention rates, based on current access methods, would be an appropriate benchmark for measuring the performance of the dedicated interface, because the RTS provide that the KPIs and service level targets for the dedicated interface should be compared with those for the interfaces made available by the ASPSP to its own PSUs, not benchmarked against the retention rates of third parties. Furthermore, this is not something that can be feasibly calculated by ASPSPs.	No change.
22. GL 2.3	A few respondents suggested that the GL should define additional performance metrics that take into account the PSU’s convenience (number of screens or clicks) and abandon/dropout rate.	The EBA is of the view that this is already addressed in GL 5.2(d) (new 5.1(b)) regarding obstacles, and that it is not something that could be translated into a KPI and measured by the ASPSP.	No change. See, however, the changes made to GL 5.2(d) (new 5.1(b)), highlighted in the response to comment 90 below.

23. GL 2.3	A few respondents were of the view that the GL should include an additional KPI on error response rates.	The EBA agrees with the respondents and has included a new KPI on the ASPSP’s error response rate in the new GL 2.3(d). The EBA acknowledges that there may be no such comparable KPI for the PSU interface, and that, as a result, for the purpose of the requirement in GL 3, ASPSPs are not required to publish a KPI on the daily error response rate for the PSU interface.	The EBA has added a new GL 2.3(d): ‘d. the daily error response rate – calculated as the number of error messages concerning errors attributable to the ASPSP sent by the ASPSP to the PISPs, AISPs and CBPIIs in accordance with Article 36(2) of the RTS per day, divided by the number of requests received by the ASPSP from AISPs, PISPs and CBPIIs in the same day’.
24. GL 2.3	A few respondents suggested defining KPIs in GL 2 on the ASPSP’s ability to deal with faults reported by TPPs regarding the dedicated interface. These respondents also suggested that ASPSPs should publish data on their error/problem resolution performance across all access interfaces and that CAs should assess the impact of wide discrepancies in the ASPSP’s error/problem resolution capacity, across all interfaces, as part of the ongoing monitoring under Articles 30(6) and 33(7) of the RTS.	The EBA notes that, in accordance with Article 33(6)(c) of the RTS, in order to be eligible for an exemption, ASPSPs should resolve any problem related to the dedicated interface without undue delay. Furthermore, the EBA has amended GL 2.1 to clarify that the service level targets for resolving problems related to the dedicated interface should be at least as stringent as those for the PSU interface(s). The EBA is of the view that this should ensure that the ASPSP’s ability to deal with problems reported by TPPs is at least as good as its ability to deal with problems reported by the ASPSP’s own PSUs with regard to the customer interface(s). Furthermore, the EBA is of the view that the new KPI on the ASPSP’s error response rate, introduced in GL 2.3(d), may provide some information regarding errors on the ASPSP’s side in the transmission of data. This being said, the EBA is also of the view that a requirement for ASPSPs to publish data on their error resolution performance across all access interfaces would go beyond what is required in the RTS and could be unduly burdensome. See also the response to comment 23 above.	The EBA has amended GL 2.1 as follows: ‘The ASPSP should have in place the same define key performance indicators (KPIs) and service level objectives and targets, including for problem resolution, out of hours support, monitoring and, contingency plans and maintenance for its dedicated interface that are at least as it has in place stringent as those for the interface(s) used by made available to its own payment service users (PSUs) for directly accessing their payment accounts online.’. See also the new KPI on the error response rate introduced in GL 2.3(d), highlighted in the response to comment 23 above.

25.	GL 2.3	Some respondents suggested that the GL should include additional metrics on the application of strong customer authentication when the customers are using the services of a TPP versus when they are directly accessing their account via the PSU interface. These respondents argued that such data should be published, so that it is possible to independently verify if an ASPSP is providing SCA exemptions without prejudice.	The EBA understands that the comment raised by the respondents relates more to the compliance with legal requirements and to the non-discriminatory application of exemptions to SCA by the ASPSP, depending on whether an AISP or PISP is involved, than to the subject matter of these GL, as it does not relate to the performance or availability of the dedicated interface. As clarified in the EBA Opinion issued on 13 June 2018, the decision regarding the application of an exemption to SCA belongs to the ASPSP and should be taken in accordance with the RTS and also in line with Articles 66(4)(c) and 67(3)(b) of PSD2. This being said, the EBA is of the view that the additional KPI suggested is not required by the RTS and that imposing an obligation for ASPSPs to publish such data would be outside the scope of the GL.	No change.
26.	GL 2.3 and 2.4	Several respondents suggested clarifying that the KPIs in GL 2.3 and 2.4 are measured from the time when the ASPSP receives a request from a TPP. The respondents argued that the ASPSP should not be responsible for the performance of components outside its control and therefore only the time spent in the ASPSP’s environment should be counted in the performance indicators.	The EBA agrees that the KPIs regarding response time in GL 2.3 should be measured from the point in time when the ASPSP receives a request from a TPP via the dedicated interface. Similarly, the dedicated interface should be counted as ‘down’ when five requests are received and unanswered within the maximum timeframe set out in GL 2.4(b) (new 2.4(c)). The calculation of these KPI should take into account any unavailability of the dedicated interface or network latency that is within the ASPSP’s responsibility, including any instances where the ASPSP may have outsourced certain elements related to the implementation of the dedicated interface to a technical service provider.	The EBA has amended GL 2.4(b) (new 2.4(c)) as follows: ‘[...] count the interface as ‘down’ when the conditions in Article 33(1) of the RTS are met, that is: when five consecutive requests for access to information for the provision of payment initiation services, or account information services or confirmation of availability of funds are not replied to within a total timeframe of 30 seconds [...] In such a case, the ASPSP should calculate downtime from the moment it has received the first request in the series of five consecutive requests that were not replied to within 30 seconds [...]’.

27. GL 2.4(b) (new 2.4(c))	Several respondents requested clarifications regarding the calculation of downtime in GL 2.4(b) (new 2.4(c)). In particular, respondents requested clarifications of whether the 30-second timeframe in GL 2.4(b) (new 2.4(c)) applies to all five requests or to each request individually, what ‘consecutive’ requests mean and whether the five requests should originate from the same TPP or from different TPPs.	The EBA acknowledges that the calculation of the downtime KPI may not have been clear and has amended GL 2.4(b) (new 2.4(c)) in order to clarify that ASPSPs should count the interface as down whenever five consecutive requests are not replied to within a total interval of 30 seconds. The EBA also clarifies that, in this context, ‘consecutive’ means that there is no reply to a TPP request in between those five requests. The EBA has also clarified in GL 2.4(c) that, where the conditions in GL 2.4(c) are met, the ASPSP should calculate downtime from the moment it has received the first request in the series of five consecutive requests that were not replied to within a total timeframe of 30 seconds, and that the five requests may originate from the same TPP or from different TPPs.	The EBA has amended GL 2.4(b) (new 2.4(c)) as follows: ‘[...] count the interface as ‘down’ when the conditions in Article 33(1) of the RTS are met, that is: when five consecutive requests for access to information for the provision of payment initiation services, or account information services or confirmation of availability of funds are not replied to within a total timeframe of 30 seconds, irrespective of whether these requests originate from one or multiple PISPs, AISPs or CBPIIs. In such a case, the ASPSP should calculate downtime from the moment it has received the first request in the series of five consecutive requests that were not replied to within 30 seconds, provided that there is no successful request in between those five requests to which a reply has been provided’.
28. GL 2.4(b) (new 2.4(c))	Some respondents were of the view that downtime should be measured as an average over a longer time period, rather than in seconds, and argued that the calculation in seconds would be too burdensome for ASPSPs and brings no real benefits for TPPs.	The EBA disagrees and remains of the view that downtime should be calculated in seconds, rather than an average over a longer time period, in order to ensure consistency with the benchmark in Article 33(3) of the RTS and enable transparency of the availability of the dedicated interface in accordance with Article 32(1) of the RTS.	No change.
29. GL 2.4(b) (new 2.4(c))	One respondent requested clarification of whether or not the definition of downtime in GL 2.4(b) (new 2.4(c)) should also take into account requests from CBPIIs.	The EBA is of the view that the definition of downtime for the dedicated interface should also take into account requests received from CBPIIs, as the same interface will also be used to respond to requests from CBPIIs. The EBA acknowledges that this may not have been clear from GL 2.4 and has amended the text in order to clarify this.	The EBA has amended GL 2.4(b) (new 2.4(c)) as follows: ‘[...] count the interface as ‘down’ when the conditions in Article 33(1) of the RTS are met, that is: when five
				consecutive requests for access to information for the provision of payment initiation services, or account information services or confirmation of availability of funds are not replied to within a total timeframe of 30 seconds, irrespective of whether these requests originate from one or multiple PISPs, AISPs or CBPIIs [...]’.
30. GL 2.4(b) (new 2.4(c))	One respondent was of the view that the fact that the maximum number of seconds in Article 33(1) of the RTS has been reached or exceeded cannot be seen as a confirmation in itself, but only as a presumption, that the ASPSP’s dedicated interface is down.	For consistency purposes, the EBA has aligned the calculation of the downtime KPI in GL 2.4 as far as possible with the benchmark in Article 33(1) of the RTS. However, the EBA is of the view that the benchmark in Article 33(1) has a different aim from the KPI in GL 2.4. More precisely, the benchmark in Article 33(1) is used for assessing if there is unplanned unavailability or a system breakdown that triggers the contingency measures in Article 33 of the RTS. In this context, the RTS state that unplanned unavailability or a system breakdown may be presumed when five consecutive requests are not replied to within 30 seconds. The downtime KPI in GL 2.4, on the other hand, is used for measuring the availability of the dedicated interface, in the context of the exemption to the fall back mechanism. For the purpose of calculating this KPI, the ASPSP should count the interface as ‘down’ when five consecutive requests for access to information for the provision of PIS, AIS or confirmation of availability of funds are not replied to within a total timeframe of 30 seconds, as highlighted in GL 2.4(c). The EBA acknowledges that the reference to Article 33(1) in GL 2.4 was somewhat unclear and has removed this reference from GL 2.4.	The EBA has amended GL 2.4(b) (new 2.4(c)) as follows: ‘[...] count the interface as ‘down’ when the conditions in Article 33(1) of the RTS are met, that is: when five consecutive requests for access to information for the provision of payment initiation services, or account information services or confirmation of availability of funds are not replied to within a total timeframe of 30 seconds, irrespective of whether these requests originate from one or multiple PISPs, AISPs or CBPIIs [...]’.
31. GL 2.4(b) (new 2.4(c))	One respondent was of the view that the calculation of downtime in GL 2.4(b) (new 2.4(c)) is not proportionate to all scenarios and suggested using	The EBA is of the view that, in line with the RTS, the availability of the dedicated interface should be the same for both PIS and AIS, irrespective of whether the PSU is	No change.
		this definition of downtime only for PIS and AIS when the PSU is actively requesting account information.	actively requesting the information or the request is being made by an AISP in accordance with Article 35(5)(b) of the RTS, given that, in any case, the AIS or PIS accesses the dedicated interface, not the PSU. As a result, the definition of downtime in GL 2.4 does not distinguish between requests from PISPs or AISPs or between requests sent by AISPs depending on whether the PSU is actively requesting the information or not.
32.	GL 2.4(b) (new 2.4(c))	One respondent suggested that ASPSPs should count the dedicated interface as 'down' whenever more than 50% of the total requests received within a timeframe of 1 minute are not answered in 30 seconds.	The EBA considered a range of options for the purpose of the calculation of the downtime KPI in GL 2.3, but concluded that, on the basis that PSPs will need to calculate and monitor any instances where five consecutive requests are not replied to within a total timeframe of 30 seconds in the context of Article 33(1) of the RTS, it would be appropriate to use the same measure for the downtime KPI. This is both for reasons of ensuring consistency and for the purpose of limiting the additional burden on ASPSPs. See also the response to comment 30 above.	No change.
33.	GL 2.4(b) (new 2.4(c))	Some respondents requested clarification of how to measure the availability of the dedicated interface when the dedicated interface is not receiving requests, for example during low-activity periods.	The EBA is of the view that ASPSPs should count the dedicated interface as ‘down’ whenever the conditions set out in GL 2.4(c) are met. The EBA acknowledges that, during low-activity periods, it might take some time for five requests to be received and considers that, if the interface is not receiving any requests, it would not be counted as ‘down’. However, if the conditions in GL 2.4(c) are met, the ASPSP should count the interface as ‘down’ from the moment it has received the first request in the series of five consecutive requests that were not replied to within 30 seconds.	No change. See, however, the changes made to GL 2.4(b) (new 2.4(c)), highlighted in the response to comment 27 above.
34.	GL 2.4(b) (new 2.4(c))	One respondent requested clarifications on when the dedicated interface is considered to be up again after a period of downtime.	As set out in GL 2.4(c), ASPSPs should count the dedicated interface as ‘down’ when five consecutive requests are not replied to within a total timeframe of 30 seconds, provided that there is no successful request in between those five requests to which a reply has been provided. The EBA is of the view that the interface should be considered as up again when the ASPSP successfully replies to a new request.	No change. See, however the changes made to GL 2.4(b) (new 2.4(c)), highlighted in the response to comment 27 above.
35.	GL 2.4(b) (new 2.4(c))	One respondent requested clarification of whether or not, in the case of ASPSPs using the same interface in several countries, the fact that the ASPSP’s IT systems are not available in one country implies that the ASPSPs’ services should be considered ‘down’ in all the countries where the ASPSP is providing services.	The calculation of downtime does not differ depending on whether the ASPSP offers the same dedicated interface in one or several Member States. This means that, if the ASPSP offers the same dedicated interface in several Member States, it does not matter from the perspective of this KPI whether the interface is unresponsive in only one country or in more: the ASPSP should calculate the interface as ‘down’ whenever five consecutive requests are received by the ASPSP and are not answered within a total 30 second interval, provided that there is no successful request between those five requests to which an answer has been provided.	No change. See, however, the changes made to GL 2.4(b) (new 2.4(c)), highlighted in the response to comment 27 above.
36.	GL 3.1	Several respondents argued that the GL should not require ASPSPs to publish information on their service levels for all their PSU interfaces and that ASPSPs should report such data only to their CA. The respondents also argued that these data are commercially sensitive (as they reveal competitive information), that their publication might lead to security risks and that it would also entail significant compliance costs for ASPSPs.	The EBA notes that the publication of statistics on a quarterly basis on the availability and performance of both the dedicated interface and the PSU interface is mandated by Article 32(4) of the RTS. Therefore, the EBA does not agree that ASPSPs should report such data only to their CA, as this would not be compliant with the RTS.	No change.
37.	GL 3.1(b) (new 3.2)	Some respondents requested clarification of how the ‘best performing’ PSU interface should be determined.	As explained in more detail in the response to comment 1 above, and in order to provide more transparency regarding the availability and performance of the dedicated interface, the EBA has removed the reference to the ‘best performing interface’ from GL 3.1 (b) (new 3.2). Instead, the EBA has clarified in GL 3.2 that the	The EBA amended GL 3.1(b) (new 3.2) as follows: ‘from the date of first The publication publish the comparison of referred to in Guideline 3.1 above should enable
			publication of daily statistics should enable TPPs and PSUs to compare the availability and performance of the dedicated interface with the availability and performance of each of the PSU interface made available by the ASPSP to its PSUs.	PISPs, AISPs, CBPIIs and PSUs to compare the availability and performance of its the dedicated interface with its best-performing PSU interface with the availability and performance of each of the interfaces made available by the ASPSP for directly accessing their payment accounts online to its PSUs on a daily basis’.
38.	GL 3.1(b) (new 3.2)	Some respondents asked if all the interfaces made available by the ASPSP to the PSU should be considered for the purpose of the comparison in GL 3.1(b) (new 3.2), including the online and mobile banking interfaces and any other interfaces that the PSU can make use of, for example when using a payment instrument issued by the ASPSP. One respondent suggested that the GL should establish a maximum number of interfaces for which data should be published and compared, based on criteria such as the number of customers using the interface.	As explained in the response to comment 1 above, the EBA is of the view that, for the purpose of the comparison referred to in GL 3, all the interfaces made available by the ASPSP to its customers for directly accessing their payment account online should be considered, including the online and mobile banking interfaces as well as any other interfaces that the PSU can make use of to access its account online. This does not include the interface the PSU is redirected to from a merchant’s website in order to make a payment. This is clarified in the amended GL 3. The EBA does not agree that the number of PSU interfaces to be compared should be limited, and notes that according to Article 32(1) of the RTS the dedicated interface should offer, at all times, the same level of availability and performance as the interfaces made available to the PSU for directly accessing its payment account online, without limiting the number of PSU interfaces to be used as a benchmark for comparison.	No change. See, however, the changes made to GL 2.1 and 3.1(b) (new 3.2), highlighted in the response to comments 1 and 37 above.
39.	GL 3.1(b) (new 3.2)	One respondent argued that, for competitive reasons, ASPSPs should not be required to publish data on the service levels for all their PSU interfaces in percentages but, instead, should be allowed to use categories (e.g. green/red/yellow) for publishing this data.	The EBA notes that, in line with GL 2.3, 2.4 and 3.1, ASPSPs should publish the availability KPIs (downtime/uptime) for the dedicated interface in percentages and on a daily basis, and that the other KPIs also have to be measured on a daily basis in accordance with GL 2.3. In addition, GL 3.2 requires ASPSPs to publish the statistics referred to in GL 3.1 in a way that enables TPPs and PSUs to compare the availability and performance of	No change. See, however, the changes made to GL 3.1(b) (new 3.2), highlighted in the response to comment 37 above.
		the dedicated interface with the availability and performance of each of the interfaces made available by the ASPSP to its PSUs for directly accessing their payment accounts online. A green/yellow/red system is unlikely to be suitable given that the GL do not define such categories. However, ASPSPs may decide to present the actual performance and availability against their KPIs in graphic format (using for instance one line chart to display statistics of both the dedicated interface and PSU interfaces) in a way that facilitates comparison in line with GL 3.2.
40.	GL 3.1	Several respondents suggested that ASPSPs should be required to publish only average monthly KPIs, rather than daily figures as stated in GL 3.1. These respondents argued that the breakdown into daily figures is disproportionate to the value of added detail, that it could trigger security risks and that it is not required by the RTS. Other respondents were of the opposite view and suggested that ASPSPs should publish data in real time. These respondents argued that the publication of data in real time would be beneficial to all parties (ASPSPs, TPPs and CAs), including for root cause determination.	The EBA considered these proposals and has arrived at the view that the data that ASPSPs should publish in accordance with GL 3 should be based on daily figures, rather than monthly averages, in order to enable transparency of the performance and availability of the dedicated interface, and also for the purpose of monitoring compliance with Articles 32(1) and 33(7) of the RTS, which require a more frequent breakdown than monthly averages. In addition, the EBA notes that the publication of daily figures will also allow to monitor whether or not the ASPSP complies with the KPIs defined as per GL 2.2 and 2.3 (all of which are calculated on a daily basis). See also the response to the comment 13 above. The EBA also considers that an obligation to publish data in real time is not required by the RTS, may not be feasible and would be unduly burdensome for ASPSPs. Consequently, the EBA has arrived at the view that the publication of daily figures is the preferred option.	No change.
41.	GL 3.1	One respondent was of the view that the identification of the channel, such as online banking or mobile banking, should be available in the dataset of the dedicated interface and reported to the CA. The respondent argued that this information is important for risk analysis as well as for assessing the performance of the dedicated interface.	The EBA understands that, where an ASPSP receives a request from a TPP through the dedicated interface, it may not be feasible for the ASPSP to identify the channel through which the PSU is using the services of the TPP that is approaching the ASPSP through the dedicated interface. The EBA considers that the reporting of such information is outside the scope of these GL, given that	No change.
			the GL focus on the interaction between TPPs and the ASPSP through the dedicate interface and not between the PSU and TPPs.
42.	GL 3.1	Several respondents requested clarification regarding the first observation period (quarter) for which ASPSPs should calculate and publish the KPIs required as per GL 2. One respondent suggested that the first publication should cover the period from 14 September 2019 to the end of the year, when there will be meaningful customer usage data. Another respondent was of the view that ASPSPs should be required to publish quarterly statistics in advance of the application date of the RTS.	The EBA is of the view that, where an ASPSP applies for an exemption ahead of the date of application of the RTS, it should submit a plan for the publication of data to its CA starting with the date of application of the RTS, i.e. from 14 September 2019, given that the obligation to publish data starts only when the RTS apply, namely on 14 September 2019. The EBA agrees with the respondent who suggests that it may be more meaningful to define the first quarter from 14 September 2019 until the end of the year (rather than until 14 December 2019).	No change.
43.	GL 3.1	One respondent suggested that GL 3 should specify an overall maximum timeframe during which ASPSPs should publish the quarterly statistics, such as one month after the end of the quarter.	The EBA notes that the RTS do not specify a timeframe during which ASPSPs should publish these statistics after the end of the relevant quarter. The EBA considers that this is outside the scope of these GL and it is a decision for the CAs to make.	No change.
44.	GL 3.1 and 3.2	One respondent suggested that the data reported under GL 3 should be clustered by TPPs. The respondent argued that this is necessary for root cause determination and in order to allow all parties, including CAs, to get an idea of statistical outliers on the TPPs’ side.	The EBA disagrees and notes that the RTS do not require ASPSPs to publish data on the availability and performance of their dedicated interface clustered by TPPs. In addition, the EBA is of the view that publishing data clustered by TPPs would be practically very difficult and potentially disproportionate, particularly where there are many AISPs and PISPs using the interface, including other APSPSs using the interface in their capacity as AISPs or PISPs. Instead, the EBA considers that ASPSPs should publish this data in a way that enables TPPs and PSUs to compare the availability and performance of the dedicated interface with the availability and performance of each interface made available by the ASPSP to its PSUs for directly accessing their payment accounts online on a daily basis, as highlighted in GL 3.2. See also the response to	No change.
		comment 39 above.
45.	GL 3.2	One respondent suggested extending GL 3.1 (b) (new 3.2) to also cover the comparison of the performance of the dedicated interface with the best-performing PSU interface.	The EBA has amended GL 3.2 for consistency with GL 3.1 to also cover the performance of the dedicated interface and the performance of each PSU interface. As explained in the response to comment 37 above, the EBA notes that GL 3.2 no longer refers to the comparison with the ‘best performing’ PSU interface. See the response to comments 1 and 37 above for more details.	The EBA has amended GL 3.1(b) (new 3.2) as follows: ‘from the date of first The publication publish the comparison of referred to in Guideline 3.1 above should enable PISPs, AISPs, CBPIIs and PSUs to compare the availability and performance of its the dedicated interface with its best-performing PSU interface with the availability and performance of each of the interfaces made available by the ASPSP to its PSUs for directly accessing their payment accounts online on a daily basis’.
46.	General comment	Some respondents were of the view that the KPIs in GL 2 are not appropriate, because different interfaces may have different service level targets depending on the channel chosen by the PSU for accessing its account. The respondents argued that, instead, these KPIs should be replaced with higher-level KPIs, such as the number of critical impacts and incidents; the total outage time and mean recovery time in case of incidents; and performance service levels, for example page load time targets and sign-off/sign-on targets.	The EBA disagrees with the suggestion that the KPIs in GL 2 should be replaced with higher-level ones. The EBA considered whether or not the KPIs suggested by the respondents could be translated into additional KPIs, but it arrived at the view that they are already sufficiently covered in the RTS and the GL, including through the KPIs in GL 2.3 and 2.4, and the contingency measures in Article 33(2) of the RTS and in the new GL 5.1(b) on obstacles. The EBA has therefore decided to retain the minimum set of KPIs in GL 2, as they are necessary to monitor the availability and performance of the dedicated interface and to ensure that the dedicated interface offers the same service levels as the PSU interface(s) in accordance with Article 32(1) and (2) of the RTS.	No change.
47.	GL 2.2 and 2.3	One respondent was of the view that the GL should consider only ‘active’ requests for the purpose of calculating the availability and performance KPIs.	The respondent did not clarify what it means by ‘active’ requests and, therefore, the EBA cannot provide a response. The EBA notes that the KPIs in GL 2.2 and 2.3 refer to requests that are received by the ASPSP from a TPP through the dedicated interface, regardless of	No change.
			whether or not the PSU is in session at the time of the request.
48.	General comment	One respondent requested clarification of whether or not it would be sufficient for an ASPSP, in order to comply with the GL, to follow the existing supervisory practice and regulations at national level setting out requirements on KPIs.	Guidelines are different from regulatory technical standards, to the extent that they are not directly applicable in all EU Member States and for all providers within their scope. Instead, guidelines are a level 3 instrument with which CAs should make every effort to comply. CAs have 2 months, once the final Guidelines are published in all EU official languages, to inform the EBA whether they comply, intend to comply or will not comply. The CA may choose how to introduce the requirements set by the GL within the national framework - this may include complying with existing national rules where relevant and applicable. Where a CA has confirmed it complies (or intends to comply) with the GL, all payment service providers within its jurisdiction have to comply with the GL as they have been incorporated by their CA in the national framework.	No change.
49.	General comments	Some respondents suggested specifying in the GL that CAs are responsible for checking that the dedicated interface matches the highest levels of availability and performance of the best performing PSU interface.	As explained in more detail in the response to comment 37 above, GL 3.1 (b) (new 3.2) no longer refers to a comparison with the ‘best performing’ PSU interface. Instead, the EBA has clarified in the new GL 3.2 that the publication of the daily statistics should enable TPPs and PSUs to compare the availability and performance of the dedicated interface with the availability and performance of each of the interfaces made available to the PSUs for directly accessing their payment accounts online. The monitoring carried out by CAs of the ASPSPs’ ongoing compliance with the requirements set out in the RTS and the GL, including the monitoring of the ASPSP’s compliance with the service level targets in GL 2, forms part of the general supervisory activity of CAs, in accordance with Articles 32(2) and 33(7) of the RTS. The EBA considers that such monitoring by CAs is outside the scope of these GL, as this is not a requirement addressed to ASPSPs.	No change. See, however, the changes made to GL 3.1 (b) (new 3.2), mentioned in the response to comment 37 above.

| 50. General comment | Some respondents argued that ASPSPs’ self-attestation of conformance to performance targets may be misleading and were of the view that the GL should establish a process that TPPs can use to report to the CA any availability and performance issues they experience while accessing the test or production interfaces. The respondents also suggested that the GL should provide guidance to CAs on how to review/consider issues reported by TPPs in the process of granting an exemption. | In order to address the concern that ASPSPs’ self-attestation of conformance to performance targets may be misleading, the EBA has made a number of changes to the GL in order to increase the transparency about the availability and performance of the dedicated interface. These changes include the changes to GL 3.1(b) (new 3.2) which now requires ASPSPs to publish data in a way that enables TPPs and PSUs to compare the availability and performance of the dedicated interface with those of each of the interfaces made available by the ASPSP to its own PSUs for directly accessing their payment accounts online. In addition, the EBA has made a number of changes to the GL in order to clarify that for the purpose of the exemption ASPSPs will need to demonstrate TPPs’ involvement in the design and testing of the dedicated interface. This includes the requirement in the new GL 6.1 requiring all ASPSPs to provide their CA with information on whether and, if so, how they have engaged with TPPs; the new GL 6.6, which requires ASPSPs to provide the feedback they received from TPPs that have participated in the testing to their CA, together with an explanation of how the ASPSP has addressed any issues identified in the testing; and GL 8 which, as further explained in the response to comment 139 below, requires the ASPSP to provide the CA with an explanation of the problems reported by TPPs regarding the ASPSP’s production interface that have not been resolved by the ASPSP in accordance with the service level targets under GL 2.1. Furthermore, the EBA has added a new GL 6.7 which provides that CAs may also take into account, when assessing the ASPSP’s compliance with the design condition in Article 33(6)(b) of the RTS, any problems reported by TPPs to the CA in relation to the elements to be tested in accordance with GL 6.5. Having said this and while TPPs can always come to the CAs directly, the EBA strongly encourages TPPs to | The EBA has amended GL 3.1(b), 6.1, 6.6 and 8.1 as follows: GL 3.1(b) (new 3.2): ‘from the date of first The publication publish the comparison of referred to in Guideline 3.1 above should enable PISPs, AISPs, CBPIIs and PSUs to compare the availability and performance of its the dedicated interface with its best-performing PSU interface with the availability and performance of each of the interfaces made available by the ASPSP to its PSUs for directly accessing their payment accounts online on a daily basis’. GL 6.1 ‘For the purposes of
evidencing compliance with the requirement in letter (b) of Article 33(6) of the RTS regarding the design of the dedicated interface, the ASPSP should provide the competent authority with: [...] b. information on whether, and if so, how the ASPSP has engaged with PISPs, AISPs and CBPIIs [...]’. GL 6.6 ‘The ASPSP should provide to the competent authority with a summary of the results of the testing for the referred to in Article 30(5) of the RTS for each of the elements to be tested in accordance with letters (a) to (g) of paragraph 6.5 above, including the identification of number of PISPs, |
|---|---|---|---|

			communicate any issues they experience with the test or the production interfaces to the ASPSP, as a first port of call, and try to resolve those issues together with the ASPSP, so they can be addressed in a timely manner. See also the response to comment 112 below.	AISPs and CBPIIs that have used the testing facility, the feedback received by the ASPSP from these PISPs, AISPs and CBPIIs, the weaknesses issues identified and a description of how these weaknesses issues have been addressed. GL 8.1 For the purpose of Article 32(1) and letter (d) of Article 33(6)(d) of the RTS, the ASPSP should provide to the competent authority with: 4.information on the systems or procedures in place for tracking, resolving and closing problems, including particularly those reported by PISPs, AISPs and CBPIIs; and 5.an explanation of the problems, particularly those reported by PISPs, AISPs and CBPIIs, that have not been resolved without undue delay in accordance with the service level targets and support detailed set out in Guideline 2.1. Also, the EBA has added a new GL 6.7 as follows: ‘6.7 For the purpose of assessing whether the ASPSP meets the requirements in letter (b) of Article 33(6) of the RTS, the competent authority may also take into account any problems reported to it by PISPs, AISPs and CBPIIs in relation to Guideline 6.5 above’.
51. General comment	One respondent suggested that the GL should include a clear commitment from the EBA and the CAs to define future solutions for technically monitoring dedicated interfaces in an automated, cost-efficient and future-proof way. The respondent suggested that, as a first step, the EBA and CAs should create a central online web platform at EU level, where they could gather data on KPIs from all ASPSPs in standardised formats and make them available, on a restricted access basis, to reporting ASPSPs, TPPs and CAs. The respondent also suggested that CAs should define a strategy that would allow them, in the longer term, to carry out their own automated monitoring and testing of the ASPSPs’ dedicated interfaces.	The EBA is of the view that this is outside the scope of these GL. However, the EBA agrees that such centralised monitoring could possibly be beneficial to the industry.	No change.
Feedback on responses to question 2
52. General comment	Several respondents suggested that the GL should be more specific regarding the stress tests to be run, and the assumptions that ASPSPs will need to adopt for stress testing. One respondent suggested that a standard template should be provided with the tests to be run by ASPSPs for stress testing. Other respondents were of the view that CAs should define at national level what is meant by ‘extremely high number of requests’, ‘high number of concurrent sessions’ and ‘heavy loads’, as these terms are subjective and vary from country to country. Finally, other respondents were of the view that GL 4 should remain high-level and that stress testing should be based on the ASPSPs’ forecasts regarding the level of take-up of their dedicated interfaces. One respondent was of the view that the take-up levels are likely to be relatively low at first, followed by a growing usage over the following 2 to 3 years. Another respondent was of the view that the terms used in GL 4.2 are relative to the size of the ASPSP.	In line with GL 4.1, the stress testing should establish and assess how the dedicated interface performs when subjected to an extremely high number of requests from PISPs, AISPs and CBPIIs. In designing the stress tests, PSPs should follow common practices. In this context, the reference to ‘extremely high number’ of requests means that the number of requests goes significantly beyond what the interface has been designed for, which should be determined based on the ASPSPs’ forecasts regarding the level of take-up of their dedicated interfaces by TPPs. For proportionality reasons, the EBA considers that the size of the ASPSP should also be considered when determining the minimum stress test levels. As the level of take-up of the dedicated interface may differ, the EBA is of the view that these GL should not prescribe minimum stress levels. However, the EBA has clarified in GL 4.3 that ASPSPs should provide their CA with the assumptions used for stress testing, as well as the summary of the results of the stress tests, and thus allowing the CAs to verify the basis on which the stress	The EBA has amended GL 4.3 as follows: ‘The ASPSP should provide to the competent authority with a summary of the results of the stress testing tests, including the assumptions used as a basis for stress testing each of the elements in letters (a) to (d) of Guideline 4.2 above, and how any weaknesses or issues identified and confirmation that these have been addressed’ See also the changes made to GL 4.2, highlighted in the response to comment 54 below.
			tests have been conducted.
53.	General comment	A few respondents suggested that, where ASPSPs already undertake stress testing as part of their normal processes before market launch and under the supervision of their CAs, they should be granted a dispensation not to comply with GL 4.	The EBA disagrees and is of the view that all ASPSPs seeking an exemption to the fall back-mechanism should comply with GL 4.	No change.
54.	GL 4.1. and 4.2	One respondent suggested clarifying in GL 4.2(a) that ‘firms’ refers to PISPs, AISPs and CBPIIs. Another respondent was of the view that stress testing should not cover CBPII requests, because this service is not offered via the PSU interface.	The EBA agrees that the stress testing should also cover CBPII requests and acknowledges that the terminology used in GL4 has not always been consistent. The EBA has therefore amended GL 4.1 and 4.2 in order to clarify that stress testing also covers CBPIIs, and that the reference to ‘firms’ in GL 4.2(a) refers to PISPs, AISPs and CBPIIs.	The EBA has amended GL 4.1 and 4.2 as follows: ‘4.1 For the purpose of the stress tests referred to in Article 32(2) of the RTS, the ASPSP should have in place processes to establish and assess how the dedicated interface performs when subjected to an extremely high number of requests from PISPs and, AISPs and CBPIIs, in terms of the impact that such stresses have on the availability and performance of the dedicated interface and the defined service level targets’. ‘4.2 The ASPSP should undertake adequate stress testing of the dedicated interface including but not limited to: 6.the capability to support access by multiple firms PISPs, AISPs and CBPIIs; 7.the capability of the dedicated interface to deal with unusually an extremely high numbers of requests, from PISPs, AISPs and CBPIIs, in a short period of time without failing; 8.the use of an extremely high number of concurrent sessions open at the same time for payment initiation and, account information and confirmation on the availability of
				funds requests; and 9.requests for large volumes of data’.
55.	GL 4.2	One respondent was of the view that the dedicated interface should be able to handle, for AIS, at least four times the current daily volume of users, and that TPPs should be able to verify if the interface can handle this load and, if not, they should report it to the CA. Another respondent was of the view that stress testing should not assume that all of an ASPSP’s customers will use AIS or PIS from the outset and that, instead, stress testing should be based on the ASPSP’s forecasts of take-up.	As explained in more detail in the response to comment 52 above, the EBA is of the view that the minimum stress levels should be determined by the ASPSPs, based on their forecasts regarding the level of take-up of their dedicated interfaces. ASPSPs should provide these assumptions to their CA, allowing the CA to verify the basis on which the stress tests have been conducted.	No change. See, however, the changes made to GL 4.3, highlighted in the response to comment 52 above.
56.	GL 4.2	One respondent was of the view that GL 4.2 should clarify the duration of the stress testing.	The EBA is of the view that the duration of the stress testing is outside the scope of these GL	No change.
57.	GL 4.2	One respondent was of the view that the stress testing should also cover the external network to which ASPSPs will connect their API.	The EBA considers that this is part of the general IT/security testing that ASPSPs are required to carry out before the launch of the production interface.	No change.
58.	GL 4.2	One respondent was of the view that stress testing should also cover contingency plans, for example in the scenario of a DDOS attack.	The EBA notes that this is already covered in Article 33 of the RTS regarding contingency measures.	No change.
59.	GL 4.3	One respondent was of the view that the summary of the results of the stress testing in GL 4.3 should specify how the weaknesses identified during the testing period have been solved.	The EBA agrees with the suggestion made by the respondent and has amended GL 4.3 accordingly.	The EBA has amended GL 4.3 as follows: ‘The ASPSP should provide to the competent authority with a summary of the results of the stress testing tests, including […] how any weaknesses or issues identified and confirmation that these have been addressed’.

60.	GL 4.3	Several respondents were of the view that TPPs should be involved in stress testing and that the results of stress testing should be made available to TPPs. One respondent was of the view that the stress testing should be conducted by licensed TPPs and that reports should be produced by both TPPs and ASPSP and sent to the CA. The respondent also suggested that TPPs should send their stress testing plan to CAs to ensure all ASPSPs are tested in the same way.	The EBA is of the view that TPPs will have the opportunity to conduct sufficient testing in the context of the testing facility and that the stress testing is the responsibility of the ASPSP, based on the expected level of take-up of the dedicated interface by TPPs. The EBA encourages ASPSPs to engage with TPPs when establishing these assumptions, in order to understand and forecast when peak usage or other stresses may occur. See also the response to comment 52 above.	No change. See, however, the changes made to GL 4.3, highlighted in the response to comment 52 above.
61.	GL 4.3	Some respondents requested clarification regarding the format in which ASPSPs should submit the summary of the results of the stress testing to the CA and the method of submission.	The EBA is of the view that the format in which and the method by which a CA requires ASPSPs to submit the information required under the GL is a decision for the CA to take and is outside the scope of these GL.	No change.
62.	General comment	One respondent was of the view that any overlap with the reporting requirements under the existing stress testing frameworks should be avoided.	The EBA agrees that the risk of double reporting should be minimised, wherever possible.	No change.
63.	General comment	Some respondents suggested that the results of the stress testing for the dedicated interface should be compared with the results of the stress testing for the PSU interface(s) and that ASPSPs should provide the CA with a summary of the results of stress testing for all access interfaces. Other respondents were of the opposite view and argued that the usage pattern of the dedicated interface will differ from that of the PSU interface(s) and that, therefore, the stress testing may be different across interfaces.	The EBA considers that a comparison with the results of the stress testing for the PSU interface(s) may not be appropriate, because the usage pattern of the dedicated interface is likely to differ from the customer interface(s), thus the volumes going through the two channels may not be comparable. As a result, the stress tests may be different across the dedicated interface and the PSU interfaces. See also the response to comment 52 above.	No change. See, however, the changes made to GL 4.3, highlighted in the response to comment 52 above.
64.	General comment	One respondent was of the view that the dedicated interface should be able to endure similar stress levels to those of an ASPSP’s ‘private’ dedicated interface and that CAs should define the minimum stress levels to be handled by both the ASPSPs’ ‘private’ dedicated interfaces and the dedicated	As explained in the response to comment 5 above, the EBA is of the view that the dedicated interface should be compared with the interface(s) made available to the PSU for directly accessing its payment account online and not with the ASPSPs’ ‘private’ interfaces. Therefore, the EBA does not agree with the suggested comparison between	No change.
		interface.	the dedicated interface and the ASPSPs’ ‘private’ dedicated interfaces.
65.	General comment	Several respondents requested clarification regarding the frequency of stress testing. In particular, the respondents requested clarification of whether stress testing should be carried out only when an ASPSP applies for an exemption to the fall back mechanism and following important changes to the dedicated interface, or whether it should be conducted periodically. Also, one respondent requested clarification of whether or not stress testing should be conducted in the ‘pre-production’ environment.	The EBA is of the view that, for the purpose of applying for an exemption from the fall back mechanism, the ASPSP should demonstrate that it has conducted the stress testing, in accordance with GL 4, at least once before applying for the exemption. However, the obligations applicable to dedicated interfaces under the RTS will have to be complied with at all times, which means that stress testing is an ongoing obligation, although it is not within the scope of these GL. The stress testing should test that, once in operation with AISPs, PISPs and CBPIIs, the ASPSPs’ dedicated interfaces will be able to handle large volumes of requests from PISPs, AISPs and CBPIIs. For the purpose of the application for an exemption ahead of the 14 September 2019 deadline, ASPSPs should conduct the stress testing in the context of their production environment. As is common practice for stress testing, certain processes (such as settlement of payments) might be simulated during stress testing.	No change.
66.	General comment	One respondent was of the view that it is important to allow ASPSPs to make use of an IT-group service centre, or a common technical service provider, to fulfil the stress testing on behalf of multiple ASPSPs.	The EBA considers that the GL do not restrict such a possibility. However, the EBA notes that, in such a case, the summary of the results of the stress testing should be specific to each individual ASPSP.	No change.
67.	General comment	One respondent was of the view that ASPSPs should provide consistent and conformant error messages to the TPPs if the dedicated interface is unable to process TPP requests because of stress.	The EBA notes that the RTS do not impose any standardised error messages that ASPSPs should send to TPPs in accordance with Article 36(2) of the RTS. Therefore, the EBA is of the view that the GL cannot impose this either.	No change.
68.	General comment	One respondent was of the view that stress testing results should be integrated in a joint and access-restricted KPI web platform at EU level so that the results across Member States are easily comparable.	See the response to comment 51 above.	No change.

Feedback on responses to question 3

69.	General comments	Some respondents agreed that the monitoring of KPIs by CAs cannot be one of the requirements for granting an exemption and that it should be part of the supervisory activity of CAs. Other respondents were of the opposite view, that the monitoring by CAs should be a precondition for granting an exemption. These respondents argued that ASPSPs self-attestation of compliance with the service level targets set will not be objective and suggested that CAs should consult with TPPs prior to granting an exemption. Some respondents also suggested that an early warning mechanism should be put in place that would allow TPPs to instantly inform the ecosystem in case of technical issues with a dedicated interface. One respondent suggested that CAs could use independent third parties to monitor ASPSPs’ interfaces, indicators and targets on a risk-adjusted and/or targeted basis as part of their assessment of the application for an exemption. Other respondents highlighted that ASPSPs should provide CAs with all the material they need to perform the monitoring within a reasonable timeframe before granting an exemption. Several respondents requested clarification of whether CAs are responsible for monitoring the contents of the data published by ASPSPs or just that the quarterly reports have been published.	As explained in the response to comment 49 above, the monitoring of the ASPSPs’ ongoing compliance with the requirements set out in the RTS and these GL, including the monitoring of the ASPSPs’ compliance with the service level targets in GL 2 and with the requirements in Article 32 of the RTS, will be part of the general supervisory activity of CAs, in accordance with Articles 32(2) and Article 33(7) of the RTS. The EBA is of the view that such monitoring is outside the scope of these GL, as it is not a requirement with which ASPSPs can plausibly comply. The EBA considers that the GL should focus on the requirements that ASPSPs should meet for the purpose of qualifying for an exemption, rather than on the monitoring by CAs. Regarding the comment raised by the respondents that the ASPSPs’ self-attestation of compliance with the service level targets set will not be objective, please refer to the answer to comment 50 above.	No change. See, however, the changes made to GL 3.1(b) (new 3.2), highlighted in the response to comment 50 above.
70.	General comments	One respondent suggested that the GL should include references to the level of market activity, market intelligence and user complaints to be used for the supervisory activity of CAs.	As explained in the responses to comments 49 and 69 above, the monitoring of the ASPSPs’ ongoing compliance with the requirements set out in the RTS and these GL is part of the general supervisory activity of CAs and is	No change.
		Another respondent suggested aligning the monitoring period with that applicable to normal online channels.	outside the scope of these GL.
71.	General comments	Some respondents suggested that the CAs should create a central source of information where aggregated statistical data could be gathered, in addition to ASPSPs publishing data on their own respective websites.	Please see the response to comment 51 above.	No change.
72.	General comments	One respondent suggested clarifying in the GL that no additional reporting will be required from ASPSPs on the availability and performance of their dedicated interfaces other than the statistics published on the ASPSPs’ websites in accordance with GL 3.	The EBA notes that the requirements set out in the GL are without prejudice to any other obligations applicable under other legal instruments, including, for example, the reporting of security incidents under PSD2. Therefore, the EBA considers that such confirmation cannot be given.	No change.
Feedback on responses to question 4
73.	GL 5.1 and 5.2(a)	Several respondents suggested aligning the wording of GL 5.1 and 5.2(a) with the terminology used in the RTS and the EBA Opinion and also suggested clarifying what is meant by ‘methods of access’ in GL 5.1. One respondent suggested aligning the wording in GL 5.2(a) with the wording in Article 97(5) of PSD2.	The EBA agrees with the suggestion made by the respondents and has clarified that ‘methods of access’ refers to the methods of carrying out the authentication procedure of the PSUs that are supported by the dedicated interface, i.e. redirection, decoupled, embedded or a combination thereof, in line with the wording in the EBA Opinion. The EBA also aligned the wording in GL 5.1(b) with Article 97(5) of PSD2.	The EBA has amended GL 5.1 and 5.2(a) as follows: ‘5.1 In addition to the requirements set out in Articles 65, 66, 67 and 97 PSD2 and in the RTS, t The ASPSP should provide to the competent authority with: a. a summary of the method(s) of access chosen carrying out the authentication procedure(s) of the PSUs that are supported by the ASPSP dedicated interface, i.e. redirection, decoupled, embedded or a combination thereof; and b. where the ASPSP has put in place only one method of access, an explanation of the reasons why this the method(s) of access carrying out the authentication procedure(s) referred to in paragraph (a) is/are not an obstacle as referred to in

				Article 32(3) of the RTS and how this such method(s) of access supports allow(s) PISPs and AISPs to rely on all the authentication methods procedures provided by the ASPSP to its PSUs [...]’. ‘5.2 As part of the explanation referred to in letter (b) of Guideline 5.1,Tthe ASPSP should provide to the competent authority with a confirmation that: a. the dedicated interface does not prevent PISPs and AISPs from relying upon the security credentials issued authentication procedure(s) provided by the ASPSP to its PSUs [...]’
74.	GL 5.1(b)	Some respondents asked whether ASPSPs should provide the explanation in GL 5.1(b) when they provide multiple methods of access (e.g. redirection and decoupled) or when they provide only one method of access. One respondent suggested deleting this requirement altogether.	Following the comments made by the respondents, the EBA has further considered this issue and has reached the view that ASPSPs should provide the explanation in GL 5.1 (b) both when the dedicated interface supports only one method of access and when it supports several methods of access (redirection, decoupled, embedded or a combination thereof). The EBA is of the opinion that CAs should always look at whether or not the dedicated interface creates obstacles to the provision of PIS and AIS, regardless of whether the ASPSP has implemented only one or several methods of access. The EBA has consequently amended GL 5.1(b) in line with the above. The EBA disagrees with the suggestion to delete this requirement and continues to be of the view that it is an essential part of the CAs’ evaluation and that it is aligned with the intention of Article 32(3) of the RTS.	The EBA has amended GL 5.1(b) as follows: ‘5.1 In addition to the requirements set out in Articles 65, 66, 67 and 97 PSD2 and in the RTS, tThe ASPSP should provide to the competent authority with: [...] b. where the ASPSP has put in place only one method of access, an explanation of the reasons why this the method(s) of access carrying out the authentication procedure(s) referred to in paragraph (a) is/are not an obstacle, as referred to in Article 32(3) of the RTS, and how this such method(s) of access supports allow(s) PISPs and AISPs to rely on all the authentication methods procedures provided by the ASPSP to its PSUs [...]’.

75.	GL 5.2(a)	One respondent mentioned that some SCA procedures (e.g. fingerprint authentication) are not possible in the ‘embedded’ model because of technical restrictions and suggested that the EBA clarify in the GL that this should not be seen as an obstacle.	The EBA notes that, in accordance with Article 97(2) of PSD2 and GL 5.2(a), ASPSPs should ensure that the dedicated interface does not prevent PISPs and AISPs from relying upon the authentication procedure(s) provided by the ASPSP to its PSUs. As stated in the EBA Opinion, ASPSPs should ensure that the dedicated interface supports all the methods for authentication that the ASPSP provides to its own PSUs. This means that, where fingerprint authentication is used by the PSU to access the ASPSP’s PSU interface, fingerprint authentication should also be available to the PSU when accessing its account through an AISP or PISP. If an ASPSP only provides access via the embedded model (or a variation of it), but cannot accommodate all methods of authentication provided to its own PSUs, then the ASPSP will have to provide another method of access for the purpose of carrying out SCA.	No change. See, however, the changes made to GL 5.2(a), highlighted in the response to comment 73 above.
76.	GL 5.2 (a)	One respondent suggested that the EBA should clarify in GL 5.2(a) that TPPs do not need to know the static password of the PSU. Another respondent mentioned that it is essential that the PSU’s security credentials are not shared with the PSP and that they remain under the sole control of the PSU.	The EBA is of the view that the protection and handling of the PSU’s security credentials by PSPs are governed in PSD2 and the RTS and that such aspects are outside the scope of these GL.	No change.

77.	GL 5.2(b)	Several respondents interpreted GL 5.2(b) as allowing ASPSPs to introduce new requirements, in addition to those imposed by law, to TPPs using their interface, as long as such requirements are imposed on all PSPs. Several respondents were concerned that this could be used as a justification of obstacles.	The EBA agrees with the respondents that the initial wording of GL 5.2(b) may not have been clear and could have been misread as allowing ASPSPs to impose additional requirements on AISPs, PISPs and CBPIIs that are not required by law. The EBA has therefore amended GL 5.2(a) in line with Article 32(3) of the RTS.	The EBA has amended GL 5.2(b) as follows: ‘5.2 As part of the explanation referred to in letter (b) of Guideline 5.1, Tthe ASPSP should provide to the competent authority with a confirmation that: [...] b. no additional authorisations or registrations are required from PISPs, AISPs and or CBPIIs do not have to comply with any different or additional requirements, other than those imposed by legislation in Articles 11, 14 and 15 of PSD2, that are not equally imposed on all other types of payment service providers (PSPs)’.
78.	GL 5.2(b)	One respondent argued that the requirement in GL 5.2(b) to treat all TPPs identically is inconsistent with the intent of PSD2 and, more specifically, with Article 35 of PSD2. In the respondent’s view, ASPSPs should be allowed to apply different terms of access for individual PSPs based on a case-by-case assessment, taking into account the specific risks and local requirements relevant to each PSP.	As explained in the response to comment 77 above, the EBA has amended GL 5.2(b) in line with Article 32(3) of the RTS and has removed the references to the provisions to which the respondent refers. The EBA also notes that Article 35 of PSD2 does not apply in this case, as it refers to access to payment systems and not to the access of TPPs to the customers’ payment accounts held with an APSPS.	No change. See, however, the changes made to GL 5.2(b), highlighted in the response to comment 77 above.
79.	GL 5.2(c)	One respondent suggested clarifying in GL 5.2(c) that the ASPSP is not expected to confirm a workflow managed between the PSU and TPP.	The EBA agrees with the respondent that some clarification was needed and has refined the wording of GL 5.2(c) in order to clarify that this provision refers to checks imposed by the ASPSP on the consent given by the PSU to the AISP or the PISP.	The EBA has amended GL 5.2(c) as follows: ‘c. there are no additional checks by the ASPSP on the consent, as referred to in Article 32(3) of the RTS, given by the PSU to the PISP or , the AISP or CBPII to access the information of on the payment account(s) held in with the ASPSP or to initiate payments;’

| 80. | GL 5.2(c) and 5.2(d) (new 5.1(b)) | Several respondents requested clarifications on what would represent an ‘additional check on consent’ under GL 5.2(c). In particular, respondents asked whether, in the redirection model, an ASPSP can, as part of the authentication process, enable the PSU to confirm the TPP’s access before the ASPSP proceeds with servicing the TPP’s request, or whether such confirmation would represent an obstacle. Some respondents were of the view that, in the redirection model, the ASPSP displaying information to the PSU on the type of access being requested, the duration, the data and accounts with the possibility of the PSU selecting the accounts for which access is granted on the ASPSP’s domain does not represent an obstacle if the same confirmation is also requested when the PSU is accessing its account directly. These respondents argued that ASPSPs have a duty of care to confirm what is being shared or executed before handing over data or initiating a payment. Another respondent was of the view that, in the redirection model, where the PSU is redirected to its ASPSP to authenticate, the PSU’s interaction with the ASPSP should be minimised, and redirection should merely facilitate the PSU’s authentication, leaving the account selection and all other steps to the TPP. The respondent argued that, in the redirection model, when the account to be credited is not known beforehand, the PSU should be redirected back to the TPP’s interface after the SCA step and should be able to select the payment account on the TPP’s domain. | The EBA agrees with the respondent stating that, in a redirection scenario, the PSU’s interaction with the ASPSP should be minimised to the extent that, as stated in the new GL 5.1(b), the dedicated interface should ‘not give rise to unnecessary delay or friction in the experience available to the PSUs when accessing their account via a PISP, AISP or CBPII or to any other attributes, including unnecessary or superfluous steps or the use of unclear or discouraging language, that would directly or indirectly dissuade the PSUs from using the services of PISPs, AISPs and CBPIIs’. The EBA is of the view that asking the PSU to confirm if the TPP can have access to the PSU account in general terms before the ASPSP proceeds would likely be an obstacle, given that such confirmation would amount to a check on consent. By contrast, the ASPSP may require the PSU to confirm the payee and the amount of the payment transaction after the PSU has input its credentials on the ASPSP’s domain and before redirecting the PSU to the PISP’s interface, without this representing an obstacle, in the same way as it would do for its customers, and provided that, in line with the amended GL 5.1(b), it does not use unclear or unnecessary language and does not require the PSU to provide or confirm superfluous information. In an AIS context, with respect to the ASPSP displaying information to the PSU following redirection
from the AISP on the type of access being requested, the duration, the data and accounts, the EBA notes that it is the AISP’s responsibility to obtain explicit consent for the data being accessed. ASPSPs are not required to check or confirm the terms of the consent provided by the PSU to AISPs or PISPs. The presentation of this information should not be used to obtain the PSU’s confirmation that they have consented to the information being shared with the TPP. On the question of whether or not the selection of the payment account on the ASPSP’s domain is an obstacle to | No change. See, however, the changes made to GL 5.2(d) (new 5.1(b)), highlighted in the response to comment 90 below. |
|---|---|---|---|---|
| | | | the provision of PIS services, the EBA is of the view that this will depend on whether or not the PSU selects the account at the level of the PISP, prior to being redirected to the ASPSP for authentication. If the PSU selects the account in the PISP’s domain, and the PISP communicates the account selected to the ASPSP, together with the payment initiation request, the EBA is of the view that the ASPSP should not request that the PSU select the account again before executing the PISP’s request. If the PSU does not select the account in the PISP’s domain and the account is not known in advance, the EBA is of the view that the ASPSP may ask the customer to select the account on the ASPSP’s domain, as part of the authentication step, before the customer is redirected back to the PISP’s interface, without this representing an obstacle. | |
| 81. | GL 5.2(c) | Several respondents requested clarification on what is meant by ‘consent’ in GL 5.2(c) and, in particular, whether this refers to the consent in Article 67(2)(a) of PSD2. | The EBA has clarified in GL 5.2(c) that the reference to ‘consent’ has the same meaning as in Article 32(3) of the RTS. This includes, for PIS, the consent given by the PSU to the PISP in accordance with Article 66(2) of PSD2 and for AIS, the consent given by the PSU to the AISP in accordance with Article 67(2)(a) of PSD2. | The EBA has amended GL 5.2(c) as follows: ‘c. there are no additional checks by the ASPSP on the consent, as referred to in Article 32(3) of the RTS, given by the PSU to the PISP or , the AISP or CBPII to access the information of on the payment account(s) held in with the ASPSP or to initiate payments;’ |
| 82. | GL 5.2(c) | One respondent was of the view that ASPSPs should receive information on the consent given by the PSU to the TPP and should be able to check such consent before executing requests, without this representing an ‘obstacle’ under GL 5.2(c). The respondent referred to the Berlin Group specifications and argued that, under these specifications, the consent is saved in the ASPSP’s database and, therefore, the ASPSP is checking the consent given by the PSU to the TPP. | The EBA notes that, in accordance with Article 33(3) of the RTS and GL 5.2(c), any checks by the ASPSP of the consent given by the PSU to the PISP or the AISP would represent an obstacle. The EBA is of the view that it is the obligation of the PISP/AISP to ensure that the PISP/AISP has obtained the PSU’s explicit consent, as required by Articles 66(2) and 67(2)(a) of PSD2. | No change. |

83.	GL 5.2(c)	One respondent requested clarification on who bears the responsibility for fraudulent behaviour, in case the ASPSP does not have information about the consent given by the PSU to the TPP while it is executing the TPP’s requests.	The EBA notes that the allocation of liability between PSPs in cases of unauthorised transactions is governed by PSD2 and is outside the scope of these GL. For any further clarification regarding the interpretation of PSD2 or the RTS, the EBA encourages the respondent to submit a question to the EBA via the EBA Q&A tool.	No change.
84.	GL 5.2(c)	One respondent requested clarification of whether or not ASPSPs can check the consent given by the PSU to the TPP, provided that all the parties agree.	The EBA is of the view that this would not constitute an obstacle if expressly agreed between the TPP and the ASPSP, based on a contract, and with the consent of the PSU.	No change.
85.	GL 5.2(c)	One respondent requested clarifications of whether or not paragraph 13 of the EBA Opinion should be understood as requiring ASPSPs to check if there is a contract in place between the PSU and the PISP/AISP and, if so, whether or not this would represent an ‘additional check on consent’.	The paragraph from the EBA Opinion to which the respondent refers states that, ‘where AIS or PIS are provided to a payment service user (PSU) following a contract that has been signed by both parties, ASPSPs do not have to check consent’. The EBA clarifies that this does not mean that the ASPSP needs to check whether there is a contract in place between the PSU and the AISP or the PISP. As explained in the response to comment 82 above, the obligation to ensure that the PISP/AISP has obtained the PSU’s explicit consent, as required by PSD2, lies with the PISP/AISP, and the ASPSP cannot oblige the PISP/AISP to provide the consent given by the PSU (or the contract in place between the PSU and the PISP/AISP), otherwise this would represent an obstacle.	No change.
86.	GL 5.2(c) and new GL 5.2(d)	Several respondents suggested clarifying the reference to CBPIIs in GL 5.2(c), taking into account the fact that the PSU needs to give prior consent to the ASPSP to respond to requests from CBPIIs.	The EBA acknowledges that the reference to CBPIIs in GL 5.2(c) may have been unclear, and has amended GL 5.2 to clarify that, for CBPIIs, the issue of checking consent has to be worded slightly differently from the wording for PISPs and AISPs, because PSD2 requires the PSU to provide, in addition to the explicit consent to the CBPII in accordance with Article 65(2)(a) PSD2, a further explicit consent to the ASPSP, so the latter can respond to requests from a specific CBPII, before the first request for confirmation is made, in accordance with Article 65(1)(b) and (c) of PSD2. The EBA is of the view that the consent given by the PSU to the	The EBA has deleted the reference to CBPIIs from GL 5.2(c) and added a GL 5.2(d) as follows: ‘5.2 As part of the explanation referred to in letter (b) of Guideline 5.1, Tthe ASPSP should provide to the competent authority with a confirmation that: [...] c. there are no additional checks by the ASPSP on the consent, as referred to in Article 32(3) of the RTS, given by
			ASPSP, in accordance with Article 65(1)(b) and (c) of PSD2, is not a check on the consent given to the CBPII and is therefore not an obstacle. This has been clarified in the new GL 5.2(d).	the PSU to the PISP or , the AISP or CBPII to access the information of on the payment account(s) held in with the ASPSP or to initiate payments; d. no checks on the consent given by the PSU to the CBPII in accordance with Article 65(2)(a) of PSD2 are performed.‘
87.	GL 5.2(c) and paragraph 34(c) of the CP	One respondent was of the view that paragraph 34(c) of the CP is unclear and suggested that it should be clarified further.	The EBA acknowledges that the wording of this paragraph may not have been clear and clarifies that the intention was to highlight that it is the responsibility of AISPs and PISPs to ensure that they have obtained the explicit consent from the PSU in accordance with Articles 66(2) and 67(2)(a) of PSD2. See also the response to comment 82 above.	No change.
88.	GL 5.2(c)	Some respondents requested clarification of whether or not the PSU can disable certain TPP services at the ASPSP’s level, based on paragraphs 9.3 and 9.4 of the EBA Guidelines on security measures for operational and security risk under PSD2 (EBA/GL/2017/17), without this representing an obstacle under GL 5.2. Several respondents suggested that PSUs may request that the ASPSP, based on these provisions, disable certain TPP services and that, in such cases, the ASPSP can accept a request from a TPP only after the PSU has reversed the action or has given a new consent to the ASPSP.	The EBA is of the view that the provisions referred to from the EBA Guidelines on security measures for operational and security risk under PSD2 relate to the payment services that the ASPSP is providing to its own customers, and cannot be used as a justification for an ASPSP to refuse to provide access to payment account data to a PISP or AISP. The EBA reminds respondents that the reasons why an ASPSP may deny an AISP or PISP access to a payment account are set out in Article 68(5) of PSD2, and have to be objective, duly justified and related only to unauthorised or fraudulent access to the payment account.	No change.
89.	GL 5.2(a) and 5.2(d) (new 5.1(b))	(a) Several respondents were of the view that redirection-only does not comply with PSD2 and is always an obstacle, regardless of how frictionless the PSU’s experience is. (b) These respondents argued that the right offered to TPPs under PSD2, to rely on the security credentials provided by the ASPSP to its PSUs implies that TPPs should be allowed to forward the PSU’s security credentials to the ASPSP if	(a) As clarified in the EBA Opinion, the EBA is of the view that redirection is not, in itself, an obstacle to AIS or PIS, but that it ‘may’ be so, if the ASPSP implements it in a manner that creates delay or friction in the customer experience that would dissuade PSUs from using the services of AISPs or PISPs. The amended GL 5.1 (b) illustrates this view. (b) The EBA is of the opinion that ‘redirection’ does not deny the right of AISPs or PISPs to use, or rely on, the	No change.

they are shared by the PSU with the TPP. (c) One respondent also interpreted the reference in Recital 32 of PSD2 to the ‘direct access’ for the PISP to the payer’s account as implying that the PSU can share its credentials with the PISP and that the latter may forward them to the ASPSP in order to access the PSU’s account.

(d) In addition, the respondents referred to various recitals and articles in PSD2 and the RTS on the sharing of credentials ‘by’ or ‘through’ a PISP or AISP as arguments against redirection, including:

the obligation of PISPs under Article 66(3)(b) of PSD2 to ensure that the personalised security credentials (PSC) of the PSU are transmitted ‘by’ the PISP through safe and efficient channels;
the obligation of ASPSPs under Article 30(2)(c) of the RTS to ensure the integrity and confidentiality of both the PSC and authentication codes transmitted ‘by or through’ the PISP or the AISP via the dedicated interface.

(e) Some respondents also argued that the reference to ‘may’ in Article 32(3) of the RTS does not mean that the examples listed may or may not be obstacles but that it can only mean that the list is not comprehensive. These respondents argued that, otherwise, the other examples listed would also be only potential obstacles, which would make the specified list unnecessary. In the respondents’ view, the only reason for including the list of obstacles is to clarify that each of those four obstacles on an individual basis is without any doubt an obstacle.

security credentials provided by the ASPSP to its PSUs, because the AISP/PISP is not required to issue its own credentials or authentication procedures, and is able to rely on the ASPSP’s authentication procedures.

(c) The EBA considers that Recital 32 of PSD2 was intended neither to refer to methods of access via an ASPSP’s dedicated interface (such as redirection, embedded or decoupled) nor to give preference to one method of access over another. As regards access by screen scraping, the EBA, having consulted with the Commission on the interpretation of PSD2, has clarified in its final report on the RTS (EBA/RTS/2017/02) and the EBA Opinion on the transition from PSD1 to PSD2 (EBA/Op/2017/16) that the existing practice of third-party providers accessing the PSU data via the customer interface and without identification (commonly referred to as ‘screen scraping’) will no longer be allowed once the RTS apply.

Furthermore, the EBA reminds respondents that Recitals are not legally binding, and therefore do not confer rights and obligations, and that they need to be read in the context of the applicable provisions of the legal text – in this case, PSD2 and the RTS. The EBA notes that Article 31 of the RTS gives ASPSPs an option to provide access to TPPs either by means of a dedicated interface, or by allowing TPPs the use of the customer-facing interface, adapted in order to comply with the requirements in PSD2 and the RTS.

For these reasons, the EBA does not consider that the Recital 32 of PSD2 can be interpreted in the way suggested by the respondents, namely as offering PISPs a right to request that the PSU share its security credentials with the PISP and that for the PISP forward these credentials to the ASPSP. See also the response to (a) above.

(f) In addition, these respondents argued that redirection: - limits innovation, because it works only when the PSU is using a web browser or the ASPSP’s mobile app and, therefore, it does not allow PISPs to offer innovative types of payments, such as voice-based payments, payments at point-of-sale or payments via wearables; - limits TPPs’ ability to compete, because it deprives them of the ability to design the customer journey; and - offers a worse customer experience than the services offered today by TPPs using screen scraping and that consumers that are used to other methods of access (embedded) should not be obliged to use redirection.

(g) The majority of those respondents who argued against redirection supported its use alongside other access methods, such as the embedded and/or decoupled methods. One respondent suggested that the EBA should require ASPSPs to offer the embedded and/or decoupled methods, where such methods are applicable for a specific ASPSP and its authentication methods. Another respondent interpreted paragraph 50 of the EBA Opinion as requiring ASPSPs to support the decoupled method of access.

(h) Other respondents were of the opposite view, namely that redirection-only is not in itself an obstacle. These respondents argued that redirection is more secure than the embedded model, because it avoids the need to share the PSU’s credentials with TPPs and that, if properly designed, it can deliver a better customer experience than the embedded model. One respondent suggested that the GL should state

(d) The EBA considers that the references in Article 66(3)(b) of PSD2 and Article 30(2)(c) of the RTS to the sharing of credentials ‘by’ or ‘through’ a PISP or AISP cannot be interpreted as requiring that security credentials should always be transmitted ‘by’ or ‘through’ the PISP or the AISP and cannot, therefore, be read as prohibiting redirection. As clarified in the EBA Opinion, the EBA considers that the method of access, or the combination of methods, that the dedicated interface should support, will depend on the authentication procedures that the ASPSP offers to its own PSUs, taking into account the fact that the dedicated interface should support all the authentication methods provided by the ASPSP to its PSUs, and whether security credentials are transmittable (such as a PIN) or not (such as biometrics).

(e) The EBA agrees that the list in Article 32(3) of the RTS is not comprehensive but disagrees that this means that all examples provided in the article are absolute and constitute obstacles per se. As clarified in GL 5.2, a number of such obstacles are, indeed, in themselves obstacles, such as the check on consent.

(f) The EBA supports the development of innovation and has developed the RTS and these GL in high-level terms to ensure continuing innovation. As the market develops and enables payments at point of sale or payments via wearables, while complying with the requirements on SCA in the event that the transaction or information access does not benefit from an exemption to SCA, the industry, ASPSPs and TPPs may be required to evolve and adapt, regardless of whether redirection, embedded or decoupled is used for the purpose of carrying out the authentication. The EBA acknowledges that, in the case of redirection, part of the customer journey will be within the control of the ASPSP. However, as explained in the response

	that redirection-only access is not an obstacle, where all authentication procedures are supported.	to (a) above, the EBA is of the view that redirection is not, in itself, an obstacle. Furthermore, the EBA understands that a number of consumers and TPPs prefer the redirection model. European and UK consumer associations suggest that a number of consumers feel more secure and confident with redirection and TPPs favouring redirection are of the view that it simplifies the process for them, as they do not need to securely transport credentials. The EBA agrees that the customer experience is of primary importance and has, to that aim, provided further detail in the amended GL 5.1(b).
		(g) TPPs and customers may have different views and expectations and these views may differ depending on personal experience and the existing market within the EU. Therefore, ASPSPs may wish to consider whether or not it is beneficial to offer more than one method, above and beyond the legal requirement, to cater for the diversity of the markets and consumer expectations.
		(h) Please see the response under (a) above.
90.	GL 5.2(d) (new 5.1(b))	Several respondents suggested that how redirect solutions should look needs to be clarified in the GL, in order to avoid creating unnecessary delay or friction in the customer journey. Some respondents also suggested that CAs should develop a customer experience checklist, providing examples of the ways in which ASPSPs can avoid unnecessary delay and friction in the customer journey, similar to the Customer Experience Guidelines developed in the UK by the Open Banking Implementation Entity. One respondent suggested adding a reference to ‘unnecessary steps’ in GL 5.2(d) in line with rationale 35 of the CP. Another respondent was of the view that redirection to the ASPSP’s website or mobile app would be such	The EBA has amended GL 5.2(d) (new 5.1(b)) to include some examples of features that may create friction in the customer experience and therefore lead to obstacles. The EBA clarifies that this GL applies to all methods of access, not only to redirection. Regarding the last comment on redirection, please refer to the response to comment 89 above.	The EBA has amended GL 5.1(b) as follows: ‘b. where the ASPSP has put in place only one method of access, an explanation of the reasons why this the method(s) of access carrying out the authentication procedure(s) referred to in paragraph (a) is/are not an obstacle as referred to in Article 32(3) of the RTS and how this such method(s) of access supports allow(s) PISPs and AISPs to rely on all the authentication methods procedures provided by the ASPSP to its PSUs, together with evidence that the
	an ‘unnecessary step’, because it can be avoided by sharing the personalised security credentials (PSCs) with the TPPs.		dedicated interface does not give rise to unnecessary delay or friction in the experience available to the PSUs when accessing their account via a PISP, AISP or CBPII or to any other attributes, including unnecessary or superfluous steps or the use of unclear or discouraging language, that would directly or indirectly dissuade the PSUs from using the services of PISPs, AISPs and CBPIIs’.
91.	GL 5.2(d) (new 5.1(b))	Several respondents were of the view that the benchmark for determining whether the dedicated interface creates obstacles or not should be if a TPP is hindered from providing as good a service as it can do today based on screen scraping, and not if TPPs are hindered in the provision of their services. In the respondents’ view, the latter is too unambitious as a goal.	The EBA notes that in line with Article 33(2) of the RTS, the benchmark for assessing whether the dedicated interface creates obstacles or not is if the PISP or the AISP is hindered in ‘the provision of payment initiation and account information services’. The EBA disagrees that this means that the benchmark should be if TPPs are able to provide a similar service as they can do today based on screen scraping, as both ASPSPs and TPPs will need to adapt to the changes brought in by PSD2 and the RTS regarding access to payment accounts, including the payment account data to which TPPs will have access from 14 September 2019 onwards and the way in which they can access this data.	No change.
92.	GL 5.2(d) (new 5.1(b))	Some respondents suggested that ASPSPs should be required to submit evidence to the CA to prove compliance with GL 5.2(d) (new GL 5.1(b)), instead of providing only a self-attestation of compliance. Another respondent suggested that ASPSPs should be required only to demonstrate that they ‘have taken all reasonable steps’ to ensure that their interface does not create any obstacles, rather than ‘provide a confirmation’, as required in GL 5.2. The respondent argued that the fulfilment of GL 5.2(d) depends on the subjective assessment of a third party (i.e. the PSU), which an ASPSP cannot reasonably attest to.	The EBA acknowledges that the assessment of the customer experience implies a certain degree of subjectivity but also considers that, in order to allow CAs to make an assessment of whether or not the ASPSP complies with GL 5, the ASPSP should provide its CA with evidence in support of GL 5.2(d) (new 5.1(b)). This may consist of, for example, the results of customer testing, examples of customer experience journey when using an AISP or PISP (for instance using screenshots) or other types of evidence that CAs may choose to require in support of GL 5.1(b). This is reflected in the amended GL 5.1(b). The EBA also agrees that ‘a confirmation’ may not be best	The EBA has amended GL 5.2(d) (new 5.1(b)) as follows: ‘b. where the ASPSP has put in place only one method of access, an explanation of the reasons why this the method(s) of access carrying out the authentication procedure(s) referred to in paragraph (a) is/are not an obstacle as referred to in Article 32(3) of the RTS and how this such method(s) of access supports allow(s) PISPs and AISPs to rely on all the
			suited and has redrafted GL 5.2(d) (new 5.1(b)) to request ASPSPs to provide the CA with evidence to demonstrate compliance with the requirement in GL 5.1(b).	authentication methods procedures provided by the ASPSP to its PSUs, together with evidence that the dedicated interface does not give rise to unnecessary delay or friction in the experience available to the PSUs when accessing their account via a PISP, AISP or CBPII or to any other attributes, including unnecessary or superfluous steps or the use of unclear or discouraging language, that would directly or indirectly dissuade the PSUs from using the services of PISPs, AISPs and CBPIIs’.
93.	Paragraph 39 of the CP	One respondent requested clarification regarding the reference to ‘points of sale’ in paragraph 39 of the CP.	The EBA clarifies that the reference to ‘points of sale’ (PoS) in paragraph 39 of the CP was added in order to cover possible initiation of payments non-remotely via terminals/PoS, which allow the entering of the PSU’s security credentials, and that it was not intended to refer to traditional card payments (chip and PIN) at the PoS.	No change.
94.	General comments	Some respondents were of the view that the requirement in Article 10(2) of the RTS for a PSU to re-authenticate using SCA every 90 days in order to continue using AIS creates an obstacle to the provision of AIS. The respondent suggested that the EBA should review the RTS in order to remove this requirement.	The EBA considers that the interpretation of Article 10(2) of the RTS is outside the scope of these GL. For any clarification regarding the interpretation of this article, the EBA encourages the respondent to submit a question to the EBA via the EBA Q&A tool.	No change.
95.	General comments	One respondent suggested that the EBA should consider, in the context of the GL 5, potential obstacles, resulting from grey areas, regarding the interplay between PSD2 and General Data Protection Regulation (GDPR) and the interpretation of ‘sensitive payment data’. The respondent was of the view that ASPSPs may use GDPR as a pretext not to provide AISPs with the same payment account information made available to the PSU as required in Article 36	The EBA considers that the interpretation of the GDPR and its interaction with PSD2, and the interpretation of the concept of ‘sensitive payment data’ under PSD2 and the RTS, are outside the scope of these GL. For any clarification regarding the interpretation of PSD2 or the RTS, the EBA encourages the respondent to submit a question to the EBA via the EBA Q&A tool.	No change.

		(1)(a) of the RTS.
96.	General comments	One respondent was of the view that, in addition to the requirements in GL 5 on obstacles, it is important to ensure that no commercial obstacles are imposed on operations performed via the interface, such as unreasonably high or discriminatory pricing per transaction for a particular institution.	The EBA notes that PSD2 is clear that ASPSP cannot require a contract from PISPs or AISPs (see Articles 66(5) and 67(4) of PSD2), which means that they cannot charge PISPs or AISPs for access and information requests. Any such charges imposed on AISPs or PISPs for the purpose of the provision of information that ASPSPs are legally required to provide to AISPs and PISPs would represent an obstacle. ASPSPs sharing information or providing other services to AISPs and PISPs outside of the scope of the legal requirements can be contractually arranged between parties. Commercial pricing, resulting from agreements concluded between ASPSPs and TPPs, is, however, outside the scope of these GL.	No change.
97.	General comments	One respondent suggested adding the time needed for a TPP to retrieve information from the dedicated interface in GL 5, as an additional criterion for determining whether the interface creates obstacles. Another respondent was of the view that CAs should consider, as part of their assessment, if the dedicated interface creates obstacles to the provision of AIS or PIS and if the dedicated interface matches the PSU direct access channels, in terms of capabilities, availability, user experience and overall performance.	The EBA considers that the first suggestion is addressed in the new GL 5.1(b), which considers, from the customers’ perspective, if the dedicated interface gives rises to ‘unnecessary delay’ or friction in the customer experience when using the services of a PISP, AISP or CBPII. The EBA is of the view that the second comment is addressed in GL 2.1, as regards the comparison with the PSU interface in terms of availability and performance, and in the new GL 5.1(b), as regards the user experience.	No change. See, however, the changes made to GL 5.2(d) (new 5.1(b)), highlighted in the response to comment 90 above.
98.	General comments	One respondent was of the view that TPPs should be allowed to apply their own SCA and exemptions to SCA instead of the ASPSP, in order to achieve a level playing field and for TPPs to be able to create unique, differentiated customer experiences.	The EBA considers that the question of who can apply SCA and the exemptions to SCA is outside the scope of these GL. The EBA has clarified in the Opinion from 13 June 2018 that it is the ASPSP, as the PSP that issues the personalised security credentials, who is responsible for applying SCA and who ultimately decides whether or not to apply an exemption to SCA. The ASPSP may, however, choose to contract with other providers, such as PISPs and AISPs, so they can conduct SCA on the ASPSP’s behalf and determine the liability between them.	No change.

Feedback on responses to question 5

99.	GL 6.1 (new 6.4)	One respondent requested clarification of whether or not ASPSPs must publish only a summary of the documentation of the dedicated interface on their websites, which would be accessible to everyone, rather than the full documentation that can be made available only to TPPs ‘agreed or for which an agreement is pending’.	According to Article 30(3) of the RTS, ASPSPs are required to publish a summary of the technical specifications of the dedicated interface on their websites and to make the full documentation available, upon request from authorised PISPs, AISPs and CBPIIs, or PSPs that have applied to their CAs for the relevant authorisation. The EBA has refined the wording in GL 6.1 (new 6.4) in line with Article 30(3) of the RTS to clarify this.	The EBA has amended GL 6.1 (new 6.4) as follows: ‘For the purpose of the requirement in letter (b) of Article 33(6) of the RTS regarding the testing of the dedicated interface, the ASPSP should make the technical specifications of the dedicated interface available to authorised PISPs, AISPs and CBPIIs or payment service providers that have applied to their CAs for the relevant authorisation the technical specifications for of the dedicated interface, in accordance with Article 30(3) of the RTS including, at a minimum, the following: publishing a summary of the specification of the dedicated interface on its website in accordance with the third sub-paragraph of Article 30(3) of the RTS make available a testing facility for the dedicated interface in accordance with Article 30(5) of the RTS.’

100. GL 6.2 (new 6.5)	Several respondents argued that ASPSPs should grant access to the testing facilities only to authorised/registered TPPs that can produce a PSD2 compliant eIDAS certificate. The respondents argued that granting access to TPPs that are not authorised/registered entails security risks and compliance costs for both ASPSPs and TPPs, and also has an impact on the ASPSPs’ ability to innovate if ASPSPs must make any innovation they develop available to TPPs before market launch. Some respondents raised concerns that ASPSPs will not be able to differentiate genuine acknowledgements from CAs confirming that a TPP has applied for authorisation from fake ones.	The EBA notes that Article 30(5) of the RTS requires ASPSPs to grant access to the testing facility to authorised AISPs, PISPs and CBPIIs, as well as to ‘payment service providers that have applied for the relevant authorisation’. Therefore, these providers should be allowed access to the testing facility and may use test certificates for the purpose of the testing in accordance with Article 30(5) of the RTS, given that the eIDAS certificates under Article 34 of the RTS are available only to authorised TPPs. This has been clarified in the new GL 6.5. In addition, the EBA has clarified in GL 6.5 that testing should be carried out with non-real PSU data. See also the response to comment 101 below. The question concerning the genuine nature of a CA’s confirmation that a TPP has applied for authorisation or registration is outside the scope of these GL but may be something CAs wish to consider in the context of the application of the RTS.	The EBA has amended GL 6.2 (new 6.5) as follows: ‘The testing facility prior to live usage should allow ASPSPs, authorised PISPs, AISPs and CBPIIs or payment service providers that have applied to their CAs for the relevant authorisation to test the dedicated interface in a secure, dedicated testing environment with non-real PSU data, for the following: [...] b. the ability of ASPSPs and authorised PISPs, AISPs and CBPIIs to exchange the relevant certificates for electronic seals and qualified web authentication certificates, referred to in accordance with Article 34 of the RTS [...]’
101. GL 6.2 (new 6.5)	Several respondents requested clarifications of ASPSPs and TPPs should test with real customer data or if it is possible to use fake/mock data for the testing.	The EBA is of the view that the testing in accordance with Article 30(5) of the RTS, should be carried out with non-real PSU data and that real PSU data should be used only in the context of the production interface, which needs to be used by TPPs for providing services to their customers for at least 3 months before an ASPSP seeks an exemption. The EBA has therefore amended GL 6.5 in order to clarify that the testing in the context of Article 30(5) should be conducted with non-real PSU data.	The EBA has amended GL 6.2 (new 6.5) as follows: ‘The testing facility prior to live usage should allow ASPSPs, PISPs, AISPs and CBPIIs to test the dedicated interface, in a secure, dedicated testing environment with non-real PSU data, for the following: [...]’
102. GL 6.2 (new 6.5)	Several respondents suggested clarifying in the GL that the testing should focus on functionalities and connectivity for TPPs to test their own solutions, and not on performance, and that the PSPs’ ‘satisfaction’ should be evaluated accordingly. Several respondents also suggested clarifying in GL 6 that the testing should be carried out in a dedicated test environment, whose service levels differ from those of a production or ‘live’ environment. Some	The EBA notes that Article 30(5) of the RTS requires ASPSPs to provide a testing facility for ‘connection and functional testing’, to enable authorised AISPs, PISPs and CBPIIs, including AISPs and PISPs that are not yet authorised but are seeking authorisation, to undertake connection and functional testing of their software and applications used for offering a payment service to customers. This means that the purpose of the testing in Article 30(5) of the RTS is limited to connection and functional testing, to enable	The EBA has amended GL 6.2 (new 6.5) as follows: ‘The testing facility prior to live usage should allow ASPSPs, PISPs, AISPs and CBPIIs to test the dedicated interface in a secure, dedicated testing environment with non-real PSU data, for the following: a.a stable and secure connection;
respondents asked whether the testing facility should replicate the production environment with full functional scope or whether ASPSPs can simulate ‘live’ usage in a sandbox environment before launching their ‘production’ interface. Other respondents suggested that the EBA add the ability of TPPs to test all the functionalities that will be offered by the production interface in GL 6.2 (new 6.5) as a new element to be tested.	TPPs to test their software and applications before they launch their products to customers. This does not mean, however, that this is the only testing that ASPSPs need to conduct prior to launching the interface in a production environment. Indeed, ASPSPs will also need to conduct all normal testing for any interface, in particular security and penetration testing, as well as the periodical testing of the ASPSPs’ communication channels with TPPs in accordance with PSD2 and the RTS, but this is outside the scope of these GL. As a result, the EBA has come to the view that, for the purpose of evidencing compliance with the condition in letter (b) of Article 33(6) of the RTS as regards testing, the testing facility should allow ASPSPs and TPPs to test the elements specified in GL 6.5 in a dedicated testing environment.	b.the ability of ASPSPs and authorised PISPs, AISPs and CBPIIs to exchange the relevant certificates for electronic seals and qualified web authentication certificates, referred to in accordance with Article 34 of the RTS; c.the ability to send and receive error messages in accordance with Article 36(2) of the RTS; d.the ability for of PISPs to send, and of ASPSPs to receive, payment initiation orders and the ability of ASPSPs to provide all the information on the initiation of the payment transaction as required by requested in accordance with letter (b) of Article 66(4)(b) of PSD2 and letter (b) of Article 36(1)(b) of the RTS; e.the ability for of AISPs to send, and of ASPSPs to receive, data requests for access to and to send the requested data in relation to designated payment accounts data and associated payment transactions made available to the PSU as required by and the ability of ASPSPs to provide the information requested in accordance with letter (a) of Article 36(1)(b) of the RTS; and f. the ability for of CBPIIs and PISPs to send, and for of ASPSPs to receive, requests from CBPIIs and to send PISPs, and the requisite ability of the ASPSP to send a ‘yes/no’ confirmation as required by Article
				65(3) of PSD2 and by Article 36(1)(c) of the RTS to CBPIIs and PISPs. in accordance with letter (c) of Article 36(1) of the RTS; and g.the ability of PISPs and AISPs to rely on all the authentication procedures provided by the ASPSP to its PSUs’.
103.	GL 6.2 (new 6.5)	Some respondents suggested adding in GL 6.2 (new 6.5) the ability of TPPs to test that the dedicated interface supports all authentication procedures provided by the ASPSP to the PSU, in line with Article 30(2) of the RTS.	The EBA agrees with the respondent and has clarified in the new GL 6.5(g) that the testing facility should allow PISPs and AISPs to test their ability to rely on all the authentication procedures provided by the ASPSP to its PSUs, in line with Article 30(2) of the RTS. Where an ASPSP is developing its authentication processes to meet SCA requirements by 14 September 2019, the EBA acknowledges that this SCA functionality may not be fully ready for testing by March 2019. However, the testing facilities should enable AISPs and PISPs to test the planned SCA scenarios, so they can accommodate these in their software and applications.	The EBA has added a new paragraph (g) in GL 6.5: ‘the ability of PISPs and AISPs to rely on all the authentication procedures provided by the ASPSP to its PSUs’.
104.	GL 6.2 (new 6.5)	Some respondents suggested adding a number of additional items to be tested in GL 6.2 (new 6.5), such as the quality and completeness of the documentation; the time needed by TPPs to connect to the interface; the quality and level of the assistance provided, including the possibility of contacting the ASPSP anytime during business office hours; and the dedication of a team to fix bugs and other issues identified by TPPs.	The EBA is of the view that the completeness of the technical specifications needed for testing is covered in Article 30(3) of the RTS. Regarding the time needed by TPPs to connect to the interface, the EBA notes that GL 6.5 already covers the connection of TPPs to the interface, as well as the ability of TPPs to send requests through the dedicated interface and the ability of the ASPSP to respond to these requests and provide the data requested in accordance with Article 36 of the RTS. Therefore, the EBA considers that this is sufficiently covered in GL 6.5 and that any issues regarding the ability of TPPs to connect to the interface should be reported to the CA as part of the summary of the results of the testing in accordance with the amended GL 6.6. Finally, as regards the suggestion to test the quality and level of the assistance provided, the EBA notes that Article 30(5) RTS requires ASPSPs to provide support to TPPs in	No change. See, however, the changes made to GL 6.6, highlighted in the response to comment 113 below.
			their use of the testing facility for ‘connection and functional testing’. Consequently, the EBA considers that the requirement to offer support is directly applicable on the basis of the RTS. The EBA does not consider, however, that this is one of the elements that need to be tested as part of the ‘connection and functional testing’.
105.	GL 6.2(b) (new 6.5(b))	Several respondents requested clarification of whether it is the ASPSP or the TPP who decides what type of eIDAS certificate, i.e. a qualified certificate for electronic seal or a qualified certificate for website authentication to use for testing. Some respondents suggested that GL 6.2(b) (new 6.5(b)) should be amended to refer to ‘the ability to exchange qualified certificates for electronic seals or qualified web authentication certificates referred to in Article 34 of the RTS’. These respondents argued that if an ASPSP decides to support only one type of eIDAS certificate in the production environment, it should not be required to support both in the test environment.	The EBA notes that Article 34 of the RTS does not mandate which type of certificate (a qualified certificate for electronic seal or a qualified certificate for website authentication) should be used by TPPs for the purpose of identification and permits the use of both types of certificates. Article 34 of the RTS also does not specify whether it is the ASPSP or the TPPs who decide what type of certificate to be used for the purpose of identification of TPPs towards the ASPSP. The EBA is currently looking further into the question of which PSP should decide the type of eIDAS certificate to be used for the purpose of identification of TPPs under Article 34 of the RTS, and will provide clarity on this at a later stage. That being said, the EBA has amended GL 6.2(b) (new 6.5(b)) as shown in the column on the right hand side.	The EBA has amended GL 6.2(b) (new 6.5(b)) as follows: ‘b. the ability of ASPSPs and authorised PISPs, AISPs and CBPIIs to exchange the relevant certificates for electronic seals and qualified web authentication certificates, referred to in accordance with Article 34 of the RTS [...]’.

106. GL 6.2(b) (new 6.5(b))	Some respondents raised concerns that the eIDAS certificates referred to in Article 34 of the RTS may not be available in time for the start of the testing phase. The respondents suggested that, in such a scenario, ASPSPs should be allowed to work with an alternative identification method to test the identification of TPPs. Another respondent stressed that it is important for the processes between CAs and Qualified Trust Service Providers under the European Telecommunications Standards Institute (ETSI) specification to be clarified as soon as possible.	The EBA is of the view that for the purpose of the testing in Article 30(5) of the RTS, the testing facility should allow the testing of the ability of authorised AISPs, PISPs and CBPIIs to exchange eIDAS certificates as referred to in Article 34 of the RTS. AISPs, PISPs and CBPIIs that are not yet authorised but are seeking authorisation may identify themselves for the purpose of testing using test certificates, taking into account that the RTS requires ASPSPs to also grant these providers access to the testing facility. The EBA does not have any indication that eIDAS certificates will not be available in time for testing. The interaction between CAs and Qualified Trust Service Providers is outside the scope of these GL.	See the changes made to GL 6.2 (new 6.5), highlighted in the response to comment 100 above.
107. GL 6.2(b) (new 6.5(b))	One respondent asked how an ASPSP should identify a credit institution, where the credit institution acts as a TPP but is not on the FCA register.	From the date of application of the RTS (i.e. 14 September 2019), ASPSPs should rely on eIDAS certificates, as referred to in Article 34 of the RTS, to identify PISPs, AISPs and CBPIIs. This includes credit institutions acting in their capacity as TPPs. Before 14 September 2019, ASPSPs can verify the authorisation status of credit institutions using the national public registers for credit institutions and the EBA Credit Institutions Register, accessible at: https://www.eba.europa.eu/risk-analysis-and-data/credit-institutions-register.	No change.

108. GL 6.2(b) (new 6.5(b))	One respondent asked whether the purpose of exchanging eIDAS certificates in accordance with GL 6.2(b) is a technical testing requirement or connected to an on-boarding process, or both. The respondent mentioned that, if these certificates are test certificates, the ability to verify the true identity behind the certificate may be complicated.	The exchange of eIDAS certificates under GL 6.2(b) (new 6.5(b)) is intended primarily for testing that the exchange is technically possible via the dedicated interface, but also serves an identification purpose. For the purpose of identification during testing, ASPSPs may, in addition to the use of eIDAS certificates, rely on the national public registers for credit institutions, the national public registers under Article 14 of PSD2, as well as the EBA Credit Institutions Register and the EBA Register under Article 15 of PSD2.	No change.
109. GL 6.2(c) (new 6.5(c))	One respondent suggested that the EBA specify the minimum set of error messages that a service should provide for in the GL.	See the response to comment 67 above.	No change.
110. GL 6.2(f) (new 6.5(f))	In relation to GL 6.2(f) (regarding the provision of a yes/no response to a PISP), several respondents requested clarification of whether or not: - the consent under Article 65 of PSD2 is required in order to provide a yes/no answer to a PISP; - a PISP must have permission for issuing payment instruments to request a confirmation of availability of funds; - ASPSPs must provide the yes/no answer only after receipt of a payment order from the PISP; and - an ASPSP should provide a ‘yes’ response to a CBPII/PISP in the instance where it decides to process a payment initiated directly by a PSU using an unarranged overdraft. Some respondents stressed that, when an ASPSP cannot provide a PISP with confirmation of funds via a ‘yes/no’ answer, the additional information to be provided by ASPSPs to the PISP should be limited only to what is needed for the execution of the payment.	The EBA notes that, in accordance with Article 36(1)(c) of the RTS, ASPSPs should provide, upon request, a confirmation, in a simple ‘yes or no’ format, of whether the amount necessary for the execution of a payment transaction is available on the payer’s account or not. The EBA has clarified in the EBA Opinion that this requirement applies both to CBPIIs and PISPs, and not only to CBPIIs. This does not mean that the consent in Article 65 of PSD2 is required in order to provide a yes/no answer to a PISP, or that a PISP must have permission for issuing payment instruments to request this confirmation. As explained in the response to comment 82 above, PISPs should ensure that they have obtained the customer explicit consent in accordance with Article 66(2) of PSD2. For any further clarifications regarding the data that ASPSPs must provide to PISPs in accordance with the RTS, the EBA encourages the respondent to submit a question to the EBA via the EBA Q&A tool, given that this is outside the scope of these GL.	No change.
111. GL 6.2(f) (new 6.5(f))	One respondent suggested extending GL 6.2(f) so it also covers the ASPSP’s ability to receive requests from PISPs.	The EBA agrees with the suggestion made by the respondent and has amended GL 6.2(f) (new 6.5(f)) to reflect that the testing should also cover the ASPSP’s ability	The EBA has amended GL 6.2(f) (new 6.5(f)) as follows:
			to receive requests from PISPs.	‘f. the ability for of CBPIIs and PISPs to send, and for of ASPSPs to receive, requests from CBPIIs and to send PISPs, and the requisite ability of the ASPSP to send a ‘yes/no’ confirmation as required by Article 65(3) of PSD2 and by Article 36(1)(c) of the RTS to CBPIIs and PISPs. in accordance with letter (c) of Article 36(1) of the RTS [...]’.
112. GL 6.2 (new 6.5)		Several respondents suggested that the EBA should encourage TPPs to participate in the testing phase, so as to ensure that everything runs smoothly in the production environment.	The EBA considers that TPPs participation in testing is extremely important and encourages TPPs to participate in the testing and to provide feedback to the ASPSPs on any issues they may encounter during testing, so the ASPSP can address such issues and develop a high performing dedicated interface. The EBA also notes that Article 30(5) refers to testing connection and functionalities and is aimed at TPPs, as mentioned in the response to comment 102 above.	No change.
113. GL 6.3 (new 6.6)		A number of respondents requested clarification about the contents of the summary of the results of the testing in GL 6.3 (new 6.6). Some respondents suggested that it should also cover the feedback received by the ASPSP from TPPs during testing. One respondent was of the view that it is important to consider that there is no obligation for TPPs to disclose their results of the testing. Some respondents also suggested that the summary should explain ‘how the weaknesses identified during the usage of the sandbox period have been solved’.	The EBA has amended GL 6.3 (new 6.6) in order to clarify that the summary of the results should include the results of the testing for each of the elements in letters (a) to (g) of GL 6.5, together with the feedback received by the ASPSP from TPPs during testing, the issues identified and how the ASPSP has addressed them. The EBA acknowledges that there is no obligation for TPPs to provide feedback to the ASPSPs, but it encourages TPPs to participate in the testing and to provide feedback to the ASPSP on any issues encountered during the testing, so the ASPSP can address them. See also comment 112 above. As regards the last suggestion, the EBA notes that, in line with the amended GL 6.6, the summary of the results should include an explanation of how the issues identified during testing have been resolved. The EBA does not consider that any further amendments are needed.	The EBA has amended GL 6.3 (new 6.6) as follows: ‘The ASPSP should provide to the competent authority with a summary of the results of the testing for the referred to in Article 30(5) of the RTS for each of the elements to be tested in accordance with letters (a) to (g) of paragraph 6.5 above, including the number of PISPs, AISPs and CBPIIs that have used the testing facility, the feedback received by the ASPSP from these PISPs, AISPs and CBPIIs, the identification of weaknesses issues identified and a description of how these weaknesses issues have been addressed’.

114. GL 6.3 (new 6.6)	Some respondents suggested that TPPs should have the option of sending their conclusions on the results of the testing directly to the CA, instead of the ASPSP, and that the GL should provide guidance to CAs on how to consider the feedback received directly from TPPs as part of the exemption process. Some respondents also suggested that CAs should seek to review evidence of the ASPSP’s willingness to consider the feedback received from TPPs and to address TPPs’ concerns.	The EBA has clarified in the amended GL 6.3 (new 6.6) that ASPSPs should convey to the CA, as part of the results of the testing, the feedback received from TPPs that have participated in the testing, together with an explanation of how the ASPSP has addressed any issues identified in the testing. Moreover, the EBA has amended GL 8 and has clarified that ASPSPs are required to provide the CA with an explanation of the problems reported by TPPs regarding their production interface that have not been resolved by the ASPSP in accordance with the service level targets under GL 2.1. Furthermore, the EBA has added a new GL 6.7 which provides that CAs may also take into account, when assessing the ASPSP’s compliance with the design condition in Article 33(6)(b) of the RTS, any problems reported by TPPs to the CA in relation to the elements to be tested in accordance with GL 6.5. As explained in the response to comment 50 above, while TPPs can always come to the CAs directly, the EBA strongly encourages TPPs to communicate any issues they experience with the test or production interfaces to the ASPSP, as a first port of call, so as to allow the ASPSP to address those issues in a timely manner. See also the response to comment 50 above.	The EBA has amended GL 6.3 (new 6.6) as follows: ‘The ASPSP should provide to the competent authority with a summary of the results of the testing for the referred to in Article 30(5) of the RTS for each of the elements to be tested in accordance with letters (a) to (g) of paragraph 6.5 above, including the number of PISPs, AISPs and CBPIIs that have used the testing facility, the feedback received by the ASPSP from these PISPs, AISPs and CBPIIs, the identification of weaknesses issues identified and a description of how these weaknesses issues have been addressed’. Also, the EBA has added a new GL 6.7 as follows: ‘6.7 For the purpose of assessing whether the ASPSP meets the requirements in letter (b) of Article 33(6) of the RTS, the competent authority may also take into account any problems reported to it by PISPs, AISPs and CBPIIs in relation to Guideline 6.5 above’.
115. GL 6.4 and 6.5 (new 6.1 – 6.3)	Several respondents suggested that the EBA should encourage market participants to make use of market initiative standards, but, at the same time, clarify that the fact that an ASPSP follows such standards is not sufficient to prove that its interface meets the ‘design’ condition in Article 33(6)(b) of the RTS and that it does not ‘guarantee’ that the ASPSP will obtain an exemption. The respondents were of the view that the standards developed by API initiatives, such as Berlin Group or	The EBA is aware that a number of market initiatives are developing standardised specifications for application programming interfaces (APIs). Some of these initiatives are developing conformance testing tools aimed at helping ASPSPs to test that their implementation of dedicated interfaces based on these standards complies with these standards. The EBA also understands that other initiatives more akin to implementation hubs are also developing a number of implementation tools, including conformance types of tools.	6.4 Where an ASPSP is implementing a market initiative standard, it should provide the competent authority with information as to: a. which standard the ASPSP is implementing; and b. whether, and if so how and why, it has deviated from any standard implementation requirements of the initiative, if available.
	STET, leave significant room for interpretation and that ASPSPs will only rarely adopt the entire standards developed by the API initiatives. Therefore, these respondents argued that ASPSPs that claim compliance with a market initiative standard should demonstrate such compliance. Respondents were also of the view that conformance testing tools, developed by market initiatives, could be a helpful and pragmatic way to achieve this. One respondent also suggested that the EBA should guide CAs to ‘pre-approve’ market initiative certification plans and reports, so as to allow ASPSPs to simply submit a standard-compliant certification report, encompassing the deviations from the standard and the results of the testing covering the elements.	The EBA considers that such standardisation initiatives, based on industry collaboration and in accordance with the requirements in PSD2 and the RTS, have the potential to facilitate market entry, avoid fragmentation and foster competition and innovation, thus supporting the achievement of the objectives of PSD2. The EBA also considers that the results of conformance testing may assist ASPSPs when evidencing to the CA that they meet the requirements for exemption, on the basis that the standards aim to be designed in accordance with PSD2 and the RTS. That being said, the EBA agrees that following an API market initiative standard does not guarantee an exemption and notes that, by their very nature, industry standards leave significant room for interpretation by ASPSPs, given that the implementation of an API as part of the ASPSP’s system will include many more elements than those specified in the standards. This means, therefore, that, as stated above, any conformance or compliance types of tools can only be indicative to the CA as a useful piece of evidence and never be a guarantee. As a result, the EBA has made a number of amendments to GL 6.4 and 6.5 (new GL 6.1 to 6.3) to reflect the above, as shown in the column on the right. With regard to the last comment on pre-approving the market initiative certification plans, the EBA notes that this is not within its remit, as the EBA does not supervise such initiatives. The EBA also notes that, while CAs may wish to engage with initiatives, by providing some expertise on legal requirements, CAs cannot pre-approve, endorse or ‘vet’ any such initiatives.	6.5 Where an ASPSP is not implementing a market initiative standard, it should provide the competent authority with a description as to the form of engagement that has taken place with PISPs, AISPs and CBPIIs for implementing the dedicated interface. 6.1 For the purposes of evidencing compliance with the requirement in letter (b) of Article 33(6) of the RTS regarding the design of the dedicated interface, the ASPSP should provide the competent authority with: a. evidence that the dedicated interface meets the legal requirements for access and data in PSD2 and the RTS, including: i. a description of the functional
and technical specifications that the ASPSP has implemented; and ii. a summary of how the implementation of these specifications fulfils the requirements in PSD2 and the RTS; and b. information on whether, and if so how, the ASPSP has engaged with PISPs, AISPs and CBPIIs. 6.2 For the purpose of these Guidelines, a ‘market initiative’ means a group of stakeholders that have developed functional and technical specifications for dedicated interfaces
				and, in doing so, have obtained input from PISPs, AISPs and CBPIIs. 6.3 Where the ASPSP is implementing a standard developed by a market initiative: a. the information referred to in point (i) of letter (a) of Guideline 6.1 may consist of information regarding which market initiative standard the ASPSP is implementing, whether or not it has deviated in any specific aspect from such standard and, if so, how it has deviated and how it meets the requirements in PSD2 and the RTS; b. the information referred to in point (ii) of letter (a) of Guideline 6.1 may include, where available, the results of the conformance testing developed by the market initiative, attesting compliance of the interface with the respective market initiative standard.
116. GL 6.4 and 6.5 (new 6.1 - 6.3)	Some respondents were of the view that in order for the dedicated interface to satisfy the ‘design’ condition in Article 33(6)(c) of the RTS, it should allow the exchange of data on the PSU’s identity, such as address, date of birth and social security number. These respondents stressed that the sharing of information on the PSU’s identity is essential for TPPs to avoid fraudulent behaviour.	As clarified in the EBA Opinion, the EBA is of the opinion that the data that ASPSPs are required to share with TPPs, in accordance with PSD2 and the RTS, do not include data on the identity of the PSU, such as address, date of birth and social security number. On the question of whether or not ASPSPs are required to share with ASPSPs the name of the PSU, the EBA will provide clarity on this point via the EBA Q&A tool.	No change.

117. GL 6.4 and 6.5 (new 6.1 – 6.3)	Several respondents suggested clarifying what is meant by a ‘market initiative’ in GL 6.4 and 6.5.	The EBA has clarified in the new GL 6.2 that, for the purpose of GL 6, a ‘market initiative’ refers to a group of stakeholders that have developed functional and technical specifications for dedicated interfaces, and have obtained input from TPPs in the development of such standards.	The EBA has introduced a new GL 6.2 which reads as follows: ‘For the purpose of these Guidelines, a ‘market initiative’ means a group of stakeholders that have developed functional and technical specifications for dedicated interfaces and, in doing so, have obtained input from PISPs, AISPs and CBPIIs’.
118. GL 6.5 (new 6.1 (b))	One respondent requested clarifications on what the engagement with TPPs in GL 6.5 involves, and suggested using the same wording as in rationale 59 of the CP. In addition, one respondent was of the view that this requirement should apply to all ASPSPs, irrespective of whether they follow an API market initiative or not.	The EBA is of the view that engaging with TPPs includes steps that an ASPSP has taken in order to obtain input from TPPs on the design of its dedicated interface. Evidence of such involvement may include designing the interface on the basis of a market initiative standard for which TPPs’ input has been sought during the development of the standards, publicising the availability of both the ASPSP’s testing facility and its production interface, and encouraging testing by TPPs and the use of the ASPSP’s dedicated interface. The EBA agrees with the second respondent that this requirement should apply to all ASPSPs and has therefore extended the requirement in GL 6.5 (new 6.1(b)) to apply to all ASPSPs, irrespective of whether they follow a market initiative or not.	The EBA has amended GL 6.5 and has clarified in the new GL 6.1(b) that: 6.5 Where an ASPSP is not implementing a market initiative standard, it should provide the competent authority with a description as to the form of engagement that has taken place with PISPs, AISPs and CBPIIs for implementing the dedicated interface New GL 6.1(b) ‘For the purpose of evidencing compliance with the requirement in letter (b) of Article 33(6) of the RTS regarding the design of the dedicated interface, the ASPSP should provide the competent authority with: [...] b. information on whether, and if so how, the ASPSP has engaged with PISPs, AISPs and CBPIIs’.

119. General comments	Some respondents were of the view that ASPSPs should provide appropriate notice to TPPs of any changes that they decide to make to the dedicated interface, as part of the testing phase. One respondent was of the view that Article 30(4) of the RTS applies during the testing phase and that, as a result, the ASPSP should notify TPPs 3 months in advance of any changes it makes to the dedicated interface during the testing period, otherwise no exemption can be granted.	The EBA considers that the requirement in Article 30(4) of the RTS, regarding the obligation to make available changes to the technical specifications of the interface no later than 3 months before the changes are implemented, applies to the production interface only and is not a requirement per se during the testing phase. Nevertheless, an implicit requirement of a test-only interface is that it must allow PISPs, AISPs and CBPIIs to test their software and applications used for offering a payment service to users. As a consequence, while changes to the technical specifications of a test-only interface do not need to be made available before they are implemented, any change that would affect the capability of PISPs, AISPs and CBPIs to test their software and applications would determine a breach of the provision in Article 30(5). Therefore, the EBA arrived at the view that changes to the technical specifications of the test-only interface do not have to be made available by ASPSPs 3 months before they are implemented. Where significant changes are made, the EBA is of the view that ASPSPs should make these changes available as soon as possible before they are implemented, to allow TPPs to test against the updated specifications, in the context of compliance with Article 30(5).	No change.
120. General comments	One respondent requested clarification on when changes made by an ASPSP to the dedicated interface constitute a ‘re-launch’, triggering a new 6-month testing period and the need to apply for a (new) exemption.	The EBA is of the view that this can be assessed only on a case-by-case basis, depending on the materiality of the changes made. Regarding the testing period, see also the response to comment 136 below.	No change.

121. General comments	One respondent was of the view that consumer representatives should be involved in the design and testing of the ASPSPs’ dedicated interfaces.	The EBA is of the view that input from consumer representatives could be helpful in the design and testing of the dedicated interface, in particular in the assessment of whether the interface creates obstacles from the perspective of the customer experience under the amended GL 5.1(b). See also the response to comment 92 above. However, the EBA is not of the view that this should be mandated.	No change. See, however, the changes made to GL 5.2(d) (new 5.1(b)), highlighted in the response to comment 92 above.
122. General comments	One respondent asked if GL 6 also applies when the ASPSP does not apply for an exemption to the fall back mechanism.	The GL apply only to ASPSPs that apply for an exemption to the fall back mechanism.	No change.
123. General comments	One respondent was of the view that it is important to allow ASPSPs to use an IT-group service centre, or one common technical service provider, to fulfil the design and testing requirements on behalf of multiple ASPSPs.	The EBA considers that the GL do not restrict such a possibility. However, the EBA notes that, in such a case, the results of the testing should be specific to each ASPSP that applies for an exemption. In other words, the testing should be conducted against the dedicated interface, as implemented in the back-end system of each ASPSP, rather than the common software that the IT-group service centre may be providing to many ASPSPs.	No change.
Feedback on responses to question 6
124. GL 7.1	Several respondents requested clarification of what ‘widely used’ entails. More specifically, respondents asked if the fulfilment of this condition will depend on the ratio between the number of TPPs that have signed up and the number of TPPs that are actually using the production interface; if the duration of the ‘live’ testing is a relevant indicator; and if the condition can still be met if there are no CBPII results available. Other respondents agreed with the approach taken in GL 7.1 and were of the view that, because the markets are so diverse across Member States, it would be difficult to prescribe what level of use or number of TPPs having used the interface would be	The EBA acknowledges that the assessment of whether or not an ASPSP meets the requirement in Article 33(6)(c) of the RTS on ‘wide usage’ will be challenging for CAs, particularly in the run up to 14 September 2019. This is for a number of reasons, including that, in some Member States, there are, to date, few or no authorised PISPs, AISPs or CBPIIs available to use the dedicated interfaces developed by ASPSPs. Furthermore, there is no obligation on PISPs, AISPs or CBPIIs to use the dedicated interface of an ASPSP in the run up to 14 September 2019. As a result, TPPs may choose not to do so, for various reasons, until the RTS apply, for example, some TPPs may prefer to continue screen scraping until then. Others, however, may simply not have the necessary resources to test with	The EBA has amended GL 7.1 and 7.2 as follows: ‘The For the purposes of evidencing compliance with the requirement in letter (c) of Article 33(6) of the RTS, the ASPSP should provide to the competent authority with: a. a summary description as to the availability of the technical specification and testing facility to the market and should have taken all necessary steps for the of the usage of the dedicated interface for the period referred to in letter (c) of
	deemed acceptable to prove ‘wide usage’.	multiple ASPSPs at the same time and may therefore need to select which dedicated interfaces to test and subsequently use for offering services to their customers, without this necessarily being reflective of the quality of the dedicated interfaces not being selected. As a result, the EBA considers that it is not feasible to set a one-size-fits-all numerical threshold for ‘wide usage’, by imposing a ratio, for example, as suggested by several respondents. Instead, CAs should take into account a broader range of factors when assessing this condition, including: - the usage of the dedicated interface during the period referred to in Article 33(6)(c) RTS, and in particular the number of TPPs that have used it for providing services to their customers and the number of successful requests sent by TPPs to the ASPSP via the dedicated interface during that period; - the number of TPPs in the respective jurisdiction available to use the ASPSP’s dedicated interface; - the steps that the ASPSP has taken to achieve ‘wide usage’; and - if there are any large discrepancies between the number of the TPPs that have participated in the testing and those that have used the ASPSP’s dedicated interface to offer services to their customers. To support the assessment of the condition on ‘wide usage’ by CAs, the EBA considers that ASPSPs should submit to the CA information regarding the number of TPPs that have used the interface to offer services to their customers during the minimum 3-months period referred to in Article 33(6)(c) of the RTS and the number of successful requests sent by those TPPs to the ASPSP via the dedicated interface during that period, together with evidence that the ASPSP has taken all reasonable efforts to achieve ‘wide usage’, including by communicating its availability and encouraging its use by TPPs.	Article 33(6) to be operationally used. The information should include, but is not limited to including but not limited to: (i) the number of PISPs, CBPIIs, AISPs and PSPs CBPIIs that have applied for the relevant authorisation that have made use of the testing facility; and AISPs, PISPs, AISPs and CBPIIs using used the interface to provide services to customers; and (ii) the number of requests sent by those PISPs, AISPs and CBPIIs to the ASPSP via the dedicated interface that have been replied to by the ASPSP; and b. if evidence that the ASPSP is not able to evidence fulfilment with the condition of ‘widely used’ as set out in Guideline 7.1, the ASPSP should provide evidence to the competent authority that it has made the all reasonable efforts to ensure wide usage of the dedicated interface public and available for ‘wide usage’, including by communicating the its availability of the testing facilities via appropriate channels, including, where appropriate relevant, the website of the ASPSP, social media, industry trade bodies, conferences and direct engagement with known market actors’. GL 7.2
‘In addition to the evidence referred to in Guideline 7.1, the competent
			In addition, the EBA is of the view that CAs should also consider, when assessing whether the ASPSP meets the ‘wide usage’ condition, the other evidence submitted in the context of GL 6 and 8, including the results of the testing and how the ASPSP has addressed any issues reported by TPPs. That being said, the EBA agrees that the draft GL 7.1 and 7.2 were perhaps not clear enough, and has therefore amended GL 7.1 and 7.2 in line with the above.	authority should take into account the information received in the context of Guidelines 6 and 8 when assessing whether or not the ASPSP meets the requirement in Article 33(6)(c) of the RTS’.
125. GL 7.1	One respondent was of the view that, when assessing the ‘widely used’ condition, CAs should take into account whether or not the interface has been designed to accommodate a wide range of uses and a variety of TPPs connecting to it. The respondent suggested that ASPSPs, instead of accommodating a large number of firms to test, should select a small number of engaged partners for the testing phase (around five to seven testing partners).	The EBA is of the view that the ability of the dedicated interface to support the provision of AIS, PIS and CBPII services should be assessed primarily as part of the ‘design’ condition under GL 6 and that the fact that the interface has been designed to support a wide range of services is not sufficient to satisfy the condition on ‘wide usage’. As explained in more detail in the response to comment 124 above, the EBA considers that, for the assessment of the condition on ‘wide usage’, CAs should take into account a broader range of elements, including but not limited to, the number of TPPs that have used the interface and the number of successful requests sent by those TPPs to the ASPSP via the dedicated interface during the period referred to in Article 33(6)(c) RTS.	No change.
126. GL 7.1	One respondent suggested expanding GL 7.1 to require ASPSPs to identify the total number of TPPs that have received access to the full interface documentation. The respondent was of the view that CAs should consider any significant discrepancies in the number of TPPs that have received access to the interface specifications versus the number of TPPs that have used the production interface. The respondent also suggested that the CA should take into account, in the context of the ‘wide usage’ in GL 7.1, the feedback provided by TPPs that have received access to the technical specifications of the	As explained in more detail in the response to comment 124 above, the EBA considers that, in the context of GL 7.1, CAs should consider, among other elements, if there are any significant discrepancies between the number of TPPs that have participated in the testing and those that have used the ASPSP’s production interface for at least 3 months in order to offer services to their customers. The EBA considers that a comparison with the number of TPPs that have participated in the testing, as opposed to those that have only requested access to the full documentation, is more representative, given that TPPs may request access to the technical specifications of several interfaces and	No change. See, however, the changes made to GL 7.1 and 7.2, highlighted in the response to the comment 124 above and the changes to GL 6.6 highlighted in the response to comment 113 above.
		interface.	decide, thereafter, which one(s) they will test. As regards the second comment, the EBA agrees that CAs should also consider, for the purpose of assessing the ‘wide usage’ condition, the results of the testing submitted in the context of the amended GL 6.6, including the feedback received from TPPs that have participated in the testing. This has been reflected in the amended GL 7.2.
127. GL 7.1		One respondent suggested clarifying in GL 7.1 that banks acting in their capacity as AISPs, PISPs or CBPIIs should also be included in the assessment of the ‘widely used’ condition, in line with rationale 57 of the CP. Another respondent was of the opposite view and argued that banks should not be included in the ‘widely used’ concept, because they would be both ‘judge and jury’ and have competing interests with TPPs.	The EBA notes that the condition in Article 33(6)(c) of the RTS is that the dedicated interface ‘has been widely used for at least 3 months by payment service providers to offer account information services, payment initiation services and to provide confirmation on the availability of funds for card-based payments’. Therefore, the EBA is of the opinion that all PSPs that offer AIS, PIS or provide confirmation on the availability of funds for card-based payments should be included in the assessment of the ‘wide usage’ condition. This includes credit institutions that are using the dedicated interfaces of other ASPSPs in their capacity as AISPs, PISPs or CBPIIs to provide services to their customers.	No change.

128. GL 7.1	One respondent noted that there is some missing text in the wording of GL 7.1(a).	The EBA acknowledges that the initial drafting of GL 7.1(a) included a clerical error, but it has now rectified this error.. The EBA has also clarified that ASPSPs should provide their CA, in the context of GL 7.1, with information regarding the number of TPPs that have used the dedicated interface for at least 3 months in order to provide services to their customers. The EBA notes that the information regarding the number of TPPs that have participated in the testing, including those that are not yet authorised but are seeking authorisation, is now covered in the amended GL 6.6 regarding testing.	The EBA has amended GL 7.1(a) as follows: ‘The For the purposes of evidencing compliance with the requirement in letter (c) of Article 33(6) of the RTS, the ASPSP should provide to the competent authority with: a. a summary description as to the availability of the technical specification and testing facility to the market and should have taken all necessary steps for the of the usage of the dedicated interface for the period referred to in letter (c) of Article 33(6) to be operationally used. The information should include, but is not limited to including but not limited to: (i) the number of PISPs, CBPIIs, AISPs and PSPs CBPIIs that have applied for the relevant authorisation that have made use of the testing facility; and AISPs, PISPs, AISPs and CBPIIs using used the interface to provide services to customers; and (ii) the number of requests sent by those PISPs, AISPs and CBPIIs to the ASPSP via the dedicated interface that have been replied to by the ASPSP [...]’.
129. GL 7.1	One respondent requested clarification of when, and how often, ASPSPs should provide the data in GL 7.1 to their CA, taking into account the fact that the number of requests issued by TPP will increase.	The EBA is of the view that ASPSPs should submit the evidence required in the context of GL 7 to their CA, as part of the exemption application process, after the 3-month period referred to in letter (c) of Article 33(6) of the RTS.	No change.

130. GL 7.1 and 7.2	One respondent was of the view that GL 7 diminishes the role afforded to TPPs to comment on their satisfaction in the design and testing of a dedicated interface and that TPPs should be allowed to communicate their concerns on issues that may have impeded their ability to use the testing facility.	The EBA considers that TPPs will have the opportunity, as part of the testing, to provide feedback to the ASPSP regarding any issues encountered during the testing, including any problems that may have impeded their ability to test. The amended GL 6.6 requires ASPSPs to convey to the CA, as part of the results of the testing, the feedback they received from TPPs that have participated in the testing and how the ASPSP has addressed the issues identified during the testing. In addition and as detailed in the response to comment 139 below, GL 8 requires ASPSPs to submit to the CA an explanation of the problems reported by TPPs during the period referred to in Article 33(6)(c) that have not been resolved in accordance with the service level targets set out in Guideline 2.1. In addition, the EBA has clarified in GL 7.2 that the CA should also consider, in the assessment of the condition on ‘wide usage’ in accordance with GL 7.1, the evidence submitted in the context of GL 6 and 8, including the feedback from TPPs that have participated in the testing submitted in accordance with the amended GL 6.6. Furthermore, and as explained in the response to comments 50 and 114 above, the EBA has added a new GL 6.7 which provides that CAs may also take into account, when assessing the ASPSP’s compliance with the design condition in Article 33(6)(b) of the RTS, any problems reported by TPPs to the CA in relation to the elements to be tested in accordance with GL 6.5.	The EBA has added a new GL 6.7 as follows: ‘6.7 For the purpose of assessing whether the ASPSP meets the requirements in letter (b) of Article 33(6) of the RTS, the competent authority may also take into account any problems reported to it by PISPs, AISPs and CBPIIs in relation to Guideline 6.5 above’. See also the changes made to GL 7.1 and 7.2, highlighted in the response to comment 124 above, and the changes made to GL 6.6, highlighted in the response to comment 113 above.
131. GL 7.2 (new GL 7.1 and 7.2)	Several respondents disagreed with the approach taken in GL 7.2 and were of the view that GL 7.2 is not compliant with the RTS, because it dilutes the condition on ‘wide usage’ in Article 33(6)(c) of the RTS. One respondent added that, if the dedicated interface is not being used particularly where there is a lot of marketing available, this would be an indicator that it is not functioning well. These respondents argued that, if the interface is not ‘widely used’, then ASPSPs should not be able to	The EBA considers that, while the number of TPPs that have used the dedicated interface is certainly an important factor to consider, it is not necessarily reflective, in all cases, of the quality of the interface and that other elements should be considered in the assessment, as explained in the response to comment 124 above. That being said, the EBA acknowledges that the initial wording of GL 7.2 may not have been clear, and has amended GL 7.1 and 7.2, as explained in more detail in the	See the changes made to GL 7.1 and 7.2, highlighted in the response to comment 124 above.
	obtain an exemption. Other respondents were of the opposite view and agreed with the approach in GL 7.2. Some respondents emphasized that, because AISPs, PISPs or CBPIIs are not obliged to undertake testing, it could be difficult for ASPSPs to meet any numeric thresholds in GL 7.1. Many respondents requested clarification regarding the type of evidence required in order to satisfy the condition in GL 7.2.	response to comment 124 above.
132. GL 7.2 (new GL 7.1(b))	Several respondents requested clarification of whether an ASPSP is required to provide evidence that it has used all the communication channels listed in GL 7.2 (new GL 7.1(b)) or whether the examples listed are only indicative, and, therefore, the ASPSP is free to choose whichever channel(s) it considers appropriate. Some respondents were of the view that it would be sufficient for an ASPSP to communicate the availability of its dedicated interface on its website, and that the choice of whether or not to use other channels (e.g. social media) should be left to the ASPSP, depending on its usual policy. These respondents argued that PSD2 and the RTS do not require ASPSPs to actively publicise the availability of their interfaces. One respondent was of the view that, where a central website is available, such as the Open Banking website in the UK, it would suffice for ASPSPs to display the availability of their testing facilities on such a website.	The EBA notes that, in accordance with GL 7.2 (new GL 7.1(b)), the ASPSP should prove that it has made all reasonable efforts to achieve ‘wide usage’ of the dedicated interface, ‘including communicating its availability via appropriate channels, including, where relevant, the website of the ASPSP, social media, industry trade bodies, conferences and direct engagement with known market actors’. Therefore, the channels listed in GL 7.1(b) are indicative and the ASPSP may choose whichever channel(s) it considers appropriate. However, given that the ASPSP needs to demonstrate that it has made ‘all reasonable efforts’ to achieve ‘wide usage’, the ASPSP should evidence that the channels used enabled it to communicate the availability of its dedicated interface to a wide number of TPPs.	See the changes made to GL 7.1(b), highlighted in the response to comment 124 above.

133. GL 7.2	One respondent requested clarification of whether or not ASPSPs are expected to publicly communicate the availability of the testing facility, as set out in GL 7.2, regardless of whether or not the requirement under GL 7.1 is fulfilled.	The EBA notes that this requirement applies to all ASPSPs that apply for an exemption, regardless of whether or not the requirement under GL 7.1 is fulfilled. The new GL 7(1)(b) clarifies this.	See the changes made to the GL 7.1(b), highlighted in the response to comment 124 above.
134. GL 7.3	While many respondents welcomed the clarification provided in GL 7.3, some respondents requested additional clarification regarding the timelines during which ASPSPs can launch their production interface. Other respondents were concerned that the approach in GL 7.3 may challenge the TPPs’ ability to test for 6 months. In addition, one respondent was of the view that the 3-month period in letter (c) of Article 33(6) of the RTS can be counted only as of 14 September 2019 and that, as a result, during September to December 2019, ASPSPs should offer both a dedicated interface and the fall back mechanism. In the respondent’s view, the earliest point in time when an exemption can be granted would be 14 December 2019.	The EBA notes that Article 30(5) of the RTS provides that ASPSPs should make their testing facility available to TPPs at least 6 months before the date of application of the RTS, i.e. by 14 March 2019 at the very latest (or, where applicable, at least 6 months before the target date for the market launch if the launch is scheduled after 14 September 2019). While the RTS require the testing facility to be in place at least 6 months before the application of the RTS, the RTS neither specify a duration for TPPs’ testing nor require the ASPSP to wait a certain period before launching its production interface. This means that those durations may be shorter or longer than 6 months. The EBA is of the view that the testing facility, which enables TPPs that wish to start using the interface to test their software and applications before using the production interface, should continue to remain open when the dedicated interface is in production. TPPs will then decide when they have done enough testing and are ready to start using the ASPSP’s production interface for providing services to their customers. The EBA is, however, also of the view that an ASPSP does not need to wait for a period of 6 months before launching their production interface and may so implement the latter whenever it deems appropriate, after first considering the feedback from TPPs and making any relevant changes. In order to comply with the condition in letter (c) of Article 33(6), the ASPSP should ensure that the production interface is used by TPPs to provide services to their customers for at least 3 months. The EBA disagrees with the last comment that the 3-month period in letter (c) of Article 33(6) of the RTS should be	The EBA has amended GL 7.3 as follows: ‘The three3-month period referred to in letter (c) of Article 33(6)(c) of the RTS may be included within run concurrently with the 6-month testing period referred to in Article 30(5) of the RTS’.
			counted as of 14 September 2019, with the consequence that all ASPSPs would need to build the fall back mechanism by 14 September 2019, and considers that such an interpretation would not be in line with the RTS, given that the RTS do not require the testing to last 6 months, as explained above, but that the testing facility should be available for at least 6 months before the application of the RTS. The EBA also considers that the interpretation put forward by the respondent would contradict the purpose for which the exemption to the fall back mechanism was introduced. The EBA, therefore, remains of the view that the 3-month period in letter (c) of Article 33(6) may run concurrently with the testing referred to in Article 30(5) of the RTS, for the reasons explained above. That being said, the EBA acknowledges that the wording of GL 7.3 may not have been entirely clear and has therefore refined the wording to clarify the point highlighted above. In addition, the EBA has deleted the reference to the ‘6-month’ testing, given that, as explained above, the testing period may be longer or shorter than 6 months.
135. GL 7.3	One respondent requested clarification of whether or not GL 7.3 applies only during a transitional period. Another respondent was of the view that the 3-month period in letter (c) of Article 33(6) may be included in the 6-month testing period in Article 30(5) of the RTS only if the production interface is made available for TTPs to use by 14 June 2019.	The EBA is of the view that, while for the purpose of both Article 30(5) of the RTS and the exemption process it is sufficient for ASPSPs to demonstrate that they have made the testing facility available at least 6 months before the application date of the RTS, the testing facility should remain open for as long as the dedicated interface is in place, to allow new TPPs that may want to use the ASPSP’s dedicated interface to first test their software and applications in the testing environment, before launching their services to their customers via the production interface. As a result, the EBA has arrived at the view that the GL 7.3 does not only apply during a transitory period and that the ASPSP should maintain the testing facility in place on an ongoing basis, in parallel to their production interface.	No change. See, however, the changes made to GL 7.3, highlighted in the response to comment 134 above.
136. General comments	Some respondents suggested that it would be useful to have one single repository at EU level, for example a central website, where TPPs can easily identify at European level all ASPSPs that are available for testing, and that such a website could be hosted by the EBA.	While the EBA agrees that such a repository may be helpful, the EBA considers that this is a measure for not the EBA, but rather the industry to take.	No change.
137. General comments	One respondent was of the view that the EBA should have a target for the percentage of AISPs and PISPs that use the production interface versus the total number of AISPs and PISPs in the market.	The EBA considers that this is not a target that the EBA can set and reiterates that the EBA encourages TPPs to use the dedicated interfaces developed by ASPSPs, even though there is no obligation for TPPs to do so in the run up to 14 September 2019.	No change.
138. General comments	One respondent suggested that the assessment of ‘widely used’ could be handled by an IT-group service acting on behalf of multiple banks.	The EBA considers that the GL do not restrict this possibility. However, the EBA notes that, in such a case, the evidence required in accordance with GL 7.1 should be submitted for and by each individual ASPSP.	No change.
Feedback on responses to question 7
139. GL 8.1(a)	Several respondents suggested clarifying that the condition in letter (d) of Article 33(6) of the RTS should be assessed in the context of the 3-month ‘live testing’ and not in the context of the testing facility.	The EBA notes that the condition in letter (d) of Article 33(6) of the RTS is that ‘any problem related to the dedicated interface has been resolved without undue delay’. Furthermore, Article 33(7) of the RTS requires CAs to ‘revoke the exemption referred to in paragraph 6 where the conditions (a) and (d) [of Article 33(6) of the RTS] are not met by the account servicing payment service providers for more than two consecutive calendar weeks.’ Consequently, the EBA has arrived at the view that, for the purpose of assessing if an ASPSP is eligible for an exemption, CAs should assess this condition by referring to the ASPSP’s production interface and in the context of the minimum 3-months period referred to in letter (c) of Article 33(6) of the RTS during which the ASPSP should ensure that its production interface is ‘widely used’ by TPPs for providing services to their customers, and not by reference to the test-only interface that ASPSPs need to make available to TPPs in accordance with Article 30(5) of the RTS.	No change.
			Once an exemption has been granted, ASPSPs should continue to meet this condition on an ongoing basis, and failure to do so may constitute grounds for the revocation of the exemption in accordance with Article 33(7) of the RTS. However, as explained in the response to comment 171 below, this ongoing monitoring is not part of the scope of these GL.
140. GL 8.1(a)	Some respondents suggested clarifying what the terms ‘systems’ and ‘problems’ in GL 8.1 mean, to avoid overlaps with the incident reporting obligations of the PSPs.	The EBA notes that the reference to ‘systems’ in GL 8.1(b) refers to ‘systems or procedures in place for tracking, resolving and closing problems, particularly those reported by PISPs, AISPs and CBPIIs’. The EBA is of the view that this includes any internal procedures that the ASPSP has in place for logging, monitoring, resolving and closing problems related to its dedicated interface. The EBA also notes that the reference to ‘problems’ in GL 8 has the same meaning as in letter (d) of Article 33(6) of the RTS, and is of the view that, in this context, ‘problems’ includes any issues, including any technical problems, related to the ASPSP’s dedicated interface that have been reported by PSUs or TPPs to the ASPSP or that the ASPSP has otherwise identified. The EBA notes that the requirement in both Article 33(6) of the RTS and in GL 8 is without prejudice to the security incidents reporting obligations of PSPs under PSD2, which are governed by Articles 95 - 96 of PSD2 and the EBA Guidelines on major incident reporting under PSD2 (EBA/GL/2017/10).	No change.
141. GL 8.1(b)	Several respondents requested clarification of what ‘without undue delay’ means in GL 8.1(b).	The reference to ‘without undue delay’ in the draft GL 8.1(b) submitted for consultation had the same meaning as in letter (d) of Article 33(6) of the RTS. The EBA is of the view that, in this context, ‘without undue delay’ means that the APSPS should resolve any problem related to its dedicated interface without any unnecessary delay and within the time limits defined in accordance with the service level targets in GL 2.1. That being said, the EBA has amended GL 8 to align with	The EBA has amended GL 8.1(b) as follows: ‘For the purpose of Article 32(1) and letter (d) of Article 33(6)(d),of the RTS, the ASPSP should provide to the competent authority with: […] b. an explanation of the problems, particularly those reported by PISPs, AISPs and CBPIIs, that have not been
			Article 33(6)(d) of the RTS and has deleted the reference in GL 8.1 (b) to ‘problems that have not been resolved without undue delay’. The EBA notes that, in accordance with GL 2.1 and 8, the ASPSP should define service level targets for resolving problems related to its dedicated interface that are at least as stringent as those for its own PSU interface(s). This means that the ASPSP’s performance when resolving problems related to its dedicated interface should be at least as good as it is when resolving problems related to its customer interface(s). See also the response to comment 24 above.	resolved without undue delay in accordance with the service level targets and support detailed set out in Guideline 2.1. See also the changes made to GL 2.1, highlighted in the response to comment 24 above.
142. GL 8.1(b)	Some respondents were of the view that the service level targets and statistical data will only identify if there is a problem with the availability of the dedicated interface, and will not indicate if a specific problem has been resolved in a timely manner. One respondent suggested deleting GL 8.1(b), as it does not provide any additional useful information to CAs and creates an unnecessary burden for ASPSPs and CAs.	The EBA notes that, in accordance with GL 8.1(b), the ASPSP should report and explain to its CA any problem reported by TPPs that the ASPSP has not managed to resolve in accordance with the service level targets set out in GL 2.1. This information should be provided to the CA, and is not part of the statistics that the ASPSP is required to publish on its website in accordance with GL 3. The EBA considers that this information is necessary to allow CAs to determine if the ASPSP complies with the requirement in letter (d) of Article 33(6) of the RTS and with Article 32(1) of the RTS. Therefore, the EBA does not agree with the last suggestion to delete this GL.	No change.
143. GL 8.1 (a)- (b)	Several respondents suggested adding the average problem response and solving times as additional KPIs in GL 2. Some respondents were of the view that ASPSPs should be required to publish comparative statistics on their error resolution performance, for errors of the same severity, across all access interfaces. Another respondent suggested that the EBA should make allowances where an ASPSP does not achieve the same problem resolution times for the dedicated interfaces as the ones for its other PSU interfaces, as there is likely to be a higher volume of problems	As explained in the responses to comments 24 and 141 above, the EBA has amended GL 2.1 to clarify that the ASPSP’s service level targets for resolving problems related to the dedicated interface should be at least as stringent as those for the PSU interface(s). The EBA is of the view that this should ensure that an ASPSP’s performance when dealing with problems reported by TPPs is at least as good as its performance when dealing with problems reported by the ASPSP’s own PSUs as regards the customer interface(s). That being said, and as explained in the responses to comment 24 and 141 above, the EBA is of the view that a	The EBA has amended GL 2.1 as follows: GL 2.1 ‘The ASPSP should have in place the same define key performance indicators (KPIs) and service level objectives and targets, including for problem resolution, out of hours support, monitoring and, contingency plans and maintenance for its dedicated interface that are at least as it has in place stringent as those for

raised regarding the dedicated interface, because of its novelty, than regarding the direct PSU channels. requirement for ASPSPs to publish data on their error resolution performance across all access interfaces would go beyond what is required in the RTS and could be unduly burdensome for ASPSPs. the interface(s) used by made available to its own payment service users (PSUs) for directly accessing their payment accounts online’.
144. GL 8.1 (a)-
(b)
Some respondents suggested expanding GL 8, so
ASPSPs are required to document and provide data on all the complaints received from TPPs, the length of time it took the ASPSP to resolve, or reject, each complaint, and, in the case of a rejection, the basis of the ASPSP’s decision. In addition, some respondents were of the view that the information submitted to CAs should be supplemented by information from complaints received from PSPs, TPPs and consumers; that TPPs should be able to report issues directly to the CA and to indicate any critical problems they may have faced when using the dedicated interface; and that CAs should consider complaints from TPPs and especially take into consideration issues reported by multiple TPPs.
Furthermore, several respondents disagreed with the statement in paragraph 63 of the CP that complaints data are not a reliable indicator of issues being resolved in a timely manner. These respondents argued that, if information is only exchanged bilaterally between the CA and the ASPSP, CAs may not be able to identify systemic problems.
The EBA notes that the amended GL 6.6 already requires ASPSPs to provide their CA with the feedback received from TPPs as part of the testing, including an explanation of how the ASPSP has addressed any issues identified during the testing. In addition, GL 2.1 requires ASPSPs to define service level targets for the resolution of problems related to their dedicated interfaces that are at least as stringent as those for their PSU interface(s). Furthermore, GL 8 requires ASPSPs to provide information to their CA on the procedures in place for resolving problems reported by TPPs and to explain to the CA whenever a problem reported by a TPP is not resolved in accordance with the service level targets in GL 2.1 The EBA considers that this level of information is sufficient to allow CAs to determine if the ASPSP meets the condition in letter (d) of Article 33(6) of the RTS. If the CA considers that it needs more information to be able to assess whether or not the ASPSP complies with the requirements in Article 33(6) of the RTS, it can request the additional data from the ASPSP. The EBA would like to clarify that, while customer complaints data are an important source of information and are incredibly helpful and relevant in many cases, the EBA is of the view that it is unlikely that customers would be aware of any problems related to the dedicated interface, given that they do not use it directly. Therefore, customer complaints data are likely not to be a reliable indicator of issues related to the dedicated interface being resolved in a timely manner. Finally, the requirements in these GL are without prejudice to the obligations of PSPs under the Joint Committee Guidelines on complaints-handling for the securities The EBA has amended GL 8.1 as follows:
‘For the purpose of Article 32(1) and letter (d) of Article 33(6)(d),of the RTS, the ASPSP should provide to the competent authority with:
a.information on the systems or procedures in place for tracking, resolving and closing problems, including particularly those reported by PISPs, AISPs and CBPIIs; and b.an explanation of the problems, particularly those reported by PISPs, AISPs and CBPIIs, that have not been resolved without undue delay in accordance with the service level targets and support detailed set out in Guideline 2.1.

		(ESMA) and banking (EBA) sectors (the ‘JC Guidelines on complaints- handling’), including the obligations on the procedure to respond to complaints.
145. General comments	One respondent was of the view that ASPSPs should put in place a portal to report problems using a ticket system.	The EBA considers that this is one potential way in which ASPSPs can identify, track and resolve problems, but that it is not the only way. The EBA is of the view that it is up to an ASPSP to decide on its internal problem reporting policy, in accordance with the requirements that may be applicable under EU law, including the JC Guidelines on complaints handling. Therefore, the EBA considers that the GL cannot impose such a requirement.	No change.
146. General comments	One respondent suggested that the resolution of problems could be handled by an IT-group service, acting on behalf of multiple banks.	The EBA considers that the GL do not restrict this possibility.	No change.
147. General comments	One respondent was of the view that any service levels for resolving problems beyond testing are defined and regulated in the JC Guidelines on complaints handling.	The EBA is of the view that the requirements in these GL apply without prejudice to the requirements in the JC Guidelines on complaints-handling. See also the response to comments 144 above.	No change.
148. General comments	One respondent suggested that a standardised template would be helpful for the purposes of organising and submitting the information required under GL 8.	The EBA is of the view that the format in which and the method by which a CA requires ASPSPs to submit the information required under these GL is a decision for the CA to take and is outside the scope of these GL.	No change.
Feedback on responses to question 8
149. GL 9.1	One respondent requested clarification of whether or not the EBA intends to respond to the notifications it receives from CAs after an exemption has been granted, and if so how. The respondent was of the view that an exemption should not be revoked after the 1-month period in GL 9.1 has expired and a CA has granted an exemption, in the absence of a material change in the ASPSP’s compliance with the GL.	The EBA may provide comments to the CA regarding the notifications received in accordance with GL 9.1, where it considers it necessary to do so, in fulfilment of the EBA’s consultation role under Article 33(6) of the RTS and to ensure a consistent application of the exemption conditions. The decision of whether or not to revoke an exemption belongs to the CA in accordance with Article 33(7) of the RTS. See also the response to comment 171 below.	No change.

150. GL 9.1	One respondent was of the view that the 1-month period in GL 9.1 should apply only to the initial assessment of a request from an ASPSP for a specific dedicated interface and that subsequent resubmissions by the same ASPSP for the same interface should be handled with priority over a new submission.	The EBA is of the view that this is a decision for the CA to take. The EBA notes that GL 9.1 refers to the consultation process between CAs and the EBA, in accordance with Article 33(6) of the RTS, and not to the process of applying for an exemption between ASPSPs and their CA.	No change.
151. GL 9.3 (new 9.2)	While many respondents agreed with the pragmatic approach in GL 9.3, some respondents expressed concerns that it may lead to divergent and inconsistent approaches across Member States and stressed that the EBA should provide further guidance and support to CAs during the transitional period in GL 9.3 (new 9.2).	Irrespective of the transitional period in GL 9.3 (new 9.2), the EBA will continue to provide guidance and support to CAs on the interpretation of the conditions in Article 33(6), in the run up to September 2019 and afterwards, in addition to the guidance provided in these GL, in fulfilment of the EBA’s consultation role under Article 33(6) of the RTS and the EBA’s objective of supervisory convergence, as stated in the EBA founding regulation. The EBA has also reflected further on the potential risk of divergence and possible inconsistencies and considers that in the case of a banking group with subsidiaries in different Member States that will use the same dedicated interface, the relevant CAs should inform one another when one CA considers that the dedicated interface does not meet the requirements for an exemption. This is reflected in the new GL 9.4.	No change to GL 9.2 (new 9.3). However, a new GL 9.4 has been introduced – see comment 154 below.
152. GL 9.3 (new 9.2)	One respondent suggested clarifying in GL 9.3 (new 9.2) that Annex 1 could be used if more than one ASPSP applies for an exemption, in line with the wording in rationale 66 of the CP.	The EBA acknowledges that the wording may not have been very clear, and has refined the wording in GL 9.3 (new 9.2) to clarify that during the transitional period, until 31 December 2019, CAs may submit the Assessment Form covering one or more ASPSPs.	The EBA has amended GL 9.3 (new 9.2) as follows: ‘In derogation from Guideline 9.1, until 31 December 2019, competent authorities that have notified the EBA that they comply with these Guidelines can proceed to grant an exemption provided that they have consulted the EBA by informing it of their intention to grant the exemption to one or more ASPSPs using the Assessment Form set out in Annex 1. In such a case, the competent authorities may submit
				the Assessment Form covering one or more ASPSPs’.
153. General comments	Some respondents did not agree with the statement in paragraph 64 of the CP that CAs may decide on the format in which ASPSPs are required to provide information and argued that this could lead to fragmentation among Member States, in particular for PSPs that are active in several Member States. Several respondents expressed support for a consistent, standardised approach to be adopted by CAs. One respondent was of the view that it would be helpful for ASPSPs to be provided with templates regarding the information required. Another respondent suggested an access-restricted web platform at European level could be used to handle assessment forms.	The EBA notes that the decision of whether or not an ASPSP complies with the requirements set out in the RTS and these GL and is eligible for an exemption belongs to the CAs. By the same token, the EBA is of the view that the format in which a CA requires ASPSPs that apply for an exemption to provide information, to assess whether or not the ASPSP complies with the requirements in the RTS and these GL, is a decision for the CA to take. However, in line with one of the respondents, the EBA notes that CAs may choose to provide templates to ASPSPs.	No change.
154. General comments	A large number of respondents requested clarification of the process for applying for an exemption in the case of ASPSPs that have branches or subsidiaries in different Member States using the same dedicated interface.	The EBA notes that, in accordance with point 39 of Article 4 of PSD2, a branch is ‘a place of business other than the head office which is part of a payment institution, which has no legal personality and which carries out directly some or all of the transactions inherent in the business of a payment institution’. Furthermore, in accordance with point 17 of Article 4(1) of Regulation No 575/2013, a ‘branch’ means ‘a place of business which forms a legally dependent part of an institution and which carries out directly all or some of the transactions inherent in the business of institutions’. As a branch does not have legal personality, an ASPSP will always have to apply for an exemption from the fall back mechanism with the CA in the Member State where its head office is located, irrespective of whether or not the ASPSP has branches in other Member States that will use the same dedicated interface as that used by the head office. In this case, the exemption granted by the CA of the Member State where the ASPSP’s head-office is situated	The EBA has added a new GL 9.4, as follows: ‘Where an ASPSP is part of a group with subsidiaries in different Member States that will use the same dedicated interface, each of the competent authorities of those Member States should: a.inform the other relevant competent authorities without undue delay if it intends to refuse to grant an exemption; and b.on request from the other competent authorities and without prejudice to any confidentiality obligations, inform the other competent authorities of its reasoning why it intends to refuse to grant an exemption and, where
			will also be valid in the other Member States where the ASPSP is providing payment services via branches using the same dedicated interface. By contrast, subsidiaries are separate legal entities from the ASPSP and, therefore, each subsidiary would need to apply for a separate exemption with its CA in the Member State where the head-office of the subsidiary is located. In order to limit the risk of inconsistent assessments of the same dedicated interface by different CAs, the EBA encourages CAs to request information from ASPSPs, when applying for an exemption, on whether or not the same dedicated interface will be used by other Group entities in other Member States, and, where necessary, to consult with the other CAs before granting, or refusing to grant, an exemption for the same dedicated interface. However, in order not to unduly delay the assessment process for each CA, and given the large number of requests for assessments expected, the EBA has arrived at the view that this prior consultation is particularly important when one CA intends to refuse to grant an exemption. This is reflected in GL 9.4.	relevant, of the issues reported by PISPs, AISPs and CBPIIs to the competent authority’.
155. General comments	Some respondents were of the view that Annex 1 should include more details on the arguments for granting an exemption. Another respondent was of the view that Annex 1 should provide more details on the reasons for the rejection of an application, and suggested listing, at minimum, the major criteria for not granting an exemption.	The EBA considers that the level of detail in Annex 1 is sufficient, on the basis that the conditions that should be met to benefit from an exemption are set out in the RTS and the GL. Where a CA decides not to grant an exemption, it should specify in the Assessment Form submitted to the EBA, in accordance with the GL 9.2 (new 9.3), its reasons for refusing to grant the exemption (see also paragraph 9 of Annex 1). In addition, where the CA intends to refuse to grant an exemption and the same dedicated interface is also used by other group entities in other Member States, the CA should inform the other relevant CAs of its intention to refuse to grant an exemption and, upon request, inform the other CAs of its reasoning why it intends to refuse to grant an exemption. This is reflected in the new GL 9.4. See	No change. See, however, the new GL 9.4, highlighted in the response to comment 154 above.
			also the response to comment 154 above.
156. General comments		Some respondents were of the view that, where an exemption request is rejected, ASPSPs should be entitled to receive the feedback provided by the CA to the EBA and that the GL should define a mechanism for ASPSPs to oppose or appeal against decision by a CA not to grant an exemption.	The EBA considers that the procedure for an ASPSP to oppose or appeal a decision taken by the CA is governed by national law, and is not within the scope of these GL.	No change.
157. General comments		One respondent suggested that the GL should allow a simplified application process in cases of standardised, cooperative solutions or solutions adopted by several counterparties regarding the dedicated interfaces. The respondent suggested that, in such case, the certification of the compliance of the dedicated interface and the ‘widely used’ condition could be assessed at the level of the standardised/ cooperative solution. Another respondent requested clarification of whether all ASPSPs within the same group that use the same dedicated interface in different Member States can use the stress testing data, the testing facility data and the ‘wide usage’ MI from one ASPSP in the group for the purpose of the exemption, or whether data must be provided for each ASPSP separately.	The EBA is of the view that the fulfilment of the conditions in Article 33(6) of the RTS should be assessed separately for each ASPSP that applies for an exemption and that ASPSPs should provide all requested data to each CAs in order to prove compliance with GL 2-8, as the assessment will be carried out by each CA. That being said, the EBA notes that the ‘widely used’ condition is not limited to the territory of one Member State and could be considered at EU level if the CA considered it appropriate.	No change.
158. General comments		Some respondents requested clarification of whether or not ASPSPs can apply for separate exemptions for different interfaces (e.g. different interfaces serving retail versus corporate customers, or different interfaces for each brand or channel).	Yes, ASPSPs can and should apply for separate exemptions for each dedicated interface if they have developed more than one and wish to be exempted from the obligation to build the fall back. Where the ASPSP has opted for a dedicated interface in accordance with Article 31 of the RTS, it is the ASPSP’s choice whether to offer one dedicated interface servicing all their customers, or separate dedicated interfaces servicing different customer segments. In the latter case, ASPSPs would need to apply for a separate exemption for each dedicated interface to be exempted from the obligation to build the fall back. See also the response to comment 169 below.	No change.
159. General comments	One respondent suggested amending the title of the GL, to clarify that the GL cover the conditions to be met to benefit from an exemption from the ‘contingency mechanism’ (i.e. the obligation to build the fall back), and not from the ‘contingency measures’ in Article 33(1) and (2) of the RTS, which are broader.	The EBA acknowledges that the reference to ‘contingency measures’ in the title of the GL may not have been clear and has amended the title to refer to the ‘contingency mechanism’ in paragraph 4 of Article 33 of the RTS.	The EBA has amended the title of the GL to refer to the ‘conditions to be met to benefit from an exemption from the contingency measures mechanism under Article 33(6)’ of the RTS.
Feedback in responses to question 9
160. General comments	Many respondents were concerned about the deadlines set by the RTS and the timelines for meeting the requirements in the GL. Some respondents were of the view that ASPSPs will not be able to meet the deadline set by the RTS (i.e. 14 September 2019) and suggested that this deadline should be deferred. One respondent suggested extending this deadline by another 18 months. Other respondents were concerned about the potentially adverse impact on TPPs’ business and innovation if TPPs are no longer allowed to screen scrape without the ASPSP providing the fall back mechanism. These respondents were concerned that the tight deadlines do not allow CAs to do a thorough assessment of the applications for an exemption and were of the view that, unless a dedicated interface undoubtedly meets all the requirements for an exemption, it would be preferable to either require ASPSPs to build the fall back, or delay the ban on screen scraping. By contrast, other respondents suggested that ASPSPs that are not able to meet all the requirements in time, but have a plan to fully comply and are committed to developing a high-quality dedicated interface, should be allowed a grace period for meeting all the requirements, without having to build the fall back by 14 September 2019. These	The EBA notes that, in accordance with the RTS, any ASPSP that has opted for a dedicated interface in accordance with Articles 30 and 31 of the RTS, and has not obtained an exemption from the obligation to build the fall back by the date of application of the RTS (i.e. by 14 September 2019), is required to build the fall back mechanism described in Article 33(4), by 14 September 2019. The EBA notes that the timelines that ASPSPs must meet to be eligible to receive an exemption are determined by the timelines set in PSD2 and the RTS. It is not within the EBA’s power to change these timelines. As regards the current methods of access by screen scraping, the EBA has clarified in its final report on the RTS (EBA/RTS/2017/02) and in the EBA Opinion on the transition from PSD1 to PSD2 (EBA/Op/2017/16) that the existing practice of third-parties accessing the PSU data via the customer interface, and without identification, will no longer be allowed once the RTS apply.	No change.
		respondents were of the view that imposing the fall back, or the prospect of having to build the fall back by September 2019, takes away the incentive and resources needed for ASPSPs to develop high performing dedicated interfaces. Similarly, one respondent was of the view that the timelines put forward by the EBA motivate firms to hedge their risk and build the fall back, which ultimately reduces the incentive to develop high performing, customer-focussed APIs. Respondents also stressed the time criticality for the EBA to finalise these GL as soon as possible.
161. General comments		Some respondents were particularly concerned about the feasibility of meeting the deadlines for obtaining an exemption if PSD2 has not been transposed into national law in their jurisdiction and no CA has been designated.	The EBA agrees that the delay in the implementation of PSD2 in some Member States creates additional challenges for all parties involved, including for ASPSPs, TPPs and CAs when meeting the deadlines set by the RTS. That being said, given that the RTS are directly applicable and have been published in March 2018, the requirements contained therein will not change, meaning that, regardless of whether or not PSD2 has been transposed into national law, and given that it is very likely PSD2 will be transposed by the time the RTS apply, ASPSPs from countries where PSD2 has not yet been transposed have the same preparation time as others and cannot therefore be considered as being negatively affected. In addition, and as explained in the response to comment 160 above, it is not within the EBA’s power to change the timelines imposed by PSD2 and the RTS.	No change.
162. General comments		Some respondents were concerned that the API standards developed by market initiatives are not yet matured.	This is not a comment related to the GL and therefore is out of scope.	No change.

163. General comments	Several respondents requested clarification regarding the timelines for ASPSPs to apply for an exemption, and the timelines for CAs to process the application and make a decision. Some respondents asked if an application may be submitted before the expiry of both the testing period and the 3-month wide usage period, so as to allow the CA time to consider the application ahead of 14 September 2019. In addition, one respondent called for the EBA to set clear timelines for CAs to acknowledge receipt of, and respond to, exemption requests.	The timelines by which ASPSP should apply to their CA for an exemption are a decision for CAs to make in line with the requirements in the RTS and these GL. See also the response to comment 160 above.	No change.
164. General comments	Some respondents requested clarification regarding the treatment of the applications pending on 14 September 2019 and of those applications received after 14 September 2019.	The requirements set out in the GL apply to both applications for an exemption received in the run up to 14 September 2019, and those received after this date.	No change.
165. General comments	Several respondents were concerned that if the assessment by CAs takes too long, ASPSPs may be forced to build the fall back in an unrealistic short timeframe in the event that their application for an exemption is rejected. One respondent was also of the view that, if an ASPSP applies for an exemption ahead of the 14 September 2019 deadline, the CA should, in accordance with Article 33(6) of the RTS, take into account if the ASPSP is able to offer the fall back method within 2 months, in case the application for an exemption were to be rejected.	In accordance with Article 30 of the RTS, all ASPSPs have to offer at least one interface from the day the RTS apply. In accordance with Article 34(4) of the RTS, in the event that an ASPSP that has opted for a dedicated interface does not receive an exemption from the obligation to build the fall back mechanism by 14 September 2019, the ASPSP should have the fall back mechanism in place by 14 September 2019 in order not to be in breach of EU law. As explained in the response to comment 160 above, it is not within the EBA’s power to change the timelines imposed by PSD2 and the RTS. Consequently, the EBA considers that it is important to take into account, in the timelines for applying for an exemption, the possibility that an ASPSP will not receive an exemption by 14 September 2019 and, therefore, will have to build the fall back by 14 September 2019. However, this does not mean that, in the event that the ASPSP’s request for an exemption is rejected, the ASPSP should be allowed 2-months to build the fall back if that would mean exceeding the deadline laid down by the RTS for building	No change.
			the fall back (i.e. 14 September 2019). The EBA is of the view that the 2 months period in Article 33(7) of the RTS only applies from 14 September 2019 onwards, and that it cannot be inferred from this article that, in the event that the ASPSP’s request for an exemption is rejected, the ASPSP may be allowed a grace-period from the obligation to build the fall back later than 14 September 2019. CAs may consider it appropriate to aim to provide decisions 2 months in advance of the 14 September deadline, provided that the ASPSP has applied for the exemption to the CAs well in advance of that date. This remains a decision for each CA to make.
166.	General comments	One respondent was of the view that it is particularly challenging for smaller firms and FinTech firms to meet the deadlines and to build the fall back mechanism if they do not succeed in obtaining an exemption. Another respondent suggested that larger ASPSPs would face difficulties too, as a result of having a larger number of customers, products or brands to manage.	As stated in the response to comment 160 above, the timelines that ASPSPs must meet to be benefit from an exemption from the obligation to build the fall back are determined by the application date of the RTS and the requirements set out in the RTS, which apply to all ASPSPs, irrespective of their size. Similarly, all ASPSPs wishing to benefit from an exemption have to comply with all the requirements set out in Article 33(6) of the RTS and these GL in order to be eligible for an exemption, irrespective of their size. That being said, the evidence and in particular the level of detail provided, may differ, taking into account the proportionality principle, particularly in the light of the ASPSP’s size. Moreover, the EBA is of the view that CAs should bear in mind the proportionality principle when applying the requirements in these GL in particular the assessment of the ‘widely used’ condition. See also the response to comment 52 above.	No change.
167.	General comments	One respondent was of the view that it would be helpful to have more visibility on where each ASPSP is in its journey towards the September or March 2019 deadline.	This comment is not related to the GL and is therefore out of scope.	No change.

Feedback on responses to question 10

168. General comments	Some respondents requested clarification of whether or not the exemption to the fall back mechanism covers all TPP services, i.e. AIS/PIS/CBPII, or whether it can cover only one specific service individually (e.g. only PIS).	The EBA notes that the exemption refers to the contingency mechanism in Article 33(4) of the RTS, which states that: ‘As part of a contingency mechanism, payment service providers referred to in Article 30(1) shall be allowed to make use of the interfaces made available to the payment service users for the authentication and communication with their account servicing payment service provider, until the dedicated interface is restored to the level of availability and performance provided for in Article 32’. The exemption does not refer only to a specific TPP service (e.g. only AIS or PIS). In order to be eligible for an exemption from the obligation to build the fall back, an ASPSP should ensure that its dedicated interface supports all TPP services.	No change.
169. General comments	Respondents asked whether the exemption covers all customer segments (retail and corporate customers) or only a specific customer segment.	The exemption is specific to each dedicated interface. As explained in the response to comment 158 above, an ASPSP may decide to have only one dedicated interface for servicing all its customers or separate dedicated interfaces for different customer segments. In the latter case, ASPSPs would need to apply for a separate exemption for each dedicated interface, in order to be exempted from the obligation to build the fall back.	No change.
170. General comments	One respondent requested clarification of how TPPs should identify themselves towards ASPSPs while using the fall back option, in case an ASPSP has to build the fall back.	The EBA is of the view that the identification of TPPs when using the customer-adapted interface is outside the scope of these GL. The EBA is currently looking into this issue further, and will provide clarity on this at a later stage.	No change.
171. General comments	Several respondents were of the view that the GL should also cover the process for the revocation of an exemption under Article 33(7) of the RTS and requested clarification of whether or not partial revocation is possible (for example, only in relation to PIS, but not for AIS or CBPPII). Several respondents were of the view that the GL should specify how CAs will monitor the dedicated interfaces after an exemption has been granted and, in particular, how they will ensure that TPPs’ services are not disrupted in accordance with Article 30(6) of the RTS. Some respondents also suggested that CAs should put mechanisms ‘post-exemption’ in place , while a decision on the revocation of the exemption is pending, to ensure that TPPs can have immediate access to the PSU interface if the dedicated interface is not working properly.	Given the time criticality for finalising these GL, these GL focus on the conditions for granting an exemption and do not address the requirement under Article 33(7) of the RTS regarding the revocation of the exemption. The EBA will provide clarity on this, as well as on the interaction between Article 33(7) of the RTS and Article 30(6) of the RTS at a later stage.	No change.
172. General comments	Some respondents were of the view that the GL should also cover the requirement in Article 30(4) of the RTS regarding the notification of changes to the dedicated interface.	The EBA is of the view that the requirement in Article 30(4) of the RTS regarding the notification of changes to the technical specifications is outside the scope of this mandate. See also the response to comment 119 above.	No change.