The European Union’s revised Directive on Payment Services (PSD2) is more than a complex compliance project; it will usher in years of dynamic market change. PSD2 went into full effect on 14 September 2019, but the European Banking Authority extended the deadline for strong customer authentication or SCA until 31 December 2020.
Firms face a dual challenge, to be met in record time. Firstly, they must address the new requirements comprehensively and manage additional security risks and liabilities imposed by them. Secondly, they have to prepare for an entirely new business dynamic in a way that secures their business against disruption.
As mandated under PSD2, the European Banking Authority’s regulatory technical standards (RTS) regarding strong customer authentication and common and secure communication define the enhanced security and authentication requirements that all relevant parties must use. Many practical questions remain, but such analysts as the Payments Advisory Group are on hand to endorse patented software and certify that it meets all the relevant articles of the RTS. The PAG reviews authentication and app security products and then makes its declaration about their compliance.
What follows is a summary of the basic requirements set out in the RTS.
Strong customer authentication
Except in defined circumstances, strong customer authentication (SCA) is obligatory under PSD2 when a payer or proxy accesses payment accounts online, initiates an electronic payment transaction, or carries out any action through a remote channel that may imply a risk of fraud or other abuse. An SCA procedure must use at least two of the following factors:
- Knowledge – something that only the user knows (e.g. password, PIN, or identification number);
- Ownership – something that the user possesses (e.g. token, smart card, mobile phone);
- Inherence – something that the user is (e.g. a computer-readable biometric characteristic)
Some RegTech firms (including Transakt) use digital certificates to uniquely identify each registered mobile phone or tablet, transforming it into a trusted factor of possession.
These certificate are also used to generate authentication codes for every individual operation and to sign them digitally, thereby guaranteeing the authenticity of any digital transaction. In other words, the software proves that the customer initiated and authenticated each operation. There is no chance in this case that an interloper can intercept and modify any operation by mounting a man-in-the-middle attack.
The independence of the elements of SCA
The transmission and use of authentication factors must be independent of one other, so that a breach of one will not compromise the other. The channel, device or mobile app through which the authentication code is generated and received must be independent from the channel, device, or mobile app to be used for initiating each transaction.
Cryptographic software that complies with the pronouncements of the US National Institute of Standards and Technology might be appropriate here.
The transmission and the use of authenticating factors must be independent of one other, so that a breach of one will not compromise the other. The channel, device or mobile app through which the authenticating code is generated and received must be independent from the channel, device or mobile app used for initiating the transaction.
One way of solving this problem is by installing an app on a mobile device which generates a pseudonymous digital certificate that uniquely identifies it. This certificate is only linked to the customer by the IT service provider at registration, so only the provider is party to the relationship between device and customer. If the device is stolen, lost, or replaced, the provider simply unlinks the certificate from the user, rendering the app unusable.
Is the separation of SCA elements possible on mobile devices?
The RTS state that a transaction and corresponding authentication can be conducted on the same device if all authenticating factors are separated on it adequately. This has proved controversial among IT people. The perfect encapsulation of a basic principle of SCA – the maxim that the breach of one factor of authentication should not compromise any other – very often presents problems when people try to apply it to mobile devices.
What the RTS say
Article 9 of the European Banking Authority's “Regulatory technical standards on strong customer authentication and secure communication under PSD2” is entitled "Independence of the elements." It states the following.
1. Payment service providers shall ensure that the use of the elements of strong customer authentication referred to in Articles 6, 7 and 8 is subject to measures which ensure that, in terms of technology, algorithms and parameters, the breach of one of the elements does not compromise the reliability of the other elements.
2. Payment service providers shall adopt security measures, where any of the elements of strong customer authentication or the authentication code itself is used through a multi-purpose device, to mitigate the risk which would result from that multi-purpose device being compromised.
3. For the purposes of paragraph 2, the mitigating measures shall include each of the following:
(a) the use of separated secure execution environments through the software installed inside the multi-purpose device;
(b) mechanisms to ensure that the software or device has not been altered by the payer or by a third party;
(c) where alterations have taken place, mechanisms to mitigate the consequences thereof.
Commenting on the draft RTS, Klarna, a prominent Stockholm-based payments provider, raised widely shared concerns about requirements in Article 9 as it was then phrased: "With regards to the independence of the authentication requirements we do find it problematic that data delivered to a device has the requirement for independence in the SCA elements as they thereby mutually exclude each other. In the example given the mobile device (the possession element) makes the code (the knowledge element) sent to the mobile device insufficient."