Friday, March 23, 2007

The economic benefits of mobile phones

In a recent report published by McKinsey's the value of mobile phones in developing markets is quantified. It is shown that the economic impact of mobile phones is significantly higher than the direct value to the mobile operators. This is because of a number of factors, but predominantly because of the productivity gains generated by users of mobile phones. The report then concludes that governments and regulatory bodies could amplify these gains by simplifying rules and deploying strategies to smooth the roll-out of mobile phones.

This report emphasise experiences that we have in developing economies where regulatory hurdles (and lack of capital) are the two most important factor that delay the roll-out of financial services on mobile phones in developing countries. Some of the regulatory questions that we often get confronted with are the following:
  • How does financial products relate to Know Your Client requirements?
  • Are special reporting and documentation required?
  • What are the responsibilities of the Mobile Operator? and
  • Can a Mobile Operator elect to block specific services on their (regulated) network?

Resolution of some of these questions have taken so long in the past that projects sometimes stop or turn into marginal projects. It is the interest of all (including governments) that regulatory dispensations are made lighter and the deployment of mobile based solutions are made easier.

In this regard the work that CGAP and the Worldbank is doing to make recommendations to streamline the regulatory dispensations should be commended. We at Fundamo are in full support of their efforts and contribute as best we can to help establish a facilitating environment for mobile banking and services.

Sunday, March 18, 2007

Co-operation or Exclusivity

Two totally different initiatives in the US this quarter related to mobile banking is of special interest. Two companies have launched (or rather announced) two initiatives that is diametrically apposed in terms of the underlying strategy.

Firethorn announced an agreement with Cingular where the Firethorn Java application will ship with every Cingular mobile phone. Revenue generated via mobile banking and payment transactions will be shared with Cingular and in turn, Cingular will effectively block (or at least make it difficult) for other suppliers downloading their own proprietary Java applications onto Cingular handsets. Firethorn is confident that they will conclude similar agreements with other mobile operators soon. This is a totally closed and proprietary approach. Will it work?

Obopay is a service provided to any person with a mobile phone. A subscriber to Obopay is able to download a Java application to any mobile phone. This enables a subscriber to transfer money from any Obopay customer to another, do some rudimentary payment and enquiry services and withdraw cash or pay (using the obopay pre-paid (debit) card) at ATM's or POS's. The importance of this approach is that it is totally "open" in the sense that it is suppose to run on any mobile operator and work on any ATM. This is of course the most logical way given what happened in the past with the Internet economy... but is it the logical way in payments and banking?

It would be interesting to be able to roll forward in time to understand which of the two approaches win, as it will tell us a lot about the power balance in mobile banking. Consumers are of course very important. It is their decisions and preferences that have catapulted small companies into the limelight in the Internet economy. But, then, the Internet is much more open than is the case with mobile (at least at this stage). Mobile operators have much more control over what happens on their handsets and their network. As a matter of fact, Cingular have indicated that they do not see their network as an "open network".

So what will happen? I believe that the role of banks, their ability to take their own decisions and stay in touch with their own clients will play a mega-role in which model wins. Not only banks per se, but also other organisations and bodies in the banking domain. It would be interesting to track what VISA, Mastercard and clearing switches (like Swift) do, as these organisations will ultimately influence who will win.

Thursday, March 15, 2007

Content and Mobile Payments

Today content on mobile (ringtones, pictures, etc) are mostly paid for by utilising the billing systems of the mobile operators. This approach is probably the only mechanism that allows content providers and mobile operators to effectively collect the millions that is spent on this industry every month. Unfortunately, utilising the billing system to collect for non-telecommunications (and especially ad hoc) services leads to many problems:
  • The billing systems are not effective mechanisms to collect payments. In other words it costs a lot of money to collect what is often small amounts. This is because of many factors, but primarily because of built-in distribution costs in the collection of the value in the mobile phone accounts (independant if it is pre- or pos-paid). It is expensive to collect the money in these accounts because of the established commission structures.
  • Billing systems are not geared to cater for effective management of disputes. This also means that it is expensive to deal with complaints for content services that consumers lodge.
  • Payment activation by the consumer is also often cumbersome and often different from one service to another. (For instance, send the following code via SMS to the following number, or enter the code that we sent you via SMS on a WAP session or the Internet, etc etc.)

This situation will get more complex and problematic in future as more sophisticated content services are being invented and delivered to subscribers. Mobile TV and other services based on broadband is a case in point.

Mobile payment schema's offer elegant solutions to solve the problems listed above. This is because it is possible to provide much more cost-effective payment solutions as well as proven rigid and intuitive support for disputes and complaints. The ability to give immediate feedback on payment activity also adds to cost-reduction and customer satisfaction.

Thursday, March 08, 2007

GCash in other Markets?

I have absolute respect for the results that have been achieved by dedicated people in the Philippines to deploy excellent solutions. In many ways the solutions deployed by Smart Communications (Smartmoney) and Globe (GCash) have set benchmarks for other organisations to follow. Recently, GCash started a concerted drive to bring GCash in the same or similar format to other markets. I believe that the implications and challenges associated with this should be highlighted.

GCash is a Structured SMS, predominantly closed payment solution, focused on a large under, or un-banked population in the Philipines. It provides for the creation of an electronic wallet that some-one can access with their cellphone by sending "code-words" in open SMS commands. The solutions security is based on a "M-PIN" (that is often stored on the cellphone in the open), limits in terms of transactions and the local Philippine Identity document. The operation in the Philippines is connected via participating banks in many other countries. These banks provide a mechanism for people in these countries to send money to electronic wallets in the Philippines. It must be noted that these banks do not operate e-wallets, nor are the G-cash functionality available in these countries.

The problem with proposals to deploy GCash in other countries (as it was done in the Philippines) are the following, and prospective clients/partners, should consider these carefully prior to engaging with Globe:

Regulatory complexities
The GCash deployment as is currently deployed operates under a special Central Bank dispensation (resolution 116 of 2005). Although the Central Bank of the Philippines should be applauded in giving the regulatory backing for a very good solution, this is not a given in other countries. As a matter of fact, it is most likely that this dispensation would not be given in many countries as the situation is totally different from one country to another. In regulating banking type solutions, a Central Bank should consider specific market realities, the potential risk, impact on other players etc. To assume that, because the Central Bank of the Philippines have allowed a GCash solution, other Central Banks would do the same, is a big folly. One should also take cognisance of the role, strength and maturity of banks in other markets and their right to objecting in other markets.

The role of banks (and Credit Card Associations)
The relative strengths and ability to innovate of banks in relation to mobile operators differ significantly from one country to another. The Philippine market with two very strong and innovative mobile operators is not a blueprint for every market. As a matter of fact, this is probably quite unique. It is our experience that one should consider a total eco-system of payments when deploying mobile banking. Banks in general will not allow a Mobile Operator to deploy a GCash type solution without a strong (and often effective) reaction. Participation by banks to send money to GCash in the Philippines should however be supported and banks should consider participating and assisting GCash in this way. (This should not be confused with deploying a GCash type solution in country)

Support considerations

It has been shown over and over again that remote support of technology solutions is something totally different to operating a solution in country. The fact that GCash is being operated successfully in the Philippines does not mean that it can be replicated into another country. As a matter of fact this is highly unlikely. The skills required to support and maintain multiple different technology solutions, in different time-zones with different languages, require a totally different organisation, set-up, managed and organised in a totally different way. We at Fundamo for instance, have well defined support roles, service levels measurements and escalation mechanisms in place. The version management of our software is carefully documented and controlled so as to ensure that we know exactly which version of which module is in production with which client. Evaluating operational excellence does not say anything about ability to provide technical support.

Security dispensations
It is unlikely that the security dispensation deployed at GCash will be acceptable to other markets (and specifically to mature banks). The fact that the M-PIN remains resident on the phone after the SMS has been sent, that the M-PIN is often in the clear will not be acceptable to many banks. Security management that is heavily dependant on the availability of a general Identity Document can also not be deployed in many countries where this is not the case.

Consumer behaviour
Philipino’s are famous for their SMS ability. Manila is often referred to as the SMS-capital of the world. The willingness and ease with which Philipino’s adopted a keyword paradigm based on open SMS’s for mobile payments will not necessarily be replicated in other markets. It is our experience that (especially when payments and money are involved) that consumers requires usability one level up from SMS’s. Prompt’s like “Are you sure”, more intuitive inputs and online support (like “invalid account number”) are critical to ensure adequate adoption. Porting a solution that works in the Philippines “as-is” without due consideration of consumer behaviour cannot be recommended.



Even if a client is interested in deploying a GCash like solution (e-Wallet, with an exemption from the Central Bank), a solution provider should be used with a track record in deploying solutions in different countries and time-zones. We at Fundamo have relevant expertise, an understanding of different behaviour in many countries and the ability to deploy legal solutions given different central bank dispensations. It is important to deploy mobile banking solutions with a proper understanding of local realities as well as what is possible with technology.

Tuesday, March 06, 2007

The Economics of Mobile Banking

