Your roaming revenue is leaking. Not all of it — but somewhere in the CDR stream between your network and your wholesale partners' invoices, tariff mismatches, partner-settlement disputes and subscription fraud are quietly draining margin. By the time you discover the leak, you have already written it off as a cost of doing business. The signals were there the whole time, sitting in the call detail records as they landed. Nobody read them in time.
This is the gap that real-time models close. The same OSS/BSS data you already collect — CDRs, alarms, RAN counters, subscriber records — carries the signature of every leak. Reading it as it streams, rather than reconciling it weeks later, is the difference between holding revenue on settlement day and arguing about a credit note three months after the money is gone.
The Hidden Cost of Roaming Revenue
Roaming is a precision business. You sign an interconnect agreement with a partner in another country, define the tariffs per service — SMS, data, voice — and agree on settlement terms. The roaming subscriber makes a call or sends data. Your network routes it via the partner. The partner's network executes it and sends you a CDR, a call detail record, that says: this subscriber, this service, this duration, this charge.
Weeks later you receive an invoice. You pay it. Or you receive a claim that you owe more, and you pay again.
The problem is that CDR streams are noisy. A roaming call that should have been billed at one agreed rate arrives in your invoice at a higher one. A subscriber makes ten calls while roaming in a high-rate country; nine are legitimate, one is a SIM-swap attack on the account by someone in a different country, and you do not see it for weeks. A partner's billing system glitches and sends duplicate CDRs for an hour of traffic. You pay. The partner sends a credit three months later. The revenue is gone, customer goodwill is damaged, and your margins are thinner.
This is where real-time models live.
CDR Anomaly Detection: Catch the Fraud Before Settlement
A roaming fraud attack — SIM-swap, IRSF, toll bypass — leaves a signature in the CDR stream. A compromised account suddenly makes calls to high-rate countries the subscriber has never dialed before. Multiple roaming calls stack in a single hour across different countries, which is statistically impossible for one human. Calls originate from a device that is geographically impossible to have moved that fast. Premium SMS goes to short codes known as fraud vectors.
The legacy approach is batch analysis. You collect CDRs for a month, build a reconciliation report, and hunt anomalies. By then the fraud has occurred, the revenue is gone, and the partner has already been paid — or worse, you have already remitted through an automated clearing house.
Real-time detection works differently. You ingest the CDR stream as it lands — every call, every SMS, every roaming event — and score it against learned patterns and known fraud typologies. A SIM-swap is caught in the first roaming call made on the compromised account. IRSF is flagged when call volume to a specific high-rate partner spikes in a way that does not match the subscriber's history. A tariff mismatch is caught the moment the CDR arrives, not when an auditor compares invoices.
The outputs land in two places: in the NOC, the network operations center, for immediate intervention on the network side, and in the revenue-assurance system for billing teams to investigate and correct the charge before settlement happens.
Tariff Mismatch and Partner-Settlement Integrity
You sign an agreement with a partner: voice calls in a given country cost you an agreed per-minute rate. The partner sends a CDR showing a higher rate. You pay the overage. Next month, the same pattern. This is not always fraud on the partner's side — sometimes it is a genuine update to the agreement that was supposed to be coded into their billing system and was not. Sometimes it is a configuration error on their side. Either way, you catch it weeks later and argue about it.
The answer is not to trust the partner. It is to read the CDR against your own tariff matrix, in real time, and flag any mismatch. A call billed above the agreed rate is immediately surfaced. A data session charged at a rate that does not match your contract is flagged. An SMS charged in a currency other than the agreed settlement currency lands in a rejection queue.
This is what holds roaming revenue on settlement day. Not fighting about the invoice after it arrives, but preventing the overage from entering the invoice in the first place.
The model applies your tariff agreements — those rules are explicit, not learned from data — to every CDR in the stream. When a record breaches the agreement, it lands in an exception queue with the root cause attached: the expected rate, the billed rate, the route, the duration. A revenue-assurance engineer reviews it, contacts the partner if needed, and either corrects the record or escalates the dispute with a clear evidence trail.
- Real-time
- Scoring on CDR and alarm streams
- OSS/BSS
- Runs on data you already collect
- Pre-settlement
- Anomalies surfaced before you pay
- 10–15%
- Industry-benchmark churn reduction
Cross-Domain Correlation: When Network Alarms Hide Revenue Leaks
A cell site goes down. The NOC is alerted. Operations teams reroute traffic. Service is restored. But during that window, a large number of roaming calls failed midstream. Some were billed as complete calls by the partner. Some were billed as partial calls. Some are disputed by the subscriber. The roaming revenue attached to that site during that window is now ambiguous.
This is where real-time cross-domain correlation matters. When the cell-site alarm fired, it was captured in the alarm stream. When roaming CDRs started failing, that was captured in the CDR stream. A correlation engine that runs across both streams can flag: roaming CDR anomalies at this site during this window correlate to a documented cell-site outage — these records need special handling.
The effect is that revenue-assurance teams have a clear root cause. The outage was not fraud. It was not a tariff mismatch. It was an infrastructure fault that produced genuine billing artifacts. The records are either corrected against the outage timeline or escalated to the partner with an evidence trail that says: here is the alarm log showing the fault, and here are the affected CDRs.
The models that do this run on your OSS/BSS data — the network-operations and billing systems already in your network. They are specialized for point anomalies (one CDR that looks wrong), contextual anomalies (a CDR that looks wrong given the network's state), and collective anomalies (a group of CDRs that together look like a billing glitch). Each model is tuned to the kind of noise you actually see on your roaming streams.
When roaming revenue leaks, it is caught in the CDR stream as an anomaly or in your partner's invoice as an overage. Real-time detection eliminates the gap between the leak and the discovery.
Subscription Fraud: SIM-Swap and Premium SMS
SIM-swap attacks on roaming subscribers are a specific flavor of the fraud that hits roaming revenue hard. An attacker compromises a subscriber's account, swaps the SIM, and immediately initiates high-cost roaming calls or premium SMS to monetize the account before the legitimate subscriber notices. The calls go to high-rate countries or premium short codes the attacker controls, creating artificial revenue for themselves and a liability for you and your partner.
The signature is unmistakable in real time: a subscriber who has never roamed before suddenly makes calls to three countries in fifteen minutes. A subscriber's usual roaming profile — one call to their home country per month — suddenly becomes ten calls per day to an IRSF target country. Premium SMS fires off to short codes that are known fraud vectors.
Real-time detection catches these in the first roaming event. A scoring model trained on legitimate roaming patterns, subscriber-specific baselines and known fraud vectors flags the anomaly the moment the CDR arrives. An alert lands in the NOC and in the fraud-prevention system. The fraud team can immediately suspend the SIM, contact the subscriber, and prevent further damage. The roaming partner can be notified so they do not bill for the fraudulent traffic.
The cost of not catching this is the full roaming revenue for the fraud session, plus the cost of reversing the charges and managing the customer-support fallout. The cost of catching it — a real-time model running on the CDR stream — is a fraction of the first incident prevented.
Service Assurance: The Open Loop That Costs You
Your network operations center today works like this: alarms come in. A noise-reduction engine filters the most obvious duplicates. A human engineer reads the alert and decides whether it is real. If it is real, they raise a ticket and page someone to investigate. That investigation takes time. Meanwhile, the network condition that produced the alarm might be spreading or correcting itself on its own.
The same thing happens in revenue assurance, in parallel: a billing discrepancy is noticed, sometimes weeks later, and a human investigates.
The gap between "network fault occurred" and "revenue impact corrected" is where leakage lives. A cell-site failure causes roaming CDR errors. The network team sees and fixes the failure. The revenue team never connects the two. The billing error stands as written-off cost.
The models that close this loop run on your OSS/BSS streams — your RAN counters, CDR streams, alarms and care-contact data. They correlate a cell-site alarm with roaming CDR anomalies. They surface the probable root cause in the NOC console. They flag the same anomalies to the revenue-assurance queue with a link: these records are likely secondary effects of an alarm at this site — investigate them together.
This is what explainability looks like at carrier scale. Not a score, but a reason. Not just "this is anomalous," but "this is anomalous because the network was in a known fault state at the time." A network engineer and a revenue-assurance engineer can then collaborate on a fix instead of investigating independently and missing the connection.
Where to start
The assessment phase for roaming revenue integrity is a data-readiness audit. You map your CDR sources — which partners send clean streams, which ones are delayed or incomplete. You map your OSS/BSS data: which alarms are routed where, how fresh your subscriber records are, where your tariff agreements are maintained. You then profile your roaming CDRs and identify your highest-leakage categories: are your biggest losses coming from tariff mismatches with one partner? From IRSF to a specific country? From SIM-swap on one particular subscriber segment?
The assessment output is a ranked roadmap: which roaming anomaly-detection use case pays back first, whether it is tariff-match integrity or fraud prevention, sequenced against your data readiness. You will typically have a clear 4–6 week roadmap that names the first model to build and the operational change it requires — a new queue in your revenue-assurance system, a new alert type in your NOC, a new closed loop with a wholesale partner.
You then build that first model against your live CDR stream, integrate it with your existing OSS/BSS systems, and pilot it on real roaming traffic. The moment the first fraud is caught live, the model is hard-wired in. The moment the first tariff mismatch is corrected before settlement, the revenue is kept. That is when it stops being a proof of concept and starts being a line item in your P&L.
“CDR streams hide roaming fraud and settlement leakage in plain sight — until you read them in real time.”
Get in touch
Put RealAI’s applied-AI team on your hardest data problem.
We help enterprises move from pilots to production — sovereign models, governed data, and agents you can audit. Start with a value-first assessment.