For this weeks question, the route cause was one of many possibilities that were investigated. The actual issue was identified after validating data used for performing a prepaid balance audit.
A prepaid balance audit is a simple control whereby the following steps are conducted:
Step 1: At a fixed point in time record the total amount of credit held on your prepaid billing system
Step 2: Record the total number of credits(top ups) to the prepay billing system for a given period(say 24hrs) – use an external source like the prepaid card database along with any other crediting mechanisms
Step 3: Record the total amount of debits from prepaid accounts for the same period(as a negative number)
Step 4: at the end of the period record the total credit held on the prepaid billing system
Step 5: Perform the following reconciliation: 1 + 2 + 3 = 4
Now the above didn’t identify the issue, however by validating Step 2 against cash received for sales of top up cards we could see that there was a general issue, where more credits were being applied to the prepaid billing system than those being sold.
Simple but effective. I like it! There are some parallels here to a general retail business.
Hi!
Concerning reconciliation of top ups (step 2) and sales of cards – how can it be realized?
1. If we try to compare aggregated figures (i.e., volume of top ups and volume of sales for the same 24 hrs) – the results won’t be representative, because subscribers don’t necessarily activate purchased card immediately after purchasing. So there would be permanent descrepancy between these volumes, disguising possible fraud.
2. We can’t match individual “top up”- and “sale”- transactions, because of lack of information about serial number of every card sold.
Hi Dmitry,
For your 1st question what you need to do is compare these figures day on day. You’re right that the results will be disproportional on a single given day, however if you do this exercise for a month and find that 90% days show greater amounts of crediting to sales – it could indicate a problem. Compare this to the net effect of the month’s worth of transactions and again if you see greater crediting to sales this would indicate an issue. In reality, you should always see less crediting than sales – as cards get lost, never the other way round.
If we look at the route cause of why there were more credits than sales, you could probably skip the above analysis and go straight to the issue. Basically top up were being used, but not by the person purchasing the card – in theory this wouldn’t cause there to be more credits than sales as the used top up serial numbers would eventually get purchased and hence things even up. However what was happening in the company I worked for, was that customers would phone in and say there top up cards failed and our customer services department would then give them a customer care credit i.e. add the top up value to their account. This is where the disparity was created and therefore for your situation you could simply go straight to customer services and ask how often this scenario occurs.
For your second question, you will need to be able to associate the serial number of the top-up to the crediting of an individual SIM if you are to be able to find the perpetrator of the fraud (or at least the recipient of the benefits). In theory all of the information should be available within the top-up serial number database or the pre-paid billing system – if not, I would do step 1 above to identify whether the issue exists and then use this as justification for introducing transaction logging on the respective system.
I hope this is of some help, if you need further advice please post again.
Thanks, Dave! About №1 – yes, it’s really interesting control, we should try it. And, nevertheless, any suspicious descrepancy will require root cause analisys, and we’ll face to lack of information about serial numbers of sold cards.
I don’t know, may be it’s a specific of Russian and CIS providers only (where I have worked), but 99,9% of cards are sold by various kinds of dealers (and subdealers, and sub-subdealers etc :)). So, CSP has only information about ranges of cards, given to one or another dealer and doesn’t know, when this dealer has sold certain card.
So, now I see possibilities for looking for some more “drill down”-root causes of “over-topuping”:
1. Searching of doubled top ups (2 or more top-up transactions with the same card number)
2. Searching for top-up transactions with card numbers not from the ranges, that are already given to dealers.
May be something else?
Thank you again!