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?