API Banking is the latest buzzword in the consumer banking industry. Like many buzzwords, it’s not quite as revolutionary as it sounds – APIs have been around since the 60’s and banks have been using them just as long. What it really means is providing access to the data banks hold about consumers, to trusted third parties, via a real-time technical interface. This builds on concepts introduced in the early 2000’s, as Software as a Service started to emerge.
So what is an API?
It stands for Application Programming Interface. In order to read this text, your web browser is no doubt using many APIs to access third party libraries on your computer. In the context of API Banking, we are talking about web services provided over the internet, to external parties. What is really interesting about modern web services is the security model – which in a consumer data context needs to not only authenticate users but authorise third party applications to access a specific consumer’s data. Most smartphone users will be familiar with the security dance that occurs when you link, for instance, your Facebook or Google account with an app. A very similar model will need to be implemented for any consumer data provided by banks – except rather than “This app needs access to your public profile”, you are more likely to see “CleverMoneyApp needs access to your last 30 days of credit card transactions”.
So why is this different to the mobile banking apps and websites we are used to? Well, nearly all mobile / web banking apps are proprietary (provided by your bank) – there’s a few which are not, but they use pretty insecure mechanisms called screen scraping – which is akin to a selenium script opening your banking website in the background and copying text from the page. As an aside, if you use these you should check your bank’s terms and conditions, you might be breaking them by using such things, and as a result, the bank is much less likely to help you if it results in fraud.
If you think about the best non-financial mobile apps you are used to, and the rich, data-driven functionality they provide – then contrast this with your banking app – the difference is huge. API banking will change this, because it will open the market up to competition. Just imagine you can use a single app which interfaces with all the financial services you use, and integrates that with other data sets from the crowd and cloud. There’s real power in opening up more data channels, especially to an open, competitive Fintech market.
Another angle on this is competition in terms of financial services themselves. The “Minimum Viable Product” of API Banking isn’t actually what I describe above, it’s much simpler – bank’s providing static product data such as interest rates and fees for different account types, via a public API. That starts to allow app developers to build “compare my bank account” style applications. That would be a small but powerful step towards opening up banking data. It is quite possible to envisage that in the future – apps will be able to “back-test” my financial history against different service offerings, and tell me which bank account is the best value for my spending habits. Given UK consumers very rarely change their bank, this is clearly a necessary strategic direction for the industry.
So why are bank’s going to do this?
Clearly, it isn’t necessarily in their interest to change, but there are two very significant catalysts at play. Firstly, the regulators are forcing the issue. The EU’s Payment Services Directive II (PSD2) is the first regulation to require banks to provide such data, whilst the relevance of PSD2 is yet to be understood in the post-Brexit UK, the Open Data Institute, along with a number of large banks (including Barclays), have recommended that the UK gets ahead of the game on this one, and also standardises APIs across the industry. In theory standardisation onto a single API structure (more on this later) will keep the costs down for both banks, and data consumers. This is a laudable goal, which has been further recommended by the UK Competition & Markets Authority in a provisional report.
So when can we get it?
The second catalyst is the challenger banks, the likes of Mondo, Atom and Starling Bank. These newcomers can move much faster and provide API banking at a fraction of the cost. If the incumbent banks don’t move to match their feature sets, then they will soon be left behind.
So it all sounds great, and like a brighter future for the technologically enabled consumer, but is this just around the corner, or years away? The answer, unfortunately, is probably the latter. Whilst regulators and banks will no doubt set schedules within the next year or two, most retail banks are still on (at least one) legacy mainframe infrastructure for the core of their consumer banking and payments offerings. Integrating a modern web infrastructure with legacy technology will be costly, and will take time.
The second challenge is the data itself. Sure, it is easy enough to standardise the syntax of data across banks. Everyone knows a bank account number has 8 digits (except when it doesn’t), and a transaction amount has two decimal places (except it doesn’t always)! But what about the semantic meaning of the data? As every tester knows, the devil is in the detail here – standardising the meaning of data values across the UK banking industry is a mammoth task, if it is expanded to the whole of the EU, it gets even bigger.
Regardless of the challenges, here at Piccadilly Labs we think the forward march to more open data has proven transformational in so many sectors, it is now inevitable for banking, and as long as the security is right, can only be beneficial for the average consumer.
For more information please contact firstname.lastname@example.org
Adam Smith – Director