Open banking wave is coming, but are banking APIs ready for fintech?
On 14 September 2019, the Second Payments Directive (PSD2) went into full effect all over Europe. It made it possible for a third-party to connect to banking APIs to obtain history of clients’ accounts, make a payment or check the availability of funds. In theory, it would cause a new generation of banking apps that will bring new quality to banking clients. However, the development of new solutions is not as fast as many would like it to be.
The UK, with its Open Banking Directive that came into force in January 2018, is far more evolved than the rest of Europe. Therefore, many open banking solutions (like Revolut’s account aggregation) are only available in the UK.
Why is it hard to get into open banking as a new player?
Even the most innovative banking players, like KBC or ING are locally connected with four to five different banking partners at most.
Why is it hard to get into open banking as a new player? BanqUP, a Belgium-based platform that works similarly to what Plaid is doing for the US Market, and already connected to over 50 banks from eight countries in their aggregator platform, has some interesting views on this subject.
Lukasz Chmielewski, banqUP’s chief technology officer (CTO) says that the APIs provided by banks are pretty different across different API standards, but not only that, as he states: “Each bank has a different approach to how it complies with PSD2 directive. There are a number of pain-points that we observed across very different national and multinational API standards and their implementations in Europe.”
Too little sand in the sandboxes
Very often sandbox/test APIs provided by banks significantly differ from the final API. “We have encountered sandboxes that, by design, offer around 10% of the functionalities of the production API. This will make it easier for Third-party providers (TPPs), not sure in which way,” mentions Chmielewski.
Why is this a problem? Sandbox should be a tool for a TPP company to test their solution to later seamlessly connect to access real data. It should also allow any entity without a TPP licence to build its solution. “Before we got our TPP licence in December, we basically had no idea how accurate our connector is. Only after deployment to our TPP client we have learnt about the scale of differences. And most TPP service providers are still in this inconvenient situation,” says banqUP’s CTO.
Sandbox stability may also be an issue. It seems logical that the sandbox environment may be less stable than the production one, but the banks are obliged to inform their partners about any changes to a production API that may cause failure to connected applications (usually a few months prior to their release) but not to the sandbox.
However, some basic level of reliability is required to make sandbox useful. “When it comes to sandbox change reports, we have had cases where the changes have been communicated to us 20 minutes before their release to the sandbox automatic tests, depending on sandbox APIs, almost never work for a full set of banks. We had to design the process to automatically disable/enable sandbox tests based on health checks, as instabilities occur very often,” explains Piotr Szyperski, banqUP’s lead developer.
Non-standard standards
Another issue TPPs face is the differences within a single API standard. Mostly stemming from different approaches to the guidelines. There are banks that only support most basic scenarios, ignoring the fact that according to their API standard they should support much more. For example, some of them allow only standard payment and neither recurring payment nor scheduled ones are supported.
These seem minor issues but often whole business cases can be (or are being) built around those missing features. “Some banks follow standard to the letter, some decide to add additional functionalities or features. Others decide to ignore some elements of the standard, claiming that they are not useful,” says banqUP’s lead developer.
“Standards are usually treated by banks as guidelines or inspiration only. Even if they are strictly followed, they still leave a lot of room for interpretation. Multiple optional fields, a lot of alternative paths and missing elements that most REST APIs possess. All of these make the banking APIs far from perfect,” he adds. “However, there are standards with more precise requirements. One good example is the Polish API. It is precise enough to result in very similar implementations of both AIS and PIS services across the whole country.”
Growing pains
“From our perspective it seems that both people responsible for PSD2 standards and those implementing them have been focused either on maximising security of the API or minimising the effort of implementation, having internal banking architecture in mind,” says Chmielewski. “Moreover, it seems that in some cases, after the bank has addressed the minimum regulatory requirements regarding PSD2, they invest much less of their resources and focus on improving the quality of the API, especially sandbox. It may be somehow understandable, but it may still slow down changes related to open banking,” he adds.
On the bright side, most banks approach support very seriously. They have appointed contact personnel to handle API reports or even set up small departments. There are only rare cases where the answers are not helpful or take longer than one day on average.
“Many of the issues we have described stem from the fact that we are often one of the first entities that connect to a given banking API. We are observing steady increase in stability and usability of the APIs, even though it is not necessarily rapid,” says Chmielewski.
“Reactions from banks to our feedback are also usually very constructive and positive. We believe open banking, with a proper set of tools simplifying connectivity, might soon become a game changer it was hoped to be,” adds banqUP’s CTO.
