In Part 1/3 of our short series of articles about the “Strong Customer Authentication under PSD2 in the View of EBA – A Summary of the Status Quo” (“Part 1/3”) we provided an overview of the definition of strong customer authentication (“SCA”) and in which cases it has to be applied under PSD2. We pointed out that the broad scope of application for SCA under PSD2 may present a considerable challenge to many stakeholders in the market. As mentioned in Part 1, the EBA has been tasked – inter alia – with drafting the particular requirements of SCA as well as certain exemptions from this broad obligation to apply SCA in so called Regulatory Technical Standards (“RTS”), which may help to mitigate the most pressing challenges. Part 2/3 of our short series of articles on Strong Customer Authentication under PSD2 will focus on the EBA’s approach to develop the RTS and how the market reacted to that approach.
Table of Contents
1. Discussion Paper
In its Discussion Paper (“DP”), the EBA introduced a general approach and first thoughts on SCA and the exemptions to be drafted. With publishing the DP the EBA invited all stakeholders in the market to provide feedback on its approach to draft the RTS by 8 February 2016. The EBA received 118 (!) responses to the Discussion Paper, among which 82 gave permission for the EBA to publish them on the EBA website. This represents the second highest number of responses ever received, the EBA said, thus underlining the importance of this topic for the market. The DP and the stakeholders’ responses are both available here.
2. What Did the EBA Say on SCA in the DP?
In its DP, the EBA mainly discussed three issues: (i) the definition of SCA, (ii) its understanding of the cases in which SCA has to be applied, and (iii) the exemptions from the obligation to implement SCA.
2.1 Definition of SCA
In Part 2/3 we learned that SCA is an authentication that is based on the use of two or more elements categorized as
- knowledge (something only the user knows),
- possession (something only the user possesses), and
- inherence (something the user is),
that ensures the elements are independent from one another, 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.
2.2 When to Apply SCA
We have further seen that a payment services provider (“PSP”) shall apply SCA where the payer:
- accesses its payment account online;
- initiates an electronic payment transaction;
- carries out any action through a remote channel which may imply a risk of payment fraud or other abuses.
2.3 EBA identified several complicated issues regarding the implementation of SCA
Before that background, the EBA has identified several questions related to the implementation of the above, in particular on the scope of the payment instruments to which SCA should apply as well as how it should be applied by PSPs for a card transaction or the provision of payment initiation services (“PIS”). The EBA stated that it has identified certain issues with the PSD 2 definition of SCA, which it intends to address in its draft RTS:
- The requirement for independent authentication elements may be problematic, if the (mobile) device via which the payment service user accesses his account at the same time contains his credentials (e.g. hardware or software layer) or is used to receive the credential (e.g. via SMS);
- The EBA has identified a potential complication with the requirement of dynamically linking the transaction to a specific amount and specific payee in case of electronic remote payment transactions. The EBA points out that this may be difficult to implement in some scenarios, either due to the characteristics of the channel itself (e.g. authentication via voice over IP) or due to the transaction amount being unknown (e.g. recurring direct debits). However, the EBA considers it possible to address this issue in the course of the exemptions to be drafted (cf. below).
2.4 Exemptions from the obligation to implement SCA
As regards to the exemptions from the obligation to implement SCA, the EBA first emphasized that the exemptions will have to be based on the criteria in Art. 98 (3) PSD 2. These criteria are (i) the level of risk involved in the service provided, (ii) the amount and/or recurrence of the transaction and (iii) the payment channel for the transaction.
Based on these criteria the EBA stated that it intends to clarify that exemptions could apply in the following cases:
- low value payments (if risk for cumulative transactions are monitored).
- outgoing payments to trusted beneficiaries included in previously established white lists by a Payment Service User.
- transfers between two accounts of the same Payment Service User held at the same PSP.
- low-risk transactions based on a transaction risk analysis (taking into account detailed criteria to be defined in the RTS).
- purely consultative services, with no display of sensitive payment data, taking into account data privacy laws.
With regard to lit. d), the EBA further suggested providing clarification in the RTS as to which kind of capabilities and minimum set of information is necessary for a transaction risk analysis to reliably evaluate the risk of a transaction. EBA suggested that
“Such capability could, for example, be required to be based on comprehensive real-time risk analysis taking into account (a) an adequate transaction history of that customer to evaluate the latter’s typical spending and behaviour patterns, (b) information about the customer device used (e.g. IP address, model, operating system, language preferences) and where applicable (c) a detailed risk profile of the payee (e.g. types of service provided, transaction history) and the payees device (where applicable).“
Based on these explanations the EBA asked the stakeholders certain questions regarding, in particular, the proposed exemptions (cf. p. 15 and 16 of the DP). In a nutshell these questions basically requested responses from the stakeholders on whether they consider the EBA clarifications useful and if they consider any further exemptions necessary.
3. What Did the Stakeholders Respond?
The stakeholders’ responses included a wide range of different opinions and suggestions. While, overall, most of the stakeholders considered the clarifications proposed by EBA to be generally useful, certain issues were addressed in many of the responses and came up so repeatedly that we would consider them to be of major importance for the market.
The following major issues have been raised by the stakeholders:
3.1 Re. the Definition of SCA: No further Definition of the Nature of the “Three Elements”
With regards to the definition of authentication elements (knowledge, possession, inherence), the majority of respondents was of the view that the EBA should refrain from further defining the nature of the three elements in order to ensure technology neutrality and allow for the development of user-friendly, accessible and innovative means of payment.
3.2 Re. the Application of SCA
a. Principle-Based and High-Level Requirements
A majority of the responses requested the EBA to define the requirements of SCA in a way that would facilitate the development of innovative security solutions in years to come, as well as to facilitate an utmost of consumer convenience. The majority took the view that the requirements of SCA should be as much as possible principle-based and high level and should not prescribe specific technical solutions.
A few voices, however, requested further clarification on the relationship between authentication elements, the personalized security credentials (“PSCs”), and the SCA procedure. This request is based on the concern that the SCA was in fact already a “weak” authentication method, as there are already other solutions that are much more secure than the “strong two-factor” authentication under PSD 2 but would not comply with the requirements of the latter.
b. “Dynamic Linking”: EBA Should Take a Neutral Position
It has been pointed out with regard to the “dynamic linking” to the amount and payee for electronic remote payment transactions that EBA should remain neutral as to when the “dynamic linking” should take place. In particular the EBA should not require that the authentication code in the form of a one-time password sent to the payer is generated based on algorithms that take into account the amount of the transaction and the payee. Otherwise, the respondents argued, such requirement could prevent PSPs from adapting the SCA solutions currently implemented in compliance with the EBA’s SECUREPAY Guidelines, in order to make them compliant with the requirements of dynamic linking.
Furthermore, many responses also underlined a number of cases where, for electronic remote payment transactions, the “dynamic linking” might be difficult to implement, e. g. where the amount of the transaction might not be known (example: a card-based payment transaction for which the payer has given consent to the exact amount of the funds to be blocked, e.g. car rental deposit) or for bulk payments where several payment orders are agreed by the Payment Services User in one “transaction”.
c. E-IDAS Should Not be the Only Solution
Due to possible synergies, many respondents were of the view that e-IDAS regulation might offer one of many suitable solutions on which PSPs could rely for ensuring the SCA procedure, but should not, however, be considered as the only solution.
3.3 Re. Exemptions from the Application of SCA
a. Customer Convenience and User-Friendly Payment Solutions
Many stakeholders requested to put a stronger emphasis on consumer convenience as a key driver for electronic payment transactions to avoid “apathy” on the customer side due to excessive use of the SCA, and avoid an increase in transaction costs due to the implementation of SCA.
b. No Mandatory Exemptions
Many respondents underlined that the exemptions from the application of SCA shall not be mandatory for PSPs, so that the PSPs are always in the position to apply SCA in case of risk of fraud, even on transactions that would meet the criteria for exemption.
c. Divergent Views on Other Aspects of the Exemptions
Further divergent views were expressed depending on the category of the respondent.
Non-Exhaustive List of Exemptions
A vast majority of banks and banking associations were of the opinion that the list of exemptions should not be exhaustive in order for the PSP to apply exemptions based on its own transaction risk analysis. An exhaustive list could not be future proof and might prevent future innovations in fraud prevention analysis.
Clear and Limited List of Exemptions
By contrast, other respondents, in particularly payment initiation services providers (“PISP”), underlined a strong support for a clear and limited list of exemptions to ensure a high level of security, transparency, a level-playing between PSP and to expose the payer to SCA on a regular basis, so that the latter get accustomed to the application of SCA. These exemptions should also equally apply to Payment Initiation Services (“PIS”) and Account Information Services (“AIS”), without any discrimination from the Account Providing Payment Services Provider (“ASPSP”).
Specification of Thresholds
With regards to the exemption of low-value payments, many respondents requested that the EBA shall specify the threshold for such transactions.
Exemption for Consultative Services
Finally, several respondents, in particular Account Information Services Providers, were in support of an exemption for purely consultative services with no display of sensitive payment data. In the latter regard some respondents requested to clarify the term “sensitive payment data”. The definition of that term seems difficult as the fact that sensitive payment data may differ from one payment instrument to another. However, for the sake of legal certainty, the EBA should at least provide examples of what constitutes sensitive payment data.
4. Conclusion
While the changes in some areas caused by the PSP 2 are rather limited, the regulations on SCA are one of the major changes with a material effect on the market. They present considerable challenges to the PSPs, as (i) their scope of application is extremely wide (ii) they may severely affect consumer experience and (iii) may possibly even weaken the safety of online payments in the long run. As described above, the market gave feedback to these challenges. In Part 3/3 of this short series of articles we will have a closer look on how the EBA took into account and implement the feedback from the market in its draft RTS and provide an outlook on the impacts of the RTS on the payment sector.
