Response to public hearing on the Consultation paper on the amendment of the RTS on SCA&CSC under PSD2
Go back
Furthermore, we would be pleased if the EBA could specify its point of view regarding the right for ASPSPs to revert to SCA at any time if they have objectively justified and duly evidenced reasons relating to unauthorised or fraudulent access and the conditions to report to their national competent authority, upon request, the reasons for applying SCA. In our sense, fraud should be sufficiently defined to avoid an excessive interpretation by ASPSPs, thus avoiding any abusive blocking. We would suggest some kind of control on this reimplementation of SCA, eg : only possible if duly notified, justified, and accepted, by the relevant NCA.
As we understand and respect the EBA’s point of view, we are convinced that the wording of PSD2 allows not only the extension of the SCA renewal delay, but also the means of renewing this consent. In fact, the following interpretation has been made by Bird & Bird law firm :
Based on the wording of Article 36(5)(b) of the RTS, one could take the view that (1) a background refresh is not an instance of the payer accessing its payment account online (which in principle requires SCA under PSD2) but instead an instance of the AISP (but not the payer) accessing the payment account online and therefore not an event requiring SCA under PSD2.
(Source: https://www.twobirds.com/en/news/articles/2021/global/eba-consults-on-changes-to-strong-customer-authentication)
This interpretation of the PSD2 is more in line with the views of the Commision at the time the PSD2 was drafted: the multitude of use cases of the AIS was not discovered at the time, and the legislator just envisioned the possibility for the PSU to consult several of its accounts through one interface. The possibility to fetch data in between connections without an active intervention of the PSU, in order to fulfill one of the said use cases, was not taken into account, and that’s why it is excluded by the current wording of the PSD2. A simple renewal of the consent, or an opt out system, would actually be possible through PSD2. Such a system would benefit the whole ecosystem.
However, we understand that the EBA is firm on its interpretation of the PSD2, a position that we regret but respect if the EBA is not willing to reconsider its interpretation. Taking into account this position, we would like to thanks again the EBA's recognition of the burden and limit of the 90 days limit, which provoked harmful effects on the consumers (impossibility to fluidly use the services, lack of understanding of the burden imposed on them, frustration) and the TPP’s and their customers (massive loss of business, not being able to be the new innovative services that the PSD2 promised to create).
An extension from 90 to 180 days is already a good improvement, but it is unfortunately not enough to be a real game changer in this situation. In fact, as the services are made today, the 90 days SCA renewal is basically the same as losing all our customers every 3 months. Not understanding this SCA renewal or missing the notifications, a big part of the customers miss this opportunity, causing the TPP’s B2B partners to deploy massive communication campaigns to bring back their own users (the TPPs’ PSUs) and invite them in reconnecting to benefit from services they never wanted to stop. The TPPs are losing business with a too short renewal delay, as well as their own business partners.
To be a real game changer, the delay must be extended to at least one year. In terms of advantages, it would allow the consumers to really adopt and use those products. They would not have to support a burden they do not want in the first place. The feedback that the TPPs have from the consumers is clear: they want to have a fully functional service, without their intervention. They simply do not understand why they are being asked to renew their SCA and often complain to us that they do not feel the need or the use for it. They want to have a service that works the same way as all the other types of services they know (financial or not). There is absolutely no service to which you must renew your consent less than every year. This extension to at least one year would allow the TPPs and their business partners to really develop their business. It would be key to finally make their activity viable and a succes, and would be the real beginning of a functional and efficient open banking market.
In terms of risk to extending the renewal period to one year or more, the only one opposed is the risk of fraud. It is to be noted that extending to this point or above the delay would not be a problem at all. TPPs and APSPs monitor fraud, and up to this day, the data collected prove the AIS service is at very low risk. We have never received any complaints for fraud cases from our customers/consumers and never had any case of fraud. Moreover, we do understand that the renewal delay would be longer in the situation of the premium APIs. We are noting that, if a longer delay is not a risk in this setup, it is not a risk with the default API under PSD2. The premium API do nothave for purpose to be actually different from the default ones, just basically allowing to fetch additional data. We would therefore, based on everything that was exposed here, suggest to maintain the principle of this extension, and would strongly advise to make it more than one year.
In addition, it is to be noted as well that TPPs face unfair competition with EBICS T.
For memory, there are 2 EBICS:
EBICS TS, which concerns payment ; and
EBICS T, which concerns access to bank account.
EBICS TS is exempted from SCA in some European Countries, according to the PSD2 article 17. ETPPA has no objection with this exemption.
EBICS T is an interface which allows access to bank account information. ETPPA thinks EBICS T is in the scope of the article 10 of the PSD2 RTS, as EBICS T allows access to :
1) the balance of one or more designated payment accounts ; and
2) the payment transactions executed in the last 90 days through one or more designated payment accounts.
When a client accesses account information via EBICS T, no SCA is required in some countries (like France). On the contrary, when this same client wants to access account information via a PSD2 API, the client will have to perform a SCA. We support that the SCA rules should apply in the same way for all interfaces, both EBICS T and PSD2 API (and so no matter which solution is selected).
Q1. Do you have any comments on the proposal to introduce a new mandatory exemption for the case when the information is accessed through an AISP and the proposed amendments to Article 10 exemption?
We fully agree to this proposal to introduce a new mandatory exemption when the information is accessed through an AISP, and we express our gratefulness toward the EBA for taking fairly and fully in consideration this question. Indeed, introducing this mandatory exemption for all types of accounts (personal and professional) will greatly help the harmonization of the services across the EU, an essential condition for their success. It is an obvious gain for the consumers, who will not suffer anymore from uncoordinated anxiety-inducing SCAs. It will help their adoption and appropriation of their account aggregation services, without degrading at all the level of security that is due to them. In the TPP’s and their B2B clients’ end, this will really improve their operational management of their services, their business and the adoption of their service, helping create a more functional and innovative open banking market, fulfilling the main goal of the PSD2. From the point of view of the ASPSPs, first they will benefit from the above, a large part of them using the TPPs services. But, more importantly, it will help them rationalize the management of their SCA demands, pleasing at the same time their consumers who are simultaneously consumers of the TPPs services. Therefore, considering the goals to achieve and the means put in place, we think this proposition is optimum, and again we are saluting the careful work of the EBA.Furthermore, we would be pleased if the EBA could specify its point of view regarding the right for ASPSPs to revert to SCA at any time if they have objectively justified and duly evidenced reasons relating to unauthorised or fraudulent access and the conditions to report to their national competent authority, upon request, the reasons for applying SCA. In our sense, fraud should be sufficiently defined to avoid an excessive interpretation by ASPSPs, thus avoiding any abusive blocking. We would suggest some kind of control on this reimplementation of SCA, eg : only possible if duly notified, justified, and accepted, by the relevant NCA.
Q2. Do you have any comments on the proposal to extend the timeline for the renewal of SCA to 180-days?
Budget Insight would like to first acknowledge the rationale behind the EBA’s decision to not review the means to renew the PSU’s consent.As we understand and respect the EBA’s point of view, we are convinced that the wording of PSD2 allows not only the extension of the SCA renewal delay, but also the means of renewing this consent. In fact, the following interpretation has been made by Bird & Bird law firm :
Based on the wording of Article 36(5)(b) of the RTS, one could take the view that (1) a background refresh is not an instance of the payer accessing its payment account online (which in principle requires SCA under PSD2) but instead an instance of the AISP (but not the payer) accessing the payment account online and therefore not an event requiring SCA under PSD2.
(Source: https://www.twobirds.com/en/news/articles/2021/global/eba-consults-on-changes-to-strong-customer-authentication)
This interpretation of the PSD2 is more in line with the views of the Commision at the time the PSD2 was drafted: the multitude of use cases of the AIS was not discovered at the time, and the legislator just envisioned the possibility for the PSU to consult several of its accounts through one interface. The possibility to fetch data in between connections without an active intervention of the PSU, in order to fulfill one of the said use cases, was not taken into account, and that’s why it is excluded by the current wording of the PSD2. A simple renewal of the consent, or an opt out system, would actually be possible through PSD2. Such a system would benefit the whole ecosystem.
However, we understand that the EBA is firm on its interpretation of the PSD2, a position that we regret but respect if the EBA is not willing to reconsider its interpretation. Taking into account this position, we would like to thanks again the EBA's recognition of the burden and limit of the 90 days limit, which provoked harmful effects on the consumers (impossibility to fluidly use the services, lack of understanding of the burden imposed on them, frustration) and the TPP’s and their customers (massive loss of business, not being able to be the new innovative services that the PSD2 promised to create).
An extension from 90 to 180 days is already a good improvement, but it is unfortunately not enough to be a real game changer in this situation. In fact, as the services are made today, the 90 days SCA renewal is basically the same as losing all our customers every 3 months. Not understanding this SCA renewal or missing the notifications, a big part of the customers miss this opportunity, causing the TPP’s B2B partners to deploy massive communication campaigns to bring back their own users (the TPPs’ PSUs) and invite them in reconnecting to benefit from services they never wanted to stop. The TPPs are losing business with a too short renewal delay, as well as their own business partners.
To be a real game changer, the delay must be extended to at least one year. In terms of advantages, it would allow the consumers to really adopt and use those products. They would not have to support a burden they do not want in the first place. The feedback that the TPPs have from the consumers is clear: they want to have a fully functional service, without their intervention. They simply do not understand why they are being asked to renew their SCA and often complain to us that they do not feel the need or the use for it. They want to have a service that works the same way as all the other types of services they know (financial or not). There is absolutely no service to which you must renew your consent less than every year. This extension to at least one year would allow the TPPs and their business partners to really develop their business. It would be key to finally make their activity viable and a succes, and would be the real beginning of a functional and efficient open banking market.
In terms of risk to extending the renewal period to one year or more, the only one opposed is the risk of fraud. It is to be noted that extending to this point or above the delay would not be a problem at all. TPPs and APSPs monitor fraud, and up to this day, the data collected prove the AIS service is at very low risk. We have never received any complaints for fraud cases from our customers/consumers and never had any case of fraud. Moreover, we do understand that the renewal delay would be longer in the situation of the premium APIs. We are noting that, if a longer delay is not a risk in this setup, it is not a risk with the default API under PSD2. The premium API do nothave for purpose to be actually different from the default ones, just basically allowing to fetch additional data. We would therefore, based on everything that was exposed here, suggest to maintain the principle of this extension, and would strongly advise to make it more than one year.
In addition, it is to be noted as well that TPPs face unfair competition with EBICS T.
For memory, there are 2 EBICS:
EBICS TS, which concerns payment ; and
EBICS T, which concerns access to bank account.
EBICS TS is exempted from SCA in some European Countries, according to the PSD2 article 17. ETPPA has no objection with this exemption.
EBICS T is an interface which allows access to bank account information. ETPPA thinks EBICS T is in the scope of the article 10 of the PSD2 RTS, as EBICS T allows access to :
1) the balance of one or more designated payment accounts ; and
2) the payment transactions executed in the last 90 days through one or more designated payment accounts.
When a client accesses account information via EBICS T, no SCA is required in some countries (like France). On the contrary, when this same client wants to access account information via a PSD2 API, the client will have to perform a SCA. We support that the SCA rules should apply in the same way for all interfaces, both EBICS T and PSD2 API (and so no matter which solution is selected).