Open Banking has been the phrase on everyone’s lips during the first half of this year. Of course, APIs lie at the heart of this – the connectivity code that will unlock data communication and sharing between banks and third parties. Such a short acronym, but an enormous technological feat and significant change of mindset for banks around the globe, who have historically enjoyed an unchallenged monopoly on customer data.
The race is on. However, it’s not as simple as cutting a red ribbon behind the scenes to declare dormant APIs now “open”. Before banks can open up their data to newcomers, they must first untangle old and inefficient webs of infrastructure. Not only that, but from speaking to our members, it’s clear that every bank is working in a silo to define their own sets of APIs. Needless to say, this will hamper connectivity, easy integration and openness, which rather defeats the purpose of the initiative.
Integration is the key word here. When BIAN was founded, our challenge was to improve the interoperability of infrastructure that was performing different functions in banks. In a new open landscape, the task is now to harmonise standards around the APIs that will allow banks to connect their product and data services to third parties. You don’t design and build an API overnight. And banks are often at pains to remind us that integration costs can often triple the purchase costs of the original software. Our members tell us that these costs can make or break the business case for deploying new functions.
A complex web and service landscape
At the risk of stating the obvious – banking is enormously complex. A bank might be a multinational with a head office, regional and country level subsidiaries. It will operate in many different markets, offering a wide range of banking products for institutional, corporate and consumer customers. It will be running an extensive branch network and provide customer access through all major channels and digital devices. This also implies they are under a lot of different regulatory regimes.
BIAN’s service landscape maps this structure, serving as a reference model of a bank and all the possible business functions that it comprises. This enterprise blueprint is more or less a linked collection of building blocks. Although the business role or purpose of a function may not change all that much over time, the internal approaches, systems, usage and connections will evolve.
As this evolution takes place, it becomes increasingly problematic that there is no clear and universally acknowledged taxonomy which lays out standard definitions for all these banking business functions, in a way that they mean exactly the same thing to every person, and every bank. Add on to this the new information flows between the 300 or so banking capabilities that might exist within each bank, and it can be very hard to see how far the capabilities are connected, and which should be taken up for API enablement.
A new role in the value chain
The technology changes alone would provide enough for banks to be getting on with. Layered on top of this however, is an even more significant implication – the need to get to grips with the re-ordering of the financial system.
For decades, this hasn’t changed very much. Now, evolving customer demands coupled with technological advances are challenging traditional business models, including the historically assumed building blocks of banking, and therefore banks’ value proposition.
It is the re-ordering of this system, with new players challenging previously ‘un-challengeable’ capabilities that is bringing pressure for the banks we’re speaking to. Within this, connectivity and APIs are some of the biggest trends we’re hearing about. Today, many of the infrastructure services that banks provide, namely matching and exchange, are only accessible by a restricted number of parties. However, the internet means that connectivity is not proprietary anymore. This is democratising many areas, and fuelling unbelievable opportunities for agile challengers.
The API quest will continue
Regardless of the difficulties, banks will continue to push ahead with API development and the associated move to micro-services. The very first APIs showed us that it was possible for computer browsers to remember and recognise basic personal data during login points, such as email address and passwords, to make it simpler for users to login to Facebook or Amazon accounts. As we move through 2018 and beyond, we’re hearing from organisations who are looking to build much more complex APIs, allowing customers to initiate a loan or apply for a mortgage.
As this shift occurs, the entire industry will reduce its reliance on core banking systems, causing a fundamental shift in the way that banks work and how software providers will have to design and package their solutions for them.
It is a quick throwaway headline to poke at some of the delays we have seen behind Open Banking. It is a complex balancing act between Open Banking and increasing privacy demands. The behind the scenes view reveals an enormously complicated, interlinked set of processes and information that must be carefully dissected, interrogated, and put back together – all while safeguarding precious customer details and very real financial flows. The opportunities are overwhelming, but it is a steep and potentially slippery ascent before banks can stake their flag at the top of the Open Banking summit.