Whilst working for a fixed line operator the following scenario was discovered:
A single switch that served half of the country was found to have nearly a thousand customers on it that weren’t set up in the billing system. The customers had been set up in such a way that whenever they made calls they didn’t create CDR’s – so there was no downstream issue with suspense. After a lengthy investigation it was found that the engineer who administered the switch had offered the residents in the local town an amazing deal of free calls for life, for a one off fee – which he pocketed.
Although this is actually a case of fraud, it was discovered using Revenue Assurance methodologies. There are numerous ways this issue could be discovered, how would your existing controls/solutions identify this loss?
I can think of two ways off the top of my head:
1. Perform a line reconciliation between the billing system and switch.
Capture all of the relevant switch configuration information using some kind of data extraction script or Network Collector.
Extract all active subscriber line data from the billing system.
Compare: active subscribers on switch against active subscribers in billing.
Theoretically though, the engineer could have made alterations to the configuration after the activation stage of the provisioning process, which this method alone would not capture. It would mean that the customer would probably still be charged line rental though.
2. Switch CDR Generation Query
Once again, switch configuration data needs to be captured from the switch with a Network Collector. This time, the data needs to include a feature dump rather than just lines and is looking for the “create CDR” feature.
Usually switches have a few levels of complexity when generating CDRs, e.g. “line” level and “global” level. Some switches have a “group” level too. It is very simple to check the configuration of the global settings, but group level requires a little more knowledge of the switch. This is an important distinction as line level settings will most likely override any global settings.
Query: Once you have loaded all of your parsed switch data, you can run a query looking for the “charging flag” feature.
All this talk of Network Collectors is making my eye twitch.
Hi Matt,
Good answer but not the way I found this particular one.
Looking at your answers:
1) This is an excellent way to find this type of issue, but does have the downfall of requiring some serious levels of expertise and a fair amount of coding. Ultimately the engineer cannot completely hide what is in the inventory, so by extracting all switch inventory tables and applying a lot of switch architecture knowledge this would result in correct identification of this problem
2) The create CDR feature search would return all lines where CDR supression was in place. For most operators this feature should never be applied, therefore the query would only return suspiscious provisions. As with answer one, technical expertise would be required
To do both of the above, either an expert like Matt would need to be recruited or the procurement of a specialist piece of software, both of which may not be possible for a small scale operator.
As a hint, I got this one with CDR’s
You have to believe that customers who get free calls are going to make lots of calls to lots of destinations. Did you spot the anomaly by comparing the traffic being passed to other operators with the traffic being recorded at the local switch?
This is a good question and the control check suggested by Eric would also identify other revenue assurance related issues. For example, I have witnessed at one particular operator, outbound calls/minutes at the i/c gateway to be 10% higher than billed calls from local switches. A subsequent CDR reconciliation between local switches and the i/c gateway (taking in to account suspense calls)revealed short duration calls not being billed, rounding logic less favourable, insufficient DMS filter compensation, hidden switches, and a fraudulent Engineer performing CDR suppression.
Well, there are a few ways to identify such a scenario. Matt has gone through my preferred approach earlier,i.e. Subscription assurance. As a standard check, we do reconcile HLR subscription info alongwith all features subscribed to against Provisioning and then to Billing. We would highlight all those subs where there is any form of mismatch (be it in status, missing in billing, missing in HLR, feature mismatch etc.)
Another way that comes to mind is the subscriber call ratio trending that we perform. We trend against each subscriber the cumulative amount of calls made per week/month. As one of the alarms is low usage, we would get all the subs in the scenario that you’ve highlighted as zero usage over an extended period of time.
There are other checks we perform based on trunk/switch that might give similar results, i.e. low or no usage traffic.
Hi Eric,
This particular operator was a 2 switch outfit. Both switches had direct interconnects to the offnet operators, however only one switch was managed by the fraudulent engineer……
A simple retail to interconnect reconciliation would have thrown this one up – but it wasn’t how I spotted it.
Hi Dave,
Did you find it by comparing SS7 probe CDR’s to CDR’s coming off the switch?
Hi Hakim,
An SS7 to CDR reconciliation would easily have found this issue, but it wasn’t the way I found it. I’ll be posting the answer later today
Was there a regular RA piss up.. sorry l mean meeting down the pub, where someone overheard the engineer bragging to his mates?
I think Hakim has his terminology confused. The preferred way to describe “a regular RA piss up” or “meeting down the pub” is to refer to it as a “steering committee of the World RA Forum/Global RA Professionals Association/Pan-Galactic RA Union*”.
* Delete depending on which clown is giving orders but not buying drinks