In the absence of mobile banking

What do people do when they do not have access to Mobile banking and payment solutions. Surely if a major need exist they consumers must utilise alternatives. The fact of the matter is that they do, often with major risks and costs associated with the alternatives.

The most often used alternative is the use of Premium SMS's. This is still by far the most often used mechanism to pay for content in the mobile world. Few consumers realise this, but the cost of performing a transaction with premium SMS's are as high as 50%. This means that half the price of the goods (content in this case) is paid in order to perform the transaction. If this type of payment were utilised in the purchase of lets say groceries, goods would cost twice as much as they do now.

Another example is payments being charged to your phone bill for broadband usage for instance.

The use airtime as currency is gaining momentum especially where money must be sent over a distance. This means of payment is hugely expensive and also unsafe. This mechanisms does not provide for any consumer protection, yet is being used daily to solve problems that consumers in the lower income bracket are confronted with. In some instance, I have even seen airtime being used as hedging against currency fluctuations. This practice is not only technical illegal, but also inherently dangerous for participants in such schemes.

All of the above is indicative for the need for cost effective, secure, easy to use payment solutions available on mobile phones.

Airtime as Currency

I should have blogged on this before, as this is a hot topic. Many examples of schema that utilise airtime as an alternative to real currency can be found. These solutions either provide for person to person payments and also for remittance solutions in a number of cases. The question now arises if this is not the way to go.

My take on this, is an emphatic NO! This is for one just not sustainable (see some of my comments below), but also potentially extremely hazardous to the underwriter of this currency (the mobile operator). If this approach really takes off and more and more currency needs to be produced to support the demand (money supply), serious problems like inflation, run-on-the-bank etc. could materialise. Mobile Operators are not in a position to deal with this. If they fully assess the potential implication on a devaluation of their airtime stock, I believe that they would put measures in place to stop it immediately (like elapse dates on pre-paid airtime). They should be apprehensive to ever start treating their airtime like money in the hands of consumers.

In addition, I think that using airtime for money in any format is totally unsustainable, because I believe that using airtime as money would be:

• Very expensive
• Totally inefficient as compared to proper e-money solutions
• Does not provide security to the client
• Would be illegal in any properly regulated environment

If airtime is being used as currency, it should be seen as an absolute indication of banks failing to
provide in an obvious need.

Killer applications

Most would agree that doing payments or banking is not fun. It is not something that we would do if we could help it. (Well, maybe with the exception of receiving payments!). To provide sexy banking services is a contradiction in terms in my book. This is one of the reasons why mobile banking and payments will never prove to be successful unless it can be used for something, ... well sexy.

The mobile banking and payment industry refer to these things that you can do with mobile banking and payments as the "killer applications". Giving access to your consumers to "killer applications" that they can pay for easily on their mobile phone is the trigger (and key) to a successful mobile banking/payment implementation. In this blog-post, I list a few categories of what applications have been "killing" and which ones are likely to "kill" in the future.


The most frequently quoted killer application is the ability to buy pre-paid airtime directly from your bank account using a mobile phone. I have heard some observers talk of this as being not that sexy, but some of the case studies are immense and only thing I would say is:"ignore air-time purchases at your own peril"

Others that have already been implemented and have proved to be successful are bill payments (low margins are the biggest challenge here), cash on delivery (big money here), payment for parking (requires enough cars and less parking to work - not the case in many countries), some examples of retail payments, payments for content and other pre-paid (e.g. pre-paid electricity).

Payment for the purchase of lottery tickets and other gambling applications have been implemented by a few operators, but it is my opinion that this has not proved to be that successful. I am of the opinion that this is because we have not yet figured out how to do this effectively on mobile phones - so that it works for the new form factor. Many people have ideas on how to turn this into killing applications, but I have not seen them yet.

Others that should also be mentioned in this blog are of course money remittance. Many examples of this type of application have been deployed with good successes. The challenge in this area is working with regulatory constraints and to turn localised deployments into global deployments.

Other killers that I sense are lurking will come from micro lending, export/import, other financial services and many niche applications (like transport, medical, content etc.)

Once again, what do you think?

Transaction Manager (Part One)

This is by far the most complex and often overlooked component of mobile banking. If one were to analyse the fundamentals of mobile banking, one will get to the conclusion that good mobile banking design is about the management of transactions originating on a phone and terminating on a bank account - and many similar types of transactions. A well-designed mobile banking system caters for the support of many different transaction flows. In addition proper consideration should be given for error conditions or when external sources are not available.

A transaction manager should cater for transactions to and from the following subsystems:

• The transaction manager must be able to accept and send messages to the Mobile Channel. This should preferably be done in such a way that it can be done independently from the actual handset solution that has been deployed. Communication to this channel is very time sensitive, because a human would ultimately be receiving these messages. As such time-dependent actions should be configurable.
  
• Applications that are often integrated into mobile banking offerings (called Third Party Applications) must also be integrated. Typical systems that the transaction manager must be able to talk to are bill payment, pre-paid airtime, COD systems and more.
  
• Transaction Clearing is a often overlooked outcome of a mobile payment transaction. a well-designed transaction manager must be able to integrate to and support transactions to and from systems like Money Remittance systems, Central Clearing systems etc.
  
• A mobile banking transaction will ultimately lead to a debit and credit transaction on some account, purse or card. The transactions to and from these Value Stores can be quite complex.
  
• Many different security techniques can potentially be supported. This could be PIN-based, or User-ID and password. It could utilise CLI or certificates. The transaction manager must be able to route transactions to the correct source to verify security and adhere to requirements that may be applicable.
  
• The switch must record transactions in such a way that it is fully auditable and that it can be proved that the operation is fully in compliance with regulations. A well-designed switch will cater for this too.
  

In addition, the transaction manager must be able to string together different transactions in a logical way. It should have the capability to roll transactions back if one component fails or is not available. It should also have the ability to place transactions in pending status and have the ability to resolve pending transactions. This should, according to my experience, be possible without human intervention as it is possible to get hundreds of thousands of transactions in a pending status (when a pre-paid top-up system is not available for a time). When the failing component comes on-stream again, the transaction manager should be able to resolve the transaction in pending state automatically.

In the next blog, I will discuss characteristics and special conditions that a well designed transaction manager must cater for. I will also discuss critical conditions that the system will have to cater for and typical solutions to this.