This concept is nothing new, most pieces of software that you use, will rely on a data source coming from somewhere; think about stock trading platforms which essentially have a pipeline of data coming from a variety of sources in order to provide real-time data to traders. The software platform has been setup in such a way as to provide information to traders in a logical an efficient manner. For those of us lucky to have access to a Bloomberg terminal, you’d be aware that Bloomberg has taken thousands of data sets which have been cut in various way and overlaid with each other in order to provide some pretty impressive and insightful graphs and tables – yet another example of software which takes a complex data source and presents information to a user in a logical and efficient manner.
Note however, that both of these examples are from what you might call ‘closed’ platforms. The software is a locked box which does not allow or only allows limited customisation within a set of predefined parameters.
Historically, if you have wanted to access you bank account information, you’ve really only had one choice, to log into internal banking and accept the format and data presented by the bank; usually limited to account balances, outstanding credit card payments and loan values. More recently, most banks also present the same information via mobile apps. Note that in both of these cases, you (the client) are viewing materials on a platform that has a) been developed by the bank, and b) only contains data which is provided by the bank, such as account balances.
The concepts of APIs has created considerable ‘buzz’ recently, namely because a) it involves opening up the data source to public developers, allowing them to do with it what they which, and b) it’s banks which are actually opening their data sources. Yes, those traditional, stuffy and very private institutions are allowing external developers to access parts of their data. Banks will continue to stick to their core businesses, whilst acknowledging that rapid software development is probably something that should best sit outside of their primary scope of interest.
This is huge step, the weight of which should not be glossed over.
The potential for innovation and creativity here is phenomenal. Have you ever wanted to be able to:
- See an automated forecast of your income and expenses, taking into account historic earnings, expenses and future share dividend payments
- Track in real-time your expenses
- Overlay a map of ATMs or department stores on your spending to see where, when and how much you spent
Think back to when Apple launched the App Store. It gave unprecedented opportunity for developers to build their applications and launch them using a platform which provided a global reach. In 20016 the Apple App Store was a platform with roughly 2.2 million individual apps, which created US$8.5 billion worth of additional revenue for Apple and paid out US$20 billion to the developers using it as a platform.
Turning the attention back to the banks, they may not have the same global client size that Apple does, but within their markets, there is no doubt a relatively captive audience that will be keen to access and view their personal financial information in new and creative ways.
There are several interesting questions which can be posed now and answered over the coming years as greater clarity emerges in this space.
- What measures will API developers be expected to take in order to protect the data provided by the bank and maintain the privacy of clients?
- What commercial models will start to appear in this space to entice banks and developers to work collaboratively?
- Will other owners of data ‘open their pipes’ to APIs? Think healthcare, utility providers and government services to start with
- By supplementing financial data with that from healthcare (for example) what other innovative ideas exist?