Blog article
See all stories »

Open Banking APIs: Are They As Useful As An Ashtray On A Motorbike?

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

Below are my general observations with 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.

Additionally, 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

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 DataIn 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 with bank sandboxes. 

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. 

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.

Open Banking Developers Europe Linked In Group

To help unite the Open Banking Developers of Europe, I have setup a new group on LinkedIn. It would be great if you could join in and contribute to the knowledge sharing and discussions. Click here to join.

 

5658

Comments: (2)

Ed Daniel
Ed Daniel - esdaniel.com - Europe 19 October, 2017, 06:48Be the first to give this comment the thumbs up 0 likes

+1 on sharing your experiiences here and setting up the LinkedIn group.

John Power
John Power - Ostia Solutions - Bray 10 November, 2017, 12:04Be the first to give this comment the thumbs up 0 likes

This is interesting reading. Having participated in a recent conference with a number of banks participating, many seem to feel that simply offering a shared sandbox which simply responds correctly to API requests is all that is needed. From talking to developers on the other hand, many will want more functional sandboxes and an ability to potentiall have their own individual read/write sandbox for their own testing. Having stand alone individual sandboxes will be key for an agile development CI/CD process so that automated tests can be run without being tripped up by other users.

Member since

0

Location

0

More from member

This post is from a series of posts in the group:

Innovation in Financial Services

A discussion of trends in innovation management within financial institutions, and the key processes, technology and cultural shifts driving innovation.


See all

Now hiring