Open Mobile Money APIs

--

CGAP released a short article called “Digital Rails”. It’s a decent read about a look at what mobile money can (and should) be. No one questions the potential of mobile money for financial inclusion and we’ve spent the last four years trying to make mobile money more accessible for businesses. We’ve written about how mobile money can serve as digital rails before and CGAP isn’t the only organization pushing Open API’s.

Note: I’ll do this workshop for free
  • GSMA is pushing their own set of “harmonized API’s” for mobile money.
  • The UNCDF Mobile Money 4 the Poor (MM4P) is hiring a consultant to run an “Open API Workshop” in Uganda.
  • The core wallet providers have even started to acknowledge that Open API’s are a thing. Although after integrating with these systems, the title of this blog makes me think that someone at Comviva wrote this as an internal memo and not a thought leadership piece. More on that later.
  • Even some operators have started to jump on the API bandwagon. (1, 2, 3) although there certainly are some criticisms of process. (Nice Post Leonard — spot on)

At the risk of flying to close to the sun or invoking Jerry Maguire, I couldn’t help but think that nearly all of these articles miss the mark on where the problem really lies. There may still be a few operators that don’t want Open API’s, but that’s not the issue. The problem, as I see it, is that creating API’s that are “Open” requires:

  1. the operators to manage internal processes in a way that is sane
  2. core wallet providers to be incentivized to offer API’s to their customers (usually operators).

Let me offer you a closer look.

First — the process. Kirui K. Kennedy has perhaps the best post on the UX for MPesa that I have read. The lack of usability extends to the way API access is managed and granted. In Safaricom’s case, the API itself is usable, although not particularly clean. Where Sfaricom struggles is in the handoffs between the different departments. It took our team 2 months of back and forth with Huawei and Safaricom engineers, risk managers and our account managers to get the process done in Aug. 2015. To be fair to Safaricom, it seems like it has gotten better, which is good to hear. More and more companies we come across in Kenya already are integrated with their system but they still haven’t released a KYC/Identity Verification API to the public.

Safaricom has an advantage that the Core SDP and the mobile wallet platform are both built and managed by Huawei. It also helps that they made a concerted effort to open up their API. Let’s take a case where neither of these things are true — MTN Uganda.

The following account paints a negative picture of MTN Uganda, but it is meant to illustrate the pains of integrating with telco systems everywhere. This was our experience. I hope it adds value to those embarking on a similar process and if you work for MTN and want to discuss any of the following, email me at {dan at beyonic dot com}.

First — getting access involved us nearly being shut down by MTN. We had asked for API Access for about 18 months prior to getting it. For those 18 months, we were delivering payments through their bulk payment interface. We were nearly at capacity on the current setup and had 10 additional enterprise customers who wanted to use our system. We couldn’t service these customers, and we knew it. We kept being turned away, but as fate would have it, breaking the rules is what finally opened up the door for us.

Specifically, we moved all of our payments to the agent interface vs. the bulk payer interface. For techies out there, we were essentially scraping both interfaces to run some of our systems. This may not seem like a big issue, but it’s a matter of regulation and revenue assurance for MTN. Agents get a commission for putting payments on to the network. Bulk payers (like Beyonic) pay MTN to deliver payments on to the network and by moving our payments to the agent interface, we were accumulating commissions. This set off flags at MTN and we were asked to come into their office to explain why we had been pushing transactions through the agent interface. Luckily, there was a paper trail of us asking for API access and a business case to back our request. We also never took our commissions. We finally cut through the red tape internally.

Then we got to the fun part — the technical integration. MTN Uganda runs Huawei’s core SDP and uses Ericsson’s MFS Wallet product to run MTN Mobile Money. Navigating the technical and operational sign offs involved 3 different companies, with people across (I think) 10 business units. At one point, we had 27 people in our Skype integration group to discuss who was responsible for what. There wasn’t a clear process on what exactly each person was responsible for, so we effectively served as the PM pushing this through. At the time, it felt like puppeteering with a slinkies. I later found a better schematic on what this process looks like:

MC in the House

After about 2 months of back and forth, testing, building, getting UATs signed off, we finally went live. Then we started with the MTN collection (C2B) system and repeated most of this process.

I’ll spare you the details. You get it.

This isn’t an easy task.

We’ve done this for numerous operators in several markets. It is tedious and resource-intensive. For quite a few companies, this process is complicated enough that it doesn’t make sense to go through. This is true for large multi-nationals like Uber or One Acre Fund, where the cost of maintaining multiple wallet integrations is too high and for small startups who can’t afford to spend the resources necessary to properly integrate and launch their products. This is a win for the operators, who don’t lose money on fruitless integrations. It’s a loss for nearly everyone else.

There’s an argument to be made that this process limits the type of companies that can get all the way through it. I do believe that’s true, but if this is the way the filter is applied, it doesn’t go towards this grand vision of Open API’s.

Incentives

As I mentioned, a large number of Mobile Money providers do not actually maintain or build the core wallet system. MTN uses Ericsson, and Airtel uses Comviva or Obopay. There are several others out there, and generally, they are third-party software vendors that sell the core wallets to telcos. Initially, telcos only care about the core product; P2P payments. Value-added services like merchant and bulk payments are a secondary thought. API’s are a third, maybe 4th, thought. Pretty simply — the core wallet systems aren’t made to have Open API’s and the incentives to create them aren’t there. Because the wallets weren’t designed to have Open API’s, integrations with these systems is complicated and time-consuming (see above). The result of this is that core wallet providers charge USD $10,000–$20,000 for every integration they do. In the case of Airtel, each country-level OpCo gets 4 “free” integrations per quarter and then Airtel must pay for additional integrations. Airtel hasn’t asked us to pay to play yet, but when Beyonic finally got access to MTN’s systems, budget was restricted after MTN got hit with a multi-billion dollar fine in Nigeria. Ericsson charged MTN Uganda, MTN charged us, and we paid for it. If Ericsson, Obopay and Comviva make $10,000 on every integration, they aren’t incentivized to open these systems up, and the current contracts between operators and these service providers aren’t well-suited to changing this dynamic.

Note: If you run Ericsson or Comviva MFS Products and want to talk about how we change this, get in touch.

All said and done, this process cost us a fair amount of money and an extraordinary amount of time. The plus side is that we’ve been able to launch some great products our customers tell us they really enjoy . We even have a great API so others don’t have to go through the same process. In the spirit of open, harmonized API’s, it’s uniform across all of the networks to which we are connected. Our goal is to have these products serve as wide of an audience as possible.

The trend across most systems are Open APIs, and financial service providers, including large banks, are starting to embrace this trend. But until the operators and wallet providers can streamline the processes and retool the systems, this will continue to be a barrier for the top-down dream of truly open financial systems.

Have some thoughts on Open API’s? Hate my writing? Want to just say hello? Comment below.

I am the co-Founder and COO at Beyonic. We help businesses connect to mobile payment networks across Africa and make it easy to use mobile money instead of cash.

--

--

Dan Kleinbaum
Business Beyond Cash — The Beyonic Blog Archive

Working with the next wave on FinTech companies in emerging markets as the EIR at the DFS Lab http://www.dfslab.net/portfolio.html #Purdue & @UTAustin Alum