Global losses from telecom fraud are projected to reach $41.82 billion in 2025, up from $38.95 billion in 2023 (according to the CFCA Global Fraud Loss Survey 2025). This trend is forcing telecom operators and large enterprise companies to radically rethink their service channel security. Traditional contact centers, which have relied on closed, monolithic BSS/OSS systems for years, face a difficult choice. Businesses demand efficiency and the immediate implementation of AI agents, intelligent voice assistants, and seamless omnichannel experiences. However, attempts to implement these tools often encounter critical vulnerabilities in VoIP traffic.
Modern contact centers are striving to balance the efficiency of AI-driven omnichannel interactions with the need to protect communications from sophisticated fraud, such as spoofing and subscription fraud. According to CFCA estimates, the use of genuine or stolen identities in subscription schemes causes $5.31 billion in annual industry losses. Effective customer service today is impossible without integrating innovations into a secure, modular core protected at the signaling level.
Anatomy of vulnerability: why modern contact centers are targets for fraud
A modern contact center is a complex, distributed system combining SIP trunks, interactive voice response (IVR) systems, automatic call distribution (ACD) mechanisms, and customer databases. When companies attempt to rapidly deploy new digital service channels through fragmented API integrations, they create an architecture with poorly secured touchpoints.
Attackers exploit these weaknesses for social engineering and financial fraud. The lack of reliable source authentication in traditional VoIP allows for call spoofing, bypassing initial verification stages. Global vulnerabilities in telecom infrastructure further complicate the situation. The ENISA Threat Landscape 2025 report highlights that the exploitation of legacy signaling protocols, such as SS7 and Diameter, remains a significant risk for mobile networks. This means relying solely on traditional verification methods (e.g., SMS passwords) when a customer contacts a center is becoming increasingly dangerous.
From monolith to ODA: how open architecture enables secure AI agent integration
The main obstacle to the secure implementation of artificial intelligence is the closed structure of monolithic BSS/OSS systems. Integrating a modern AI agent into such a monolith turns into an inflexible point-to-point scheme, where every system update can lead to service disruptions.
The solution is a transition to the Open Digital Architecture (ODA) concept, developed by the TM Forum consortium. ODA proposes replacing monolithic legacy systems with a component-based, API-first architecture. In this model, AI tools are connected as independent microservices that interact with the operator's core via standardized open interfaces. It should be noted that ODA is not a ready-made "off-the-shelf" solution that can be deployed instantly; it is a long-term strategy and a reference architecture for transformation.
Using ODA paves the way for the secure integration of AI agents via secure API gateways. This allows for precise control over the context of AI queries, logging every action, and restricting data access, which is critical for compliance with European legislation (AI Act).
Cryptography against spoofing: implementing RFC 8224 and SIP Identity in customer service
To protect the voice channel from Caller ID spoofing and verify the origin of incoming calls, the industry uses cryptographic mechanisms. The technical standard for this is IETF RFC 8224 (Authenticated Identity Management in SIP).
This standard defines the use of the Identity header in SIP messages. The header contains cryptographically signed information about the call's origin. When a subscriber calls a contact center, the initiating operator signs the call, and the receiving Session Border Controller (SBC) verifies this signature. If the signature is valid, the AI agent or contact center operator receives confirmation that the number has not been spoofed. It is important to understand that implementing RFC 8224 and related technologies (such as STIR/SHAKEN) only solves the Caller ID authentication problem. They do not eliminate fraud entirely and do not replace general risk management systems, as they do not protect against device compromise or social engineering.
Routing logic: blocking IRSF and registration fraud at the switch level
A contact center can become not only a victim of incoming attacks but also a tool for generating losses through International Revenue Share Fraud (IRSF). Attackers can exploit IVR logic or compromise SIP accounts to mass-forward calls to premium international numbers, earning a percentage of the call cost.
Minimizing IRSF requires embedding strict security rules directly into the contact center's call routing logic. This includes blocking international destinations by default, prohibiting unauthorized forwarding at the IVR level, and using monitoring systems capable of detecting traffic anomalies in real-time.
Architectural requirements matrix for modern contact centers
| Layer | Technology / Standard | Business Value |
|---|---|---|
| Signaling layer | Anti-spoofing via RFC 8224 (SIP Identity) | Prevents caller ID spoofing by attackers |
| Integration layer | Transition to ODA (Open Digital Architecture) API | Replaces monolithic links with flexible microservices for AI |
| Routing layer | Real-time IRSF control | Blocks unauthorized forwarding to premium numbers |
| Compliance layer | AI agent context control (AI Act compliance) | Ensures transparency and auditability of AI actions |
Architectural transition: how to modernize the core without interrupting business processes
For large operators (Tier-1/Tier-2) and enterprise companies, moving away from monolithic solutions must occur without risking business continuity. The best approach is to create a secure integration layer that handles data routing, security, and API orchestration.
To implement such large-scale transformations, the expertise of the Intecracy Group consortium is applied. Intecracy Group is an alliance of independent companies linked by partner agreements and share exchanges. The technological foundation for designing cloud-native architectures and modernizing legacy systems is often the low-code / model-driven platform UnityBase. This is a joint development of the consortium's companies, where InBase is a key, but not the only, developer.
UnityBase uses a unified domain model (Domain metadata), which allows for the rapid generation of REST APIs to connect AI agents and securely link new digital channels with existing legacy systems. The platform ensures architectural security through built-in row-level security (RLS) and attribute-level access control mechanisms, and maintains a detailed audit trail of every operation. For projects with high security requirements or high-load telecom environments, the platform's official page recommends using the commercial Enterprise or Defence editions. Corporate systems such as Megapolis.DocNet or Scriptum.DMS are built on the platform and can be integrated with operator voice gateways. This allows an AI agent or operator to automatically process incidents and manage documents during a conversation, while maintaining full control over data and compliance with corporate security standards.
FAQ
How does the RFC 8224 standard help protect a contact center from Caller ID spoofing?
The RFC 8224 standard defines the use of the Identity header in the SIP protocol, which contains cryptographically signed information about the call's origin. The receiving system verifies this signature, which allows for the authentication of the caller's number and protects the contact center from Caller ID spoofing.
What are the advantages of transitioning to Open Digital Architecture (ODA) when integrating AI agents?
Transitioning to ODA replaces legacy monolithic BSS/OSS systems with a component-based, API-first architecture. This allows for the secure integration of AI agents as independent microservices via standardized open interfaces, ensuring data access control and system flexibility.
How can IRSF (International Revenue Share Fraud) be prevented in call routing logic?
To prevent IRSF, it is necessary to implement security rules at the switch level: block unauthorized international destinations by default, prohibit automatic call forwarding via IVR to external numbers, and use monitoring to block anomalous activity in real-time.