Banks should avoid treating the delivery of CMA and PSD2 APIs as just another compliance project and instead take the same approach as when delivering new customer products such as mobile banking apps or mortgages 

On August 9, the Competition and Markets Authority (CMA) released the final report on its investigation into the retail banking market. It found that the market is “still not as innovative or competitive as it needs to be”. In response the report outlines a package of remedies which include mandating that larger banks adopt and maintain a common standard for open APIs (Application Programming Interface). To comply - and to benefit -the best approach for banks is to treat APIs as customer products. But what does this mean in practice? 

The CMA’s Open Banking proposal is not the only attempt to make banks open their data to trusted third parties. The upcoming implementation of PSD2 (Payments Service Directive 2), passed in October 2015 and due to go live from January 2018, will require banks to open access to customers’ account data and give third parties providers (TPPs) the ability to initiate payments. 

Open APIs will enable permitted third parties to access key information about banking products, such as interest rates and terms and conditions, as well as customer account data, such as transaction history and account balances. 

Customers will benefit from new services that enable them to: 

• Securely use their banking data to get personalised financial advice and best offers on financial products;
• View information about all their bank accounts in one place;
• Easily compare banking products. 

APIs in context 

APIs have been around for more than 10 years but have grown in popularity recently, powering many of the digital services we use daily. They provide a mechanism that supports controlled access to both public and private data. For example, the popular smartphone app Citymapper uses publicly available data from the Transport for London API to plot the fastest way to travel around London, and many popular websites enable users to sign in using the Facebook API. 

APIs are not new to finance either, with many payment services providers, such as PayPal, and a number of banks (for example Mondo, Fidor, Yes Bank, Barclays, Capital One and BBVA) already offering APIs to third party developers who develop apps based on this technology. 

The API opportunity for banks 

In theory, APIs are a threat to banks, as they may trigger fiercer price competition and divert customers’ attention to third parties’ services. But banks can also benefit by creating customer services that use APIs. There is also an opportunity to be realised by delivering a mixture of mandatory and discretionary APIs in a way that drives additional value to customers and potentially new revenues for the bank. 

Successfully delivering Open APIs 

To help banks take advantage of this opportunity, we have outlined five key principles to consider when delivering APIs prescribed by CMA and PSD2. 

1. Treat APIs as customer products 

APIs are products with both direct and indirect customers (not just technical interfaces that technology teams need to implement and run). By engaging with their API customers, banks can deliver products that meet customer needs. If not, they risk losing out to banks that do.  

2. Build your developer community

Nurturing an enthusiastic ecosystem of developers is essential if banks are to flourish on the back of their APIs, not least because developers are the source of invaluable feedback. Equipped with this third-party knowledge, banks can make their APIs even more attractive to an expanding developer community delivering ever more sophisticated services.  

Mondo is a great example here. They have published an API that enables any Mondo customer to download and ‘play’ with their own data.  As a result people have already built dozens of tools (see examples in their github).

3. Talk to your customers

Of course you also need feedback from the end-users of API-based services. Existing retail, corporate, wealth and SME customers are the source of crucial insights that can inform the design process. At the same time, banks must emphasise the security of the API approach to ensure widespread take up of new services.

One of the best examples so far is the German challenger bank Fidor. Its service offer and customer experience are driven by powerful questions: how do we make banking customer-centric, more transparent and more contextual? Fidor creates a strong sense of community, by regular interaction with users and continuously seeking their opinions. They don’t price and launch products on a ’take it or leave it’ basis. Instead, they get feedback from customers on everything from the price of the product to its name.

4. Build iteratively

Banks should not wait until mandatory deadlines to deliver APIs. Adopting a delivery approach akin to lean product development will ensure that an API programme rapidly delivers a minimum viable product (MVP) for customers to use. Drawing out an API product roadmap will show how the programme moves from the MVP to meeting full compliance. Getting to market quickly means that banks benefit from early feedback that can be incorporated into subsequent versions of the service. 

5. Create a combined business and technology API support model 

Alongside technology delivery of APIs, banks will also need to deliver a new combined business and technology operating model to support third party developers and bank customers using the APIs. For large banks the realisation of APIs will cut across multiple customer-facing divisions and potentially multiple brands. Finding the right place in the organisation for APIs to operate properly as products may not be a trivial exercise, although when executed successfully it can potentially bring significant customer acquisition and retention benefits.

6. Conclusion

Banks should avoid treating the delivery of CMA and PSD2 APIs as just another compliance project. To take full advantage of this opportunity (and to avoid losing business to new entrants and TPPs), banks should take the same approach as with new customer offers, such as mobile banking apps or mortgage products. And as with any other product, APIs need a dedicated product manager who will own the product vision and roadmap that accommodates feedback from customers and business stakeholders. 

In short, only by treating APIs as customer products and building a product management structure around them will banks be able to reap the full benefits of providing APIs to their customers.

References:

https://www.gov.uk/government/news/cma-paves-the-way-for-open-banking-revolution

http://ec.europa.eu/finance/payments/framework/index_en.htm

https://theodi.org/open-banking-standard