Regulatory considerations

Let us agree that, even though some of the functions are very similar to other types of banking, mobile banking is different. For a start this is the only type of banking where you can enter your own PIN on your own secure device. It is the only type of banking where you can be informed of banking transactions and be asked to confirm actions at any time or place in the world, providing you have cellphone reception.


The question frequently asked is what is the regulatory implications of all of this? or.. does it impact regulatory considerations at all? These are very important questions and should be properly resolved prior to deploying any solution. It is far better to ensure Central Bank approval prior to launch than having to suspend a product launched in haste in order to get the regulatory dispensation in place. This is especially embarrassing when the product is particularly successful.


In considering regulatory issues four areas are important:

Deposit taking

The basis of banking anywhere in the world is the management of systemic risk. Central banks are primarily concerned of situations where an institution holds money on behalf of some-one else and then is not capable of repayment if required. Organisations that take deposits from consumers and hold it on their behalf forms the basis of banking and is carefully controlled. These organisations are usually called banks and must conform to Central bank's regulations (like strict reporting and capital adequacy considerations). When deploying mobile banking solutions the regulator must be consulted especially in instances where a wallet, or pseudo bank account is created or even in instances where clearing is a delayed process.

Know your customer (KYC)

One of the most difficult problems to solve in the provision of entry-level banking to low income people is the disproportional high cost of opening a bank account. Some of the regulatory prescriptions regarding KYC, if implemented according to the letter of the law, often kills the business case. It is important to consider the characteristics of the phone, the objective of the service and special dispensations often available in banking law to solve this problem in a legal way. The registration process and take-up procedure in many mobile banking solutions often contravene regulatory prescriptions. In many cases the solutions had to be suspended in others the Central bank accommodated solution providers by making small modifications to the rules. We at Fundamo are of the opinion that this work should be done prior to product launch.

Dispute management

One of the strengths of the existing banking world is the clear definition of liability. If you accepted a card payment without checking the signature, then you may be liable to refund the whole amount. Payment systems have been clearly defined to cater for situations like when your PIN has been compromised, when a card payment is accepted while the card is not present at the merchant, what happens if the terminal is not certified etc. etc. In many instances the rules usually applicable in the classic world can not be applied as is for mobile initiated transactions. Liability and dispute mechanisms must be re-developed, tested and then applied. These rules should conform to laws and existing relationships between banks and clients. It is not trivial to adjust these rules for mobile payments/banking, but critical to ensure that disputes can be managed accurately.

Clearing and settlement

Many countries have promulgated advanced electronic payment laws. These laws prescribe regulations regarding the clearing and settlement of transactions between banks. When implementing mobile banking solutions, it is critical to consider these rules carefully. Considerations should be given to the legal implications of aggregated settlement and/or nett settlement designs. The need to be a member of or even the establishment of ACH's must be considered carefully.


Regulatory considerations is not trivial and differs from one country to another. It is best to contract experts in this space when deploying mobile banking solutions. The small additional cost is not even closely comparable with the potential risk and loss of income that may accrue to a customer if regulatory mistakes are made.

Back Office

Much thought is being given on how an end-user will interact with a mobile banking system. Many a debate hinges on the channel required, how the system will be distributed and how the functionality would work. What is sadly lacking though, is a quality debate on what happens in the back. This is often the most important element in insuring a workable (and legal) deployment - one that can be backed-up by reputable companies and that can deliver sustainable solutions to customers.

In evaluating back office functionality, a number of factors should be considered without which a solution would not be viable. We at Fundamo and our partners pride ourselves in our experience in many of these aspects. It is critical to work with experienced professionals to ensure that a sound, auditable and legal service is delivered to end customers. Operators should select solution providers with suitable experience and systems that are able to provide solutions that can be deployed in commercially viable instances:

