Telecom fraud management (SIM-box, IRSF, Wangiri, SIM-swap, A2P SMS fraud)

Telecom operators lose revenue and customer trust to fraud that runs through their own networks: traffic that bypasses interconnect fees (SIM-box), calls pumped to premium numbers (IRSF), one-ring callbacks (Wangiri), hijacked phone numbers (SIM-swap) and grey-routed or spoofed business SMS. Fraud management systems score CDR, signalling and provisioning events in near real time, block suspect routes and numbers, and give fraud analysts ML-ranked cases. LLMs assist with case summaries and partner disputes; the decision to block customers or terminate partners stays with trained analysts and defined policy.

Problem & value

• Who: fixed and mobile operators, MVNOs/MVNEs, wholesale carriers, CPaaS/SMS aggregators, and enterprises with large PBX/SIP estates (toll fraud). Distinct from ANOM-025, which protects end users on their phones, and from ANOM-022 (bank-side scam payments); this use case is operator-side.
• Today: rule-based fraud management systems (FMS) with threshold alarms per destination, per subscriber and per route, plus manual investigation, test-call platforms and bilateral dispute handling. Rules require constant tuning; fraudsters rotate numbers, SIM ranges and routes within hours.
• Why AI helps: behavioural baselines per subscriber/route, unsupervised detection of new patterns, graph linkage of SIMs, devices and accounts, and automatic case enrichment reduce analyst triage time and shorten the window between fraud start and block.
• Scale of the problem: the Communications Fraud Control Association (CFCA) runs a periodic global telecom fraud loss survey, [1]. We do not quote loss totals here because the full survey is member-gated; consult the current CFCA survey for figures.

Variants

• SIM-box / interconnect bypass: SIM farms terminate international traffic as local mobile calls. Detection uses traffic-profile features (short, many-destination, uniform call patterns, no mobility, no data usage) and test-call confirmation.
• IRSF (international revenue share fraud): artificially inflated traffic to premium destinations, typically via hacked PBXs or abused subscriptions. Detection is velocity and destination-based, with fast blocking.
• Wangiri (one-ring) and callback fraud: high-volume ultra-short calls to many subscribers; detection at network level plus subscriber warning (see ANOM-025).
• SIM-swap and eSIM-swap / account takeover: detect abnormal SIM change, porting or eSIM profile transfer sequences; expose a SIM-swap signal to banks and fintechs via CAMARA-style network APIs [2][3] (ties into ANOM-022, ANOM-014).
• A2P SMS fraud: grey-route traffic, SMS pumping (artificially inflated traffic), sender-ID spoofing and smishing campaigns at SMS firewalls; for CPaaS providers also pumping against OTP endpoints.
• Subscription/identity fraud and handset fraud: synthetic identities, device financing fraud, mobile money fraud (e.g. in markets with large mobile-money use).
• Enterprise toll fraud: SMBs with SIP trunks/cloud PBX use the operator or UCaaS provider's spend caps and destination blocks; AI-based anomaly alerting is a feature of the provider rather than a project of their own.
• Not in scope: content-based protection of end users on-device (ANOM-025), law-enforcement interception (separate legal regime; not documented here).

How it works

1. CDR/signalling/SMS/provisioning streams
2. normalisation & enrichment (rate tables, number ranges, device DB)
3. streaming feature store
4. rules + supervised models (gradient boosting) + unsupervised anomaly detection + graph linkage
5. alarm scoring
6. auto-action (throttle/block/route change) or analyst case
7. LLM case summary
8. analyst decision
9. feedback labels
10. retraining

