Strong Customer Authentication (SCA): EBA Opinion allows for more time, and provides more clarity on the various SCA elements

In its Opinion, the EBA:

• for Payment Service Providers (PSPs) to be granted more time by their national Competent Authority (CA) to comply with the SCA requirements, i.e. a de facto postponement of the 14 September 2019 deadline;
• Provides helpful clarifications on the various elements of SCA (something you are / something you have / something you know).

We address both items in terms below.       

1. Delaying the 14 September 2019 deadline

1.1. Comments on timing

Although the EBA reiterates in its Opinion that all PSPs should comply with the PSD2 SCA mandate by 14 September 2019, the EBA acknowledges how complex the required changes are in order to comply with the SCA requirements and accepts that, "on an exceptional basis and in order to avoid negative unintended consequences for some payment service users after 14 September 2019"[1], CAs may provide "limited additional time"[2] to PSPs in order to migrate to authentication approaches that are compliant with the SCA requirements.

The Opinion specifies that CAs should only grant additional time to PSPs if three conditions are met:

1. "PSPs have set up a migration plan"[3];
2. "PSPs … have agreed the plan with their CA"[4];
3. "PSPs … execute the plan in an expedited manner"[5].

The EBA adds that "CAs should monitor closely the execution of these plans to ensure swift compliance with the PSD2 and the EBA's technical standards and to achieve consistency of authentication approaches across the EU"[6].

The EBA also indicates in its Opinion that "Where the EBA identifies inconsistencies, despite the guidance contained in this opinion and the previous clarifications provided in the Opinion on the implementation of the RTS and Q&As, it will take the actions needed to remedy those inconsistencies in line with the powers conferred on the EBA in its founding regulation"[7].

In its Opinion, the EBA does not set a hard deadline for this migration plan to be completed. This creates a risk that different CAs will grant more or less time to PSPs to get into compliance, which in turn creates a risk of unintended negative impact on transactions – in particular on card transactions where two different PSPs are typically involved (i.e. the card issuer and the merchant acquirer). Indeed, if an acquirer in country A is given an extra 18 months to comply with SCA, whereas the card issuer in country B is not given any extra time, the acquirer will send transactions to the issuer without a technical request for the issuer to perform SCA (typically referred to as a "3D Secure flow" or "3DS flow").However, the issuer will have to decline those transactions, except those transactions in relation to which the issuer has identified an exemption allowing it to let the transactions proceed without SCA. This may result in a great number of transactions being declined, with a negative impact on all stakeholders in the value chain: the merchant will lose a sale/transaction, the acquirer will lose out on its margin on the transactions, the card schemes will lose scheme fee revenues, processors will lose processing fees, the issuer will not collect an interchange fee, the cardholder will not purchase the goods or services that it wanted to purchase, etc. This would also be harmful to the EU internal market, which is one of the objectives of the PSD2 SCA provisions…

One can only hope that the CAs in the various EU Member States will coordinate the extensions that they will grant to PSPs (in particular in relation to card transactions) in order to avoid such negative impact on all stakeholders in the payments value chain. However, given the great number of PSPs in the EU with different levels of SCA readiness, as well as the fact that the EU has 28 different CAs, one can (unfortunately) only be sceptical as to the capability of all those national CAs to agree on one common deadline, and perhaps a common set of milestones along the way... For example, the UK CA is already discussing with UK PSPs the possibility of a "managed rollout" of SCA in the UK until 14 March 2021 (i.e. an 18-month extension) – whereas other national regulators have either not yet communicated on this topic, or are potentially suggesting even longer deadlines for compliance. For example, it is rumoured that, in France, card transactions with only one strong factor (in the form of a One Time Password (OTP) sent by SMS, combined with card credentials which are not considered by the EBA as being a strong factor) could be tolerated until September 2022 (i.e. a 3-year extension)?

In its press release accompanying the Opinion, the EBA indicated that it will communicate on deadlines later this year (see here). However, by the time the EBA communicates, CAs and PSPs may already have agreed on an extension. What will happen if the deadline put forward by the EBA does not match the prior plan agreed between the CA and the PSP? Surely legal certainty and legitimate expectations would command that the deadline not be changed in light of what the EBA publish?

1.2. Comments on the scope of the extension

Note that the scope of the actions that could potentially benefit from the extension is not entirely clear. Does the possible extension only apply to the SCA that would otherwise be required when the payer is initiating an electronic payment, or does it also apply to SCA that would otherwise be required when the user accesses it payments account online? Arguably the possible extension applies to all scenarios when a SCA is required pursuant to Article 97(1) PSD2 and the RTS[8]? If this is correct, an Account Servicing Payment Service Provider (ASPSP) that would be granted more time in order to comply with SCA will be mindful to apply SCA in the same way whether the user is accessing the payment account directly with the ASPSP, or via an Account Information Service Provider (AISP), as otherwise the ASPSP could be accused of creating an "obstacle" in violation of the RTS[9].

As regards to payments (rather than accessing payment accounts), we presume that the possible de facto extension of the deadline would apply not only to the scenarios where the user initiates an electronic payment directly with its PSP (e.g. with its bank in relation to initiating to a credit transfer, or with its card issuer in relation to a card transaction), but also when the user is initiating a payment (in practice a credit transfer) via a Payment Initiation Service Provider (PISP)? If that is correct, as already indicated in relation to AISPs above, ASPSPs will need to be mindful not to apply a different SCA regime between payments initiated by the user directly with the ASPSP versus payments initiated through a PISP, as otherwise the ASPSP could be argued to be creating an "obstacle" for the PISP, in violation of the RTS[10].

