At the end of 2014, Open Data Institute and Fingleton Associates was commissioned by HM Government to explore how competition and consumer outcomes could be affected, by creating an API, which exposes some transactional data to third parties.
The report was primarily focused on two main banking markets: Personal Current Accounts (PCAs) and SME Lending, although did look into other markets that could potentially benefit from the sharing of data. Further to this report, a call for evidence was requested for anyone interested in the sharing of data in banking to respond; including the banks, consumer groups, financial service providers and software developers who will ultimately be creating the application(s) consuming the data.
As a digital marketing agency we work with many APIs on a daily basis - having access to the data and services they provide is extremely valuable and intrinsic to the creative process and the work that we produce. For an API to be effective it has to be underpinned with good quality data: box ticked - banks already have this in abundance.
But such a vast amount of rich data with so much potential also presents an inherent risk. More time can be spent discussing a range of issues: the possibilities, the mechanisms in which to surface the data, the technologies that could be used and what the problems might be, that it can sometimes slow down the process of creating something tangible, especially when working in small teams. This can lead to the creative process becoming relatively slow and ultimately suppress innovation.
But by opening the data up to more people, this in turn has the potential to accelerate this process exponentially. Innovation can come in many ways - from learning and evolving ideas from your own experiences, but also from the success and failures of others around, which can spark a new direction of thought and fresh ideas. By inviting people from different markets and disciplines, you encourage the cross-pollination of ideas that derive from different perspectives; which in turn, increases the level of innovation that can be achieved.
Keep it simple
We develop API’s for many of our clients. The first rule we follow is: ‘keep it simple’.
This has many benefits in this context. Firstly, you don’t have to invest large amounts of time initially into developing a large complex API, which may contain elements that may never get used. You can develop a basic API available quickly. This can then initially be released as beta to trusted suppliers, and tested to see what works and what doesn’t. You can start to get a feeling for how people use the technology, as this can sometimes be different to how it was first envisaged. This then informs the direction of later iterations the API needs to take and how to shape it.
Thirdly, the process would give banks confidence in areas of concern, or help to inform any decisions where views are split on an approach.
A Software Developer’s perspective
In order to deliver an API that provides useful data in a consistent way, banks will clearly have to agree on many things between themselves and key internal stakeholders - from what data to expose and the security and governance around it - to who they allow to use it and how this is moderated. Whilst these things need a lot of serious consideration, as a software developer there is one area that shouldn’t be overlooked: how the API is packaged up and presented to the development community.
It’s essential developers want to and can use it easily; it needs to be intuitive, easy to use, and as much thought needs to go into how this is communicated to the developers that will be developing against it to maximise the adoption of it. This also includes all supporting documentation, from API References to Terms and Conditions, ensuring it is clear and concise, with no ambiguity.
Open Data and banking is inevitable if the banks are to keep up with modern consumer-buying expectations, and the value that both banks and customers can derive from it is huge. There are lots of big decisions that the banks will need to made and this will likely need some time to reach a collective agreement, which could be a slow process. However, reducing the size and complexity of the API could help speed things up.
Finally, an API can have an amazing set of data or services behind it, but if it is difficult to develop against and the barrier to entry is high then this can lower the levels of adoption and innovation.
In essence: keep it simple.
Find out more about our work