The revised Payment Services Directive (PSD2) had a number of stated objectives, including to address security concerns that emerged alongside the growth in increasingly technologically sophisticated payment systems and practices. Its remit therefore included providing a clear legal framework to enable the establishment of an accessible common technological means for users of a payment service to provide consent that can be acted upon by a payment services provider. In this article, Roseyna Jahangir considers the detailed standards the EU authorities have produced to give guidance on addressing these.
PSD2 requirements
Article 97 of PSD2 requires Member States to ensure that a payment service provider applies strong customer authentication where the payer:
- accesses their payment account online
- initiates an electronic payment transaction, and
- carries out any action through a remote channel which may carry a risk of payment fraud or other abuses.
Member States must also ensure that payment service providers have in place adequate security measures to protect the confidentiality and integrity of payment service users’ personal security credentials.
Article 98 of PSD2 requires the European Banking Authority (EBA) to develop Regulatory Technical Standards (RTS) specifying:
- the requirements of the strong customer authentication required by article 97
- the exemptions from the application of article 97
- the requirements with which security measures have to comply, in order to protect the confidentiality and the integrity of the customers’ personalised security credentials, and
- the requirements for common and secure open standards of communication for the purpose of identification, authentication, notification and information, as well as for the implementation of security measures, between the various actors involved with payment services.
The Directive required that the development of the RTS by EBA should:
- ensure an appropriate level of security for payment service users and providers through the adoption of effective and risk-based requirements
- ensure the safety of payment service users’ funds and personal data
- secure and maintain fair competition among all payment service providers
- ensure technology and business-model neutrality, and
- allow for the development of user friendly, accessible and innovative means of payment.
What is strong customer authentication?
‘Strong customer authentication’ is defined in the Directive as an authentication based on the use of two or more elements categorised as:
- knowledge (something only the user knows), such as passwords, phrases or PINs
- possession (something only the user possesses), such as security tokens, and
- inherence (something that is a part of what the user is), e.g. fingerprint scanners or voice recognition technology.
The elements must be independent, in that the breach of one does not compromise the reliability of the others, and designed in such a way as to protect the confidentiality of the authentication data.
Two factor authentication is a common concept, akin to having two locks on a door. Strong customer authentication is already in use by certain sites. Examples include Chip and PIN for payment cards, where to require a payment to be made requires both the use of a PIN – i.e. something only the user knows – and a card with an embedded chip – i.e. something only the user possesses.
Additionally, for remote transactions (i.e. internet or mobile phone payments), an additional element may be required: a unique authentication code which links the transaction to a specific amount and a specific payee.
RTS provisions
The mandate from PSD2 to EBA in order to ensure secure communication between the relevant actors in the context of the services, was to specify the requirements of common and open standards of communication to allow for the provision of online payment services, to allow the interoperability of different technological communication solutions. When developing the RTS, EBA is to systematically assess and take into account the privacy dimension, in order to identify the risks associated with each of the technological options available and the remedies that could be put in place to minimise threats to data protection.
The EBA consulted on its proposals when drafting the RTS. The key issues the EBA focused upon were:
- the scope and technologically-neutral requirements of the draft RTS
- the exemptions, including scope and thresholds
- the access to payment accounts by third party providers and the requirements around the information communicated.
The RTS require payment service providers to have transaction monitoring mechanisms in place to enable them to detect unauthorised or fraudulent payment transactions. These should be based the analysis of payment transactions, taking into account elements which are typical of the payment service user in the circumstances of a normal use by the payment service user of the personalised security credentials. Accordingly, payment service providers must ensure that the transaction monitoring mechanisms takes into account, at a minimum, each of the following risk-based factors:
- lists of compromised or stolen authentication elements
- the amount of each payment transaction; known fraud scenarios in the provision of payment services, and
- signs of malware infection in any sessions of the authentication procedure.
The RTS specify the security measures that are to be required for the application of strong customer authentication. In order to achieve the objective above, payment services providers shall adopt security measures that ensure that each of the following measures is achieved:
- no information on any of the elements of the strong customer authentication categorised as knowledge, possession and inherence can be derived from the disclosure of the authentication code
- it is not possible to generate a new authentication code based on the knowledge of any other authentication code previously generated, and
- the authentication code cannot be forged.
Specific requirements include that the number of consecutive failed authentication attempts cannot exceed five, and that once logged on the customer’s account cannot be inactive for more than five minutes.
Additionally, the security measures must include the following:
- the payer is made aware of the amount of the payment transaction and of the payee
- the authentication code generated shall be specific to the amount of the payment transaction and the payee agreed to by the payer when initiating the transaction
- the authentication code accepted by the payment service provider corresponds to the original specific amount of the payment transaction and to the payee agreed to by the payer, and
- accordingly, the payment service provider must have security measures that ensure the confidentiality, authenticity and integrity of the amount of the transaction, the payee and the information displayed to the payer through all phases of authentication.
Other measures set out in the RTS include:
- requirements of the elements categorised as knowledge: measures should be adopted to mitigate the risk that elements known as ‘knowledge’ are protected from discus lure to or uncovering by unauthorised parties
- requirements of the elements categorised as possession: similarly, measures should be adopted that mitigate the risk elements categorised as possession are used by unauthorised parties
- requirements of devices and software and linked to elements categorised as inherence. Again, payment service providers should adopt measures to mitigate the risks that this category of such measures are uncovered by unauthorised parties
- independence of the elements: security measures must protect the elements independently, i.e. breach of one of the elements shall not compromise the reliability of the other elements, using measures that include the use of separated secure execution environments through the software installed inside the multi-purpose device and mechanisms to ensure that the software or device has not been altered by the payer or by the third party or mechanisms to mitigate the consequences of such alternation where this has taken place.
Exemptions
The EBA noted that when developing the RTS, it had to make ‘difficult trade offs’ including the objective of PSD2 to facilitate innovative payment services, which would suggest that the EBA should pitch the technical standards at a higher, i.e. less detailed levels, to allow room for the industry to develop industry standards or technical solutions that are compliant with the EBA’s while also allowing innovation over time, to exploit technological advancements and to respond to future security threats. A lack of detail may also result in many different industry solutions emerging across the European Union, thus leading to a fragmentation across geographical, sectoral and/or other lines, which would undermine PSD2’s objective of integrating retail payments in the European Union and facilitating competition across the European Union.
Additionally, EBA sought to balance the objective or ensuring a high degree of security and safety with user-friendliness.
These balancing exercises influenced the EBA when considering exemptions to the two-factor secure customer authentication requirements.
The RTS sets out exemptions for the following:
- where the user is limited to accessing either or both of the following items online without disclosure of sensitive payment data about the balance of one or more designated payment accounts; and the payment transaction executed in the last 90 days through one or more designated payment accounts, unless the customer is accessing this information for the first time or the last time the customer accessed this information online (and using strong customer authentication) was more than 90 days ago
- where the customer is using a contactless means of electronic payment, for a transaction of €50 or less and where there has been a secure customer authentication within 5 consecutive individual transactions or transactions amounting to €150
- where the transaction is being done remotely and them amount does not exceed €30, and there has been a secure customer authentication within €100 or 5 consecutive individual remote transactions
- where the purpose of the electronic transaction is to pay for a transport or parking fare at an unattended payment terminal
- where the payment is to a recipient that has been designated as a trusted beneficiary
- where the payer has initiated a series of transactions with the same amount and the same payee
- where the customer is making a payment to themselves.
The RTS also make provision for an exemption based on a transaction risk analysis, where the payer initiates a remote electronic payment transaction, and the circumstances meets certain requirements set out in the RTS.
If a payment provider is using one or more of the exemptions, they will have to record and monitor certain usage data on at least a quarterly basis, and make the results available to the competent authorities on demand.
RTS status
Although the Directive came into force on 13 January 2018, the RTS are still under review by the European Parliament and the European Council. If the text passes the scrutiny of both institutions, the RTS are expected to be published in the Official Journal of the European Union by in March 2018, and to come into force in September 2019.
This article was written for Compliance Monitor.