2. On the three categories of SCA elements 

In addition to the clarifications already provided in its June 2018 Opinion (see here, and our client alert here), and in the various answers published on the EBA's online portal (see here), the EBA Opinion contains additional clarifications on which factors can be considered as strong factors, and in which category they fall (something only I am, something only I have, or something only I know).

2.1. Something only I am (inherence)

The EBA Opinion contains a helpful table of the elements that (do not) constitute strong inherence elements – see below.

The table does not come as a surprise as regards biological (or static) biometric elements, e.g. fingerprint, face, pulse, voice, etc.

The views expressed on behavioural biometric (e.g. keystroke, angle at which the device is held) are similarly predictable since the EBA had already provided helpful comments in that respect in responses published on its online portal (see Qu 2018_4238 and Qu 2018_4049).

An argument had been raised that, given the nature and magnitude of the data points contained in a 3DS 2.0 flow, it should be treated as a strong (inherence) factor. For the moment, the EBA rejects that argument considering that "none of the data points, or their combination … appears to include information that relates to biological and behavioural biometrics …"[11]. However, this is a position that may change in the future if and when more (inherence) data points get inserted in the future iterations of a 3DS flow (e.g. 3DS 2.2, 3DS 2.3).

A memorised swiping path is logically not accepted as being something inherent to you (unlike, for example, a signature on a tablet when paying at a merchant POS which arguably qualifies as a strong factor[12]), but would instead qualify as a something only I know (knowledge) element.

2.2. Something only I have (possession)

Unsurprisingly, the EBA confirms that card details do not qualify as a possession element (nor a knowledge element – see below). However, this position is contrary to the position of the UK CA which considers that cards credentials do constitute a possession factor[13] - although, based on recent information, the UK CA would possibly be about to change its position on this issue and therefore align with the EBA's opinion.

2.3. Something only I know (knowledge)

As mentioned above, the EBA is of the view that card details do not constitute a strong knowledge factor (nor possession factor), which is something that the EBA had already indicated in the June 2018 Opinion[14].

An OTP sent to a mobile number does not constitute a knowledge factor, but does constitute a possession factor – i.e. possession of the SIM card stored in the user's mobile phone, which is something that the EBA had already clarified in a response posted on its web portal[15].

2.4. Other comments

We provide a few additional comments on the EBA Opinion, about items that are addressed, or on the contrary not addressed, in the EBA Opinion:

• On several occasions, the EBA states in its Opinion that the two elements should belong to different categories – which is a view that the EBA had already expressed in its June 2018 Opinion[16] (and which is shared amongst others by the UK CA[17]). We remain of the view that the definition of SCA contained in PSD2 allows for the possibility to have the two elements in the same category (e.g. two something I know, such as a password and a PIN). Indeed PSD2 defines SCA as "an authentication based on the use of two or more elements categorised as knowledge … possession … and inherence … that are independent, in that the breach of one does not compromise the reliability of the others, and is designed in such a way as to protect the confidentiality of the authentication data"[18]. In our view, as long as the two factors comply with the independence requirement, they could fall within the same category while being compliant with the SCA requirement (although, clearly, the EBA and UK CA take a different view).
  
  
• In its Opinion, the EBA confirms that "… an element used for the purpose of SCA may be reused within the same session for the purpose of applying SCA at the time that a payment is initiated, provided that the other element required for SCA is carried out at the time of the payment initiation and that the dynamic linking element is present and linked to that latter element"[19]; a view that the EBA had already recently expressed in a response published on its web portal[20]. In our view, this EBA's statement remains unclear. It relates to a scenario where a user would access its payment account online and would be authenticated via a static password (something he knows) and an OTP sent by SMS (something he has, i.e. the SIM card), but a few seconds/minutes later the user would decide to initiate a payment. The PSP asked the EBA whether it would be SCA compliant, as regards the authentication of the payment transaction, if it only sent a new OTP by SMS to user with the dynamic linking (i.e. name of payee and amount of transaction), but did not request the user to type-in again his password. The above answer from the EBA can either be interpreted as saying that (1) it is acceptable to use the password as one of the factors to authenticate the payment without a need to type-in again the password, or (2) it is acceptable to use the password as one of the factors to authenticate the payment but the password would need to be typed-in again. We believe that the most logical interpretation of the EBA's response is option (2) above (i.e. no need for the user to type-in the password again); however this would raise two potential issues:
  
  
  • The EBA would seem to, perhaps, be contradicting the position it previously expressed in its June 2018 Opinion: "… SCA has to be applied to access to payment account information and to every payment initiation, including within a session in which SCA was performed to access the account data, unless an exemption under the RTS applies"[21]?
    
    
  • More importantly, the EBA's statement would seem to contradict the requirement contained in the RTS that "… it shall not be possible to identify which of the elements … was incorrect"[22]. If the password does not need to be typed-in again by the user in order to authenticate the payment, but the SCA (and therefore the payment transaction) fails, it will be possible to identity that it is the OTP that was incorrect, as opposed to the password since the password was not typed-in again…

Questions are being raised within the industry as to whether a PSP relying on handset manufacturers (e.g. Apple, Samsung) or an operating system (OS - e.g. Google Android) running on a mobile phone, should be considered as outsourcing its SCA compliance to the handset manufacturer or OS provider, and therefore would need to comply with the relevant outsourcing requirements, and in particular the EBA guidelines on outsourcing that will become effective on 30 September 2019 (see our previous alert on those EBA guidelines here). We believe that there are good arguments to support the view that such a "delegation" of SCA by a PSP to a third party does not constitute an outsourcing. However, a confirmation by the EBA or national CAs would be welcomed.