News & Insights

Key highlights for banks focusing on PSD2 requirements

The majority of bank developer portals in our OBM consist of EU banks adhering solely to PSD2 requirements (i.e. 76%). More than 250 banks operating in the EU have recently launched their PSD2 developer portal and APIs, consisting of functionalities pertaining to Payment Initiation, Account Information, and Confirmation of Available Funds.

Usually, banks’ PSD2 implementation adheres to one of the major API market initiatives (e.g. Berlin Group with 65%), however, some take a proprietary approach to their API specification (i.e. 16%). While PSD2-banks slightly differ in the scope of the PSD2 functionalities offered (driven by the capabilities in their online customer channels) and the API market initiative standards that they apply, these banks mainly differ between each other in terms of Developer Experience (i.e. tools offered by banks in order to connect and understand the APIs).

Banks adhering solely to PSD2 requirements have not been visualised in the OBM. The OBM visual in figure 1 below includes players that have moved beyond this by expanding past the mandatory PSD2 API scope, and frontrunning banks across the world that released new and previously unseen API functionalities. The latter include, for example, Artificial Intelligence empowered accounts information API (by OP-financial). These banks have taken it upon them to provide (potential) API consumers with better engagement tools.

Most PSD2-banks focus primarily on providing only the necessary technical details of the API Documentation and basic Developer Usability tools (see two of the four core developer portal capabilities of the Open Banking Monitor, elaborated in our previous whitepaper on ‘How the “Masters of Openness” create value’), allowing visitors to test the available API functionalities. However, these banks lack additional developer guidance, showing a developer where they can find the necessary information and how to connect to a particular API. This is why the majority of PSD2-banks score below average when comparing them to banks from around the world with an Open Banking offering beyond PSD2 mandatory APIs.

A large number of PSD2-banks (i.e. 44%) deploy their offering through so-called ‘API Hubs’, which provide a single interface to access all banks using their solution. This means that the Developer Experience for banks that make use of the same API Hub can be considered rather similar. Currently, the top three largest API hubs measured by the number of connected banks are BEC (i.e. 23 banks), Luxhub (i.e. 19 banks), and SIBS API market (i.e. 18 banks).

Although many PSD2-banks have launched their developer portal, only 51% indicate that their production APIs are ready for usage. The remaining banks solely provide a sandbox environment with example (customer) data. This example data is generated by the bank in order to mimic what the actual production API will return as output and allows developers to test a variety of scenarios. Furthermore, access to the sandbox environment ensures that developers can adapt their implementation to fit the bank’s API specifications and test full end-to-end user experience flows. This is why it is interesting that a significant number of PSD2-banks (34%) require a TPP license before developers are allowed to access the sandbox-testing environment, thus prohibiting developers from testing potential use-cases before going through the puzzle of obtaining a PSD2 license.

Key highlights of front running banks in the API economy

Deutsche Bank and Capital One have seen a steady performance throughout the past year and together with BBVA and Nordea now make up for the leaders in Developer Experience. Deutsche Bank provides a well-rounded Developer Portal, tailored to both business and developer minded visitors. Capital One has clear API Documentation providing all of the necessary components that contribute to a solid documentation and, additionally, actively supports community engagement by ensuring the means to contribute and consume community developed tools. Several examples are ‘Hydrograph’, which is a next-generation data integration tool aimed at managing and processing big data, and ‘Hygieia’, a configurable, dashboard to visualise near real-time status of an entire software delivery pipeline).

ERSTE Group maintains a solid position thanks to their comprehensive app management capabilities, which allows organisations to manage their members and assign them with different roles depending on their access rights, all the while additionally providing means for compliance checks and uploading PSD2 certificates. HSBC has recently released a considerable update to their Developer Portal, now delivering a solid Developer Experience with possibilities for API testing and PSD2 APIs for three market API standard initiatives – OBIE, STET, and Berlin Group – something which is not common across other banks.

OCBC and DBS continue to grow their API offering with OCBC, now offering eight different payment methods. Bunq has come a long way, being the third runner up for ‘Functional scope’, a great performance considering their limited product offering but high granularity of API functionalities. This provides developers with access to virtually every option in Bunq’s product portfolio and although it is a small bank, other banks can still learn greatly from this example of what it means to be a truly ‘Open Bank’.

Open Banking: best practices to shape your API and Developer Portal roadmap

To support banks who are starting with opening-up or those that are seeking to take the next step in their Open Banking journey, we have identified three key takeaways that could help create focus in their API and developer portal roadmap.

1. Comprehensible APIs for a broad spectrum of visitors (i.e. business and tech)
While Developer Portals were initially designed solely for a developer to understand the technical specifications and how to connect to a particular API, an increasing number of banks are now catering for a wider public on their Developer Portals. The visual below shows four elements that can make your developer portal more business-focused.

High-level descriptions, API features, data exposed and potential use cases are all focused on promoting the value the bank APIs provide. This is to ensure that it spikes the interest of the more business-minded visitors as well as the technical developers looking for new and interesting ideas.

2. Match the stages of developer interaction to gradual developer onboarding
Six stages can be distinguished in developer interaction and developer onboarding. These stages are depicted in the visual below.

Banks need to carefully consider the design of these six stages to ensure a seamless developer experience. Visitors of a Developer Portal first have to explore and see what they can access or use before starting any form of commitment. This is why banks should allow a visitor to quickly browse through the available functionalities and promote the available APIs. Once the visitor has seen enough potential in a particular API, it is time to experiment. To support this, the bank should provide a sandbox environment, which is easily accessible and handles an ample amount of test data and availability of mock credentials. This will allow developers to understand the user experience flows and identify potential blocking issues for their application. Only once a visitor has requested access to go-live, the bank should connect and start its due diligence and the identification process of the requesting party.

3. Support Community Development
Community development consists of two related activities in which banks create traction and then promote engagement, and is depicted in the visual below

A part of Community Development is aimed at ‘creating traction’ around the bank’s Open Banking offering. This means actively advertising and promoting activities such as Open Banking events, hackathons or updates to the portal, newsletters, blogs or other channels. However, perhaps equally important in order to maintain traction is ’promoting engagement’. Examples of banks that do this well are Capital One – with their ‘Open source first approach’, in which they actively use, contribute, and manage open source software projects and allow the community to contribute as well. Starling Bank is another example, by creating a marketplace exposing all the financial products developed by third parties that consume Starling’s APIs. This helps new developers to get started on their own projects by using ready-made pieces, triggers visitors with potential ideas and use cases, and shows the bank’s customers what added (banking) functionalities are out there which they can use and experience.

Closing statement

Open Banking is heading towards a state in which banks aim to involve the community as much as possible, allowing them to contribute by providing the necessary tools and promoting their engagement. This creates an immortal state in which the bank profits from community-created content that, in turn, sparks others with new and innovative ideas.

Reach out to discuss the opportunities if you are starting your Open Banking transformation and/or when you are seeking to take the next step in your Open Banking journey. Stay tuned for more updates of the INNOPAY Open Banking Monitor.