< Back

Share |

Strong customer authentication under PSD2

The new Payment Services Directive (PSD2) will make a number of significant changes to the UK's existing payment services regime. This article considers just one of these changes: the introduction of a legal requirement for payment service providers (PSPs) to use strong customer authentication (SCA) under certain circumstances.

September 2016

The European Banking Authority (EBA) is currently consulting on draft regulatory technical standards (RTS) were published in a consultation paper on 12 August 2016 (Consultation Paper). Once finalised, the RTS will put the flesh on the bones of PSD2's SCA provisions, detailing (among other things) the authentication procedure, the requirements relating to elements categorised as knowledge, possession and inherence, and the exemptions to SCA.

PSPs' use of a form of SCA is already mandatory in the majority of the EU by virtue of local regulators' decisions to implement the EBA's Final Guidelines on the Security of Internet Payments (EBA GL/2014/12) (Guidelines). While the UK's Financial Conduct Authority decided to delay the implementation of the Guidelines in order to allow the PSD2 implementation timeline to catch up, many banks have already adopted a form of SCA as good practice.

As might be expected, PSD2 and the draft RTS contain much more detail on SCA than that found in the Guidelines. Given the weight of system and administrative change the adjustments to comply with the draft RTS may require, PSPs would be well advised to carefully consider the Consultation Paper, not least to understand how they can benefit from the exemptions to SCA set out in the draft RTS.

PSPs will have a little breathing space before having to implement SCA. PSD2 must be implemented in the UK by 13 January 2018 (at which point the UK will almost certainly still be an EU Member State), although the provisions relating to SCA will only apply from 18 months after the date of entry into force of the RTS, which, at the time of publication, is anticipated be October 2018 at the earliest.

Who will the new SCA obligations affect?

The requirement to apply SCA will affect the payments industry as a whole, and the retail space in particular. Merchant agreements and card scheme rules will need to be amended to take SCA into account, and online retailers can be expected to look to work with those payment providers that deliver SCA within the most seamless purchasing experience for customers.

What is SCA?

SCA means authentication based on the use of two or more elements categorised as knowledge (i.e. something only the user knows), possession (i.e. something only the user possesses), and inherence (i.e. something the user is). These elements must be independent so that breach of one element does not compromise the reliability of the others. The SCA as a whole must be designed in such a way as to protect the confidentiality of the authentication data.

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. Rather, the draft RTS provides that the elements should contain security features such as (in the case of knowledge) the use of non-repeatable characters and (in the case of possession), algorithm specifications. The use of knowledge elements must be subject to mitigation measures in order to prevent their disclosure to unauthorised parties, while the use of possession elements must be subject to measures designed to prevent replication of the elements.

The security features required for the inherence element are worth examining in more detail.

The security features of the inherence element

Security

The EBA has set a particularly high bar for use of authentication elements categorised as inherence. While devices and software provided to the payer to read inherence elements must possess securities features (such as algorithm specifications or biometric sensors), these features must also: (a) guarantee a "sufficiently low likelihood of an unauthorised third party being authenticated as the legitimate payment service user"; and (b) guarantee "resistance against unauthorised use of the elements" through access to the relevant device and software.

There is currently no guidance on the meaning of "sufficiently low likelihood", or "resistance". The requirement to "guarantee" security levels is also vague: for example, what level of "resistance" must be guaranteed, and what would be the consequences of a breach of this guarantee? We expect that the burden of proof of compliance would fall so heavily on the PSP that a breach would be considered to be tantamount to a failure to apply SCA (for which PSD2 allocates liability), but confirmation of this analysis would be welcome.

When should PSPs apply SCA?

PSD2 requires PSPs to apply SCA when the payer: (a) accesses its payment account online; (b) initiates an electronic payment transaction; or (c) carries out any action through a remote channel that may present a risk of payment fraud or other abuses (unless a relevant exemption applies (see below)). The payer's PSP (i.e. their account servicing payment service provider – often a bank) must apply SCA when a payer initiates payments, or requests information through, respectively, a payment initiation service provider or an account information service provider (each a new type of PSP under PSD2).

Electronic remote transactions (such as payments made over the internet or mobile phone) require an additional form of SCA, being the inclusion in SCA of elements which dynamically link the transaction to a specific amount and a specific payee. The concept of "dynamic linking" is new to PSD2 and represents another layer of authentication over and above that required by the Guidelines.

In order to dynamically link the transaction, the draft RTS states the following requirements must be met:

  • the payer must be made aware at all times of the amount of the transaction and of the payee;
  • the authentication code must be specific to the amount of the transaction and the payee;
  • the underlying technology must ensure the confidentiality, authenticity and integrity of: (a) the amount of the transaction and of the payee; and (b) information displayed to the payer through all phases of the authentication procedure (the EBA hasn't specified the nature of this "information");
  • the authentication code must change with any change to the amount or payee; and
  • the channel, device or mobile application through which the information linking the transaction to a specific amount and payee is displayed must be independent or segregated from the channel, device or mobile application used for initiating the electronic payment transaction.

There are additional requirements for card-based transactions involving blocked funds and batch payments.

Exemptions from strong customer authentication and "dynamic linking"

PSD2 formalises the requirement to have exemptions to SCA and requires the EBA to give further detail for exemptions to both SCA and dynamic linking. The draft RTS builds upon the Guidelines, although (as demonstrated by the table below) not all "alternative measures" have tracked across to become exemptions under the draft RTS.

The decision by the EBA not to include a "low risk transaction" exemption marks another significant change from the precedent set by the Guidelines. The industry had hoped to use such an exemption to identify low risk transactions given the pattern of client-specific and market behaviour. The EBA explains in the Consultation Paper that it while it recognises that there is "merit in implementing a transaction risk analysis", it did not include this exemption because it "was not able to identify which minimum set of information the RTS should require for such transaction risk analysis to be sufficiently reliable".

Type of exemption

Guidelines

Draft RTS

When Guidelines recommend "alternative customer authentication measures" could be applied (in summary)

Exemptions to SCA (in summary)

Exemptions to dynamic linking (in summary)

Trusted beneficiary

Outgoing payments to trusted beneficiaries included in previously established white lists for that customer

N/A

Where the payer initiates an online credit transfer where the payee is included in a list of trusted beneficiaries. This exemption does not apply if the payee has created this list for the first time or has amended the list

Where the payer has initiated an online series of credit transfers with the same amount and the same payee. This exemption does not apply if the payee has initiated the series of transfers for the first time or has amended the series

Transactions where payer and payee are the same

Transactions between two accounts of the same customer held at the same PSP

N/A

Where the payer initiates an online credit transfer where the payer and payee are the same person and the payee's payment account is held by the payer's account servicing payment services provide

Low risk transactions

Transfers within the same PSP justified by a transaction risk analysis

N/A

N/A

Low value payments

Low-value payments, as referred to in the PSD (in brief, an individual payment transaction whose value does not exceed €30 or a payment instrument which has a spending limit of, or stores funds that don't exceed, €150)

Where contactless payments of less than €50, provided that that the cumulative amount of previous consecutive electronic payment transactions without SCA doesn't exceed €150

Where the payer initiates a remote electronic payment transaction where (a) each individual transaction is capped at €10; and (b) the cumulative amount of previous transactions without the application of SCA is capped at €100

No disclosure of sensitive payment data

Purely consultative services, with no display of sensitive customer or payment information

Provided sensitive payment data is not disclosed, where the payer accesses exclusively the information of its payment accounts online.

"Sensitive payment data" is defined in PSD2 as "data, including personalised security credentials, which can be used to carry out fraud. For the activities of payment initiation service providers and account information service providers, the name of the account owner and the account number do not constitute sensitive payment data"


N/A

Conclusion

While the Consultation Paper is open to responses until 12 October 2016, the draft RTS and the EBA's view have already been shaped by responses to its earlier discussion paper on the same subject as well as by at least one roundtable with industry players. It is unlikely, therefore, that the EBA will, at this stage, substantively change its approach to SCA; rather, submissions should aim to assist the EBA to clarify its approach and insert nuance where this is lacking. Actors in the payments space would therefore be well advised to take note of the EBA's direction of travel (if not the detail) in respect of SCA, and to begin to analyse whether and how they should shape their operations to comply with PSD2 and to take advantage of the opportunities it presents.

If you have any questions on this article please contact us.

Strong customer authentication
Jonathan Rogers

      

Talia Carman





Jonathan and Talia look at the new legal requirement for PSPs to use strong customer authentication and at the exemptions which may apply.

"Given the weight of system and administrative change the adjustments to comply with the draft RTS may require, PSPs would be well advised to carefully consider the Consultation Paper, not least to understand how they can benefit from the exemptions to SCA set out in the draft RTS."