The first bite of Open Banking leaves a bitter-sweet aftertaste

After recently announcing the program of expanding our PSD2 API integrations, with already 250+ connected APIs across Europe, we thought it might be useful to share the accumulated experience – good and bad. We believe that this is not just our company’s journey, but of each and every TPP that aims to provide stable, highly secure, and valuable Open Banking services. Luckily, up till now, we found banks to be receptive to our feedback. And hopefully, API vendors and banks that are still building the PSD2 interfaces will take into account our comments and do their best at delivering better user-experience and reliable communication interfaces for TPPs. 

As Salt Edge is specialized in both consuming and building PSD2 compliant APIs, this experience helped us understand better which are the main pain points during TPP integrations – and we have already successfully applied this knowledge in building APIs for banks across Europe.

We encountered various issues while integrating with bank channels, some of them adding unnecessary friction while others blocking us entirely. Very few banks have built their sandbox environments in ways that are compliant with RTS and PSD2 specifications and that allowed us to successfully test connections and try out AIS and PIS flows. The situation varies from country to country, with the UK leading the way. While Open Banking Standard in the UK set explicit requirements for bank interfaces, in continental Europe – the emerged API standards (NextGen, STET, etc.) leave space for adaptations and interpretations within the same standard. This led banks to implementing custom versions of APIs, which as a result, makes TPPs waste their limited time on analyzing APIs and integrating them one by one. 

Based on several factors like the ease of integration, the possibility to test various scenarios, and overall compliance with the RTS requirements, we divided the integrated bank APIs in 3 groups. 

10% – Great APIs

Integrating with these banks was a blast: clear documentation, seamless flows, support of dynamic registration, and fast communication. And they deserve to be known: BBVA, ERSTE Group, UK CMA9, Fineco, Revolut and others.

70% – Inhabitable APIs

Onboarding with these banks was quite painful and it took up to 2 months or more. The registration and communication with them were cumbersome, presenting unnecessary delay or friction during the integration and bad customer journey. We present only few of endless difficulties that we encountered in this grey area. 

Several use cases that we experienced are:

1. The APIs of several banks were in compliance only partially with the declared API standard (e.g. NextGen). For example, there were mismatches in parameter location, formats of data, field types, etc. and these differences are not documented anywhere. Only after a lengthy discussion with the bank representative, we were able to identify these mismatches. Besides, the documentation defines the end points but does not define the parameters that should be sent to these end points.  
2. In order to integrate with their sandboxes, some banks requested additional unique verifications like presenting notarized documents (even though we had a valid Test eIDAS certificate), conducting several phone calls, the possession of a local country phone number for communication or receiving sms confirmations. Some banks simply notified us that the registration had been completed and that they had to manually verify our identity. It took up to 2 weeks to get a reply from them to just start the onboarding.
3. Verifications that are outside compliance with PSD2. Even though we had an active passporting rule in a specific country, some banks still required a formal letter of registration with their national competent authority (NCA). 
4. For the purpose of SCA testing, the second factor of authentication (e.g. one-time password) was delivered via various inaccessible channels. The most ridiculous ways we encountered were the requirement to call the bank and inform them about the intention to test the SCA flow and only after that the bank would send the authorization code via email or chat. With another bank, we had to access their internal infrastructure (possible only by using VPN) in order to access the second factor of authentication. 
5. The Test User credentials to be used for accessing the sandbox are not present neither on the website nor in the documentation. We had to contact the banks via email or phone to get access to this data. 
6. Useless sandboxes due to limited testing cases. Some sandboxes support only a set of predefined requests and parameters, which, in result, give the same mocked response to any request. There is no possibility for “functional testing of” (Art. 30 (5) from RTS). 
7. Some banks require separate consents for accessing different types of data (account information, current balance, transaction history, etc.) from the same account, for data aggregation purposes. Each consent was accompanied by the strong customer authentication. Going 3 times or more through the same strong customer authentication steps in order to connect a single PSU account for account information purposes is a huge barrier in the user-experience.
8. While account information flows eventually worked, payment initiation requests were not functional. Payment initiation testing should be simpler than account information testing as it basically includes generation of a payment order and receiving the notification about the payment execution from the bank, but this flow ended each time in generic errors (‘something went wrong’). Even after informing the bank about these constant errors, we did not get reasonable technical support.

20% – Blockade API 

Surprisingly, there are banks that have published press releases or designed entire landing pages about having a PSD2 sandbox and documentation but the provided links lead to an error page. 

Other banks had their onboarding forms blocked for registration. Filling in the required fields results in failing validation with no comprehensive explanation. 

Some banks do not support the TPP identification with eIDAS certificate (neither test nor production certificate). Two banks actually stated that they accept only the eIDAS certificates issued by a specific QTSP, which clearly represents a great obstacle for integration and TPP testing.

While going through such broken bank integration journeys, it is hard to take seriously the September deadline and the possibility to offer innovative payment services in such conditions. Salt Edge has big concerns that some of the banks with faulty APIs could eventually get exempted from providing a fall back channel from their NCA. This could lead to unstable services for the end-customers and thus transforming open banking into an unrealized idea. We encourage all TPPs and banks that plan to act as TPPs to speak up about their experience, be open with banks during the integration and claim a well-functioning environment for building a business. It is gladdening to see that some banks are open to listen and adjust their interfaces. With several banks, we were the first or through the first 3 TPPs to test their interfaces. We learned that keeping a collaborative attitude from both sides helped us go through the integration smoother. There is a strong need for cooperation between banks and TPPs.

About Salt Edge

Salt Edge is a global fintech company offering a range of cutting-edge solutions to financial institutions, banks, finapps, and other fintech companies. The company is registered as Account Information Service Provider by the UK’s FCA, under PSD2. Among its most popular services are financial data aggregation API, open banking and PSD2 solutions, white label retail banking, and data enrichment. ISO 27001 certified, the company employs the highest international security measures to ensure stable and reliable interoperability channels between financial institutions and their users. Connected to 3400+ financial institutions in 66 countries, Salt Edge brings comprehensive financial data at the fingertips of hundreds of thousands of end-users on a daily basis.

More information: www.saltedge.com

Phone number: +1-437-886-3969

E-mail: press@saltedge.com