Training fraud-detection ML on synthetic transaction data — the 95/5 architecture

Synthetic data wins on privacy and bias control. Fraud detection is the one fintech ML domain where it cannot win alone. The reason is structural: adversarial signal lives in the long tail of transactions, the adversaries adapt, and a synthetic generator trained on legitimate-behavior distributions produces no realistic adversarial signal. A pure-synthetic fraud model under-performs in production by a margin that doesn't close with more data.

The production pattern that does work is 95/5. Synthetic data for the legitimate-behavior majority, a small curated real-fraud holdout for the adversarial layer. Below: the data shapes, the access controls around the 5% real-fraud carve-out, and the validation gates that make the hybrid defensible to security and compliance review.

What fraud-detection ML actually has to do

A production fraud-detection model has multiple layers, each with different signal requirements:

The split: legitimate-behavior modeling (the first four rows) is amenable to synthetic data. Adversarial-pattern modeling (the last three) needs real signal. A production model has both layers, and the data architecture has to provide both.

The 95/5 split

The architecture pattern that's converged across production fraud teams as of 2026:

1. Layer 1
   Legitimate-behavior synthetic corpus
   95%+ of the training data. Synthetic transactions, customers, devices, sessions. Captures normal-behavior baseline. Refreshable, scalable, no privacy or PCI scope.
2. Layer 2
   Adversarial real-data holdout
   5% or less of training data. Curated real fraud cases with the cardholder and identifying information stripped, retained in a high-control environment. Captures adversarial signal that synthetic can't reproduce.
3. Layer 3
   Production telemetry
   Live signal from production used for ongoing model retraining. Subject to the same privacy and PCI controls as the adversarial holdout.
4. Layer 4
   Synthetic adversarial augmentation
   Limited synthetic adversarial signal — known patterns synthesized to balance the training set. Useful for class balancing; not a replacement for real adversarial signal.

The legitimate-behavior layer is the largest by volume and the lowest by risk. It can scale freely. The adversarial layer is small, sensitive, and access-controlled.

The synthetic legitimate-behavior corpus

For fraud training specifically, the legitimate-behavior corpus needs:

A synthetic corpus that ships with these properties supports the bulk of fraud-model training without privacy or PCI exposure. Ours runs roughly $0.50 per synthetic cardholder-month — affordable for any fraud team needing diverse coverage.

The adversarial holdout architecture

The 5% adversarial layer is where the engineering and compliance work is harder.

The architecture pattern:

1. Stage 1
   Real fraud event capture
   Production fraud detection identifies a confirmed fraud event. Full transaction data captured into a controlled queue.
2. Stage 2
   Tokenization at boundary
   PAN tokenized, full PII removed. Behavioral signal preserved (amounts, merchants, sequences, device patterns).
3. Stage 3
   Curation and labeling
   Human-reviewed labeling — adversarial pattern type, severity, related-event linkage. Labels are themselves valuable for training.
4. Stage 4
   Training-corpus addition
   Tokenized + labeled cases added to the adversarial corpus, available to model training in the high-control environment.
5. Stage 5
   Refresh cadence
   Quarterly or monthly refresh of the corpus as new fraud patterns emerge. Model retraining triggered on material changes.

The adversarial corpus is small (low thousands of cases at most for a major issuer, growing with new fraud waves) but disproportionately valuable — most of the model's discriminative signal comes from this layer.

What gets validated where

The validation pattern for hybrid fraud models:

Each validation has its own data requirement. Engines that run only the first validation (against real data) miss the engineered edge cases that production fraud will eventually exercise.

Common implementation traps

Three patterns we see in fraud-detection deployments that produce post-deployment surprises:

Synthetic data with no adversarial layer. The team builds a clean synthetic corpus, trains a model, deploys it, and watches the model under-detect known fraud patterns. The synthetic distribution didn't include the adversarial tail; the model never learned to flag the patterns. Fix: add real adversarial holdout.

Real-data-only with no edge-case coverage. The team trains on production data only. The model performs well on patterns the production data contained and fails on patterns the production data didn't. Particularly: novel adversarial waves the production data is too old to include. Fix: synthetic engineered edge-case cases for forward-looking robustness.

No fairness validation. The team uses real data without demographic awareness. The model learns to use ZIP-coded census proxies as fraud signal. The fraud detection works statistically and produces disparate-impact false positives on protected classes. Fix: synthetic demographic-controlled fairness validation.

The architecture that survives audit and production is the same architecture in both cases: a synthetic legitimate corpus large enough to scale the legitimate-behavior layer, an access-controlled adversarial holdout small enough to govern the privacy and PCI surface, demographic-controlled fairness sets generated alongside, and the validation gates separated by layer (velocity, device, amount, account-takeover, synthetic-identity) rather than collapsed into a single F1 score.