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
FBF understands that Guideline 2.4.b clarifies that the ASPSP counts “the 5 consecutive requests for access to information for the provision of PIS or AIS not replied in 30 seconds” and that the request concerns the access to the ASPSP system only (i.e. should a SCA is needed, the execution of the SCA is not included in the timing of 30 seconds).
It has to be noted that to be able to start counting, the ASPSP is to receive the request. That means that network transit time or related issues are not taken into consideration, and that ASPSP can only start counting as soon as it has received the request.
Moreover, FBF would like to add that in the following cases, the performance of the ASPSP’s dedicated interface cannot be questioned:
- A request that is blocked or deleted at transmission level through the IP technical layer (router). The ASPSP is not able to detect the problem as no information is delivered by the router;
- The TPP request does not reach the ASPSP, even if the API is correctly working because of an internet service provider problem.
- This KPI reached or exceeded, cannot in itself considered as sufficient to confirm that the interface service of the ASPSP is actually down. Currently some websites such as « Down for everyone or just me. Com » gives information when web sites are down or not. As such a TPP could then notice a problem in terms of availability that would not occur for other TPP.
FBF would like to point that “5 consecutive requests not replied within 30 seconds” doesn’t constitute a KPI in line with the current practices of the ASPSPs when they monitor their web banking or the apps they deliver to their clients.
As ASPSPs have to deliver to TPPs the same service level as to the PSUs, we suggest EBA guidelines to be consistent with ASPSPs practices e.g. 90 % of the requests reacted upon by the ASPSP either positively or negatively (https response status codes as OK, error in the request, error in the response, no response) in less than one second and 95% in less of 3 seconds well received on a period of, a minima, one rolling hour (evaluation made out of scheduled maintenance periods).
The KPI should naturally be aligned with existing service level of each bank.
Maintenance periods scheduled regarding the needs of each type of our web banking clients are not specified to our clients out of an information message. No more information should be given about the API knowing that no maintenance period is scheduled during critical periods such as the end of the year in order to provide a maximum availability to payment processes.
Last comment, the usage of the KPI regarding the « 5 consecutive requests for access to information for the provision of PIS or AIS are not replied in 30 seconds » is not proportionate to all scenarios: the need of availability is not the same regarding a payment to be processed quickly, and the request for the access of an AISP processing one of the fourth request to access the PSU account they can process each day out of the PSU attendance. So, FBF would suggest using this KPI for PIS and for AIS-when-PSU-is-present.
Regarding the Guideline 3, FBF believes that the publication of quarterly figures and averages is sufficient as reporting with daily statistics would not allow a better understanding or analysis.
Guideline 4.2 b., c. and d. requests from an API to be able to deal with unusual high number of requests or concurrent sessions, and large volumes of data without failing specifying any value or reference.
ASPSPs have to deliver to TPPs the same level of service as they deliver to their clients on their websites or apps.
FBF understands that the stress tests have to be made whether to obtain the fallback exemption or to benefit again from the exemption when it was lost previously.
There can only be a comparison about how much time a payment initiation takes on the ASPSP website, and how much it takes through the PISP.
For CBPIISP, since the service does not exist on websites or app for ASPSP, there is no possible comparison point. Since there is no contract, no commitment on any service level can be.
Furthermore, protocols such as OAuth 2.0, which are used by API Initiatives, were precisely build to prevent the user to give its credential to the service provider. FBF would encourage the EBA to clarify in Guideline 5.2.a that TPPs do not need to know the static password with such international standards.
Regarding Guideline 6.2, from an operational and security point of view, the sandbox for testing environment has to be completely in line with the complete specifications and requirements of the API.
Regarding Guideline 6.3, the weaknesses could be reported during the testing period by the TPPs or the ASPSP testing teams. Therefore, FBF would amend the sentence as follows: “The ASPSP should provide to the competent authority a summary of the results of the testing for the above, including how the weaknesses identified during the usage of the sandbox period have been solved”.
Does EBA have any recommendation in terms of tests (assuming they are non-discriminant nor designed as obstacle) ensuring correct connectivity between the ASPSP and the TPP?
Regarding Guideline 6.4, we would like more information about which initiatives are qualified as “market initiative” or what is the process to be qualified so. Indeed, a protocol used among several entities of a large group can be wider than a published standard followed by few banks.
Regarding Guideline 6.4 b., it has to be taken into account that specific data could be given by the PSU, in particular for international transfer in some instances. This activity should not be included into the Guideline 6.4 b. as an ASPSP can have a legitimate role to ask for this information without additional reporting.
Regarding the full Guideline 6, does it need to be applied when the ASPSP does not apply for the fallback exemption?
FBF would like to comment on Rationale 47 that ASPSPs will not be able to differentiate genuine from fake acknowledgements of application.
Nevertheless, we understand from Guideline 7.2 that ASPSPS do have to actively communicate on the availability of their testing facilities, which is not required in the directive nor the RTS.
To comply with rule of law, ASPSPs shall be granted transparent and equitable process each time negative comments are issued by CA to EBA. Such process shall allow notably ASPSPs to defend any position taken including additional hearings and right to appeal.
As a matter of fact, the public consultation will be closed on August 13 and we do not have any idea of the moment when the final guidelines are published.
ASPSPs will need time to adapt their API for exemption purpose to the final version of these Guidelines.
Is the exemption granted by the CA to the ASPSP necessarily full i.e. on the whole scope of services: AIS services and PIS services and PIIS services or can it be partial i.e. either AIS or PIS or PIIS services?
We would need precisions to avoid litigations and situations where international banks have to deal with multiple CAs.
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 understand that guideline 2.4 refers only to guideline 2.2 i.e. the availability of the interface in terms of downtime.FBF understands that Guideline 2.4.b clarifies that the ASPSP counts “the 5 consecutive requests for access to information for the provision of PIS or AIS not replied in 30 seconds” and that the request concerns the access to the ASPSP system only (i.e. should a SCA is needed, the execution of the SCA is not included in the timing of 30 seconds).
It has to be noted that to be able to start counting, the ASPSP is to receive the request. That means that network transit time or related issues are not taken into consideration, and that ASPSP can only start counting as soon as it has received the request.
Moreover, FBF would like to add that in the following cases, the performance of the ASPSP’s dedicated interface cannot be questioned:
- A request that is blocked or deleted at transmission level through the IP technical layer (router). The ASPSP is not able to detect the problem as no information is delivered by the router;
- The TPP request does not reach the ASPSP, even if the API is correctly working because of an internet service provider problem.
- This KPI reached or exceeded, cannot in itself considered as sufficient to confirm that the interface service of the ASPSP is actually down. Currently some websites such as « Down for everyone or just me. Com » gives information when web sites are down or not. As such a TPP could then notice a problem in terms of availability that would not occur for other TPP.
FBF would like to point that “5 consecutive requests not replied within 30 seconds” doesn’t constitute a KPI in line with the current practices of the ASPSPs when they monitor their web banking or the apps they deliver to their clients.
As ASPSPs have to deliver to TPPs the same service level as to the PSUs, we suggest EBA guidelines to be consistent with ASPSPs practices e.g. 90 % of the requests reacted upon by the ASPSP either positively or negatively (https response status codes as OK, error in the request, error in the response, no response) in less than one second and 95% in less of 3 seconds well received on a period of, a minima, one rolling hour (evaluation made out of scheduled maintenance periods).
The KPI should naturally be aligned with existing service level of each bank.
Maintenance periods scheduled regarding the needs of each type of our web banking clients are not specified to our clients out of an information message. No more information should be given about the API knowing that no maintenance period is scheduled during critical periods such as the end of the year in order to provide a maximum availability to payment processes.
Last comment, the usage of the KPI regarding the « 5 consecutive requests for access to information for the provision of PIS or AIS are not replied in 30 seconds » is not proportionate to all scenarios: the need of availability is not the same regarding a payment to be processed quickly, and the request for the access of an AISP processing one of the fourth request to access the PSU account they can process each day out of the PSU attendance. So, FBF would suggest using this KPI for PIS and for AIS-when-PSU-is-present.
Regarding the Guideline 3, FBF believes that the publication of quarterly figures and averages is sufficient as reporting with daily statistics would not allow a better understanding or analysis.
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.
FBF agrees with the fact that stress tests should only be conducted by ASPSPs.Guideline 4.2 b., c. and d. requests from an API to be able to deal with unusual high number of requests or concurrent sessions, and large volumes of data without failing specifying any value or reference.
ASPSPs have to deliver to TPPs the same level of service as they deliver to their clients on their websites or apps.
FBF understands that the stress tests have to be made whether to obtain the fallback exemption or to benefit again from the exemption when it was lost previously.
There can only be a comparison about how much time a payment initiation takes on the ASPSP website, and how much it takes through the PISP.
For CBPIISP, since the service does not exist on websites or app for ASPSP, there is no possible comparison point. Since there is no contract, no commitment on any service level can be.
Question 3: Do you agree with the EBA’s assessments on monitoring? If not, please provide your reasoning.
FBF agrees with EBA’s assessments on monitoring as monitoring is limited to 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.
Regarding Rationale 34, FBF would like to point out the consequence of using PSU credentials when the credential is a static password. Should the TPP be able to play again the password, this means the knowledge factor is gone and the authentication process would not be considered anymore as a strong one.Furthermore, protocols such as OAuth 2.0, which are used by API Initiatives, were precisely build to prevent the user to give its credential to the service provider. FBF would encourage the EBA to clarify in Guideline 5.2.a that TPPs do not need to know the static password with such international standards.
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.
Regarding Guideline 6.1, FBF agrees on the fact that only a summary of the specifications has to be published.Regarding Guideline 6.2, from an operational and security point of view, the sandbox for testing environment has to be completely in line with the complete specifications and requirements of the API.
Regarding Guideline 6.3, the weaknesses could be reported during the testing period by the TPPs or the ASPSP testing teams. Therefore, FBF would amend the sentence as follows: “The ASPSP should provide to the competent authority a summary of the results of the testing for the above, including how the weaknesses identified during the usage of the sandbox period have been solved”.
Does EBA have any recommendation in terms of tests (assuming they are non-discriminant nor designed as obstacle) ensuring correct connectivity between the ASPSP and the TPP?
Regarding Guideline 6.4, we would like more information about which initiatives are qualified as “market initiative” or what is the process to be qualified so. Indeed, a protocol used among several entities of a large group can be wider than a published standard followed by few banks.
Regarding Guideline 6.4 b., it has to be taken into account that specific data could be given by the PSU, in particular for international transfer in some instances. This activity should not be included into the Guideline 6.4 b. as an ASPSP can have a legitimate role to ask for this information without additional reporting.
Regarding the full Guideline 6, does it need to be applied when the ASPSP does not apply for the fallback exemption?
FBF would like to comment on Rationale 47 that ASPSPs will not be able to differentiate genuine from fake acknowledgements of application.
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.
FBF welcomes the alternative proposal described in the Guideline 7.2 should the ASPSP not be able to produce the information as listed in the Guideline 7.1.Nevertheless, we understand from Guideline 7.2 that ASPSPS do have to actively communicate on the availability of their testing facilities, which is not required in the directive nor the RTS.
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.
No comment.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.
When an ASPSP is operating in different European countries with the same API specifications, in order to avoid to go through different CAs for exemption (leading to different assessment forms sent to EBA regarding the same API), FBF believes that the ASPSP should only do once the procedure through the CA of the ASPSP’s home Member State.To comply with rule of law, ASPSPs shall be granted transparent and equitable process each time negative comments are issued by CA to EBA. Such process shall allow notably ASPSPs to defend any position taken including additional hearings and right to 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?
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 are a real concern for FBF.As a matter of fact, the public consultation will be closed on August 13 and we do not have any idea of the moment when the final guidelines are published.
ASPSPs will need time to adapt their API for exemption purpose to the final version of these Guidelines.
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.
We were expecting more information about the timeline to deliver the exemption. We propose that the demand for exemption is requested as soon as the testing period starts, so that it can be delivered during the 3 months of live “widely used” period. This is essential considering the tight schedule ahead of us.Is the exemption granted by the CA to the ASPSP necessarily full i.e. on the whole scope of services: AIS services and PIS services and PIIS services or can it be partial i.e. either AIS or PIS or PIIS services?
We would need precisions to avoid litigations and situations where international banks have to deal with multiple CAs.