Norine Product Manager

Connecting PSD2 APIs across Europe: our 3 key findings

The main goal of the second EU Payment Services Directive (“PSD2”) issued in 2016 is to increase openness and competition to foster the development of innovative financial services across the European Union. Together with its numerous implementation rulebooks, the PSD2 sought to incentivize banks to build unified interfaces for third-parties to access banking data (accounts, transactions) and initiate bank-to-bank direct payments – regardless of the Member States concerned.

Two years after the first steps into PSD2, and following its recent expansion in Belgium, Italy, Spain and the UK, Budget Insight has gained a great deal of experience on how close – or how far – the reality is from the initial PSD2 promise. In this post, Norine, our Product Manager, walks you through our 3 key findings. 

 

1/ PSD2 APIs data quality has decreased compared to scrapping and that did not help going abroad 

 

Our first experience with PSD2 was to migrate our existing AIS and PIS services to compliant channels (APIs and fallbacks). As a historic aggregator of banking data (or Third Party Provider – “TPP” in PSD2 parlance), with close relations to our local regulators in France, Belgium and Luxembourg, we were in ideal conditions to assess how good the first bank APIs were. 

 

It did not take us too long to reach our first conclusion: because banks had to adapt in record time their internal systems, and because they tried to map their internal data model to a standard one (STET, Berlin Group…), there was a lot of data missing in the APIs. That effectively made very difficult the provision of a unified service for users of different banks- and even more difficult for users of banks located in different Member States. Besides, managing varying levels of data quality is always tricky, whether from a technical or an operational standpoint. 

 

So how did we crack this problem? In addition to having a very flexible data model, we maintained a trustworthy relationship with local banks and regulators and provided systematic and actionable feedbacks on a regular basis. This allowed us to build a healthy and exacting dialogue with ASPSPs, and support them in improving their APIs. 

 

Also, having tech-friendly compliance and compliance-friendly tech teammates was a must. Fortunately, we have exceptional staff here at Budget Insight. Did you know that France, our Head of Compliance and legal, knows everything about APIs authentication protocols? And that Laetitia, product manager and Bertrand, CPO, have law degrees?  

 

2/ Pre-existing traffic is a must. Do you have pre-existing traffic when you launch a new country? (spoiler: you don’t)

 

When testing APIs, by relying on banks’ sandbox environments or by our own means, we were able to detect the most significant defects – but that’s not enough to provide a level of service that is good enough for our clients. Corner cases are numerous: how can we assess the bank’s API’s behaviour for all our end-users’ cases? Well, we needed actual end users to synchronize their data from this new channel, so we could monitor and see what was really happening. And, to do it well, we needed a lot of those users, so we could catch all possible scenarios. 

 

In fact, each time we developed the PSD2/API source of one of our existing connectors, we had to switch a small part of our client’s existing user base to the new API source (a release method called canary testing). The consequence of that is bad, to say the least: while we had already detected the most significant issues, the hard-earned users of our customers had to crash-test the rest of the banks’ APIs. For a customer-obsessed product company like us, this is as close as you can get to a nightmare.  

 

Now, back to the European issue. If the only way to get a well-functioning bank API is to rely on pre-existing traffic – an existing volume of end-user data synchronisations – that is quite a barrier to expanding into a new EU country where you have, well … no pre-existing traffic! If you’re lucky, maybe a local TPP would have already helped the banks improving their APIs. And if the use-cases of your client base differ from those of the other TPP, some areas of the local banks’ APIs may not have been even tested. Just think about PFM apps, requiring data from individual accounts, vs. accounting softwares, requiring data from business accounts. 

 

So how did we crack this problem? We relied on our long-lasting relationships with some of our amazing clients, who helped us building traffic in key countries where they expanded. Bit by bit, we made things work. I cannot stress how grateful we all are for their patience and commitment. We do love our clients.

 

3/ Varying NCA interpretations is bad, but lenient interpretation is worse.  

 

Fortunately, in the case we would face issues with APIs, regulators had provided us with a scrapping fallback mechanism: until the bank’s API was deemed complete by actors like us (TPPs) and validated by the regulator, banks had to maintain a shadow web interface, so we could use it as a secure and PSD2-compliant data source.

 

Unfortunately, there is no single authority when it comes to technical implementation of APIs. The directive’s implementation is supervised by each national regulator (called “National Competent Authorities”). In France, the ACPR; in Italy, the Bank of Italy, in Germany; the BaFin, etc. Each regulator’s interpretation of a bank’s API compliance with PSD2 may vary. For example, in Italy, all the banks’ APIs have been considered valid. When we started developing connectors to Italian banks, though, we realized that many APIs had important issues which, under the French regulator, would have prevented the API from being validated. And because those APIs are validated, Italian banks are no longer obliged to provide a scrapping fallback that would have allowed TPPs to mitigate the APIs’ data shortcomings.

 

So how did we crack this problem? Thanks to our experience with the French ecosystem (Banks, Fintech, TPPs and regulator) and how we gradually helped the banks and mediated between the different interests/constraints, we were able to make Fintech’s and banks benefiting from both PSD2 API and direct, non-PSD2 access to data.    

 

A couple of key take-aways. 

 

Reading the previous paragraphs, you may well think that the PSD2 is a broken promise. That is not our opinion. The PSD2 remains a formidable tool for openness, innovation, financial inclusion and European integration, and despite the difficulties, our clients’ continuous success proves it. Having said that, it is clear that we have only scratched the surface of what’s possible with Open Banking. Who knows what the market will look like in 2, 3 or 5 years, when the APIs will be fully complete. Whatever happens, we’ll continue to do what we do best: provide our clients with the most important breadth of data, the best data quality and the most stable API there is in order to fuel and foster their innovative products and services.