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.

Many platforms (including that use by MPesa) were designed for airtime. The platform designers figured that by replacing minutes with a currency the platform would magically become a mobile money platform. This approach never works well because money is fundamentally different from airtime. The security, reporting, KYC, and other requirements are catagorically different when dealing with airtime versus money. Many airtime platforms have a “maybe” transaction where there is a doubt as to whether the transaction should be processed and the minutes are “given away” when in doubt. When it comes to money there is no room for doubt and giving it away is out of the question.

Other platforms have been built for cards or banking and have since been adapted to include the mobile as a new channel. While such platforms are build to handle money they are not built to leverage the inherent security features of the mobile phone nor do they know how to optimize the service and interface to take advantage of the phone’s ability to communicate with the account holder. Furthermore, they are not designed for unbanked and underbanked populations which I think should be the primary target market of any mobile money service.

There are so many issues at the platform and technology level–I’m only scratching the surface here.
I agree that it’s truly a testament to the value and power of mobile money that these issues have not undermined it’s popularity.

I’d be happy to discuss this with you further and will likely discuss this on our blog (http://www.tagpay.blogspot.com/) in the near future. You can reach me via email if you have questions: isabelle.berner@tagattitude.fr.

Wherever I go, I keep hearing about mobile money platforms that are not stable and experience regular capacity issues. System downtime is a recurrent customer complaint. Of all the hard stuff that a mobile operator needs to do to pull off a successful mobile money platform, I would have assumed this would be one of the more routine ones. I would have thought that by now there would be adequate scalable hardware and ample experience on how to run basic transactional platforms. It’s remarkable that the mobile money proposition is so strong that even a popular perception of unreliability doesn’t seem to derail it.

You supply some answers but it feels a little too grab-bag for my taste, apologetic almost. And I don’t see much of it being special to mobile money. Any large mobile-enabled IT deployment would face similar issues.

Let me re-group your answers into four categories:

a) The problem is not real, it’s mostly a perception. When people can’t do something, they blame the system rather than themselves or their phone.
b) It’s not that hard, we know what needs to be done, we can do it. But it’s just not taken seriously by telco senior management. They don’t put in enough resources, and when things go wrong they accept downtime too readily without making heads roll.
c) The problem is not in the mobile money platform itself, which indeed is quite simple. It’s in all the other telco platforms that it needs to integrate into. The telco and IT bits just intrinsically don’t work well together.
d) It is harder than you think, this truly is leading-edge stuff.

Can someone tell me where the real issue is, and why? Thank you.

One great way to avoid dependency issues and optimize throughput and reliability is to use the audio channel and sound based technologies to process transactions. Tagattitude’s platform, TagPay uses the audio channel and Near Sound Data Transfer technology to secure all transactions.

Audio provides three crucial advantages that help ensure that the mobile money service remains reliably available–First, with NSDT it provides bank-grade security that is online with real time transaction processing (this is not the case of the SMS channel). Second, the voice channel is much more reliable than the SMS channel–even with network overloads you instantly know whether a call goes through or not. With SMS, you aren’t sure whether and when a message will be transmitted. Third, the audio channel is public and therefore there is no need for partnerships and special agreements with the telecom operators and clients belonging to any telco can access the mobile money service.

Another lesson we have learned relates to the customization. In previous versions of the TagPay platform we offered such customization and sure enough this made version management much more complex. Since we have switched to an open API approach whereby we include a set of standard public APIs that allow our clients to customize their platforms without impacting the core platform and therefore, without risking upgrade incompatibilities or impacting service integrity.

In sum we’ve found Audio and APIs to be key factors in ensuring that our TagPay platform supports mobile money services that are reliable, secure, scalable, and robust.