Administration Module

It is actually relatively easy to demonstrate a mobile banking transaction. To connect a phone channel to a banking system and to demonstrate the transaction being initiated by a phone subscriber is by far the easiest problem to solve in mobile banking.

Far more complex but much more important is to also provide robust administrative support for the mobile banking solution. This is an essential component to deliver a commercially sound and a production ready mobile banking system.

In evaluating a deployment ready solution one should expect to find the following components in a well designed Administrative module:

• Support staff access is important as it is probably the biggest risk factor in the operations of the system. Statistics have shown that fraud is more often perpetrated by internal staff and the exposure is also much bigger. Well-designed systems should cater for defined responsibility matrix, with segregation of duties. Techniques like dual authorisation, limits and exception reporting should be available. Proper logging of support staff activities is important so as to ensure that activities can be tracked and audited.
  
• Most of the administration activities are made available by means of suitable procedures. Systems should support standard procedures and workflow for the key functions (like registration of a new subscriber, renewal of a PIN, reversal of a transaction to name a few). In addition the workflow component should be flexible enough to accommodate changes and to add new procedures.
  
• The tasks within the procedures should include Client support functions that would enable a client support staff member to handle queries, set new limits, change personal information etc. Support should be given to search the data by means of surnames, identification numbers etc. in addition to mechanisms to authenticate clients.
  
• Administrative support could include the ability to raise interest and fees. To run reconciliation tasks, to change system parameters or to send communications to support staff or clients.
  
• The availability of Management Information is critical not only to be able to operate a mobile banking system effectively, but also to be able to improve the service.
  
• A well-designed system should cater for External administration functions. This would enable third party suppliers to possibly register clients or to pay commissions. It is preferably to have a defined interface to build customised access to the Administrative functions.
  

Administrative support is often delivered as an afterthought, or not based on a well-architected design. It is often inflexible, limited in its functionality, open to mis-use and expensive to change. It often does not provide sufficient management information support or caters for the exceptions. One should evaluate alternatives carefully on the basis of their administrative support, as this is usually the most expensive element to add or modify later.

Transaction Manager (Part Two)

The challenge with the development of a Mobile Banking transaction manager is to consider the following unique realities of mobile banking:

• It is likely that the system will have to deal with much more transactions than would be expected from traditional banking systems. Remember that millions and millions of people have mobile phones and they just might want to access their banking at the same time
• The different systems that mobile banking have to integrate to (Telecommunication Infrastructure, Pre-paid top-up billing systems etc.) are often not as stable (or sometimes as available) as what one would expect from financial systems.
• The behaviour of cell-phone users reflect an expected immediate feedback. If they do not get a response within a few seconds, they would typically send the request again. The transaction manager must be able to deal with this kind of behaviour, without compromising integrity.
  
• Security paradigms that can be implemented on mobile phones are not necessarily compatible with what is required for financial systems and this must be mapped somewhere

In looking at the design considerations for the above, it is clear that a synchronous architecture would probably not be able to deliver on these requirements. A transaction manager that has to keep thousands (if not millions) of transactions open while the transaction is completing would not be able to handle surges in requests, nor will it be easy to tune or scale such a system. The correct architecture (without a doubt) is a message based architecture.

Mobile banking solutions are often deployed without proper consideration for the transaction manager. Often mobile banking is bolted onto the Internet Banking functionality. This works great during pilot and initial production deployment, but starts to fail dramatically when the solution experience massive take-up (subscribers or transactions). Such conditions are then often aggravated when one component in the eco-system starts breaking or suddenly is not available. At that stage it is often too late to change.

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.

m Commerce management

This is one of the most tricky elements of mobile banking. This is where mobile banking systems integrate with mobile operator infrastructure and where the intricacies of telecommunications must be dealt with in such a way that financial transactions can be processed without losing accuracy. It is in this layer where a mobile phone number (or an identifier in the telecommunication world) is mapped to a banking number. The procedures for the establishment and maintenance of this link is often complex and should cater for many different scenarios.

