The Fraud Analyst AI Coworker: Detecting Telecom Fraud in Real-Time on One Platform

The Fraud Analyst AI Coworker: Detecting Telecom Fraud in Real-Time on One Platform | Databricks Blog Skip to main content

Summary

As fraudsters use agentic AI to attack at machine speed, defense teams must accelerate response times using AI coworkers. Additionally, real-time network telemetry can be used as fraud signals and improve fraud detection models.

Databricks unifies Fraud detection stack on a single platform: Lakebase removes the analytical and transactional split for faster data sync, Databricks Apps powers a custom case-management workbench, and Genie as an AI coworker, provides natural-language querying over governed fraud data; This unified stack supports fraud detection team to work more efficiently against fraudsters.

Our Telecom Fraud Prevention Solution Accelerator deploys this entire pipeline, risk engine, workbench, and AI investigation agent into your workspace via Databricks Asset Bundles, adaptable to other industries.

Background According to the Communications Fraud Control Association's 2025 survey, telecom fraud losses have climbed to $41.82 billion 1 , and the broader fraud economy is growing fast: U.S. consumers alone reported losing more than $12.5 billion to fraud in 2024, a 25% jump in a single year 2 . Breaches are getting more expensive too; the global average cost of a data breach hit a record $4.88 million in 2024 3 ; Every dollar of fraud costs a carrier roughly 3.4x once you count chargebacks, replacement costs, and the operational overhead of investigating it. A telecom account is no longer just a phone plan. It's the gateway to many assets that a subscriber owns: banking apps authenticate through phone number, password resets flow through it, and two-factor codes land on it. Consequently, when a fraudster compromises an account through phishing, social engineering, or using credentials from an old breach, the clock runs fast. Within minutes they can execute a SIM swap, change the billing address, order expensive devices, and pivot into linked financial accounts often before the victim or the carrier notices anything at all. Meanwhile, the fraud team is still waiting on last night's batch job to complete. That dichotomy, fraud moving at machine speed while detection moves at batch speed, is the inhibitor. For an executive team, fraud is not a security footnote. It’s revenue leakage, regulatory exposure, accelerated churn, and an operations tax that rarely shows up cleanly in a loss report. Every major fraud type succeeds for one of three reasons: It creates a data signature that has not been detected in time It exploits gaps between systems that don't talk to each other Or it thrives in the lag of batch processing.

Here's the reframe we think matters most: All three are data architecture problems that can be solved with a unified, real-time, governed data foundation. Defending the Business Account takeover and SIM swap attacks were up 240% in 2024 in Australia based on stockhead , and roughly 90% of them now happen with no contact with the actual victim. The fraudster's request simply looks legitimate. International Revenue Share Fraud pumps $4–7 billion a year into premium-rate numbers by looking like normal traffic. SIM box bypass fraud (~$3.1B/year) hides inside call patterns that seem routine 1 . In nearly every case, the signal that would detect this fraud already exists - it's just split across the six or seven systems (CDRs, CRM, billing, device/SIM, network, digital channel logs) that don't share a single query surface. Often sophisticated fraud types are processed in overnight batches when the attack window is measured in minutes while simpler fraud types such as spoofing can be caught real time. The human cost of that fragmentation compounds the financial one. Rigid rule-based systems flood analysts with false positives, so fraud teams spend hours investigating benign account changes while the sophisticated attacks executing at machine speed slip through. It's a daunting cycle: analysts drowning in alerts, genuine threats going undetected, losses mounting. Why the old architecture can’t keep up Most operators have invested heavily in fraud management systems that successfully block the known, well-understood attack patterns, and those systems are saving real money today. The opportunity isn't to rip those out, it's to augment them. But fraud is an adversarial game, not a static one — every pattern a model learns to catch is a pattern fraudsters are actively working to route around, and they do it fast. The gaps show up in exactly what existing fraud engines were never built for: cross-channel correlation, behavioral modeling, device emulation, and fraud patterns that evolve faster than a rule-change cycle can keep up with. Those gaps trace back to architecture, not effort — and architecture that can't move at the speed of the adversary is architecture that's already behind. The common thread in any anti-fraud system is that it will undergo adversarial drift, and it will happen on the fraudster's timeline, not yours. The moment a fraudster gets caught, they change behavior immediately — no delay, no courtesy window. That means the recall of any deployed model starts degrading right away, sometimes within 24 hours. In this environment, being outdated isn't a minor inefficiency, it's the difference between a model that catches fraud and one that's effectively blind to it. There is no such thing as "good enough for now" — a detection system is only as good as its last update, and the agility of the monitor-tune-redeploy loop isn't a nice-to-have, it's the whole game. This is exactly where most fraud operations lose the race. The typical pattern: an operational (OLTP) system handles live transactions, while a separate analytical (OLAP) system houses the actual intelligence: — the context, the historical queries, the fraud models, the dashboards data scientists refine every day. The problem is that the live risk engine can't reach into that analytical environment fast enough at decision time. Teams must then fall back on a slow, costly synchronization process — scheduled batch jobs that copy finished "gold" data (engineered features, model scores, risk signals) out of the OLAP warehouse and back into the operational database. That copying is the bottleneck, and in an adversarial-drift world, bottlenecks are where you lose. The...