This is the first of a three-part series of posts detailing the EU’s PSD2 Strong Customer Authentication (SCA).
The European Union’s European Banking Authority (or EBA) directive called PSD2 (short for The Second Payment Services Directive) was originally published at the end of 2015. By 13 January 2018, all member states were required to implement the regulations. This directive has implications for all banking, payment, fintech, and online merchants throughout the EU.
There are three key purposes of PSD2:
- To open new market opportunities for a variety of players such as online merchants, while leveling the playing field for all key stakeholders
- To provide consumer transparency and consumer choice
- To introduce new and more robust security practices for online payments
Of these, the one that we will focus on in this and two additional articles is the last one – new and more robust security practices for online payments. Specifically, this is called Strong Customer Authentication (or SCA).
The EBA notes: “Thanks to PSD2 consumers will be better protected when they make electronic payments or transactions (such as using their online banking or buying online). The Regulatory Technical Standard (RTS) makes strong customer authentication (SCA) the basis for accessing one’s payment account, as well as for making payments online.” While most PSD2 regulations are in effect as of January 2018, SCA has until around September 2019 to be operational.
Strong Customer Authentication’s guiding principle is to ensure that customers (e.g. consumers) are protected via an increased level of security when using electronic payments:
- When a customer (either individual consumer or business) accesses their payment account online
- When making an electronic payment (online and mobile):
- When carrying out actions through a remote channel where there may be a risk of fraud
There are a number of exceptions to these rules for SCA:
- For remote payments less than € 30, except:
- When a cumulative value of € 100 is reached
- Or when 5 payments up to € 30 have been made (e.g. every 5 payments under € 30)
- For contactless card payments up to € 50, except:
- When a cumulative value of € 150 is reached
- Or when 5 contactless payments up to € 50 have been made (e.g. every 5 contactless payments under € 50)
- At unattended payment terminals for transport fares and parking fees (such as for a metro train, etc.)
- Online transactions to an identified beneficial (trusted, by name). These may be card based credit transfers)
- Corporate payments if dedicated payment processes and protocols are used. These may require audit from a national authority to make sure all security levels are satisfied
- When an online payment account is accessed, except:
- The first time the account is consulted
- Every 90 days thereafter
- When fraud rates of the payment service provider (PSP) are lower than the pre-set reference fraud rates as described in the Annex to the PSD2 RTS).
These various exceptions are not strictly required, but the implementer – typically the merchant, coordinated with or the payment service processor, must weigh requiring SCA activities vs. consumer convenience. SCA basically calls for, at minimum, two-factor authentication (2FA).
Two-factor authentication means that users will need to prove their identity by two separate elements of three:
- Something they know (a PIN code or password)
- Something they possess (a mobile device, a card)
- Something they are (fingerprints, face scan: e.g. biometrics)
Fortunately, there are wide variety of 2FA solutions already in place that can be applied to conforming to SCA and are widely accepted by consumers such as tokens (codes) sent over SMS or other channels. Another fortunate fact is that the EBA does not specifically specify how SCA (or 2FA under SCA) may be implemented.
The international law firm Taylor Wessing, in their paper: Strong customer authentication under PSD2, notes that the “The EBA agreed with the majority of respondents to the Consultation Paper that, in order to ensure technology neutrality and allow for the development of user-friendly, accessible and innovative means of payment, it should not define the authentication elements further.”
In part 2 of this series, we’ll go deeper into the limitations and specific regulations that SCA implementers must consider: details around authentication codes, dynamic linking of the transactions, and channel independence.
Want to follow along on Twitter? You can find me here.