Telecom Fraud Management Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does fraud detection get scoped as a report so often?

Because reporting is where the data already lives. Somebody says we need to see unusual international traffic, the billing team already produces a daily summary, and the requirement becomes a dashboard with thresholds and an email alert. It is cheap to build, it demonstrates well, and it does almost nothing.

The reason is arithmetic. The entire exposure window in an international revenue share fraud event is measured in hours, most of them outside working hours. A dashboard requires a person to be looking at it, and the loss happens precisely when nobody is. Alerting improves that slightly by pushing the notification, but it still depends on someone being awake, sober, near a laptop and authorised to make a blocking decision at 2am on a Saturday.

The fix is to invert the order of operations: contain first, review second. The system takes a narrow, reversible action automatically and creates a case with the triggering call records attached, and the human reviews something that has already been stopped. That single design decision is what determines whether the project saves money, and it needs to be in the statement of work from the beginning, because retrofitting automated action onto an alerting tool means rebuilding the parts that touch your network. Scope the report as a by product of the case queue, not as the deliverable.

What goes wrong when call detail records are used as the data source?

You inherit the billing cycle's latency and call it detection. Most operators have call detail records after mediation, arriving in batches hours after the calls, sometimes the next day. That is the correct source for revenue assurance and the wrong one for fraud, because a detection system running on yesterday's records is an expensive way of reading your own invoice early.

The second problem is shape. Mediated records are built for rating and settlement, so they are complete rather than timely, and they often lack the fields that matter most for fraud, including the originating internet protocol address, the registration identity and the concurrency picture at the moment of the calls. You cannot compute a rolling concurrent channel count from a nightly file.

The fix is to tap live call events out of band from your softswitch, session border controller or class 4 platform, and to hold rolling counters per customer, per trunk, per destination prefix and per originating address in memory. Out of band matters as much as live: detection must never be able to affect call flow. If a supplier proposes anything inline with signalling, stop the conversation. Keep the mediated records too, for reconciliation against wholesale invoices, but do not build detection on them.

Why do session border controller and provisioning integrations break after launch?

Because writing controls into live infrastructure is the part everybody defers, and it is the part the whole system depends on.

• Access takes longer than the build. Production traffic events and a safe path to write blocks both go through your network team's change process, not the development team's calendar. Projects that start those conversations in month three lose a month.
• No rollback path. A block applied automatically must be removable automatically, and controls written directly to device configuration without a documented reversal are how a false positive becomes an outage.
• Provisioning drifts. Customer and endpoint identity in the provisioning system does not always match what the switch reports, so the block lands on the wrong account or nowhere at all.
• Configuration changes underneath you. Session border controller upgrades and rule reorganisations break assumptions the fraud system made about where its entries live.

The fix is to design the action layer with reversal as a first class requirement, test every action type by applying and removing it in a maintenance window, and start the network access conversation in week one. Name the specific devices and provisioning systems in the contract.

What happens when reseller hierarchies and graduated actions are not covered?

Blocking becomes all or nothing, which means it never gets armed. Operators know that a single kill switch will one day take down a paying customer's phones, so they leave automation off and keep eating losses, which is a rational response to a badly designed control.

Reseller structures make it worse. In a wholesale or hosted platform the account you must suspend is often three levels below the one you bill. If the system only understands your direct customer, the only available action is suspending the reseller, which takes down hundreds of innocent end customers to stop one compromised endpoint. So nobody does it.

The fix is a tiered, reversible action set scoped to the lowest identifiable entity. Cap concurrent channels to one destination without dropping calls in progress. Bar a specific prefix range for that one customer. Suspend international outbound while leaving domestic and emergency calling intact. Deregister the compromised endpoint and force re authentication. Each tier is narrow, each is logged with the rule and evidence that triggered it, and each can be reversed by one action.

Build shadow mode alongside it, so every new rule runs against live traffic and records what it would have done before anyone arms it. Shadow mode is cheap at the start and nearly impossible to add convincingly later.

Should you build custom or configure what you already own?

Some operators should not build at all, and the cheapest answer is often the right one. If your total outbound international exposure is genuinely small, apply a hard destination whitelist, a low per customer credit ceiling and international barring by default with opt in. That is crude, costs nothing and removes the catastrophic case. If your customers rarely call internationally, do that and spend the engineering money elsewhere.

If you are a large carrier with a staffed fraud function, multiple networks and appetite for a multi quarter deployment, buy. Subex and Mobileum carry deep telecom domain knowledge and are deployed across large carriers, and at that scale you should not be writing your own. Araxxe and Xintec are credible in adjacent detection and test call territory. TransNexus is genuinely good at session initiation protocol analytics and call authentication, and if you already run it, configure it further before commissioning anything.

The build case is about iteration speed rather than capability. It starts when two of the following are true. You sit between customers you do not control and upstream carriers you owe. You have taken a five figure loss, or know you would not survive one. Your traffic is diverse enough that global thresholds are unusable. You need to change detection logic faster than any release cycle allows. Or you have automated blocking nowhere, which means your defence is currently whether somebody happens to look on a Saturday.

How do hidden costs get into the quote?

Through everything that touches the network rather than the application.

• Traffic sources counted as one. A hosted platform, a wholesale interconnect and a mobile core produce different event shapes, and each is its own ingestion path.
• Real time action integration, which needs safety design, a rollback path and maintenance window testing on live equipment.
• Multi tenant reseller hierarchies, which change the identity model everywhere, not just in one screen.
• Tuning after go live. Rules need weeks of shadow running and adjustment against your own traffic before they earn their place, and that is analyst time somebody has to fund.
• Case handling process. Somebody has to define what happens after containment: who calls the customer, what the notification says, and who authorises reversal.
• Correlation across networks you do not fully control, which is usually a second phase disguised as a requirement.

Ask for the estimate broken down per traffic source and per action type, and ask what the tuning period assumes of your team.

What separates a build that works from one that fails here?

Baselines per customer rather than global thresholds. A spend limit or a concurrent call cap catches crude attacks and generates a steady stream of false positives against exactly the customers you least want to annoy: the call centre ramping for a campaign, the travel agency with a seasonal peak, the enterprise that just onboarded three hundred seats. Support raises the limit permanently and the control quietly stops existing. Learn each customer's own shape instead, meaning destinations ever called, hour of day distribution, average and peak concurrency, call duration and answered to attempted ratio, and alert on deviation from that history. 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.

The second marker is who owns the rules. Your team should be able to write a rule on Saturday against a pattern they can see, run it in shadow mode against live traffic, and arm it when confident. Fraud patterns change faster than release cycles, and the operator who can adapt in an hour beats the one who files a ticket. Leave machine learning for later, once you have a labelled history of confirmed fraud and confirmed false positives, because without labels a model is a random number with a confidence score attached.

When vetting a developer, ask them to describe the international revenue share fraud signature specifically: what the test phase looks like, why concurrency matters more than call count, and why a destination being new to that customer is the strongest single feature. That separates telecom people from generic anomaly detection people. Then ask what graduated actions they would implement and how each is reversed.

Get ownership in writing before kickoff, including the rule set, because the rules are your accumulated knowledge of how you get attacked. At Digital Heroes the client owns the repository and the detection rules from the first commit.