This is the third of a three-part series of posts detailing the EU’s PSD2 Strong Customer Authentication (SCA)
We’ve reached the third and final installment of this series. In the first installment, we introduced the European Union’s European Banking Authority (or EBA) directive called PSD2 (short for The Second Payment Services Directive) and outlined some of the guiding principles of Strong Customer Authentication (or SCA). The second installment explored the SCA limitations and regulations that implementers must consider including the authentication codes, dynamic linking of the transactions, and channel independence.
For this post, we will outline SCA implementation options that should satisfy the requirements outlined in the PSD2 RTS (Regulatory Technical Standard), as well as some good places to look for more information.
Before we look at some implementation options for SCA, we should also point out that there are some exceptions from strong authentication and dynamic linking.
In the PSD2 Press Release FAQ, they note: “[exemptions are] to avoid disrupting the ways consumers, merchants and payment service providers operate today. It is also because there may be alternative authentication mechanisms that are equally safe and secure. However, “payment service providers that wish to be exempted from SCA must first apply mechanisms for monitoring transactions to assess if the risk of fraud is low.” The specific exemptions are outlined in Chapter III of the PSD2 RTS.
Two areas where Strong Customer Authentication is called for in PSD2
- Account Access – this is access to payment accounts through any device: desktop, laptop, tablet, or mobile phone.
- Payments – this is the actual authentication of a payment, including the dynamic linking of the payment information with the authentication method.
In today’s multi-device, multi-channel world, there are a variety of methods of banking / payment applications to accomplish authentication, from simple SMS-based 2FA to the more sophisticated (and secure) Universal 2nd Factor (U2F) from the Fido Alliance along with everything in between.
We typically have four major configurations today:
- Two devices – one running the banking/merchant application; another providing the authentication. This would include hardware tokens as well as U2F devices as authentication devices, but would also include a mobile device and a laptop with the laptop running the banking/merchant application and the mobile device providing authentication (even Out-of-band authentication)
- Two apps, one device – on a single device, typically a mobile phone, we would have the banking/merchant app and an authentication app. The authentication app could include a soft-token solution such as Google Authenticator or a specialty-built authentication app that would integrate with the banking/merchant to transfer, for example, dynamically linked purchase information to the authenticator app.
- One app, one device – an example would be a mobile banking app that also provided the authentication capability within that app.
- Out-of-Band – or OOB Authentication – this includes SMS sent to mobile phone number, secured by a SIM card. In this case, the mobile device, reached through an out-of-band channel such as SMS (or even RCS, when it is supported) will be the 2nd factor (possession).
Given all these options, what would be the best options and methods to support PSD2 SCA and be compliant?
The Out-of-Band option (OOB) is the easiest and most well-known method to consumers. It is fully compliant with the rules for Account Access and should be an option for Payments as long as the payment information is included in the SMS. It also meets the requirement of channel independence.
Of course, these days, there are some security issues with SMS; however, many these are somewhat overblown in the press (e.g. SIM-swap, SMS interceptions). That said, there are better, more secure methods. If using SMS as an OOB channel for 2FA, consider adding an additional knowledge factor to further secure the account or payment. That will provide additional security against certain SIM-swap or SMS-interception scenarios, should they occur.
One of the problems with the multi-device (2-device) authentication option using various hardware devices for authentication for payments is that it is difficult to incorporate the dynamic linking of payment / merchant information back to that authentication device. While many of these are quite secure such as U2F devices, it is difficult to incorporate dynamic linking of the purchase / payment information.
One method that would be useful would be to use an Authentication solution that still creates a standardize PIN code in the cloud, but uses encrypted information sent to a specialized Authentication app. The banking/merchant app could also include the payment information along with code which would be sent to the authentication app.
The authentication app would present the information to the user and then reply with an “Accept” or “Deny.” The authentication app could be part of a two-device strategy as well as a two-app (one device) strategy. The app would not depend on phone numbers (e.g. OOB), and therefore be resistant to SIM-swap or device hijacking. Additionally, the device would have to be in physical possession of the account holder along with knowledge-based information of the account holder.
Fortunately, there are many options available to EU payment providers, who will need to implement PSD2 SCA in the coming months. Each will have specific use-cases that should be examined closely to determine if SCA resources should be applied. Here are a few tips:
- Examine each use-case
- Understand if SCA exemptions may be applied
- Determine is the use-case related to account access or payments
- For payments, determine how you will present the payment information and merchant to the user (dynamic linking)
- For account access, we suggest always applying two-factor authentication to logins – it’s just more secure
For most EU markets, we expect the most prevalent method for online shopping and payments would be through a mobile device. Therefore, that implies the device will be used both as the primary device for shopping/payments as well as for authentication. Don’t always expect that users will be using desktops or laptops. Mobile device usage (including tablets) will only increase as primary devices.
PSD2 SCA is a complex set of regulations, but with some common sense and understanding about today’s authentication challenges and options, it can be implemented meet these regulations as well as protect all parties involved. In recent months, there have been some criticisms of some of the requirements of SCA and some of the limitations that they impose. In fact, there may be follow-up regulations (PSD3?) in the coming months and years.
Don’t be afraid to go ahead and implement SCA if you are involved in online payments. Don’t wait until the last minute. Take the time to read the requirements, study them, and then make decisions. There are many options out there and we hope this 3-part series has been helpful in guiding you through the various options and elements of PSD2 SCA.
