Response to public hearing on the Consultation paper on the amendment of the RTS on SCA&CSC under PSD2

Go back

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?

The AFEPAME and its members 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.

Q2. Do you have any comments on the proposal to extend the timeline for the renewal of SCA to 180-days?

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 their 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 their 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 concern access to bank account.
EBICS TS is exempted from SCA in some European Countries, according to the PSD2 article 17. AFEPAME has no objection with this exemption.

EBICS T is an interface which allows access to bank account information. AFEPAME thinks EBICS T is in the scope of the article 10 of the PSD2 RTS, as EBICS T allows access to the PSU 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).

Q3. Do you have any comments on the proposed 6-month implementation timeline, and the requirement for ASPSPs to make available the relevant changes to the technical specifications of their interfaces not less than one month before such changes are required to be implemented?

For this amendment, time is of the essence: the AFEPAME would suggest reducing the standard 3-month notice on interface changes to one month, and as well reducing the implementation timeline to a maximum of 3 months. ASPSPs already have in place technical solutions (that includes access tokens) for account access. Extending the SCA time limit would reuse the same technical solution as ASPSPs already have in place. There would not be a need to introduce new technical solutions to meet an extended time limit.


industry associations

Name of the organization