Since SCA is just a part of a large directive, it is good to understand the two main goals of PSD2:

• Goal 1: Open up the banking and payment industries to spur innovation.
  This is achieved through APIs (Application Programming Interfaces) that allow the sharing data between established banks and a new breed of businesses that appeared within PSD2; the Payment Service Initiation Providers (PISPs) and Account Information Service Providers (AISPs). This part of PSD2 is commonly referred to as Open Banking. 
• Goal 2: Better protect the end-users when using banking services and when paying.
  This second subset of PSD2 is called Strong Customer Authentication, which is the topic of this article. 

When talking about SCA, it is often associated with multi-factor authentication (MFA) or two-factor authentication (2FA); however, if your business needs to be SCA compliant under PSD2, two-factor authentication is not enough.

2FA is an important part of SCA, but it is not the only requirement in the regulation. The requirements of the EBA are expressed in the Regulatory Technical Standards (RTS) and covers three main aspects:

• Two-factor authentication  
• Secure execution environments
• Dynamic linking 

In this article, we will give you a brief overview of the three different aspects of SCA and how SCA impacts the payment industry, but first, let's take a look at why SCA is needed.  

As users, we are used to receiving a password by SMS from our bank when completing a purchase online. This is a One-Time-Password that we need to enter into a web browser or in an app to complete a purchase; this practice is known as OTP by SMS. OTP by SMS is using a protocol called 3DSecure v1 (3DSv1) which is supporting the entire payment process when it comes to authenticating a user when completing an online purchase.

When first introduced several years back, OTP by SMS was a useful method to fight online fraud; however, fraudsters have also benefited from technological advancement and have become more innovative. Today it is a known fact that SMSs can be listened to, intercepted, and eventually modified by either hacking the smartphone or the telecom network. OTP by SMS is thus no longer viewed as a completely secure method. For that reason, the EBA decided that some drastic measures had to occur to authenticate users in a better and safer way, hence the need for SCA. 

While we are security-conscious when setting up passwords, passwords can easily be broken - either by brute force, phishing, or social engineering. And, with more and more services requiring passwords, there is a big chance of people using the same password for several services. As such, accessing your bank account, changing your phone number, creating a wire transfer, or creating a new beneficiary for money transfer, are all at risk when you use traditional credentials (such as a user name and a password), regardless of how sophisticated they may be.

To keep us secure, SCA applies to more than just online payment transactions. It also applies to transactions occurring with or within a bank web service, whether it is performed in a web browser or a banking app. 

The requirements of the EBA are expressed in the Regulatory Technical Standards (RTS). They are not exactly "technical" as one might expect with a protocol; for instance, it just defines what is expected Two-factor authentication is one of the expectations in the RTS. 

End-users will have to authenticate using two factors (2FA) amongst three possibilities: 

• Possession: this is what the user has. 
• Knowledge: this is what the user knows. 
• Inherence: this is what the user is. 

For possession, the smartphone is so pervasive in our daily lives that it has imposed itself as a natural candidate for possession. So, when users use their smartphone as part of the authentication, the device is checked by the bank services. The check is invisible to the user, or what is often referred to as frictionless to the end-user. To be able to authenticate using a smartphone, the end-user would use a banking app installed on the smartphone. 

Previously OTP by SMS has been used as a proof of possession, however, receiving an OTP by SMS does not prove possession, for the reasons expressed earlier on. That fact makes proving possession more complicated for users that do not own a smartphone but have a "dumb-phone" or even just a landline. 

For knowledge, the end-user can enter a password. This is a code only known by the end-user, and it is different from the password used as part of the credentials. This usually is a 4-to-6-digit number. It can be a fixed code or an OTP. Since OTPs by SMS can be intercepted, the OTP, in this case, should be sent in a secure channel between the bank service and the end-user app. Think of this as an authentication tunnel instead of an unsecured SMS. 

For inherence, many traits of a person can be used. This is the realm of biometrics. This has been made possible because modern smartphones have biometric capabilities. Finger and face recognition have become two common biometric methods that we all use in our daily lives.  

2FA is the visible part of the SCA iceberg. But these factors can be broken if they are not properly secured when a transaction occurs. The RTS is adamant that the factors are protected so that if one factor is broken, this does not imply that the second factor is.

To ensure this, the RTS introduced two important security requirements: a secured execution environment and dynamic linking. These are the "hidden" part of the SCA that the end-users do not see, but they are still crucial to securing the authentication. 

Simply put, providing a secure execution environment is to make sure that the environment where the authentication is taking place is secure. At the moment when a transaction is authenticated, the environment should be secure enough to guarantee the integrity, authenticity and confidentiality of the authentication. This can be achieved either with specialized hardware or with a software solution on a smartphone. 

Here issuers are facing an important challenge with their users' smartphones. Users do not necessarily have up-to-date Operating Systems on their smartphones. And it is a known fact that around two-thirds of Android phones no longer receive any updates from the manufacturers. A phone that is not updated can be a threat, as there will be several known security vulnerabilities that can be exploited.

