Casebook/Case 24
Fairness, privacy & security

Stripe Radar: learning fraud under adversarial pressure

Production fraud detection as a global, delayed-label, cost-sensitive, adversarial decision system.

Reported by the primary sourceFACT LAYER

What we can attribute directly

Stripe published an overview of how it built Radar for fraud prevention.

The system learns from payment-network data and operates as part of real-time payment decisions.

Read Stripe — How we built Radar Primary source · last checked 26 Aug 2026
01 · Problem & constraints

The operating envelope

Very low latency, extreme imbalance, delayed chargebacks, adaptive attackers, merchant variation, and false-decline cost.

Actors

Model teams, platform owners, operators, downstream product systems, and people affected by decisions.

Evidence

Versioned data, configs, traces, artifacts, deployments, and outcomes aligned on one timeline.

Failure cost

Rules become brittle and local merchants lack enough labeled fraud to learn robustly alone.

02 · Architecture reconstruction

Trace the system before naming the bug.

  1. 01

    Producers emit versioned data or model artifacts.

  2. 02

    A platform validates, computes, stores, schedules, or routes them.

  3. 03

    Training or inference consumes the exact declared version.

  4. 04

    Telemetry joins the decision to system, data, and model identity.

  5. 05

    Operators compare outcomes, stop conditions, and the last known-good path.

03 · Symptoms & investigation

Follow the evidence boundary by boundary.

Symptoms

Rules become brittle and local merchants lack enough labeled fraud to learn robustly alone.

Investigation

Join authorization-time features with mature outcomes; inspect leakage, merchant/country slices, calibration, and attack shifts.

DIAGNOSTIC EXERCISE

A new attack increases chargebacks before labels mature. Which proxy signals and safe controls can respond without poisoning retraining?

Open investigation scaffold
  1. Write the earliest known-bad timestamp.
  2. Compare exact identities on either side of that boundary.
  3. Find the smallest affected slice and a known-good counterexample.
  4. Separate mitigation from root-cause confirmation.
04 · Root cause & fix

Repair the contract, not only the symptom.

ROOT CAUSE

Fraud is a changing network problem where labels and exposure are delayed and policy-dependent.

FIX

Combine shared statistical learning, contextual signals, rules, feedback, and calibrated operating thresholds.

Rollout

Shadow, canary by merchant cohort, constrain false declines, and retain deterministic controls for active attacks.

05 · Rejected alternatives

Reason about the tempting shortcuts.

  • Optimizing global accuracy.
  • Assuming yesterday’s calibrated threshold survives an attack shift.
06 · Monitoring after the fix

Make recurrence visible early.

01

Fraud loss and false decline by slice

Define owner, slice, normal range, alert persistence, and the exact mitigation the alert should trigger.

02

Score calibration and attack clusters

Define owner, slice, normal range, alert persistence, and the exact mitigation the alert should trigger.

03

Label maturity and review yield

Define owner, slice, normal range, alert persistence, and the exact mitigation the alert should trigger.

REUSABLE PRODUCTION PATTERN

Risk modeling connects delayed supervision, adversarial drift, calibrated decisions, and layered controls.

Carry this pattern into assignments as a design constraint and into incident reviews as a hypothesis—not as proof about an unpublished system.