Solution Atlas
SpecialisedUser storyConsultative playbook

We need real-time fraud detection on transactions, not batch

Fraud losses are rising and the current batch detection misses the window to intervene. The team wants real-time scoring on every transaction with the model retraining as patterns shift, and alerts dispatched within seconds rather than overnight.

Trigger
Fraud loss escalation; batch detection limits exposed.
Good outcome
Fabric Real-Time Analytics streaming pipeline, model scoring inline, alert dispatch under 10 seconds.
Diagnostic discovery

Signals this story fits

Observable cues that confirm the conversation belongs here.

  • ·Fraud losses rising and the batch-detection pattern missing intervention windows
  • ·Business teams asking for real-time signal
  • ·No streaming infrastructure in place
  • ·ML models running in batch mode only
  • ·Customer-service team notified of fraud after the fact

Questions to ask

Open-ended, SPIN-style — each one has a reason it matters.

  1. 1.What does your current fraud detection process look like end-to-end?

    WhyEstablishes the latency baseline and surfaces where the gap lives.

  2. 2.What is the latency from transaction to detection today?

    WhyAnchors the business case. Hours-to-days vs sub-second is a different conversation.

    Listen for: “overnight batch” · “next-day report” · “we do not know”

  3. 3.What is the rough fraud loss baseline annually?

    WhySets the scale of the opportunity. ROI on real-time is fraud-loss-driven.

  4. 4.Which transactional systems would feed real-time detection?

    WhySurfaces the ingest surface area and the integration challenge.

  5. 5.Do you have ML capability for real-time scoring, or only batch?

    WhyDifferent platforms. Batch ML on Databricks or Foundry; real-time scoring needs an online endpoint.

  6. 6.What is the operational cost of false positives versus missed fraud?

    WhyTunes the model precision/recall trade-off.

Baseline → target architecture

TOGAF-style gap framing — what we typically see today, and what the proposed end state looks like. The gap between them is the engagement.

Baseline architecture

Transactions land in a data warehouse via overnight batch. Fraud rules run against batch data with hours-to-days latency. ML scoring happens offline; manual review queues. No streaming infrastructure. Customer-service notified of fraud after the fact — by which point the loss has been realised.

Typical concerns

  • ·Detection latency exceeds the intervention window
  • ·Fraud losses growing faster than detection improvements
  • ·Batch ML cannot adapt to fast-moving fraud patterns
  • ·Customer experience suffers when fraud is detected post-event
  • ·No clear path to streaming infrastructure

Capability gaps

  • ·Streaming substrate for transaction events
  • ·Real-time ML scoring endpoint
  • ·Alert dispatch within seconds
  • ·Streaming + batch reconciliation in unified storage
  • ·Model lifecycle tied to drift detection
Target architecture

Fabric Real-Time Analytics ingests the transaction stream via Event Hubs. KQL queries surface anomalies in seconds. ML scoring via a Databricks Mosaic AI online endpoint with the model lifecycle anchored in Unity Catalog. Alerts dispatched to fraud operations within seconds. Streaming and batch reconciled in OneLake for downstream analytics. Model drift detection automated with retraining cadence.

Key capabilities

  • Streaming ingest via Event Hubs
  • Real-time KQL anomaly detection
  • Real-time ML scoring endpoint
  • Streaming + batch reconciliation
  • Model lifecycle with drift detection

Enabling SKUs

Resolved in the ‘Recommended cards’ section below.

Architecture decisions

Each decision is offered as explicit options with trade-offs — Hohpe's “selling options” principle. A safe default is noted where one exists.

  1. Decision 1.Streaming substrate — Fabric Real-Time Analytics vs Event Hubs + Stream Analytics vs Databricks Streaming

    Fabric Real-Time Analytics (KQL DB)

    When it fitsFabric is the strategic platform; KQL skills available; OneLake reconciliation needed.

    Trade-offsTied to Fabric capacity; KQL learning curve.

    Event Hubs + Stream Analytics

    When it fitsLighter-weight streaming; SQL-based transformations sufficient.

    Trade-offsLess native lineage; separate billing.

    Databricks Structured Streaming

    When it fitsExisting Databricks investment; Spark-based streaming patterns.

    Trade-offsNo native KQL surface; separate observability.

    Default recommendationFabric Real-Time Analytics for the streaming surface and Databricks Mosaic AI for the ML scoring layer. Event Hubs as the ingest transport.

  2. Decision 2.ML serving — Mosaic AI online endpoint vs Foundry endpoint vs custom

    Databricks Mosaic AI

    When it fitsModel training and lifecycle on Databricks; Unity Catalog governs the model.

    Trade-offsTied to Databricks workspace.

    Azure AI Foundry endpoint

    When it fitsModel lifecycle on Foundry; Azure-native estate.

    Trade-offsLess native lineage if training data on Databricks.

    Custom (Azure Functions + ONNX)

    When it fitsLatency-critical; cost-sensitive at very high volume.

    Trade-offsOperational overhead; bespoke MLOps.

    Default recommendationMosaic AI if training data on Databricks; Foundry if Azure-native; custom only for extreme latency or cost requirements.

  3. Decision 3.Alert dispatch — direct to fraud ops vs SOAR-routed

    Direct to fraud ops console

    When it fitsFast iteration; fraud team owns the response.

    Trade-offsTight coupling; harder to evolve.

    SOAR-routed (via Sentinel or Logic Apps)

    When it fitsAlerts trigger automated workflows (card freeze, customer notification, case creation).

    Trade-offsAdditional latency; SOAR engineering needed.

    Default recommendationDirect to fraud ops for the first 6 months while detection precision stabilises; SOAR-routed once playbooks are validated.

Low-risk trial — proof of value

8-week real-time scoring pilot on one transaction class

8 weeks

Event Hubs provisioned for one transaction class. Fabric Real-Time Analytics KQL database stood up. Databricks Mosaic AI online endpoint deployed with the existing batch fraud model migrated to real-time scoring. Alert dispatch to fraud ops within seconds. Streaming and batch reconciliation validated in OneLake.

Success criteria

  • Transaction-to-detection latency below 5 seconds P95
  • Real-time fraud model serving online with parity or better than batch baseline
  • Streaming + batch reconciliation matching to within 0.1%
  • Fraud ops actioning real-time alerts on at least one intervention scenario

InvestmentFabric capacity (existing or trial F32) + Event Hubs throughput + Databricks Mosaic AI endpoint. Estimated ~€10–18k/month for the trial scope. Batch detection continues running during pilot.

Proof metrics

  • ·Detection latency under 5 seconds P95
  • ·Fraud loss prevented (measured against baseline)
  • ·False positive rate at or below batch baseline
  • ·Model retraining cadence operational

Recommended cards

The SKUs and capabilities most likely to be part of the solution, with the editorial rationale for each in the context of this story. Add the ones that fit your situation.

Why for this story

Real-Time Analytics ingests the transaction stream and runs KQL anomaly detection in seconds. OneLake provides the unified storage substrate for streaming + batch reconciliation, so the same data underlies real-time alerts and downstream analytics.

Why for this story

Mosaic AI provides real-time ML scoring with the model lifecycle (Unity Catalog registry, drift detection, retraining cadence) that fraud detection needs to stay ahead of evolving patterns.

Back to Real-time & event-driven data