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
ABA is clear that ASPSPs will designate their dedicated interface as a critical business process as they already do for the customer interface/proprietary channel. Therefore, the dedicated interface will be subject to the same high standards of uptime and availability as an online banking interface. Key Performance Indicators (KPIs) to monitor the performance of the dedicated interface will not necessarily match with the KPIs currently in use to monitor the availability and performance of Payment Service User (PSU) channels (eg online banking) as provided by an ASPSP.
Paragraph 21: with regards to the concept of ‘accuracy of information provided’ it should be clarified that the concept refers to the accuracy of KPIs.
Paragraph 24: comparison of availability and performance should be at channel level i.e. the channel chosen by the client. It is not appropriate to compare the API availability and performance with the best performing PSU interface, because:
o By definition, a mobile banking interface will usually have a different access scope compared to the fully-fledged online banking interface. The first might allow only a limited access to the account and to limited types of transactions considered more appropriated for the user compared to the full online banking interface
o Service levels and availabilities for interfaces differ by client profile based on customer’s targets and individual service level agreements – this is specifically the case for commercial clients
As a result, whilst the two should be separated and monitored separately, we propose that this is taken into account in the monitoring approach adopted by ASPSPs. This will allow ASPSPs to achieve comparable performances between the dedicated interface and PSU channels but only after a considerable usage period of the dedicated interface. Each ASPSP channel/segment has its own SLA/KPI, therefore the comparison of the API performance can be done only with the specific channel/segment which should be selected by the ASPSP based on the brand/channel.
If the EBA would like to specify high-level metrics which could be applies across the industry, ABA suggest the following:
• Number of critical impacts and incidents, (outage based on a monthly figure) underpinned by a series of service levels including serviceability (unplanned disruption), availability (planned service disruption), the service support
• Number of critical impacts longer than 120 minutes
• Total outage time as regards incidents
• Mean recovery time as regards incidents
Performance service levels such as page load time targets, sign off/sign on targets.
In addition to that, some modifications are to be considered to improve the practical implementation of the Guidelines:
Guideline 2.3: We agree with the proposed guidelines, which are in line with the Opinion on the RTS. Also, we understand that when confirmation of funds via yes/no message cannot be provided by the ASPSP, the additional information to be provided are limited only to what is needed for the execution of the payment. Allowing access to any other data would be against requirements on data minimisation or consent.
Guideline 2.4.:
• The service level should be measured over a longer time period, for example, averaged over a month, rather than each 24-hour period, to provide a more reliable metric.
• The reference time period is important to ensure that the dedicated interface is subject to high standard, and possible “underperformance” is not triggered inappropriately or unnecessarily, particularly taking into account the reality of unexpected downtime. Unexpected downtime could possibly affect the dedicated and user interfaces at different moments (i.e. in different 24-hour periods). In such case the dedicated interface could register “under-performing” metrics in a 24-hour period while it could even significantly exceed the user interface service levels over a longer time horizon. The use of a longer time average in Article 2.4(a) of the Guidelines instead of 24 hours, would implement a high threshold for the dedicated interface but reduce the number of “false positives”.
• Therefore, we suggest amending the guidelines according to the following proposal “a. calculate the percentage planned and unplanned downtime by using the total number of seconds the dedicated interface was down in a period of one month starting and ending on day one of each month at midnight”. Also, planned downtimes should not be considered in 2.4.b and c.
• There is also a need to ensure that any form of manipulation where for instance an external party has deliberately overloaded an API, this should be included in the unplanned downtime parameter in both 2.2(c) and 2.4(b).
• Likewise, if a request if blocked or deleted at transmission level due to IP technical problem or internet provider problem, the performance of the ASPS dedicated interface cannot be questioned
• In line with the service level targets measurement, the dedicated interface should be calculated as an average" performance value.
Guideline 3:
• We would like to express our concerns regarding the publication of service level information on all an ASPSP’s other user interfaces. This information is sensitive as reveals competitive information and should not be publicly available. The publication of absolute value statistics would allow a comparison of the performance of each ASPSP towards its customers, which is not only commercially sensitive, but would also favour cyberattacks. If a bank would be exposed to, for instance, a Distributed Denial of Service (DDoS) attack; the effects of such an attack would then be included in the publication, potentially putting at risk the cybersecurity infrastructure of the bank. The institutions behind the attack are then able to evaluate the success of their actions and adapt their processes thereafter.
• Additionally, such requirement would also go beyond the scope and spirit of the RTS, whose aim is to allow NCAs to assess whether the performance of the dedicated interfaces towards TPs is equivalent to the user interface, and not to disclose the relationship between ASPS and their clients.
• Also, the definition of “down” for the user interface is not clearly defined and there are likely to be substantial differences in interpretation among different ASPSPs, which could generate confusion and inappropriate comparisons. For example, some ASPSPs might consider their user interface to be “down” if one particular functionality is not working, while another may only define their interface as down if the entire system is offline.
• We would therefore suggest publishing percentage values comparing the availability of the user interface and the dedicated interface
• As a result, ASPSP’s should only be obliged to report service level information on their dedicated interface to their Competent Authority ex post, together with the reporting of the other relevant service levels, permitting Authorities to confirm their compliance with the RTS and Guidelines.
• Therefore, we suggest amending the Guidelines according to the following proposal:
3.1 For the purpose of Article 32(4) of the RTS, the ASPSP should report to its competent authority:
a. percentage on a quarterly basis on availability and performance as set out in Guideline 2.2 and 2.3 for the dedicated interface and each payment service user interface together with information on where these percentage statistics will be published and the date of first publication. Access to further information shall be restricted to Comptetent Authorities; and
b. from the date of first reporting, informing the Authority of the comparison of the availability of its dedicated interface with its best performing the PSU interface"
• Guideline 5.1 a. refers to ‘method of access’ to address what the EBA opinion of 13 June refers instead to ‘authentication procedure’ as per the ‘methods of carrying out authentication procedure of the PSU trough a dedicated interface, and API in particular, namely redirection, embedded approach, and decoupled approach’. We suggest aligning the wording of the two texts to ensure legal certainty. Any further interpretation of such provisions should be left to Competent Authorities.
We would suggest using similar language in the Guidelines as in the Opinion, e.g. refer to: methods for carrying out the authentication procedure.
• Compliance Testing
• Load Testing
• Stress Testing
• Volume Testing
It allows for firms to either test themselves on a ‘self-attestation’ basis or for independent firms to review the testing. The ABA believes that this is the best solution for the entire market. We also believe that API initiatives should provide the tools or basis for this testing based on strong collaboration with the industry. A firm can then provide to the NCA their test results to gain an exemption
• Paragraph 52/53: It should be explicitly mentioned also in the text of the guidelines that testing is performed on a dedicated test environment for which service levels differ from production or live environment.
• It is worth mentioning that testing can only be done with registered/authorized TPPs or those that are in the process of getting a license/registration (Art. 30.5 RTS).Therefore ASPSPs should not be required to make available the testing facilities before an authorisation is granted, considering the resources that will be required for the testing on both sides. The requirements to publish and make available changes in the test environment before going to production applied to new products and innovations could severely impact the ability for an ASPSP to innovate, disrupting the level playing field if the intention that any innovation by the ASPSP must always be made available to all the TPP’s in the marketplace in advance of the actual introduction into the marketplace.
• Even the availability of the technical specifications before authorisation should be reconsidered to avoid unnecessary diffusion of elements that could result in a fraudulent behaviour or attempts from non-authorised PSPs to access customers’ payments accounts.
• Guideline 6.2 (f) : Please refer to our answer to question 1 regarding the yes/no confirmation.
• Guideline 6.4 and 6.5 : In principle, the market should gradually converge but these requirements go further than PSD2 obligations and enter the competition space. Therefore, it should be left free to individual ASPSPs.
• Guideline 7.1 : We would like to stress that to comply with guideline 7.1. certificates for the testing phase are needed.
• Guideline 7.2: We would suggest that the evidence the ASPSP are mandatory requested to provide is limited to publications on the ASPSPs’ websites or channels. The other ways of publicising their interfaces should clearly be indicated as further options left to the policy of each individual ASPSP.
• We are also of the view that it would be useful to have a unique EU registry / EBA website where PISP / AISP / CBPIIs could easily identify at European level all ASPSPs that are available for testing.
• Nevertheless, from our point of view, the mechanism to oppose a negative decision should also be described and harmonized by the Guidelines. There should be clear timelines for acknowledgement and response of the exemptions, especially given the short deadlines which are imposed on both NCAs and the industry.
• We would also welcome a clarification that ASPSPs who implement one API for TPP access across PSU interfaces in multiple countries or clients (e.g. retail vs corporate
customers) will only have to apply for the exemptions for that API once with the NCA in the Member States where it has its registered head office..
• Moreover, we would like to highlight that in point 66 it is stated “submit the form covering more than one ASPSP…”. In contrast, Guideline 9.3 says that an exemption can be granted “to one or more ASPSPs´”. These wordings are contradictive. The logical wording should be what is stated in point 66, i.e. the annex could be used if more than one ASPSP applies for an exemption.
• However, we are very concerned about the process and envisaged timelines for ASPSPs to develop an API and more specifically, the possibility for CAs to assess whether or not the ASPSP meet the requirements for an exemption according to article 33.6 in the RTS. Time is very short considering also that the PSD2 has not been transposed in all Member States yet and certificates are not in place (see ERPB statement), therefore that part of the dedicated interface cannot be finalised nor tested.
• An ASPSP must be ready to publish the documentation on their websites already in the beginning of 2019 to meet the deadline in September 2019. Moreover, it has to be questioned, at least at this stage, if the CAs has the capacity to assess the upcoming applications. There is still an uncertainty on the administration time for local CAs which makes it difficult to understand and take into account the timelines for applications. This is especially important as any rejected exemption application leads to the need for develop a fall-back solution in two months’ time.
Additionally we would like to stress that:
• the concept ‘accuracy of information provided’ should be further clarified
• There is need for certificates for the test phase in order to comply with the guidelines. The timing issue is pressing and of high concern.
• It should be clarified in the text that multi-country ASPSPs ask their home state NCA only for exemption
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.
Overall, the Austrian Bankers Association (ABA) is supportive of the EBA’s assessments on KPIs and the calculation of uptime and downtime, however, we have some comments in regard to some more technical level details.ABA is clear that ASPSPs will designate their dedicated interface as a critical business process as they already do for the customer interface/proprietary channel. Therefore, the dedicated interface will be subject to the same high standards of uptime and availability as an online banking interface. Key Performance Indicators (KPIs) to monitor the performance of the dedicated interface will not necessarily match with the KPIs currently in use to monitor the availability and performance of Payment Service User (PSU) channels (eg online banking) as provided by an ASPSP.
Paragraph 21: with regards to the concept of ‘accuracy of information provided’ it should be clarified that the concept refers to the accuracy of KPIs.
Paragraph 24: comparison of availability and performance should be at channel level i.e. the channel chosen by the client. It is not appropriate to compare the API availability and performance with the best performing PSU interface, because:
o By definition, a mobile banking interface will usually have a different access scope compared to the fully-fledged online banking interface. The first might allow only a limited access to the account and to limited types of transactions considered more appropriated for the user compared to the full online banking interface
o Service levels and availabilities for interfaces differ by client profile based on customer’s targets and individual service level agreements – this is specifically the case for commercial clients
As a result, whilst the two should be separated and monitored separately, we propose that this is taken into account in the monitoring approach adopted by ASPSPs. This will allow ASPSPs to achieve comparable performances between the dedicated interface and PSU channels but only after a considerable usage period of the dedicated interface. Each ASPSP channel/segment has its own SLA/KPI, therefore the comparison of the API performance can be done only with the specific channel/segment which should be selected by the ASPSP based on the brand/channel.
If the EBA would like to specify high-level metrics which could be applies across the industry, ABA suggest the following:
• Number of critical impacts and incidents, (outage based on a monthly figure) underpinned by a series of service levels including serviceability (unplanned disruption), availability (planned service disruption), the service support
• Number of critical impacts longer than 120 minutes
• Total outage time as regards incidents
• Mean recovery time as regards incidents
Performance service levels such as page load time targets, sign off/sign on targets.
In addition to that, some modifications are to be considered to improve the practical implementation of the Guidelines:
Guideline 2.3: We agree with the proposed guidelines, which are in line with the Opinion on the RTS. Also, we understand that when confirmation of funds via yes/no message cannot be provided by the ASPSP, the additional information to be provided are limited only to what is needed for the execution of the payment. Allowing access to any other data would be against requirements on data minimisation or consent.
Guideline 2.4.:
• The service level should be measured over a longer time period, for example, averaged over a month, rather than each 24-hour period, to provide a more reliable metric.
• The reference time period is important to ensure that the dedicated interface is subject to high standard, and possible “underperformance” is not triggered inappropriately or unnecessarily, particularly taking into account the reality of unexpected downtime. Unexpected downtime could possibly affect the dedicated and user interfaces at different moments (i.e. in different 24-hour periods). In such case the dedicated interface could register “under-performing” metrics in a 24-hour period while it could even significantly exceed the user interface service levels over a longer time horizon. The use of a longer time average in Article 2.4(a) of the Guidelines instead of 24 hours, would implement a high threshold for the dedicated interface but reduce the number of “false positives”.
• Therefore, we suggest amending the guidelines according to the following proposal “a. calculate the percentage planned and unplanned downtime by using the total number of seconds the dedicated interface was down in a period of one month starting and ending on day one of each month at midnight”. Also, planned downtimes should not be considered in 2.4.b and c.
• There is also a need to ensure that any form of manipulation where for instance an external party has deliberately overloaded an API, this should be included in the unplanned downtime parameter in both 2.2(c) and 2.4(b).
• Likewise, if a request if blocked or deleted at transmission level due to IP technical problem or internet provider problem, the performance of the ASPS dedicated interface cannot be questioned
• In line with the service level targets measurement, the dedicated interface should be calculated as an average" performance value.
Guideline 3:
• We would like to express our concerns regarding the publication of service level information on all an ASPSP’s other user interfaces. This information is sensitive as reveals competitive information and should not be publicly available. The publication of absolute value statistics would allow a comparison of the performance of each ASPSP towards its customers, which is not only commercially sensitive, but would also favour cyberattacks. If a bank would be exposed to, for instance, a Distributed Denial of Service (DDoS) attack; the effects of such an attack would then be included in the publication, potentially putting at risk the cybersecurity infrastructure of the bank. The institutions behind the attack are then able to evaluate the success of their actions and adapt their processes thereafter.
• Additionally, such requirement would also go beyond the scope and spirit of the RTS, whose aim is to allow NCAs to assess whether the performance of the dedicated interfaces towards TPs is equivalent to the user interface, and not to disclose the relationship between ASPS and their clients.
• Also, the definition of “down” for the user interface is not clearly defined and there are likely to be substantial differences in interpretation among different ASPSPs, which could generate confusion and inappropriate comparisons. For example, some ASPSPs might consider their user interface to be “down” if one particular functionality is not working, while another may only define their interface as down if the entire system is offline.
• We would therefore suggest publishing percentage values comparing the availability of the user interface and the dedicated interface
• As a result, ASPSP’s should only be obliged to report service level information on their dedicated interface to their Competent Authority ex post, together with the reporting of the other relevant service levels, permitting Authorities to confirm their compliance with the RTS and Guidelines.
• Therefore, we suggest amending the Guidelines according to the following proposal:
3.1 For the purpose of Article 32(4) of the RTS, the ASPSP should report to its competent authority:
a. percentage on a quarterly basis on availability and performance as set out in Guideline 2.2 and 2.3 for the dedicated interface and each payment service user interface together with information on where these percentage statistics will be published and the date of first publication. Access to further information shall be restricted to Comptetent Authorities; and
b. from the date of first reporting, informing the Authority of the comparison of the availability of its dedicated interface with its best performing the PSU interface"
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 agree with the proposal not to explicitly include testing such as security and penetration testing that is already part of an IT assessment.Question 3: Do you agree with the EBA’s assessments on monitoring? If not, please provide your reasoning.
We do agree with the assessment that monitoring by CAs cannot be considered a criterion for granting an exemption to an ASPSP and it should be limited to compliance.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 ABA welcomes the EBA’s clarification in regard to obstacles and agrees in principle with the EBA assessment, however we suggest the authentication terminology in the Guidelines to be reviewed to improve clarity and ensure consistency with the EBA Opinion. In particular, the ABA agrees with the EBA that ‘redirection’ is not in itself an obstacle. We are of the strong view that a well implemented dedicated interface which makes use of redirection is best for the customer, the ASPSP and the best way to encourage new market entrants to create AIS and PIS services.• Guideline 5.1 a. refers to ‘method of access’ to address what the EBA opinion of 13 June refers instead to ‘authentication procedure’ as per the ‘methods of carrying out authentication procedure of the PSU trough a dedicated interface, and API in particular, namely redirection, embedded approach, and decoupled approach’. We suggest aligning the wording of the two texts to ensure legal certainty. Any further interpretation of such provisions should be left to Competent Authorities.
We would suggest using similar language in the Guidelines as in the Opinion, e.g. refer to: methods for carrying out the authentication procedure.
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.
• We agree with the EBA’s assessments for design and testing. In order to achieve the underlying aims of PSD2, the RTS and the concept of ‘open banking’ in a broad sense, we strongly believe that a testing environment should be based on what is commonly called ‘conformance testing’, or ‘compliance testing’. Conformance testing verifies that a product performs according to its specified standards and is commonly used and determines whether a process, product, or services complies with the requirements of a specification, technical standard, contract, or regulation. Conformance Testing can be logical or physical, and it comprises following types of testing:• Compliance Testing
• Load Testing
• Stress Testing
• Volume Testing
It allows for firms to either test themselves on a ‘self-attestation’ basis or for independent firms to review the testing. The ABA believes that this is the best solution for the entire market. We also believe that API initiatives should provide the tools or basis for this testing based on strong collaboration with the industry. A firm can then provide to the NCA their test results to gain an exemption
• Paragraph 52/53: It should be explicitly mentioned also in the text of the guidelines that testing is performed on a dedicated test environment for which service levels differ from production or live environment.
• It is worth mentioning that testing can only be done with registered/authorized TPPs or those that are in the process of getting a license/registration (Art. 30.5 RTS).Therefore ASPSPs should not be required to make available the testing facilities before an authorisation is granted, considering the resources that will be required for the testing on both sides. The requirements to publish and make available changes in the test environment before going to production applied to new products and innovations could severely impact the ability for an ASPSP to innovate, disrupting the level playing field if the intention that any innovation by the ASPSP must always be made available to all the TPP’s in the marketplace in advance of the actual introduction into the marketplace.
• Even the availability of the technical specifications before authorisation should be reconsidered to avoid unnecessary diffusion of elements that could result in a fraudulent behaviour or attempts from non-authorised PSPs to access customers’ payments accounts.
• Guideline 6.2 (f) : Please refer to our answer to question 1 regarding the yes/no confirmation.
• Guideline 6.4 and 6.5 : In principle, the market should gradually converge but these requirements go further than PSD2 obligations and enter the competition space. Therefore, it should be left free to individual ASPSPs.
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.
• Paragraph 55-59: We support the EBA’s assessment that the requirement ‘widely used’ is difficult to assess prior to 14 Sept 2019 and also should be specific to each Member State. We welcome the alternative proposal for this specific period for ASPSPs to prove/document the measures taken to publicise and encourage testing and usage of the API. Whilst it is the intention of ASPSPs to have the API up for testing well in advance of the minimum testing period, it is clearly beyond an ASPSPs direct influence upon TPP to make use of this testing environment as well as production interface prior 14 Sept 2019.• Guideline 7.1 : We would like to stress that to comply with guideline 7.1. certificates for the testing phase are needed.
• Guideline 7.2: We would suggest that the evidence the ASPSP are mandatory requested to provide is limited to publications on the ASPSPs’ websites or channels. The other ways of publicising their interfaces should clearly be indicated as further options left to the policy of each individual ASPSP.
• We are also of the view that it would be useful to have a unique EU registry / EBA website where PISP / AISP / CBPIIs could easily identify at European level all ASPSPs that are available for testing.
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’s assessment that the condition of the sufficient resolution of problems is to be seen in the context of testing. However, documents supporting GL 8.1 should be part of the ASPSP’s application for exemption.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 EBA pragmatic approach and welcome the temporary provisions to ensure a timely processing of exemption requests prior to Sept 2019.• Nevertheless, from our point of view, the mechanism to oppose a negative decision should also be described and harmonized by the Guidelines. There should be clear timelines for acknowledgement and response of the exemptions, especially given the short deadlines which are imposed on both NCAs and the industry.
• We would also welcome a clarification that ASPSPs who implement one API for TPP access across PSU interfaces in multiple countries or clients (e.g. retail vs corporate
customers) will only have to apply for the exemptions for that API once with the NCA in the Member States where it has its registered head office..
• Moreover, we would like to highlight that in point 66 it is stated “submit the form covering more than one ASPSP…”. In contrast, Guideline 9.3 says that an exemption can be granted “to one or more ASPSPs´”. These wordings are contradictive. The logical wording should be what is stated in point 66, i.e. the annex could be used if more than one ASPSP applies for an exemption.
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 support the EBA definition of the envisaged timelines.• However, we are very concerned about the process and envisaged timelines for ASPSPs to develop an API and more specifically, the possibility for CAs to assess whether or not the ASPSP meet the requirements for an exemption according to article 33.6 in the RTS. Time is very short considering also that the PSD2 has not been transposed in all Member States yet and certificates are not in place (see ERPB statement), therefore that part of the dedicated interface cannot be finalised nor tested.
• An ASPSP must be ready to publish the documentation on their websites already in the beginning of 2019 to meet the deadline in September 2019. Moreover, it has to be questioned, at least at this stage, if the CAs has the capacity to assess the upcoming applications. There is still an uncertainty on the administration time for local CAs which makes it difficult to understand and take into account the timelines for applications. This is especially important as any rejected exemption application leads to the need for develop a fall-back solution in two months’ time.
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.
We agree with the overall level of detail.Additionally we would like to stress that:
• the concept ‘accuracy of information provided’ should be further clarified
• There is need for certificates for the test phase in order to comply with the guidelines. The timing issue is pressing and of high concern.
• It should be clarified in the text that multi-country ASPSPs ask their home state NCA only for exemption