APIs provide the technological means for banks to connect their payments and data services to third parties, which is the core intent of PSD2. This collaboration enables incumbents and challengers alike to use customer data and innovations to create new revenue streams and more contextual services. But there are obstacles to overcome in developing these interfaces.
The level of interaction of APIs with incumbents will depend on challenges around interoperability and payloads, as well as the complexity of banks’ existing backend systems. The latter is one of the most problematic areas for API development and integration, says Hans Tesselaar, executive director at Banking Industry Architecture Network (BIAN), a not-for-profit fintech industry body. He says:
The real challenge for banks is that they have to connect to their complex back office environment before they are able to work on implementing open APIs. This is something that fintechs do not have to do, resulting in a much faster and more efficient integration process than banks.
Tesselaar says the legacy status of much of the IT infrastructure at established banks is a real problem:
API is a short acronym, so there’s the potential for misconceptions that these interfaces are somehow already ‘packaged up’ behind the scenes, ready to be declared ‘open’ for use. The reality is much more complex, due to banks’ tangled up and archaic core infrastructure.
Once processes have been mapped, Tesselaar points out that banks still have to address the question of whether to keep these various business capabilities in-house, or simply consume them off the cloud as and when required. In addition to these well-known issues, there’s the problem of lack of global rules for APIs.
The lack of standards issue
As well as the issue of integration, having a global standard and model for API development will be crucial in taking innovation further.
Even though most banks are now working very closely with fintechs that specialize in both API development and deployments – and tend to use many of the same large vendors – there is no single set of rules. Tesselaar explains:
It is essential that all parties speak the same language and respect the agreed [IT] boundaries in order for accelerate progress towards a truly open environment.
He believes a serious issue that can be seen across the industry right now is that every bank is shaping its own set of APIs. This in turn limits openness and defeats the principle of collaboration and standardization that sits at the heart of PSD2 and Open Banking.
This problem persists because there is not currently a universally adopted reference model or taxonomy for standard definitions of all the various banking business functions.
The lack of standards is a huge obstacle to making progress on opening up access to account information and transactions, he adds:
Without [standards], it’s almost impossible for banks to visualize the different information flows of every single banking capability within their models, let alone understand how these capabilities are connected and how they can be reconfigured using APIs.
Which standards apply?
PSD2 requires financial institutes to share customer data with regulated third-parties if the customer provides explicit consent. But as Sahana Hussein, HSBC's head of open banking, explains, there is no explicit requirement for banks to share data via APIs, as the regulation doesn’t mandate a specific technology:
But we all agree that API would be an effective interface for banks to share the data. On that basis, it is not correct to say that PSD2 requires standardization of APIs.
Having common standards across the industry would be beneficial for the industry, Hussein says, but she argues there is no need to be very prescriptive:
Hussein points out that a bank like HSBC would not want very prescriptive standards – which are difficult to change on a global scale – but at the same time, some common standards are needed:
I agree there is a need to adopt universally recognized, open standards like OAuth, ISO, FAPI, and apply industry best practices for effective interoperability and wider adoption across the financial ecosystem.
Startups vs banks
While the hope is that every API developed by a financial services provider will be identical, there is still a long way to go before achieving the aim of compliance to a common set of rules. In some countries new bodies such as Open Banking in the UK – or to give its full name, the Open Banking Implementation Entity (OBIE) – aim to create software standards and industry guidelines for competition and innovation in retail banking.
But even where there are local standards banks should adhere to, another issue is that they are likely to interpret them slightly differently – and for startups keen to access incumbents’ services, this represents a major overhead, according to Ritesh Tendulkar, chief software architect at fintech Modulr.
Modulr acts as a mediator that provides a single API for account information and payment initiation services – aggregating APIs from multiple banks and smoothing over their differences, as well as providing regulatory cover. Its API is based on the REST protocol for exchanging data, which is popular with developers.
This, according to Tendulkar, reduces development lead-in times and the need to deal with the different ways banks have implemented the Open Banking API standard. He adds:
Every time Modulr creates a new feature, we consider how to expose this out as an API. [We consider] how should we structure the API to make it user friendly, what information should be exposed.
The fintech also gives a lot of thought to security, says Tendulkar, a crucial aspect of API development in a banking environment. Modulr employs various security measures, including transport layer security (TLS) to keep communications secure between sender and receiver and prevent man-in-the-middle attacks, and a hash-based message signature, which is implemented at the API, rather than the transport-layer level.
Smoothing the path to API access
Under PSD2, the API also needs to be secure in terms of only allowing access to necessary functionality. For example, a third-party system should be able to see accounts and see a payment, but not be able to make a payment unless it also has this permission.
Echoing the thoughts of BIAN's Tesselaar, Tendulkar agrees that given the various technical aspects to be taken into account when building an API, it is much simpler for fintechs such as his employer to develop the interfaces than incumbent banks. He says:
Fintechs tend to look at one aspect of the whole transaction value chain and they need their functionality to work with existing systems. Big banks, on the other hand, have typically controlled a lot more processes in the transaction value chain, so they haven’t needed to worry as much about making their applications work with other systems.
Going forward, what will incumbents and startups alike need to improve to smooth the path to operating in an API-based open banking marketplace? According to Neil Dixley, former lead developer at UK challenger Atom Bank, there must be more cooperation within the banking ecosystem:
The best thing the banking and fintech industry can improve is to collaborate with each other over interests we all share, particularly in security and customer protection. We should all be watching out for each other's backs and working together to set new standards in secure technical processes and patterns.
As PSD2 regulations facilitate market entry in financial services for regulated non-bank players, increased transparency and more choice become a key area of focus for the sector and open APIs are right in the middle of this new reality.
The problem for incumbents has been to adapt to this novel way of doing things – even though many large players have set up an open banking divisions and are trying to work with fintechs to reduce the technical complexities related to innovation and compliance.
As financial offerings become more sophisticated, banks will need to look beyond integration issues and enhance their service fabric to connect the API world to their legacy systems. The lack of global API standards is a complicating factor, but fintechs like Modulr understand incumbents' pains well and are already using them as a competitive advantage.
The standards debate is likely to continue for some time, but as Dixley points out, security and customer protection are paramount in an API-driven marketplace. Where banks historically have been the main responsible parties for their own security, what will happen in the competitive scenario introduced by PSD2 remains to be seen.