Imagine if every time you wanted to use Google Maps you had to visit the Google Maps home page.
You’re on a restaurant’s web site and you need the directions? Just exit the site, type in the Google Maps URL, enter the name of the restaurant and wait for the map to appear.
Thankfully, we are spared this clunky experience. Why? Because Google has opened up its APIs. This means that third party developers can add some code to their own sites that link it to Maps data.
This way, consumers get a speedy experience, web sites can offer richer information and Google gets more hits.
It’s fair to say APIs have transformed the online experience for web and app users. Think about how simple it is to click a Facebook Like or retweet a link or pin an image to your Pinterest page.
So the question is: why can’t banking be like this? Why do banks alone control access to customers’ account information? It’s our data, after all.
There are obvious reasons. First, banks are huge, conservative organisations. They guard their data closely. And they are bureaucratic, so they make innovation decisions slowly.
However, there are exceptions. In 2012, for example, France’s Credit Agricole opened up its APIs to crowdsource new ideas for apps. It showcased them in its own CAStore portal.
The following year, BBVA did something similar via its Innova Challenge Big Data 'datathon’. In all, it attracted 144 app submissions from developers in 19 countries.
Meanwhile US banks including Citigroup, Bank of America and Capital One have also experimented. Just a few weeks ago BBVA Compass made its APIs available to the payment startup Dwolla. Now, any BBVA Compass customer can transfer money instantly to anyone on the Dwolla network.
Evidently, these initiatives are mostly experiments by individual banks. So far the only truly collaborative API initiative has come from Germany.
Back in 1995 the German Bankers Association created HBCI (Home Banking Computer Interface) to help the country’s smaller banks extend access to account information without having to build expensive front end services.
The protocol - later re-born as FinTS/Financial Transaction Services - is now supported by more than 2,000 banks and has given rise to some extremely popular third party apps.
A good example is the personal finance management (PFM) app Numbrs. This app lets users import account information from virtually any bank and then track spending, set budgets, create alerts and project future financial patterns.
Of course, it is possible to build a PFM app like Numbrs without an open API. For example, you could ask users to enter their own spending and account data. Obviously, this is not a great consumer experience.
Another option is to store users log-in details so that the app itself can access the account. This is the approach chosen by popular products like Mint, which then visit the bank web site and to retrieve the information needed. Needless to say, there’s a security risk here.
Using banking APIs is more secure. Why? Because the account holder only ever logs in through the bank itself. He or she is then free to grant the app read-only access to specific account details. The process is similar to when you let an app have access to camera or location.
And it’s secure because no login credentials are ever stored on the app servers.
This is how a product like Numbrs works. It’s also the basis of popular PFM apps in other regions such as Kontomierz.pl. This is powered by the Kontomatik banking API, and lets the user import his account data countless times, but only asks for the login once.
While HBCI kickstarted a lot of bank innovation is Germany, many believe the protocol is now limited and out of date. It’s why some companies are taking the original API and trying to build more modern technology on top of it.
The Open Bank Project, launched by Berlin startup Tosebe, is the leading example. Its tech is based on a the open source ‘RESTful’ API and uses the OAuth standard for secure authentication. Tosebe also helps banks create branded app stores, through which they can distribute the new breed of apps that result.
Sample products include TimeBalance, a MacOS desktop app that plugs into the menu bar and displays recent transactions. Then there’s the Android app - Speaking Bank – for the visually impaired, which ‘talks’ transaction details in response to voice commands.
As well as giving consumers more choices, bank APIs could encourage corporate bank customers to explore the idea of making their accounts more transparent too.
For example, a charity could display its bank transactions for all to see in real time (with the option to anonymise or use aliases where confidentiality is required). One could imagine how the most ethical organisations would flourish if they made their activities truly transparent.
Despite the conservatism of the banks, the momentum doe seem to be building behind openness. The aforementioned Kontomatik API currently supports over 70 banks across Poland, Russia, Spain, Czech Republic Slovakia, Brazil and Mexico.
They include a new generation of digital-first banks like Alior and Idea, which have used APIs to foster innovation around their services.
Another indication that support for the idea is growing came when Envestnet bought startup Yodlee for $590 million in August 2015. Yodlee offers developers access to data from around 450 banks worldwide via a combination APIs and screen scraping.
Meanwhile, in September 2014, the UK Government’s Treasury Department launched a ‘Call for Evidence’ to explore how an open banking API standard could be delivered.
It said its aim was to maintain the UK’s position as ‘the global centre for financial technology and to lead the world in open source data in banking’.
The city of London has been the hub of world finance for 400 years. Clearly, it believes that a new era is approaching and that only an open approach to data access can keep it there for centuries to come.