BLOG

Avoiding Common Pitfalls Along the Journey to Open APIs

In developing markets, there is no shortage of innovative start-ups and app developers that are eager to build digital products for unbanked populations. However, these solutions are often not possible unless developers can seamlessly leverage the data and payments infrastructure of their countries’ large payments providers. Granting access to these “digital rails” through open application programming interfaces (APIs) -- which allow third parties to connect to an enterprise’s systems -- brings obvious benefits to developers and customers. As a growing number of examples show, harnessing third-party innovations can also increase revenues for providers. But opening APIs is challenging. It takes time and strategic thinking to get right.

The API journey of e-commerce platform MercadoLibre is a good example of what open APIs — if done strategically — can accomplish for providers, developers and customers. MercadoLibre has provided APIs to third parties who offer complementary services (such as accounting, delivery tracking, analytics and marketing) to vendors across 19 countries. In Argentina, for example, this has allowed Moon Money Online to offer loans to small businesses that have difficulty accessing credit from large financiers.

After obtaining consent, Moon Money uses a loan applicant’s MercadoLibre transaction data to calculate a credit score. In this way, Moon Money avoids relying on traditional bank sources that might not capture the applicant’s financial viability. For Moon Money, e-commerce vendors and MercadoLibre, this is a win-win-win. Moon Money reaches new lending customers they had not previously been able to support. Vendors get access to credit to grow their businesses. And as the vendors start selling more products, MercadoLibre receives higher sales commissions and sees an increase in buyers visiting their platform.

This is exactly the type of API approach that other established digital financial service (DFS) providers should consider pursuing, and some are already moving in that direction. But as early cases have shown, when traditional enterprises get started with open APIs, they often do so on an ad hoc basis and end up spinning in circles, rebuilding similar APIs over and over. Internally, this creates confusion and inefficiencies. Externally, companies that approach APIs with a “build it and they will come” attitude can become disappointed when developers don’t start knocking down their doors to integrate with them.

For all these reasons, having a well-conceived APIs business strategy in place is key. And digital financial services providers can avoid common pitfalls on the way to developing a strategy by following an API maturity model. The model below is based on best practices that have emerged in various industries and countries.

Chart of an API maturity model.

In the initial stage of the maturity model, providers introduce APIs for one-to-one integration only. This means individually connecting partners to the company’s business services, such as bill payments or bulk payments.

In the enablement stage, providers open the essential digital rails by moving from custom integrations to a more efficient, standard payment API offering that any partner can use via self-serve access.

Once the basic digital rails are in place, providers move into a more experimental stage in which they stimulate innovation by releasing open APIs and testing new revenue streams with external developers. They watch and learn to see how developers use the APIs.

In the last stage, providers draw on what they have learned in previous stages to develop an open API business strategy and introduce business models that move beyond opening essential services, to frontier opportunities like sharing aggregated, anonymized data that could inform new product development.

Already, some enterprises have adopted this maturity model approach. In Kenya, for example, Safaricom has moved beyond one-off custom integrations by recently releasing an API suite in beta version, through which they hope to learn from developers. Developers are already using the APIs and starting to engage on the company’s developer portal by contributing to forum discussions about how to build new apps. This move by Safaricom represents a significant shift in Kenya’s market, where most APIs are offered on a one-to-one basis.

CGAP has started working with a handful of partners who are interested in adopting open API strategies. We will be helping them to refine their strategies; determine which APIs make sense to open up; decide how to open them up on a technical, commercial, operational and governance level; and help with ecosystem engagement to facilitate innovation.

As we learn through these partnerships, we will share the successes and challenges of opening the digital rails. A number of new resources are currently being developed for use by the sector, exploring issues such as API business strategies and products, technical considerations, and governance to manage risk and security.

Add new comment

CAPTCHA