The need of the unbanked - or why is transformational banking necessary

What is it that poor communities really need in as far as financial services are concerned? Do people with a low income and very little money really need financial services? Because if they do not need financial services, what are we busy with... this banking the unbanked thing. So, I thought that I would list the things that I think people need in communities with limited resources, just to get the ball rolling:

• They have the need to be able to receive remote payments electronically, without having to take a day out and to travel. Many people in poor communities need payments from families working in cities or elsewhere or use government grants or handouts as the means for subsistence. The act of receiving these payments are often expensive and complex.
• The ability to be able to save towards a target is not available. Even if some-one cultivates the discipline, the actual mechanisms (putting cash in a bottle or savings clubs etc.) are not convenient or safe. Many people want to buy something big or are planning a major expense (e.g. sending their kids to university etc.). The correct way that they should do this is by means of a targeted electronic savings product.
• If something happens (like an accident or an unplanned expense for instance), poor people also need access to lending products. Better still, many of these mishaps can be catered for by well-designed risk products. Most of these new financial products are only possible with efficient, electronic payment systems.
• I do believe that poor people also need to be able to have a record of their financial transactions. This is important from a number of perspectives, but the most important (I believe) is that such a transaction record will enable financial education. It is (for instance) extremely difficult to produce and manage a budget, if no record of financial transactions exist.

Many studies seems to indicate that the need really exists, But what do you think?

The collaboration between DFID and CGAP

CGAP recently announced the UK Department for International Development (DFID) to expand ongoing global efforts to use information and communication technologies (ICT), especially using mobile phones. (Read here). This is a very positive move for the the future support of Mobile Money for the Unbanked (MMU).


CGAP did stirling work in financial and advisory support for many deployments all over the world. Their involvement can be traced to the ultimate success of many of the leading solutions in emerging economies today. Similarly, it was through a DFID grant that mPesa was initiated in Vodafone. This can also be seen as one of the trigger-events in the MMU industry.

By joining forces, these two organisations now acknowledge that the vision of providing electronic financial services to the Bottom of the Pyramid can be delivered. The involvement of the Bill and Melinda Gates Foundation in the initiatives that these organisations are now tackling is a further endorsement. The biggest challenge that must be resolved is to help organisations get over the first investment hump quicker. It is important to show that commercial success can be attained without significant capital investment.

My observations of the recent mCommerce in Karachi

I was the guest speaker at this year's mCommerce conference held at the Sheraton hotel in Karachi. The conference was sponsored by MCB and as always well organised by Total communications. I attended the event last year as well. (Read my comments about last year here)

Two things struck me about this year's event:

Much more talk about real consumer successes.
The take-up and transaction volumes of both MCB and Easypaisa received a lot of attention. It was my impression that all of the delegates were excited about the inroads that these two companies have made and the milestones achieved by them. It seems as if they serve as an inspiration to other banks and mobile operators.

Collaboration between regulators
Both the banking and telecommunication regulators were prominent at this event. Both made excellent presentations during the same session and it seems as if a genuine intention to collaborate exist. This is a good sign for the future of mobile banking in Pakistan.

I had a sense that the participants were looking for business insights and that the mood was very much focused on finding business solutions rather than looking for maverick technology.

Mobile banking inter-operability/connectivity challenges

I have written previously about interoperability/inter-connectivity (Read here and here). I have also promised to discuss some of the high level technical challenges of implementing this capability in the current schema and have not yet done so. This blog-entry is a stab at describing some of these challenges. Two major challenges spring to mind immediately. The routing of payment instructions and backing out of failed transactions. I will discuss both briefly below:

The routing problem

