Regulatory compliance related to Strong Customer Authentication (SCA) can be one of the most demanding tasks for any PSP. The number of required routines, systems and reporting requirements from national supervisory agencies alone can be pretty daunting. Whether it is anti-money laundering or operational/security/financial/IT risk management (including anything related to GDPR), the list can appear endless.

Nevertheless, if a "regulated entity" is performing payments, they must use SCA. It should be done during the signup process of new customers, whether it takes place at the point of device-account binding for doing password management, changing user data, or managing whitelists and cards. 

Perhaps most importantly, SCA is also required when making payments. At least when there is no exemption involved. One difference between the SCA requirements and most other regulations is that SCA requirements are based on computer security theory. Let us start here as we begin to look at the fundamental requirements.

The requirements that follow are from the EU's Payment Services Directive 2 (PSD2) Regulatory Technical Standards (RTS) regarding SCA. Starting in Article 4 of the RTS, the first requirement is for authentication to consist of two out of three elements. The elements are  

1. possession
2. knowledge and 
3. inherence

Typical examples of these three elements are:

• a device fingerprint (possession),
• a password or a PIN ("personal identification number" - knowledge), and 
• a biometric fingerprint (inherence)

Once authentication is completed, it has to be linked to the transaction details using a Dynamic Linking process. For more information on how this works, see our article on SCA.

A direct result of these requirements is that authenticating with a smartphone becomes a tempting option, as other options (such as dedicated hardware dongles) are either expensive or not allowed. Moreover, in Article 9, two essential requirements come into play once a smartphone device is chosen as the medium of authentication: 

1. If any element of the authentication takes place on a multi-purpose device, the PSP is required to use a separate secure execution environment through the software installed on the device and 
   
   
2. There should be mechanisms to "ensure that the software or device has not been altered by the payer or third party", as well as mechanisms to mitigate the consequences of any said changes.

The RTS then defines a series of requirements to how the security credentials are to be used, starting in Article 22. These requirements should be familiar to anyone who has done a security audit, including the credentials' authenticity, integrity, and confidentiality. The credentials used should be kept secret, cannot be changed during transmission or entry, and must be authentic to the individual customer. 

As one can imagine, this presents an issue when SMS is used as part of the authentication process. As such, it is imperative to be aware of these potential problems if considering using SMS during onboarding, re-enrollment, or as part of the authentication process.

The RTS may define the SCA process, but it is a requirement that follows in part from PSD2 requirements and in part from the last decade of payment trends. 

In our eyes, the PSD2 background serves as a wish to open the payment market up in the same way that European mobile phone markets opened throughout the 1990s. During this time, Europe went from a situation where phones were being rented from state-owned telecoms, to multiple competing mobile networks alongside a spectrum of new services. 

We believe the PSD2 increases the European payment market's competitiveness, similar to what happened in the 1990s. However, it is also important to note that by opening the market up to new technology, the market also becomes more susceptible to new types of crime and fraud. This makes the proper implementation of SCA requirements not "just another requirement", but the fundamental protection for consumer information and payments.

In the next post, we will look a bit closer at the other RTS requirements, and perhaps more importantly, at the consequences of noncompliance and the liability shift introduced with the PSD2.

————————————

This is part 1 of 3 of a series on PSD2 RTS SCA Compliance. Part 2 of the series focuses on the April 30th deadline, while Part 3 focuses on how Okay can help you meet compliance standards.