Archive for May, 2017

API Strategy: Partner API’s

May 2, 2017

Like an Extranet, Partner API’s are limited to specific parties, often for a very specific purpose like providing a product / service. Technically the API is no different to a public API, but access to the API will be limited typically using a 3rd party API gateway solution. Partner API’s are usually monetised, and this can be achieved in a number of ways e.g:

  • Directly: Charge for access to API’s

This might be by individual or bundles of calls, or through a subscription charge for access (e.g. see https://algorithmia.com/) . You may even decide to give access to a subset of API’s away for free so as to try and sell “premium” services later.

The charge can also be built into the API itself, online payment platforms that take a      percentage of transaction values are a good example of this.

  • Indirectly: Use API’s to create revenue streams outside

As above there are many ways to do this:  Banks are already used to selling 3rd party products and taking commission or introducer fee’s on products like insurance and credit cards: API’s make this easier.

You can find a good discussion of monetisation models here.

You might create partnerships simply to create a new value chains that increase customer loyalty e.g. make it easy for customers to use a P2P Lender within the banking service rather than customers having to create a separate relationship with them. The bank will also benefit from a better understanding (data) of the customers financial activities. Driving innovation is also an objective for many banks. Hence increasingly banks are creating their own API Marketplaces e.g. https://www.bbvaapimarket.com/ or https://developer.capitalone.com/ ).

Increasingly banks are looking to differentiate their offering through “vertical integration”. This is where banks will use API’s to integrate 3rd party products and services to augment what they provide. This may be purely financial providers or others that help the bank target very specific customer journeys or segments. For example Monizo (UK) and Kumsal (Turkey) both target different segments of business banking and augment their banking service with other services that are useful e.g. tax filing and expense tracking.

Hence in looking at your API strategy remember it’s not just about what you publish, but also about what API’s you consume from 3rd parties. Choosing your partners is an important decision, especially when you own the customer relationship. Some of the things to consider when selecting a partner:

  • What if the partner “defaults” or their service goes down – will their absence break a process/journey?
  • What data are you passing and do you need to get customer permission first?
  • How many relationships does the bank want to or can it manage
  • What do you lose by using a partner rather providing the service yourself e.g. customer intelligence

Partner API’s may be part of your overall API strategy or managed quite separately from others (Public and Private API’s), either way they are going to play a key role for banks going forward and need to be managed accordingly.

Key Take Aways

  1. Your Partner API strategy should have clear objectives and measurable outcomes ( e.g. increased revenue, customer loyalty)
  2. Choose your partners wisely and manage them proactively

The next post addresses the 3rd type of API’s, Private (internal) API’s – sometimes known as Enterprise API’s.