The (sorry) state of PSD2 APIs in Hungary

After making the PSD2 APIs available for the public, let’s check how far the banks went with opening up to TPPs.

As probably everybody knows, PSD2 became effective on September 14 in Hungary too. It didn’t cause much of a turmoil on the customer front since most of the relevant SCA (Strong Customer Authentication) features were already in place for years. That can’t be said from the part of the fin-tech companies who eagerly awaited the opening of the account information and transactional channels. Because of my position (IT consultant) and personal interests, I’m one of them too.

There is/was certainly heightened anticipation on how PSD2 enables all the fin-tech startups to start to develop all the functionalities we crave to have as customers, but our banks failed (for various reasons) to deliver. We couldn’t be more wrong. I try to explain my point of view, after checking out all the 28 participants as a normal fin-tech would do. Here’s a summary on neat chart:

A few words on my method: I selected all the banks from the central banks’ bank list, selected the ones with distinct BIC codes, filtered for the banks and checked each ones’ website/portal for information.

Update: I’ve got mentions, that some of the irrelevant banking participants distort the picture. So I’ve designed an other view to show only those banks that we know for sure they should have PSD2 APIs available. Also, merged banks are filtered out.

Let’s dive into the details.

Legal compliance

As expected, the overwhelming majority of the banks pass this test. Except for a few small banks, everybody put up information on how to get started with developing, and also, their endpoints for the developer portals can be found. Usually, the customer portals have a distinct section “for API developers”, and also, portal search guides to the articles.

There were few cases, where no information could be found at all, but I’m not sure that each of those financial institutions fall under the jurisdiction of the PSD2 requirements. Also, there were 2 cases where the only information available was “send us an email and we’ll reply with relevant information”. Errr, no, thank you.

Interfaces

Let’s talk about the standards. The PSD2 requires to implement a widely accepted standard for providing APIs to TPPs (Third Party Providers). There are many standards to choose from, but nor the European Parliament, nor the European Banking Authority defined what that standard should be. Some of the countries’ central banks defined a “national API”, but Hungary’s isn’t one of them, so it’s the “wild west” for us.

Remarkably, on the surface, there’s not so much fragmentation, as one would expect. This is due to the fact, that the boxed solutions that were available, already settled for one standard. There are three approaches:

• Berlin Group-based APIs: one large portion has settled with the Berlin Group, either because it is a group solution, or the corporate channel’s implementation offered it as standard.
• Open Banking-based APIs: another large portion settled with another boxed solution. It isn’t mentioned everywhere, but the developer portals are strikingly similar, with the same developer registrations processes. More on that a bit later.
• Custom APIs: one large bank decided to go with its API — which is also it’s group’s standard, and there are ones I couldn’t identify because there’s no public information on them.

There are certain peculiarities in the APIs: there are banks that offer two APIs, or two endpoints — one for accessing corporate / SME customers and a different one for retail customers. This will be a pain to develop for.

TPP friendliness

If I examine the support of developing/connecting to the bank and to get to the market fast, there are two types of banks:

• Supportive: they usually use a group-solution, where all the interfaces and API documentations are available to download, examine, generate code, etc, with all the right examples and documentation.
• Restrictive: the interface definitions can only be accessed after a registration where there’s a necessary step to upload your AISP/PISP certificate (side note: in Hungary, there are only 2 certified TPPs). It’s really hard to state anything about API quality in these cases, and it doesn’t help when you try to build a business case, which requires months of preparation with the Central Bank for a certificate to be able to check whether half of the bank sector’s APIs are usable or not.

APIs in the wild

There’s also the case of the APIs’ real-life usage since the devil usually lies in the details.

Unfortunately, there’s very little to tell anything about the APIs in general, since there’s no way for me to test them in live environments. I have to resort to second-hand information: there’s a case where one of the big 5 banks built a multi-bank application, and in the current timeframe, could only provide information from one other bank. And it’s not because the developers didn’t try.

It’s also telling (when browsing the developer portals) to continuously bump into messages like “currently our APIs don’t work”.

Summary

To sum it up short: it’s not easy to find comprehensive API information, even harder to find a working API. Getting up-to-speed with development which works in every Hungarian bank is nearly impossible for the wanna-be TPPs.

Our dreams of pouring innovative ideas into startups and propel them to new heights are shattered.