Primary tabs

Estonian Banking Association

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.
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.
We agree with the guideline.
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.
We agree with the guideline.
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.
We agree with the guideline.
We agree with the guideline.
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.
We believe that the level of detail is sufficient.
Estonian Banking Association