Top 3 Engineering Challenges You Must Overcome to Win at Open Banking
Open Banking and PSD2 are new regulations which mandate banks to open up their data and platforms to third parties such as FinTech startups, comparison shopping sites, and other organisations, to share data about their products, their customers, and their customers’ transactional data.
Regulators are bringing these changes in to make the banking market more competitive and to improve the financial lives of consumers who will be able to more easily use and share their data in different ways once it is extracted from the confines of the bank.
Open Banking is potentially highly disruptive for banks. Using APIs, a FinTech startup could, for instance, build a digital front-end or a mobile application which uses all of the bank’s infrastructure and products behind the scenes. This means that the bank is disintermediated and becomes a commodity back-end provider, losing the touch point with the customer to a competitor.
To combat this, banks need to build the best, most expansively featured APIs so that more people build applications in their ecosystem rather than the competitions’. Banks also need to build better digital experiences themselves so they are not disintermediated quite so easily.
We have followed the Open Banking agenda closely over the last year. The most interesting angle for us was what this means for technology stacks and how the new API capabilities can technically be delivered in the short timescales available.
Engineering Challenges
Through our work with banks, we know that they suffer from legacy technology stacks, monolithic applications, mainframe-centric architectures and a highly interconnected and sometimes fragile application landscape.
Connecting to all of this over the internet, through clean APIs that are capable of meeting all of the planned digital use cases will be an enormous engineering task. I discuss some of the key challenges below.
Delivery of APIs
The first challenge is in the development, test and deployment of APIs. This might sound like a simple software engineering task, but API development is sometimes an art in itself!
For instance, good APIs need a clean interface design that is clearly documented and easy to understand for developers. Architects developing these APIs will need to incorporate a way of managing dependencies across APIs that evolve at varying paces, and implement a strategy for versioning and maintaining backwards compatibility across new releases.
Once developed, testing is the next challenge. Banks will need to test APIs against known data sets, but have all kinds of data restrictions, such as data masking, which mean that accurate data cannot be easily brought into test environments. They also need to performance test and security test APIs that will potentially be under very frequent ongoing development. Finally, they might also need to test against many clients, for instance checking that our APIs still work against iPhone and Android handsets, or all kinds of browsers.
Once deployed into production, there are a whole other set of considerations and challenges around running APIs at scale. Open Banking envisions thousands of partners interacting with a bank via APIs and digital channels. APIs therefore need to be able to scale rapidly in line with demand. This might include peak periods of the year such as Christmas, or more generally as take up of the APIs increases with usage.
From day to day, these APIs will need monitoring for availability, security, performance or risk management. Again, as a digital platform, these APIs will be under frequent development and iteration, so thorough and proactive monitoring for availability and usage will be critical.
It’s one thing solving some of these challenges for an internal API with a handful of consumers, but when you have thousands of consumers if you make an error or a bad deployment, the reputational and regulatory stakes become very high!
Infrastructure
IT infrastructure projects can take a long time in a bank. Banks are often based on physical infrastructure, including compute, network and storage. Even when they have moved to virtualisation platforms, there are typically still long periods of solution architecture and provisioning, especially for a new initiative the size of the Open Banking.
To make matters worse, a lot of the infrastructure to support Open Banking will need servers or connectivity outside of the bank, either in the internet or a DMZ, for example. This has a lot of security implications for the solution architecture, security governance, and can create further delays for the infrastructure build.
Security
Open Banking potentially involves exposing personal or transactional data over the internet. The security implications of this are massive, with information security groups and even the regulators likely to take a keen interest in how the relevant APIs are delivered in a way that does not compromise security. The APIs themselves and the infrastructure need to be highly secure.
The identity and authentication layer in itself is filled with complexity. Banks will need to onboard and manage the identity of the organisations and individuals who are providing API connectivity into their data and platforms, and also overlay this with a security model whereby individual customers can selectively share information with third parties. For instance, as a customer, I may be willing to share a limited about of transactional data with Facebook or a comparison shopping site, but more information with a company to whom I’m applying for a new mortgage.
A Modern Approach
When we first began researching Open Banking, we realised how this would require and drive IT transformation within banks. To deliver Open APIs on time will likely require a different approach from that which is currently deployed in banking IT - leveraging all of the tools in the modern software delivery arsenal.
To develop the software, it makes sense to use a microservices architecture of loosely coupled services which can be developed, tested and deployed independently of each other. To do this requires significant automation in the build, testing and deployment of the services, which is a relatively new way of doing things for the typical bank.
Considering the tight timelines of Open Banking and PSD2, leveraging third party tooling provided by a vendor or cloud platform feels like a wise decision. This will allow banks to get to market quickly and in a robust way, whilst focusing on the layers more bespoke to their own internal platforms and capabilities that they want to offer as part of their API propositions.
Finally, to use these cloud platforms and deliver on an automated cloud platform needs new ways of working and an appropriate organisational structure: cross-functional, product-aligned teams working in a DevOps way, where small teams own the services and the products behind their APIs from cradle to grave.
Open Banking is potentially a serious threat to the typical bank. However, we believe that with the right approach and the application of the modern engineering techniques described above to make it happen, this agenda can be turned from existential threat into an opportunity for winning market share.
