Gemalto SIM STK

I found that Gemalto sell excellent development kits that allow developers to develop applications that run on SIM cards. These applications can be downloaded on the SIM cards and can perform powerful functions like intercept primitive radio messages and send data to other servers. Amazing stuff! Because these applications reside on the SIM card, they can run on any phone. No more special operating systems, and applications build for the Blackberry or iPhone only. The same application runs on all phones. Now any-one can build an application and download it on their SIM card.

Only problem is the cost ot the development software. Why do Gemalto sell the software? What are they thinking? Surely by distributing the software for free, more people would see the benefit and utility of the SIM card?

Top five posts

I track the visitors to my blog, thanks to Google Analytics. I can report that the blog is being visited, and (hopefully) read. With an average time of almost two minutes spent on the blog (yes, they can measure that), it does seem that some people find some of the entries interesting.

As part of the feedback that I get from Google Analytics, I get statistics on the blog-entries that are visited most. Although not a statistically big enough sample, I started keeping a record of my top five blogs. Those entries that have been visited the most during the past month. I thought that this may be an indication of what people are interested in. Well, here are the top five posts on my blog:

• Why SIM solutions are best for mobile banking (read here)
• Airtime as Currency (read here)
• Mobile banking in Africa (read here)
• Africa as mobile banking benchmark (read here)
• Important elements of mobile banking (read here)

I don't know what it means, but I thought it is interesting. Maybe I should write some more about these topics...

m Commerce management

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

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

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

Mobile Channel Access Layer

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

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

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

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