Where is the money?

Mobile payments is an interesting concept. I have heard a lot of people talking about how making payments from a cellphone could be earth-shattering - how it would change the way that people shop and do business for ever. And I believe that they are right, but in order to make this vision happen we have to solve a difficult problem... where is the money?

No, I don't mean, how we are going to make money by running a mobile payment scheme. I mean, what are people going to use as money to pay with. If they complete a transaction and they hit "send" (or "pay") where will the money come from to do this payment. To put it in another way: "which account will be debited". Many different solutions have been suggested and implemented, but all have significant challenges. Below is a summary of some of the Value Stores that could be used as the money in mobile payments:

• Using an existing credit card as the source for doing a mobile payment would seem to be the most obvious approach. This has successfully been implemented, but suffers from the following challenges: A relatively small percentage of people with mobile phones have credit cards globally, the transaction can be expensive as credit card fees must be paid before any other revenue can be generated and the rigid (but sound) rules regarding fraud places a very big risk on such an approach.
• Using the mobile operator's billing engine as the source for payments have been proposed, but this approach can even be more expensive than credit card transactions. (See one of my previous blogs) . In addition, expect regulatory problems and significant challenges to extract cash out of the system. It is also unlikely that the mobile operator would be happy with sharing money earmarked for telecommunications with other retailers.
• Utilising existing bank accounts could be interesting, but integrating telecommunication systems to core banking systems can be expensive and time-consuming. Also the strain on a banking system when millions of small transactions starts hitting it, can be outside the design limits of such a system.
• A new dedicated mCommerce account may be the way to go. Remember that when credit cards (a new payment system) were launched in the 1970's, it came with its own dedicated account management system. Why should that not be the case for mobile payments?
  

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.