I have recently released a new report looking at the second phase of the Payment Services Directive (PSD2) and its security requirements along with my colleagues Jacob Morgan and Andras Cser. Banks and financial institutions are currently hard at work building APIs and testing their Strong Customer Authentication (SCA) solutions. Banks need to comply with the PSD2 SCA Regulatory Technical Standards (RTS) by September 14, 2019.

While many of the security requirements in the RTS are well intentioned, vague and ambiguous wording has hampered its implementation significantly. Here is what we have observed:

  1. Customer experience (CX) investments are at risk of being thrown down the drain because of security. Banks invest millions in improving CX every year. The short implementation deadline imposed by PSD2 has forced banks down the route of using clunky solutions for multifactor authentication such as SMS one-time passcodes (e.g., in Italy, France, and some UK banks) or other solutions (e.g., QR codes in Germany). As customers will have to go through additional authentication steps more frequently than before, these solutions might meet the letter of the standard but offer suboptimal customer experience journeys. We see some institutions more seriously considering a form of biometric authentication to smooth out some of these bumps — others will follow suit once customers start to become vocal about their unhappiness and demand a more usable solution.
  2. There’s a lack of common technical solutions and API standards for information exchange across Europe. There are several different API standards and specifications being used by banks across Europe, including those of the Berlin Group and Open Banking Implementation Entity in the UK, for example. These standards and specifications are different and in some cases don’t even agree on the same underlying security models for performing authentication with a bank for typical payment flows. The differing regionalized specifications that seek to implement the RTS are themselves a function of differing levels of technology maturity and readiness to implement the open banking model. This significant divergence means cross-country providers must grapple with implementing several different specifications, sometimes even having to do this on an individual country-by-country basis. This is creating unnecessary friction in the ecosystem and adding to cost and compliance burden for banks or driving them to use intermediaries to provide solutions.
  3. PSD2 is unintentionally harming fintech innovation. PSD2 has lofty ambitions of promoting a more open ecosystem and encouraging innovation. Lovely sentiments, for sure, but several elements of the PSD2 security approach will actually harm innovation — for example, the seemingly trivial requirement to reauthenticate a user periodically (every 90 days). Fintechs offering digital money managers or account aggregation services will need to get a user to reauthenticate every one of the accounts they are using within such a service. This will harm the user experience for these applications. It could drive customers back to using the main application provided by each individual bank. Good for banks, bad for the fintech. This is just one example, but unfortunately an own goal has been scored here. Rather than helping fintech innovation, another layer of red tape will slowly constrict it.

It is difficult to argue with the good intentions behind many of the security requirements in the PSD2 directive. Unfortunately, the implementation has been bumpy, leaving some important lessons for other countries looking to emulate the open banking revolution. To find out more and to review more of our findings in detail, our report is available for Forrester customers here.

Forrester will also be hosting a complimentary event on Thursday, June 27 in London examining open banking trends in further detail, including security and CX, core application renewal, and broader PSD2 trends. Space is limited; register today.