A well designed mCommerce layer should also cater for risk management elements (like functionality available to specific profiles or daily and transaction limits). This is especially important in multi-channel deployments. This layer must be able to allow (for instance) a balance enquiry from a SMS channel with only CLI security but at the same time person to person payment with PIN encryption from a SIM Toolkit channel. In order to effectively be able to deploy this functionality proper mapping of profiles and access matrices is essential. This component must enable the operator of the system to present different options/menus to different people by making small parameter adjustments.

Often this component is grouped with the mobile channel layer (especially in the case where only one channel is supported or when the solution is inflexible in working with alternative channel providers). Grouping this component with the Channel management is often referred to as a wallet system as sufficient information must be stored to be able to process and route financial instructions to financial back offices systems. More than 75% of mobile banking vendors specialise in the provision of only these two components with at best limited features that could be classified as belonging to the remaining three components.

Mobile Channel Access Layer

The subscriber of a mobile banking deployment would interact with this component of the total solution. Depending on the deployment paradigm, the component may consist of application(s) downloaded to the mobile phone (SIM Toolkit or Java as examples), or in some instances would have no logic on the phone (WAP/xHTML or USSD deployments). This portion of a mobile banking deployment must cater for the user interface and manage the interaction with the subscriber.

Many different security paradigms can also be implemented ranging from security that ius only based on CLI (does the transaction come from the expected phone?), to advanced cryptographic solutions. Sometimes the security deployed utilise very innovative and unique techniques, and sometimes solutions are based on standard, tested security techniques.

