Response to public hearing on the Consultation paper on the amendment of the RTS on SCA&CSC under PSD2
Go back
Cozy Cloud is service provider based - hopefully partially - on bank statements. We have seen the huge impact of DSP2 on our users. With DSP2 was gradually implemented, we not only have stoped our progress, but even had a globaly negative net growth on this service. Today we have stoped to invest on this service, it is just impossible to provide an acceptable user experience when requiring AISP services.
Few will confess such a situation. We can because it is not our only business.
But facts speaks for themselves : all french AISPs have either filed bankruptcy (LafinBox) or have been bought by banks (Linxo, Bankin, Budget Insight) (no nice exist here : just opportunities for banks to buy companies in difficulties, in order to acquire at low cost skills and technologie, and waiting for the time when data portability will be a reality)
You should read this article from Budget Insight (a french AISP) explaining that DSP2 made access to data much more difficult than before. The only advantage for them is that it created an entry barrier for new competitors...
https://www.larevuedudigital.com/open-banking-lacces-aux-donnees-des-banques-par-les-apis-de-dsp2-est-un-piege/
To understand the reasons for this situation, you should discuss with our user support service. They would list you thousands of users messages explaining the reasons to this sinking :
i) recurring SCA
ii) with hazardous periodicity
iii) with heterogeneous UX (sms, mobile app validation, emails...)
iv) with double SCA for API and for Scraping (scrapping remains unfortunately mandatory because DSP2 APIs do not cover all accounts data)
v) and they would point the level of services of APIs (amazingly poor and fluctuating over time and ASPSPs)
That's why 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. 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, while still increasing the level of security in comparison of before DSP2.
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 unauthorized 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.
As we fully agree with their answer, we copied it below. But before we point that even if we do agree that extending the timeline for the renewal of SCA to one year is legitimate, it is still not the real solution.
==> The solution would be for the AISPs to be responsible for collecting ACS renewals on behalf of the ASPSPs. This is legitimate because AISPs are regulated and submitted to strict constraints of transparency, organization etc...
but this solution is not in the scope of this proposal...
[Start of BudgetIsight's response with which we totally agree]
Cozy Cloud 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 concern 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?
Introductory note : no polite legal language, just down to earth reality from a startup who survived DSP2.Cozy Cloud is service provider based - hopefully partially - on bank statements. We have seen the huge impact of DSP2 on our users. With DSP2 was gradually implemented, we not only have stoped our progress, but even had a globaly negative net growth on this service. Today we have stoped to invest on this service, it is just impossible to provide an acceptable user experience when requiring AISP services.
Few will confess such a situation. We can because it is not our only business.
But facts speaks for themselves : all french AISPs have either filed bankruptcy (LafinBox) or have been bought by banks (Linxo, Bankin, Budget Insight) (no nice exist here : just opportunities for banks to buy companies in difficulties, in order to acquire at low cost skills and technologie, and waiting for the time when data portability will be a reality)
You should read this article from Budget Insight (a french AISP) explaining that DSP2 made access to data much more difficult than before. The only advantage for them is that it created an entry barrier for new competitors...
https://www.larevuedudigital.com/open-banking-lacces-aux-donnees-des-banques-par-les-apis-de-dsp2-est-un-piege/
To understand the reasons for this situation, you should discuss with our user support service. They would list you thousands of users messages explaining the reasons to this sinking :
i) recurring SCA
ii) with hazardous periodicity
iii) with heterogeneous UX (sms, mobile app validation, emails...)
iv) with double SCA for API and for Scraping (scrapping remains unfortunately mandatory because DSP2 APIs do not cover all accounts data)
v) and they would point the level of services of APIs (amazingly poor and fluctuating over time and ASPSPs)
That's why 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. 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, while still increasing the level of security in comparison of before DSP2.
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 unauthorized 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?
To be clear, Budget Insight (who is our AISP vendor), provided us a response proposal.As we fully agree with their answer, we copied it below. But before we point that even if we do agree that extending the timeline for the renewal of SCA to one year is legitimate, it is still not the real solution.
==> The solution would be for the AISPs to be responsible for collecting ACS renewals on behalf of the ASPSPs. This is legitimate because AISPs are regulated and submitted to strict constraints of transparency, organization etc...
but this solution is not in the scope of this proposal...
[Start of BudgetIsight's response with which we totally agree]
Cozy Cloud 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 concern 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).