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
Also we consider publishing of data regarding existing interfaces is sensitive both from security (for example possibility to monitor results of DDOS attacks) and competition aspect. Our proposal is to make quarterly statistics available only to Competent Authority, who can then monitor ASPSPs based on KPIs previously defined.
Also we would like to note that API channel will not be initially used as widely as other interfaces and therefore it is not reasonable to use the same volumes for testing as for these channels. IT is also possible, that the usage pattern for API will not be similar to ASPSP own channels, if TPP will use automated process to query large number of customer data regularly. Possible issues arising will be revealed by monitoring and SLA breaches.
It is not clear whether ASPSPs are not allowed to check the consent or this is brought out as optional approach applicable when all of the the parties agree with that. Also it is not clear who is responsible for fraudulent behaviour in case when ASPSPs do not have information about consent and are executing TPP’s requests.
According to Berlin Group specification consent can be initiated from TPP interface, but it is saved in ASPSP’s database and therefore ASPSP is checking the consent. We have agreed to follow Berlin Group standard and propose that consent information is provided to ASPSP and it is always checked before executing requests.
When describing obstacles (point 36-41) terms “methods of access”; “access solutions”; “authentication procedures” and “authentication methods” are used. It is difficult to understand what exactly is meant with those terms. The proposal is to unify the terms and make it clear that “methods of access” are redirect, decoupled, embedded and “authentication methods” refer to authentication devices.
In Guideline 5.1 b it is stated that where the ASPSP has put in place only one method of access, an explanation of the reasons why this method of access is not an obstacle and how this method of access supports all authentication methods provided by the ASPSP to its PSU has to be provided.
We would like to propose that guidelines state clearly that providing only redirection method, where all the authentication devices are supported is sufficient to comply and not considered as an obstacle.
We have following concerns:
1. Banks in Estonia have agreed to follow Berlin Group API standard in order to provide one common API interface for TPP’s. However the API standard is not yet matured, with many aspects still not described or being reworked in subsequent versions. It is unclear whether banks need to freeze API development during the assessment period or is it allowed to continue improving the API’s as new versions of Berlin Group API standards are being published.
2. It is unclear whether the Competent Authority and EBA conducting the assessment, will have sufficient resources to conduct assessment for all the applicants at the same time.
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.
We agree with the approach, but would like to point out that it is difficult to measure exactly the downtime by this definition - for example network down will result in no requests at all. We propose to measure only the requests that have reached ASPSPs and calculate downtime based on those.Also we consider publishing of data regarding existing interfaces is sensitive both from security (for example possibility to monitor results of DDOS attacks) and competition aspect. Our proposal is to make quarterly statistics available only to Competent Authority, who can then monitor ASPSPs based on KPIs previously defined.
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.
We agree, but would like to specify the criterias for stress testing. It is not clear how to define „multiple firms“; „unusually high number of requests“; “extremely high number of concurrent sessions” and „large volumes of data“. We propose to have more clear measures for those criterias.Also we would like to note that API channel will not be initially used as widely as other interfaces and therefore it is not reasonable to use the same volumes for testing as for these channels. IT is also possible, that the usage pattern for API will not be similar to ASPSP own channels, if TPP will use automated process to query large number of customer data regularly. Possible issues arising will be revealed by monitoring and SLA breaches.
Question 3: Do you agree with the EBA’s assessments on monitoring? If not, please provide your reasoning.
We agree with the guideline.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.
In Guideline 5.2 c it is stated that requiring additional checks on consent is considered as an obstacle, because each firm is responsible for its own compliance with all relevant legislation. Furthermore, in „Opinion on the implementation of RTS and SCA“ point 13 it is stated that where AIS or PIS are provided to a payment service user (PSU) following a contract that has been signed by both parties, ASPSPs do not have to check consent.It is not clear whether ASPSPs are not allowed to check the consent or this is brought out as optional approach applicable when all of the the parties agree with that. Also it is not clear who is responsible for fraudulent behaviour in case when ASPSPs do not have information about consent and are executing TPP’s requests.
According to Berlin Group specification consent can be initiated from TPP interface, but it is saved in ASPSP’s database and therefore ASPSP is checking the consent. We have agreed to follow Berlin Group standard and propose that consent information is provided to ASPSP and it is always checked before executing requests.
When describing obstacles (point 36-41) terms “methods of access”; “access solutions”; “authentication procedures” and “authentication methods” are used. It is difficult to understand what exactly is meant with those terms. The proposal is to unify the terms and make it clear that “methods of access” are redirect, decoupled, embedded and “authentication methods” refer to authentication devices.
In Guideline 5.1 b it is stated that where the ASPSP has put in place only one method of access, an explanation of the reasons why this method of access is not an obstacle and how this method of access supports all authentication methods provided by the ASPSP to its PSU has to be provided.
We would like to propose that guidelines state clearly that providing only redirection method, where all the authentication devices are supported is sufficient to comply and not considered as an obstacle.
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 with the guideline.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.
We agree with the guideline. It is beyond ASPSP’s influence whether there will be ‘wide usage’ of API’s by the TPP’s or not. We propose that in guideline 7.2. It should be stated that evidence provided is limited to information provided in ASPSP’s public homepage as this is practical to check by the competent authority. We would also welcome a pan-European registry of ASPSP’s providing API’s to be created by EBA.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.
We agree with the guideline.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 agree with the guideline.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?
It is clear about the envisaged timelines to apply for fallback exemption prior to 2019 september. This means that documentation and sandbox for testing must be made available 6 months before. Estonian Banking Association believes that all major banks will apply for exemption.We have following concerns:
1. Banks in Estonia have agreed to follow Berlin Group API standard in order to provide one common API interface for TPP’s. However the API standard is not yet matured, with many aspects still not described or being reworked in subsequent versions. It is unclear whether banks need to freeze API development during the assessment period or is it allowed to continue improving the API’s as new versions of Berlin Group API standards are being published.
2. It is unclear whether the Competent Authority and EBA conducting the assessment, will have sufficient resources to conduct assessment for all the applicants at the same time.