Real-Time Fraud & AML Detection

The problem

A rules engine that was both too strict and too slow to adapt.

• False positives cost revenue

  A hand-written rules engine declined a meaningful share of legitimate transactions — lost volume, support cost, and merchant churn, all from a system that couldn't tell a false alarm from a real one.

• Rules go stale in weeks

  Fraud patterns shift faster than a change-approval cycle can keep up with. By the time a new rule ships, the pattern it targets has already moved on.

• AML alerting was almost all noise

  Overnight batch alerting produced large volumes of suspicious-activity flags, the vast majority dismissed on review — analysts spent their time reconstructing context, not judging risk.

• No memory across entities

  A device shared across a dozen "unrelated" accounts is invisible to a system that scores one transaction at a time with no relationship signal.

The high-level solution

A three-tier decision system.

Deterministic guardrails handle what must always be explainable by construction. A real-time model scores everything else. Generative AI joins only after a decision has already been made — to explain it, never to make it. The model proposes. It never decides. The block/allow decision stays with a deterministic, auditable system. That separation is what makes the design defensible to a regulator, and it's the single most common mistake to get wrong in a fraud project like this.

• Tier 1 — Guardrails

  Sanctions lists, velocity hard-stops, blocked identifiers. Kept as deterministic rules on purpose: some decisions must be provable to an auditor by construction, not by explanation after the fact.

• Tier 2 — Real-time ML

  A model scores every transaction in milliseconds using behavioral, device, and relationship signals, returning a calibrated risk score with feature-level attributions.

• Tier 3 — GenAI investigation

  For elevated-risk cases, an LLM assembles a case narrative — what happened, what drove the score, what typology it resembles — and drafts the regulatory filing narrative for a human to confirm.

Architecture

Three paths, three different latency budgets.

• Synchronous decision path

  Transaction event → guardrail checks → real-time risk score → policy decision → response. Target: under 100ms at the 99th percentile, including a feature-store lookup and a model inference call.

• Streaming feature path

  Event stream → stream processing → feature store (online + offline) → graph enrichment. The same windowed features feed both real-time scoring and model training — the single biggest source of train/serve mismatch, closed by construction.

• Investigation path

  Elevated-risk case → evidence gathering → LLM case narrative → guardrail & grounding check → analyst review. Every generation is logged with its grounding score. Ungrounded output is regenerated once, then escalated to a human with the raw evidence attached.

Pipeline

How it got built.

• Foundation

  Landing zone, event streaming infrastructure, and a security baseline — private networking, key management, and audit logging from day one.

• Streaming & features

  Event ingestion and windowed feature computation, with one feature definition shared by training and real-time serving.

• Model training

  Temporal train/test splits (never random — label maturity matters), bias evaluation across sensitive segments, and a versioned model registry.

• Real-time serving

  A low-latency scoring endpoint behind the decision API, with a rules-only fallback if the model ever fails or times out — a degraded decision beats a blocked payment.

• Graph enrichment

  Relationship signals — shared devices, shared beneficiaries, circular fund flows — that a flat, per-transaction model can't see on its own.

• Investigation layer

  LLM-assisted case narratives with citation requirements and guardrails, evaluated against a hand-labelled set of real cases before it ever reaches an analyst.

• Monitoring & retraining

  Drift detection, a scheduled retraining cadence, and a shadow-then-canary rollout for every new model version.

Outcomes

What moved.

Figures are illustrative engineering targets for this solution pattern, based on comparable production systems — not a guaranteed result for any specific deployment.

• Fraud detection rate (at fixed false-positive rate)

  Before: ~62% → Target: 85–90%

• False positive rate

  Before: ~3.0% → Target: 0.6–0.9%

• Decision latency (p99)

  Before: ~140ms → Target: <100ms

• AML alert precision

  Before: ~5% → Target: 25–35%

• Analyst time per case

  Before: ~35 min → Target: 8–12 min