In 6 months PSD2 APIs will be reality: Developers are our hope now!

six months until RTS must be appliedIt is only six (!) months until 14 September 2019, the day the Regulatory Technical Standards (RTS) of the European Banking Authority (EBA) on Strong Customer Authentication (SCA) and communication, i.e. the communication between banks and third party providers under the PSD2, must be applied. One focus of the ongoing discussions in the market is the PSD2 interfaces to be expected by then. In February I was invited to participate with other market representatives in a BaFin workshop discussing the status quo. My main conclusion: We now have to shift the last open issues from the conference table into the heads of our developers.

What happens or should happen on 14 March 2019

If a bank wishes to be exempted from offering any fallback access as of 14 September 2019, then in accordance with the RTS deadlines, the interface documentation must be published today and the test environment must be provided for functional tests. Unfortunately, for us as a third party provider, it is not possible to look this up in an EU-wide EBA register. Each bank is going to do this individually – more or less innovatively – on its website. The first interfaces have been live since the beginning of 2019 and we have already been asked to test them. The mass of banks will follow now.

Talking helps, but only actions will save us

The exchange between banks and third party providers is still difficult for historical reasons. Although it seems like, the market has been mixed. Since 2016, banks have gradually been offering payment initiation and account information services (PIS/AIS), even relying upon the technical expertise of traditional third party providers. At the end of 2018, the pan-European market standard initiative NextGenPSD2 (Berlin Group) opened itself to the broad experience of third party providers. Since then, figo has also been active on the initiative’s advisory board.

Unfortunately, no official reference implementation for NextGenPSD2 is published today that would have made it possible to centralise general functional tests. At the BaFin workshop mentioned above, the initiative presented the successful reach of its API standard. The German market leader banks reported to follow the standard, but at the same time they also shared the implementation status of their individual sandboxes, test plans and go-live plans. A NextGenPSD2 side-project’s framework, with which integration tests can be standardised or automated, is to support third party providers in the diverse API testing world.

Traditional third party providers will be very goal-oriented with regard to the tests and will avoid double efforts if sandboxes are offered rather as means of compliance and still have little to do with the real interfaces. From 14 June 2019, the latter can be expected for the go-live or initial three-month market probation phase. Banks, on the other hand, must prove that their interface has been tested to the satisfaction of third party providers in order to be exempted from the fallback.

I was invited by BaFin to explain how figo, as a third party provider, assesses the transition phase. We know from experience what difference it makes to connect a good or bad third party API, what it means to continuously operate a data integration and make it usable for our partners – and last but not least how our own availability and performance is impacted by a wrong usage of our API. As the first regulated PIS/AIS provider in Germany, we are also aware of what it means to operate IT systems in compliance with BaFin.  

Therefore, it is obvious how important the exchange between banks and third party providers is. And the uncertainty that drives us all with a view to the next six months should have an additional connecting effect. Banks are worried about whether they are able to meet the API requirements in terms of content and deadlines, while third party providers fear the quality and inconsistencies of the APIs that must be used.

The coming months will be complex – even under the most ideal conditions

Inconsistent APIs or their individual operation mean unnecessary additional costs for all of us – for banks, third party providers and the BaFin, which needs to assess their PSD2 compliance. IT budgets and EBA resources adequately prepared for the PSD2 could have saved the market current and future pain. With regard to Supervisory Tech, we urgently need to catch up in Europe, e.g. through a centralised data collection at the regulator for stress testing and monitoring the PSD2 APIs.

Why, despite all our efforts, did the standard initiatives not succeed in preventing   inconsistencies in the construction of the APIs? Wasn’t that their stated goal? Well, first of all, it’s because there are at least six initiatives in Europe. And if the pan-European NextGenPSD2 now promises not to contradict other national standards – with good intentions, it unfortunately cannibalises its goal at the same time.

The result is that third party providers continue to face immense complexity, even if all EU banks were to comply with the voluntary NextGenPSD2. If one deals with the NextGenPSD2 specification, it becomes clear that in future many optional specifics will have to be managed via the bank’s interface, because each individual bank must decide between:

  • six possible SCA procedures (embedded, redirect, decoupled, mixed forms)
  • three types of consent management (global, bank offered, detailed)
  • bank- or user-specific 2nd factors (mTAN, flicker Tan, QRCode, etc.)
  • risk-based scopes of the 2-factor exemptions.

Implementation at the individual bank level will not only have an immense impact on the backends of third party providers, but also on the frontends of future payment service offerings. Every possible SCA scenario must be covered by different user flows. After all, the complexity also reaches the user. If one only thinks this through for multibanking solutions, the inconsistencies described could easily endanger the success of the multibanking feature. The digital departments of banks that operate PIS/AIS features are also likely to become gradually aware of this.

And with all these hurdles we still haven’t grasped reality yet, because until now I have only explained the new Open Banking future of payment accounts. Many banking products, including established ones, also depend on access to brokerage accounts, credit card or savings accounts. Due to the PSD2 changes, there are fears that access to these will be restricted as of September. In Bonn, representatives of the German banking industry negated this for registered web services, at least with regard to HBCI/FinTS.

Today, however, HBCI access also offers payment account functions (foreign payment transactions, direct debits, collective transfers) which are not necessarily included in online banking and could therefore actually be omitted as of September. This means that third party providers must now show some trust. The banks’ market vision, which has meanwhile been sharpened by their own products, will hopefully lead to PSD2 interfaces conceived in this way.

Will supervisory authorities help us?

In parallel to the test phase and go-live phase, last minute clarifications on the RTS are expected from the EBA, be it from the EBA Working Group or the EBA Q&A. Unfortunately, the EBA’s actions sometimes seem too distant from the European market. Despite Brexit and its own market failure, the UK OpenBanking Standard still has a great influence on the authority. For example, UK representatives constitute one sixth of the EBA Working Group. Time will tell whether this leads to decisions that strengthen the EU Digital Single Market.

BaFin, on the other hand, is trying to support the market to the best of its ability with its resources and within the narrow national PSD2 limitations. The phase of the API compliance checks will show whether the German authority can meet the challenges. Just one example: If a mandatory redirect approach is offered for SCA, the German Authority plans to even check the bank’s frontend texts to assess whether third party providers are being hampered.

May the force be with the growing PSD2 developer community

However, instead of just hoping for help from EBA and BaFin, we should finally connect the most important people in this market directly with each other. In particular, our product owners and developers must be able to implement Open Banking products from the backend to the user front end in a PSD2-compliant and innovative way. A direct exchange in the GitHub/GitLab and Slack channels between the developer who maintains a specific bank API and the third party developer would be a much needed breakthrough for the EU Open Banking market.

In my daily work with smart minds, I have often seen how we conference RTS theoreticians argue far too often about problems, while the Dev or the DevOps team can already offer a smart technical trade-off solution. But also important: An exchange from a banking market point of view must not be limited to outsourcing the technical solution from political PSD2 crutches to its API or frontend service provider.

If in the coming months, PSD2 API web presences by banks are designed to be product owner and developer friendly, including usual Dev Tool offers and a visible availability of the API developers, we will have taken the first important step. Meanwhile I dream of a pan-European Open Banking Dev Convention as a further development of the Bankathon. After all, we think big now.