Mobile Banking's additional layer

I am often asked why a dedicated mobile banking installation is needed. Some of the companies that we deal with have already deployed excellent Internet banking services or run advanced ATM networks. They sometimes feel that they may as well make the same service available on the mobile.

Many reasons exist for deploying an additional layer between the core banking and the mobile network. The most important ones can be summarised under the following headings:

State management
The Mobile banking layer have to be able to manage the "state" of the interaction of a mobile phone with a back office system that often has not been designed to work with a mobile front-end. In its most simple format, let us look at a balance inquiry. If the back office is busy and a balance is not returned in an acceptable timeframe, the mobile logic should return a message that says: "Service not available, please retry later". In more complex situations where balances are debited and credited across multiple systems with many possible points of failure, state management can be even more challenging, with capabilities to be able to manage (and resolve) transactions in a "pending" state essential.

Buffering of peak transactions
Banking systems are generally designed to deal with transaction peaks of not more than hundreds of transactions a second. In mobile telephony is is possible to be confronted with peaks of tens of thousands of transactions per second. It is good practice to "shield" banking core systems from these levels of transactions while still communicating with subscribers in a meaningful way. It is also important to "shut down" in a structured way when the system is flooded rather than crashing. The problem with most mobile payment/banking deployments is that they have never been exposed to these levels of transactions. Quite a few of Fundamo's deployments are managing transaction volumes that sometimes peak at around fifty transactions a second. I have learned from hard experience that the challenges in this regard are not trivial.

Channel management
Mobile banking/payment solutions are often designed from the front to the inside. This means that the decision regarding the channel (SMS, USSD, Java or xHTML) is taken first and the rest of the system is then developed to support this channel only. These systems are quite simple, but also very inflexible. It is preferred to deploy "channel agnostic" solutions where many different front-end technologies can live together and can be utilised as required. This approach enable banks to offer more advanced solutions that can actually be used.

Unique mobile security elements
Effective, (but also usable) security can be deployed using mobile phones. Unfortunately this is often different than ATM's or the Internet. Characteristics like CLI, SIM certificates, phone and location based data are all available and should at least be catered for. A dedicated layer is the best way to harvest this.

The above factors are just some of the reasons why a separate mobile banking and payment channel is recommended in all serious installations.