September 14 has been repeated over and over again since the last year as a mantra. "New era of banking", "the turning point for the financial sector"- these terms appeared as descriptions of open banking, announcing a change in the financial ecosystem. The fact is that for two months before the deadline, the APIs are far from perfect, and the provision of services based on them may not be possible.
Since mid-March, Kontomatik as a Third Party Provider has been testing connections with Sandboxes, and from the end of May with live environments. Four months of testing is a good time to stop and gather some facts about the condition of the banking APIs in Europe.
Is happy ending possible? Yes! The answer may be surprising, but there are banking APIs which meet all the basic requirements of the ideal scenario. Integration with API and 14 banks in a few days is proof that this work can be done well.
How was such fast connection possible? Test environment and live environment were well prepared ... as simple as that. Starting from scratch: clear and complete documentation describing process step by step. Good communication. No problems with certificates. The developer portal with easy access, where you can generate API keys and check sample integration scenarios is an ecosystem that makes work much more comfortable. And finally - the live environment has the same mechanism as a Sandbox, so the whole connection is about a few steps.
A few days as the time needed to create a test application is a scenario that we would like to accept as a standard.
After weeks of trying to connect with APIs throughout the European Union, reporting bugs, testing various scenarios, we must conclude that the case of such a quick connection is just an exception proves the rule. Connection with API is a painful and long-lasting process, and most of the APIs are in poor condition.
First attempts to connect to the banking APIs s revealed several problems. They appear both - in the technical layer (certificate errors, internal errors in banks stopping the process) as well as in the business logic layer. While technical errors can be quickly and efficiently fixed, it is worse with errors in the business logic layer. Developer portal with easy access, where you can generate API keys and check sample integration scenarios is an ecosystem that makes work much more comfortable
But let's start from the beginning. 14th of March was a deadline to launch test environments. Most banks have kept this deadline. Theoretically. The test environment has a specific meaning in system engineering - it should be complete and allow test scenarios. Unfortunately, reality has painfully verified this definition.
No direct access - Sandboxes not available to the public, websites informing that Sandboxes are available, but after granting access in an unspecified time or in extreme cases - no Sanboxes at all - these are a few scenarios that we've met during the first attempts to check availability.
Defective, clumsy and hard to understand documentation - lack of basic data (e.g., lack of full URLs to perform the request) make it impossible to work with the API.
Problems with eIDAS certificates - some banks imposed the requirement of having certificates to connect with the test environment, and then... had a number of problems with their processing.
Implementation differences between banks there are few standards in Europe but using them is not obligatory and this means that every banking API requires a separate connection, communication and ... a large amount of time.
Lack of business continuity, incomplete flow, no possibility to test the full path of the user, lack of verification e-mails, recurring errors are a continuation of obstacles that have been encountered during the work with test environments.
But we can assume that the effort to work with Sandboxes will pay off. In the end, thanks to the developed and tested connection, using the live environment should be trouble-free and can be reduced to a few simple steps. Unfortunately, test environments turn out to be ... different than live environments. No redirects, no real choice of the account, the view of illegible, incomprehensible windows instead of running software, pages with error images (not error codes) - these are just examples of differences that we encountered during attempts to connect to the bank's APIs.
Next to the fact that we’ve tested Sandbox and found errors, we also know that banks are trying to make their APIs better. Providing developer portals with integration examples and a step-by-step explanation of what to do, quick response of support channels, help beyond what is required is just a handful of evidence that most banks are concerned about API quality. Unfortunately, the clock counts downtime without mercy for errors and shortcomings.
What if the API will not be available or the technical problems will occur? Fallback mechanism described in PSD2 directive will come to the rescue. Fallback allows verified TPP direct access to the customer's account via online banking. This solution may keep business up however, condition of this approach will depend on TPP and banks to be prepared to this mechniasm.
And while cooperation between banks and third parties gives hope for a happy ending, unfortunately, there is one unbeatable factor - the time. Assessing the status of currently available production APIs the possibility of providing services via this channel may not be possible. And disruptions in the provision of services that may irreversibly undermine consumer confidence of the whole idea of open banking. That is why it is so important to prepare for alternative scenarios and, especially, to be ready to use fallback mechanism.