After recently announcing their program of expanding the PSD2 API integrations, with already 250+ connected APIs across Europe, Salt Edge is sharing the accumulated experience – good and bad. They believe that this is not just the 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, they have found banks to be receptive to their feedback. And hopefully, API vendors and banks that are still building the PSD2 interfaces will take into account their comments and do their best at delivering better user-experience and reliable communication interfaces for TPPs.
As they are 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 Salt Edge has already successfully applied this knowledge in building APIs for banks across Europe.
They 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, the company 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. Salt Edge present only few of endless difficulties that we encountered in this grey area.
Several use cases that Salt Edge experienced are:
- 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, the company 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.
- 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 them that the registration had been completed and that they had to manually verify their identity. It took up to 2 weeks to get a reply from them to just start the onboarding.
- Verifications that are outside compliance with PSD2. Even though Salt Edge had an active passporting rule in a specific country, some banks still required a formal letter of registration with their national competent authority (NCA).
- 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 Salt Edge 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.
- The Test User credentials to be used for accessing the sandbox are not present neither on the website nor in the documentation. The company had to contact the banks via email or phone to get access to this data.
- 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).
- 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.
- 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, they 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. The company 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. The company encourages 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, they were the first or through the first 3 TPPs to test their interfaces. The company 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.