Key components: - Streaming ingestion of CDRs (seconds to minutes latency); latency drives how much IRSF loss is avoided. - Features: call duration distributions, answer-seizure ratio, destination entropy, B-number fan-out, time-of-day, per-SIM mobility/cell usage, data-vs-voice ratio, SMS sender/receiver ratios, conversion rates (OTP delivered vs. verified for pumping detection). - Models: gradient-boosted trees for labelled fraud types, isolation forest/autoencoders or per-entity baselines for novel patterns, graph clustering for SIM/device rings. - LLM layer: summarises evidence for a case, drafts partner dispute notes and internal reports, and answers analyst questions against the case record. It does not take blocking decisions. - Human-in-the-loop: analysts confirm blocks beyond automated safe actions (for example blocking a postpaid customer's service or terminating a carrier route), handle customer disputes, and label outcomes.

Data preparation

Needed data: call detail records, signalling and SMS logs, provisioning and SIM data, rate tables and number ranges, device databases and case outcomes. They typically live in mediation or billing systems, the HLR/HSS and SMS gateways, partly in file exports from carriers, and in analysts' spreadsheets.

Typical gaps: heterogeneous CDR formats between network elements, delays in feeds, missing labels for confirmed fraud, outdated rate tables and number ranges, duplicate subscriber identities, and access restrictions because CDRs are personal traffic data.

Preparation steps: normalise CDRs into one schema and stream them (see PREP-005, PREP-007), enrich with destination and rate references (PREP-012), build stable feature definitions per SIM, route and sender, harvest labels from past alarms and dispute outcomes (PREP-020) and define fraud categories (PREP-019). Create a test set of known fraud episodes with analysts (PREP-018). Pseudonymise subscriber identifiers for development and never send raw CDRs to external LLMs (PREP-022). Tools: Kafka or Redpanda, Flink, ClickHouse, dbt. About 40 to 50 percent of the effort goes into feeds and features; see GUIDE-003.

Implementation paths

Which path for whom

• enterprise (operators): A, because dedicated telecom fraud-management platforms cover bypass, IRSF, SMS and roaming fraud with partner data and mature integrations; B suits operators wanting custom features.
• developer: C, because Kafka, Flink and open-source anomaly detection allow a custom stack, with HW2 enough for summaries.
• smb (small MVNOs, CPaaS providers, resellers): A, because a managed fraud service or firewall gives protection without a data-science team.

Path A — Buy (off-the-shelf)

Dedicated telecom FMS / revenue-assurance platforms are the default for operators. Vendors include Subex (FraudZap, AI-powered fraud management covering bypass, SMS, subscription, roaming and IRSF [4]), Mobileum (risk management, roaming and signalling security), Enea/AdaptiveMobile Security (SMS and signalling firewalls), Syniverse, Cleartouch, Araxxe and Lanck Telecom (France, EU), and CPaaS-side tools from Infobip and Sinch (fraud guard / SMS pumping protection). Verify product lines and current ownership with each vendor, as the sector has consolidated. Choose A when you are an operator or MVNO without a large data science team; MVNOs often get fraud management from their MVNE. Check EU hosting, data residency and subprocessor terms.

Path B — Build on cloud APIs

Use a managed streaming + ML stack (Kafka/managed equivalents, a cloud feature store, gradient boosting and anomaly detection services) in an EU region, plus an LLM API (EU-hosted endpoints from major clouds or EU providers such as Mistral) for case summarisation only. Realistic for CPaaS providers, large enterprises and MVNOs that want custom features. Never send raw CDRs or subscriber identifiers to an LLM; send pseudonymised case evidence. Real-time blocking must not depend on an LLM call.

Path C — Self-host (open source)

Apache Kafka or Redpanda and Apache Flink for streaming; ClickHouse or Apache Druid for CDR analytics; XGBoost/LightGBM, PyOD or scikit-learn for models; a graph database (e.g. Neo4j, Memgraph) for SIM/device linkage; an open-weight LLM (e.g. Llama-class or Mistral-class models, verify current licences) for summaries on one workstation GPU. Telco CDR volumes are large, so storage and stream processing, not the GPU, are the cost driver. Sensible for tier-1/2 operators with data teams and sovereignty requirements; heavy ops effort. Signalling firewalls and test-call platforms still generally require specialised products.

Path D — Custom training

Worth it for operator-specific patterns: fraud-type classifiers trained on years of labelled alarms, per-route baselines, graph embeddings for SIM rings. Needs labelled case outcomes (hundreds to thousands per fraud type), stable feature definitions and drift monitoring. Fine-tuning an LLM is rarely necessary; retrieval over case history is enough.

State of the art (2026)

• Architecture: shift from batch rules to streaming ML with automated, reversible actions, and from per-vendor silos to shared platforms for CDR, signalling and SMS data.
• Network APIs: CAMARA, an open-source Linux Foundation project defining operator-exposed service APIs [2], includes a SIM Swap API that returns information about recent SIM pairing changes for a number [3]. Banks use such signals as an extra factor in payment and account-recovery risk decisions. Availability varies by operator and country.
• Agentic assistants: vendors market AI agents for fraud investigation (for example Subex's AI Agents Squad with a Fraud Investigative Agent [4]); treat these as analyst assistance and validate outputs against evidence.
• Generative-AI-enabled fraud: AI-generated voices and texts make social-engineering campaigns cheaper (see SEC-011); operator-side detection relies on traffic behaviour rather than content.
• Limits and failure modes: concept drift as fraudsters adapt; legitimate high-volume traffic (call centres, emergency-notification, marketing campaigns, roaming peaks) causing false positives; sparse labels; fraud that mimics normal usage; cross-operator blind spots (each operator sees only its own traffic); latency of CDR collection. Over-blocking disrupts customers and can breach service obligations.

Shared resources & combinations

• Shared building blocks: streaming ingestion, feature store, tabular ML and anomaly detection, graph analytics, case management and feedback loop, identical to ANOM-001 (card fraud) and ANOM-002 (AML); the same graph engine serves ANOM-004 (fake accounts and platform abuse).
• ANOM-022 and ANOM-014: SIM-swap and number-verification signals feed bank-side APP-scam and identity-proofing checks.
• ANOM-025: operator-side detection and on-device scam warnings complement each other (shared number-reputation data).
• SEC-002, SEC-005, SEC-006, SEC-011: smishing and phishing intelligence, user-behaviour baselines, network monitoring and deepfake-voice detection reuse features and threat feeds.
• ANOM-005: time-series anomaly methods for network telemetry are shared with industrial anomaly detection.
• Hardware: the streaming and storage tier dominates; a single HW2 GPU covers LLM summaries and embeddings. Real-time scoring runs on CPU.

Effort, cost & KPIs

• Path A: weeks to a few months to integrate feeds, then ongoing tuning; licence usually based on traffic volume or subscribers. Path B: months; cost drivers are streaming compute and storage. Path C: quarters; staff and storage. Path D: adds a data-science team and labelling effort.
• KPIs: fraud loss as share of revenue; time from fraud start to block; precision of alarms and false-positive rate on legitimate traffic; analyst cases per hour; share of auto-resolved alarms; recovered revenue through disputes; SIM-swap incidents leading to account takeover; customer complaints caused by wrongful blocks.

People & change

Start with management and the head of fraud or revenue assurance, then IT and network operations, who provide the feeds and carry out blocks, and IT security. The data protection officer must be involved because CDRs and traffic data are personal data and fall under telecommunications secrecy (TDDDG); a DPIA is likely at subscriber scale, and every vendor needs an Art. 28 GDPR agreement.

Works council: depends. It applies where analyst consoles log individual handling and performance (§87(1) no. 6 BetrVG); the fraud detection itself monitors traffic, not staff. Inform it under §90(1) no. 3 when work processes change. Small providers without a works council skip this step but should still consult staff.

AI literacy measures (AI Act Art. 4) should support analysts in reading alarm scores and in recognising that the LLM only summarises. Pilot with one fraud type, such as SMS pumping or IRSF, and run it in alert-only mode before enabling automatic throttling. Typical concerns are wrongful blocks of legitimate customers and alarm overload; address them with safe automatic actions only, analyst approval for blocks of postpaid service, and a complaint process. See GUIDE-005, GUIDE-011 and GUIDE-013.

Risks, regulation & compliance

• EU AI Act: typical fraud-detection systems are minimal risk. Annex III point 5(b) lists creditworthiness evaluation as high-risk but excludes AI systems used to detect financial fraud [5]. Telecom networks are not in the Annex III critical-infrastructure safety-component category unless the system acts as a safety component of the network, which this use case normally does not. Result: minimal, with Art. 4 AI literacy applying. Re-check if the scores feed decisions about access to essential services for natural persons (for example credit-like decisions on prepaid vs. postpaid eligibility).
• GDPR / ePrivacy: CDRs and signalling are personal data and traffic data. The German TDDDG and national implementations of the ePrivacy Directive and the Telecommunications Act permit traffic-data processing for fraud and misuse detection under specific conditions; confirm the legal basis (purpose limitation, retention limits, necessity) with the DPO and a telecom-law counsel. Automated blocking affecting individuals engages GDPR Art. 22 safeguards (human review and a path to contest). Do not analyse call content for this purpose.
• Sector law: telecommunications secrecy (Fernmeldegeheimnis), NIS2 and national telecom security rules, CLI/number-spoofing rules by national regulators (Bundesnetzagentur in Germany), and contractual interconnect terms for disputes.
• Risks and mitigations: wrongful blocks (reversible actions, allow-lists, fast appeal), model drift (monitoring and champion/challenger), insider access to subscriber data (role-based access, logging), LLM leakage (pseudonymise, EU hosting, no raw CDR in prompts).

Getting started

1. Quantify the baseline: fraud loss by type, mean time to detect and block, and alarm precision from your existing FMS.
2. Inventory data feeds (CDR latency, signalling, SMSC, provisioning) and agree legal basis and retention with the DPO.
3. Start with one high-loss type (typically IRSF or SIM-box) and add ML scoring alongside existing rules in shadow mode.
4. Add case management with feedback labels; then pilot LLM summaries on pseudonymised cases.
5. For SIM-swap, assess exposing CAMARA-style signals to bank or fintech partners and define SLAs and consent handling [2][3].

Sources

1. CFCA (Communications Fraud Control Association), insights and fraud loss survey page, https://cfca.org/insights-intelligence-2/ (accessed 2026-10; survey figures are in a member-gated PDF and are not quoted)
2. CAMARA project (Linux Foundation open-source network APIs), https://camaraproject.org/ (accessed 2026-10)
3. CAMARA SimSwap API repository, https://github.com/camaraproject/SimSwap (accessed 2026-10)
4. Subex, telecom fraud management and AI products, https://www.subex.com/ (accessed 2026-10)
5. EU AI Act Annex III, https://artificialintelligenceact.eu/annex/3/ (accessed 2026-10)