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 would like the EBA to clarify that it is the best performing PSU interface that shall be the baseline for the dedicated interface.
(2) specific points to which the comment relates:
Sec. 4.2.24 of the CP stipulates that “For the purposes of monitoring, CAs should check that the dedicated interface matches the highest level of availability of any of the best performing PSU interfaces of the ASPSP.” Evidently, EBA instructs the CAs to monitor the dedicated interface compared to the best performing PSU interface.
(3) rationale:
It would be prudent to link the obligations of the ASPSP in sec. 2.1 of the GL on having in place aligned service levels to the best performing PSU interface, as this is what the CAs are to monitor. If the obligation does not refer to the best performing PSU interface, but only the monitoring, this leads to uncertainties as to what would be required of the ASPSPs.
(4) evidence:
The discrepancy between the rationale of the EBA in sec. 4.2.24 and sec. 2.1 of the GL.
(5) alternative regulatory choices the EBA should consider:
To include a reference to the best performing PSU interface in sec. 2.1 of the GL.
In our view, it is unclear what ASPSP should actually provide to the CA in respect of the reports to be compiled to summarize the stress-testing.
(2) specific points to which the comment relates:
Is it a report?
Are there specific tests that should be run (specific way to load the system and specific value to measure/validate)?
(3) rationale:
Sec. 4.2 and 4.3 do not provide any guidance on which sort of tests that are to be carried out nor any information on what it is that should be reported to the CAs. Arguably, if a requirement is that the APIs are to be stress-tested, the results of such testing should also be possible to compare with something else to ensure relevant testing and appropriate outcome of such tests.
(4) evidence:
There is no guidance on what the requirements are in the referred sections.
(5) alternative regulatory choices the EBA should consider:
It should be possible to standardize tests that each ASPSP could run. Our suggested alternative would be to define specific tests to run and specific outcomes to be achieved. While we do understand that this might be a challenge and not something that we would expect the EBA to formulate, it would be our recommendation to seek the guidance of an independent body to set an industry standard that the EBA could refer to in its GLs.
No, it is not evident by EBAs rationale in sec. 4.2.31 whether it considers the CAs being responsible for monitoring that data has been published or whether the CAs are required to monitor the contents of the data published. While the first mentioned option would require less of the CAs, it would not fulfil the monitoring obligation placed on them under the RTS.
(2) specific points to which the comment relates:
Sec. 32.2 of the RTS compared to EBA’s rationale on monitoring.
(3) rationale:
Given that the RTS sets forth a monitoring obligation for the CAs, that should be implemented in a manner that actually provides a result. We cannot see that a monitoring obligation would actually be met if the monitoring to be carried out is to be limited to noting whether any information has been published. If the monitoring stops at concluding that data has been published the monitoring will not have much effect. Further, given that information on all PSU APIs is to be published, it should be a fairly limited effort to compare the dedicated API with the best performing PSU API and monitor discrepancies.
(4) evidence:
The discrepancy between the rationale of the EBA in sec. 4.2.31 and sec. 32.2 of the RTS.
(5) alternative regulatory choices the EBA should consider:
Reevaluating its assessment in line with the RTS to ensure compliance.
The guidelines do not provide any further clarity on what is considered to be an obstacle and what is expected from ASPSPs to be implemented.
(2) specific points to which the comment relates:
Sections 38, 40 and 41 of the GL say that everything may be considered an obstacle.
How will it be possible to judge compliance or not?
Both embedded and decoupled approach provide clear and unquestionable end-user journey and implementation options
The most problematic approach is redirect (as the redirect itself could under some circumstances be an obstacle) as well as steps that actually happen on the interface of the ASPSPs (depending on implementation those may or may not be obstacles for certain TPPs).
Accordingly, while one redirect approach could be fine for one TPP, the same redirect approach could be a clear obstacle for another TPP.
(3) rationale:
While we do appreciate that the ASPSPs shall actually confirm to the CAs the points set out in sec. 5.2 of the GL. However, sec. 5.1.b. on the ASPSP being allowed to only apply one method of access accompanied with an explanation as to why the chosen method of access is not an obstacle will not be sufficient for ensuring that the method chosen does not entail obstacles for the TPPs using the API and thereby affected, particularly in the light of the specific points raised above in respect of this question.
(4) evidence:
Sec. 5 of the GL.
(5) alternative regulatory choices the EBA should consider:
Mandatory support for embedded (if it's applicable for a given bank and its authentication methods)
Mandatory support for decoupled (if it's applicable for a given bank and its authentication methods)
Provide best practice flow for ASPSPs that would provide guidance on how redirect should be implemented
Points 6.1. - 6.3. provide sufficient guidance, however points 6.4 & 6.5 seem to imply that adoption of a certain API standard" provides in itself certain assurance about compliance.
(2) specific points to which the comment relates:
There is limited value in the knowledge of which API initiative standard the ASPSP has adopted (point 6.4) as that does not provide any indication on whether a given implementation conforms to RTS. In order for the answer to question 6.4b to carry any value very significant level of (technical) detail would need to be provided by the ASPSP
(3) rationale:
Standards defined by all current API initiatives (e.g. Berlin Group, STET) leave such significant room for interpretation that ASPSPs will have to 1) adjust the implementation to their (local) needs and/or interpretation and 2) will only rarely adopt the entire standard
It is how a given standard has been interpreted and (then) implemented technically by the ASPSP that will determine the suitability of ASPSP's interface for usage
Given the difficulties that CAs will face when evaluating ASPSPs' interfaces the questions posed in 6.4a and 6.4b could easily be interpreted by ASPSPs and CAs as that adopting a certain API standard will guarantee fallback exemption.
(4) evidence:
Widely discussed issues raised by TPPs in the past months about UK OB demonstrate that even a standard that is defined to a very significant technical level detail does not lead to unified implementations and consistent developer experience. In fact, TPPs are required to have ASPSP specific implementations and PSU undergo a fundamentally different user journey per ASPSP.
(5) alternative regulatory choices the EBA should consider:
Point 6.5 should be required to be completed by all ASPSPs
ASPSP's response to questions under 6.4 should only be used as a supporting point to question under 6.5.
ASPSPs should provide evidence that they have engaged with a range of different TPPs (at least one AISP, PISP and CBPIIs)"
In our view, it is very unclear what “widely used” entails. The GLs are open-ended and the reference to having evidenced compliance does not add up. Using “widely used” as a criteria is completely inappropriate.
(2) specific points to which the comment relates:
The wordings of sec. 7.1 - 7.2 in their entirety.
(3) rationale:
Sec. 7.1 is the section that is intended to address the “widely used” definition, however, it does not include any guidance other than that the ASPSPs should provide the CAs with information which shall include the total number of TPPs that have applied and the number of TPPs using the interface. What would then be the basis for determining what “widely used” actually means? The ratio between the number of TPPs having signed up and the number of those TPPs actually using it? And regardless if a dedicated API is used by a large number of the TPPs having signed up, that fact does not evidence that the API is in fact a well-functioning API without any obstacles, since this may very well vary from TPP to TPP, not to mention that it may vary vastly among the different types of TPPs.
Further, sec. 7.2 provides an alternative to the ASPSP of providing evidence that if not fulfilling the - remarkably unclear - definition of “widely used”, it may evidence to the CA that it has communicated the availability of the testing facilities via appropriate channels. How would this help? While we do appreciate that the EBA encourages the ASPSPs to market their dedicated APIs, the existence of these are quite expected and TPPs that wish to use APIs of a certain ASPSP will certainly look for that. Further, if the API is not even used, it would sure be an indicator - particularly where there is a lot of marketing on it being available - that it is not a well-functioning API. Providing information on marketing efforts appears a waste of time, both for the ASPSPs and the CAs.
(4) evidence:
The rationale presented.
(5) alternative regulatory choices the EBA should consider:
Excluding “widely used” from being a criteria to be applied when determining whether an exemption should be granted. It is ambiguous and calls for uncertainty by the mere lack of an appropriate definition.
Sec. 8.1.b of the GL on the ASPSP being obligated to provide an explanation on problems not having been resolved is unclear in our view - to what end is this required to be provided? In the event problems are not resolved no exemption should be granted, whether the ASPSP is able to provide an explanation for it is irrelevant.
(2) specific points to which the comment relates:
Art. 33.6.d of the RTS, Sec. 8.1.b of the GL.
(3) rationale:
Uncertainties as for what this entails. Having guidelines in place on ASPSPs being required to providing information comprising explanations as to why problems are not solved appears to be an obligation that will be an unnecessary burden for the ASPSPs and the CAs, while not providing any comfort for the TPPs.
(4) evidence:
GLs not in line with RTS.
(5) alternative regulatory choices the EBA should consider:
Delete the wording from the GLs.
The assessment form does not include any section dedicated to establish whether the requirements for granting an exemption have been met, which is what is to be evaluated by the EBA under the RTS. The aim is to ensure an aligned application of the rationale for granting an exemption - to ensure this the arguments for granting an exemption should be elaborated on rather than the rationale for refusal.
One of the things enabled through PSD2 is harmonisation of the landscape across the EU and spreading innovation across markets. If no actual consultation is required with EBA, how will it be ensured that the quality of the interfaces and threshold for granting exemption will be identical across all EU?
(2) specific points to which the comment relates:
Art. 33.6 of the RTS, Sec. 9 of the GLs, Annex 1 in the GLs.
(3) rationale:
The method for the assessment is contrary to what is prescribed in the RTS.
(4) evidence:
References sections of the RTS and the GLs.
(5) alternative regulatory choices the EBA should consider:
Alter the GLs to ensure compliance with the RTS.
We are particularly am worried about the risk of the ASPSPs taking a long time in granting us access to their APIs. What do we do if it takes several months for the ASPSP to review our application for accessing production APIs? A number of ASPSPs whose APIs we are currently testing require a number of questionnaires, meetings, interviews and background checks in order to grant access. Obviously, this takes time.
(2) specific points to which the comment relates:
This is not in any manner addressed in the GLs. Would be good to have a deadline tied to making available production environments.
(3) rationale:
(4) evidence:
(5) alternative regulatory choices the EBA should consider:
No, the GLs do not provide for much more clarity. Reference is made to our answers and rationales in respect of questions Q1-Q9.
(2) specific points to which the comment relates:
(3) rationale:
(4) evidence:
(5) alternative regulatory choices the EBA should consider:
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.
(1) response to question:We would like the EBA to clarify that it is the best performing PSU interface that shall be the baseline for the dedicated interface.
(2) specific points to which the comment relates:
Sec. 4.2.24 of the CP stipulates that “For the purposes of monitoring, CAs should check that the dedicated interface matches the highest level of availability of any of the best performing PSU interfaces of the ASPSP.” Evidently, EBA instructs the CAs to monitor the dedicated interface compared to the best performing PSU interface.
(3) rationale:
It would be prudent to link the obligations of the ASPSP in sec. 2.1 of the GL on having in place aligned service levels to the best performing PSU interface, as this is what the CAs are to monitor. If the obligation does not refer to the best performing PSU interface, but only the monitoring, this leads to uncertainties as to what would be required of the ASPSPs.
(4) evidence:
The discrepancy between the rationale of the EBA in sec. 4.2.24 and sec. 2.1 of the GL.
(5) alternative regulatory choices the EBA should consider:
To include a reference to the best performing PSU interface in sec. 2.1 of the GL.
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.
(1) response to question:In our view, it is unclear what ASPSP should actually provide to the CA in respect of the reports to be compiled to summarize the stress-testing.
(2) specific points to which the comment relates:
Is it a report?
Are there specific tests that should be run (specific way to load the system and specific value to measure/validate)?
(3) rationale:
Sec. 4.2 and 4.3 do not provide any guidance on which sort of tests that are to be carried out nor any information on what it is that should be reported to the CAs. Arguably, if a requirement is that the APIs are to be stress-tested, the results of such testing should also be possible to compare with something else to ensure relevant testing and appropriate outcome of such tests.
(4) evidence:
There is no guidance on what the requirements are in the referred sections.
(5) alternative regulatory choices the EBA should consider:
It should be possible to standardize tests that each ASPSP could run. Our suggested alternative would be to define specific tests to run and specific outcomes to be achieved. While we do understand that this might be a challenge and not something that we would expect the EBA to formulate, it would be our recommendation to seek the guidance of an independent body to set an industry standard that the EBA could refer to in its GLs.
Question 3: Do you agree with the EBA’s assessments on monitoring? If not, please provide your reasoning.
(1) response to question:No, it is not evident by EBAs rationale in sec. 4.2.31 whether it considers the CAs being responsible for monitoring that data has been published or whether the CAs are required to monitor the contents of the data published. While the first mentioned option would require less of the CAs, it would not fulfil the monitoring obligation placed on them under the RTS.
(2) specific points to which the comment relates:
Sec. 32.2 of the RTS compared to EBA’s rationale on monitoring.
(3) rationale:
Given that the RTS sets forth a monitoring obligation for the CAs, that should be implemented in a manner that actually provides a result. We cannot see that a monitoring obligation would actually be met if the monitoring to be carried out is to be limited to noting whether any information has been published. If the monitoring stops at concluding that data has been published the monitoring will not have much effect. Further, given that information on all PSU APIs is to be published, it should be a fairly limited effort to compare the dedicated API with the best performing PSU API and monitor discrepancies.
(4) evidence:
The discrepancy between the rationale of the EBA in sec. 4.2.31 and sec. 32.2 of the RTS.
(5) alternative regulatory choices the EBA should consider:
Reevaluating its assessment in line with the RTS to ensure 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.
(1) response to question:The guidelines do not provide any further clarity on what is considered to be an obstacle and what is expected from ASPSPs to be implemented.
(2) specific points to which the comment relates:
Sections 38, 40 and 41 of the GL say that everything may be considered an obstacle.
How will it be possible to judge compliance or not?
Both embedded and decoupled approach provide clear and unquestionable end-user journey and implementation options
The most problematic approach is redirect (as the redirect itself could under some circumstances be an obstacle) as well as steps that actually happen on the interface of the ASPSPs (depending on implementation those may or may not be obstacles for certain TPPs).
Accordingly, while one redirect approach could be fine for one TPP, the same redirect approach could be a clear obstacle for another TPP.
(3) rationale:
While we do appreciate that the ASPSPs shall actually confirm to the CAs the points set out in sec. 5.2 of the GL. However, sec. 5.1.b. on the ASPSP being allowed to only apply one method of access accompanied with an explanation as to why the chosen method of access is not an obstacle will not be sufficient for ensuring that the method chosen does not entail obstacles for the TPPs using the API and thereby affected, particularly in the light of the specific points raised above in respect of this question.
(4) evidence:
Sec. 5 of the GL.
(5) alternative regulatory choices the EBA should consider:
Mandatory support for embedded (if it's applicable for a given bank and its authentication methods)
Mandatory support for decoupled (if it's applicable for a given bank and its authentication methods)
Provide best practice flow for ASPSPs that would provide guidance on how redirect should be implemented
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.
(1) response to question:Points 6.1. - 6.3. provide sufficient guidance, however points 6.4 & 6.5 seem to imply that adoption of a certain API standard" provides in itself certain assurance about compliance.
(2) specific points to which the comment relates:
There is limited value in the knowledge of which API initiative standard the ASPSP has adopted (point 6.4) as that does not provide any indication on whether a given implementation conforms to RTS. In order for the answer to question 6.4b to carry any value very significant level of (technical) detail would need to be provided by the ASPSP
(3) rationale:
Standards defined by all current API initiatives (e.g. Berlin Group, STET) leave such significant room for interpretation that ASPSPs will have to 1) adjust the implementation to their (local) needs and/or interpretation and 2) will only rarely adopt the entire standard
It is how a given standard has been interpreted and (then) implemented technically by the ASPSP that will determine the suitability of ASPSP's interface for usage
Given the difficulties that CAs will face when evaluating ASPSPs' interfaces the questions posed in 6.4a and 6.4b could easily be interpreted by ASPSPs and CAs as that adopting a certain API standard will guarantee fallback exemption.
(4) evidence:
Widely discussed issues raised by TPPs in the past months about UK OB demonstrate that even a standard that is defined to a very significant technical level detail does not lead to unified implementations and consistent developer experience. In fact, TPPs are required to have ASPSP specific implementations and PSU undergo a fundamentally different user journey per ASPSP.
(5) alternative regulatory choices the EBA should consider:
Point 6.5 should be required to be completed by all ASPSPs
ASPSP's response to questions under 6.4 should only be used as a supporting point to question under 6.5.
ASPSPs should provide evidence that they have engaged with a range of different TPPs (at least one AISP, PISP and CBPIIs)"
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.
(1) response to question:In our view, it is very unclear what “widely used” entails. The GLs are open-ended and the reference to having evidenced compliance does not add up. Using “widely used” as a criteria is completely inappropriate.
(2) specific points to which the comment relates:
The wordings of sec. 7.1 - 7.2 in their entirety.
(3) rationale:
Sec. 7.1 is the section that is intended to address the “widely used” definition, however, it does not include any guidance other than that the ASPSPs should provide the CAs with information which shall include the total number of TPPs that have applied and the number of TPPs using the interface. What would then be the basis for determining what “widely used” actually means? The ratio between the number of TPPs having signed up and the number of those TPPs actually using it? And regardless if a dedicated API is used by a large number of the TPPs having signed up, that fact does not evidence that the API is in fact a well-functioning API without any obstacles, since this may very well vary from TPP to TPP, not to mention that it may vary vastly among the different types of TPPs.
Further, sec. 7.2 provides an alternative to the ASPSP of providing evidence that if not fulfilling the - remarkably unclear - definition of “widely used”, it may evidence to the CA that it has communicated the availability of the testing facilities via appropriate channels. How would this help? While we do appreciate that the EBA encourages the ASPSPs to market their dedicated APIs, the existence of these are quite expected and TPPs that wish to use APIs of a certain ASPSP will certainly look for that. Further, if the API is not even used, it would sure be an indicator - particularly where there is a lot of marketing on it being available - that it is not a well-functioning API. Providing information on marketing efforts appears a waste of time, both for the ASPSPs and the CAs.
(4) evidence:
The rationale presented.
(5) alternative regulatory choices the EBA should consider:
Excluding “widely used” from being a criteria to be applied when determining whether an exemption should be granted. It is ambiguous and calls for uncertainty by the mere lack of an appropriate definition.
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.
(1) response to question:Sec. 8.1.b of the GL on the ASPSP being obligated to provide an explanation on problems not having been resolved is unclear in our view - to what end is this required to be provided? In the event problems are not resolved no exemption should be granted, whether the ASPSP is able to provide an explanation for it is irrelevant.
(2) specific points to which the comment relates:
Art. 33.6.d of the RTS, Sec. 8.1.b of the GL.
(3) rationale:
Uncertainties as for what this entails. Having guidelines in place on ASPSPs being required to providing information comprising explanations as to why problems are not solved appears to be an obligation that will be an unnecessary burden for the ASPSPs and the CAs, while not providing any comfort for the TPPs.
(4) evidence:
GLs not in line with RTS.
(5) alternative regulatory choices the EBA should consider:
Delete the wording from the GLs.
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.
(1) response to question:The assessment form does not include any section dedicated to establish whether the requirements for granting an exemption have been met, which is what is to be evaluated by the EBA under the RTS. The aim is to ensure an aligned application of the rationale for granting an exemption - to ensure this the arguments for granting an exemption should be elaborated on rather than the rationale for refusal.
One of the things enabled through PSD2 is harmonisation of the landscape across the EU and spreading innovation across markets. If no actual consultation is required with EBA, how will it be ensured that the quality of the interfaces and threshold for granting exemption will be identical across all EU?
(2) specific points to which the comment relates:
Art. 33.6 of the RTS, Sec. 9 of the GLs, Annex 1 in the GLs.
(3) rationale:
The method for the assessment is contrary to what is prescribed in the RTS.
(4) evidence:
References sections of the RTS and the GLs.
(5) alternative regulatory choices the EBA should consider:
Alter the GLs to ensure compliance with the RTS.
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?
(1) response to question:We are particularly am worried about the risk of the ASPSPs taking a long time in granting us access to their APIs. What do we do if it takes several months for the ASPSP to review our application for accessing production APIs? A number of ASPSPs whose APIs we are currently testing require a number of questionnaires, meetings, interviews and background checks in order to grant access. Obviously, this takes time.
(2) specific points to which the comment relates:
This is not in any manner addressed in the GLs. Would be good to have a deadline tied to making available production environments.
(3) rationale:
(4) evidence:
(5) alternative regulatory choices the EBA should consider:
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.
(1) response to question:No, the GLs do not provide for much more clarity. Reference is made to our answers and rationales in respect of questions Q1-Q9.
(2) specific points to which the comment relates:
(3) rationale:
(4) evidence:
(5) alternative regulatory choices the EBA should consider: