Global losses from telecom fraud in 2025 are estimated at approximately $41.82 billion (compared to $38.95 billion in 2023), according to the CFCA Global Fraud Loss Survey. This figure clearly indicates that classic protection methods based on reactive analysis are no longer capable of shielding operators from financial losses. Modern fraud has become high-speed and technologically advanced. When attackers launch an IRSF (International Revenue Share Fraud) attack, every second counts. If an operator discovers an incident only after generating and exporting CDR (Call Detail Records) files, the financial losses become irreversible.
The main issue lies in architectural isolation. Threat detection systems often function separately from call processing infrastructure (softswitch) and billing. Without direct API connectivity and low-latency interaction between these three components, it is impossible to stop a transaction or terminate a session in real time. To effectively counter fraud, operators must move from isolated security tools to an integrated engineering approach.
Anatomy of millisecond fraud: why CDR analysis no longer protects operators
Historically, telecom operators relied on CDR file analysis, which was performed at specific intervals (from 15 minutes to several hours). However, in the context of modern high-speed attacks, this approach is obsolete. A typical IRSF scheme involves generating hundreds of simultaneous calls to Premium Rate Numbers via compromised client PBXs. Attackers drain traffic to expensive destinations in minutes, profiting from interconnect fees, while the operator receives a bill from a transit partner that must be paid.
In addition to IRSF, Subscription fraud remains a serious threat, causing approximately $5.31 billion in annual losses according to CFCA data. Attackers use complex manipulations and forged identifiers that are difficult to detect at the registration stage without instant verification through external databases and scoring systems.
According to the ENISA Threat Landscape 2025 report, phishing and vulnerability exploitation remain the leading vectors for initial system access. Once access to internal subscriber management systems is gained, attackers can change credit limits, activate non-existent services, and initiate unauthorized traffic that billing perceives as legitimate.
Architectural triangle: connecting softswitch, billing, and anti-fraud systems
To prevent fraud at the moment of its occurrence, three key elements of the telecom infrastructure must be combined into a single control loop:
- Softswitch: responsible for signaling (SIP) and direct media traffic routing. It acts as a Policy Enforcement Point that can block or terminate a call.
- Billing system (OCS/BSS): controls the subscriber's balance, tariff plan, active services, and credit limits in real time.
- Anti-fraud platform (FMS): analyzes behavioral factors, number reputation, geographic anomalies, dialing speed, and signaling parameter compliance.
Communication between these systems must occur via low-latency interfaces (API) with a response time not exceeding 50–100 milliseconds. When a SIP INVITE request reaches the softswitch, the switch should not route the call further into the network until it receives confirmation from the anti-fraud system and billing. If the anti-fraud module detects signs of IRSF, it immediately returns an instruction to the softswitch to reject the call.
Integration in practice: system interaction scenarios for IRSF detection
During an active call, a subscriber may exceed allowed limits or exhibit anomalous behavior. The billing system (OCS) continuously tracks balance depletion. If the rate of spending increases sharply, the OCS sends a trigger to the anti-fraud system. The latter analyzes the subscriber's current sessions on the softswitch and, if the threat is confirmed, initiates a SIP BYE command for immediate forced termination of all active connections.
For telecom operators and enterprise clients, the Intecracy Group alliance (a network of independent companies linked by partner agreements and share exchanges) offers design and modernization of the telecom core (VoIP, SIP routing, BSS/OSS). Integration solutions can be built on the UnityBase platform (a joint development of Intecracy Group companies; InBase is a key, but not the only, developer). The platform provides a unified Domain metadata model, automatically generated REST API, and built-in security mechanisms (RBAC, Row-Level Security, and deep Audit Trail), which allows for the creation of a secure integration layer with minimal transaction processing latency.
Transitioning to API-first and ODA: rebuilding BSS/OSS
Modernizing a telecom operator's infrastructure is often complicated by the risk of disrupting critical billing processes. Architecture can be built on the principles of Open Digital Architecture (ODA) from TM Forum. ODA aims to replace monolithic BSS/OSS with a microservice-based, componentized architecture where each module interacts with others via standardized API-first interfaces.
It is important to note that transitioning to ODA does not in itself guarantee complete network security—it is an architectural approach, not a ready-made security tool. However, it creates a flexible foundation for an intermediate integration layer (API Gateway) that aggregates requests from the softswitch and redirects them to billing and the anti-fraud platform in parallel.
STIR/SHAKEN and call authentication: technology limitations
One of the tools for combating number spoofing in SIP networks is the STIR/SHAKEN technical framework, described in FCC reports. It is based on adding a digital signature to the SIP Identity header, which allows the receiving operator to verify the authenticity of the Caller ID during incoming traffic processing.
Although STIR/SHAKEN reduces the risks of number spoofing, it does not eliminate the fraud problem entirely. The technology confirms the authenticity of the identifier but does not protect against calls from legitimate yet compromised devices. Therefore, authentication must always be accompanied by behavioral analysis.
| Scenario | Integration point | Target latency (SLA) | Security outcome |
|---|---|---|---|
| Pre-call authentication | SIP INVITE -> Softswitch -> Anti-fraud (API) | < 50 ms | Call blocking based on Caller ID reputation (STIR/SHAKEN) before switching begins. |
| Real-time limit control | Billing (OCS) -> Anti-fraud -> Softswitch | < 100 ms | Immediate termination of an active session upon credit limit exhaustion or detection of an anomalous IRSF spike. |
| Post-call behavior analysis | CDR -> Billing -> Anti-fraud (Batch) | < 5 minutes | Updating subscriber risk profiles, detecting Subscription Fraud, and adjusting routing rules (LCR). |
To ensure business resilience, modern telecom operators must abandon isolated security systems. Only deep integration of the signaling core, billing, and analytical anti-fraud tools allows for the construction of a proactive protection system.
FAQ
How can an anti-fraud system be integrated with billing without reducing call processing performance?
This is achieved through parallel request processing via an API-first architecture. Instead of sequential polling, the softswitch sends an authorization request that is processed in parallel by billing (balance check) and the anti-fraud platform (risk analysis) within an SLA of 50–100 ms.
Which architectural principles help optimize an operator's BSS/OSS systems?
Modernization often relies on the Open Digital Architecture (ODA) from TM Forum, which involves replacing monolithic billing and support systems with a componentized, microservice-based architecture using standardized open APIs.
Does STIR/SHAKEN guarantee complete protection against telecom fraud?
No. STIR/SHAKEN is a technical framework that allows for the verification of Caller ID authenticity in SIP traffic (protecting against direct number spoofing). It does not detect fraudulent actions from compromised legitimate PBXs or identifiers, so it must be used in conjunction with behavioral anti-fraud analysis.