Integration considerations
Unfortunately no solution is an island, and neither can mobile banking be deployed without due consideration of many different integrations that can be required. Some of the key integrations that are often required are: integration to existing bank accounts or credit cards, integration to clearing streams or switches, integration into infrastructure (like ATM's or POS's), integration into mobile infrastructure and integration into third party service providers (like bill providers or ticket vendors). Each of these integrations are often complex on their own, but to ensure a consistent integration architecture can be quite challenging. Fundamo technology ships with many pre-packaged integration tools.

Regulatory
Banking laws are different from one country to another and are often strictly enforced. A keen understanding of the implications and the options possible to cater for deposit taking, KYC and conformance to clearing and settlement regulations are important. Some of the deployments that we have been involved with can be quite challenging as one will have to consider novel schema's like push clearing and aggregated settlement. In instances where deployments span more than one regulatory domains (like in the case of money transfers), regulatory conformance is even more difficult.

Scalability and Recovery after disruptions
The banking world and telecommunications are very different in many ways. The typical transaction volumes experienced in the telecommunication industry is of an order of magnitude bigger than what is typically expected in banking. This in itself is a major challenge. It is just not possible to plug a phone into a banking system. This is almost like connecting a fire hydrant to a hosepipe. Something is going to break somewhere. The design required to ensure that transaction peaks can be managed should be built into the system from the start, but more important, functionality and capability to deal with disruptions and to be able to recover from disruptions where tens of thousands of pending mobile payment transactions must be resolved should be available.

Support for administrative staff
Back office business processes must be supplied with a working system to ensure an effective deployment. Administrative staff must have the ability to authenticate a customer (in a call center environment) and must have the ability to serve his/her requests. Financial staff must be able to evaluate performance, profitability and be able to post journals or raise interest or subscription fees (if applicable). All of this must be done in such a way that fraud is limited by means of role management and security mechanisms like dual authorisation etc. Systems without support for functionality like this is just not good enough. Systems should also generate suitable audit trails.

Commercial support
The importance of billing engines for mobile banking is often ignored. I have seen production deployments that do not have the ability to charge the customer (or merchant) for transactions that is being performed on the system. Capability like fee management, risk management and least cost management are critical to ensure a successful commercial deployment of a mobile banking system

The Mobile Banking Concept

The lifespan of all good ideas can be broken into five phases: concept, prototype, pilot, pre-production, commercial deployment. Few ideas ever reach the stage of commercial deployment, because they are just not viable, or have been ill conceived or badly deployed. For some or other reason, mobile banking has been over-saturated with concepts and to some degree with prototypes. The idea of utilising the phone for financial transactions are so obvious that every man and his dog have developed a new concept or have submitted a patent somewhere. Everyone of them believing that they have stumbled on the ultimate approach.

The reality is that very few of these ever progress past the rudimentary prototype stage. And it is actually quite easy to demonstrate simple mobile banking functionality in a prototype environment. Some of the challenges that often have not even been identified and hence solved are issues related to integration, regulatory/legal and usability. These are sometimes addressed in the few prototypes that migrate to pilot.

A pilot usually consists of a few hundred, maybe thousands of subscribers performing transactions in a controlled environment with limited functionality. Even if pilots work, they often don't address important aspects like scalability and system responses to unpredicted actions or break-downs. What happens in the case of transactions that have been lost and how does the system respond to situations where a component is not available. Important legal aspects are also often not addressed yet at this stage. Pilots seldom uncovers the real system challenges and at best highlights key elements regarding user experience.

During the pre-production stage business processes and system reliability and robustness should be attended to. Many different business processes are required if a system is to be deployed in a production environment. This should include registration, dispute resolutions, service activation to name only a few. In examples that we have seen in the market some deployments have neglected key processes leading to very difficult deployments and disillusioned clients. What looked easy during pilot now turns out to be a nightmare of realities.

It is only when a solution is deployed commercially that they most important element of any idea is tested: Can it make money? Mobile banking solutions that are not profitable will fail ultimately. An this is where we at Fundamo can really contribute to making a difference in deploying successful mobile payment/banking solutions. We have seen what works and what does not. We have built powerful business modeling tools and have helped many customers to culminate with commercially successful deployments of novel ideas. We have seen many competing products fail because they were not commercially viable.

Why SIM based solutions are best for Mobile Banking

The matter of empowering the Bottom of the Pyramid is a challenge that many have attempted. We at Fundamo have been working on this challenge for the best part of ten years and you would agree with me, that nobody is a better teacher than experience. We deployed the first mobile payment solution on a SIM card during 1999 and have since helped many mobile operators and banks to enter the exciting world of mobile payments. Our technology has been deployed on most major networks in Africa and further afield.

Our technology and experience spans many different channels (ranging from simple SMS and USSD, to advanced deployments utilising Java and Internet Chat protocols), but by far our most popular solutions run on SIM cards. It is no doubt the best way to deploy financial services on mobile. We have a close working relationship with Gemalto in this regard, but our technology have been deployed on almost all serious SIM card manufacturers.

So why is SIM cards so important for mobile banking:

Ease of Use

The problem with our modern life is that we have to remember such a lot of things. Even if information is stored on a phone, one still needs to remember the name that it was stored under. One thing that I do remember is the PIN that I unlock my life with. If you cannot remember a PIN you are quite dead in the modern world, but you don’t have to remember much more.

Yet, many mobile payment solutions are based on remembering numbers to call or send Text’s to. One has to remember special acronyms and error codes, or then you could do with a quick-reference guide that you have to remember where you left it. Mobile payment solutions based on for instance USSD suffer other usability problems. For instance, the application cannot set an input field for numeric input only, or awkward key-strokes, like hit “YES” first before you enter info and then “SEND”. Java is pretty user-friendly, too.

SIM based solutions are by far the most user-friendly deployments. Our customers that ship mobile payment solutions on SIM cards report that between 80 and 100% of subscribers try the service, without any training or quick reference guides. It is intuitive, conforms to the phone paradigm that consumers are used to and pre-empt the consumer’s behaviors. I would say quite safely that SIM card based solutions score better than any other channel on the usability stakes.

Cost
I am thinking about this problem from a GSM operator perspective. What is the total cost of ownership for running a mobile payment solution for a mobile operator? Of course, a mobile operator could charge it at what-ever price they want – could even give it away for free for that matter, but it is important to look at the intrinsic cost to understand the profitability and business case.

• How easy is it to deploy the solution and what is the cost associated with this. Well, it is pretty expensive for any of the deployments, considering infrastructure that must be deployed. Java requires a lot of development to make it accessible on all phones on the network and USSD and SIM require back-office infrastructure, so pretty much similar I would say. I assume that the operator will be distributing SIM cards anyway, so I am not counting the cost of SIM cards. But if you do, this would increase the cost of a SIM based solution.
• Once again, I would say that Java and SIM are similar in the cost to transact. Java would probably run on GPRS connections and this is very low cost to the operator. SIM applications typically run SMS classII, but can also utilise GPRS and the cost is therefor similar. USSD on the other hand, hoard a voice channel for the duration of the transaction time (from base station to IN platform), and this is expensive, because one less voice call can be made.
• The maintenance of Java is extremely expensive. To ensure that the Java applet is compatible with all (and all new) handsets, can be quite expensive. USSD’s advantage is one just need to make changes on the back-office, whereas SIM based solutions will require OTA functionality if changes are to be deployed.
• The most expensive element is the cost of scaling. The problem with USSD (because it is a session based solution), is that it is expensive to scale. At a critical stage of increased usage USSD will fail unpredictably, because it is not possible to implement any queuing capability.

Security
Some people have told me that one does not need that high level of security and that good-enough security is, well.. “good enough”. I think the question is then, what is good enough? I thought a good indication of what is deemed to be good enough is a statement by the Federal Financial Institutions Examinations Council of the United States. All banks in the US must conform to two-factor authentication by December 2006 for electronic financial transactions.

