Strong Customer Authentication under PSD2: the Good, the Bad and the Ugly

an article written by Frederik Mennes, Director Product Security at OneSpan

In a few days, on 14 September 2019, the long-awaited Strong Customer Authentication (SCA) requirements under PSD2 will finally go into effect. Published about 18 months ago by the European Commission in the Regulatory Technical Standards (RTS) on Strong Customer Authentication and Common and Secure Communication, these requirements will impact the way consumers in Europe access their Internet banking applications, pay for e-commerce purchases, and use new financial services provided by Third-Party Providers (TPPs) via Open Banking.

In this article we look back at SCA under PSD2, and evaluate what went well and what is required for a further successful deployment of SCA in Europe.

1) The Good

PSD2 is increasing the security level for authentication to financial services across the whole of Europe, and is harmonizing the strength of authentication processes for financial applications. Because of PSD2, financial institutions have been phasing out weak authentication methods. Examples are solutions based solely on username/password combinations, and solutions based on printed lists of authentication codes, such as TAN-lists and matrix cards. As confirmed by the Opinion of the European Banking Authority (EBA) of 21 June, these solutions do not meet the SCA requirements.

PSD2 ensures that advanced authentication concepts, such as dynamic linking, device binding for mobile apps, mobile application shielding and transaction risk analysis become standard security tools in financial services. In this respect PSD2 goes much further than the EBA’s Final Guidelines on the Security of Internet Payments, which became applicable on 1 August 2015 and will be replaced by PSD2 on 14 September.

PSD2 is also accelerating the adoption of adaptive authentication methods, which adjust the way in which the user is authenticated to the risk of what the user wants to do. As such PSD2 allows striking a user-specific balance between convenience and security. This approach was included into the RTS thanks to the EBA’s openness and close collaboration with industry players during the drafting of the RTS.

2) The Bad

PSD2 puts the responsability for protecting access to bank accounts with the banks, also known as Account Servicing Payment Service Providers (ASPSPs). As banks own the bank accounts, this seems to make sense at first sight.

However when taking a closer look it becomes clear that this approach creates significant complexity in the context of Open Banking, as follows:

. First of all, users of TPP applications will need to authenticate twice: once in order to access the TPP application, and a second time to use a certain bank account via the TPP application.

. In addition, the authentication method and flow for a certain bank account depends on the bank. For instance, bank A might implement authentication using a card reader and “redirect” approach, while bank B might use a mobile app via the “decoupled” approach. Hence the user experience within the TPP application will depend on the bank.

As a consequence, the overall authentication experience for the average TPP user promises to be complicated.

However PSD2 itself is not to blame for this. The issue is the consequence of a larger problem that transcends PSD2, namely the absence of a pan-European digital identity system built on verified, trustworthy identities. Inspiration for such systems can already be found in multiple countries, such as Sweden (Bank ID) and India (Aadhaar). The challenge is to construct such system at European level. Such system is key for the future of Open Banking. Citi’s recent article provides further inspiration for this.

3) The Ugly

The SCA requirements of PSD2 are meant to be future-proof and technology-independent. They provide some leeway to Payment Service Providers (PSPs), meaning that PSPs can decide how to best meet a certain requirement. However, this may leave PSPs, who need to meet the requirements, in the dark. Some examples:

Usage of SMS for dynamic linking. The EBA has clarified in its Opinion from 21 June that SMS can be considered to be a valid possession element. More specifically the SIM-card in the mobile device that receives the SMS is a valid possession element. This implies that one-time passwords (OTPs) delivered via SMS can be used to construct a strong authentication mechanism when combined with a second factor (e.g. a password or PIN). However the Opinion does not clarify whether SMS can be used for dynamic linking. Indeed, the dynamic linking requirement in Article 5 of the RTS stipulates that the confidentiality and integrity of payment information (e.g. bank account number, amount of money) needs to be protected during the authentication process. Since the content of an SMS is typically not protected, it seems SMS does not meet the dynamic linking requirements.

Creating a Secure Execution Environment for mobile apps. The RTS states that PSPs must use secure execution environments to protect mobile apps. However, the final RTS does not define what a secure execution environment actually is, or how it could be implemented. Given the current state of mobile app security, the best approach to meet this requirement probably consists of using application shielding technology, protecting the app against threats such as overlays, code injection and keylogging.

Finally, the timeline for the enforcement of the SCA requirements of PSD2 has started to shift in recent months. Originally the SCA requirements for Internet banking and e-commerce applications would become applicable on 14 September 2019. On the same date, the requirement for banks to provide a communication interface for Open Banking would go into effect. However since the EBA published its Opinion on 21 June deadlines have become more fragmented. At the moment of writing the deadlines are as follows:

. Deadline for banks to implement SCA for Internet banking: 14 September 2019, except in the UK where the deadline is now 14 March 2020

. Deadline for implementing SCA for card payments for e-commerce: country-specific delays are allowed

. Deadline for banks to offer Open Banking interfaces: 14 September 2019

As a consequence, different PSPs might have different timelines to comply with the SCA requirements, and this could impact payments where multiple PSPs are involved. For instance, if a card payment is performed between a card issuer that complies as of 14 September 2019 and an acquirer that has received an extension of say 6 months, then the acquirer might send a request for payment without SCA to the issuer, but the issuer will decline the payment because it requires SCA. As a consequence, payments could be declined although both issuer and acquirer act correctly. This clearly raises the need for Competent Authorities (CAs) to grant extensions in a coordinated way. The EBA should play the role of coordinator between the different CAs here.

In Sergio Leone’s epic movie from 1966, the Good takes the gold, the Bad dies, and the Ugly is saved by the mercy of the Good. Let’s hope the movie’s script applies to PSD2 as well.

More in-depth analysis of PSD2 and its Strong Customer Authentication requirements is available at https://frederikmennes.wordpress.com

About the author

Frederik Mennes is an experienced business strategy director in the information security industry. He combines expert knowledge of authentication, identity management, and mobile application security technologies with about 14 years of experience in the financial services and healthcare markets. He is a recognized speaker in the information security field, with speaking engagements at Trustech, Money 20/20, RSA Conference, InfoSecurity Europe, Global E-commerce Summit, etc. He has over 7 years of experience in leading international teams, and has a solid educational background with master degrees in computer science, information security and business administration. 

Linkedin profile