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
In general, the EPC would like to request further clarity concerning the scope of Guidelines 2.3 and 2.4 in light of Guidelines 2.2 and 3.1.a (i.e. all interfaces versus only the dedicated interface).
The EPC’s understanding is that an ASPSP can only start counting the seconds (in relation to the defined “down time”, i.e. 5 times 30 seconds), as soon as it has received a request and hence network transit time or related issues should be excluded as an ASPSP cannot measure a request that it has not yet received. Moreover, it should be noted that the good functioning of the ASPSP’s dedicated interface cannot be confirmed in the following cases:
- A request could not be taken into account by the ASPSP because it was blocked or deleted at transmission level through the IP technical layer (router). If a message containing a request cannot be transmitted by the router, the message is deleted without capability for the ASPSP to detect the problem (given that no information is provided by the router);
- If the TPP’s or the ASPSP’s ISP (Internet service provider) is down, the TPP request cannot reach the ASPSP, even if the API is working well.
It should be noted that the fact that the maximum number of seconds (as defined in the KPI) has been reached or exceeded, can in itself not be seen as a confirmation but only as a presumption (as stated in Article 33(1) of the 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 (hereafter referred to as the “RTS”)) that the ASPSP’s dedicated interface is down. (Note: For example, websites such as ”downforeveryoneorjustme.com” indicate if a website is down or not). More concretely, how to apply Guideline 2.4.a in conjunction with Guideline 2.4.b is not clear.
The EPC would like to indicate that it is not possible to compare a new dedicated interface with the long-existing PSU interfaces until after a sufficient level of experience and usage with the dedicated interface has been reached. Moreover, it should be noted that each ASPSP channel/segment has its own service level agreement (SLA)/KPI, therefore the comparison of the API performance can be done only with the PSU interface for the same channel/segment.
The EPC is also of the view that there can only be a straight comparison between how much time a payment transfer takes on the ASPSP’s website or app versus how long it takes via the PISP. For CBPIIs there is no possible comparison point (as the service does not exist on ASPSPs’ websites or apps). For AIS straight comparability may also in some cases be challenging.
The measurement will need to be done on ASPSP server side, not involving the client network time.
In the case of an ASPSP (group) operating in multiple countries but with a single, centrally operated dedicated interface the measurement of KPIs should be done at that central level.
Whilst acknowledging the provisions of Guideline 4.2.b on stress testing (subject to some comments – see below under Question 2), the EPC wishes to draw the EBA’s attention to the fact that the response time per request may significantly vary depending on the number of accounts, payment orders and volume of information requested.
Finally, it is the EPC’s opinion that each PSP can only be held responsible for the performance and availability of its own domain, with the ASPSP being solely responsible for the performance and availability of its dedicated interface.
Guideline 3: Publication of Indicators
The EPC would like to note that Guideline 3.1.b on the one hand goes beyond the requirements of the RTS and on the other hand overlooks the fact that performance and availability must be compared channel by channel as already mentioned above. Therefore, the EPC recommends removing Guideline 3.1.b.
The EPC is also of the view that quarterly figures and averages would suffice (i.e. without the need for a breakdown into daily figures). Moreover, the RTS (Article 32(4)) do not require the reporting of daily statistics. The EPC furthermore believes that the impact of providing daily figures is disproportionate to the value of the added detail.
Further clarification would also be needed in relation to Rationale 28 and Guidelines 4.2 b, c, d as there is currently no reference in relation to what is meant with “unusually high numbers of requests”, “extremely high number of concurrent sessions” and “large volumes of data” and hence these statements are rather subjective. The EPC believes that this should be covered in the existing Business Continuity Management (BCM) stress testing frameworks and implementation of the ASPSPs. ASPSPs have to deliver to the TPPs the same level of service that they deliver to their clients on their websites or apps and hence the EPC suggests that in relation to the measurement of volumes, the reference would be based on an API which has the capability of processing the same volume of requests and payment transfers than currently is the case on the ASPSP’s website or app (on an annual basis and at peak time). The EPC proposes to amend Guideline 4.2 b, c, d in line with the above.
The EPC would suggest amending the Guideline 4.3 sentence as follows: “The ASPSP should provide to the competent authority a summary of the results of the stress testing, including how the weaknesses identified during the testing period have been solved”.
Guideline 6.2: The EPC agrees that from an operational and security point of view, the testing environment has to be completely in line with the complete specifications and requirements of the production version of the API. Also, clause b. mentions the ability to exchange certificates for electronic seals AND qualified web authentication certificates whereas Article 34 of the RTS states that “payment service providers shall rely on qualified certificates for electronic seals as referred to in Article 3(30) of Regulation (EU) No 910/2014 OR for website authentication as referred to in Article 3(39) of that Regulation”.
Guideline 6.3: The weaknesses could be reported during the testing period by the TPPs or the ASPSP testing teams. The EPC hence suggests amending the sentence as follows: “The ASPSP should provide to the competent authority a summary of the results of the testing for the above, including how the weaknesses identified during the usage of the testing period have been solved”.
The EPC is of the view that the overall authorisation process of TPPs should be clarified by the Competent Authorities, with a specific regard to the case of authorisation revocation.
Rationale 47: It is not clear for the EPC how the ASPSP could differentiate ‘genuine’ from ‘fake’ acknowledgements of application.
Rationale 58 states that the PISPs/AISPs/CBPIIs are not obliged to undertake tests for the dedicated interfaces of ASPSPs. While it is acknowledged that the RTS did not include such obligation, it is suggested that the Guidelines recommend explicitly such testing on the side of PISP/AIPS/CBPIIs, in order not to adversely impact the PSU’s experience with the PISPs/AISPs/CBPIIs and therefore the connection with the ASPSP. Moreover, it is not clear what is meant with “engagement” in Guideline 6.5. The EPC would hence suggest to replicate the wording from Rationale 59.
In the case of an ASPSP (group) operating in multiple countries but with a single, centrally operated dedicated interface it would be more efficient - both for the ASPSP and for the Competent Authorities concerned (and EBA) - not having to go through multiple Competent Authorities for exemption and compliance monitoring purposes but rather through the Competent Authority of e.g. the ASPSP’s home Member State.
Also, the EPC would require further clarity on whether the exemption - granted by the Competent Authority to the ASPSP - covers all services (AIS/PIS/CBPII) together or only each specific service individually (e.g. PIS). For example, if an exemption would cover all services and it turns out that the dedicated interface does not meet the requirements for PIS, but still does for AIS and CBPII, the EPC understands that the exemption would be revoked only for PIS.
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.
Guideline 2: Service level, availability and performanceIn general, the EPC would like to request further clarity concerning the scope of Guidelines 2.3 and 2.4 in light of Guidelines 2.2 and 3.1.a (i.e. all interfaces versus only the dedicated interface).
The EPC’s understanding is that an ASPSP can only start counting the seconds (in relation to the defined “down time”, i.e. 5 times 30 seconds), as soon as it has received a request and hence network transit time or related issues should be excluded as an ASPSP cannot measure a request that it has not yet received. Moreover, it should be noted that the good functioning of the ASPSP’s dedicated interface cannot be confirmed in the following cases:
- A request could not be taken into account by the ASPSP because it was blocked or deleted at transmission level through the IP technical layer (router). If a message containing a request cannot be transmitted by the router, the message is deleted without capability for the ASPSP to detect the problem (given that no information is provided by the router);
- If the TPP’s or the ASPSP’s ISP (Internet service provider) is down, the TPP request cannot reach the ASPSP, even if the API is working well.
It should be noted that the fact that the maximum number of seconds (as defined in the KPI) has been reached or exceeded, can in itself not be seen as a confirmation but only as a presumption (as stated in Article 33(1) of the 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 (hereafter referred to as the “RTS”)) that the ASPSP’s dedicated interface is down. (Note: For example, websites such as ”downforeveryoneorjustme.com” indicate if a website is down or not). More concretely, how to apply Guideline 2.4.a in conjunction with Guideline 2.4.b is not clear.
The EPC would like to indicate that it is not possible to compare a new dedicated interface with the long-existing PSU interfaces until after a sufficient level of experience and usage with the dedicated interface has been reached. Moreover, it should be noted that each ASPSP channel/segment has its own service level agreement (SLA)/KPI, therefore the comparison of the API performance can be done only with the PSU interface for the same channel/segment.
The EPC is also of the view that there can only be a straight comparison between how much time a payment transfer takes on the ASPSP’s website or app versus how long it takes via the PISP. For CBPIIs there is no possible comparison point (as the service does not exist on ASPSPs’ websites or apps). For AIS straight comparability may also in some cases be challenging.
The measurement will need to be done on ASPSP server side, not involving the client network time.
In the case of an ASPSP (group) operating in multiple countries but with a single, centrally operated dedicated interface the measurement of KPIs should be done at that central level.
Whilst acknowledging the provisions of Guideline 4.2.b on stress testing (subject to some comments – see below under Question 2), the EPC wishes to draw the EBA’s attention to the fact that the response time per request may significantly vary depending on the number of accounts, payment orders and volume of information requested.
Finally, it is the EPC’s opinion that each PSP can only be held responsible for the performance and availability of its own domain, with the ASPSP being solely responsible for the performance and availability of its dedicated interface.
Guideline 3: Publication of Indicators
The EPC would like to note that Guideline 3.1.b on the one hand goes beyond the requirements of the RTS and on the other hand overlooks the fact that performance and availability must be compared channel by channel as already mentioned above. Therefore, the EPC recommends removing Guideline 3.1.b.
The EPC is also of the view that quarterly figures and averages would suffice (i.e. without the need for a breakdown into daily figures). Moreover, the RTS (Article 32(4)) do not require the reporting of daily statistics. The EPC furthermore believes that the impact of providing daily figures is disproportionate to the value of the added detail.
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.
In general, the EPC agrees with the EBA proposal although it would be beneficial to get further clarification on whether there are specific requirements for the execution of stress tests. The EPC is of the view that stress tests should only be conducted by the ASPSP to obtain a fallback exemption or to reactivate it in case it was revoked.Further clarification would also be needed in relation to Rationale 28 and Guidelines 4.2 b, c, d as there is currently no reference in relation to what is meant with “unusually high numbers of requests”, “extremely high number of concurrent sessions” and “large volumes of data” and hence these statements are rather subjective. The EPC believes that this should be covered in the existing Business Continuity Management (BCM) stress testing frameworks and implementation of the ASPSPs. ASPSPs have to deliver to the TPPs the same level of service that they deliver to their clients on their websites or apps and hence the EPC suggests that in relation to the measurement of volumes, the reference would be based on an API which has the capability of processing the same volume of requests and payment transfers than currently is the case on the ASPSP’s website or app (on an annual basis and at peak time). The EPC proposes to amend Guideline 4.2 b, c, d in line with the above.
The EPC would suggest amending the Guideline 4.3 sentence as follows: “The ASPSP should provide to the competent authority a summary of the results of the stress testing, including how the weaknesses identified during the testing period have been solved”.
Question 3: Do you agree with the EBA’s assessments on monitoring? If not, please provide your reasoning.
The EPC is of the view that this corresponds with the usual business practice of PSPs and that monitoring should be limited to compliance. Moreover, the EPC’s interpretation is that monitoring by the Competent Authority does not influence the requirements for granting or maintaining an exemption to an ASPSP.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.
The EPC would like to point out that according to requirement 9.3 of the Guidelines on security measures for operational and security risk under PSD2, a PSU can disable specific payment functionalities. In the EPC’s opinion this qualifies as a legitimate action by the PSU, which the PSU will have to reverse before consent can be accepted by the ASPSP for a payment using this specific (by the PSU disabled) payment functionality. The EPC is moreover of the view that this cannot be seen as an obstacle as long as the disablement is explicitly activated by the PSU.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.
Guideline 6.1: the EPC agrees on the fact that only a summary of the dedicated interface specifications would need to be published on the ASPSP’s website, in line with Article 30(3) of the RTS.Guideline 6.2: The EPC agrees that from an operational and security point of view, the testing environment has to be completely in line with the complete specifications and requirements of the production version of the API. Also, clause b. mentions the ability to exchange certificates for electronic seals AND qualified web authentication certificates whereas Article 34 of the RTS states that “payment service providers shall rely on qualified certificates for electronic seals as referred to in Article 3(30) of Regulation (EU) No 910/2014 OR for website authentication as referred to in Article 3(39) of that Regulation”.
Guideline 6.3: The weaknesses could be reported during the testing period by the TPPs or the ASPSP testing teams. The EPC hence suggests amending the sentence as follows: “The ASPSP should provide to the competent authority a summary of the results of the testing for the above, including how the weaknesses identified during the usage of the testing period have been solved”.
The EPC is of the view that the overall authorisation process of TPPs should be clarified by the Competent Authorities, with a specific regard to the case of authorisation revocation.
Rationale 47: It is not clear for the EPC how the ASPSP could differentiate ‘genuine’ from ‘fake’ acknowledgements of application.
Rationale 58 states that the PISPs/AISPs/CBPIIs are not obliged to undertake tests for the dedicated interfaces of ASPSPs. While it is acknowledged that the RTS did not include such obligation, it is suggested that the Guidelines recommend explicitly such testing on the side of PISP/AIPS/CBPIIs, in order not to adversely impact the PSU’s experience with the PISPs/AISPs/CBPIIs and therefore the connection with the ASPSP. Moreover, it is not clear what is meant with “engagement” in Guideline 6.5. The EPC would hence suggest to replicate the wording from Rationale 59.
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.
In relation to Guideline 7.2 (communication efforts launched by ASPSPs to inform the market on the availability of the testing facilities), the EPC would suggest it is clarified that the evidence the ASPSPs are mandatorily requested to provide is limited to publications on the ASPSPs’ websites while other means such as social media are included just as examples of what an ASPSP, in its full discretion and according to its customary policies, may also wish to do.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.
The EPC agrees to the extent that this is a common supervisory practice.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.
The EPC supports the pragmatic approach in the interest of a good customer journey and in view of the importance of the speed of implementation.In the case of an ASPSP (group) operating in multiple countries but with a single, centrally operated dedicated interface it would be more efficient - both for the ASPSP and for the Competent Authorities concerned (and EBA) - not having to go through multiple Competent Authorities for exemption and compliance monitoring purposes but rather through the Competent Authority of e.g. the ASPSP’s home Member State.
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?
The EPC acknowledges the envisaged timelines for ASPSPs to meet the requirements set out in these Guidelines prior to the September 2019 deadline. The EPC would however like to stress that the time available for ASPSPs to adapt their dedicated interfaces to the final version of these Guidelines might be challenging. Indeed, the publication time of the final version of these Guidelines is still uncertain since the EBA will certainly need some time to process all the feedback received following the public consultation. In addition, these Guidelines should be implemented by the Competent Authorities, which could also introduce specific changes that might require further steps, as well as possible differences in interpretations in the various Member States. All these circumstances might result in a very limited time available for ASPSPs to adapt their interfaces for exemption purposes.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.
For the most part the EPC believes that the level of detail is sufficient. The EPC would however have expected more information about the timeline to deliver the exemption approval. The EPC hence proposes that the application may be submitted during the three-month period referred to in Article 33(6)(c) of the RTS, so that it can be provided no later than directly after that 3-month “widely used” period. This would be essential in view of the tight schedule.Also, the EPC would require further clarity on whether the exemption - granted by the Competent Authority to the ASPSP - covers all services (AIS/PIS/CBPII) together or only each specific service individually (e.g. PIS). For example, if an exemption would cover all services and it turns out that the dedicated interface does not meet the requirements for PIS, but still does for AIS and CBPII, the EPC understands that the exemption would be revoked only for PIS.