The truth of the matter is that mobile banking can only be successful if it makes business sense in the long run, and that means business sense for most (or all) stakeholders. Obviously this is only going to be possible if mobile banking can lead to more efficiencies that can be translated into direct benefits. Fortunately (for people like me working on mobile banking solutions) improvements in efficiencies are easy to demonstrate: replacement of expensive cash systems, improvements in back office processes, removal of the constraints of time and place (meaning people don't have to travel and stand in queues) etc. All of these things lead to direct benefits to participants in the mobile banking eco-system.

The challenge is is two-fold: To demonstrate this to potential investors in mobile banking solutions and to ensure that the ultimate solution does not have an economic barrier to one of the stakeholders:

Demonstrate the benefits
It is important to be able to build suitable business models to demonstrate that a positive business case exists. We at Fundamo have refined our approach to this having worked in many markets and different realities. We have build powerful business modeling tools and have learned that models should take cognisance of the different realities from one country to another. They key is to start with the different sources of revenue to prospective investors. These are typically the following: subscription, transaction fees, treasury benefits, interchange fees, commissions and cost savings. The contribution of each differs significantly from one scenario to another.

Ensure all participants benefit
I have seen other solution providers in this industry making fatal mistakes by deploying solutions with impossible cost barriers. These barriers implies that it is impossible for one of the participants (say for instance the mobile operator) to support the initiative in the long run. In some instances it is assumed that the subscriber would be prepared to pay more for almost the same service. It is therefor important to evaluate the proposed mobile banking solution from the perspective of all participants in the solutions eco-system. Every-one should get a slice of the revenue or benefits, enough so as to entice them to make behaviour changes.

Friday, February 23, 2007

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.

Wednesday, February 21, 2007

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.

Monday, February 19, 2007

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?

Monday, February 05, 2007

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.

Wednesday, January 31, 2007

Mobile banking a target for criminals?

The Tower Group recently produced a report highlighting the danger of mobile banking and how criminals will now start to target mobile banking users:

"The success mobile banking and payments, as well as the concept of the mobile wallet, will be measured against the industry's ability to effectively contain the malware problems to a level that is at least on par with that of the existing Internet channel", said Bob Egan, Chief Analyst at TowerGroup and author of the research.

Of course analysts must prove their worth by coming up with new thoughts in order to sell their reports. To label some of the ideas presented as "absurd" would be to complement the analyst. The best case in point is the fear created in humankind about the "Y2K-problem". This will probably go down in history as the biggest analyst scam ever.

To be able to write a full report on how criminals will target mobile banking users by means of "malware", is not on the same scale, but falls in the "Y2K" category. Sure, bad deployments of mobile banking solutions (especially if it is a porting of an Internet banking site onto a browser on a phone) may be exploitable. This is definitely possible, but will only be applicable if mobile banking was implemented without due consideration of state of the art techniques and by contracting professionals.

Because of the nature of mobile phones and the design available to specialists in mobile banking, it is possible to deploy mobile banking solutions that is more secure than any other means commercially available today. As a matter of fact, we at Fundamo have deployed the first three-factor authenticated banking solution commercially (it is being used successfully by a major bank). This means that a customer interaction is authenticated on "something he/she has" (the SIM card in his/her phone), "something he/she knows" (a PIN that is never in the clear), and "something he/she is" (a digital voice print).

In a recent test, we gave access to a professional hacker to a test environment running Fundamo software. The conclusion was that mobile banking (implemented correctly) is "un-hackable".

Mobile banking a target for criminals? - you be the judge.

Saturday, January 27, 2007

Interchange Fees

Interchange fee is an interesting animal. This is the fee that flows from the payer's bank to the payee's bank (or in the opposite direction). This is supposedly to cater for the "imbalances" of capital required to build the payment infrastructure. This is a remnant of the past where the cost of a POS and an ATM (and the maintenance of this equipment) was expensive. Nowadays, with everything turning more and more into electronic on-line transactions and where transactions are running off personal devices (like mobile phones), the capital cost for the banks have just about disappeared.

It is therefor interesting that a number of regulators are considering the impact of interchange fees. See for instance (http://www.finextra.com/fullstory.asp?id=16433, and http://www.mg.co.za/personalfinance/articlePage.aspx?articleid=290403&area=/personal_finance/pers_fin_banking/)

The question is: When will the cost of leveraging the interchange fee be bigger than the actual fee? This would be the time to totally abolish interchange fees, and maybe the time is near?

Friday, January 26, 2007

More secure Internet Banking

"A recent survey of nearly 1700 customers in eight countries found that the majority of account-holders - 82% - want banks and brokerages to monitor online and telephone banking transactions for suspicious activity - similar to the way that credit card transactions are monitored.

Furthermore, a masssive 91% are willing use a new authentication method, beyond the standard username-and-password procedure, if their banks decided to offer stronger security. Over two third of respondents (69%) say banks should replace the standard username-and-password log-in procedure with stronger authentication."

This is very encouring and shows an awareness in consumers that Internet banking is not as secure as they would like , but more important that they would be happy to use a more secure mechanism for Internet banking. Of course, the challenge for banks is how to do this effectively. The only way to really increase security is to distribute "something" to the client: either a random number generator, or a once use password booklet, or a digital certificate stored on something... and this is going to be a costly exercise.

The most obvious way to distribute a secure digital certificate is by means of mobile phone distribution channels. The SIM card in GSM phones is an ideal vehicle to distribute digital certificates. As a matter of fact these certificates have already been distributed in many markets.

The Fundamo mobile payment technology has been designed to make use of these digital certificates, not just to increase the security of mobile banking, but also Internet banking.

Wednesday, January 17, 2007

Mobile Banking Profitability

Notwithstanding the fact that banks operate much the same way in different markets, it seems that some banks (in some markets) are just more profitable than others. Banks issue credit cards and provide loans (usually at a healthy interest differential to the Central Bank), banks finance cars and homes and support payment systems. Yet, the profitability of banks in some markets are just higher:

For instance Korea: "Encouraged by record-breaking third-quarter earnings at South Korean banks, analysts expect profits there to grow strongly into 2006. www.investors.com/editorial/IBDArticles.asp?artsec=23&issue=20051202 ,

Or South Africa: "Banks profitability increased significantly from already healthy levels in 2003" IMF Worldbank www.imf.org/external/pubs/ft/scr/2005/cr05345.pdf

I was looking for a reason, when I realised: mobile banking penetration is big in both Korea and South Africa, and people actually use it.

Mobile Banking Satisfy People

One of the markets with the highest penetration of Mobile banking is South Korea. The usage of mobile banking services provided by most banks have seen unpresedented growth during the last two years (both in terms of number of subscribers and transaction volumes). It seems to be a good market to review the satisfaction of consumers with mobile banking.

In a recent survey conducted in Korea, looking at convergent services on mobile (Mobile TV, Location based etc.), consumers were by far more satisfied with mobile banking than with any other service. The article conclude in the following way:

"The survey, based on 110,455 mobile users, also said that mobile users are generally satisfied using mobile banking service as only some 10 percent showed negative reactions.

``Consumer satisfaction levels are considerably higher for mobile banking than those for other mobile convergence services. If security and convenience are provided, the future of the mobile banking market looks bright,’’ said Kim. "

times.hankooki.com/lpage/biz/200512/kt2005120...

This finding is of particular importance in markets where mobile banking deployments have lagged, and banks and mobile operators in these markets should consider the deployment of suitable product to focus on providing in the need of consumers.

People want Mobile Banking

Two surveys conducted by well-known research firms indicated that Britians would want to use mobile banking, if it were available.

The first survey conducted by Forrester Research on behalf of Meridea, surveyed existing online banking users aged between 16 and 34. Some of the interesting findings in this research indicate that more than half of the survey sample would try such a service. Even more interesting is that almst a quarter of the surveyed sample would consider SWITCHING their bank if it did not provide mobile banking! (www.vnunet.com/vnunet/news/2147681/mobile-ban... )

The second survey conducted by the Henley Centre on behalf of BT on a sample of respondents aged between 25 and 44, had similar results. The survey found that more than a third of the respondents would like to conduct their banking by means of mobile phones. The study also indicate the types of transactions that consumers would like to conduct by making use of their mobile phones. (www.finextra.com/fullstory.asp?id=14667 ).

These two studies indicate the growing consumer demand for mobile banking services. In both of the reports conclusions indicate that banks must expect this demand to grow into the next year.

Monday, January 08, 2007

Danger-signs for Chip and Pin



It did happen. Some-one did the obvious and showed the inherent weakness in the design for EMV. This "foolproof" payment system can easily be hacked by tampering with the Point of Sale in the hands of merchants.

Researchers at the University of Cambridge have shown how a terminal designed to read an EMV card can be modified to play Tetris with. They have made a video of their work and have posted it on YouTube. See article.
What is the relevance of this? Well this means that some-one can change a terminal to capture your card information and your PIN when you enter it onto some crimally minded merchant's terminal. This may not be a big issue in High Street London, but take the concept to developing economies and the challenges is almost unsurmountable.
If you are however prompted to enter your PIN number on your own phone when you make a purchase, this problem goes away. Mobile payments are so much more inherently safer.

Wednesday, January 03, 2007

The role of Banks and Mobile Operators

It is like wondering if Alcoholic Bread should be baked or brewed. Mobile banking is a similar contradiction in terms. Examples exist of both banks and mobile operators making huge successes of mobile banking. MTN Banking is an initiative with a clear mobile operator branding, whereas Celpay is owned by a bank and have clear banking characteristics.

The fact of the matter is that the aims the approach and the structure of mobile banking differs significantly if provided by banks or mobile operators, but the important fact is that both are capable of deploying mobile banking succsesfully. In considering mobile banking and the role of banks or mobile operators, one should take the following into account:
  • What market segment is the target market (people with mobile phones, but no/little banking exposure, or people with bank accounts looking for additional access channels?)
  • What revenue models is supporting the initiative (how large is the telecommunication revenue in support of the business case?)
  • What are the secondary objective of mobile banking (Retention of marketshare, or brand enhancement or the basis for other services?)
  • The maturity of the banking industry in the specific country/marketplace
  • The banking support and infrastructure (electronic clearing, ATM's etc)
  • regulatory considerations. Dispensations exist in some countries to support electronic money payment systems from a regulatory perspective, for instance.
With the above in mind, it stands to reason that it is impossible to have a one recipe for all mobile banking deployments. It is important to consider different factors before embarking on a course of action.

Friday, December 29, 2006

End-user experience

A mobile phone is completely different to the Internet (as it is accessed via a PC). The difference is in terms of the charateristics of the device, the behaviour of the people using it and when and where and by whom it is being used. It is important to consider all of these factors when developing mobile banking solutions.

A mobile phone is different because of a smaller screen, a different keyboard and no (or sometimes an akward) pointing device. So when designing software for mobile phones, one must take these constraints into considerations. Solutions with a lot and superfloues input will not be successful. Many different keystrokes and inputs for exceptions is not a good idea. It is much better to try and deduce values than to expect entry for every value. (For instance, we assume that one primary bank account is associated with one mobile phone and does not require a client to enter a bank account every-time. Not only is it easier to input, but actually more secure - if you think about it).

Another thing to consider is when and why people would want to use mobile phones. Where the Internet works well to browse and to collect a lot of information (for instance when you want to perform a share trade and graphs and information about previous transactions are important - it is probably more suitable to perform these transactions via the Internet). On the other hand people tend to use mobile phones to do a specific transaction only (send a text or make a phone call). Banking transactions in this mould is therefor ideal candidates for mobile banking. (We tend to offer different types of payments of the ability to purchase stuff as typical banking features on mobile phones).

Also consider the typical mobile banking customer. This person often don't have access to the Internet, is very capable in using the mobile phone, but is also time and cost sensitive. It is important to design banking transactions with these customers in mind. Easy to use, low cost, yet powerful and quick transactions are typical candidates.

Wednesday, December 20, 2006

Mobile Banking Examples

This is the deal: You can have a new bank account right now. You don't have to go into a branch of a bank, fill in a lot of forms, send copies of your last three payslips or explain anything to any-one. You must have a mobile phone and be able to use the phone in the same way as if you were sending a text message.

This is what we have implemented for one of the biggest mobile operators in developing economies. MTN banking is a new generation bank that enable any-one to open a bank account directly on a mobile phone. Oh, you would say this is a play-play bank account. Yet, this is a fully flexed with all functionality bank account. Some of the features that the bank account provides for is the following:

a. A Mastercard credit card linked to the bank account with the ability to withdraw cash at an ATM or purchase goods at any Mastercard outlet.
b. Full EFT capability to enable debit orders and batch payments into the bank account (including SWIFT transactions). You could get your salary to be paid into this account for instance.
c. Full (and advanced) Internet banking where you could move money around and check statements any place in the world. You could also do advanced things (like schedule recurring payments etc.) However, you would need your mobile phone to log into the bank site.
d. On the phone you could send money to any-one else to their existing bank account, their phone or their credit card (in real-time) and with immediate confirmation via text message.
e. You could switch your card on or off via your mobile phone. Amazing feature if you have lost your card and then found it again.
f. By using the phone you can send statements to any fax machine or authorise your personal information to be faxed to some-one (for instance to authorise a debit order with a company)
g. You could pay bills, purchase airtime and pre-paid electricity directly off your phone.

New generation banking, made possible because of the unique characteristics of the mobile phone, already deployed and utilised by more than a 100 000 subscribers. Go and check it out www.mtnbanking.co.za