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
We agree that the dedicated interface shall have the same service level objectives as the interface available to the PSU. It should however be noted that the service levels shall be measured at the ASPSPs endpoint level to make sure that any network disturbances between the ASPSPs endpoint and the TPP are not included in the calculation of downtimes. As a consequence, the guidelines must clarify that the counting of seconds towards downtime can only start as soon as the ASPSP has received the request from the TPP.
As a service level monitoring service only is capable of measuring whether a given response to a request is delivered in a timely manner, and with data present, the quality of the data is difficult to validate. Rationale 21 must clarify this; comparing response times and functionality between dedicated and PSU interfaces makes no sense as the interaction, flow and content may be quite different.
We agree to the formula for calculating uptime and downtime.
However, we are concerned that the definition of downtime may lead to different interpretations among ASPSPs and TPPs. According to RTS Article 33(1) the interface shall be regarded as “down” if five or more consecutive requests are not replied within 30 seconds. Does that mean that there is a 30 second timeout, or does it mean that the 5 consecutive requests must be within a 30 second period?
In GL 2 the period of calculating downtime is set for a 24-hour period, starting and ending at midnight. On a 24-hour basis, only a few seconds of downtime will impact the measured service levels. We suggest that service levels are calculated also at a monthly, or quarterly, basis to give a better picture of the total service-levels of the different interfaces and channels. Otherwise this may result in sub-optimisation of service level reporting with service level adjustments across interfaces.
Guideline 3
We are concerned that the publication of daily statistics may be used by hackers to identify the effect of network or application attacks, and hence to tailor the attacks that have most effect to the different endpoints. Based on this, and other competitive reasons, we suggest that the ASPSPs should not be obligated to publish their statistics openly, but make these available to the NCA’s only.
We find that the four types of stress testing described in section 4.2 in the consultation guidelines are relevant and should be sufficient to identify any bottle-necks in the ASPSPs IT-infrastructure.
However, we believe that there should be more detailed guidance for the EBA/NCA’s in terms of assessing the test results. The terms ‘multiple firms’, ‘unusually high numbers of requests….in a short period of time’, ‘extremely high number of concurrent sessions open’ and ‘requests for large volumes of data’ would for the individual ASPSP be relative to size (customer numbers, expected online traffic relative to customer numbers etc.).
The guidelines do not provide any guidance on the frequency of the ordinary stress testing or under which other circumstances the ASPSP should perform a stress test of their interface. We believe that the guidelines should provide a reference to ‘periodic’ stress testing as both the ASPSP IT-infrastructure and the number and complexity of the third-party providers will change over time.
The definition of an ‘obstacle’ must be something that differentiate the user experience in a negative way, introducing more friction or delays so that the PSUs find it more cumbersome to use the TPPs than the ASPSPs payment services directly. We believe that offering the exact same solutions and hence the same user experience to PSU for use via a TPP as the PSU is faced with in the ASPSP’s online services, will ensure a level playing field for all PSP’s regardless of their business model and relationship with the PSU. The most important principle is that the solution offered to the PSU via the TPP does not create any friction or delay for the PSU compared to the other access methods available directly from the ASPSP to the PSU.
For Norway, the understanding that the PSU’s security credentials should not be shared with the PSP is of vital importance. This is due to the vide usage of BankID among PSU’s - not only for banking services, but also for governmental and other public and private services. BankID is key for the digitalization of Norway. To continue to provide eID based services with BankID, BankID is required to become eIDAS compliant. According to eIDAS regulation, security credentials should not be shared – they should be ‘under the sole control’ of the PSU.
We also support that the EBA clarifies that introducing additional steps to verify the consent of the PSU or requiring TPP compliance with requirements not imposed by the legislation would be regarded as obstacles.
Finally, we would like to point out that any security measures under control of the PSU cannot be regarded as an obstacle. Examples of such security measures may be geo-blocking, spending limits for specific payment instruments or disabling of payment functionalities referred to in section 9.4 in Guidelines on security measures for operational and security risk under PSD2.
Especially on rationale 48 and 49 – design must be in line with legal requirements, and ‘to the satisfaction of the payment service providers’ – which will be close to impossible for CA’s to assess. Furthermore, impossible to handle in a harmonized way across Europe.
As for rationale 51 – we understand the reasoning for being concrete on mentioning the API EG as an organization to consider. When being as concrete as the EBA is in this matter, we believe that CA’s could benefit from even more concretization – e.g. alignment with standardization of dedicated interface initiatives, national stakeholder initiatives etc.
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 2We agree that the dedicated interface shall have the same service level objectives as the interface available to the PSU. It should however be noted that the service levels shall be measured at the ASPSPs endpoint level to make sure that any network disturbances between the ASPSPs endpoint and the TPP are not included in the calculation of downtimes. As a consequence, the guidelines must clarify that the counting of seconds towards downtime can only start as soon as the ASPSP has received the request from the TPP.
As a service level monitoring service only is capable of measuring whether a given response to a request is delivered in a timely manner, and with data present, the quality of the data is difficult to validate. Rationale 21 must clarify this; comparing response times and functionality between dedicated and PSU interfaces makes no sense as the interaction, flow and content may be quite different.
We agree to the formula for calculating uptime and downtime.
However, we are concerned that the definition of downtime may lead to different interpretations among ASPSPs and TPPs. According to RTS Article 33(1) the interface shall be regarded as “down” if five or more consecutive requests are not replied within 30 seconds. Does that mean that there is a 30 second timeout, or does it mean that the 5 consecutive requests must be within a 30 second period?
In GL 2 the period of calculating downtime is set for a 24-hour period, starting and ending at midnight. On a 24-hour basis, only a few seconds of downtime will impact the measured service levels. We suggest that service levels are calculated also at a monthly, or quarterly, basis to give a better picture of the total service-levels of the different interfaces and channels. Otherwise this may result in sub-optimisation of service level reporting with service level adjustments across interfaces.
Guideline 3
We are concerned that the publication of daily statistics may be used by hackers to identify the effect of network or application attacks, and hence to tailor the attacks that have most effect to the different endpoints. Based on this, and other competitive reasons, we suggest that the ASPSPs should not be obligated to publish their statistics openly, but make these available to the NCA’s only.
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.
Stress testing of the IT-systems is normal practice for banks offering online services to their customers. Independent of any requirements in the RTS, we believe that ASPSPs will perform stress tests to ensure that their systems are capable of handling high volumes. Hence, we fully agree that the responsibility for stress testing should be on the ASPSPs and not on the NCAs.We find that the four types of stress testing described in section 4.2 in the consultation guidelines are relevant and should be sufficient to identify any bottle-necks in the ASPSPs IT-infrastructure.
However, we believe that there should be more detailed guidance for the EBA/NCA’s in terms of assessing the test results. The terms ‘multiple firms’, ‘unusually high numbers of requests….in a short period of time’, ‘extremely high number of concurrent sessions open’ and ‘requests for large volumes of data’ would for the individual ASPSP be relative to size (customer numbers, expected online traffic relative to customer numbers etc.).
The guidelines do not provide any guidance on the frequency of the ordinary stress testing or under which other circumstances the ASPSP should perform a stress test of their interface. We believe that the guidelines should provide a reference to ‘periodic’ stress testing as both the ASPSP IT-infrastructure and the number and complexity of the third-party providers will change over time.
Question 3: Do you agree with the EBA’s assessments on monitoring? If not, please provide your reasoning.
As long as the NCA is able to perform monitoring of the KPIs there should be no need to specify any other requirements related to the exemption of contingency measures.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.
We strongly support EBAs pragmatic and open assessments for what is to be regarded as an obstacle with respect to article 32(3). The ASPSPs understand they must open their systems and offer their solutions free of charge via the third-party providers.The definition of an ‘obstacle’ must be something that differentiate the user experience in a negative way, introducing more friction or delays so that the PSUs find it more cumbersome to use the TPPs than the ASPSPs payment services directly. We believe that offering the exact same solutions and hence the same user experience to PSU for use via a TPP as the PSU is faced with in the ASPSP’s online services, will ensure a level playing field for all PSP’s regardless of their business model and relationship with the PSU. The most important principle is that the solution offered to the PSU via the TPP does not create any friction or delay for the PSU compared to the other access methods available directly from the ASPSP to the PSU.
For Norway, the understanding that the PSU’s security credentials should not be shared with the PSP is of vital importance. This is due to the vide usage of BankID among PSU’s - not only for banking services, but also for governmental and other public and private services. BankID is key for the digitalization of Norway. To continue to provide eID based services with BankID, BankID is required to become eIDAS compliant. According to eIDAS regulation, security credentials should not be shared – they should be ‘under the sole control’ of the PSU.
We also support that the EBA clarifies that introducing additional steps to verify the consent of the PSU or requiring TPP compliance with requirements not imposed by the legislation would be regarded as obstacles.
Finally, we would like to point out that any security measures under control of the PSU cannot be regarded as an obstacle. Examples of such security measures may be geo-blocking, spending limits for specific payment instruments or disabling of payment functionalities referred to in section 9.4 in Guidelines on security measures for operational and security risk under PSD2.
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 to the described principles for publication of documentation and the method of confirming that the third-party provider has applied for registration/authorisation with the NCA. Different third-party providers will have different needs, hence the described practical approach to assessment of the design and documentation of third-party testing seems like a plausible method.Especially on rationale 48 and 49 – design must be in line with legal requirements, and ‘to the satisfaction of the payment service providers’ – which will be close to impossible for CA’s to assess. Furthermore, impossible to handle in a harmonized way across Europe.
As for rationale 51 – we understand the reasoning for being concrete on mentioning the API EG as an organization to consider. When being as concrete as the EBA is in this matter, we believe that CA’s could benefit from even more concretization – e.g. alignment with standardization of dedicated interface initiatives, national stakeholder initiatives etc.