PSD2 and what it means for user authentication

PSD2 Explained

Open Banking is coming up. Starting September 2019, Account Servicing Payment Service Providers in the SEPA zone (aka “ASPSPs” or … banks) must provide Payment Initiation Service Providers (aka “PISPs” or … Fintechs) with an API to access accounts data and initiate payments. As a consequence, Strong Customer Authentication (“SCA”) must be enforced on this API.

Fintechs 1 – Banks 0

Europe has ruled that starting September 2019, banks must provide APIs so that Fintechs can access accounts data and initiate payments on behalf of users. Banks lost the case they had themselves brought to European courts (Deutsche Bank against Sofort) in an attempt to ban webscrapping, i.e, Fintechs accessing bank accounts through a browser agent using the users’ authentication credentials. Europe’s decision has translated into law as what is now known as PSD2 – the Payment Services Directive 2.

It does indeed prohibit webscrapping (under normal circumstances) but not the way the banks hoped for. For the banks, the case was indeed not about webscrapping, it was about whether accounts data had to be open to 3rd parties.

That data is what Fintechs need to provide value-added services such as accounts aggregation, budget planning, financial services, payments, and ultimately, loans. That would leave traditional banks with not much more than providing checking accounts.

A ground principle for Europe’s decisions has always been to foster competition as it is supposed to benefit consumers. Discussing whether or not this holds true from a theoretical or practical standpoint is way beyond the scope of this post; nevertheless, this is what motivated the ruling that will soon enter into effect as PSD2.

Fintechs 1 – Banks 1

A valid objection, if not the only one, which banks brought to the case was security and fraud. It’s indeed a bad security practice to have users provide their authentication credentials to 3rd parties, with the risk of a poor protection leading to potential dissemination and abuse. Banks rightfully argued that users would be responsible for fraudulent transactions performed with their credentials.

Banks got a point there and PSD2 requires (in the so-called RTS specifications) that payment requests using the bank account enforce strong authentication. This is a bittersweet decision for Fintechs: they got the API and access to data they were begging for but with a security requirement attached to it, which they fear might be used by the banks to hinder a simple access to the accounts data and thus distort free competition.

Exit SMS-OTP, exit grids and TANs, exit OTP generators

It’s too early to know whether banks will be good sports and if opening their APIs will spur competition benefiting consumers – which is why PSD2 was designed in the first place. Banks are under attack but they are not going to let Fintechs create value behind their back without reacting. Whether this will be by innovating, by dragging their feet to slow down competition, or by acquiring successful Fintechs, we’ll see that soon. But for now, let’s have a closer look at the “strong customer authentication” (SCA) mandated by the RTS and how it’s going to impact the security of payments.

Strong authentication for banking and payments has been required for a long time in Europe, but it was mostly at a country level. The definition of strong authentication and the operations or transactions that required it differ vastly among countries. The RTS go much farther than what was – and still is – the practice in many European countries.

In short, the RTS define strong authentication as a one-time proof based in a non-predictable and non-trivial way (understand, with sound cryptography) on at least 2 independent (compromising one must not give a way to compromise the other) authentication factors of different nature (such as knowledge, possession, inherence e.g. biometry). Furthermore, that proof must be dynamically linked to the amount of the transaction, or to the maximal amount that the user authorizes.

Exit SMS-OTP. Exit passwords. Exit grids and TANs. Exit OTP generators. What the RTS actually specifies is a 2-factor authentication solution completely aligned with the inWebo Transaction Sealing feature that we first implemented in 2012 to make secure transactions non-disputable – the seal being the dynamic link to the transaction amount.

The RTS also lists exemptions to strong authentication such as A/ payments under 30 Euros, repeat requests of a duly authorized recurrent payment, B2B payments; B/ payment requests scored as not or little risky: payment initiators (Fintechs) are given the option to skip strong customer authentication if they can maintain the fraud level below a threshold by applying transaction scoring instead; they will be audited and will have to prove that fraud is indeed maintained within authorized boundaries.

PSD2, theory and practice

Let’s conclude this post with what is clear with PSD2 strong authentication, but also with what is not clear at the time of writing – at least to the author.

What is clear is that banks must implement an API supporting strong authentication by September 2019 and that it should be available by March 2019 for test purposes (if you are in charge of this topic at a bank or a Fintech, you should definitely come talk to inWebo or check our authentication solution for PSD2).

Unclear is whether banks will be ready in time, whether they will be granted a delay, and what the APIs will actually give access to. Unclear is also to what extent banks will open their APIs without strong authentication to requests for which the RTS doesn’t mandate strong authentication – it would make Fintech services look overly secure and probably overly complicated. Unclear is finally who will be liable if a Fintech enforces its own compliant strong authentication and fraud prevention systems without using those of the bank i.e., can the bank pass the liability.

These are some of the open questions that time and adjustments to the regulation will answer.