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
• A downtime from an ASPSP interface cannot be defined for the requests of one TPP (PISP or AISP), but for all the TPPs using the dedicated Interface, in an aggregated manner.
• A request could not be taken into account by the ASPSP, if blocked or deleted at transmission level through the IP technical layer (router). If a packet containing a request cannot be transmitted by the router, the packet is deleted without capability for the ASPSP to detect the problem, no information being delivered by the router.
• Other situation if the TPP or the ASPSP ISP (Internet Service Provider) is down, the TPP request cannot reach the ASPSP, even if the API is working well.
• The KPI and downtimes can only be calculated by the ASPSP, with the information it has available, meaning calls that have successfully arrived to its infrastructure.
Furthermore, in what concerns the counting of five parallel requests, from an ASPSP perspective, APB understands it may lead to the reporting of the interface as 'down' due to a small system glitch which could have occurred in a timeframe as short as a few milliseconds (eg. <10ms). Any formula must take into consideration that low activity periods may negatively affect the downtime counter, e.g.: if within 1 hour only one request has been received and its processing failed, the threshold will hit 100% downtime. But was it really a downtime or merely a simple glitch? As such, APB proposes to apply a threshold counter whereas the interface would be considered as 'down' whenever more than 50% of total requests are not answered in 30 seconds, within an observation timeframe large enough to cater for small glitches (eg. in 1 minute, if more than 10 requests have been received).
Regarding point a. of Guideline 3.1., we propose its amendment to: “monthly statistics on a quarterly basis”. The publication of daily statistics for all ASPSP's interfaces requires the development and maintenance of a complex infrastructure, with extra costs and little practical use. Average monthly KPIs would be more adequate and feasible. The impact of providing daily figures is disproportionate to the value of the added detail.
APB understands Guideline 4.2. should be rewritten, clarifying that the high number of concurrent sessions, requests, multiple firms, large volumes of data, etc. will be defined by the NCA at national level.
Furthermore, we would like to see clarified:
• That stress tests have to be made only to obtain the fall back exemption or to reactivate it if it was lost, and not regularly.
• That stress tests are made on Pre-Production / Quality environments.
• ‘Extremely high number of requests’, ‘high number of concurrent sessions’ and ‘heavy loads’ should be defined by the NCA at national level, as they are subjective and vary from country to country.
As an alternative, visibility on the ASPSPs websites or channels and the competent authority's websites would be more standardized tools that would help making clear what exactly is difficult for this requirement to be satisfied.
In this context, it would be advisable that, after the initial competent authority's assessment of a given solution in which one or several non-compliant features have been detected, additional time is granted to ASPSPs to solve these issues and present a tuned solution for the CA to re-assess. This would be of extreme importance in this first movement towards a new market context and ecosystem.
These considerations should lead to a further extension of the adjustment time granted to ASPSPs after their initial interface roll-out by March 2019, should non-compliant features be detected.
APB proposes that the fallback exemption is granted to the ASPSPs that may be non-compliant with one or more requirements of the Guidelines, but have a plan to comply by the end of 2019.
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.
In relation to point b. of Guideline 2.4. (downtime calculation as 5 consecutive attempts not answered in 30’’), the Portuguese Banking Association (APB) would like to see the following points clarified:• A downtime from an ASPSP interface cannot be defined for the requests of one TPP (PISP or AISP), but for all the TPPs using the dedicated Interface, in an aggregated manner.
• A request could not be taken into account by the ASPSP, if blocked or deleted at transmission level through the IP technical layer (router). If a packet containing a request cannot be transmitted by the router, the packet is deleted without capability for the ASPSP to detect the problem, no information being delivered by the router.
• Other situation if the TPP or the ASPSP ISP (Internet Service Provider) is down, the TPP request cannot reach the ASPSP, even if the API is working well.
• The KPI and downtimes can only be calculated by the ASPSP, with the information it has available, meaning calls that have successfully arrived to its infrastructure.
Furthermore, in what concerns the counting of five parallel requests, from an ASPSP perspective, APB understands it may lead to the reporting of the interface as 'down' due to a small system glitch which could have occurred in a timeframe as short as a few milliseconds (eg. <10ms). Any formula must take into consideration that low activity periods may negatively affect the downtime counter, e.g.: if within 1 hour only one request has been received and its processing failed, the threshold will hit 100% downtime. But was it really a downtime or merely a simple glitch? As such, APB proposes to apply a threshold counter whereas the interface would be considered as 'down' whenever more than 50% of total requests are not answered in 30 seconds, within an observation timeframe large enough to cater for small glitches (eg. in 1 minute, if more than 10 requests have been received).
Regarding point a. of Guideline 3.1., we propose its amendment to: “monthly statistics on a quarterly basis”. The publication of daily statistics for all ASPSP's interfaces requires the development and maintenance of a complex infrastructure, with extra costs and little practical use. Average monthly KPIs would be more adequate and feasible. 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.
The stress test requirements seem adequate but should be balanced by the need to establish a comparable resilience for the dedicated interface with the ASPSP's direct channels for its PSUs. It would not make sense to demand more stringent requirements for the dedicated interface than those applicable to the ASPSP's channels. This aspect should be made clear in the Guidelines.APB understands Guideline 4.2. should be rewritten, clarifying that the high number of concurrent sessions, requests, multiple firms, large volumes of data, etc. will be defined by the NCA at national level.
Furthermore, we would like to see clarified:
• That stress tests have to be made only to obtain the fall back exemption or to reactivate it if it was lost, and not regularly.
• That stress tests are made on Pre-Production / Quality environments.
• ‘Extremely high number of requests’, ‘high number of concurrent sessions’ and ‘heavy loads’ should be defined by the NCA at national level, as they are subjective and vary from country to country.
Question 3: Do you agree with the EBA’s assessments on monitoring? If not, please provide your reasoning.
APB agrees with the EBA’s conclusion that CAs cannot be required to monitor KPIs as a condition to exempt ASPSPs from a fallback solution, but as a normal supervisory activity. Based on paragraph 32 (“… The EBA is therefore of the view that the monitoring by CAs cannot plausibly be one of the requirements for granting an exemption to an ASPSP.”), we agree with the EBA’s assessments on monitoring.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.
Taking into consideration the content of paragraphs 35 and 36, APB proposes to rephrase or exclude point b. of Guideline 5.1. We cannot fully understand why, if a given ASPSP has chosen to use a single method of access to its services and it is compliant with the applicable legislation, the ASPSP has to provide … an explanation of the reasons why this method of access is not an obstacle as referred to in Article 32(3) of the RTS and how this method of access supports all authentication methods provided by the ASPSP to its 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.
It should be clarified that Guideline 6.2. applies to authorized PISPs, AISPs and CBPIIs, because only those entities have valid certificates as required under point b. of Guideline 6.2. As such, APB proposes to rephrase it to: “6.2 The testing facility prior to live usage should allow authorized PISPs, AISPs and CBPIIs to test the dedicated interface for the following:”.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 (Communicating availability of test interfaces), given the fact that it is a legal requirement to have a dedicated interface including testing facilities and documentation, APB agrees that the information should be made available on the website of the ASPSP and “... by communicating the availability of the testing facilities via appropriate channels…”. We would, however, like to see clarified that the different channels mentioned in the Guideline are only examples and not mandatory.As an alternative, visibility on the ASPSPs websites or channels and the competent authority's websites would be more standardized tools that would help making clear what exactly is difficult for this requirement to be satisfied.
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.
APB agrees with the EBA’s assessment, to the extent that this is a common supervisory practice. We see no reason to intensify supervision on this subject, compared with other channels or ASPSPs services.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.
APB agrees with the scope of the Annex 1 Assessment Form (as detailed in the Guideline 9.1), and the interaction between CAs and the EBA.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?
Dedicated interfaces for TPPs are a new concept and a new market standard, defined by PSD2 and its associated RTS. As such, and taking into account the fact that compliance requirements are quite significant and in fact have recently been revised/complemented in the EBA's Opinion document (13th June 2018), there is a relevant possibility of these interface's having one or a few non-compliant features, for some ASPSPs across Europe. Also the final Guidelines for fallback exemption will only be available from September 2018, and not all countries have transposed PSD2.In this context, it would be advisable that, after the initial competent authority's assessment of a given solution in which one or several non-compliant features have been detected, additional time is granted to ASPSPs to solve these issues and present a tuned solution for the CA to re-assess. This would be of extreme importance in this first movement towards a new market context and ecosystem.
These considerations should lead to a further extension of the adjustment time granted to ASPSPs after their initial interface roll-out by March 2019, should non-compliant features be detected.
APB proposes that the fallback exemption is granted to the ASPSPs that may be non-compliant with one or more requirements of the Guidelines, but have a plan to comply by the end of 2019.