AI 服务暂时不可用，以下为来源正文，待恢复后补全翻译。
The Fraud Analyst AI Coworker: Detecting Telecom Fraud in Real-Time on One Platform | Databricks Blog Skip to main content 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 billion1, 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 year2. Breaches are getting more expensive too; the global average cost of a data breach hit a record $4.88 million in 20243; 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 routine1. 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 operational store is always working off a stale snapshot — and "stale" compounds fast when your adversary is actively mutating behavior hour by hour. The pipeline is brittle (a schema change upstream breaks it), expensive to maintain, and worst of all, slow to repair;every hour it's down is an hour your decision engine is running on yesterday's intelligence against today's attack. The models and context that make detection smart end up stranded one hop away from the decision engine, exactly when speed matters most. Put an AI agent on top and it inherits the same gap, just with higher stakes: either it reasons without the rich OLAP context it needs — fast but blind — or you copy sensitive gold data out to reach it, trading governance for access. Neither option holds up against an adversary that's already moved on by the time your architecture catches up. How Databricks solves for this The fix has to attack the actual bottleneck: the hop between where intelligence lives and where decisions get made. Lakebase, our managed Postgres engine integrated into the unified environment, eliminates the traditional OLTP/OLAP split entirely. Gold tables in the lakehouse sync continuously into Lakebase, giving the real-time scoring engine sub-millisecond feature retrieval — right alongside the same analytical models that generated them. There's no batch job standing between the decision engine and the intelligence it needs, which means no stale snapshot and no brittle pipeline waiting to break on the next schema change. When a model starts drifting, the fix propagates at the speed the drift demands, not at the speed of the next scheduled sync. Meanwhile, our agentic platform and Genie let analysts analyze historical incidents, synthesize operational playbooks, and automate complex investigative work — closing the monitor-tune-redeploy loop faster, so the gap between "fraudster changes behavior" and "model adapts" shrinks from days to something much closer to real time. With Databricks Apps, teams can rapidly deploy custom operational tools on this same unified architecture, instead of waiting on a separate build cycle every time a new fraud pattern demands a new tool. And because it's one architecture rather than two systems stitched together, an AI agent built on top doesn't face the earlier trade-off between reasoning with rich context and preserving governance. A single plane under Unity Catalog manages governance, lineage, and security from raw network ingestion through to the live transaction decision — so speed and control stop being opposites. Compliance leaders get full lineage, engineering teams get an architecture that can actually keep pace with an adversary that doesn't wait around. What we built: solution accelerator Databricks built a Solution Accelerator for telecom fraud, covering the full lifecycle from raw data to an analyst queue to the executive dashboard. The pipeline. The solution includes a pipeline with a medallion architecture (Bronze → Silver → Gold) that generates realistic transaction, device, and network Call Detail Record data at scale. Additionally, a risk engine scores every transaction against rules like impossible travel, cell/IP mismatch, rapid cell-tower hops, roaming anomalies, and device emulation, the same category of signals that catch SIM box and SIM-swap fraud in production. Score threshold route transactions to one of three outcomes: auto-approve, queue for analyst review, or auto-block. The fraud analyst workbench app showcases different fraud workflows with three role-based views built on the same governed data: Executive - financial P&L impact, quarterly trends, regional risk distribution, and a Genie Space for a leader to ask questions in natural language like "which regions had the most SIM-swap cases this quarter?" and get governed, data-backed answers - no analyst or SQL required. Management - Ticket pipeline health, a 30-day AI forecast, fraud engine performance, and SLA tracking, so managers can staff analyst capacity proactively instead of reactively. Analyst - a case queue and device/case detail view backed by a tool-calling AI investigation Genie agent that reads case history, risk rules, and policy together, then recommends approve, deny, or escalate - and a Knowledge Assistant trained on the company's fraud playbook for procedural questions like escalation thresholds and documentation standards. The bigger pattern None of the individual pieces here - a risk-scoring pipeline, an AI agent, a governed catalog - are unique. What's different is running all of them on one platform instead of stitching together a fraud engine, a separate feature store, a BI tool, and a bolted-on AI layer, each with its own governance model and its own latency tax. For telecom operators, the opportunity is huge. It's recognizing that the infrastructure built to protect the business is the same infrastructure that can turn network data into a new revenue line. Deploy the Solution Accelerator in your environment: GitHub - databricks-industry-solutions/fraud_prevention_in_telco Clone it, deploy the pipeline, and stand up the analyst workbench in your own workspace - the industry-specific logic lives in a single configuration file, so the same architecture retargets to fintech, insurance, or e-commerce fraud with no changes to the core platform. To go deeper, reach out to your Databricks account team to provision Lakebase, creating synced tables, configuring a fraud-domain Genie Space, and building the investigation app. Citations 1 Co [truncated for AI cost control]