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.

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.

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.

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.
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?


Anonymous said...

If we can have a silicon that can work on any SIM, what do you think it will be the possible mobile banking solution? SIM Application via OTA? Any channel we can refer to to understand how can we devolop such solution? Many thanks, Edward @ ROCKEY

Hannes@Home said...

Thanks for your comments on my blog, Edward. We have been deploying SIM based mobile banking solutions since 1999. Our technology has been OTA'ed, ported, personalised on millions of SIM cards all over the world and we know exactly how to do it. I would love to talk to you if you don't mind sending me an e-mail to

Anonymous said...

Piggybacking on the SIM card requires a close relationship with the MNO's. Since mobile payment solutions are threatening their regime in regards to ex. premium SMS, how can this be done in a cost-effective and independent way, not paying the MNO’s loads of money to cover for their PSMS loss?

The case with Visa showing off their new things – it requires a new mobile phone for the users and (of course) a Visa card. Not independent at all – show how will this apply to the mass-market?

Hannes@Home said...

Anything that you do on mobile phones require a relationship with the MNO. Think about it: you have to plug into the network to send SMS's, to do USSD transactions. To work with a MNO and utilise the SIM's capabilities is not different in any ways.

The use of premium SMS's are extremely limited in terms of functionality and applicability. Just as a few simple examples: you cannot top-up your pre-paid airtime with premium SMS's, neither can you pay bills with it.

Anonymous said...

"you cannot top-up your pre-paid airtime with premium SMS's, neither can you pay bills with it."

Hi Hannes,
I kind of disagree with your comment above. Those can actually be done, and have been done.
As for USSD not being secure, i think it depends on how it's implemented by the providing company. The technologies you've compared in this blog entry can actually be fused together to produce very secure, and powerful GSM/CDMA mobile applications.

As for SIM based applications, i would not subscribe to it even if it can be OTA deployed. what happened if the SIM gets missing or breaks? The application goes with it. What if the user wants to switch network provider? He loses the service of the deployed application. I would rather go with java applications as they have proven to me to be the most scalable and user friendly.
My two cents
If you would a more detailed discussion on this lets chat on MSN as I've added you already. I am ''

or in 'Phones, Internet and Computers section' of the website below

Anonymous said...

I have a mixed opinion about using the intelligence of a medium to enable the M commerce. Sim based application have their own strengths and so does USSD and Java based applications.
The prominent aspect of a successful m commerce deployment is to provide three things.
1. Security
2. Convenience
3. Interoperability.
I think USSD gives more ubiqutousness and interoperability then the rest of the two mediums. It is also important as to what should be the level and cost of implementing security. If we allow small transactions over the mobile then one can do with the risk of using an USSD application.
Also let me know why we need MNO and why not we have a single platform that can act as a service provider rather than an application platform provider..

Hannes@Home said...

USSD is only available when deployed by the mobile operator an dmade available commercially. I would not call that ubiquitous... Many operators do not allow 3rd party applications on USSD (as it cannot be billed effectively).

USSD is a cul de sac for payments. If you don't like SIM cards, rather consider Java, Brew or WAP.

Anonymous said...

A SIM approach would not work globally.

DavidGoose said...

This guy understands nothing about mBanking.

Anonymous said...

Actually - your report on SIM based for Visa & Maxis is completely incorrect - the SIM based solution was & is still not today - ready for deployment - the deployment then was centred on a Java based application - how do i know this? because i was the Project Manager...

Anonymous said...

You have also left out the most important part of the discussion regarding SIM's & A/C data on the chip - there is not one SIM card in the world certified by the Banking world for supporting a Banking application..

Hannes@Home said...

The purpose of my blog is to trigger discussion and it seems as if this entry surely did. I appreciate all of the comments and value your contributions. As per some of the comments on the accuracy of my blog:
1. I based my comments regarding Maxis and Visa on a presentation made by Visa at Mobile Payments 2006 in Bangkok.
2. "not one SIM card in the world certified by the Banking world" is a bit of a difficult statement to substansiate. For a fact, my company (Fundamo) have deployed mobile banking solutions utilising SIM's certified by mainstream banks. The PIN entry on one of our deployments have been certified by Mastercard. (under PPID standards).

Anonymous, next time, why don't you identify yourself, as I would love to meet you and discuss many topics of mutual interest.

Simon said...

I am prepared to discuss further points of mutual interest with you as you have definately stirred up some discussion on some very interesting topics - i will email your hotmail..

starscriber said...


Correction ...

"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."

USSD is 100% control channel signaled. Only uses SDDCH (and Fast when on call). Zero TACH (traffic channel) in the mix.

On the air interface TACH is the limiting resource.


Playing on the "peripheral" is playing on the periphery. For critical mass adoption service has 2work out the box. And from user acceptance (sustained and repetitive use) standpoint the metric and litmus test is simply this: how does it stack up to making a regular phone call?

Java ... SIM ... USSD ... all fail on 2clix 2ubiqt.


Unknown said...

All... there is a big difference between mobile banking, mobile commerce and mobile PAYMENTS. if you are doing mobile payments, ask yourself: what is pivotal for me to use te service?
answer: simplicity (of signup and use) and universality. Speed, cost and security also register as important factors but the first 2 always win in surveys.
Startscriber had it right:
the solution must work out of the box and an it has to stack up well to making a regular phone call.
Java/IP, SIM toolkit, Wap, SMS just do not cut it. what's left is: USSD and Voice/IVR channels.

Everything else will not pass the "will my mother do it " test.

Anonymous said...

What if we can do away with telco dependency for a secured mobile financial transaction. Of course you did mention that we have to be plug to the network to enable the transaction. From my perspective telco should remain in their core business and facilitate the transaction. I also believe there is a suitable mobile payment business model for the telco to play a role. One thing for sure you can't play the game by being the umpire and the player at the same time.

Anonymous said...

Care to elaborate on the cul de sac of using USSD as the channel for mobile banking/payment.

Hannes@Home said...

Good point.
See my latest blog on this.

Unknown said...

Great ideas about the narrow aspect of the technology of mobile payment/banking etc. Specifically any solution that restricts the service provider or user to a single carrier is problematic. Remember these payment mediums are to replace cash/cards/ivr transactions. If you require restrictive control of the ability to spend freely you can not say you have an uptimized solution.Yes the SIM solution could have worked and have externsive implimentation but it does not mean that that is the best way to do it. In the my experience a lot of the banking and even telecoms executives are not too familiar with the verious technical options and what business model works well with which consequently a vendor with a good provile ( Marketing) always succeeds in putting solutions which are inferior or not the best to a captive market. I do agree that what ever the case you should plan on dealing with the carrier. I am very familiar with other carrier idependent solutions (SD,NFC,STK ondevice) which the carrier eventually frustrates becuase they want to be in the game and still be the umpire. I will go for USSD for it does exactly what the SIM will do only more efficiently and does not need any OTA, version control or maintain bank signed certificates. Speed of implementation and speed of execution can not be matched by any other solution. Very interesting comments.

Anonymous said...

Good writeup Hannes,I have been part of the Fundamo deployments in WECA countries and if there's one thing I appreciate most its the simplicity in integrating several channels and entire durability of the system.Good stuff.