Earlier this month, The European Banking Authority (EBA) issued new guidance on the implementation of the regulatory technical standards (RTS) on strong customer authentication (SCA).

Since the release of the PSD2 RTS requirements back in March, there’s been significant discussion about several of its provisions, including exemptions from SCA and what authentication methods are necessary for PSD2 compliance.

The regulation is top of mind for banks for good reason. It’s opening the door for open banking by mandating that European financial institutions allow third-party payments providers (TPPs) to connect to their internal systems through open APIs.

Here’s an overview of the latest clarifications from the EBA on PSD2 strong customer authentication requirements.

RTS Requirements for PSD2 Compliance

Deciphering PSD2 compliance comes down to more than just understanding the technical requirements of strong customer authentication. The many players interacting around every transaction also raise questions of responsibility. Who decides when SCA applies and who must actually implement the technology?

Two-factor authentication requirements

The EBA made it explicitly clear: SCA must be composed of two different elements from two different categories.

Under PSD2, those categories are:

  • Knowledge: something only the user knows, like a password. A credit card number with CVV and expiration date printed on the card does not qualify as a knowledge element.
  • Possession: something only the user possesses, like a mobile device, token, or smart card. For device ID to be considered a possession, it has to be confirmed with a dynamic validation element on the device.
  • Inherence: something the user is, typically based on biometrics, like a fingerprint or voice, or on behavioral biometrics, to monitor a user’s unique actions.

The critical update is that account servicing payment service providers (ASPSP) will need to carry out an authentication procedure that combines two of these three categories.

Who’s responsible for implementing strong customer authentication?

Are ASPSPs or TPPs required to apply SCA? The EBA has resolved the issue, and the answer is ASPSPs hold the responsibility. They are the ones that issue personalised security credentials and make the final decision about whether or not to apply an exemption.

That doesn’t mean SCA can’t be outsourced to a TPP. It can, according to the EBA, citing wallet providers as one example. Overall, however, one of the main RTS requirements is that account information service providers (AISPs) and payment initiation service providers (PISPs) are able to rely on all authentication procedures issued by the ASPSP to its customers.

Finally, when deciding what strong customer authentication methods to use, the ASPSP needs to ensure that all the methods available to their own customers are also supported when that customer uses an API.

Balancing SCA with the User Experience

A bigger question for TPPs is how to carry out SCA in a way that doesn’t disrupt the customer experience while still keeping users secure.

Studies show that when authentication methods are clunky or inconvenient, users have no problem abandoning their transactions.

The inherence category for SCA is built on authenticating a user by their physical characteristics or their behavior. Relying solely on the physical means that authentication is not continuous and the user is asked to supply something, like a fingerprint. Relying on behavior ensures that a session can be consistently monitored for fraud from login to logout.

Behavioral biometrics not only detects fraudsters throughout a session, but it is the only way to protect users without actually asking them to do anything. Instead, behavioral biometrics relies on the user’s native behaviors, how he or she routinely interacts with an application, to build up a profile of that user’s unique actions and then track anomalies against it.

How do they type or click? How fast do they scroll? When an action is not the norm for that user, TPPs are immediately alerted to the threat of fraud. Behavioral biometrics works completely in the background, so fraud detection is happening unbeknownst to the user, which is just the way they like it.

The June opinion from the EBA is not the final say on PSD2 compliance. In the coming weeks and months, the EBA has promised it will continue to provide much-needed clarifications on the RTS as banks gear up to fully implement the new measures by September 14, 2019.

Going forward, properly securing transactions will be crucial not only for PSD2 compliance, but also for banks to block fraudsters from launching attacks against the new technology.

Looking for a strong customer authentication solution to help you meet RTS security requirements? Take a look at our data sheet on the behavioral biometrics in a PSD2 world.

Related Posts