Most banking solutions utilise at least two factors to ensure adequate levels of security. One of the best examples is the EMV standard, currently being rolled out globally by the large credit card associations. This is based on a smartcard (something you have”) and a PIN (“something you know”). It stands to reason that one should expect the same level of security to be deployed in mobile payments. Anything just based on a UserID and Password is just not acceptable. For a start, SIM-based solutions (if implemented correctly) is one of the best examples of dual-factor authentication. It utilises cryptographic keys in the same way that EMV does. Definitely score highest.

USSD transactions can (at best look like dual authentication) and suffers many security short-comings. It is literally a single-factor deployment with big holes for “man-in-the-middle” attacks. Java applications can digitally be signed and could mimic dual factor solution, but is an ideal candidate for “Trojan horse” attacks.

Ubiquity
This is probably the most contentious topic. It is correct to understand that USSD is available on more phones. Although one should recognise that not all networks support USSD Type II (which is often required for mobile banking application support).

Java phones are not yet that widely distributed (especially in developing markets) and a Java application, running on one phone is often not portable to another. That brings us to SIM-applications. SIM solutions require a SIM card capacity of at least 32k, with appropriate keys loaded. The penetration of suitable SIM cards is higher in some markets than in others, but surprisingly high in many markets. In markets that we have worked in (Nigeria, South Africa and Middle East), the penetration of suitable SIM cards is closing in on 100%. Consider the massive churning in most markets and the rate at which SIM’s are replaced (especially in pre-paid markets). Within a few months of a firm decision to distribute suitable SIM cards, operators will have a sizable market of SIM cards.

Strategy
It is difficult to understand specifically what is going to happen in the future, but one thing we know about GSM: we are going to have SIM cards. SIM cards will be different with more capacity and higher transport protocols, but they will still bear the identification of mobile telephony. It would be easier to store information on High Capacity (HC) SIM cards, more complex routines would be able to run on the platform and communication to the SIM card from the network would be easier. As a matter of fact, the Java functionality and SIM capabilities will merge with deployment of the JSR188 specifications. Deployments utilising NFC technology will require the flexibility that SIM card-based systems require. As a matter of fact, when Visa piloted their NFC solution with Maxis in Malaysia, a critical component of the solution was a SIM-based application on the phone.

New SIM cards will enable more secure solutions with high likelihood of deploying PKI and Sandbox concepts as a given. This will enable much, much more advanced solutions than is currently possible or that can even be envisaged. Mobile Operators with the vision to embrace SIM technology, will be so much better positioned to experience the benefits.

USSD technology, though important will probably not develop further. The management of dynamic menus and handsets that operate more effectively with USSD commands will be developed, but it is unlikely that any strategic advances will benefit USSD-based transactional solutions. As far as strategy is concerned USSD is a cul de sac.

The question to ask (I believe) is: In a world of interoperability where one operator will allow another to send money to them (and vise versa), what should the minimum requirement be? Would you be happy to accept the risk of a lower security deployment at another mobile operator? Or should the industry decide on what is acceptable risks?

The important elements of Mbanking

What is important about mobile banking? What makes it successful? How do you judge failures? These are all critical questions in approaching mobile banking projects and deployments. To answer any of the above questions, first answer the following question: "Is the service being used?" If people are using the system (preferably voluntarily), it is most probably addressing a need or making life easier for the subscriber and this is the single most important driver for a successful deployment of mobile banking.

So what make people use mobile banking? Not a lot of people around that can answer this question as not a lot of people have got people to use the service.

First of all the service must address a specific need - a reason for using the system (preferably regularly). This is not as easy as it seems, because it will have to change behaviour and people don't do this easily. Furthermore the reason is different for different communities and target markets. It takes skill and insight to get this right.

Second, it must be easy and fun to use. It must be intuitive and work... every time.

and Thirdly, consumers must feel that the solution can be trusted and is secure.When it gets to money, the average consumer is quite conservative. It is not about how secure the system is, but rather how secure it is perceived to be.