Response to public hearing on the Consultation paper on the amendment of the RTS on SCA&CSC under PSD2
Go back
The proposed changes are very welcomed by our members across the EU TPP community, and we appreciate the EBA’s efforts to improve the end consumer’s ability to access their financial data. We thank the EBA for harmonising this aspect of the EU’s PSD2 implementation.
FDATA asks that the EBA clarify that SCA is required only when the PSU is present and requesting the data via an AISP. Our understanding of the RTS is that SCA should not be required when an AISP is requesting the data, under PSU consent, when the PSU is not present or online.
In the case where the AISP is accessing the account without the customer being present, SCA should not apply. As noted in RTS Article 36(5b), when the customer is not present, AISPs are limited to accessing the account data up to four times in a 24-hour period; the four instances do not include the times a PSU actively requests such information via the AISP.
SCA was intended to provide additional security, yet the EBA Consultation Paper lists multiple reasons why there is very little risk when an AISP is involved in accessing the data (paragraphs 32-35). SCA serves an essential purpose for payments, but not for account information access itself. Therefore it is reasonable and proportional to not require SCA for AISP access when the customer is not present, under the Article 10 exemption.
Of course, SCA should apply to account access under the Article 10 exemption if:
- there is a specific security concern as detailed in RTS Article 2; or
- the account is accessed for the first time, either directly or through an AISP, wherein the latter case this serves as the PSU’s consent and mandate for future access by the AISP.
Anything else would unnecessarily restrict the use of AISPs when the customer is not present.
FDATA agrees with Bird & Bird’s interpretation of the law: 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, and/or (2) AISPs have an unconditional right pursuant to the RTS to perform background refreshes irrespective of the use or non-use of an optional exemption to SCA by the ASPSP (i.e. the AISP’s right to perform a background refresh should be not made conditional on the ASPSP deciding to make use of an optional exemption). [https://www.twobirds.com/en/news/articles/2021/global/eba-consults-on-changes-to-strong-customer-authentication)]
If this is a possible interpretation of the law then it follows that any more stringent view does not meet the principle of proportionality without clear evidence of risk.
FDATA recommends not limiting the Article 10 exemption to just AISPs; it should have a broader context that includes PISPs. Doing so would secure and maintain fair competition amongst all PSPs, specifically enabling PISP services to be more competitive and allow for the development of user-friendly, accessible, and innovative means of payment. Extending the Article 10 exemption to include PISPs would meet the above objectives while not jeopardizing the safety of PSU’s funds and personal data.
However, we have concerns that the extension does not solve the root cause of the problem, and recommend that the EBA consider an alternative approach as part of the PSD2 review exercise. FDATA has spent a considerable amount of time and effort to analyse the problem, and in light of that, we recommend several possible approaches, one of which is to extend the timeline to 365 days instead of just 180 days. Below we articulate our rationale for these suggestions.
SCA and reauthentication, as it has been implemented, has produced more harm than good for end customers:
- It has nearly zero positive impact on bank security, in opposition to the objective of the rule [SCA does not make a material difference to bank security due to implementation inconsistencies];
- It poses a hassle to end customers, many of whom have used fintech services for years without the imposition of either SCA or the need to reauthenticate;
- It has proven to be a customer eduction nightmare, with no convincing argument for end-customers outside of 'it's the law';
- It creates poor customer outcomes, both by marring and creating friction in the customer journey, as well as potentially disconnecting them from critical TPP services that are meant to protect the customer's financial health.
Differing regionalised specifications across the EU to deliver SCA and the RTS are a function of differing levels of technological maturity and readiness to implement the open banking model. The significant divergence here means TPPs have to implement several different specifications (sometimes on a country-by-country basis), which adds unnecessary friction in the ecosystem, adding cost and additional compliance burdens for banks and TPPs alike, while providing no consistent security upswing, and frustrating end customers.
PSD2's political objective was to nurture those companies, improving competition, innovation and security in the EU payments market. However, currently the way Reauthentication and SCA work defeats the political objectives of PSD2 and fails to materially improve security to protect consumers. Moreover, it is anticompetitive at its core. Only TPPs, not banks, are disconnected from the customer data if the customer fails to log in to renew/reauthenticate within the required time frame, or if the reauthentication journey fails due to unavailable/non-working bank APIs.
If the consumer is cut off, they can rely only on time bound bank supplied services, rather than their chosen and contracted fintech supplier. This asymmetric data access is anticompetitive.
No other market allows incumbent firms to control their competitors’ market access, yet this is the de facto standard under PSD2. Banks can and do control TPPs’ ability to access customer data, despite an end customer granting that permission to the TPP; it is controlled both in part by how and when SCA is applied in the customer journey, and by the cliff-edge 90-day rule imposed by the SCA-RTS. Changing the 90-day timeframe to 180-days does not fix this cliff-edge. This asymmetric control of market access is anticompetitive.
And in no other market are incumbent firms in control of their competitors’ relationship with their end customers, yet this is exactly what PSD2 enables, as it puts banks in charge of reminding TPP customers of the data access connection and service. Consent resides with the TPP/fintech, however reauthentication takes place at the bank. This creates additional friction for the customer, who, in wishing to confirm their consent to the TPP, is required to reauthenticate at the bank. This gives banks the competitive advantage of being obstructionist in the commercial relationship between the end customer and their chosen service provider (the fintech). This asymmetric interference in the customer relationship is anticompetitive.
SCA and Reauthentication is unique to payments alone; the common practice across banking is for an initial, explicit opt-in to any service, and an easy (1-click) opt-out to ensure that customers are not locked in. For example, this is the case with direct debits. Requiring AISPs to obtain a regularly recurring re-opt-in of their entire customer base is not only unique across all industries that require consent, but it is completely disproportionate to the low risk of AISP services.
Requiring not just re-consent opt-in, but applying SCA on top of that (performed via the ASPSP, an intermediary, not the AISP with whom the customer has a direct relationship) is an extreme and punitive measure for a low risk service. Direct debit is riskier than account information services, yet direct debit requires less stringent, opt-out measures.
FDATA recommends the EBA explore an alternative, best practice approach as part of the PSD2 review: an initial explicit opt-in consent given to the AISP, with a one-time SCA validation via the ASPSP. It would also best serve the market to have an easy, 1-click opt-out feature via a dashboard at the AISP. Shifting to a consent based model, rather than a reauthentication model, is a reasonable compromise that puts the customer in charge of how and with whom their data is shared, and puts the management of that relationship between the two interested parties, without the interference of an intermediary.
Should the EBA choose to maintain the current reauthentication process, FDATA recommends extending the timeline for renewal to 365 days, to allow for a longer, uninterrupted connection for end consumers.
Over the course of 2020, FDATA collected evidence of the degree to which the SCA-RTS requirement negatively impacts both TPPs and customers. The evidence, highlighted from a broad sample of mostly mature TPPs, showed that under the 90 Day Reauth requirement, customer attrition rates span between 13-65% depending on the business model. These rates are simply not economically sustainable at either end of the spectrum, with firms losing customers who fail to reauthenticate for a variety of mostly technical and behavioural reasons, not because of a low service value. Moreover, some banks have an exemption to providing an API, and instead have stood up a modified customer interface (MCI). Due to the nature of MCIs, they require a customer be present for every data transfer from the bank to a TPP. In this case, the SCA and 90 Day rules are an obstacle to a number of use cases, and results in a near 100% customer attrition rate for the TPP.
Customers also suffer from being disconnected from valuable services that allow them to better manage their money, beyond what their ASPSP can provide. Not only are those services stopped, but those who renew post day 90 (and in the proposed 180 day extension, this same circumstance applies) are forced to set up those services again from scratch, often at the cost of considerable user friction.
For end customers, this is a terrible customer journey which places obstacles in front of the customer, hindering their ability to consume TPP services. It erodes the value of the propositions, resulting in the objectives of PSD2 missing the mark entirely.
Two use cases in particular highlight just how detrimental these two rules can be. For example, small business account automation leveraging both payment account and savings account data. Because savings accounts are not payment accounts, they require SCA to be performed every time that data is accessed. (in fact, common practice is to pre-load the current and savings accounts to automate the bookkeeping.) Automated accountancy is hindered, as any reconciliation between payments and savings will have to be performed manually to enable savings data to be access using SCA. This is a return to manual loading of savings data renders an ‘automated’ solution null. This unintended consequence of the SCA/90 Day rule virtually destroys small business accounting system solutions and negatively impacts small businesses as well. The rules do double the harm.
Personal finance management (PFM) tools are also crippled by these rules. For consumers relying on budgeting apps, the need for SCA to access bank held savings, investment, and credit data means that automation, especially reminders and push notifications meant to keep customers aware of their finances are rendered moot. Customers have to perform SCA every time they check the PFM tool. And due to a dearth of available financial advice, any technology proxies for that advice cannot step in because data is restricted from flowing to the application that helps customers. This unintended consequence of the RTS leaves PFM tools hindered and customers worse off.
The accounting use case also showcases the extent to which users will go to circumvent the hassle of SCA reauthentication: SMEs who do not directly manage their accounting, but are clients of accounting firms who do leverage Open Banking to do bookkeeping on their behalf.
A 2020 survey of nearly 500 licensed bookkeepers and accountants by a cloud accounting firm, 100% of whose clients connect their accounts via Open Banking, showcased just how damaging SCA reauthentication is to small businesses
Of those accounting professionals asked, 97.9% confirmed that the requirement for clients to reauthenticate their bank feeds every 90 days caused significant problems. Nearly a hundred percent of respondents (97.3%) spent time chasing their clients to reauthenticate. 83% said their clients were not even familiar with the reauthentication process. And 76.6% said that they frequently had to deal with out-of-date accounting records because required reauthentication had not happened. And 69% said that they spend at least an extra hour of additional time per client per month helping clients reconnect their bank feeds. A quarter of respondents spent more than three hours per month per client chasing reauthentication. They don’t spend this time accounting, they spend it chasing reauthentication. 77% of respondents said that there is at least some risk of their clients getting into cash flow problems because of disconnected bank feeds, with at least double the number of firms at very high risk in comparison to those in the low-to-no risk range.
In that context, a vast majority of SMEs rely on these automated, bank-feed connected services, and expect that those connections remain intact, despite the rule to reauthenticate every 90 or 180 days. They are using a non-technical workaround to accomplish this. Accountants are reporting back to these providers that their clients suggest that the accountants be set up as users on the clients’ bank accounts so that they can do the reauthentication on behalf of the SMEs.
This poses material security issues for both the small business and the accountants. But SMEs are seemingly more willing to go this route than to log in every 90 days themselves. If SMEs aren’t able to reconnect/reauthenticate, or they forget to do it, it leaves the accountants in a position of working with and advising on out-of-date data, or large data gaps. Sharing passwords and login credentials with accountants poses increased security problems and risk; inaccurate data poses a different set of increased risk.
SCA also happens to introduce an unnecessary technical security risk, one that has nothing to do with sharing security credentials, but one that does exist because of how often security credentials are exposed.
Every additional exposure of a customer’s security information required to login or validate themselves, increases the risk of exploitation by hackers. Attack sophistication continues to improve, and each time a customer is asked to authenticate at the bank, the risk of customer exploitation materially increases. Given this exposure, if the customer is required to reauthenticate every 90 or 180 days with each of their banks directly, the customer is subject to increased risk. Frequency is directly related to risk (and compounded by the number of accounts and services that are connected. With account aggregation services, this risk increases linearly in line with the number of banks with whom the customer is required to authenticate. For example, a customer who has accounts with four different banks presents an opportunity to be exploited by attackers at least 4 times every 90/180 days for each TPP service connected to each of those accounts.
Despite improvements in the authentication process over the years, the weakest link has always been the initiation and input of authentication data. Between 2018-2029, mobile-based malware detections increased by 72%. This is of primary concern because most fintech apps are mobile based, yet the mobile is the most common attack vector today. And 2020 marked the year where everything went online, and mobile-first really came out first in preferred channels.
Take, for example, the ExoBot (or Marcher) trojan. ExoBot is an Android based malware that focuses predominantly on financial organisations in relation to the multi-factor authentication process, where it acts as a ‘man-in-the-middle’ to steal that multi-factor authentication information to gain access to the customer’s bank services. An estimated 7% of EU Android devices are infected with this trojan. [ https://www.threatfabric.com/blogs/exobot_android_malware_spreading_via_google_play_store.html]
Authentication data is the most sensitive data a customer holds; requiring a customer to offer up that sensitive data on a frequent and unnecessary basis violates the principles of sound and secure data/platform management. It does not adhere to the National Cyber Security Centre (NCSC) and National Institution of Standards and Technology guidelines. In fact, multiple authorities best practice recommendations are that where possible, authentication processes on trusted devices (i.e., mobile phones) be minimised. Instead, these agencies suggest opting for session-based authentication, thereby reducing the need for the customer input in order to validate the authenticity. Best practice recommends that organisations should minimise the requirements for non-user led authentication.
SCA amounts to repeated security credential exposure, resulting in increased security risk. This is exacerbated by financial institutions who offer a modified customer interface rather (MCI) than an API, because that MCI means a customer has to be present to go through SCA in order for the TPP to be able to access the data in order to perform the contracted service. MCIs mean even more numerous security exposures. Allowing for an MCI exemption nullifies the intended purpose of weaving increased security measures into PSD2; it completely fails the consumer from a risk and access to competitive services perspective. SCA was originally intended to be a security tool, however it has turned into a brute tool to manage consent, resulting in harm to the very competitive firms PSD2 and Open Banking are meant to foster.
TPP data on customer attrition rates typically ranges from 20-40% at the 90-day mark; this means a significant number of customers are cut off from these services at day 90, a similar case would happen at day 180.
This is not due to a lack of perceived value on the customer’s part. It’s because of technical and behavioural issues. A more nuanced and contextual examination provides insight. For example, one AISP reported a 32.7% drop off of users who do not reauthenticate after day 90, ceasing to use the service at that time. In that group of 32.7%, however, more than 50% of those users log in after Day 90, indicating that they still want the service but that the hassle of reauthentication, or indeed bank API failures during the reauthorization process, means that the service is interrupted and no longer available to them.
Furthermore, for the remaining 67% of customers, only 40% of those users reauthenticate at day 90 – the remaining percentage reconnect to the TPP after the 90-day mark. This results in a large percentage of users who want the service but experience an interruption to that service. In those remaining cases, this requires the user to set up the service from scratch, including all of the categorisation work history they had previously completed. There is also a significant spike in customer attrition at 180 days, when customers are required to reauthenticate for a second time. This strict requirement to reauthenticate at the bank side to confirm TPP consent to access date results in consumers abandoning services which they are happy with, and which continue to provide value; it’s the obstacle to the service, not the value of the service, that means TPPs lose customers because of the conflicts in PSD2 and the SCA-RTS.
This is compounded for customers whose banks provide a Modified Customer Interface (MCI) rather than an API under protection of the SCA-RTS Article 31 exemption. Due to the nature of MCIs, which require a customer be present for every data transfer from the bank to a TPP, SCA and reauthentication rules are a complete road blocker to a number of use cases. This ‘customer must be present’ requirement means that all forms of passive use cases (personal finance management where the service happens in the background before accessing budget and financial dashboards, or cloud accounting services that keep real-time records of business banking transactions) result in a near 100% attrition rate for the fintech.
100% customer attrition. In no way is that sustainable for TPPS, their customers, nor the market as a whole.
There are other value propositions that are being withheld from the market because fintechs know that they would have a 100% attrition rate (even with an API connection) at either the 90-day or 180-day mark. Here, the opportunity cost alone is steep: the cost to competition, to innovation, and to the customer’s benefit. And all because the legal text has a few conflicting clauses.
Customer churn is a natural part of business, however the SCA and 90-day rules amplify churn rates.
Churn is a reality for all digital solution providers: every app provider across every industry experiences churn. Even during the pandemic Netflix experienced customer churn – in its early days it saw 10% monthly churn, but for the last couple of years it averages at 2% a month. [https://gibsonbiddle.medium.com/4-proxy-metrics-a82dd30ca810 - Netflix CEO Gibson Biddle’s reported estimates mid-2019] Being able to control customer churn is essential for business survival. Like any other business, fintechs accept this fact. Unlike other digital businesses outside of a highly regulated industry like financial services, however, fintechs are handicapped by an inability to control for churn related to anything but the service value. While they can battle churn based on the value of the service they deliver, their hands are tied when it comes to artificial influences on customer attrition: the requirement to reauthenticate every 90 days, or even 180 days.
One TPP submitted evidence of quarterly churn due to 90-day reauthentication. The firm has been in the market pre-PSD2 and have so far survived PSD2 being rolled out; but the post-PSD2 implementation churn rates have increased exponentially. Before Open Banking, their quarterly churn rate hovered just under 7%. Post Open Banking, their 90-day churn metrics have risen to 44%. That’s almost a 600% increase in customer churn for a service that had not changed its business model or its value proposition. In fact, customers had reported positive feedback on additional features and functionality, so the quality of the service had only increased between pre- and post-PSD2.
Another TPP provided data showing the decline of reauthentication over a 3 month/90 day period, comparing the total number of connections week over week, with week one measuring the number of customers onboarded to the service. 90 days later, there is an abrupt drop in connections. An estimated 97% of customers were not re-authenticating at the worst of the dip (at the 90-day mark). This level of attrition is not typical churn – it sits so far outside of any anticipated statistical standard deviation that its outlier status is a huge red flag.
A 3% customer retention rate at day 90 is clearly not sustainable for any business. Any delay to implementing a change to the rule will continue to produce churn rates so unsustainable that businesses are sure to exit the EU Open Banking market.
Normally customer churn is attributable to three primary things: poor product, poor customer service, and better alternative products. But in the case of the aforementioned TPP, all evidence pointed to something other than these typical churn reasons. This TPP has a high product-market fit: 96% of their users would be disappointed if they could no longer use the app. This TPP perpetually rates a 95%+ Customer Satisfaction on Zendesk score, so customer service is not a churn issue. Moreover, survey after survey for this TPP indicates that 80% of their users prefer this app over comparative bank apps providing a similar service, so this fintech isn’t facing a slew of better alternative competition. In fact, this TPP is a repeat award winner.
FDATA also encourages the EBA to consider alternative approaches to consent management, especially given the particular use case for cloud accounting service providers, for example Delegated Consent.
TPPs who provide cloud accounting services have noted that the explicit re-consent seems unnecessarily burdensome when the user has authenticated with the TPP application and continues to directly access their account transactions in the TPP application within the previous 90 days (e.g. to include them in their accounting records). Consideration also needs to be given to the impact of this provision on delegated access; in this case, an accountant using accounting software on behalf of their client.
The following use case in particular highlights just how detrimental these SCA and 90-day reauth rules can be: small business account automation leveraging both payment account and savings account data. Because savings accounts are not payment accounts, they require SCA to be performed every time that data is accessed. (in fact, common practice is to pre-load the current and savings accounts to automate the bookkeeping.) Automated accountancy is hindered, as any reconciliation between payments and savings will have to be performed manually to enable savings data to be accessed using SCA. This is a return to manual loading of savings data that renders an ‘automated’ solution null. This unintended consequence of the SCA/Reauthentication rule virtually destroys small business accounting system solutions and negatively impacts small businesses as well
In that context, a vast majority of SMEs rely on these automated, bank-feed connected services, and expect that those connections remain intact, despite the rule to reauthenticate every 90 days. Accountants have reported that their clients the accountants be set up as users on the clients’ bank accounts so that they can do the 90-day reauth on behalf of the SMEs.
This poses material security issues for both the small business and the accountants. But SMEs are seemingly more willing to go this route than to log in every 90 days themselves.Sharing passwords and login credentials with accountants poses increased security problems and risk; inaccurate data poses a different set of increased risk.
A delegated consent would improve the outcomes for small businesses significantly, and reduce the risk of those SME accounts being disconnected. It would also reduce the security risk of any workaround, and ensure that accountants are accounting rather than chasing their clients for renewed reauthentication. FDATA suggests that as part of the delegated consent journey that each time an advisor, lawyer, accountant, etc. – whomever has delegated consent – re-consents on the PSUs behalf, the PSU receives notification of re-consent as either a push notification or via email.
The necessary change on the ASPSP side to accommodate the EBA’s proposal is straightforward and do not require extensive build. ASPSPs already have the technical solution in place for account access, including access tokens. Extending the time frame from 90 days to 180 days can be managed using the same technical solution that is already in place. This time frame adjustment is a configuration change to the existing solution, not an introduction of a complex new solution. Therefore it is a reasonable request to expedite the implementation.
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?
FDATA fully agrees that a new mandatory exemption is required when a PSU accesses their account information via an AISP, pursuant to PSD2 Art. 97(4). This mandatory exemption, applied ubiquitously across all ASPSPs will promote competition, and harmonise the rules across all providers. This clarification to how the Article 10 exemption is applied is very welcomed.The proposed changes are very welcomed by our members across the EU TPP community, and we appreciate the EBA’s efforts to improve the end consumer’s ability to access their financial data. We thank the EBA for harmonising this aspect of the EU’s PSD2 implementation.
FDATA asks that the EBA clarify that SCA is required only when the PSU is present and requesting the data via an AISP. Our understanding of the RTS is that SCA should not be required when an AISP is requesting the data, under PSU consent, when the PSU is not present or online.
In the case where the AISP is accessing the account without the customer being present, SCA should not apply. As noted in RTS Article 36(5b), when the customer is not present, AISPs are limited to accessing the account data up to four times in a 24-hour period; the four instances do not include the times a PSU actively requests such information via the AISP.
SCA was intended to provide additional security, yet the EBA Consultation Paper lists multiple reasons why there is very little risk when an AISP is involved in accessing the data (paragraphs 32-35). SCA serves an essential purpose for payments, but not for account information access itself. Therefore it is reasonable and proportional to not require SCA for AISP access when the customer is not present, under the Article 10 exemption.
Of course, SCA should apply to account access under the Article 10 exemption if:
- there is a specific security concern as detailed in RTS Article 2; or
- the account is accessed for the first time, either directly or through an AISP, wherein the latter case this serves as the PSU’s consent and mandate for future access by the AISP.
Anything else would unnecessarily restrict the use of AISPs when the customer is not present.
FDATA agrees with Bird & Bird’s interpretation of the law: 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, and/or (2) AISPs have an unconditional right pursuant to the RTS to perform background refreshes irrespective of the use or non-use of an optional exemption to SCA by the ASPSP (i.e. the AISP’s right to perform a background refresh should be not made conditional on the ASPSP deciding to make use of an optional exemption). [https://www.twobirds.com/en/news/articles/2021/global/eba-consults-on-changes-to-strong-customer-authentication)]
If this is a possible interpretation of the law then it follows that any more stringent view does not meet the principle of proportionality without clear evidence of risk.
FDATA recommends not limiting the Article 10 exemption to just AISPs; it should have a broader context that includes PISPs. Doing so would secure and maintain fair competition amongst all PSPs, specifically enabling PISP services to be more competitive and allow for the development of user-friendly, accessible, and innovative means of payment. Extending the Article 10 exemption to include PISPs would meet the above objectives while not jeopardizing the safety of PSU’s funds and personal data.
Q2. Do you have any comments on the proposal to extend the timeline for the renewal of SCA to 180-days?
FDATA welcomes the EBA’s proposal to extend the timeline for SCA renewal to 180-days, and hopes this extension can be quickly implemented.However, we have concerns that the extension does not solve the root cause of the problem, and recommend that the EBA consider an alternative approach as part of the PSD2 review exercise. FDATA has spent a considerable amount of time and effort to analyse the problem, and in light of that, we recommend several possible approaches, one of which is to extend the timeline to 365 days instead of just 180 days. Below we articulate our rationale for these suggestions.
SCA and reauthentication, as it has been implemented, has produced more harm than good for end customers:
- It has nearly zero positive impact on bank security, in opposition to the objective of the rule [SCA does not make a material difference to bank security due to implementation inconsistencies];
- It poses a hassle to end customers, many of whom have used fintech services for years without the imposition of either SCA or the need to reauthenticate;
- It has proven to be a customer eduction nightmare, with no convincing argument for end-customers outside of 'it's the law';
- It creates poor customer outcomes, both by marring and creating friction in the customer journey, as well as potentially disconnecting them from critical TPP services that are meant to protect the customer's financial health.
Differing regionalised specifications across the EU to deliver SCA and the RTS are a function of differing levels of technological maturity and readiness to implement the open banking model. The significant divergence here means TPPs have to implement several different specifications (sometimes on a country-by-country basis), which adds unnecessary friction in the ecosystem, adding cost and additional compliance burdens for banks and TPPs alike, while providing no consistent security upswing, and frustrating end customers.
PSD2's political objective was to nurture those companies, improving competition, innovation and security in the EU payments market. However, currently the way Reauthentication and SCA work defeats the political objectives of PSD2 and fails to materially improve security to protect consumers. Moreover, it is anticompetitive at its core. Only TPPs, not banks, are disconnected from the customer data if the customer fails to log in to renew/reauthenticate within the required time frame, or if the reauthentication journey fails due to unavailable/non-working bank APIs.
If the consumer is cut off, they can rely only on time bound bank supplied services, rather than their chosen and contracted fintech supplier. This asymmetric data access is anticompetitive.
No other market allows incumbent firms to control their competitors’ market access, yet this is the de facto standard under PSD2. Banks can and do control TPPs’ ability to access customer data, despite an end customer granting that permission to the TPP; it is controlled both in part by how and when SCA is applied in the customer journey, and by the cliff-edge 90-day rule imposed by the SCA-RTS. Changing the 90-day timeframe to 180-days does not fix this cliff-edge. This asymmetric control of market access is anticompetitive.
And in no other market are incumbent firms in control of their competitors’ relationship with their end customers, yet this is exactly what PSD2 enables, as it puts banks in charge of reminding TPP customers of the data access connection and service. Consent resides with the TPP/fintech, however reauthentication takes place at the bank. This creates additional friction for the customer, who, in wishing to confirm their consent to the TPP, is required to reauthenticate at the bank. This gives banks the competitive advantage of being obstructionist in the commercial relationship between the end customer and their chosen service provider (the fintech). This asymmetric interference in the customer relationship is anticompetitive.
SCA and Reauthentication is unique to payments alone; the common practice across banking is for an initial, explicit opt-in to any service, and an easy (1-click) opt-out to ensure that customers are not locked in. For example, this is the case with direct debits. Requiring AISPs to obtain a regularly recurring re-opt-in of their entire customer base is not only unique across all industries that require consent, but it is completely disproportionate to the low risk of AISP services.
Requiring not just re-consent opt-in, but applying SCA on top of that (performed via the ASPSP, an intermediary, not the AISP with whom the customer has a direct relationship) is an extreme and punitive measure for a low risk service. Direct debit is riskier than account information services, yet direct debit requires less stringent, opt-out measures.
FDATA recommends the EBA explore an alternative, best practice approach as part of the PSD2 review: an initial explicit opt-in consent given to the AISP, with a one-time SCA validation via the ASPSP. It would also best serve the market to have an easy, 1-click opt-out feature via a dashboard at the AISP. Shifting to a consent based model, rather than a reauthentication model, is a reasonable compromise that puts the customer in charge of how and with whom their data is shared, and puts the management of that relationship between the two interested parties, without the interference of an intermediary.
Should the EBA choose to maintain the current reauthentication process, FDATA recommends extending the timeline for renewal to 365 days, to allow for a longer, uninterrupted connection for end consumers.
Over the course of 2020, FDATA collected evidence of the degree to which the SCA-RTS requirement negatively impacts both TPPs and customers. The evidence, highlighted from a broad sample of mostly mature TPPs, showed that under the 90 Day Reauth requirement, customer attrition rates span between 13-65% depending on the business model. These rates are simply not economically sustainable at either end of the spectrum, with firms losing customers who fail to reauthenticate for a variety of mostly technical and behavioural reasons, not because of a low service value. Moreover, some banks have an exemption to providing an API, and instead have stood up a modified customer interface (MCI). Due to the nature of MCIs, they require a customer be present for every data transfer from the bank to a TPP. In this case, the SCA and 90 Day rules are an obstacle to a number of use cases, and results in a near 100% customer attrition rate for the TPP.
Customers also suffer from being disconnected from valuable services that allow them to better manage their money, beyond what their ASPSP can provide. Not only are those services stopped, but those who renew post day 90 (and in the proposed 180 day extension, this same circumstance applies) are forced to set up those services again from scratch, often at the cost of considerable user friction.
For end customers, this is a terrible customer journey which places obstacles in front of the customer, hindering their ability to consume TPP services. It erodes the value of the propositions, resulting in the objectives of PSD2 missing the mark entirely.
Two use cases in particular highlight just how detrimental these two rules can be. For example, small business account automation leveraging both payment account and savings account data. Because savings accounts are not payment accounts, they require SCA to be performed every time that data is accessed. (in fact, common practice is to pre-load the current and savings accounts to automate the bookkeeping.) Automated accountancy is hindered, as any reconciliation between payments and savings will have to be performed manually to enable savings data to be access using SCA. This is a return to manual loading of savings data renders an ‘automated’ solution null. This unintended consequence of the SCA/90 Day rule virtually destroys small business accounting system solutions and negatively impacts small businesses as well. The rules do double the harm.
Personal finance management (PFM) tools are also crippled by these rules. For consumers relying on budgeting apps, the need for SCA to access bank held savings, investment, and credit data means that automation, especially reminders and push notifications meant to keep customers aware of their finances are rendered moot. Customers have to perform SCA every time they check the PFM tool. And due to a dearth of available financial advice, any technology proxies for that advice cannot step in because data is restricted from flowing to the application that helps customers. This unintended consequence of the RTS leaves PFM tools hindered and customers worse off.
The accounting use case also showcases the extent to which users will go to circumvent the hassle of SCA reauthentication: SMEs who do not directly manage their accounting, but are clients of accounting firms who do leverage Open Banking to do bookkeeping on their behalf.
A 2020 survey of nearly 500 licensed bookkeepers and accountants by a cloud accounting firm, 100% of whose clients connect their accounts via Open Banking, showcased just how damaging SCA reauthentication is to small businesses
Of those accounting professionals asked, 97.9% confirmed that the requirement for clients to reauthenticate their bank feeds every 90 days caused significant problems. Nearly a hundred percent of respondents (97.3%) spent time chasing their clients to reauthenticate. 83% said their clients were not even familiar with the reauthentication process. And 76.6% said that they frequently had to deal with out-of-date accounting records because required reauthentication had not happened. And 69% said that they spend at least an extra hour of additional time per client per month helping clients reconnect their bank feeds. A quarter of respondents spent more than three hours per month per client chasing reauthentication. They don’t spend this time accounting, they spend it chasing reauthentication. 77% of respondents said that there is at least some risk of their clients getting into cash flow problems because of disconnected bank feeds, with at least double the number of firms at very high risk in comparison to those in the low-to-no risk range.
In that context, a vast majority of SMEs rely on these automated, bank-feed connected services, and expect that those connections remain intact, despite the rule to reauthenticate every 90 or 180 days. They are using a non-technical workaround to accomplish this. Accountants are reporting back to these providers that their clients suggest that the accountants be set up as users on the clients’ bank accounts so that they can do the reauthentication on behalf of the SMEs.
This poses material security issues for both the small business and the accountants. But SMEs are seemingly more willing to go this route than to log in every 90 days themselves. If SMEs aren’t able to reconnect/reauthenticate, or they forget to do it, it leaves the accountants in a position of working with and advising on out-of-date data, or large data gaps. Sharing passwords and login credentials with accountants poses increased security problems and risk; inaccurate data poses a different set of increased risk.
SCA also happens to introduce an unnecessary technical security risk, one that has nothing to do with sharing security credentials, but one that does exist because of how often security credentials are exposed.
Every additional exposure of a customer’s security information required to login or validate themselves, increases the risk of exploitation by hackers. Attack sophistication continues to improve, and each time a customer is asked to authenticate at the bank, the risk of customer exploitation materially increases. Given this exposure, if the customer is required to reauthenticate every 90 or 180 days with each of their banks directly, the customer is subject to increased risk. Frequency is directly related to risk (and compounded by the number of accounts and services that are connected. With account aggregation services, this risk increases linearly in line with the number of banks with whom the customer is required to authenticate. For example, a customer who has accounts with four different banks presents an opportunity to be exploited by attackers at least 4 times every 90/180 days for each TPP service connected to each of those accounts.
Despite improvements in the authentication process over the years, the weakest link has always been the initiation and input of authentication data. Between 2018-2029, mobile-based malware detections increased by 72%. This is of primary concern because most fintech apps are mobile based, yet the mobile is the most common attack vector today. And 2020 marked the year where everything went online, and mobile-first really came out first in preferred channels.
Take, for example, the ExoBot (or Marcher) trojan. ExoBot is an Android based malware that focuses predominantly on financial organisations in relation to the multi-factor authentication process, where it acts as a ‘man-in-the-middle’ to steal that multi-factor authentication information to gain access to the customer’s bank services. An estimated 7% of EU Android devices are infected with this trojan. [ https://www.threatfabric.com/blogs/exobot_android_malware_spreading_via_google_play_store.html]
Authentication data is the most sensitive data a customer holds; requiring a customer to offer up that sensitive data on a frequent and unnecessary basis violates the principles of sound and secure data/platform management. It does not adhere to the National Cyber Security Centre (NCSC) and National Institution of Standards and Technology guidelines. In fact, multiple authorities best practice recommendations are that where possible, authentication processes on trusted devices (i.e., mobile phones) be minimised. Instead, these agencies suggest opting for session-based authentication, thereby reducing the need for the customer input in order to validate the authenticity. Best practice recommends that organisations should minimise the requirements for non-user led authentication.
SCA amounts to repeated security credential exposure, resulting in increased security risk. This is exacerbated by financial institutions who offer a modified customer interface rather (MCI) than an API, because that MCI means a customer has to be present to go through SCA in order for the TPP to be able to access the data in order to perform the contracted service. MCIs mean even more numerous security exposures. Allowing for an MCI exemption nullifies the intended purpose of weaving increased security measures into PSD2; it completely fails the consumer from a risk and access to competitive services perspective. SCA was originally intended to be a security tool, however it has turned into a brute tool to manage consent, resulting in harm to the very competitive firms PSD2 and Open Banking are meant to foster.
TPP data on customer attrition rates typically ranges from 20-40% at the 90-day mark; this means a significant number of customers are cut off from these services at day 90, a similar case would happen at day 180.
This is not due to a lack of perceived value on the customer’s part. It’s because of technical and behavioural issues. A more nuanced and contextual examination provides insight. For example, one AISP reported a 32.7% drop off of users who do not reauthenticate after day 90, ceasing to use the service at that time. In that group of 32.7%, however, more than 50% of those users log in after Day 90, indicating that they still want the service but that the hassle of reauthentication, or indeed bank API failures during the reauthorization process, means that the service is interrupted and no longer available to them.
Furthermore, for the remaining 67% of customers, only 40% of those users reauthenticate at day 90 – the remaining percentage reconnect to the TPP after the 90-day mark. This results in a large percentage of users who want the service but experience an interruption to that service. In those remaining cases, this requires the user to set up the service from scratch, including all of the categorisation work history they had previously completed. There is also a significant spike in customer attrition at 180 days, when customers are required to reauthenticate for a second time. This strict requirement to reauthenticate at the bank side to confirm TPP consent to access date results in consumers abandoning services which they are happy with, and which continue to provide value; it’s the obstacle to the service, not the value of the service, that means TPPs lose customers because of the conflicts in PSD2 and the SCA-RTS.
This is compounded for customers whose banks provide a Modified Customer Interface (MCI) rather than an API under protection of the SCA-RTS Article 31 exemption. Due to the nature of MCIs, which require a customer be present for every data transfer from the bank to a TPP, SCA and reauthentication rules are a complete road blocker to a number of use cases. This ‘customer must be present’ requirement means that all forms of passive use cases (personal finance management where the service happens in the background before accessing budget and financial dashboards, or cloud accounting services that keep real-time records of business banking transactions) result in a near 100% attrition rate for the fintech.
100% customer attrition. In no way is that sustainable for TPPS, their customers, nor the market as a whole.
There are other value propositions that are being withheld from the market because fintechs know that they would have a 100% attrition rate (even with an API connection) at either the 90-day or 180-day mark. Here, the opportunity cost alone is steep: the cost to competition, to innovation, and to the customer’s benefit. And all because the legal text has a few conflicting clauses.
Customer churn is a natural part of business, however the SCA and 90-day rules amplify churn rates.
Churn is a reality for all digital solution providers: every app provider across every industry experiences churn. Even during the pandemic Netflix experienced customer churn – in its early days it saw 10% monthly churn, but for the last couple of years it averages at 2% a month. [https://gibsonbiddle.medium.com/4-proxy-metrics-a82dd30ca810 - Netflix CEO Gibson Biddle’s reported estimates mid-2019] Being able to control customer churn is essential for business survival. Like any other business, fintechs accept this fact. Unlike other digital businesses outside of a highly regulated industry like financial services, however, fintechs are handicapped by an inability to control for churn related to anything but the service value. While they can battle churn based on the value of the service they deliver, their hands are tied when it comes to artificial influences on customer attrition: the requirement to reauthenticate every 90 days, or even 180 days.
One TPP submitted evidence of quarterly churn due to 90-day reauthentication. The firm has been in the market pre-PSD2 and have so far survived PSD2 being rolled out; but the post-PSD2 implementation churn rates have increased exponentially. Before Open Banking, their quarterly churn rate hovered just under 7%. Post Open Banking, their 90-day churn metrics have risen to 44%. That’s almost a 600% increase in customer churn for a service that had not changed its business model or its value proposition. In fact, customers had reported positive feedback on additional features and functionality, so the quality of the service had only increased between pre- and post-PSD2.
Another TPP provided data showing the decline of reauthentication over a 3 month/90 day period, comparing the total number of connections week over week, with week one measuring the number of customers onboarded to the service. 90 days later, there is an abrupt drop in connections. An estimated 97% of customers were not re-authenticating at the worst of the dip (at the 90-day mark). This level of attrition is not typical churn – it sits so far outside of any anticipated statistical standard deviation that its outlier status is a huge red flag.
A 3% customer retention rate at day 90 is clearly not sustainable for any business. Any delay to implementing a change to the rule will continue to produce churn rates so unsustainable that businesses are sure to exit the EU Open Banking market.
Normally customer churn is attributable to three primary things: poor product, poor customer service, and better alternative products. But in the case of the aforementioned TPP, all evidence pointed to something other than these typical churn reasons. This TPP has a high product-market fit: 96% of their users would be disappointed if they could no longer use the app. This TPP perpetually rates a 95%+ Customer Satisfaction on Zendesk score, so customer service is not a churn issue. Moreover, survey after survey for this TPP indicates that 80% of their users prefer this app over comparative bank apps providing a similar service, so this fintech isn’t facing a slew of better alternative competition. In fact, this TPP is a repeat award winner.
FDATA also encourages the EBA to consider alternative approaches to consent management, especially given the particular use case for cloud accounting service providers, for example Delegated Consent.
TPPs who provide cloud accounting services have noted that the explicit re-consent seems unnecessarily burdensome when the user has authenticated with the TPP application and continues to directly access their account transactions in the TPP application within the previous 90 days (e.g. to include them in their accounting records). Consideration also needs to be given to the impact of this provision on delegated access; in this case, an accountant using accounting software on behalf of their client.
The following use case in particular highlights just how detrimental these SCA and 90-day reauth rules can be: small business account automation leveraging both payment account and savings account data. Because savings accounts are not payment accounts, they require SCA to be performed every time that data is accessed. (in fact, common practice is to pre-load the current and savings accounts to automate the bookkeeping.) Automated accountancy is hindered, as any reconciliation between payments and savings will have to be performed manually to enable savings data to be accessed using SCA. This is a return to manual loading of savings data that renders an ‘automated’ solution null. This unintended consequence of the SCA/Reauthentication rule virtually destroys small business accounting system solutions and negatively impacts small businesses as well
In that context, a vast majority of SMEs rely on these automated, bank-feed connected services, and expect that those connections remain intact, despite the rule to reauthenticate every 90 days. Accountants have reported that their clients the accountants be set up as users on the clients’ bank accounts so that they can do the 90-day reauth on behalf of the SMEs.
This poses material security issues for both the small business and the accountants. But SMEs are seemingly more willing to go this route than to log in every 90 days themselves.Sharing passwords and login credentials with accountants poses increased security problems and risk; inaccurate data poses a different set of increased risk.
A delegated consent would improve the outcomes for small businesses significantly, and reduce the risk of those SME accounts being disconnected. It would also reduce the security risk of any workaround, and ensure that accountants are accounting rather than chasing their clients for renewed reauthentication. FDATA suggests that as part of the delegated consent journey that each time an advisor, lawyer, accountant, etc. – whomever has delegated consent – re-consents on the PSUs behalf, the PSU receives notification of re-consent as either a push notification or via email.
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?
This proposed amendment is urgently needed, and given this urgency, FDATA has no objection to reducing the standard 3-month notice on interface changes to one month, or even less; we also encourage the EBA to consider reducing the implementation timeline to 3 months.The necessary change on the ASPSP side to accommodate the EBA’s proposal is straightforward and do not require extensive build. ASPSPs already have the technical solution in place for account access, including access tokens. Extending the time frame from 90 days to 180 days can be managed using the same technical solution that is already in place. This time frame adjustment is a configuration change to the existing solution, not an introduction of a complex new solution. Therefore it is a reasonable request to expedite the implementation.