Also you mention that in many countries most of the customers are multiSIMing and at the same time you say that Mobile Money services are used by MNOs to gain customer loyalty and reduce churn. But as most of the customers in those markets are price sensitive they will always multiSIM.

Today in most of the cases MNOs already partner with at least a bank, this require a minimal integration. Saying that this is not yet the time to think about a centralized way of integration with other actors encourage bilateral relationships thus multiple projects and multiple partners to manage. I just want to say that instead of looking for cheaper alternatives and workarounds that provide a satisfactory response for the time being, it is probably wiser to think about long term solutions. I believe that the long term solution are the centralized switches that can be owned and managed by third party actors willing to invest and offer interoperability services, but not limited to money transfer service. The investments on the MNOs side in this case will be limited to the implementation of the interfaces toward centralized switches.

I think interoperability should be part of MNOs long-term strategy. If interoperability has no real essential benefits, then I do no see why MasterCard and Visa are willing to get into this business?

Although we have had our share of technical issues with our platform, my greatest frustration with mobile money platforms (in general) is that they are cost prohibitive.

In a small market like Cambodia (population 14 million), where mobile money is relatively new, we struggle to find a balance between growing the transaction volumes and investing in additional functionality to grow transaction volumes (i.e. payroll, ATM cash out, remittances, etc.). We need to add additional functionality to better serve our subscribers, but we struggle to build business cases that support the exorbitant development costs. For example, as a professional courtesy to our post-paid subscribers (MNO), we wanted to add post-paid accounts to our bill pay menu. However, when we asked Utiba (our platform provider) for a cost estimate, they came back with a cost of [redacted] USD (we opted not to pursue it further). There are many other examples of costs preventing us from adding additional functionality, as the business cases don’t support the investment.

The issue is not just isolated to our business, but our competition as well. ANZ Bank recently sold their interest in Wing (competing mobile money service), as their losses became too great. From what we here within the industry, their Comviva platform was so cost prohibitive that after 3 years, they realized that they could not recoup their investment.

If small markets are to have successful mobile money deployments, the platform costs need to come down and reliability needs to increase.

Are there any reliable ratings related to platform providers? I would like to see much more competition in this space, as current options are less than satisfactory.

However, there is a vendor originated issue that is affecting the industry which isn’t much talked about, which has to do with where the industry is coming from, I think this might be what Hannes is touching upon. Mobile money deployments have increased drastically over the last two-three years, but the vendors who are around are mostly the same ones. So we have a number of small to medium sized companies that suddenly can find themselves in a situation with more customers than ever, scattered over three different continents, trying to trim their products in different ways to fit the needs of their market.

Given this, most successful vendors are undergoing big administrative changes to cope with the increase in demand by hiring and training staff & engineers while trying to take more market share in an industry in bloom. The result is that many of them are struggling to keep quality and delivery times, being reactive rating than pro-active in how they manage their product. This can express itself in tech providers in a couple of ways:

i) Lack of longterm vision (partnership) – due to shortsightedness of both the vendor and the MNO, it is common that the price and product gets negotiated down so much that many deployments lack basic features required to deliver a good service. Monitoring tools and reporting tools to mention some two examples. If both parties saw this as a long term partnership, the MNO would be less concerned of initial cost and it would be in the interest of the vendor to deliver a good quality service.
ii) Keeping talent – many vendors are suffering from high turnover in staff. Due to the increase in deployments, talented engineers get hired by customers or competitors.
iii) Improving their product – many MNOs customizes the platform. Here a lot needs to be learned by the technology vendors in adding features to their platform after input from customers. Improving their core platform as they learn from the industry.

To conclude, I believe that most technical providers are working hard to try and handle these issues, and I hope that more companies are focusing on building the best product possible and taking it forward continuously. Right now, the state of some technical providers are beginning to be a bottleneck for innovation in the industry. If all these issues mentioned in my comment don’t get fixed, many providers will find themselves in a tight spot when bigger and more experienced technical providers like Ericsson and Huawei enters the mobile money technology market.

I was one of the original 6 people involved in the creation of the M-PESA pilot, and personally involved both in creation of the platform and on-the-ground launch. I was on the end of the telephone on on-call duty when some of the early platform capacity issues hit, and involved in the resolution of those issues. (I have not been involved in any of the incidents related to M-PESA of recent however.)

Given my background – i would like to say:

1) M-PESA was built from scratch as a mobile money platform, purpose-designed, because nothing that existed in the market fitted the vision. It was (and i believe still is) hosted separately to Safaricom’s airtime servers in PCI-DSS compliant hosting facilities required by a banking product. It was not at all linked into airtime systems apart from the fact you could buy airtime from your M-PESA account. (It was obviously linked to the Safaricom SMSCs too)

2) M-PESA has a plethora of behind-the-scenes features that take care of the full puzzle: identity management; security/encryption, KYC, real-time account registrations, CSR, Reporting, Fraud, Sanction Screening, and not at all least: very coherent agent facilities that should never be underplayed in a system of this nature that is 100% dependent on a very strong agent network with good float management, where they themselves are disparate and need to be paid commission!

3) There are many potential places where a service of this nature can have bottlenecks, and probably a comment on a board of this nature is not the place to go into it in intricate detail; some frankly were unavoidable in the early days (before there was an undersea cable to Kenya, we were at the mercy of sunspots!).

Some of these things become even more difficult if you have’t got the right partnerships in place however – if you can’t raise your satellite link provider to determine if there are connectivity issues, and you have no SLA with him, or you end up having to prove to him there is a problem rather than the other way round. If you are trying to launch a product that relies on SMS independently of an SLA with the MNO… no matter how much capacity in the platform, you will still have downtime that feels EXACTLY the same to the customer – no money movement; even worse – silence. Thankfully the Safaricom team proved an excellent partner that took the product very seriously, learning alongside us what extra processes and procedures they needed to run a service of this nature.

However – capacity planning is an important element in the puzzle too, and no-one in the original team foresaw the incredible growth streak that M-PESA experienced in those early days; the business/capacity plan for 2 years was achieved in less than 6 months. Building extra capacity into a system growing at that rate, whilst also trying to cope with massive demand for new features and capabilities was no easy job!

We all understood in the early days what was at stake when the servers went down; literally – people were stoning agent premises, patients couldn’t have operations because they couldn’t get their cash… the stories are all out there. The personal commitment of the original team from all involved companies could not be questioned, we all bought into the vision very keenly of what we were trying to do. Personal dedication from employees on all fronts from all 3 partners was fundamental.

I guess I just wanted to set the record straight a little about M-PESA, from an insider’s point of view in the early days, as I noticed the comment about it being an airtime platform. I have no direct associaton now with the platform and the problems they’ve been experiencing recently. New platforms emerging can certainly benefit from those lessons from the start, as to the potential of a platform like this to really capture people’s imagination. I can see it again in the past week here in the UK with the marketing launch of Pingit too – people are definitely interested!

When I was small, I used to build sand-dams on the beach. It was fun to see if I can keep them intact when the waves broke over them. The principles of building sand-dams are significantly different than large concrete dams built into rivers, because the scale is just not comparable.

The same is the case with mobile banking. We have found that the principles start to change when subscribers start growing into the millions and transaction-volumes increase to a million a day or more. Not many systems run these types of transaction volumes and it is my fear that many with subscribers of a hundred thousand and tens of thousand transactions a day will learn these lessons the hard way when their deployments reach scale.