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 3^rd 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, 3^rd 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¹ created Albert, a POS terminal with open API’s. This allowed 3^rd 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² (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³ created their marketplace over 4years ago to create an ecosystem of apps for their customers. Visa⁴ has a broad range of API’s including extensive access to data and analytics and BBVA⁵ have certainly put their money where their mouth is when it comes to API investment.

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.

Dis-intermediation 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

 

Next: Partner API’s

Do you need a business strategy for API’s?

There seems to be a gold rush around API’s, every bank, fintech and his friend have their picks and shovels to mine their wealth. Hackathons, marketplaces, platforms are abound as they seek to drive innovation and chase the “network effort” for compound growth that has catapulted today’s winners like Amazon, Uber and AirBNB. API’s themselves aren’t new, the internet has given them a new lease of life while mobile ubiquity has provided a compelling audience whose owners look for their lives to be easier, better and more convenient. Hence API’s are the key enabler for improving customer journeys.

About 3years ago I searched Google for “digital banking”, it was early granted, but nevertheless clearly on the horizon. There was hardly a page of results specifically targeting anyone looking for guidance on creating business strategy for digital and today the same can be said of API’s.

This is surprising given the investment already gone into API’s and hence from a business perspective a number of questions go round my head:

·      Are there enough developers for every bank to drive innovation through hackathons?

·      How many banks can grow and sustain an active marketplace (aka ecosystem)?

·      Is it beneficial for a fintech to partner with a bank and become a B2B player?

·      Will API’s disintermediate banks rather than make them prosper through innovation?

·      Who should publish and who should consume an API?

Having spoken to many banks globally, I have yet to meet one that has a clear and solid business plan behind their investments into API’s. A plan to create an “ecosystem” or marketplace is not a strategy, as it needs to address opportunity/returns, competition, risks. So I’d love to hear from Banks that are proud of their API strategy.

A key tenant of API’s is that giving access to them generates new value, which may take form in many ways such as creating innovation, creating new revenue streams or adding value to customer journeys. I believe the keys to an API strategy is first determining WHO you give access, to WHAT and WHY. To create your strategy, start with WHO and then the WHAT and the WHY will be specific to that audience.

For me the WHO is similar to the early days of the world wide web and hence exist at 3 levels for a business, each having a distinct and separate goal. These 3 levels I call the 3 P’s: Public, Partner, Private. Firstly like the open Internet, there are Public API’s which are accessible to anyone. In banking, regulations is driving for open banking which will be enabled by Public API access. Although getting account information or making payments will require customer permission, these will be open such that banks can not determine who can or can’t access them, if their customer has provided permission to a 3rd party to do so. However Banks may open up other public API’s too, for example to drive innovation.

Next are Partner API’s, these are API’s that are accessible to only to specific Partners of the bank, similar to how many companies run portals or Extranet’s for partner access. These could be Fintech’s, other banks or indeed organisations nothing to do with financial services. Banks will need to use API Gateway’s to manage access to these API’s for specific organisations only.

Finally, there are Private API’s, these are used internally by a bank, similar to how they use Intranet’s. Generally these will be used by larger organisations with many disparate departments

I’ll be covering the WHAT and WHY for each scope of API (Public, Partner and Private) in the following posts.