Someone else's phone bill

Most fraud in software is about getting something for nothing — a free subscription, a refund that should not have happened, a card that is not yours. Telecoms fraud is different in a way that changes how you defend against it: the loss accrues continuously, in real time, and somebody is genuinely owed the money.

The classic shape is toll fraud. Someone gets access to an account — a weak SIP password, a handset exposed to the internet, credentials in a breach — and starts dialling premium-rate international destinations they control. Every connected minute earns them a share of the termination fee. A compromised account left running over a long weekend is a five-figure problem, and the carriers you buy from will invoice you for those minutes regardless of how the calls originated.

That last point is what makes it urgent rather than annoying. You cannot resolve it afterwards by declining to pay.

Two very different fronts

The work splits cleanly into two problems that feel related and are not.

Signup fraud is about who gets an account. It is adversarial in the normal way — automated registrations, throwaway identities, cards that will chargeback — and the defences are the usual ones.

Usage fraud is about what an account does once it exists, and it is frequently not the customer's fault. A legitimate business with a badly configured handset is a victim, not an attacker, and the correct response is to protect them from a bill rather than to treat them as hostile.

Getting that distinction right matters because the instinct — build a wall, keep bad people out — only addresses the first, and the second is where the money is.

Graduated response beats a binary gate

The instinct with any risk signal is to pick a threshold and refuse anything below it. I think that is usually the wrong shape, and the reasoning generalises well beyond telecoms.

A hard block on a signup flow has an asymmetric cost profile. Someone determined will try again with a different browser in four minutes — the block costs them almost nothing. An honest customer on an unusual network, or with a privacy extension, or simply having a bad day, hits a wall and goes elsewhere. You never hear from that second group, which is precisely why the control looks like it is working.

A graduated response inverts the asymmetry. Instead of refusing, you attach additional verification and let the person continue. The honest customer is mildly inconvenienced and completes. The other kind meets a step that costs something real and does not scale for them — which is the entire point of friction, applied to the population it should apply to.

The engineering consequence is that a risk signal has to be plumbed as an input to a workflow rather than a boolean at a gate. It needs to be stored, to survive the session, to be visible to staff reviewing an account later, and to handle being absent — when a scoring service does not answer, the result must be a defined state rather than a crash or an accidental refusal.

Act automatically, or do not bother

On the usage side, the thing that separates a control from a gesture is whether it acts on its own.

An alert is not a control. By the time somebody reads a notification about unusual activity, reasons about whether it is genuine, finds the right person and acts, hours have passed. Automated abuse does not observe office hours, and when the loss is linear in time those hours are the entire cost.

Nobody enjoys building something that will occasionally interrupt a legitimate customer. It is still correct, because the distributions are not comparable: a rare, recoverable interruption for a real business against an unbounded loss on a compromised one. Alert as well, certainly — but the alert should tell you what already happened, not ask you to decide.

Thresholds also cannot be global. Different partners sell into different markets with genuinely different legitimate patterns, so a single set of limits is either too loose for one or too tight for another.

Never the emergency path

Every one of these controls carves out emergency calls. Outbound is disabled; 999 is not. Rate limiting applies; not to emergency calls.

I have written about this before and it bears repeating here because it is the clearest example of why: the scenario where the carve-out matters is someone dialling for an ambulance from an account that has been suspended for non-payment or locked down for suspected fraud. The protective control and the emergency path must never be the same code path.

Blocking without explaining creates its own work

Two things I would insist on from the start next time.

Every block needs a visible reason. When a call is refused because of an outbound restriction, the person on the support desk needs to see that, in those words, without reading logs. Otherwise your fraud controls generate a steady stream of "customer says calls are failing" tickets that take an hour each to diagnose — and that cost is paid by your colleagues, quietly, forever.

Blocking controls need a rollback path you have tested. Anything that denies service automatically will eventually deny it wrongly, and at scale. The question is never whether that happens, only whether you can undo it in minutes or hours — and that is a property you have to build deliberately, before you need it.

What I took from it

Prefer escalation to refusal. A risk signal is more valuable as a trigger for verification than as a gate. You keep the customers you would have turned away and impose real cost on the ones you would not.

Automated controls beat alerting when losses are continuous. If the damage accrues per minute, a human in the loop is not a safeguard, it is a delay. Alert as well — but act first.

Victims look like attackers. In usage fraud the account behaving badly usually belongs to somebody who has done nothing wrong. Designing the response around protecting them, rather than punishing them, produces different and better decisions.

Every denial is a support conversation. Budget for the explanation surface at the same time as the control, or your colleagues will absorb the difference.