Value Store System

It is impossible to provide a payment system (any payment system) without connecting (or being able to access) some kind of value store. A credit card based payment system must debit a credit card account and an EFT payment system must debit a bank account somewhere along the line. This is the case for mobile payments too. Without being able to debit (or credit) some kind of value store, it would be impossible to deploy a payment system.

Most mobile payment solutions provide a mobile payment experience that integrate into an existing value store. For instance, mobile banking solutions that provide a mobile channel to existing bank accounts or mobile payment solutions that mobile enable an existing credit card. The challenge with these solutions is to ensure a seamless integration to the existing systems. Some of the challenges is to ensure that the registration process (when a mobile phone gets linked to a credit card for instance) does not create an opportunity for fraud. Also the boundaries and rules related to liabilities and disputes are not always easy to implement consistently.

Other solution providers (only a few) provide the ability to open a new type of value store that can be utilised to perform mobile payment transactions with. This facility is particularly interesting in markets where more people have mobile phones than does have bank accounts or credit cards. The advantage of this approach is that the value-store can be designed in such a way that it is much more tightly integrated with the mobile payment solution. At the same time many challenges must be overcome, like conformance to regulations, compliance with international protocols and the ability to perform audits and reconciliations that will be acceptable to a central bank.

The selection of and deployment of the value store element of the solution is probably the most important decision that can be taken. The different components that must ideally be present in a mobile enabled value store are:

• Real-time clearing
• Push and pull payment support
• Support for a multitude of primitive transaction types
• Security paradigms compatible with mobile enablement
• Ease of use
  
• Transparency

The key to deciding on a value store strategy should not be dictated by available technology, but rather be based on market realities and business objectives.

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.