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 appreciate the recent initiatives by the EBA aimed at contributing to a harmonized implementation of the 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 a common understanding and consistent application of the four criteria under Article 33(6) RTS.
Especially for cross-border banking groups, 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 a holistic group-wide implementation.
Therefore, we generally agree with the proposed Guidelines as set out in the Consultation Paper and welcome that the EBA aims at ensuring common, uniform and consistent implementation of the exemption criteria.
Nevertheless we point out that the reporting duties stipulated in the draft guidelines seem to go beyond the already existing reporting duties concerning the EBA GL on major incident reporting. We find a group of intersecting parts according to that the banks would have to report partly the same and partly different indicators, figures and information using different templates. A well-structured and harmonized approach would be welcomed and could add clarity with regard to a level playing field.
We allow ourselves to allert you to the fact that the implementation of API is dependent on the final wording of the minimum requirements. If the implementation can not be done in a well planned manner this may lead to the usage of a not-yet-finished version going along with error-proneness.
Ad Question 1:
Generally, we agree with the assessments and the requirements proposed in Guideline 2 and 3. However, we would like to point out that for availability and performance calculations only the relevant percentage of active requests should be considered.
Furthermore, external factors such as network connectivity between the interface and the TPPs, the performance of the TPP systems, as well as the response times of the Qualified Trust Services Providers (QTSP) or registers for authentication with eIDAS certificates or authorization of the TPPs need to be taken into account and might affect the response time of the dedicated interface. We 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. Therefore, in Guideline 2.3 it needs to explicitly be stated that only the time spent in the ASPSPs environment is to be counted in the performance indicators since the ASPSP cannot be made responsible for the performance of components outside its control.
Regarding Guideline 3.1.b: How is the best-performing" interface determined? One interface may have high throughput but high latency and another interface may show the opposite, so it is not clear which one performs better."
Furthermore, we appreciate the EBA’s clarification that redirection is not in itself an obstacle and 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 of the dedicated interface to the interface made available by the ASPSPs directly to the PSU and not to point of sale channels as well.
Guideline 5.2.c: It just needs to be clarified what is meant by consent by EBA in this specific case. Is this the consent mentioned in PSD2 Art 67(2)(a)?
Guideline 6.2.b
The use of a qualified certificate in the test and development environment may not be realistic with respect to the CAs' methodologies (especially eIDAS seals certificate). Should the testing facility prior to live usage enable E2E testing of APIs which means building replication of the production environment with full funtional scope impacting banking backends system? Or institutions can simulate live usage in the sandbox used by TPPs before going for production.
Guideline 6.3
It is stated that ASPSPs have to provide test results of tests by third parties to the CA, but there is no obligation for AISPs,PISPs, CBPIIs to disclose that data. We therefore cannot see how this can be a reason for granting an exemption, as it is not under the control of the ASPSP. How can it be assured that claims of interface not working" are really errors made on ASPSP-side and not on TPP-side?
Guideline 6.4
How is "market initiative standard" defined?"
Guideline 7.1
It is not stated at which point in time (or how often) this data has to be provided to the CA. The number of PSPs using the interfaces starts with zero today and will ramp up to larger numbers in the years to come.
Every definition of the GL comprehend the 3 different TPP roles. Is it acceptable if e.g. 100 AISP and 100 PISP have a satisfying test result, but no CBPII test result is available?
Guideline 7.2
What is the adequate level of evidence provided by the ASPSP? Is it enough to communicate the availability on the ASPSP website?
Guideline 7.3
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 six-months testing period.
However, the description seems imprecise. The three months when the dedicated interface should be widely used are part of the six months which means that ASPSPs should cooperate with a large number of TPPs three months before the market launch which seems challenging. But this is the base of the exemption.
However, we still want to highlight that the EBA shall contribute to the consistent application of the exemption conditions and address divergent approaches between CAs. A harmonized implementation of the RTS and consequently a harmonized application of the exemption criteria is key to avoid uneven playing field issues and additional operational burden for cross-border firms having to adapt their dedicated interface to divergent local requirements.
Therefore, we believe that the EBA shall also address potential concerns that might arise with regard to divergent approaches by competent authorities before 31 December 2019.
More generally speaking, we would like to address the fact that the 6-months documentation requirement before the go-live of product developments perhaps may slow down the innovation process, as can be seen in the pan-European adoption of instant payments: ASPSPs are currently implementing SCTInst 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.
General RemarksWe appreciate the recent initiatives by the EBA aimed at contributing to a harmonized implementation of the 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 a common understanding and consistent application of the four criteria under Article 33(6) RTS.
Especially for cross-border banking groups, 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 a holistic group-wide implementation.
Therefore, we generally agree with the proposed Guidelines as set out in the Consultation Paper and welcome that the EBA aims at ensuring common, uniform and consistent implementation of the exemption criteria.
Nevertheless we point out that the reporting duties stipulated in the draft guidelines seem to go beyond the already existing reporting duties concerning the EBA GL on major incident reporting. We find a group of intersecting parts according to that the banks would have to report partly the same and partly different indicators, figures and information using different templates. A well-structured and harmonized approach would be welcomed and could add clarity with regard to a level playing field.
We allow ourselves to allert you to the fact that the implementation of API is dependent on the final wording of the minimum requirements. If the implementation can not be done in a well planned manner this may lead to the usage of a not-yet-finished version going along with error-proneness.
Ad Question 1:
Generally, we agree with the assessments and the requirements proposed in Guideline 2 and 3. However, we would like to point out that for availability and performance calculations only the relevant percentage of active requests should be considered.
Furthermore, external factors such as network connectivity between the interface and the TPPs, the performance of the TPP systems, as well as the response times of the Qualified Trust Services Providers (QTSP) or registers for authentication with eIDAS certificates or authorization of the TPPs need to be taken into account and might affect the response time of the dedicated interface. We 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. Therefore, in Guideline 2.3 it needs to explicitly be stated that only the time spent in the ASPSPs environment is to be counted in the performance indicators since the ASPSP cannot be made responsible for the performance of components outside its control.
Regarding Guideline 3.1.b: How is the best-performing" interface determined? One interface may have high throughput but high latency and another interface may show the opposite, so it is not clear which one performs better."
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 generally agree with the assessments and the requirements proposed in Guideline 4. The specification of the stress test requirement seems too vague. The stress test should have a telling value, e.g. by comparing it with the current interface or industry standards.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 generally 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 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 of the dedicated interface to the interface made available by the ASPSPs directly to the PSU and not to point of sale channels as well.
Guideline 5.2.c: It just needs to be clarified what is meant by consent by EBA in this specific case. Is this the consent mentioned in PSD2 Art 67(2)(a)?
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.
Yes, we agree and appreciate the EBA’s reference in rationale 51 to the work and output of the API Evaluation Group. We believe that this initiative contributes to 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.Guideline 6.2.b
The use of a qualified certificate in the test and development environment may not be realistic with respect to the CAs' methodologies (especially eIDAS seals certificate). Should the testing facility prior to live usage enable E2E testing of APIs which means building replication of the production environment with full funtional scope impacting banking backends system? Or institutions can simulate live usage in the sandbox used by TPPs before going for production.
Guideline 6.3
It is stated that ASPSPs have to provide test results of tests by third parties to the CA, but there is no obligation for AISPs,PISPs, CBPIIs to disclose that data. We therefore cannot see how this can be a reason for granting an exemption, as it is not under the control of the ASPSP. How can it be assured that claims of interface not working" are really errors made on ASPSP-side and not on TPP-side?
Guideline 6.4
How is "market initiative standard" defined?"
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 fully agree with the EBA’s view that it might be challenging for CAs to assess whether an API has been “widely used”, especially before the application date of the RTS. We welcome that the EBA has discarded the requirement for numerical measurements of “wide usage” as this might have been discriminating 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 testing.Guideline 7.1
It is not stated at which point in time (or how often) this data has to be provided to the CA. The number of PSPs using the interfaces starts with zero today and will ramp up to larger numbers in the years to come.
Every definition of the GL comprehend the 3 different TPP roles. Is it acceptable if e.g. 100 AISP and 100 PISP have a satisfying test result, but no CBPII test result is available?
Guideline 7.2
What is the adequate level of evidence provided by the ASPSP? Is it enough to communicate the availability on the ASPSP website?
Guideline 7.3
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 six-months testing period.
However, the description seems imprecise. The three months when the dedicated interface should be widely used are part of the six months which means that ASPSPs should cooperate with a large number of TPPs three months before the market launch which seems challenging. But this is the base of the exemption.
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 generally agree with the assessments and the requirements proposed in Guideline 8. However, the proposed requirements seem to be partly controversial. Production SLAs can not be expected in the testing phase, because bug fixes fail to meet the production SLAs by nature. So the testing phase availability can not be measured against production requirements and as a consequence should not be the base of the 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 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.However, we still want to highlight that the EBA shall contribute to the consistent application of the exemption conditions and address divergent approaches between CAs. A harmonized implementation of the RTS and consequently a harmonized application of the exemption criteria is key to avoid uneven playing field issues and additional operational burden for cross-border firms having to adapt their dedicated interface to divergent local requirements.
Therefore, we believe that the EBA shall also address potential concerns that might arise with regard to divergent approaches by competent authorities before 31 December 2019.
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 understand the envisaged timelines and acknowledge the timelines and deadlines as set out by the RTS. However, the timeframe (planned application date 1st Jan 2019) is very challenging and the planned publication date seems too late.More generally speaking, we would like to address the fact that the 6-months documentation requirement before the go-live of product developments perhaps may slow down the innovation process, as can be seen in the pan-European adoption of instant payments: ASPSPs are currently implementing SCTInst 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.