Open banking: Getting the business model right

APIS are at the heart of open banking. If executed correctly propose to increase innovation, foster collaboration, extend customer reach and lower costs compared to existing legacy systems. A key concept in the open banking paradigm is to enable third-party developers to build financial applications on top of the banks’ exisiting infrastructure. To succeed with an open banking strategy without rendering oneself obsolete, finding the right business model is imperative.

For banks considering to open their infrastructure, an API strategy should be considered a business strategy, not an IT strategy. Giving away API access for free may drive brand loyalty and allow the API provider to enter new channels, but may prove unsustainable over time. If executed properly, free API access may act as a stepping stone for both direct and indirect business models.

Data exchange is one of the most common API models, and is the core of Facebook’s Graph API. For banks pursuing a data-based business model, the rule of thumb is to create a two-way data feed where you receive data every time the API is consumed by third parties.

Transaction based models is perhaps the most familiar one for banks, and does not differ much from traditional transaction banking services. The main difference in an API context is the way companies like Paypal and Stripe allows third parties to integrate and utilize their services through plug and play APIs, thus reaching out to a broader audience and driving payment volumes.

Charge by call is the most straight forward monetization model, where third parties pay each time a service offered through the API is called. To succeed with this model, your services need to offer a clear value proposition. Before setting up a direct monetization models, you should talk to your customers to see if they’d be willing to pay for these services and for how much. As an example, the default price per API query for IBM watson is $0.0025.

Subscription based pricing for API access could both be fixed or dynamic. A fixed model is straight forward and offers full API access for a fixed monthly cost. A pay as you go approach is more dynamic, where pricing is determined by metered usage. For example a cloud computing platform’s usage price could be determined by the operating system platform and size of platform on an hourly basis. Another dynamic subscription model is a tiered model. Developers sign up to and pay for a particular usage tier based on the number API calls over a fixed time period. While the cost increases per tier the cost per API call usually drops. Vertical Resources uses the tiered business model. Prices drop with consuming more volume (API calls), so after analyzing usage over a time frame, users can adjust their tier.  

Freemium is a great way to get started for both API owners and third parties curious to connect and explore and could serve as a stepping stone towards both subscription based models as well as charge by API call. In this model companies offer developers some of their APIs capabilities for free and then charge for additional functionality. For example, a web mapping service could allow a low number of calls to be made to the API for free and then any additional calls to the API are charged. Adding additional API access to a Premium subscription offers a strong motivator to upgrade to a higher package, as it allows end users to customize their experience and workflow more easily.

Balance sheet is an important strategic resource for banks opening their APIs to third parties. Many fintech are seeking bank partners to provide core financial infrastructure for new products and services. This could benefit banks by increasing assets under management, providing deposits faor capital requirements as well as the potential for additional interest margins if credit is involved.

Revenue sharing is an option to encourage open innovation and co-creation with third parties . in this model it is often the third party who gets paid based on the popularity of the third party application. A revenue sharing model offers shared incentives for both API owner and third party community and should also provide additional scaling incentives.

No matter which model you choose, it all comes down to profitability. One way to measure the success of your APIs is a simple Average Revenue Per User Model (ARPU) in order to see if an API strategy is worth your while. Last but not least, the business model must be aligned with the long term vision and strategic agenda.