Fifty million years ago, in the Cambrian Era, the diversity of life on earth exploded, thanks to a perfect storm of microbial enablers and geologic conditions. Today, some observers think the world is witnessing a digital “Cambrian Moment” because of a combination of highly connected people and easily accessible building blocks for digital services. The financial inclusion sector is poised to share in this Cambrian Moment, thanks to widespread mobile phones, mobile money adoption and other enablers of innovations that promote access for the underserved.

In this post, we look at one of those building blocks – a potential enabler for financial inclusion: application programming interfaces (APIs). We also discuss the different types of APIs and how financial institutions should think about their API strategies.


What are APIs?

Application program interfaces (APIs) are a set of defined methods and functions that allow one computer program to “talk” to another program to consume data, perform actions, or both. APIs generally reduce the complexity of accessing technology systems and automate the interaction between systems and apps in ways that are seamless and unseen to the consumer.

Greg Walker of 18F explains APIs by analogy to grocery stores, which easily connect thousands of shoppers to thousands of food producers. “You [know to] go to the produce section for bananas, not the dairy aisle. You don’t have to know how to grow bananas, how to harvest them, or how to ship them; you only need to know that you want them. The store ‘hides’ the how so you can focus on what matters to you – getting some food.”

APIs act as a catalyst for a variety of services, including some examples that promote financial inclusion. For example, Teller, a DFS Lab portfolio company uses APIs to connect cost-effectively with customers. Teller offers AI-powered financial literacy training, customer onboarding, and customer support for digital financial service providers. Teller is behind some of the largest deployments of chatbots in emerging markets. A key enabler for their multi-platform chatbot are APIs that enable Teller to access messaging services like SMS and WhatsApp and voice via IVR to reach customers. APIs to these services are provided by companies like Twilio and Turn.


API Delivery Models

Generally speaking, financial institutions offering APIs utilize one of three methods:

1) Open APIs

Open APIs are designed for general, repeatable use and openly accessible to third parties.

Twilio and Turn are open APIs for communication. Open APIs offer access to functional systems and, ideally can be accessed purely online, with no human interaction. To encourage uptake of open APIs, providers often offer free sandbox testing or freemium pricing allowing developers to start using the service free to get a sense of how the APIs function and whether they work with the developers’ products. Readily available documentation, standardized onboarding and KYC documentation processes, sandboxes and other aspects of the delivery in open APIs are designed for repeatability.

A financial institution planning to offer open APIs embarks on a journey that can require significant upfront investment of time and resources and may come with some risk. This is especially true when converting from complex legacy IT and core banking systems which were not initially designed to be accessed via API. Moreover, there are often significant security requirements and regulatory hurdles that must be considered.

Despite these barriers, more and more financial service providers are opening APIs. MTN Uganda invested $400,000 to open their mobile money API. Equity Bank in Kenya has invested upwards of $10 million in Finserve – a subsidiary to offer a suite of open transactional, KYC and account APIs – and NedBank in South Africa invested over $138 million to incorporate APIs as part of a massive technology overhaul across the bank. Justifying the investment, long run benefits can include higher deposits, transaction volumes and revenue, resulting from an ecosystem of partners who also benefit from lower costs of integration and better service delivery through open infrastructure.

2) Private APIs

Private APIs are created to grant access to a specific party or parties.

Private APIs are designed to enable financial institutions to allow specific internal or external, pre-authorized parties access to certain functionality, based on predetermined requirements. Often, a discreet business or use case dictates the development of a private API and, consequently, the major distinguishing feature of private APIs is a lack of repeatability.

An example comes from Xendit, a payment processor in Indonesia, which was founded to build the “Venmo for Indonesia.” After succeeding with peer-to-peer payments, Xendit saw demand for customer-to-bank transfers. Xendit collaborated with a mid-sized bank which, as a regulated financial institution, can process payments to any other bank in Indonesia. The bank partner developed a transactional API for Xendit that enables the service to make instant transfers to any bank in Indonesia from an escrow account held by Xendit at the bank. On that foundation, Xendit built an expanded set of products, including payroll payments and invoices, has successfully onboarded a large number of customers, and built a viable business. For the partner bank, the Xendit relationship has significantly increased its total deposits.

3) API Marketplaces

API marketplaces are offered by third parties to other third parties.

API marketplaces are also operated by third parties, and offer APIs on behalf of any number financial institutions. API marketplaces aggregate documentation, KYC, and onboarding processes and try to get a critical mass of fintech innovators actively looking to develop solutions with participating financial institutions. By spreading the costs of constructing APIs among a larger number of participating FIs, marketplaces can lower the costs for participants. Examples of API marketplaces include FinConecta, a global API marketplace, and the APIX exchange launched in the ASEAN region.

The resources available and business goals tend to determine the delivery model chosen by a financial institution. Internally-owned, open APIs offer financial institutions the greatest flexibility to build a suite of API-based products that can enable a successful innovation ecosystem, but they require significant investments in technology and people to sell and support. In some cases, there may not be a need, or resources available, to open APIs, and a private API will suffice to work with a partner. Private APIs still requires technical development and internal capacity to build and sell.

API marketplaces, on the other hand, reduce the need to redo internal business structures and add internal capacity. However, initial interviews for my research indicate that given the lack of ownership over success metrics, in addition to regulatory barriers, more effort may be required to make these successful. I will investigate this in more detail as my research proceeds.

– Matthew Reinbold, Director, Platform Services Center, Capital One

More Than Technology: A Product

Regardless of how a particular financial institution implements APIs, technology alone will never be enough to successfully build partnerships using APIs. Thinking of APIs as products inevitably leads to considering complementary business units, which can be the difference between success or failure. The gold standard comes from Amazon Web Services, Twilio and Stripe – three companies that have been extraordinarily successful in building and selling APIs. They have separate departments for a set of services to adequately deliver APIs as a product: sales and marketing, technology, documentation, customer onboarding, and customer support. Successful API implementations need to think through each of these aspects, and having KPIs attached to each function can lead to measurable results.

Financial institutions have regulatory approvals and core banking capabilities that are highly valuable in the market, while fintech innovators often have greater ability to iterate rapidly and develop new products for underserved or unproven customer segments. Creating partnerships between these two types of organizations offers multiple opportunities for bringing innovations to market. Increasingly, these partnerships are based on financial institutions productizing APIs and offering infrastructure for new products and services.

Dan Kleinbaum

Entrepreneur in Residence, DFS Lab

Dan Kleinbaum is a 2019 CFI Research Fellow investigating how fintechs and financial institutions are using APIs to reach underserved customers.

Dan is the Entrepreneur in Residence at DFS Lab, where he is supporting the next wave of fintech companies and helping build out the global fintech ecosystem. Prior to joining DFS Lab, Dan co-founded and served as the Chief Operating Officer at Beyonic, a payment aggregator offering streamlined APIs and other tools for businesses to connect to mobile money networks throughout sub-Saharan Africa.

Explore More

Sign up for updates

This field is for validation purposes and should be left unchanged.