Synthetic data for fraud detection rebuilds the rare fraud and money-laundering patterns that real datasets barely contain, so a model can learn on enough labeled examples of the behavior it is supposed to catch.
Fraud and anti-money-laundering (AML) teams sit on huge transaction histories, yet the events they most need to detect are a rounding error in the data. Confirmed fraud often runs well under one percent of transactions, and in AML transaction monitoring, confirmed laundering typologies are rarer still. That scarcity is not a minor inconvenience, and regulators have taken it up directly: the UK Financial Conduct Authority’s Synthetic Data Expert Group devoted its report to synthetic data across fraud controls, model testing and validation, and data sharing in financial services. A fraud model trained on almost no positive examples is exactly the kind of project that stalls after a promising demo.
Why fraud and AML data breaks machine learning
The core problem is class imbalance layered on top of access restrictions. A model that sees fraud in 0.3% of rows can score 99.7% accuracy by labeling everything as clean, and it will still miss almost every real case. Rebalancing by throwing away legitimate transactions loses signal; naive oversampling of the few fraud rows teaches the model to memorize a handful of individuals rather than the shape of fraudulent behavior.
The access problem compounds it. Transaction records carry account numbers, counterparties, amounts, and timing that fall under banking secrecy, privacy law, and internal risk controls. The data scientists who could improve the model frequently cannot touch the raw rows, and the raw rows cannot leave the regulated environment. So the scarce positive examples that do exist are also the hardest to work with.
How DTS builds synthetic data for fraud detection
DTS, CUBIG’s AI-ready data transformation engine, treats a scarce fraud class as a structure to be rebuilt rather than a quota to be filled. It follows three steps: Diagnose, Transform, Rebuild. Diagnose measures where the data blocks learning, which for fraud usually means the joint structure of the rare class: how amounts, timing, sequence, and counterparty relationships co-occur in confirmed cases. Transform applies structure-preserving synthesis so the rebuilt records carry those correlations forward instead of sampling each field on its own. Rebuild produces a fuller labeled set the model can actually learn the minority pattern from.
Two properties matter for regulated fraud work. First, this is rare-pattern augmentation, not blanket duplication: DTS concentrates on the parts of the distribution the model is starving for, and leaves the abundant clean traffic mostly intact. Second, it runs on a non-access architecture, so the engine learns the statistical structure of the sensitive transactions without analysts reading raw customer records. Differential privacy can bound how much any single real account influences the rebuilt output, which keeps a synthetic row from becoming a copy of one person’s history.
Structure-preserving synthesis versus plain resampling
The distinction that decides whether a fraud model improves is whether the rebuilt minority class preserves relationships or just adds volume. Synthesizing the minority class has deep roots: SMOTE, the JAIR 2002 method, standardized the generation of synthetic minority-class examples to correct imbalance. Classic resampling and interpolation techniques add rows, but they tend to smear fraud examples toward the clean majority or invent points that violate how a real transaction behaves. Structure-preserving synthesis keeps the conditional structure intact, so a rebuilt laundering sequence still looks like a plausible chain of movements rather than a bag of independent numbers.
| Approach | Preserves rare-class structure | Works on restricted data |
|---|---|---|
| Drop clean rows to rebalance | No | Yes, but loses signal |
| Naive oversampling / interpolation | Partial | Yes, but risks memorizing individuals |
| Structure-preserving synthesis (DTS) | Yes | Yes, non-access architecture |
How this changes AML transaction monitoring
AML transaction monitoring has its own scarcity problem: known AML typologies such as layering, structuring, or mule networks appear in tiny numbers, and new typologies appear with essentially zero labeled history. Teams that rely only on rule thresholds drown in false positives, and teams that try to train supervised models rarely have enough confirmed cases per typology to generalize. Rebuilding rare typologies with structure-preserving synthesis gives the model more examples of the sequence-level behavior that distinguishes laundering from ordinary movement, which is where flat, per-transaction features fall short.
Because DTS runs on the Syntitan platform, the rebuilt data does not sit off to the side as a one-time export. The augmentation step is part of a data state you can point a run at, so an AML transaction monitoring model retrained this quarter can be tied back to the exact rebuilt set it learned from. That matters when a regulator or an internal audit asks why an alert fired and what the model was trained on. Banks already answer to this standard on risk data: BCBS 239 requires risk data to be aggregated accurately and completely, largely by automated means, precisely to keep the probability of error down.
A quick self-diagnostic for fraud and AML teams
Run this short test before your next model retrain. If you answer “no” to two or more, scarcity is probably capping your detection rate:
- Do you have at least a few hundred confirmed positive examples per fraud or laundering typology you want to catch?
- When you rebalance, are you preserving the joint structure of the rare class rather than duplicating rows?
- Can your data scientists improve the model without reading raw customer transactions?
- Can you tie a deployed detection model back to the exact dataset it was trained on?
- Do rebuilt or augmented examples stay statistically representative until you reproduce results on your own held-out data?
Where it fits in CUBIG’s operating layer
DTS handles one specific job: rebuilding restricted, scarce, or unusable data into data a model can learn on. For fraud and AML, that job is the difference between a model that has seen the behavior and one that has only seen its absence. DTS diagnoses where the rare class blocks learning, applies structure-preserving synthesis to rebuild it, and does so without exposing the underlying records. It runs on the Syntitan platform, so the rebuilt data belongs to a state you can reproduce rather than a loose file no one can account for later.
The honest framing is this: synthetic augmentation makes a fraud model trainable, not omniscient. Performance you see on rebuilt data is representative until you reproduce it on your own held-out cases. That is the standard we hold DTS to, and the one your risk and audit functions will hold you to as well. For related depth, see structure-preserving synthesis, how to validate that synthetic data is good enough, and the pillar overview of what DTS is.
Try it on your data for free. Run a sample proof and see it on your own workflow.