This has many implications for issuers in terms of security choices. Issuers also have a responsibility regarding financial inclusion and cannot just opt users out of their services. Separating the environment from the OS and securing it with security mechanisms makes sense in this context. 

Think of the dynamic linking as a unique code that is specifically created for one transaction, linking the user with the transaction-specific information. This code can be visible or invisible to the user when authenticating. If the code is tampered with, the transaction is invalidated. 

Dynamic linking has to be protected throughout the authentication process. In case of an online purchase, the merchant name, as well as the amount to be validated, will appear on a user interface (banking app) on the user's smartphone. This has to be protected throughout, meaning when the user presses the "ok" button and goes through a biometric challenge, the information is indeed genuine, the user signs what they see. A typical attack on dynamic linking would be an overlay attack, hiding the fraudulent transaction at the moment of validation. 

A well-implemented secure execution environment and dynamic linking protection should help fight against any attempt to tamper with an SCA and fend off the most innovative types of attacks like malware caught on the root of a smartphone. 

For end-users, having to complete a two-factor authentication is the biggest change brought on by SCA. The other aspects of SCA do not affect the user flow for the end-users significantly.

It is important to note that SCA is not applied to all transactions. For online payments, small amounts are not subject to SCA. It is only when a payment hits an amount threshold that SCA will be a requirement. This is the same for physical and contactless payments with a plastic card. And some types of transactions are exempt from SCA: parking payments, phone order payments, corporate wire transfers, etc.

SCA impacts the entire chain of payment and payment is clearly the most complex SCA process; but beyond complexity, there is a major shift in liability when fraud occurs and needs settling.

The liability shift is an important topic. With 3DSv1, an e-merchant could switch off the authentication step (also called the out-of-bound authentication process). In this case, there would be no OTP by SMS sent to check the identity of the user, and the process would be deemed as "frictionless". Friction in the purchasing process has proven to increase the risk of purchase abandonment, and thus many e-merchants prefer to remove friction wherever they can. However, if 3DS is switched off and there is a fraud, the liability to settle it will be with the e-merchant and its acquiring bank. If 3DS is turned on and there is a fraud, the issuing bank is responsible.

With PSD2, this is no longer possible. The issuer remains the sole decision-maker to run an authentication step. For issuers, there might be a temptation to run SCA for all transactions systematically. Naturally, this led to debates and lobbying. 

The initial deadline for SCA implementation was September 2019. The complexity to move an entire ecosystem at once, and some lobbying taking place because of the liability shift, led to the deadlines being postponed to the end of 2020 in most countries in the EEA, and then beyond. In the UK, there are two deadlines set by the national competent authority, the FCA. March 2019 for in-app SCA, and September 2021 for payment SCA. In France, the naca – La Banque de France – postponed implementation to the end of March 2021.

3DSv2 was introduced after 3DSv1 to take into account the new requirements when payment is concerned, and 3DSv2.x has two main parts: One that is used by the acquirer/e-merchants, and the other one by the issuer which manages the Access Control Server. The two parts discuss via the card scheme networks like that of VISA and Mastercard.

3DSv2 allows the transfer of a lot more information between the acquirer and the issuer. This information is the base for Transaction Risk Analysis (TRA). A risk analysis can trigger or avoid SCA.

For online purchases, as with contactless payments, there are thresholds. The fraud rate of the acquirers sets the amount that triggers the SCA. The higher the fraud rate experienced by an acquirer, the higher the threshold requiring SCA. This means that acquirers need to know and manage their fraud rates accurately. This, of course, will become a competitive advantage to acquirers vis-à-vis e-merchants.

Issuers are faced with two important challenges with SCA. 

The first one is the user journey. Issuers need to create the simplest and most consistent user journey for both payment and in-app SCAs. This means systematically using their app as the point of authentication as opposed to OTP received by SMS; and using the best couple of authentication methods so that the journey when authenticating is as frictionless as possible – i.e. smartphone + biometrics. 

The issuers also have to choose the best fallback options given the many use cases and situations: a smartphone with no data coverage but phone coverage, a user without a smartphone (i.e. old generation mobile phone), a corporate user (even if corporate payment is an exemption), etc. This means choosing to phase out OTP by SMS while, in parallel, educating their users about the changes taking place. 

Issuers also need to make sure that the enrolment to the SCA service (new user) and the re-enrolment (loss, theft or re-initialisation of a device) is secured, meaning they have to find solutions to strengthen the possession factor. For instance, against SIM-swap attacks. 

The second challenge is to make sure that the SCA is compliant with the RTS, especially with the two important security requirements of a secure execution environment and dynamic linking, as we discussed previously. Any issuer that manages to be fully compliant while still providing a good end-user experience will have a competitive advantage. 

SCA is complex, with many implications. Our entire blog section is dedicated to SCA and the many challenges the industry, and the issuers, in particular, are facing. We hope you find the right content to your questions. If not, do not hesitate to contact us at hello@okaythis.com.  

If you want to dig deeper into the topic of SCA industry challenges, we recommend our blog series and white paper dedicated to the topic.