AI for Fraud Review in Telecom

An alert fires late on a Friday against a business account that has been unremarkable for years. Since the office emptied, its lines have been dialling a small set of expensive international destinations, continuously, in a rhythm no person is producing. The traffic is still running while the alert waits in the queue, and every minute creates an obligation to another carrier that stands whether or not the customer ever pays.

At the other end of the same operation, someone stands at a retail counter with a handset in a box. The identity and credit checks came back acceptable. If the box leaves with them and the account is fraudulent, the operator has lost a subsidised device, the usage run up before anyone bars the account, and the cost of pursuing someone who was never there.

The value leaves before the money arrives

Elsewhere the disputed value moves after a payment instrument has been presented, and the argument is about who bears the loss. Here the operator hands over real value first: a subsidised handset leaves a shop, an open route to the network is granted, and the network carries whatever traffic is offered at a cost incurred in real time. The first payment is due weeks later. The desk therefore works against two clocks, one at the speed of a retail transaction and one at the speed of the switch, and a single queue design rarely serves both.

The decision made while someone is standing at the counter

An order arrives, in a shop or online, with a name, an address, a bank account and a device choice. The checks available in the moment are thin: identity verification, a credit reference, a match against known bad records. They cannot say whether this is the latest of several orders this week from a group working one postal district under different names.

The value of an agent here is not a better score. In the seconds available it compiles what a good analyst would have found given an afternoon: previous accounts at that address and how they ended, other recent orders sharing the bank account or contact number, an identity that appeared in a declined order elsewhere. That evidence moves the decision more than another decimal place on a score.

The account that never makes a payment

Device financing sharpens this. An account that takes an expensive handset and defaults before the first payment looks like credit risk in the collections report and behaves like fraud in every other respect. An agent reviewing those defaults against the order evidence, the selling channel, the opening weeks of usage and the linked accounts can separate a customer whose circumstances changed from an account that was never going to pay.

Takeover of an existing account

The second pattern is quieter. The account is real, the customer is real, and the fraud is a change made to it. A number moved to a new device. A financed handset added to an account in good standing. A delivery address changed shortly before an upgrade. A request to move the number to another operator.

Individually these are ordinary requests, which is why they work. What makes them visible is sequence and timing: a contact detail changed, then a device added, then a delivery to an address never used before, inside a short window, on an account static for years. Reviewing each change alone never surfaces it; reading the recent history as one story does. Authenticating the person asking belongs to the support operation, while the fraud desk owns the pattern across accounts.

The channel nobody wants to investigate

Dealers, resellers and franchised stores sell a large share of connections and are paid for activations. The failure mode is predictable: activations that never generate usage, connections that default together, orders clustered at hours the shop was closed, documents recurring across customers.

Comparing activation cohorts by outlet over their first billing cycles makes the outliers stand out. The difficulty is organisational: the accused is a business partner the sales channel depends on, so the evidence standard is higher than for an anonymous fraudster. An agent earns its place because the work is repetitive and evidential, covering each outlet's activation history, the payment outcome of every connection sold, documents reused across orders and what clawback would apply. The accusation stays human.

Losses that grow by the minute

Usage based fraud is where speed is everything. Traffic engineered onto expensive destinations so somebody in the chain collects a share of what the operator pays to terminate it. A business phone system compromised and used heavily outside working hours.

Detection rules exist in most operators; the gap is between the rule firing and a human acting. Someone has to establish whether the customer has a plausible reason for the traffic, whether it matches the account's own history, whether other accounts show the same destinations tonight, and how much exposure has accrued. That is investigation under time pressure at an hour when the desk is thin, and an agent can have it ready before anyone opens the alert.

Assembling the case across systems that were never joined

This rests on the same unglamorous capability. The evidence lives in the order system, the identity and credit responses, the network usage records, the billing account, the device identifiers, the selling channel, and previous accounts at that address. Those systems were built at different times for different purposes and nothing joins them, so most of the build effort goes there, not into anything clever. The file must say plainly when a source was unavailable.

Evidence that arrives after you finished

Usage carried on another network reaches you long after the traffic ended, payment outcomes take weeks, and a port completes and the account is gone. So a case is not something you open, work and close once; it has to reopen when a record arrives that changes the picture. Agents suit that, because re-reading dormant cases against new data is work nobody has had the hours for.

Linking entities across accounts

Single case review is structurally blind to organised abuse. One application looks fine. Several across a month, sharing a device, an address variant, a payment instrument or a contact number, do not.

Entity linking is the highest value thing an agent does here, and the hardest to get right. Identifiers are dirty: addresses written differently, names transliterated inconsistently, numbers recycled. Links asserted too loosely produce a graph where everyone connects to everyone and analysts stop trusting it, so every link must show what it rests on and a human must be able to discard the weak ones.

What being wrong about a real customer costs

Fraud controls act on a service people depend on. Barring an account that turns out to be legitimate cuts off someone's phone, which is a serious harm rather than an inconvenience. So the threshold for automated action and the threshold for a queued review have to be set separately. Adding a case to a queue costs analyst time; barring a line costs a customer their connection. Automated action belongs only where the pattern is narrow and historically near certain, and even there it should be quickly reversible.

What the agent does, and what it does not

It assembles the case across those systems, links the entities and shows the basis for each link, drafts the analyst narrative with every claim cited to its source, recommends a disposition with the reasoning visible, and prepares the referral or channel file for a human to act on.

It does not disconnect anyone on its own judgement. The disposition in the system of record should be written only by an authenticated human action, with the recommendation stored alongside it and any override recorded. Override rate by case type tells you where it has earned trust.

Outcomes arrive late, and the labels are stale

Feeding confirmed outcomes back into the rules is the obvious next step and the one most often oversold. Nothing counts as confirmed fraud until payments have failed or an investigation has concluded, and by then the pattern has moved on, so any label set you tune against describes the fraud of some months ago. Treat outcome feedback as evidence into a governed review of the rules rather than an automatic adjustment, and keep a route for analyst observations that carry no label yet.

Evaluating it on cases you have already decided

Take cases your own team has already dispositioned, across each fraud type in scope, and run the agent blind against them. Measure evidence completeness, factual accuracy of every cited claim, agreement with the human outcome, and above all the direction of disagreement. An agent that would have released orders your team stopped is a different problem from one that would have queued orders you let through.

Include the cases your team got wrong: customers barred who should not have been, accounts that ran for weeks unnoticed. Contested cases are where the value is.

Where AI fails here

The agent cannot verify that a person is who they claim to be. It reads what the checks returned and what the records hold. If the documents pass those checks, no amount of case assembly becomes knowledge about the person at the counter.

It cannot see the pattern that has not happened yet. Fraud here moves towards whatever the controls do not cover, so an agent built from your history is built from patterns already being abandoned.

It learns from labels that arrive late and it reproduces whatever your past decisions encoded. If certain addresses or channels were treated more harshly for reasons that would not survive examination, it applies that treatment faster and more consistently.

And a false positive here bars a real customer's phone, which is not a declined order they can retry. Any deployment that cannot show what it would have done to your legitimate customers is not ready.

Where to start

Pick one pattern with volume, clear ground truth and a tolerable cost of error. Defaults on financed devices and channel activation review are good first ground: the evidence is internal, the outcomes are checkable, and no customer's service is cut off by an early mistake.

Build the case assembly and the entity linking first, and stop there for a while, because assembly alone carries little governance weight. Add narrative drafting once analysts trust the files, and disposition recommendations last.

Adopt AI Partners builds these agents inside the operator's own systems and stays until the fraud team owns them. To talk through which fraud pattern is the right first one, hello@adoptaipartners.com reaches us.