Telecom Fraud Management Development: Stopping the Compromised PBX Before the Wholesale Invoice Arrives

Why one weekend decides whether you had a profitable quarter

Friday evening, a customer's on-premise PBX with a weak SIP password gets registered by someone who is not the customer. From about 9pm the traffic starts: short-duration calls first while they test, then sustained concurrent calls to a premium number range in a country you have never terminated traffic to before. It runs all weekend. Nobody is watching, because nobody watches on Saturday. On Monday morning your engineer notices the concurrent channel count. By then the calls are minutes on somebody's switch, the premium rate revenue has been shared upstream, and your wholesale carrier will invoice you for every second of it.

That is the thing that makes telecom fraud different from most fraud. You are not disputing a chargeback. The traffic genuinely traversed the network, your upstream carrier genuinely paid termination, and the money has already been split between parties in jurisdictions where you have no recourse. You will chase the customer whose PBX was compromised, they will point at your platform, and one of you will absorb it. Usually you, because suing a customer over their own security failure is a good way to end the relationship and still not get paid.

The other flavours are quieter but constant. Wangiri, where missed calls bait callbacks to premium numbers. Subscription fraud, where accounts are opened with no intention to pay and immediately used for international traffic. Traffic pumping into high-cost domestic ranges. SIM box bypass, where international traffic is terminated as domestic mobile and your interconnect revenue disappears. Each has a different signature, and none of them look like anything on a static threshold report.

Problem 1: your detection latency is the same as your billing cycle

Most operators detect fraud from CDRs after mediation, which means the data arrives in a batch, often hours after the calls, sometimes the next day. That is fine for revenue assurance and useless for fraud, because the entire exposure window in an IRSF event is measured in hours. A detection system that runs on yesterday's records is a very expensive way of reading your own invoice early.

The fix is not exotic. Your softswitch, your SBC and your class 4 platform can all emit call events at or near real time. Ingesting them into a stream, maintaining rolling counters per customer, per trunk, per destination prefix and per originating IP, and evaluating rules on a window measured in seconds is well-trodden engineering. The reason it is not everywhere is that it requires touching production signalling infrastructure, and nobody wants to be the person who broke calling by adding a fraud feed.

What a custom build does: tap the events out of band so detection can never affect call flow, hold the rolling state in memory, and evaluate against baselines that are per-customer rather than global. A dental practice that has never called outside the country and a freight forwarder that calls Lagos daily need different thresholds, and a single global rule set is guaranteed to either miss the first or block the second.

Problem 2: the enterprise suites are built for a bigger operator than you

Subex and Mobileum are the serious names in this space and they are serious for a reason: their fraud and revenue assurance platforms carry deep telecom domain knowledge and are deployed across large carriers. Araxxe and Xintec are credible in adjacent detection and test-call territory. TransNexus is genuinely good at SIP-layer analytics and call authentication, and many hosted voice providers already run it.

The mismatch is rarely capability. It is fit and control. Those platforms are scoped, priced and implemented for operators with a fraud team, a dedicated integration budget and a multi-quarter deployment. Tuning them to your traffic is a professional services engagement, and every subsequent tuning cycle is another one. If you are a hosted PBX provider with 4,000 seats or a wholesale voice operator with a handful of interconnects, you will spend more managing the relationship than the fraud costs you, and you still will not be able to change a rule at midnight when you can see the attack happening.

What a custom build does: put the rule engine in your hands. When your team sees a new pattern on Saturday, they should be able to write a rule against it on Saturday, test it in shadow mode against live traffic, and arm it when they are confident. That iteration loop is the actual defence. Fraud patterns change faster than vendor release cycles, and the operator who can adapt in an hour beats the one who files a ticket.

Problem 3: detection without automated action is just a faster alarm

Plenty of operators have alerting. Very few have automated blocking, because blocking is scary: block wrong and you take a paying customer's phones down, which feels worse than eating a fraud loss until you have eaten a large enough one.

The way out is graduated action rather than a single kill switch. A first-tier response caps concurrent channels to a destination without dropping existing calls. A second bars a specific prefix range for that customer only. A third suspends international outbound while leaving domestic and emergency calling intact. A fourth deregisters the compromised endpoint and forces re-authentication. Each tier is reversible, each is scoped to one customer, and each is logged with the rule and the evidence that triggered it.

What a custom build does: wire those tiers directly into your own session border controllers and provisioning system, so the action happens in seconds and the case is created automatically with the triggering call records attached. The human then reviews a case that has already been contained, rather than racing an attack. That inversion, contain first and review second, is the single design decision that determines whether the system saves money.

