Open APIs

APIs as a construct has been around for quite a while, however, banks have been slow to embrace the power that APIs and Open Banking can bring. Part of the reason for this is that APIs are generally considered a “technology service” and not a “business product”. i.e. not a revenue generator. Business leaders quite often view APIs as a “necessary headache” used for “integration” rather than strategic assets that can accelerate growth.

However, the Case for APIs and Open Banking has never been stronger.

Fig 1: The case for APIs

case for APIs

To pursue a successful monetization strategy, banks must approach APIs with the clarity of a well-thought out product — have a clear intention and articulation of value, and most importantly, have a clearly defined audience

This paper provides some pointers on how banks can look to monetize APIs and drive growth.

5 MANTRAS FOR MONETIZING APIS

1. KNOW THY INVENTORY

As with any business, it is important to know your inventory i.e. what is it that you are selling?

APIs can be classified into the following buckets:-

  • Data APIs
  • Transaction APIs
  • Application Integration APIs
  • User Interface APIs
  • Application Component APIs
  • Utility and Helper APIs

Knowing the type of API and it’s utility enables enterprises to understand the potential value for consumers of the API and providers pointers to pricing. E.g. you maybe able to monetize Data and Transaction APIs better than some of the other categories.

More importantly this approach can help you review your portfolio and help identify gaps and areas of potential.

2. UNDERSTAND MONIZATION MODELS

Depending on the type of API inventory and value for the customer, banks must have a clear view on the path to monetization. The chart below provides a view on well-known monetization models used for APIs.

Monetization models

Monetization models

  • Utility and helper APIs (which can possibly lower operational support cost) could possibly be positioned as Free APIs.
  • The ‘Consumer Pays’ model can have variants that require the consumer to pay for different levels of usage (Tiered), to pay a fee based on usage (Pay as You Go), to pay according to the consumption of specific units of computing or service (Unit – such as cpu cycles), or to use the API for free but pay for various types of additional services (Freemium).
  • Revenue share can be implemented with partners who might be bringing in net new clients for the enterprise. The revenue sharing mechanism could be one time (up-front) or recurring on a period basis (say monthly).
  • Indirect methods to monetization might mean acquisition of a service or content from a partner which possibly helps in improving customer service. i.e. the gain is not directly monetary in nature. Other forms of indirect monetization might include lead generation – identification of potential customers.

3. CREATE VALUABLE INVENTORY BY REPLACING EXISTING INFORMATION DISTRIBUTION MECHANISMS

Banks have a treasure trove of data however they are not always good at monetizing this data. Information / data distribution in many cases is through good old fashioned reports. The problem with reports is quite often you don’t know who uses them and if they are consumed at all! Reports fundamentally represent an old paradigm of data distribution and in a digital world, Data APIs are the best way to go.

In view of this, banks must review which of their data assets could be reused, repurposed, or revalued. A strategic intent towards data assets can help identify assets that really matter and create value by opening up data sets.

4. MAKE A PURPOSEFUL CHOICE ON GO-TO-MARKET

Having taken stock of your API portfolio, it is important to define how this portfolio can be taken to market as a ‘product’. For this one must define the intent of the API product offering. i.e. is this going to be a new banking channel? , is it meant for Ecosystem engagement? , integration with partners? etc.

API Banking GTM models

  • Banking Service Channel
    In this model APIs represent yet another channel of delivering banking services to your customers. The intent is “faster time to market”, customer responsiveness and possibly scaling integration with partners and clients.
    As this is a new channel for your own products, the monetization model would possibly follow traditional methods albeit factoring for incentivization /dis-incentivization a particular channel.
  • Ecosystem Engagement
    In this model Bank services are exposed through open APIs to 3rd party developers. The objective here is possibly to create a vibrant ecosystem of FinTech players around your services, helping amplify your service capabilities.
    Here it is possible to charge API calls on a Tiered or Fremium basis or even work on revenue share basis if the 3rd party is bringing in new clients for a particular service.
  • Reseller
    Here the financial institution bundles external services with it’s own offerings. The intent could be to deliver best of breed products through partnerships. As partnerships are adding to service capability and bringing in new customers, revenue share with partners is a possible monetization method.
  • Banking as a service
    Offer open banking as a service by exposing specific capabilities e.g. Ledger facility, limits etc. for consumption by other financial institutions or enterprises.
    As an entire functional capability is being shared in this model, banks can charge license, maintenance fee, hosting fees etc. for the services being provided.

5. EXERCISE VARIABLE PRICING OPTIONS

Uber’s “Surge Pricing” mechanism seeks to put a premium on scarce inventory (cabs) when demand peaks during adverse conditions (e.g. rains). In the Banking API world, server and computing bandwidth are the “scarce inventory” which you can price based on demand.

The original intent of API traffic management techniques is to regulate traffic and safe guard the system from malicious attacks or poorly written code. However, these very traffic management options can be used to implement “Surge Pricing”.

Quotas and Throttling are 2 traffic management options that limit usage of computing bandwidth.

Quotas restrict the number of API calls that can be made in a period. e.g. Twitter limits the number of API calls a user can make in an hour. For clients who want a higher volume of traffic, Twitter offers this for a fee.

Throttling is a technique that restricts API usage by slowing responses down. During peak hours you can use this option to differentiate service tiers – offering premier access to customers /partners who are willing to pay more.

CONCLUSION

Monetizing APIs requires a strategic intent and product mindset. As with any product, a clear positioning, articulation of value and knowledge of end consumer needs are elements that are crucial for success. While the product might be relatively new , age old principles of ‘knowing your inventory’ ,creating inventory in line with your strengths and market potential and  selecting the right Go-to-Market are still very much relevant. The techniques highlighted in this paper can be contextualized to your bank’s operating context to achieve best results.


Pramod Krishna KamathPramod Krishna Kamath
Lead Product Manager
Finacle Product Strategy
EdgeVerve Systems Limited
Pramod_kamath01@edgeverve.com