Blog article
See all stories »

Open Banking APIs need standards

With the objective of stimulating competition in banking, the UK’s Open Banking organization has shared a set of Open API specifications and data standards designed to dramatically reduce barriers to entry.  While APIs certainly aren’t new, developers now have a set of guidelines to follow in building their own apps and websites. The new Open API standards are helping developers get on board more quickly and are simplifying the learning curve – but is it as easy as that? Can every bank API now communicate seamlessly with every other? 

Not quite. While the Open Banking guidelines are more detailed, PSD2 is much less prescriptive when it comes to defining exactly what the APIs should look like and how they are written. Ultimately the specifications, based on REST, are a technical standard only and the exact interpretation can vary from bank to bank. Even with a simple request like ‘get account’, today there are differences in the way banks are implementing these instructions which will require code to be adapted from bank to bank. 

Consortiums such as STET in France and the Berlin Group are taking a similar stance to Open Banking in aiming to define more precise standards but there needs to be commonality between all – otherwise developers and Fintechs looking to service banks across Europe (and beyond) will need to create interfaces to support every different flavour of bank API. Clearly such an approach could become rather unwieldy.

In my view it’s essential to create a set of common, industry standard APIs that can be used by all. Certainly as more banks and Fintechs adopt the Open API specifications and experiment, it’s encouraging to see commonalities starting to emerge. Our goal is to help support and accelerate this process.

Just as Salesforce set the standard for sales automation software and created a common platform for sales automation apps, the same needs to happen in banking. A platform-based approach, underpinned by an extensive ecosystem of participants that all adhere to common standards, is crucial in enabling banks to quickly access, integrate and deploy new apps from Fintechs and developers. 

An open, agile, platform-based approach

A library of standard Open APIs, available to all banks and developers wanting to collaborate through a common platform, could dramatically ease the collaboration process. Crucially this means that application developers only need to develop their application once, with no need to create a unique version for each bank.

Connectivity to a standard set of pre-built and fully integrated Open APIs is just one of the building blocks necessary to achieve success. A platform-based approach can also dramatically optimize the software developer environment. For example, giving developers the ability to interact with the Open APIs in a sandbox environment will allow them to experiment online in bringing data into their applications and to test the inputs and outputs in a safe environment. The use of low code is another key ingredient in supporting rapid application development, with highly visual tools allowing developers to create, configure, test and deploy new apps to market faster than ever before. 

Longer term there’s also a need to extend the Open APIs beyond retail banking to cover every area of finance – from corporate and transaction banking to lending, treasury and capital markets – enabling innovation in all areas.

In my view, a platform-based approach that leverages Open API standards has the potential to fundamentally change the way that software is developed, deployed and consumed in the world of finance and to deliver immense benefits to customers.

8815
External | what does this mean?
This content is provided by an external author without editing by Finextra. It expresses the views and opinions of the author.

Comments: (1)

Ketharaman Swaminathan
Ketharaman Swaminathan - GTM360 Marketing Solutions - Pune 11 May, 2018, 20:571 like 1 like

My bank (in India) supports unlimited field length for IMPS payments but supports only a limited field length for NEFT payments. The recipient of a NEFT payment receives the sender name and account number whereas the recipient of an IMPS payment does not. Take FPS in UK. While the scheme sets stringent SLAs on communications between sender and receiver banks, the nature of communication to sender and receiver - who IMO are the two most important stakeholders in a payment transaction - is not stipulated by the scheme. According to the FPS website, “Once the payment has been made, a confirmation message will always be sent between banks. Each sending bank will decide how this confirmation will be made available to its own customer.”

Based on my exposure to martech, Salesforce has not set any industry-standard. It has created a single-company, proprietary platform - Force.com - into which other products may plug in if they wish to. The other products similarly need to develop different connectors to integrate with SFDC competitors like SugarCRM, Oracle CRM, SAP CRM, etc. I'd be happy to be corrected if my understanding is wrong.

TBH, uniformity of APIs is a pipedream for the entire banking industry even in one country, let alone across all countries in Europe. 

In any case, the point is moot in the aftermath of the FB-CA fracas. For it to gain mainstream adoption, Open Banking Needs A Blockchain Boost.