Problem 4: static thresholds punish your best customers

The default control most operators run is a spend limit or a concurrent call cap. It catches the crude attacks and generates a steady stream of false positives against exactly the customers you least want to annoy: the call centre that ramps for a campaign, the travel agency with a seasonal peak, the enterprise that just onboarded three hundred seats. Support then raises the limit permanently, and the control quietly stops existing.

Behavioural baselining fixes this without machine learning theatre. For each customer, learn the normal shape: destinations ever called, hour-of-day distribution, average and peak concurrency, average call duration, ratio of answered to attempted. Then alert on deviation from that customer's own history rather than from a global number. A first-ever call to a destination at 2am with rising concurrency is a strong signal on any account. The same call at 2pm to a country they call weekly is not.

Where genuine machine learning earns its place is later, once you have a labelled history of confirmed fraud cases and confirmed false positives. Scoring on top of the rules improves precision and reduces the review queue. Starting with it is backwards: you have no labels, so the model is a random number generator with a confidence score attached.

Problem 5: nobody can reconstruct what happened, so nobody learns

After an incident, the questions are always the same. When did it start. What was the first anomalous event. Which rule should have fired and why did it not. Who changed that threshold and when. Was the customer notified, by whom, at what time. Most operators cannot answer these because the evidence is scattered across switch logs, a support ticket and somebody's memory.

Build the case object properly from day one: every triggering event, every action taken with actor and timestamp, every rule version in force at the moment of the event, and every customer communication. This is what turns a loss into a rule improvement, and it is also what you hand to a customer or an upstream carrier when the commercial argument starts about who pays.

What this costs and how long it takes

Across projects Digital Heroes has delivered, a real-time detection and automated blocking layer runs $80,000 to $175,000 across 12 to 18 weeks. That covers live event ingestion from your switch or SBC, rolling counters, per-customer behavioural baselines, a rule engine your team can edit, graduated automated actions wired into your controls, a case queue with full audit, and shadow mode so you can validate rules against live traffic before arming them. Extending into learned scoring, SIM swap and subscription fraud detection, revenue assurance reconciliation against wholesale invoices, and correlation across multiple networks or interconnects runs $220,000 to $500,000 phased across 8 to 14 months.

What drives price up in this category: the number of distinct traffic sources, because a hosted platform, a wholesale interconnect and a mobile core produce different event shapes. Real-time action integration, because writing controls into a live SBC needs careful safety design and a rollback path. Multi-tenant reseller structures, where the account you must suspend is three levels below the one you bill. And any requirement to correlate across networks you do not fully control.

What keeps price down: starting with outbound international only, on one platform, in shadow mode. Almost all catastrophic single-event loss in this category is outbound international, and shadow mode lets you tune without risk before anything is armed.

Build versus buy, and when buying is right

Buy, or rather cap, if your total outbound international exposure is genuinely small. A hard destination whitelist, a low per-customer credit ceiling and international barring by default with opt-in is crude, costs nothing, and eliminates the catastrophic case. If your customers rarely call internationally, do that and stop reading.

Buy a platform such as Subex or Mobileum if you are a large carrier with a staffed fraud function, multiple networks, and the appetite for a multi-quarter deployment. At that scale their domain depth is worth what it costs and you should not be writing your own.

The build case starts when two of the following are already true of your traffic. You are a hosted voice or wholesale operator sitting between customers you do not control and upstream carriers you owe. You have already taken a five-figure fraud loss, or you know you would not survive one. Your traffic patterns are diverse enough that global thresholds are unusable. You need to change detection logic faster than any vendor release cycle. Or you have automated blocking nowhere, which means your best defence is currently whether somebody happens to look on a Saturday.

How to choose a developer for fraud management work

Ask how they would ingest call events without touching the call path. If the answer involves anything inline with signalling, stop. Fraud detection must never be able to break calling, and any competent telecom engineer says that unprompted.

Ask what graduated actions they would implement and how each is reversed. A developer who only offers suspend has not thought about the false positive that takes down a hospital's outbound line at 3am.

Ask them to describe the IRSF signature specifically: what the test phase looks like, why concurrency matters more than call count, and why the destination being new to that customer is the strongest single feature. This separates people who have worked in telecom from people who have built generic anomaly detection.

Ask who owns the code, the rules and the infrastructure accounts, and put it in writing before kickoff. At Digital Heroes the client owns it from the first commit, including the rule set, because the rules are your accumulated knowledge of how you get attacked. Send us a week of call detail records and a description of your last incident, and we will show you which rule would have caught it and how early.