💰

Section 8.8

Fraud Management

Deliberate or suspicious abuse — SIM swap and account takeover, IRSF, subscription, payment and device fraud: detection, risk scoring, decisions, case management and recovery, and how fraud differs from revenue assurance.

A Different Question from Revenue Assurance

Revenue Assurance asks

"Did our systems or processes lose legitimate revenue?" The cause is internal: a lost record, a missed event, a wrong price.

Fraud Management asks

"Is someone deliberately or suspiciously abusing the service, account, network or payment system?" The cause is external intent — a fraudster, sometimes with inside help.

The two share data (usage records, account data, payments) and are often sold together as "RAFM", but they work differently. RA reconciles after the fact and recovers. Fraud Management has to decide, often within minutes or seconds, whether to let activity continue — because in fraud the loss grows with every minute the activity runs, and much of it cannot be recovered afterwards.

Fraud Management

The capability that detects, scores, decides on and investigates suspicious activity across customers, accounts, devices, SIMs, network traffic and payments, and applies controls — from allowing and monitoring to challenging, restricting or blocking. Its measure of success is fraud loss prevented at an acceptable cost in false positives and customer friction.

The Fraud Management Architecture

Customer, device and network activity

Network / BSS / channels

Calls, sessions, SMS, SIM changes, logins, orders, top-ups and payments.

Data ingestion

Fraud platform

Usage from mediation and the OCS, NRTRDE roaming summaries, CRM and order events, payment gateway events, device and SIM events. Real-time feeds for high-velocity fraud; batch for pattern analysis.

Data enrichment

Fraud platform / reference data

Add context: account age, credit class, product held, device history, home location, known-bad number ranges and IMEIs.

Fraud detection engine

Rules + ML

Rules (thresholds, velocity, blocklists) catch known patterns quickly and explainably; machine-learning models find unusual behaviour against the customer's own baseline and peer groups. Most operators run both.

Risk scoring

Fraud platform

Signals are weighted into a score per account, SIM or transaction. The score is only useful if it is calibrated — a score everyone ignores is worse than no score.

Decision management

Decision rules

Policy maps score and context to an action. High-value, high-confidence patterns can be automated; the rest go to a person.

Allow / challenge / restrict / block

OCS / network policy / CRM / payment gateway

Allow (and monitor); challenge (step-up verification, call-back); restrict (bar international or premium destinations, cap spend); block (suspend the SIM, reject the order or payment).

Case management

An alert becomes a case with its evidence, owner and status.

Investigation

Fraud analyst

An analyst confirms or rejects fraud, looking at the account, device, location, usage, transactions, recent changes and history.

Recovery

Fraud / finance / legal

Withhold payments to partners where the agreement allows, dispute with carriers, reverse charges, refer to law enforcement, reinstate genuine customers.

Rule and model improvement

Fraud team

Confirmed and rejected cases feed back into rules and models. Without this loop, false-positive rates stay high and new patterns go unseen.

Five Patterns Every Operator Faces

A fraudster persuades a shop or contact centre (or abuses an online journey) to move the victim's number to a SIM they control, then receives the victim's one-time passcodes and takes over bank, email or social accounts. The operator's loss is small; the customer's can be large, and the reputational and regulatory impact falls on the operator.

Signals — SIM change followed quickly by password resets or new device IMEI; change requested from an unusual channel, store or location; recent change of contact details; many SIM changes by the same agent.
Typical controls — stronger identity checks for SIM changes; notification to the old SIM and email; cooling-off periods for high-risk changes; exposing SIM-change recency to banks (for example through the GSMA Open Gateway / CAMARA SIM Swap API).

The Trade-offs

Tension	What pulls one way	What pulls the other
False positives vs losses	Lower thresholds catch more fraud, sooner	Every false alert costs analyst time; every wrongly blocked genuine customer costs revenue and trust
Friction vs protection	Step-up checks for SIM changes and large top-ups stop takeover and payment fraud	The same checks slow down every genuine customer and push some to competitors
Real-time vs batch detection	IRSF and SIM-box losses grow by the minute; only real-time feeds (OCS, signalling, NRTRDE) limit them	Real-time detection is costlier and sees less context; batch analysis finds patterns across weeks that real-time rules miss
Automation vs investigation	Automated blocks act in seconds	An automated block on the wrong customer is a service outage the operator caused

Architecture decision

An enterprise account scores high for IRSF at 02:00: international calls jumped from ~10 a day to hundreds in an hour. What should happen automatically?

Block the account
Choose when The destinations are on a high-risk range list and the pattern matches confirmed IRSF — the loss per hour outweighs the cost of a false block.
Restrict international calls only
Choose when The signal is strong but the account also carries legitimate domestic traffic you cannot afford to cut overnight.
Challenge and monitor
Choose when The destinations are unusual but not high-cost, and a named contact can confirm quickly.

Breaks if The policy was never agreed with the business: the analyst on nights has no authority to act, and the carrier invoice for the weekend arrives weeks later.

Industry context

Operators share fraud intelligence — high-risk number ranges, new patterns, stolen-device lists — through industry bodies such as the GSMA Fraud and Security Group and the Communications Fraud Control Association (CFCA). There is no TM Forum Open API dedicated to fraud management; fraud platforms consume usage (TMF635), customer and account (TMF629, TMF666), product inventory (TMF637) and payment (TMF676) data alongside network feeds.

Try It

Fraud management simulation

Fraud asks whether someone is deliberately abusing the service, account, network or payment system. Revenue assurance asks a different question — whether our own systems lost legitimate revenue.

An attacker moves the victim’s number to a SIM they control, then uses it to pass one-time-code checks elsewhere.

10 stagesFictional customers · illustrative figures

Detect
Decide
Respond

Twenty minutes after a SIM replacement, the same account sees a password reset, a login from a new device in an unfamiliar city and a high-value handset order on account credit. Each event alone is ordinary; together they are the classic takeover sequence.

Signals vs baseline

Signals appear when the detection engine evaluates the alert.

Investigate the alert

The alert pauses at Decision management. You take the decision.

Try it: pick a scenario, read the signals, investigate the alert and decide.

Fraud, Revenue Assurance and Dunning Side by Side

Four functions, four questions

	Revenue Management	Revenue Assurance	Fraud Management	Dunning & Collections
Objective	Create and collect revenue	Protect revenue integrity	Detect and prevent abuse	Collect billed revenue
Core question	What should we charge?	Did we capture what we should?	Is this activity legitimate?	Has what we billed been paid?
Main flow	Product → usage → charge → bill → payment	Reconcile the entire chain	Activity → detection → decision → action	Invoice → due → remind → restrict → collect
Primary risk	Incorrect charging or billing	Revenue leakage (and overcharging)	Fraud loss	Bad debt
Typical response	Charge, bill, collect	Investigate, reconcile, recover	Allow, challenge, restrict, block	Remind, restrict, suspend, collect

Key Takeaways

RA asks whether our own systems lost legitimate revenue; Fraud Management asks whether someone is abusing the service, account, network or payment system
The architecture runs from activity through ingestion, enrichment, detection (rules + ML), scoring and decision to allow / challenge / restrict / block, then case, investigation, recovery and rule improvement
Five recurring patterns: SIM swap / account takeover, IRSF, subscription fraud, payment fraud and device / SIM fraud — each with its own signals and controls
Every control trades fraud loss against false positives and customer friction; real-time detection is needed where losses grow by the minute
A fraud case that ends in collections is still fraud — classifying it as bad debt hides the pattern