USSD and Mobile Payments

It was  pleasure to meet online Johann Bezuidenhoudt, who is one of the authors of this great paper about mobile payments (Download here). A recent discussion on Hannes van Rensburg’s blog induced Johann to write a comprehensive response which I think is interesting by itself. With his permission, I am posting it here. 

I do not think that technological obsolescence will put SMS or USSD to bed for a good long while.

The reason being that the predominant portion of handsets that are being shipped worldwide do not do IP data.  Thus for the next while I do not think that the mass market will be able to use more than IVR, SMS, USSD and STK.

And these technologies when used in a fit-for-purpose mode work well.  Examples exist of this – such as USSD for top ups which are here to stay and as is SMS for notifications.  There is no reason why the payments space using these technologies should not stay too.

On the Security Side – from my involvement to date – I still think that there is a place for all the technologies.   The main issue is business fit for purpose.  And that the technologies will stay for a good while.

The paper (at www.finmark.org.za/documents/MBTechnologies_risks.pdf) also looked at the high end technologies (Use case 4) and is applicable across all the application spaces in Europe USA and the developing world. This was one of the intents when it was written, also the people interviewed were from all across the world.  It just so happens that the market for mobile FS is greater in the developing world, as in the developed world most people have access to PCs and are well served with FS   (case in point – look in Germany and most of the mobile applications that are being tried are small value payments).  What was however done in the paper was a careful look at the low end day-to-day payments models.  Here the amounts are low and the risk is manageable as suggested in the paper.  And I would go to far as to say that the acceptability of USSD risk to a consumer for day-to-day purchases in say the US is actually more acceptable than it is in developing nations – mainly because of the differences in the business environments, consumer protection and in relative terms the amounts involved are less catastrophic if a risk materialises in the US.  (also draw the parallel between the EMV rollout in Europe and the US – technology does not solve all risk issues).

The choice of technology should be made at the end of a business process namely:

Firstly sort out the business
-    What service do you want to deliver
-    What is the market structure that your product is going to be delivered in (operators and channels)
-    What is the cheapest way of getting it to your customer
-    How interactive must the service be
-    What vulnerabilities and risks must be catered for
-    What can the customer and the mFSP (see paper for defn) afford for channel costs
-    What the security requirement actually are (as opposed to “you do not get fired for buying IBM” and over-engineering is not a sin)

Then the technology choice starts
-    What handset the customer has
-    What acceptability the technology has
-    Whether the MNOperators are involved or not
-    What the budgets available for the services are and then what the platforms to deliver the services cost
-    Whether the technology is already provisioned and operative on the handset – and I await someone who can show me an out the box handset that works on IP data without provisioning and that the application space can be properly managed on (my WM6.1 device does not work on many of the SIMs that I find across Africa – and forget the US!).
-    Whether new technology has to be fielded to make the service work (ie hardware and or firmware) and whether the business model can support this.

If the process above is followed, and it usually happens more when a FSBusiness ie bank wants to add a mobile channel, then the technology choices have tended to go to the existing technologies.  When it is mobile operators involved they tend to go to the heavier technologies, not least because they often start at the bottom and work up.

I enjoy my STK banking accounts (and yes I have more than one at different providers).  I also have USSD access to some accounts, WAP and Internet.  I think that the long term judgements will be the business success of mobile payments and the technology that is used to deliver the services will be incidental.

Looking wider:  USSD and plaintext and combinations thereof are not the solutions for all things, and for that matter neither is the mobile.  When the values and risks go up then the costs of the end instrument become insignificant and such things as dedicated secure smartcards plugged into PCs (with HSDPA modems – which are not mobile phones but untethered network devices) then start to predominate.  The whole larger questions around security architectures and whether or not the person should be transacting huge values with devices in insecure environments and where the devices can easily be stolen or the user coerced then come into play.  Also biometrics is starting to become an important factor and the mobile space is a good few years away from that.

Another thing:  network capacity – the USSD services do use less node resources but more channel resources than SMS and especially when technologies such as S@T and WIG start sending multiple messages.  The other thing is that mobile network operators where USSD (and for that matter SMS) usage is extremely high – simply dimension them differently and put less voice channels in and more signalling.  I have yet had to find an operator who has had to build additional network capacity in (excluding the USSD/SMSCs) because the financial services on their core network and radio portions have been overloaded by the service – I wish I could as they would have a steaming financial service offering!!!  In the analyses that I have done:  Call-me, airtime balance enquiries airtime loads and airtime transfers greatly outweigh any financial service transactions, and the operators manage these just fine.  The optimisations were done a long time ago when they moved their pre-paid subscribers off IVR based calling and token loading which is network resource intensive to USSD loads and enquiries.

Mobile Wallets

Mobile Payments, Including the Use of USSD, Are (Somewhat) Explained Here:

Mobile Money Transfer Explained, Part 2: Mobile Wallets

  February 2008

LONDON, UK — Mobile money transfer is the hottest topic in mobile payments now. Pilot programmes and commercial launches are being announced seemingly on a daily basis. But how do you make MMT work for your organisation? One of the first things you’ll need is a mobile wallet…

In the course of researching MMT 08 – the world’s first independent MMT conference – Steven Clarke, Event Director and Chief Payments Researcher for the Clarion Events Payments Division spoke to hundreds of MMT innovators, and is pleased to share his research in a series of papers. In this edition, we spoke to the leading mWallet vendors. Read more