Synthetic Data for Fraud Detection

The problem

Class imbalance defines this problem. Confirmed fraud is a tiny fraction of any real corpus, which starves the positive class exactly where the model needs signal. Sharing the confirmed cases that do exist across teams multiplies exposure of the most sensitive records you hold, so the data tends to stay locked in one place. Teams that resort to synthesising anomalies by hand usually make them too obvious — a wildly impossible income, a malformed identifier — and the model learns to detect the fixture rather than the fraud. Meanwhile the legitimate class is drawn from the same constrained real corpus, so it is neither large enough nor varied enough to define the boundary of normal.

The SymageDocs approach

Because the generator builds a coherent person before it builds a document, coherence is a control surface rather than an accident. Run it in the default mode and you get a clean population: wages that match between the W-2 and the 1040, an employer EIN consistent across employment-tax filings, an address that agrees everywhere it appears. Switch coherence mode and those relationships break in a controlled way. Shuffled mode permutes every field across identities — identity fields such as name and address as well as the figures — so every individual value remains drawn from a realistic distribution while the cross-field agreement disappears, which is a subtle, realistic anomaly rather than an obvious one. Separately — and it has to be separately, since the two cannot be combined in one request — the partial-fill facility lets you produce documents with fields blank or completed at different stages, which is a distinct and common anomaly signal.

What you actually get

• A large, coherent legitimate class: multi-form document sets whose figures reconcile across every form in the set.
• Controlled anomalies via shuffled and random coherence modes, breaking cross-field correlations while preserving per-field distributions.
• Partial and staged fills, so 'this document is incomplete in an unusual way' is a case you can generate deliberately — requested as its own job, since partial-fill scenarios and shuffled coherence cannot be combined in one request.
• A tabular CSV and per-instance JSON in every bundle, giving you exact labels for which documents are coherent and which are not.
• Adjustable class balance, because the ratio of clean to anomalous documents is a function of what you request rather than what history handed you.

How it works

1. 1

   Build the legitimate class

   Generate multi-form batches in the default coherent mode. One simulated identity fills every form in a sample, and a cross-form coherence pass runs afterwards, so the negative class genuinely represents consistent, well-formed documents.

2. 2

   Break coherence deliberately

   Regenerate with shuffled coherence to permute every field across identities — identity fields included, not only the financial ones. Per-field distributions survive, cross-field correlations do not. Because the values are permuted between identities, this only does something at a quantity above one: a single-document shuffled job is accepted and returns coherent output, so request the positive class as a batch. Random mode breaks the set at the document level instead: each form in an item is filled from its own independently generated identity, so each document is internally coherent but the set describes several different people.

3. 3

   Add structural anomalies as a separate batch

   Use partial-fill scenarios to control which groups of fields arrive completed, which stay blank, and which are filled at a later stage — producing documents that are unusual in structure rather than in value. This is its own job, not a setting layered onto the previous one: the API rejects a request that combines partial-fill scenarios with shuffled coherence, because both drive the same per-field override channel. Generate the two anomaly families as separate jobs and combine the bundles in your training set.

4. 4

   Label from the bundle

   Each job's CSV and per-instance JSON record exactly what was generated and under which settings, so labelling reduces to reading the manifest of what you asked for rather than adjudicating documents after the fact.

By the numbers

Field and page counts are read from the shipped form definitions in the SymageDocs form library. Library-size figures count every definition the API can generate; the public form reference pages under /forms document a curated subset of them, so that page shows a smaller number. Output-format availability reflects the current API contract; the ML export formats (BIO, YOLO, COCO, Donut) sit behind a feature flag that is not enabled in production, so treat them as a preview rather than a generally available option.

Who this is for

Risk and fraud teams at lenders, insurers, and payment companies who need a positive class large enough to train on; document-intelligence vendors building anomaly detection into an extraction product; and model-risk functions that need a reproducible, shareable evaluation set rather than a folder of real cases with restricted access.

Where SymageDocs is not the right tool

The anomalies here are anomalies of data, not of pixels. SymageDocs renders clean documents from a generator; it does not simulate a forged document — no splicing, no font substitution, no retouching, no inconsistent compression artifacts — so it will not train a model to detect visual tampering. It also cannot reproduce the specific fraud typologies present in your book of business, because it does not see your data; it produces a structurally plausible anomaly class, which is a starting point and a supplement, not a replacement for your confirmed cases. Any model trained on synthetic anomalies alone should be validated against real ones before it makes decisions about real people.

Relevant forms

Frequently asked questions

How do you generate anomalies that are not trivially detectable?

By breaking relationships rather than values. Shuffled coherence mode permutes every field across identities — names and addresses as well as figures — so every individual value is still drawn from a realistic distribution for its field, with nothing out of range and nothing malformed, but the cross-field agreement that should hold no longer does. That forces the model to learn the relationship, which is the actual task, rather than a threshold on a single field, which is what obviously fabricated anomalies teach it. Since the mechanism permutes values between identities, it needs a quantity above one to produce anything: a shuffled job of a single document is accepted and comes back coherent, so generate the anomalous class as a batch rather than testing the mode one document at a time.

Can I control the ratio of fraudulent to legitimate examples?

Yes, and this is one of the clearer advantages over a collected corpus. Class balance becomes a property of what you request: generate a large coherent population and a separate batch under a non-default coherence mode, then combine them in whatever proportion your training regime calls for. You are no longer stuck with the ratio history happened to produce, which for real fraud data is usually severe enough to dominate your modelling choices.

Does this replace my real fraud data?

No, and treating it as a replacement would be a mistake. Synthetic anomalies are structurally plausible, but they cannot encode the specific typologies your fraudsters actually use, because the generator has never seen your book. The realistic use is supplementation: train on synthetic data for volume and for coverage of the structural cases your real corpus lacks, then validate and calibrate against your confirmed cases before the model influences any real decision.

What kinds of inconsistency can you produce?

Two broad families, requested as two separate jobs. Value-relationship inconsistency comes from the coherence modes: figures that should reconcile between forms no longer do, and identity attributes that should agree across a document set no longer agree. Structural inconsistency comes from partial-fill scenarios: groups of fields can be marked prefilled, completed, or blank, so a document can be unusual in what it omits or in the stage it appears to have been captured at rather than in the values it carries. The two are mutually exclusive within a single request — the API returns a 400 if partial-fill scenarios are combined with shuffled coherence, because both drive the same per-field override channel — so generate a batch of each and mix them in the proportion your training regime calls for.

Are the anomalies labelled?

You know the label because you chose the settings: a batch generated under shuffled coherence is your positive class, and a batch generated coherently is your negative class. Each bundle carries per-instance JSON and a tabular CSV describing exactly what was generated, so the labelling step is bookkeeping over your own job parameters rather than an adjudication exercise. This is a meaningful difference from real data, where the label is itself uncertain and often arrives months late.

Can I train a document-forgery detector with this?

Not directly, and we would rather be clear about that than let the use case be assumed. Forgery detection is largely a signal-level problem — splicing boundaries, resampling traces, inconsistent compression, font and kerning mismatches — and SymageDocs renders clean documents rather than manipulated ones. It is well suited to detecting fraud expressed through the data on the page; a tampering detector needs a corpus of actually tampered images, which you would have to construct separately.

Related use cases