It is virtually impossible to deploy this component without some logic on a hosted server in the back office. The hosted functionality must manage versions of deployed applications, as well as menu structures and expected responses. The hosted environment must be able to respond to error conditions (specific to the channel) and should be able to adapt to fault conditions (for instance when a SMS-C is not available or when response times from an application on the phone is slower than expected.

Typically solution providers favour some or other channel technology and their specific solution is based towards the channel technology. Thus, one finds that solution providers favouring Java based channels would have developed security, access management, user interfaces dictated by the functionality and characteristics of Java. It is extremely difficult to develop a channel access layer that is technology agnostic.

Mobile Banking Fundamentals

I thought that it could be worth my while to document the different components that constitute mobile banking the way that I see it. Many different views of mobile banking exists in the market today. These views of banking are often driven by the realities of different markets. It stands to reason that mobile banking solutions applicable in a London main-street bank and mobile banking in war-ravaged Congo will be different. But surely there should be some similarities. It must be possible to find elements of the same thing in both.

I do believe that mobile banking can easily be made up of five components. Every mobile banking deployment must have all five components. Some of these components may already exist in some instances or in others all have to be sourced (because nothing exists). In some instances two or more of the components are bundled together and are almost undistinguishable as separate components. Yet the following framework is a sound way to think about mobile banking. The components are:

1. Mobile channel access

2. m-Commerce management layer

3. Banking transactional manager

4. The value store system

5. Administrative support

In the next few blogs, I will describe each of these in more detail.

The story of the Nano and Mobile Banking

I have heard Mark make this comparison at the MWC in Barcelona and thought that it was very apt. Now I can point prospective readers to his blog to read it themselves: What do Tata’s Nano and Mobile Banking Share?

Premium SMS futures

I have often been asked why Operators don't drop the share of Premium SMS's, so that this is not such an expensive payment instrument. The fact of the matter is that they can't. Many cost elements are built into SMS's that must be recouped by the Operator and they just don't have the lee-way to discount more. One may argue that it does not cost the Operator anything to deliver an SMS from a technology perspective and this is of course correct.

But a review of the other cost elements (especially regarding distribution, billing and in-built inefficiencies), have created a cost structure that represents (according to my calculations) in the region of 25% of the amount billed to the customer. It is therefor impossible for the operator to reduce their portion of a premium SMS billing much below 30%.

As such, a premium SMS is a highly inefficient payment mechanisms (for the operator, the service provider and the subscriber). As a matter of fact, the availability of an alternative payment mechanism will benefit the total mobile payment eco-system. It would be interesting to see the development of this into the future.

The SIM is built in

As I passed through Heathrow on my way back to Cape Town, I saw this billboard. I have known for some time that Intel have built GSM support into their new chipsets and was waiting for the first products to hit the market... and here it is. Dell have built a laptop with support for broadband where-ever you are and this is a big advance.

But what is really exciting for me is the convergence of mobile payments with computers that this technology allows. A SIM built iin a mobile phone provides for an effective vehicle to distribute secure elements. Any serious payment solution with aspirations to provide bank robust payment solutions should be based on the usage of a secure element in some format or other. This is why mobile payments utilising SIM cards are so powerful and of course secure.

With on-board access of a SIM card in a computer, this opens the door for very secure payment solutions. It will be interesting if any announcements based on this architecture will be forthcoming.

Is this the year of mobile transacting?

I have now spent three days at the Mobile World Congress. I have met many people and have sort-of walked through all of the halls. I think that it is safe to say that this year no clear theme is dominating. In the past Mobile TV and Advertising was clearly the talk of the town.

I have found the many different mobile phones very interesting. Some of the models that were on show from iMate, Palm and Blackberry were interesting. Even Garmin have now produced a phone (designed to be a super GPS of course). Handset manufacturers from the east have also shown great handsets. I found the Viewby from LG to be the most interesting.

If a dominant theme were to be picked, then I think it probably would be Mobile Remittances. The workshops and presentations on this topic was hugely oversubscribed. Maybe this year is the year of mobile transacting.

Build your own

It is quite amazing that many operators have opted to build their own mobile banking solutions. Quite a few examples exists of which the mPesa initiative that Vodafone have rolled out in Kenya and have announced initiatives in Russia and Afganistan is probably the most famous. In a survey conducted by Edgar and Dunn recently, it was found that 48% of mobile operators are considering building their own wallet solution (rather than buying it). The question needs to be asked why this is the case.

It is an accepted fact that no reputable company would even think of attempting the development of their own general ledger system. This is just unthinkable. It would never be sensible to do this as it would be too expensive and too risky from a general auditability perspective. Yet Mobile Operators (with very little skills as banks), are contemplating building their own banking systems (because wallet solutions are for all considerations the same as bankings systems).

In thinking about this phenomena, I can think of three reasons why they would consider doing this. It could be that mobile operators think that they can build competitive advantages into the mobile wallet solution. This may be the case, but this will only be the case in the short term, when successful solutions will be copied by competitors. Another reason could be because of internal politics and based on the aspirations of staff members of the mobile operator.

Another reason could be that mobile operators are under the perception that no reputable mobile wallet vendor exists that are able to provide scalable, industry robust solutions. If this is the case, the wallet solution industry have a lot of work to do.

Explosion in mobile wallets

In a report released by Edgar, Dunn and company (under contract by the GSM Association) today, an explosion in mobile wallets is predicted. Based on solid research, the report predicts a growth from 10 million wallets today to more than a billion wallets by 2015. If this were to only materialise partially, this would be the biggest financial revolution in the history of mankind. To grow from almost nothing to a third of the world's population would be nothing more than miraculous.

The interesting thing about the research is that it was based on the opinion of market leaders in the mobile industry. Executives in mobile operators (representing 30% of the global subscriber base) were interviewed and the results were based on their opinions. Another interesting finding is that wallets based on and utilising elements of the SIM card is by a factor the preferred technology for the deployment of mobile wallets. See a previous entry in my blog.

NFC Science Fiction

In a recent Aite report it was found that one could expect only about 2.0% of merchants to have the capability to accept contactless payments in the United States. This would be the case after five years from now. Surely this is a HUGE stumbling block to even think of NFC payments as a remotely viable product.

If this information is correct, it is highly unlikely that any NFC product can be made commercially successful. Why would any-one consider walking around with a payment product that will only be accepted at 2 in every 100 outlets? The report also highlights the challenge of providing every player with a slice of revenue that will make it worth their while to deploy and push this infrastructure. It is almost as if every-one is working on NFC solutions when no problems exist that needs solving.

In my opinion, NFC payments is not a silver bullet. We all know the form of the hype curve. It is not difficult to judge where NFC is on this curve on the moment. Next phase: valley of disillusion.