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.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: