EBA consults on changes to strong customer authentication (SCA) as applied to PSD2 account information services (AIS)

We summarise below what the situation is today under the RTS, the changes that the UK FCA proposed earlier this year on the same topic, and the solution that is now being proposed by the EBA.

The situation today

Today, under PSD2, an ASPSP needs to perform an SCA every time the PSU accesses its payment account online, whether directly (e.g. via the mobile banking app provided by his account servicing payment service provider (ASPSP)) or through an AISP.

However the RTS provide for an optional exemption (Art. 10 RTS) that allows the ASPSP to only perform an SCA of the customer every 90 days if certain conditions are met, in particular if only limited payment account information is being accessed by the PSU – directly or indirectly through the customer’s AISP (an ASPSP needs to apply this exemption in a non-discriminatory way, e.g. it cannot be used only when the customer accesses its payment account directly with the ASPSP but not when the customer accesses its accounts though an AISP).

In its June 2020 Opinion on obstacles under Article 32(3) of the RTS (available here), the EBA indicated that “In order to minimise friction in the customer journey, to mitigate the impact that a authentication with the ASPSP more frequently than 90 days may have on AISPs’ services and to avoid potential obstacles, the EBA advises NCAs to encourage all their ASPSPs to make use of the Article 10 exemption, by supporting ongoing 90-day access by AISPs without SCA” (paragraph 31). However a number of ASPSPs still do not make use of the 90-day exemption but instead require SCA on every access (or at least do not make full use of the 90-day exemption by not requesting SCA on every account access but at least requesting an SCA more frequently than merely every 90 days).

AISPs have been arguing for a quite some time that this optional exemption is having a negative impact on the customer experience and therefore on their business, in particular when ASPSPs don’t make use of the optional exemption at all, which requires the customer to perform as SCA every time it wants to access its payment account through the AISP.

In addition, the RTS allow an AISP to access the customer’s payment accounts without the customer having actively requested the information (e.g. when the customer is asleep) with a limit of maximum four times in a 24-hour period (we call this a background refresh) (Article 36(5)(b)). However SCA is potentially problematic in relation to the exercise of that right by AISPs:

• If the ASPSP makes use of the 90-day exemption, this background refresh can happen since no SCA of the customer by the ASPSP is required.

But if the ASPSP doesn’t make use of the 90-day SCA, it has never been clarified by the EBA, at least to our knowledge, whether the AISP could still perform that background refresh without the need for the ASPSP to perform an SCA of the customer (assuming that this would be possible technically), or whether the ASPSP would need to perform an SCA of the customer and therefore the AISP would, for practical purposes, lose its right to perform a background refresh (in particular, neither the EBA opinions on SCA nor the three EBA Q&As dealing with the issue of background refresh here, here and here contain any clarification from the EBA). 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 not be made conditional on the ASPSP deciding to make use of an optional exemption). But on the other hand, one could also take the view that every time an AISP accesses a payment account, whether following an active request by the customer or not, it is always the customer accessing its payment account, albeit indirectly through its AISP, and therefore SCA of the customer by the ASPSP is in principle required in relation to a background refresh – meaning that the AISP’s right to perform background refreshes is indeed conditional on the ASPSP making use of the optional exemption.

UK consultation

Earlier this year, the UK FCA consulted on some proposed changes to its Approach document in relation to SCA (see our alert here). Specifically in relation to the issue of SCA in AIS flow, the UK FCA proposed that:

• SCA of the customer by the ASPSP would only be required when the customer first decides to connect their account to an AISP (but will no longer be required on every access, or even every 90 days if the ASPSP makes use of the exemption – the 90-day exemption would only remain for direct access by the PSU to its payment accounts, e.g. via the mobile banking app provided by the ASPSP to the customer).
• If the AISP makes use of the right to perform background refreshes, the AISP will need to reconfirm the customer’s explicit consent every 90 days. If a customer fails to re-confirm their consent, the AISP would be required to disconnect access and stop collecting data from the customer’s payment accounts.

The FCA has not yet formally adopted this proposed change to its Approach document.

The proposed EBA solution

The EBA is consulting on a different solution than the one put forward by the UK FCA.

In relation to SCA in an AIS flow, the EBA is proposing a new exemption, that would be mandatory for the ASPSP to use, under which the ASPSP would only need to perform an SCA of the customer (1) upon the first access by the customer to the limited payment account data through a particular AISP and (2) every 180 days. However the ASPSP would be allowed to perform more frequent SCAs of the PSU when it has “objectively justified and duly evidenced reasons relating to unauthorised or fraudulent access to the payment account. In such case, the [ASPSP] shall document and duly justify to its competent national authority, upon request, the reasons for applying [SCA].” (proposed new Article 10a in the RTS).

In relation to the PSU accessing its payment account directly (e.g. via the mobile banking app made available by his ASPSP), that exemption would remain optional for the ASPSP to use or not. The only change that is proposed by the EBA is to extend the 90-day period to 180 days. This change is being proposed in Article 10 RTS.

The RTS being a document adopted by the European Commission (EC) (not the EBA), the changes proposed by the EBA would need to be formally approved by the EC. The EBA estimates that the proposed changes could become applicable in Q4 2022.

Under the RTS (Article 30(4)), ASPSPs are in principle required to make any change to the technical specification of their open banking interface (whether dedicated interface or modified customer interface) available to TPPs not less than 3 months before the change is implemented. However and as an exception, the EBA is proposing that this period would be reduced to only one month in relation to the above proposed change to the RTS.

Our comments

The EBA’s proposed approach will require SCA more often than under the regime proposed by the FCA in UK (see above), but it seems to us that it would nonetheless remedy some of the issues that we summarised above under the current regime. Indeed, by making the SCA exemption mandatory in an AIS flow, the EBA would:

• Remedy the issue of SCA being too intrusive/frequent, in particular when ASPSP don’t make use of the (today) optional exemption;
• Remedy the legal uncertainty on whether SCA of the PSU by the ASPSP is required when the AISP performs a background refresh. Indeed, with a mandatory 180-day SCA exemption imposed on the ASPSP, the background refreshes by the AISP in principle take place without the ASPSP being allowed to perform an SCA of the customer (except in case of “objectively justified and duly evidenced reasons relating to unauthorised or fraudulent access to the payment account”) (by the way, it appears from the EBA’s recent answer to issue XXXVIII raised by participants of the EBA Working Group on APIs under PSD2 available here, as well as from in the EBA’s consultation (paragraph 23) that the EBA is of the view that an SCA of the customer by the ASPSP is required when an AISP performs a background refresh, meaning that the AISP’s right to perform background refreshes is conditional on the ASPSP making using of the 90-day exemption).

While this would be progress from the point of view of AISPs, there is still a concern expressed by AISPs that would remain unaddressed: the fact that ASPSPs will still need to perform SCA every 180 days, which means that when AISP aggregates several payment accounts of the same customer with different ASPSPs, the customer will still need to perform SCA at various moments that will not necessarily overlap. This is an issue that will no longer exist in relation to UK ASPSPs under the solutions as proposed by the FCA.

Should you have any questions about the above, please do not hesitate to contact one of the members of the Bird & Bird global Payments team.

If you would like to receive our regular Payments alerts in your inbox, click here.

If you would like to read Bird & Bird's previous alerts, please check out our Payments InFocus webpage here.