Posts Tagged ‘telecom’

A Frugal Innovation Approach to Simcard Verification 2019 Edition – Design & High-level Architecture

Happy Easter Monday to you all, and I hope that the rains on Sunday night completed the cleansing process from the festivities, the resurrection of the Lord Jesus Christ and from the feast of the Goddess Ester (depending on which side you lean)… I am one who embraces all religious doctrines an faiths.

So over the last few days I have started receiving a message from MTN Uganda, to physcially visit a service center to verify my sim card registration, well this is only the 3rd cycle for selected customers whose details were screwed up during cycle 2, and I guess I am one of the lucky few with time to waste.

This is a followup to the 2013 recommendations for Simcard Registration https://ssmusoke.com/2013/03/12/uganda-simcard-registration-alternate-approach/¬†which apparently were not providing sufficient value ūüėČ

Anyway after having to make 10 calls this morning, the reminder message, a hardcoded IVR message, has left me frustrated, but also wondering, why do I have to physically visit the service center, it is 2019!

Rather than complain all the time, I focused my anger with support from my trusted colleagues at Styx Technology Group (http://styxte.ch) we got to protoyping a quick and dirty solution to this mess. What MTN and the regulator need are my National ID details, since they will scan the ID or take a photo of it, take a photo of me then I will have to wait 2-3 days,

A frugal innovation can be:

  1. Mobile App front end to capture data that is needed
  2. A backend system – doesn’t matter what it is – can even reuse the exisiting simcard registration database they have with processes to complete the verification flow, and link into the audit process that triggered this verification
  3. A verification process, which can be done by the app automatically, or using a backup USSD channel. This follows 2FA (two factor authentication to prevent mis-use)
  4. A notification that the verificatio process has been completed and *197# can be leveraged to check status.

This method is not for everyone, but provides a solution for those of us who may not be able to line up and waste 2-3 hours in line to do just this…

Some mobile screenshots from the design team

 

NIN Details

National ID Details

Phone Numbers

Phone Numbers

Confirmation

Confirmation

Thoughts and additions are welcome!!!

UPDATE 1:¬†One of the team members asked me, so does this solve your problem? How do you know which numbers are listed on your NIN that has been provided? Leading to iteration 2 of the Phone Numbers screen allowing the display of existing numbers with functionality to remove currently registered numbers…

Phone Numbers - v2

MTN Uganda, Mobile Money and Operations Issues

I am not one to rant and rave but I seem to have been pushed over the edge this morning, but a large Telco service which leaves a lot to be desired yet despite being innovative seem to be leading more and more wastage in terms of time which would be used for more productive pursuits.

The service is Mobile Money, currently being hailed as Africa’s savior in terms of providing¬†financial¬†services to the millions of unbanked populace. Everybody knows that mobile telcom services in Africa have been very¬†successful¬†and are growing by leaps and bounds due to the infrastructure issues associated with fixed line laying, operation and maintenance. Couple the cost of handsets, $10 Nokias are available with a battery that can last 5 to 7 days, oh yes, coupled with SMS has lead to mHeath, mEducation initiatives being developed.

Mobile money has been a core driver of mobile service usage in the last few years coz it makes it easy to move money without the hassles of banks (line up, service fees) and with the licensing of thousands of agents (there are now more agents than bars and supermarkets and groceries combined), means that getting access to money is as easy as moving to your local grocery store.

However MTN Uganda (http://mtn.co.ug/) is a market leader in Uganda and currently holds the market leadership position, I would put it at over 70% but I can be corrected, with the greatest reach within the country. The service is estimated to transact about UGX 5bn ($2.2m at current rates) per day which is quite high considering averge transaction values are in the $10 – $100 range.

Anyway their success is maybe their undoing, because despite the phenominal growth, the service is even worse the electrictity availabiltity with the platform having an average uptime of 50% during normal working hours, after a 45 day downtime during November 1, 2011 – December 15, 2011 (which started as an upgrade then later turned into an outage).

From my software engineering background I am still baffled at why this continuously happens to one of the largest telco providers due to the established DevOps (http://devops.com/ and http://en.wikipedia.org/wiki/DevOps) practices: what are the possible solutions or approaches:

  1. High Transaction Volumes
    • Hardware – buy more hardware throw more power at the problem
    • Software – not scalable then run a cluster of boxes across the switches, load balance the sessions this problem is available even with HTTP
  2. Interface Operations – In database speak we usually state separate writes from reads. Separate balance checking (reads) from ¬†withdrawals and deposits (writes) into separate distinct applications behind the interface. Use Queues, Gearman to ensure that the transactions are completed. Have the reads, balance checks run off slaves in the clusters …
  3. Notifications РSMS  Messages are good, for delivery but ensure they are sent and delivered. Queue the notifications so that they are always sent
  4. Provide options to execute transactions – provide a web interface for clients and agents. This opens up new revenue and agent opportunities since Internet cafe owners can also provide services from their interfaces. This is just an alternate way to access the service
  5. Be open to the public to lower the expectations Рprovide updates on service outages so that users do not just keep trying and only finding out from many failed trials. Failed transactions have been identified a known cause of application load spikes
  6. Reduce the number of available services and offload some services to other channels
  7. Use opensource software it has been proven to scale – or maybe some newer versions of your software applications
  8. New – Provide APIs so that developers can provide custom solutions to offload processing off your core system (switchboard)

These are just quick thoughts but they should be sufficient to start the discussion … not only rant and rave but also provide some concrete solutions

%d bloggers like this: