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

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.



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:-

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.


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

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.


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.


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


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.


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 Kamath
Pramod Krishna Kamath
Lead Product Manager
Finacle Product Strategy
EdgeVerve Systems Limited