By January 2018, all European Union payment providers will have to be compliant with the latest PSD2 (revised Payment Services Directive) requirements.
With this regulation, the European Union sends a clear message that it wants to enhance consumer protection and convenience and improve the security of payment services.
The goal of this regulation is to harmonize the European retail payments market and to secure internet payments across national borders by adopting convenient and secure payment initiatives. These initiatives are intended to combat Card-Not-Present (CNP) fraud and increase the confidence of European citizens regarding e-commerce, e-banking and other online activities.
The implications of PSD2 for payments industry participants are wide-ranging and complex. This article aims to guide you through the key elements of the new directive.
There is more to strong authentication than meets the eye
In order to be compliant with PSD2, payment providers cannot just implement any kind of strong authentication. There are specific criteria that must be fulfilled to achieve compliancy. We can discern five key elements in the PSD2 regulation:
• Two-factor authentication
• Independence of authentication elements
• Dynamic linking
• Transaction risk analysis
• Replication protection
Strong customer authentication
One of the key elements of PSD2 consists of the need to perform strong authentication of users of electronic payment services. Although strong payment authentication is already common practice in online banking services in many European countries, it may present a significant step for e-commerce services and may affect the check-out processes of e-commerce merchants.
Article 97 of the PSD2 regulation states that a user must authenticate himself when he accesses an online payment account, when he initiates an electronic payment transaction, or when he carries out any action through a remote channel that may imply a risk of payment fraud.
A basic definition of “strong customer authentication” is present in article 4(30) of PSD2. It states that authentication has to be based on the use of two or more possible authentication elements, categorized as knowledge (i.e. something only the users knows, such as a password), possession (i.e. something only the user has, such as a token) or inherence (i.e. something only the user is, such as a fingerprint or face scan). Furthermore, the authentication factors must be independent of each other.
Independence of authentication elements
If the authentication mechanism relies on a multi-purpose device such as a mobile phone or tablet, payment service providers must adopt security measures to mitigate the risk resulting from the multi-purpose device being compromised. This includes the use of separated secure execution environments as well as measures that ensure the software or device has not been altered.
In practice, this means that common mobile operating systems (e.g. Android, iOS) most likely meet the requirement of separated trusted execution environments via their sandboxing techniques. However, these sandboxing mechanisms can only function correctly as long as the device is not jailbroken or rooted. Hence, there is a need to protect mobile apps with root and jailbreak detection technology.
Payment Service Providers must also use security controls to detect, prevent and respond to the alteration of mobile apps and devices. RASP technology for mobile apps provides such security controls. More specifically, RASP technology provides security services to protect the confidentiality and integrity of mobile apps, to detect whether a device is rooted, to detect whether an app runs inside a debugger or emulator, etc.
Transaction risk analysis
PSD2 mandates the usage of transaction risk analysis to prevent, detect and block fraudulent payments. Transaction risk assessment should be based on elements such as the amount of the payment, known fraud scenarios, signs of malware infection in the payment session etc.
The regulation foresees that low-risk payments can be exempted from strong customer authentication. However, this entails that transaction risk analysis should include additional elements such as payment patterns, location of payer and payee, information about the device used to conduct the payment etc. The fraud rate of the payer’s payment service provider determines the maximum payment amount that can be exempted from authentication. The lower the fraud rate of the payer’s payment service provider, the higher the payment amount that can be exempted from strong customer authentication, with a maximum amount of €500.
Replication protection
PSD2 mandates the use of dedicated mobile app cloning countermeasures in applications. Mobile phones in particular are very vulnerable to cloning if they do not contain countermeasures. These countermeasures can include encrypting data used by the app using a cryptographic key stored inside the device’s Secure Element, or using a password or PIN to encrypt the data that is used by the app to generate an OTP (one-time password).
Dynamic linking
In case of a payment transaction, the authentication code must be dynamically linked to the amount and the payee, meaning that this code will change if either the amount or the payee is changed during the transaction. Additionally, in the case of mobile apps, payment information needs to be exchanged via a secure channel, and must be clearly shown the user.