Evolution of the Passwordless Login: Europe’s PSD2 compliance

The European Union’s updated Payment Services Directive (PSD2) is already shaking things up for 2019. These new regulations won’t be active until September 2019, but industry experts are already positing that success under PSD2 may require a small sacrifice: The conventional password. As the need for stronger user authentication standards increases, the need for seamless, passwordless alternatives that provide necessary user protection increases as well. PSD2 compliance will be an international necessity, and businesses are going to need more savvy authentication practices.

Reports suggest that most payment service providers aren’t prepared for PSD2 compliance – but it is widely anticipated that those companies who do comply will be focusing on some form of passwordless login and authentication. Under the scope of the original Payment Services Directive, applicable transactions required both parties to be located within the EU. But under PSD2, all transactions with at least one party in the EU will be included.

This means PSD2 will be a global phenonmenon. And it may be what finally kills passwords for good.

PSD2 compliance will transform online commerce through authentication

PSD2 will ultimately change the face of user authentication. With its strong customer validation standards, multi-factor authentication will become a necessity for all electronic transactions that involve a party located in the EU, save those considered “low-risk.” Few exceptions will be made and basically all electronic transactions over €30 will fall under the Strong Customer Authentication (SCA) requirements.

Financial institutions will also need to provide third-party payment service companies with access to account balance and transaction data.

Under SCA, two or more of the following independent factors must be used:

“Knowledge – something only the user knows (password, PIN)
Possession – something only the user possesses (key material, token, encryption keys)
Inherence – something uniquely identifying to user (fingerprint, biometrics)”

For remote transactions, such as those that take place over the internet, a unique authentication code for dynamic linking will also be required, which will connect the transaction to a specific amount of money and a person.

So, in addition to complying with PSD2, companies must also be concerned with how they can meet these new security requirements without adding layers of inconvenience to the payment process. Multi-factor authentication is a key point of PSD2, but streamlining the verification process is necessary – and that means passwords are going to be left in the dust.

Moving onto greener, more secure pastures

The legacy authentication system is notoriously insecure. Passwords and one-time use codes are no longer enough to safeguard sensitive information. The countless data breaches we’ve seen in the last few years is proof enough – never mind the influx of account takeover, credential stuffing attacks and identity fraud.

Clearly, SCA is a step in the right direction – but it is going to fundamentally change the marketplace. Adding additional steps to the checkout process tends to increase cart abandonment, and because of that, compliance with new regulations has been slow to gain traction. Consumers want the payment process to be simple, but payment service providers need to comply with the security demands of PSD2.

Ultimately, this means companies must innovate and solve both problems at the same time. Meeting the SCA requirements while also providing users with a simple, streamlined authentication experience is necessary under PSD2. Encryption paired with biometrics and “invisible” device-based authentication methods are poised to drive the future of seamless but safe authentication standards.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>