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
The EACB welcomes the opportunity to participate in the public consultation on Draft 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).
We consider that the recent initiatives launched by the EBA contribute to achieve a harmonized implementation of PSD2 requirements, especially with regard to the RTS on SCA & CSC. A harmonized implementation of the RTS on SCA & CSC and consequently a harmonized application of the exemption criteria is key to avoid uneven playing field issues and regulatory arbitrage. We appreciate that the EBA has addressed the potential threats and problems arising from a lack of common understanding and consistent application of the four criteria under Article 33(6) RTS.
From our point of view, divergent approaches by National Competent Authorities will ultimately lead to additional operational burden due to different local assessments and the necessity to adapt the dedicated interface according to local requirements. Furthermore, a lack of transparency about the interpretation of the conditions to be met to benefit from an exemption will increase uncertainty and hamper implementation strategies.
Therefore, we generally agree with the proposed Guidelines as set out in the Consultation Paper and welcome that the EBA aims at ensuring a common, uniform and consistent implementation of the exemption criteria.
Answer Q1:
1. The performance metric for a yes/no response to a Card based payment instrument issuer (CBPII) is excluded in rationale 22 for the purposes of the calculation of downtime but CBPIIs are included in the context of Guideline 2.3.c when defining the KPIs. The EACB would welcome a clarification on how to interpret this difference.
2. Although, we ackowledge that the requierement on article 33.1 of the RTS on SCA & CSC (5 consecutive times within 30 seconds) is expressed in seconds, the EACB would like to highlight that the unit of measure in seconds for calculating downtime (different to “response time”) is complex in technical terms (e.g. as impact on performance, when availability has to be monitored continuously on a sec basis) on the systems to be monitored.
3. In the EACB’s view, the parameters to take into account are not clear enough. We would like to obtain further clarity regarding what is the acceptable difference between the performance levels achieved by the interface dedicated to TPPs and the reference values of the interfaces available to the PSUs as well as what is the time period to be considered for the difference measurement. We would also like to invite the EBA to define a range of tolerance for the measurement between the TPP dedicated interface and the PSU direct interface. We assume that a percentage (rather than a specific value) on an annual basis (rather than a smaller one – i.e. dayly or monthly) would be acceptable. This means for instance that if the overall performance of the API interface is lower than the PSU’s one, but this performance is still within a defined window (e.g. x% lower), this would be nevertheless acceptable and considered valid for exemption purposes.
4. The performance levels of the dedicated interfaces can vary depending on the period (month, day, hour) of the collection and on the quantity of data that must be transmitted for the single PSU or the transaction. The EACB would like to request a confirmation that the values to be taken into account are those relating to the annual average of transactions and not the best absolute value recorded in the year (or other reference period to be indicated).
5. In order to determine the response time of the dedicated interface, it is necessary to consider a defined “standard access” to exclude external factors such as network latency. The EACB would welcome the confirmation that only the time actually elapsed since an already authenticated and authorized TPP made the request to the ASPSP and the response provided by ASPSP should be considered as the response time, regardless of the TPP reception times. In addition, the EACB believes that in the following two scenarios, the performance of the API cannot be questioned: (1) when a request is blocked or deleted at transmission level through the IP technical layer (router). Indeed, the ASPSP is not able to detect the problem as no information is delivered by the router; (2) when the TPP request does not reach the ASPSP even if the API is working properly because of an internet service provider problem.
6. The EACB would like to obtain clarification that, in the case where an AISPSP uses an API shared by different banks, the measurement of the performance of that API is not based on the reaction time of the slowest bank answering the AISPSP query through the joint API but that such measurement will be based on the individual reaction times of the individual banks being approached through that API.
7. The EACB would like to indicate that it is not possible to compare a dedicated interface with the 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 measurement will be done on server side, not involving the client network time.
With regard to rationale 39 in the Consultation Paper we would like to point out that the reference to “different methods of access for different channels (browser/mobile/point of sale)” is somehow misleading in this context, as the assessment of obstacles should be limited to the comparison between the dedicated interface and the interface made available by the ASPSPs directly to the PSU and not the point of sale channels as well.
We also agree with the requirement under Guideline 6.1 according to which ASPSPs only have to publish a summary of the specifications. We also believe that from an operational and security point of view, the testing environment has to be completely aligned with the full set of specifications and requirements of the API implemented by an ASPSP.
Following the discussion at the EBA Public Hearing on this Consultation Paper on 25th July 2018, we would like to ask the EBA to define in greater detail the main characteristics of the testing facility referred in Guideline 6.2. In particular, we would welcome any further information about whether the testing should be carried out taking into consideration real/customer data or if it is possible to use fake data.
Regarding Guideline 6.4, the EACB would like to request further information about which initiatives should be in EBA’s view qualified as “market initiative” or what is the process to be qualified as such. Indeed, a protocol used among several entities of a large group can be wider than a published standard followed by few banks.
According to what is implicitly suggested in Guideline 7.2, the EACB understands that ASPSPs are expected to publicly communicate about the availability of the testing facility via appropriate channels regardless of whether or not the requirement under Guideline 7.1 is fulfilled. Could the EBA please confirm whether the EACB’s understanding is right?
Furthermore, we welcome the clarification under Guideline 7.3 that the three-month period referred to in Art. 33(6) (c) RTS may be included within the 6-months testing period.
It would be good if the EBA could address potential concerns that might arise with regard to divergent approaches by Competent Authorities before 31 December 2019. In addition, in order to meet the requirements of a due and transparent process, the EACB believes that when a Competent Authority issues a negative assessment according to Guidelines 9.2, ASPSP should have the right to receive the negative feedback. In such cases, the exemption process should also allow for additional hearings and right of appeal.
The EACB would also like to highlight the fact that the requirement in article 30 (3) of the RTS on SCA&CSC regarding the 6-months documentation obligations before the go-live of product developments perhaps may slow down the innovation process, as it can be evidenced in the pan-European adoption of instant payments. Indeed, ASPSPs are currently implementing SCT Inst in their payment systems, but as there is a requirement to provide the relevant documentation on their websites six months in advance, they might have to postpone their go-live dates in order to meet the six months timeline and not to discriminate potential PISPs.
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.
Intro:The EACB welcomes the opportunity to participate in the public consultation on Draft 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).
We consider that the recent initiatives launched by the EBA contribute to achieve a harmonized implementation of PSD2 requirements, especially with regard to the RTS on SCA & CSC. A harmonized implementation of the RTS on SCA & CSC and consequently a harmonized application of the exemption criteria is key to avoid uneven playing field issues and regulatory arbitrage. We appreciate that the EBA has addressed the potential threats and problems arising from a lack of common understanding and consistent application of the four criteria under Article 33(6) RTS.
From our point of view, divergent approaches by National Competent Authorities will ultimately lead to additional operational burden due to different local assessments and the necessity to adapt the dedicated interface according to local requirements. Furthermore, a lack of transparency about the interpretation of the conditions to be met to benefit from an exemption will increase uncertainty and hamper implementation strategies.
Therefore, we generally agree with the proposed Guidelines as set out in the Consultation Paper and welcome that the EBA aims at ensuring a common, uniform and consistent implementation of the exemption criteria.
Answer Q1:
1. The performance metric for a yes/no response to a Card based payment instrument issuer (CBPII) is excluded in rationale 22 for the purposes of the calculation of downtime but CBPIIs are included in the context of Guideline 2.3.c when defining the KPIs. The EACB would welcome a clarification on how to interpret this difference.
2. Although, we ackowledge that the requierement on article 33.1 of the RTS on SCA & CSC (5 consecutive times within 30 seconds) is expressed in seconds, the EACB would like to highlight that the unit of measure in seconds for calculating downtime (different to “response time”) is complex in technical terms (e.g. as impact on performance, when availability has to be monitored continuously on a sec basis) on the systems to be monitored.
3. In the EACB’s view, the parameters to take into account are not clear enough. We would like to obtain further clarity regarding what is the acceptable difference between the performance levels achieved by the interface dedicated to TPPs and the reference values of the interfaces available to the PSUs as well as what is the time period to be considered for the difference measurement. We would also like to invite the EBA to define a range of tolerance for the measurement between the TPP dedicated interface and the PSU direct interface. We assume that a percentage (rather than a specific value) on an annual basis (rather than a smaller one – i.e. dayly or monthly) would be acceptable. This means for instance that if the overall performance of the API interface is lower than the PSU’s one, but this performance is still within a defined window (e.g. x% lower), this would be nevertheless acceptable and considered valid for exemption purposes.
4. The performance levels of the dedicated interfaces can vary depending on the period (month, day, hour) of the collection and on the quantity of data that must be transmitted for the single PSU or the transaction. The EACB would like to request a confirmation that the values to be taken into account are those relating to the annual average of transactions and not the best absolute value recorded in the year (or other reference period to be indicated).
5. In order to determine the response time of the dedicated interface, it is necessary to consider a defined “standard access” to exclude external factors such as network latency. The EACB would welcome the confirmation that only the time actually elapsed since an already authenticated and authorized TPP made the request to the ASPSP and the response provided by ASPSP should be considered as the response time, regardless of the TPP reception times. In addition, the EACB believes that in the following two scenarios, the performance of the API cannot be questioned: (1) when a request is blocked or deleted at transmission level through the IP technical layer (router). Indeed, the ASPSP is not able to detect the problem as no information is delivered by the router; (2) when the TPP request does not reach the ASPSP even if the API is working properly because of an internet service provider problem.
6. The EACB would like to obtain clarification that, in the case where an AISPSP uses an API shared by different banks, the measurement of the performance of that API is not based on the reaction time of the slowest bank answering the AISPSP query through the joint API but that such measurement will be based on the individual reaction times of the individual banks being approached through that API.
7. The EACB would like to indicate that it is not possible to compare a dedicated interface with the 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 measurement will be done on server side, not involving the client network time.
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.
Yes, we agree with the assessments and the requirements proposed in Guideline 4.Question 3: Do you agree with the EBA’s assessments on monitoring? If not, please provide your reasoning.
Yes, we agree with the 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.
Yes, we agree with the EBA’s assessments and the requirements proposed in Guideline 5. Furthermore, we appreciate the EBA’s clarification that redirection is not in itself an obstacle and we welcome the proposed requirements focusing on the user experience as such.With regard to rationale 39 in the Consultation Paper we would like to point out that the reference to “different methods of access for different channels (browser/mobile/point of sale)” is somehow misleading in this context, as the assessment of obstacles should be limited to the comparison between the dedicated interface and the interface made available by the ASPSPs directly to the PSU and not the point of sale channels as well.
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 EACB agrees and appreciates the EBA’s reference in rationale 51 to the work and output of the API Evaluation Group. We believe that this initiative contributes to achieve a more harmonized approach in API implementation and we regard the output of the group as valuable for the evaluation of the design and functionalities of a dedicated interface.We also agree with the requirement under Guideline 6.1 according to which ASPSPs only have to publish a summary of the specifications. We also believe that from an operational and security point of view, the testing environment has to be completely aligned with the full set of specifications and requirements of the API implemented by an ASPSP.
Following the discussion at the EBA Public Hearing on this Consultation Paper on 25th July 2018, we would like to ask the EBA to define in greater detail the main characteristics of the testing facility referred in Guideline 6.2. In particular, we would welcome any further information about whether the testing should be carried out taking into consideration real/customer data or if it is possible to use fake data.
Regarding Guideline 6.4, the EACB would like to request further information about which initiatives should be in EBA’s view qualified as “market initiative” or what is the process to be qualified as such. Indeed, a protocol used among several entities of a large group can be wider than a published standard followed by few banks.
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.
Yes, we agree with the EBA’s assessment regarding the “widely used” requirement for a dedicated interface. We share the EBA’s view that it might be challenging for Competent Authorities to assess whether an API has been “widely used”, especially before the application date of the RTS. We appreciate that the EBA has discarded the requirement for numerical measurements of “wide usage” as this might have been discriminatory especially for smaller firms due to a lack of interested parties to test their API and given the fact that there is no obligation for participating in the testing. There is no guarantee for the ASPSPs that the TPPs will utilize the interface during the given time period and therefore this can’t be a criteria for the exemption from the contingency measures.According to what is implicitly suggested in Guideline 7.2, the EACB understands that ASPSPs are expected to publicly communicate about the availability of the testing facility via appropriate channels regardless of whether or not the requirement under Guideline 7.1 is fulfilled. Could the EBA please confirm whether the EACB’s understanding is right?
Furthermore, we welcome the clarification under Guideline 7.3 that the three-month period referred to in Art. 33(6) (c) RTS may be included within the 6-months testing period.
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.
Yes, we agree with the assessments and the requirements proposed in Guideline 8.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 generally agree with the proposed Guideline 9 and understand the need for a pragmatic approach taking into consideration the expected large number of requests for assessments as well as the need for expedient processing. The EACB would like to nevertheless highlight that the EBA shall as much as possible contribute to the consistent application of the exemption conditions and address divergent approaches between Competent Authorities to avoid uneven playing field issues and additional operational burden as a result of different rules between Member States.It would be good if the EBA could address potential concerns that might arise with regard to divergent approaches by Competent Authorities before 31 December 2019. In addition, in order to meet the requirements of a due and transparent process, the EACB believes that when a Competent Authority issues a negative assessment according to Guidelines 9.2, ASPSP should have the right to receive the negative feedback. In such cases, the exemption process should also allow for additional hearings and right of appeal.
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 EACB acknowledges the envisaged timelines for ASPSPs to meet the requirements set out in these Guidelines prior to the September 2019 deadline. We would like to stress that the time available for ASPSPs to adapt their dedicated interfaces to the final version of these Guidelines is challenging. Indeed, the publication of the final version of these Guidelines is yet uncertain since they are still under consultation and the EBA will certainly need time to process all the feedback received. In addition, these Guidelines should be implemented by the National Authorities, which could also introduce any changes that might require further or different interventions, as well as possible differences in interpretation in the various countries of the Union. All these circumstances might result in a very limited time available for ASPSP to adapt their interfaces for exemption purposes.The EACB would also like to highlight the fact that the requirement in article 30 (3) of the RTS on SCA&CSC regarding the 6-months documentation obligations before the go-live of product developments perhaps may slow down the innovation process, as it can be evidenced in the pan-European adoption of instant payments. Indeed, ASPSPs are currently implementing SCT Inst in their payment systems, but as there is a requirement to provide the relevant documentation on their websites six months in advance, they might have to postpone their go-live dates in order to meet the six months timeline and not to discriminate potential PISPs.