Response to consultation on the Guidelines on the conditions to be met to benefit from an exemption from contingency measures under Article 33(6) of Regulation (EU) 2018/389 (RTS on SCA & CSC)
Go back
Additionally, we believe that the performance of an ASPSP in addressing errors/faults in the dedicated interface should be a standalone KPI that is recorded and reported to the relevant CA. The TPP community is keen to ensure that ASPSPs allocate adequate resources in dealing with reported faults/errors on a dedicated TPP access interface.
We have found it difficult to reconcile the statement that appears in Clause 22 of the Rationale Section stating that “The EBA is also proposing a formula to calculate uptime and down time taking into account performance so as to arrive at a figure that can be compared for the PSU and dedicated interface” with the performance KPIs detailed in Guideline (GL) 2.3. The latter only focus on time rather than the scope/accuracy of information provided to TPPs over the dedicated interface. There is also no explicit requirement to monitor/report comparative differences on performance across all ASPSP access interfaces.
We propose that GL 2.3 is expanded to include metrics on the scope (number/type of data elements) and accuracy (alignment across all ASPSP interfaces at a given point in time) of data made available over the dedicated TPP access interface. We also propose that GL 3.1 (b) is expanded to require ASPSPs to publish the “comparison of the availability and performance of its dedicated interface with its best-performing PSU interface”. We would also encourage the EBA to identify a process that TPPs can use to report ongoing availability and performance issues they have faced using Test and Live dedicated access interfaces deployed by ASPSPs. CAs should consider the scope/frequency of TPP-reported issues in the process of granting exemptions to the contingency mechanism detailed in RTS Art.33(4).
We are keen to receive additional clarity from the EBA on the unplanned unavailability definition in RTS Art 33(1) as repeated in GL 2.4(b). Is the assessment of unavailability to be carried out exclusively at the ASPSP server end? We appreciate that network lag and networking equipment failure may be factors in observed delays to the provision of information to TPPs. However, we believe it is appropriate for CAs to consider persistent interface unavailability reports for a given ASPSP interface that are forwarded by multiple TPPs. As highlighted above, we would propose that the EBA identifies a TPP-reporting process and provides guidance to the CAs to review/consider TPP reports during the exemption assessment process.
We require more clarity from the EBA on the apparent discrepancy between RTS Art. 32(4) and GL 3.1(a). The former requires ASPSPs to publish quarterly statistics on the availability and performance of all access interfaces; the latter refers to a plan for the publication of “daily statistics on a quarterly basis”.
Following up our comment above on GL 3.1, we would propose that ASPSPs are required to publish the relevant quarterly statistics on the performance/availability of all access interfaces on their website as part of the exemption assessment process (in advance of the application of the RTS). This would be consistent with the condition detailed in RTS Art. 33(6)(a). We note that our proposal goes beyond the current text in GL3.1 that only refers to a requirement that the ASPSP “should provide to its CA a plan for publication…”.
We also want to highlight the lack of any explicit CA guidance in the Guidelines to check for themselves that the ASPSP dedicated interface matches the highest levels of availability/performance of the best performing ASPSP direct PSU access interface. Rationale clause 24 references such an ambition; however, it does not appear on any of the Guidelines. We would encourage the EBA to provide such guidance to CAs in the main GLs; CAs can use a number of methods (e.g. periodic random/targeted testing of an ASPSP interface by an independent 3rd party) to carry out such checks.
GL 4.2 would benefit from additional clarity on (i) the duration of any stress-testing exercise and (ii) the definition of “unusually high numbers of requests” and “extremely high number of concurrent sessions”.
We believe that Guideline 4.3 should be expanded to require ASPSPs to provide to the relevant CA a summary of the stress test results of all its access interfaces. A CA could use the PSU access interface stress test results to benchmark the performance of the dedicated interface across a range of stress test scenarios (concurrent access sessions, multiple service requests etc.).
We also note that Rationale Clause 31 of the CP refers to a CA responsibility to “monitor KPIs”; Rationale Clause 32 also appears to point to a risk-based approach of indirect monitoring of such KPIs by CAs. We would propose that CAs carry out monitoring of ASPSP interfaces, indicators and targets on a risk-adjusted (and/or targeted basis) using an independent 3rd party as part of the review process of an exemption application for a dedicated interface. Such an approach would be better aligned with the CA responsibility detailed in RTS Art. 33(2).
The imposition of the use of redirection - as the sole PSU authentication procedure supported by the dedicated interface – will also obstruct the use of TPP-serviced devices such as POS terminals, smart watches or voice automation and hinder further service innovation in this area. Therefore, we propose that the use of redirection is not considered an obstacle to the provision of TPP services only if it is one of multiple customer authentication procedures supported over the dedicated interface.
We support the requirement that ASPSPs provide a confirmation that the dedicated access interface does not require any additional checks of the PSU consent extended to authorised TPPs.
We propose that the EBA add an additional requirement to GL 5.1 requiring ASPSPs to provide information to the CA to support their claim that “the IT solution for the dedicated interface and its implementation do not give rise to unnecessary delay, friction or any other attributes that would mean that payment service users are directly or indirectly dissuaded from using the services of PISPs, AISPs and CBPIIs” [GL 5.2(d)]. The relevant CA should review such information as part of the exemption assessment process.
We would encourage the EBA to align the language that appears in Rationale Clause 35 that references “friction, delay or unnecessary steps that would directly or indirectly dissuade PSUs” with the language in GL 5.2(d); the reference to unnecessary steps should be introduced to this Guideline.
Overall, we encourage the EBA to consider feature parity -between the dedicated TPP interface and all PSU direct access channels deployed by an ASPSP – as a component of the CA process of assessing whether an ASPSP dedicated interface creates obstacles in the delivery of TPP services. TPPs expect that the dedicated interface will deliver such feature parity (on capabilities, availability, user experience and overall performance) to match the PSU direct access channels.
We believe that GL6.3 would benefit from additional clarity on the scope of test results submitted to the relevant CA; the minimum duration of such testing should be identified.
It is not clear to us how CAs will interpret GL 6.4; a number of account access API standardization initiatives do not provide conformance testing for individual implementations. Therefore, an ASPSP may claim that its dedicated interface “complies” with an API standard even though there may be significant instances of divergence. We would encourage the EBA to provide guidance to CAs that ASPSPs – that claim compliance of their dedicated interface with an API standard – are requested to demonstrate such compliance.
GL 6.5 lacks specific guidance on the scope of engagement with TPPs - during the design/testing phase of the dedicated interface - that an ASPSP is requested to demonstrate. We propose that CAs seek to review evidence of (i) TPP feedback in the interface design & testing process and of (ii) ASPSP willingness to consider TPP feedback and address TPP concerns.
In this context, we propose that GL 7.1 is expanded to require ASPSPs to identify the total number of TPPs that have received access to the full interface documentation. We invite the EBA to instruct CAs to structure the exemption assessment process to consider (i) any significant discrepancies in the number of TPPs that have received access to the interface specification vs. the number of TPPs that use the interface and (ii) TPP feedback that is provided by any TPP that has received access to the specification.
We note that there is some missing text in the wording of GL 7.1(a) -> “the total number of PISPs, CBPIIs, AISPs that have xxxxxxx or have applied for the relevant authorisation that have made use of the testing facility”; we presume the missing text refers to “received authorization”.
Overall, we acknowledge the EBA concern that a number of ASPSPs may not be able to meet the original “widely used” condition in the RTS because of a lack of interest by TPPs to use a dedicated interface. Our concern is that the dilution of the original RTS condition may allow dedicated interfaces that offer a sub-optimal TPP payment account access to receive an exemption. Therefore, rather than seek to dilute the original RTS condition, we propose that the EBA confirms that ASPSPs that cannot meet this condition will be required to build the contingency mechanism referenced in RTS Art. 33(4). The limited amount of additional effort that ASPSPs are expected to expend to deploy the contingency mechanism (less than two months according to RTS Art. 33(7)) would be an equitable cost to incur to ensure the uninterrupted delivery of the services of the TPPs that attempt to access the payment accounts of ASPSPs. This approach to the dedicated interface exemption assessment process would align with the spirit and the letter of PSD2 and of the RTS on SCA and CSC.
Specifically, GL8.1 does not require ASPSPs to provide any (a) volume-based data for problems that have not been resolved without “undue delay” or (b) to identify the extent of such delays. We propose that GL 8.1 is extended to require ASPSPs to provide such data.
Furthermore, we propose that ASPSPs are required to publish comparative statistics on their error resolution performance for errors of the same severity across all access interfaces as part of the set of published performance indicators (see our earlier Comment under Question 1, above). CAs should be instructed to assess the impact of wide discrepancies in the error resolution capacity of an ASPSP across the payment account access channels it exposes (PSU direct access, dedicated interface) as part of the ongoing compliance assessment process outlined in RTS Art 30(6) and Art. 33(7).
We expect that the pragmatic approach described in GL9 will not lead to any decrease in the quality of the exemption assessment process that is carried out by EEA CAs in the transitional period ending on the 31st December 2019. A number of EMA members are keen to ensure that CAs only award contingency mechanism exemptions to dedicated interfaces that meet all regulatory compliance requirements detailed in PSD2 and in relevant Regulatory Technical Standards. In this context, we encourage the EBA to provide further guidance and support to CAs to ensure the performance of exemption assessment reviews in a consistent manner.
We wish to highlight our earlier concern stated under Q.6 above that CAs should not seek to dilute any of the original exemption conditions – detailed in RTS Art. 33(6) – in the name of expediency. An ASPSP - whose dedicated interfaces cannot satisfy all exemption qualifying conditions – should be required to deploy the contingency mechanism outlined in RTS Art. 33(4).
The EMA would also like to ask for further clarity on the topic of Passporting of Exemptions granted to ASPSPs using a specific dedicated TPP access interface in multiple jurisdictions.
The EMA would encourage the EBA to ensure that all EEA CAs are able to receive/process exemption applications as soon as possible. We also invite the EBA to provide guidance to CAs on the treatment of exemption applications that are still pending at the start of the application of the RTS (14th September 2019).
We also want to highlight the fact that the EBA review of the industry responses to these GLs and the generation of the final Guidelines will be taking place in parallel with national PSD2 implementation consultations run by several CAs in the run up to the start of the application of the RTS. We believe that the industry would benefit from (i) early publication of the final version of these Guidelines and (ii) EBA efforts to co-ordinate the consistent implementation of the exemption assessment process by the CAs that adopt the Guidelines.
We would have expected additional clarity on the role/process for TPPs to communicate their concerns & feedback on a dedicated interface to the relevant CA as part of the exemption assessment process. Instead, the draft GLs adopt a process where ASPSPs declare and self-certify the characteristics of the dedicated interface and submit these to the CA. Our view is that this approach diminishes the role of the TPP as a user/consumer of the interface that is explicitly referenced in the RTS [Art. 33(6)b/c].
We would also expect more explicit guidance provided to CAs on their independent review & monitoring of published interface service level objectives.
Separately, we would welcome more clarity from the EBA on the mechanics of the exemption revocation process and the payment account access options afforded to TPPs during the transitional 2-month period detailed in RTS Art. 33(7).
Question 1: Do you agree with the EBA’s assessments on KPIs and the calculation of uptime and downtime and the ASPSP submission of a plan to publishing statistics, the options that EBA considered and progressed or discarded, and the requirements proposed in Guideline 2 and 3? If not, please provide detail on other KPIs or calculation methods that you consider more suitable and your reasoning for doing so.
We support the EBA view that ASPSPs “should have in place the same service level objectives and targets, out of hours support, monitoring and contingency plans as it has in place for the interfaces used by its own PSUs”. It is not clear how the competent authority proposes to confirm service levels across different ASPSP applicants during the exemption assessment process. We would propose that ASPSPs are requested to provide detail on their service level objectives/targets across all access interfaces for review by the CA.Additionally, we believe that the performance of an ASPSP in addressing errors/faults in the dedicated interface should be a standalone KPI that is recorded and reported to the relevant CA. The TPP community is keen to ensure that ASPSPs allocate adequate resources in dealing with reported faults/errors on a dedicated TPP access interface.
We have found it difficult to reconcile the statement that appears in Clause 22 of the Rationale Section stating that “The EBA is also proposing a formula to calculate uptime and down time taking into account performance so as to arrive at a figure that can be compared for the PSU and dedicated interface” with the performance KPIs detailed in Guideline (GL) 2.3. The latter only focus on time rather than the scope/accuracy of information provided to TPPs over the dedicated interface. There is also no explicit requirement to monitor/report comparative differences on performance across all ASPSP access interfaces.
We propose that GL 2.3 is expanded to include metrics on the scope (number/type of data elements) and accuracy (alignment across all ASPSP interfaces at a given point in time) of data made available over the dedicated TPP access interface. We also propose that GL 3.1 (b) is expanded to require ASPSPs to publish the “comparison of the availability and performance of its dedicated interface with its best-performing PSU interface”. We would also encourage the EBA to identify a process that TPPs can use to report ongoing availability and performance issues they have faced using Test and Live dedicated access interfaces deployed by ASPSPs. CAs should consider the scope/frequency of TPP-reported issues in the process of granting exemptions to the contingency mechanism detailed in RTS Art.33(4).
We are keen to receive additional clarity from the EBA on the unplanned unavailability definition in RTS Art 33(1) as repeated in GL 2.4(b). Is the assessment of unavailability to be carried out exclusively at the ASPSP server end? We appreciate that network lag and networking equipment failure may be factors in observed delays to the provision of information to TPPs. However, we believe it is appropriate for CAs to consider persistent interface unavailability reports for a given ASPSP interface that are forwarded by multiple TPPs. As highlighted above, we would propose that the EBA identifies a TPP-reporting process and provides guidance to the CAs to review/consider TPP reports during the exemption assessment process.
We require more clarity from the EBA on the apparent discrepancy between RTS Art. 32(4) and GL 3.1(a). The former requires ASPSPs to publish quarterly statistics on the availability and performance of all access interfaces; the latter refers to a plan for the publication of “daily statistics on a quarterly basis”.
Following up our comment above on GL 3.1, we would propose that ASPSPs are required to publish the relevant quarterly statistics on the performance/availability of all access interfaces on their website as part of the exemption assessment process (in advance of the application of the RTS). This would be consistent with the condition detailed in RTS Art. 33(6)(a). We note that our proposal goes beyond the current text in GL3.1 that only refers to a requirement that the ASPSP “should provide to its CA a plan for publication…”.
We also want to highlight the lack of any explicit CA guidance in the Guidelines to check for themselves that the ASPSP dedicated interface matches the highest levels of availability/performance of the best performing ASPSP direct PSU access interface. Rationale clause 24 references such an ambition; however, it does not appear on any of the Guidelines. We would encourage the EBA to provide such guidance to CAs in the main GLs; CAs can use a number of methods (e.g. periodic random/targeted testing of an ASPSP interface by an independent 3rd party) to carry out such checks.
Question 2: Do you agree with the EBA’s assessments on stress testing and the options it considered and progressed or discarded, and the requirements proposed in Guideline 4? If not, please provide your reasoning.
We support the EBA request (in GL 4.1) that ASPSPs should have in place processes to stress-test the performance and availability of the dedicated TPP access interface. We propose that the EBA expands this request and ask ASPSPs to make available an Overview of such interface stress-testing processes to the relevant CA.GL 4.2 would benefit from additional clarity on (i) the duration of any stress-testing exercise and (ii) the definition of “unusually high numbers of requests” and “extremely high number of concurrent sessions”.
We believe that Guideline 4.3 should be expanded to require ASPSPs to provide to the relevant CA a summary of the stress test results of all its access interfaces. A CA could use the PSU access interface stress test results to benchmark the performance of the dedicated interface across a range of stress test scenarios (concurrent access sessions, multiple service requests etc.).
Question 3: Do you agree with the EBA’s assessments on monitoring? If not, please provide your reasoning.
The EMA challenges the reasoning detailed in Rationale Clause 31 of the consultation paper (CP) that appears to dilute CA responsibility articulated in RTS Art. 32(2) which stated that “Those interfaces, indicators and targets shall be monitored by the competent authorities ….”. In our view, the CA monitoring of the quarterly publication of access interface statistical data is not an adequate proxy for the CA responsibility detailed in RTS Art. 32(2).We also note that Rationale Clause 31 of the CP refers to a CA responsibility to “monitor KPIs”; Rationale Clause 32 also appears to point to a risk-based approach of indirect monitoring of such KPIs by CAs. We would propose that CAs carry out monitoring of ASPSP interfaces, indicators and targets on a risk-adjusted (and/or targeted basis) using an independent 3rd party as part of the review process of an exemption application for a dedicated interface. Such an approach would be better aligned with the CA responsibility detailed in RTS Art. 33(2).
Question 4: Do you agree with the EBA’s assessments on obstacles, the options it considered and progressed or discarded, and the requirements proposed in Guideline 5? If not, please provide your reasoning.
EMA members challenge the interpretation of the obstacles to the provision of TPP services - detailed in RTS Art. 32(3) – that is put forward in Rationale Clauses 34/35. Specifically, the statement in Clause 35 that “… redirection is not in itself an obstacle” when Redirection is explicitly listed as an obstacle in in RTS Art 32(3). The RTS text lists the imposition of a redirection as an example of an obstacle among three other types of obstacles in a non-exhaustive list (“Such obstacles, may include, among others…”). The EBA appears to accept that all other items in that list (preventing the TPP use of PSCs issued by the ASPSP, requiring additional TPP authorisations and registrations, requiring additional checks of the PSU consent granted to the TPP) constitute obstacles. In that context, it is difficult to reconcile the EBA reasoning that the imposition of Redirection does not constitute an obstacle, itself.The imposition of the use of redirection - as the sole PSU authentication procedure supported by the dedicated interface – will also obstruct the use of TPP-serviced devices such as POS terminals, smart watches or voice automation and hinder further service innovation in this area. Therefore, we propose that the use of redirection is not considered an obstacle to the provision of TPP services only if it is one of multiple customer authentication procedures supported over the dedicated interface.
We support the requirement that ASPSPs provide a confirmation that the dedicated access interface does not require any additional checks of the PSU consent extended to authorised TPPs.
We propose that the EBA add an additional requirement to GL 5.1 requiring ASPSPs to provide information to the CA to support their claim that “the IT solution for the dedicated interface and its implementation do not give rise to unnecessary delay, friction or any other attributes that would mean that payment service users are directly or indirectly dissuaded from using the services of PISPs, AISPs and CBPIIs” [GL 5.2(d)]. The relevant CA should review such information as part of the exemption assessment process.
We would encourage the EBA to align the language that appears in Rationale Clause 35 that references “friction, delay or unnecessary steps that would directly or indirectly dissuade PSUs” with the language in GL 5.2(d); the reference to unnecessary steps should be introduced to this Guideline.
Overall, we encourage the EBA to consider feature parity -between the dedicated TPP interface and all PSU direct access channels deployed by an ASPSP – as a component of the CA process of assessing whether an ASPSP dedicated interface creates obstacles in the delivery of TPP services. TPPs expect that the dedicated interface will deliver such feature parity (on capabilities, availability, user experience and overall performance) to match the PSU direct access channels.
Question 5: Do you agree with the EBA’s assessments for design and testing, the options it considered and progressed or discarded, and the requirements proposed Guideline 6? If not, please provide your reasoning.
The EMA is concerned about the apparent dilution of the TPP ability to indicate their satisfaction (or lack of) with the design & testing of a dedicated access interface that receives an exemption. In our view, the RTS on SCA and CSC [in Art. 33(6)b and Art.30(5)] affords TPPs an opportunity to provide such feedback to the CA during the exemption assessment process. GL6 does not include any reference to TPP feedback on the design and testing of a dedicated interface that will be sought by the CA. We propose that GL 6.3 is expanded to (a) include TPP feedback collected by the ASPSP during the testing process and (b) provide guidance to CAs to consider direct TPP feedback they receive on the design and testing of a dedicated interface.We believe that GL6.3 would benefit from additional clarity on the scope of test results submitted to the relevant CA; the minimum duration of such testing should be identified.
It is not clear to us how CAs will interpret GL 6.4; a number of account access API standardization initiatives do not provide conformance testing for individual implementations. Therefore, an ASPSP may claim that its dedicated interface “complies” with an API standard even though there may be significant instances of divergence. We would encourage the EBA to provide guidance to CAs that ASPSPs – that claim compliance of their dedicated interface with an API standard – are requested to demonstrate such compliance.
GL 6.5 lacks specific guidance on the scope of engagement with TPPs - during the design/testing phase of the dedicated interface - that an ASPSP is requested to demonstrate. We propose that CAs seek to review evidence of (i) TPP feedback in the interface design & testing process and of (ii) ASPSP willingness to consider TPP feedback and address TPP concerns.
Question 6: Do you agree with the EBA’s assessment for ‘widely used’, the options it considered and discarded, and the requirements proposed Guideline 7? If not, please provide your reasoning.
We believe that the alternative to the “widely used” condition in the RTS that is put forward by the EBA in GL 7.2 (“interface public and available for wide usage”) is not an appropriate proxy. The existing CA guidance in GL 7.2 does not identify any role for TPPs to communicate concerns on issues that may have impeded their ability to use the testing facility of the dedicated interface for a given ASPSP; such concerns may relate to the quality of the interface documentation, the quality/scope of TPP integration support, the quality of the testing facility and of the test interface itself. The current text in GL7 diminishes the role afforded to TPPs to comment on their satisfaction in the design and testing of a dedicated interface as detailed in RTS Art. 33(5)(b) and Art. 30(5). We are also concerned that the examples of evidence of an “interface public and available for wide usage” that are listed in GL 7.2 are qualitative and will be interpreted in an inconsistent manner by CAs.In this context, we propose that GL 7.1 is expanded to require ASPSPs to identify the total number of TPPs that have received access to the full interface documentation. We invite the EBA to instruct CAs to structure the exemption assessment process to consider (i) any significant discrepancies in the number of TPPs that have received access to the interface specification vs. the number of TPPs that use the interface and (ii) TPP feedback that is provided by any TPP that has received access to the specification.
We note that there is some missing text in the wording of GL 7.1(a) -> “the total number of PISPs, CBPIIs, AISPs that have xxxxxxx or have applied for the relevant authorisation that have made use of the testing facility”; we presume the missing text refers to “received authorization”.
Overall, we acknowledge the EBA concern that a number of ASPSPs may not be able to meet the original “widely used” condition in the RTS because of a lack of interest by TPPs to use a dedicated interface. Our concern is that the dilution of the original RTS condition may allow dedicated interfaces that offer a sub-optimal TPP payment account access to receive an exemption. Therefore, rather than seek to dilute the original RTS condition, we propose that the EBA confirms that ASPSPs that cannot meet this condition will be required to build the contingency mechanism referenced in RTS Art. 33(4). The limited amount of additional effort that ASPSPs are expected to expend to deploy the contingency mechanism (less than two months according to RTS Art. 33(7)) would be an equitable cost to incur to ensure the uninterrupted delivery of the services of the TPPs that attempt to access the payment accounts of ASPSPs. This approach to the dedicated interface exemption assessment process would align with the spirit and the letter of PSD2 and of the RTS on SCA and CSC.
Question 7: Do you agree with the EBAs assessment to use the service level targets and statistical data for the assessment of resolving problems without undue delay, the options it discarded, and the requirements proposed Guideline 8? If not, please provide your reasoning.
We support the EBA rationale underpinning the requirement for ASPSPs to provide information on their fault/error resolution processes for the dedicated interface detailed in Rationale Clause 62. However, we are concerned that GL 8.1 does not fully reflect the ASPSP requirements detailed in the Rationale.Specifically, GL8.1 does not require ASPSPs to provide any (a) volume-based data for problems that have not been resolved without “undue delay” or (b) to identify the extent of such delays. We propose that GL 8.1 is extended to require ASPSPs to provide such data.
Furthermore, we propose that ASPSPs are required to publish comparative statistics on their error resolution performance for errors of the same severity across all access interfaces as part of the set of published performance indicators (see our earlier Comment under Question 1, above). CAs should be instructed to assess the impact of wide discrepancies in the error resolution capacity of an ASPSP across the payment account access channels it exposes (PSU direct access, dedicated interface) as part of the ongoing compliance assessment process outlined in RTS Art 30(6) and Art. 33(7).
Question 8: Do you agree with the proposed Guideline 9 and the information submitted to the EBA in the Assessment Form in the Annex? If not, please provide your reasoning.
We support the pragmatic exemption assessment approach described in GL9. We note the derogation process that is detailed in GL9.3 to allow CAs to manage the expected high workload of exemption requests that will be submitted in the runup to the application of the RTS.We expect that the pragmatic approach described in GL9 will not lead to any decrease in the quality of the exemption assessment process that is carried out by EEA CAs in the transitional period ending on the 31st December 2019. A number of EMA members are keen to ensure that CAs only award contingency mechanism exemptions to dedicated interfaces that meet all regulatory compliance requirements detailed in PSD2 and in relevant Regulatory Technical Standards. In this context, we encourage the EBA to provide further guidance and support to CAs to ensure the performance of exemption assessment reviews in a consistent manner.
We wish to highlight our earlier concern stated under Q.6 above that CAs should not seek to dilute any of the original exemption conditions – detailed in RTS Art. 33(6) – in the name of expediency. An ASPSP - whose dedicated interfaces cannot satisfy all exemption qualifying conditions – should be required to deploy the contingency mechanism outlined in RTS Art. 33(4).
The EMA would also like to ask for further clarity on the topic of Passporting of Exemptions granted to ASPSPs using a specific dedicated TPP access interface in multiple jurisdictions.
Question 9: Do you have any particular concerns regarding the envisaged timelines for ASPSPs to meet the requirements set out in these Guidelines prior to the September 2019 deadline, including providing the technical specifications and testing facilities in advance of the March 2019 deadline?
We note the compressed timelines that ASPSPs must meet to benefit from the exemptions detailed in RTS Art. 33(6). Specifically, the requirement to make available the interface technical specification and the interface testing facility by March 2019 has introduced significant resource overheads for many ASPSPs. There is some concern that CAs may not be able to receive/process exemption applications earlier than March 2019; this will further delay/disrupt the interface deployment process and limit the ASPSP ability to address CA comments raised during the exemption assessment process.The EMA would encourage the EBA to ensure that all EEA CAs are able to receive/process exemption applications as soon as possible. We also invite the EBA to provide guidance to CAs on the treatment of exemption applications that are still pending at the start of the application of the RTS (14th September 2019).
We also want to highlight the fact that the EBA review of the industry responses to these GLs and the generation of the final Guidelines will be taking place in parallel with national PSD2 implementation consultations run by several CAs in the run up to the start of the application of the RTS. We believe that the industry would benefit from (i) early publication of the final version of these Guidelines and (ii) EBA efforts to co-ordinate the consistent implementation of the exemption assessment process by the CAs that adopt the Guidelines.
Question 10: Do you agree with the level of detail set out in the draft Guidelines as proposed in this Consultation Paper or would you have expected either more or less detailed requirements on a particular aspect? Please provide your reasoning.
The majority of the requirements proposed in these Guidelines are stated at the appropriate level of detail.We would have expected additional clarity on the role/process for TPPs to communicate their concerns & feedback on a dedicated interface to the relevant CA as part of the exemption assessment process. Instead, the draft GLs adopt a process where ASPSPs declare and self-certify the characteristics of the dedicated interface and submit these to the CA. Our view is that this approach diminishes the role of the TPP as a user/consumer of the interface that is explicitly referenced in the RTS [Art. 33(6)b/c].
We would also expect more explicit guidance provided to CAs on their independent review & monitoring of published interface service level objectives.
Separately, we would welcome more clarity from the EBA on the mechanics of the exemption revocation process and the payment account access options afforded to TPPs during the transitional 2-month period detailed in RTS Art. 33(7).