API Strategy: Public API’s aren’t just about regulations

It’s easy to think that Public API’s are just about regulation, such as PSD2 in Europe, driving open banking. Certainly regulatory driven open banking will force banks to have Pubic API’s, but they are not the only type of API’s. A few banks, the “innovators” have had public API’s well before the arrival of open banking regulations. In this post I examine the two most common Public API’s: Regulatory and Platform API’s:

Regulatory API’s

Europe’s second payment services directive (PSD2) is the first regulation globally in banking aimed at increasing innovation and competition in Banking. However it is clear governments in other countries like the USA are watching carefully before following suit.

Whilst Banks have to follow regulations they should also be cautious as without having a parallel customer intimacy strategy, it will be easy for banks to be disintermediated by 3rd parties providing stronger value propositions and more compelling customer experiences. Banks can achieve this in a number of ways for example:

• Provide services and products beyond that possible by having access to just Open API access. Remember today regulations only give access to current and deposit accounts, not loans or other products. They also only provide access to payments and account information, not to services like setting up direct debits or beneficiaries.

• Create meta-data to drive better insight or services for the customer. Spend categorisation is one obvious example. Whilst it is possible to categorise with account information, 3rd parties will not have full access to the rich meta data that is captured by banks so can only provide basic spend analysis. For example mobile transactions can provide location, weather and device type information over and above basic transaction detail.

• Aggregate other bank data to provide a full single customer view to the client. Many robo-advisors are already down this path, not looking to replace the account but to own the customer relationship for managing their total financial affairs.

 

Platform API’s

Banks have the opportunity to either become a platform or use a platform. The platform sits between buyers and sellers and can either be based on software, a device or data.

Here an API is exposed freely to create “stickiness” to the platform. The consuming organisation will have access to an API that will allow them to create new value. For example CBA(1) created Albert, a POS terminal with open API’s. This allowed 3rd parties to leverage the banks merchants using Albert and provide new applications based on API’s that give access to data and functionality provided by Albert. For example an app for rating service provided by the merchant or the ability to split a bill between friends. These apps provide additional value to merchants using the banks POS and in turn help the bank to sell more POS terminals, a mutually beneficial relationship (a key tenant for creating an ecosystem). It is also a mutually interdependent relationship, as the app vendor wants access to the bank customers, and the bank wants the app developers to create compelling solutions based on their technology. Square, the innovative payments provider, was possibly the first and certainly led the way in this kind of approach.

Another example would be Deustche Banks, Autobahn Forex trading API’s(2) (available since 2011), here the bank provides access to forex trading. The bank does not prohibit anyone, but there is a process for validating the users of the API’s. Credit Agricole(3) created their marketplace over 4 years ago to create an ecosystem of apps for their customers. Visa (4) has a broad range of API’s including extensive access to data and analytics and BBVA (5) have certainly put their money where their mouth is when it comes to API investment.

 

Rounding up

Many banks and Banking As A Service (BAAS: e.g. Fidor, Solaris, Leveris ) providers are following suit. However they all need to be mindful not to have a “build it and they will come” approach. Creating and fostering an active marketplace requires a long term commitment and significant effort and planning. There will no doubt be fierce competition for developers attention as more banks enter this space. Without a proactive approach marketplace’s can become stagnant, and I predict many will fall by the wayside due to lack of investment or competitive strategy.

Disintermediation and a lack of a planned strategy are not the only threats as API’s open the door to new security threats and hence banks will need new infrastructure to keep the wolves at bay.

Key take aways:

1. Ensure you have a strong customer intimacy strategy if you want avoid disintermediation
2. Creating eco-systems is a race for developers, ensure you have a clear strategy to recruit, retain and motivate developers, as well as a plan to sustain growth of the ecosystem.
3. Access to data or devices offer as much (if not more) opportunity for API’s as banking products/services.
4. Security (API Infrastructure) is an important piece of the jigsaw

 

1. https://www.commbank.com.au/business/merchant-services/eftpos-options/in-store/albert.html
2. https://autobahn.db.com/
3. https://www.creditagricolestore.fr/
4. https://developer.visa.com/apibrowser/#category=general_services
5. https://www.bbvaapimarket.com/products