The schema for clearing international telephone calls and to ensure that calls terminate at the correct operator utilise a combination of two types of routing techniques. The first is based on international dialing codes and (in some countries) operator codes too. In other words, routing is on the basis of meaning in the number (This is similar to BIN's incorporated in credit cards). In countries where number portability have been implemented, routing is also done on the basis of a look-up table.

Which of the two approaches should be used for mobile payments? If the payment is to be routed on the basis of a meaningful number, should the telephone number be used or a dedicated number? Who will maintain such a number and what procedure will be required to ensure higher accuracy of the routing (like check digits etc.)? If a special number are to be issued, will subscribers be able to remember it and pass it on to payers? On the other hand, if routing is to be done on the basis of a look-up table (an international routing register), who will be responsible for the maintenance of this register and what procedures will be followed to change and delete records? (just consider potential fraud of changing records are not managed well).

Failed transactions

The mechanisms of credit card transactions allows for a payment to fail at the merchant's point of sale if the transaction takes to long to complete (this is called time-out). No harm can be done with this approach as the recipient of the funds (the payee) is in control of the payment. When the request for payment does not complete successfully in a pre-allocated time, the transaction is deemed to have failed and everything is rolled back. Credit card payments are also often only cleared some time later. The merchant do not have immediate access to the funds.

Interoperable mobile payments are confronted with two major challenges because the payer is often in control of the payment and because of the need to clear the funds in real time. This means that the recipient (the payee) would be informed that the payment was successful and having been informed the payment cannot be reversed (or rolled-back). The funds must also be made available to the payee immediately. This is quite easy to implement, except when things go wrong. The technical challenges of undoing failed transactions in this scenario is extremely complex. I am not aware of systems that are capable of doing this in high volume environments today. The design of the protocols that will ensure financially robust interactions is also very challenging.

Conclusion

I think it is clear that the design, deployment and maintenance of inter-connected payments between a multitude of mobile money operators is far more complex than what meets the eye. Many architectural challenges will have to be solved in order to make this real and robust. It is my opinion that most practitioners refer to the vision of interoperability of mobile payments without consideration of how difficult it will be to attain. It may even be technologically impossible.

What is the implications of Mobile Operators buying banks

It was widely reported that China mobile bought a 20% stake in Shanghai Pudong Development Bank recently (Read here, here and here). Although the rationale of the investment given by China mobile was rather sketchy (talking of future synergies), much speculation erupted. Some analysts believed that this was merely a cash injection in the bank at the call of government, while others indicate that this may add to the revenue of the operator.

The key consideration may be to get access to clearing capabilities in a regulatory friendly way. One of the best examples of this having been executed successfully is the purchase of a small micro finance bank (Tameer bank) by one of the large operators in Pakistan (Telenor). The recently deployed Telenor mobile financial service (called Easypaisa) is turning out to be spectacularly successful, but also legal as it is a service launched by a bank, but distributed by a mobile operator. There are speculations in Pakistan that Telenor's biggest competitor (Mobilink - an Orascom company) is actively looking for a bank to buy (Read here). Some informed sources have told me that the purchase may even be of one of the smaller retail banks. Surely this is a ratification of a strategy where an operator would buy a bank with the primary intention of launching financial services.

Can anything be more serious than mCKinsey

Of the blue-chip management consultants, I have always thought of McKinsey's as the most serious. They will not try and get on a hype-wave and sell you unproven concepts. When you contract McKinsey's you expect level-heading, robust solutions. This is a block-buster consulting company with a brand that top executives relate to. This is why it was with interest that I read a recent article in the McKinsey Quarterley called: "Capturing the promise of mobile banking in emerging markets". (Read here).

The article says that the deployment of mobile financial services is a "strategic shift" for mobiel operators and an attempt to counter slowing subscriber numbers and reduction in profits. Big words coming from a major management consultancy. What I liked most about the article is all the numbers:

• For every 10,000 people, developing countries have one bank branch and one ATM—but 5,100 mobile phones.
• Mobile devices reduce the cost to serve customers with financial services by 50 to 70 percent
• About 45 million people without traditional bank accounts use mobile money, but predict that this number could rise to 360 million by 2012
• In less than three years, the opportunity could generate $5 billion annually in direct revenue

I also found reading the comments interesting. Not only are most of a very high quality and demonstrate a lot of insight, but the majority of authors are all from emerging countries (China, India and Nigeria). Really worth a read. Well done McKinsey.

The far-reaching implications of the mShift's patent infringement claim

The way that I understand patents is that this is the only mechanism to register ownership of an idea or an invention. If a patent is granted, one gets the ownership of the invention. Patents must conform to the following conditions: The invention must be novel and not obvious. In other words, it must be something that not everyone and his dog could have thought of. This is the first condition, the second is that it must be original. You cannot patent something that you saw somewhere else or that someone told you about. If the invention was spoken about previously or documented somewhere, the clever IP attorneys refer to this as "prior art".

Okay now having explained patents, lets get back to mShift. mShift is a supplier of mobile banking technology to companies predominantly in the USA. They recently claimed that Intuit infringes on their patent (so called patent 866 registered in 2005) and they are suing for damages. The patent describes a very general way of mapping banking transactions to a framework that can be displayed on a mobile device. I would describe it as a protocol conversion design (If you are interested, you can read the exact patent here).

The date of the invention is important as I believe many (more than many) instances of prior art exists. First patents like this were granted in Finland in 1992. As a matter of fact many countries had production systems of mobile banking in 2003. For the patent to be granted in the first place is strange, but if mShift's claim were to succeed, this would create a very awkward precedent.

This would mean that the advanced (leading) suppliers of mobile banking solutions in the world would be forced to ignore the US as a market, as their solutions that were built prior to the mShift invention would infringe on the patent?

It is not capacity but acceleration that is the problem

When discussing the challenges of building good software to run mobile banking (especially transformational banking), the big question on many lips is the ability of these solutions to scale. The transaction volumes are much higher than anything that financial systems had to deal with previously. Even in relatively small countries like Kenya, mPesa is running peak transaction volumes that no traditional financial systems were designed to cater for.

Under these circumstances it is actually dangerous to design mobile banking architectures that front-end existing banking systems. While it may be possible for the mobile banking portion to cater for big volumes, bottle-necks will become obvious in the core banking systems. The cost of upgrading core banking systems so that they are able to run the increased volumes often kills the business case. A much better approach is to take all the mobile banking traffic off the core systems and use stand-in, dedicated systems, specifically designed to scale.

However, it is not just the ability to scale and to deal with large volumes that is important in considering technology platforms. Some of the other aspects are:

• Not only is it important that a mobile banking system should be able to scale fast and manage large volumes, but also to recover fast from unpredictable situations. The system should also be able to protect itself from adverse conditions (e.g. an integrated service not being available, or infrastructure malfunction), by (for instance) shutting down gracefully. The system should protect the integrity of the financial data at all cost.

• Mobile financial transactions often dispay interesting characteristics. It is often the fast changes in transaction volumes (acceleration) and not the absolute volumes that breaks a system. The ability of the system to ramp up from low volumes to high volumes quickly and/or back again is also critical.
  

As is the case in most instances, these lessons are learned only by means of experience. It is almost impossible to anticipate performance challenges in designing mobile banking software. It is only observing the behaviour of production systems that these lessons can be learned.

The Mobile Money for the Unbanked Tracker

The GSMA published data on deployments of mobile money for the unbanked solutions. The emphasis on this collection is that only data of sites that are actually live and in production will be published. The tool is available here. This is a big step forward as it ignores all the claims and future deployments, but focuses on what is in production today. The document lists 61 deployments. I thought that I would highlight some statistics on these 61 sites, as documented here:

• The majority of the implementations are in Africa (52%), with Asia Pacific a close second (38%).
• Ghana, Kenya, Somalia and Tanzania all boast three deployments, while India, Pakistan and South Africa have four each.
• The oldest deployment still in production is Celpay in Zambia (2001), with 56% of the deployments done since January 2009.
• Of the large operator groups, only two claim more than five deployments (Zain with seven and MTN with five)
• The technology that drives the deployments are supplied by a number of vendors (Fundamo (10) and Utiba (6) are biggest.)

Based on my knowledge of the space, I believe that the real number of serious production deployments is closer to 45. Nevertheless, interesting reading.