Over the past several months I have signed up and written code for a number of bank APIs.

In future posts I will review specific portals in more detail using the criteria I defined previously – Creating An Awesome Developer Experience For Open Banking.

For now, I will provide my general observations on my experience using the developer portals and testing sandboxes.

Average On Boarding Experiences

Of the 250+ banks in Europe, less than 10% currently have a publicly available developer portal or an “our API is coming” landing page.

On boarding processes are similar across all available portals with common registration and validation steps required.

Once registered, the developer typically receives an app and secret key used for subsequent OAUTH exchanges.

Most have a ‘one developer, one app’ restriction, but BBVA stands out from the crowd and offers the ability to register multiple applications per organisation. This is useful when you need to build several demos/apps.

Reasonable Documentation

Most portals have reasonable documentation to get started, provide sample code and have the ability to test out the APIs.

Some portals, BBVA once again (I promise I don’t work for them), go beyond what is expected and provide examples for different languages. However, with a mixture of English and Spanish language the documentation can be confusing at times.

Disappointing Functionality

In the main, portals provide read only APIs for personal customers, account and transaction history.

Some portals provide, branch and ATM locations, product info and allow payments to be made.

BBVA go well beyond the average and provide additional APIs for loans, business accounts, cards and notifications.

Inconsistent API Definitions and Data Models

It is striking the inconsistencies in API definitions and usage across portals.

Some banks make it hard to link foreign keys between customers and their accounts with multiple API calls and complicated data navigation required.

The UK data models aren’t European friendly, although in fairness the Open Banking Implementation Entity (OBIE) is addressing that.

The upshot is that, with the exception of the UK thanks to OBIE, developers are faced with writing code specifically for each bank to handle interface and data model differences.

This isn’t going to be much fun when there are 250+ APIs out there, so Europe is in desperate need of some joined up thinking.

Different OAUTH Approaches

3 Legged OAUTH Flow

3 Legged OAUTH Flow

Some banks have taken different approaches to OAUTH exchanges, for example BBVA have taken a ‘3 legged’ approach and others simply provide hard coded tokens as they are still implementing the standard.

Once again this inconsistency makes it hard for developers, as they will be forced to write different code for different implementations.

Inadequate Sandbox and Test Data

In short, the current sandboxes and test data are as much use as the proverbial ashtray on a motorbike.

Test data limitations are the biggest challenges.

Some banks provide the same read only data sets to all users and effectively return a hard coded response. Others have gone beyond this and automatically create customer accounts and data on a per application basis.

However, few appear to provide effective write/update capabilities. For example, it would be great to use the same account to make payments and see the balances being updated and transactions generated.

For more complicated aggregation and orchestration scenarios, I was forced to develop my own sandbox and test data automation using the UK OBIE standard. This has provided me total flexibility to work outside of the bank interfaces and data models whilst I develop my apps.

Promising Start, But More Work Required

It is disappointing that more than 90% of European banks don’t yet have a fully functional developer portal.

Those that are available are mainly limited by the functionality they provide, weak sandboxes and data management.

A lack of a coordinated approach across Europe has resulted in API interface and data model differences and different approaches to OAUTH handling.

Developers wishing to test more advanced aggregation, orchestration scenarios with the APIs have the choice of either waiting for things to improve or writing their own versions of sandboxes.

However, over the past 10 months things have improved enormously and hopefully during 2018 I can paint a much better picture.

%d bloggers like this: