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
Guideline 1 states, that the competent authorities should assess whether an ASPSP is compliant with the requirements in Guideline 2 to 8. It is however not clear if an ASPSP active in several markets (via the right to passport their services under PSD2) will have to apply for an exemption to all host-country CA’s or only to their home-country CA?
We support, that the EBA has not set specific numeric availability and perfor-mance targets for each of the KPIs in Guideline 2.
However, we seek clarification regarding Guideline 2.4 (b) where the EBA pro-poses that “ASPSPs should count the interface as “down” when five consecutive requests for access to information for the provision of payment initiation services or account information services are not replied to within 30 seconds.” Finance Denmark believes that this definition leaves room for uncertainty and interpreta-tion. Instead up time" & "down time" should be calculated in an IT industry ac-cepted way, and in particular it should be a method that allows ASPSPs to de-termine that the systems are down and that the majority of TPPs using the dedi-cated interface are affected.
Also, it is not evident in what context the calculation of downtime is to be made. If an ASPSP IT systems, providing services in multiple countries, are not available in one country does that then mean that services are down in all countries? I.e. if a system fails in the branch of country A, but are running in the other countries are the system then down in all markets or only in country A?
We support the requirements in Guideline 3 regarding publication of statistics. We agree, that publication in advance of September 2019 would be impractical. We therefor support, that it is a plan for the publication of statistics, that the ASPSPs must provide the CA when applying for an exemption. It is our under-standing that publication on i.e. the ASPSPs website is sufficient."
We do however think it is essential to make it possible for an IT-group service center or one common technical service provider to fulfill the stress testing requirements on behalf on multiple ASPSPs.
In Denmark the majority of ASPSP use an IT-group service center or one common technical service provider offering them the same services / processes / infrastructures in a practical way. The sole ownership of these IT-groups/service pro-viders lies with the ASPSP.
For these ASPSPs the interfaces will be developed and maintained by the IT-groups/service providers. This is expected to shorten the time-to-market for the interfaces and resolution of problems can be handled efficiently. For AISPs and PISPs this will mean that they will have to integrate with fewer testing facilities. This could help the possibility of providing the technical specifications and testing facilities before March 2019. It would make it more plausible for PSPs to comply with the RTS requirements as soon as possible, as the EBA’s has wel-comed in its Opinion on the transition from PSD1 to PSD2.
We would therefore suggest, that CA’s in their implementation of the Guidelines can make arrangements with the ASPSP-community and its main IT-group service centers on how to handle stress testing, design, testing etc., in a way that takes into account these practical issues, as long as the requirements of the RTS and the Guidelines are fulfilled.
We welcome the clarification, that the monitoring of CA’s cannot plausibly be one of the requirements for granting an exemption to an ASPSP as stated in paragraph 32 of the CP.
In particular, it would be helpful to clarify that safeguards, that apply to both channels of access (the PSU interface and the dedicated interface), are not obstacles. I.e. when a text message is sent to confirm a requested cross boarder transfer, or to have the PSU use SCA when the first request for information or payment initiation is received. The ASPSP would normally always require these steps when an electronic payment transaction or any other committing transaction is initiated. This is in our opinion not an obstacle, because the process is the same regardless of whether the PSU uses the standard bank interface or a TPP.
The very first time an AISP makes a request for account information on behalf of a PSU, SCA is required. As a normal part of the authentication the purpose of the authentication will be presented to the PSU (i.e. X is getting account information from your account Y). It is an important security principle to present the purpose (and to use the authentication for that purpose only). It will assure the ASPSP that the authenticated PSU initiated the request and it will cause no delay, whereas not presenting the purpose would deviate from the normal process and therefor might cause uncertainty and ‘friction’ for the PSU. In our opinion the present this the purpose of the authentication to the PSU as a normal part of the first authen-tication flow (without adding extra pages to read or buttons to click on) can’t be viewed as an obstacle.
We also seek clarification on the connection between Guideline 5.2.c and the EBA opinion on the implementation if the RTS on SCA and CSC published simultaneously. In paragraph 13 of the opinion the EBA states: “It is the EBA’s view, after discussing it with the Commission, that, where AIS or PIS are provided to a pay-ment service user (PSU) following a contract that has been signed by both par-ties, ASPSPs do not have to check consent. It suffices that AISPs and PISPs can rely on the authentication procedures provided by the ASPSPs to the PSU, when it comes to the expression of explicit consent.”
For Finance Denmark it is however not clear, how the ASPSPs would know if the PSU and PISP/AISP have signed a contract or not. Or if the statement in paragraph 12 is to be understood as an obligation for the ASPSPs to check if there is a contract? If so, how does this corollate with ASPSPs being prohibited from doing an additional check of the PSU’s consent. In general Finance Denmark is of the opinion, that the ASPSP should always be able to rely on the PSUs use of the ASPSPs authentication, which indicates that the PSU has given the TPP the re-quired consent.
Finally, there is also a link to Article 68 (5) PSD2 where the ASPSP may deny AISPs or PISPs access to a payment account for objectively justified and duly evidenced reasons relating to unauthorized or fraudulent access to a payment ac-count. In our opinion this could for instance be the lack of PSU consent.
We therefor think a clarification is needed regarding Guideline 5.2.c.
We especially agree with the EBA’s view, that ‘design’ can plausible only be in relation to the legal requirements for access and data detailed in PSD2 and the RTS and that it cannot plausibly refer to a list of requirements that are independ-ent of the legislation.
Referring to our answer in Q2 we do however think it is essential to make it possible for an IT-group service center or one common technical service provider to fulfill the design and testing requirements on behalf on multiple ASPSPs.
We also refer to our answer to Q2 and suggest, that the assessment of ‘widely used’ could be handled by assessing an IT-group service acting on behalf of multiple banks.
Referring to our answer to Q2 and suggest that resolution of problems could be handled an IT-group service acting on behalf of multiple banks. This would be efficient and mean that AISPs and PISPs would have to consult fewer points of contact/information in case of a problem.
As pointed out in the answer to Q4, we think there is a need for further clarifica-tion regarding Guideline 5.2.c, and what constitutes an addition check of the consent.
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.
Finance Denmark welcomes the opportunity presented by the EBA to comment on the Consultation Paper. In general, Finance Denmark supports the need identified by the EBA to clarify the requirements ASPSPs need to meet to obtain ex-emption and the information CAs should consider. We also welcome, that the Guidelines are pragmatic in nature, as this is essential for ASPSPs to be able to meet the September 2019 deadline.Guideline 1 states, that the competent authorities should assess whether an ASPSP is compliant with the requirements in Guideline 2 to 8. It is however not clear if an ASPSP active in several markets (via the right to passport their services under PSD2) will have to apply for an exemption to all host-country CA’s or only to their home-country CA?
We support, that the EBA has not set specific numeric availability and perfor-mance targets for each of the KPIs in Guideline 2.
However, we seek clarification regarding Guideline 2.4 (b) where the EBA pro-poses that “ASPSPs should count the interface as “down” when five consecutive requests for access to information for the provision of payment initiation services or account information services are not replied to within 30 seconds.” Finance Denmark believes that this definition leaves room for uncertainty and interpreta-tion. Instead up time" & "down time" should be calculated in an IT industry ac-cepted way, and in particular it should be a method that allows ASPSPs to de-termine that the systems are down and that the majority of TPPs using the dedi-cated interface are affected.
Also, it is not evident in what context the calculation of downtime is to be made. If an ASPSP IT systems, providing services in multiple countries, are not available in one country does that then mean that services are down in all countries? I.e. if a system fails in the branch of country A, but are running in the other countries are the system then down in all markets or only in country A?
We support the requirements in Guideline 3 regarding publication of statistics. We agree, that publication in advance of September 2019 would be impractical. We therefor support, that it is a plan for the publication of statistics, that the ASPSPs must provide the CA when applying for an exemption. It is our under-standing that publication on i.e. the ASPSPs website is sufficient."
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 generally agree with the requirements proposed in Guideline 4.We do however think it is essential to make it possible for an IT-group service center or one common technical service provider to fulfill the stress testing requirements on behalf on multiple ASPSPs.
In Denmark the majority of ASPSP use an IT-group service center or one common technical service provider offering them the same services / processes / infrastructures in a practical way. The sole ownership of these IT-groups/service pro-viders lies with the ASPSP.
For these ASPSPs the interfaces will be developed and maintained by the IT-groups/service providers. This is expected to shorten the time-to-market for the interfaces and resolution of problems can be handled efficiently. For AISPs and PISPs this will mean that they will have to integrate with fewer testing facilities. This could help the possibility of providing the technical specifications and testing facilities before March 2019. It would make it more plausible for PSPs to comply with the RTS requirements as soon as possible, as the EBA’s has wel-comed in its Opinion on the transition from PSD1 to PSD2.
We would therefore suggest, that CA’s in their implementation of the Guidelines can make arrangements with the ASPSP-community and its main IT-group service centers on how to handle stress testing, design, testing etc., in a way that takes into account these practical issues, as long as the requirements of the RTS and the Guidelines are fulfilled.
Question 3: Do you agree with the EBA’s assessments on monitoring? If not, please provide your reasoning.
We agree with the EBA’s assessment on monitoring. In this context it is our under-standing, that it is sufficient to publish the statistics required in Guideline 3 on the ASPSPs website.We welcome the clarification, that the monitoring of CA’s cannot plausibly be one of the requirements for granting an exemption to an ASPSP as stated in paragraph 32 of the CP.
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.
However, we think there is a need for further clarification regarding Guideline 5.2.c, and what constitutes an additional check of the consent. The understanding of this is especially important when assessing Article 30(2, a) of the RTS, which requires the ASPSPs interface to enable AISPs and PIPSs to instruct the ASPSP to start authentication based on the consent of the PSU. The consent and SCA are inevitably link to each other.In particular, it would be helpful to clarify that safeguards, that apply to both channels of access (the PSU interface and the dedicated interface), are not obstacles. I.e. when a text message is sent to confirm a requested cross boarder transfer, or to have the PSU use SCA when the first request for information or payment initiation is received. The ASPSP would normally always require these steps when an electronic payment transaction or any other committing transaction is initiated. This is in our opinion not an obstacle, because the process is the same regardless of whether the PSU uses the standard bank interface or a TPP.
The very first time an AISP makes a request for account information on behalf of a PSU, SCA is required. As a normal part of the authentication the purpose of the authentication will be presented to the PSU (i.e. X is getting account information from your account Y). It is an important security principle to present the purpose (and to use the authentication for that purpose only). It will assure the ASPSP that the authenticated PSU initiated the request and it will cause no delay, whereas not presenting the purpose would deviate from the normal process and therefor might cause uncertainty and ‘friction’ for the PSU. In our opinion the present this the purpose of the authentication to the PSU as a normal part of the first authen-tication flow (without adding extra pages to read or buttons to click on) can’t be viewed as an obstacle.
We also seek clarification on the connection between Guideline 5.2.c and the EBA opinion on the implementation if the RTS on SCA and CSC published simultaneously. In paragraph 13 of the opinion the EBA states: “It is the EBA’s view, after discussing it with the Commission, that, where AIS or PIS are provided to a pay-ment service user (PSU) following a contract that has been signed by both par-ties, ASPSPs do not have to check consent. It suffices that AISPs and PISPs can rely on the authentication procedures provided by the ASPSPs to the PSU, when it comes to the expression of explicit consent.”
For Finance Denmark it is however not clear, how the ASPSPs would know if the PSU and PISP/AISP have signed a contract or not. Or if the statement in paragraph 12 is to be understood as an obligation for the ASPSPs to check if there is a contract? If so, how does this corollate with ASPSPs being prohibited from doing an additional check of the PSU’s consent. In general Finance Denmark is of the opinion, that the ASPSP should always be able to rely on the PSUs use of the ASPSPs authentication, which indicates that the PSU has given the TPP the re-quired consent.
Finally, there is also a link to Article 68 (5) PSD2 where the ASPSP may deny AISPs or PISPs access to a payment account for objectively justified and duly evidenced reasons relating to unauthorized or fraudulent access to a payment ac-count. In our opinion this could for instance be the lack of PSU consent.
We therefor think a clarification is needed regarding Guideline 5.2.c.
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 EBA’s assessments for design and testing proposed in Guideline 6.We especially agree with the EBA’s view, that ‘design’ can plausible only be in relation to the legal requirements for access and data detailed in PSD2 and the RTS and that it cannot plausibly refer to a list of requirements that are independ-ent of the legislation.
Referring to our answer in Q2 we do however think it is essential to make it possible for an IT-group service center or one common technical service provider to fulfill the design and testing requirements on behalf on multiple ASPSPs.
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 generally agree with the EBA’s assessment for ‘widely used’. We welcome the clarification that the activities of credit institutions should also be included in the assessment of ‘widely used’.We also refer to our answer to Q2 and suggest, that the assessment of ‘widely used’ could be handled by assessing an IT-group service acting on behalf of multiple banks.
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 generally agree with the requirements proposed in Guideline 8.Referring to our answer to Q2 and suggest that resolution of problems could be handled an IT-group service acting on behalf of multiple banks. This would be efficient and mean that AISPs and PISPs would have to consult fewer points of contact/information in case of a problem.
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 proposed Guideline 9. We agree with the pragmatic ap-proach and the fact that CAs are given the possibility of submitting the form in Annex 1 covering more than one ASPSPs. We also think that this should be a pos-sibility for ASPSPs using the same IT-group, as stated in our answer to Q2. This would help the CAs carry out assessments needed in the short period leading up to September 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?
Finance Denmark is concerned with the consequences if the application is denied. What if an ASPSPs application is denied close to the 14 September 2019-deadline. Will the ASPSP be non-compliant? We propose that the Guidelines in-clude a grace period if that happen.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.
In general, Finance Denmark agree with the level of detail set out in the draft Guidelines as proposed in this Consultation Paper.As pointed out in the answer to Q4, we think there is a need for further clarifica-tion regarding Guideline 5.2.c, and what constitutes an addition check of the consent.