Partnership: Missing Ingredient to Mobile Money APIs

If you chat with a group of software developers in an innovation hub in Africa, the conversation quickly and inevitably turns to mobile money and open APIs. Software developers are tremendously excited about mobile money and the potential for new apps, such as Wave for remittances or mjara for loans, to dramatically expand the flexibility and use of mobile money platforms. Accelerating mobile money innovation could expand the reach and benefits of financial services offered to the unbanked, which makes APIs exciting for anyone who cares about financial inclusion.

During recent interviews in East Africa, we heard the optimistic view that with open APIs “the possibilities of what could be done with this are endless,” together with the counter view that “Telcos need to open their mobile money platforms to developers if they want mobile money to survive as a payment method past 2020.” But despite the apparent demand from developers, and the six business rationales for MNOs to open their APIs recently documented by CGAP, there remain no real examples of widely adopted open APIs for mobile money. Of course, open or closed is to some extent a question of degree, depending on who the MNO grants access to, with what restrictions, and with what approval hoops the developer must jump through before gaining access to the necessary code. What is lacking are ‘fully’ open APIs where all the code for the API is published and accessible without weeks of negotiations and technical discussions with MNO integration teams to agree on protections and other specifics.

Across Africa, MNOs have stopped short of fully opening their APIs:

• Safaricom has resisted the pleas of developers so far, though it has now migrated its platform to Kenya and promised an eager developer community that open APIs will be soon forthcoming;
• Orange has opened its APIs in a limited context and marketed them in West Africa around its Orange Lab initiative, but these are still not widely adopted;
• We learned that Tigo has been publicly considering opening its APIs, but has not had any major campaign or outreach to developer communities;
• We also learned through interviews that MTN has opened its APIs in various countries but only to a limited number of aggregators, thereby restricting uptake and innovation.

A successful open API requires three things: a mutually attractive business model between MNOs and developers, an effective and easy-to-use API, and ways to encourage active use from the developer community.

Identifying the right business model can be tricky, not least because there is often a lack of trust between developers and MNOs which is rooted in developers’ belief that MNOs will “steal their product ideas” or threaten them with denial of access. Mitigating the MNO-developer mutual mistrust should be one key consideration for selecting a payment model for access to the API. There are three basic options to consider with open APIs, drawing from John Musser’s excellent presentation on ProgrammableWeb:

1. Free. Theoretically the most attractive to developers, free APIs encourage the most activity and innovation. But they also carry the risk that MNOs aren’t sufficiently invested and may choose to limit or cancel the API down the road, after developers have invested time in developing applications.

2. Developer pays. APIs where developers pay for access can include a number of options based on how they pay (e.g., pay as you go, one-time transaction fee) or when they start to pay (e.g., tiered model). One model with particular relevance to encouraging innovation is “freemium”, where developers are only charged once they pass a certain threshold and may be particularly attractive for two reasons:

• Encouraging experimentation
• Allowing API access to developers for startup or socially-minded organizations with more limited ability to pay

3. Developer gets paid – typically through a revenue share. In this model, APIs developers receive commissions for transactions conducted through their platform typically achieved through a one-time, periodic or recurring revenue share. When an MNO is actively trying to market use of its APIs, this model can be effective as it provides greater incentives for developers to use the APIs and it aligns the interests of the MNO and the developer – to drive traffic through the platform -which can benefit both sides. It signals to a developer that the MNO does not want to “charge” for use of API, but instead to share in fruits of innovation.

In practice, where they do make their APIs accessible to clients, MNOs across Africa are deploying a combination of ‘Developer pays’ and ‘Developer gets paid’ models. Two factors may determine where one model is used over another:

1. Size of the developer. Smaller, independent developers need the MNOs in short-term more than MNO needs them, so do not have leverage to insist on a revenue share
2. Nature of product. If the developer’s product is a standardized cookie-cutter type product, such as integration of the mobile money platform into developer’s website for receiving merchant payments, then the MNO may use the ‘Developer pays’  model. In this scenario, the  developer is not bringing new types of revenue streams to the table. If a product is genuinely innovative and doing something new with MNO’s platform, then ‘Developer gets paid’ may be attractive, as it gives the developer space to prove a concept without being charged for using API.

So what does this mean for financial inclusion? Business models and campaigns such as the recent Citi Mobile Challenge can be structured to encourage innovation targeting specific challenges – such as financial literacy – or specific products – such as insurance – that reach underserved people. Partnership is the missing ingredient to achieve the right incentives for all.