Structure-preserving synthesis is a data rebuild method that reproduces the statistical relationships, rare patterns, and schema of a restricted source dataset, so a model can learn on it, whereas generic synthetic data optimizes for surface realism and often loses the correlations and edge cases that decide whether the model works.
The gap between the two shows up late, in production, where it is expensive. Synthetic data has been correcting class imbalance since long before today’s generators: SMOTE, the canonical JAIR 2002 technique, generates synthetic minority-class examples for exactly that purpose. A synthetic dataset that looks right on a dashboard but drops the rare pattern your fraud model needs is quietly failing the assignment that technique was built for.
This article compares the two approaches on the terms that matter for a model in production: whether the rebuilt data carries joint distributions, whether it holds the rare cases, whether the schema survives, and whether you can defend the privacy claim. If you are choosing between a general synthetic data generator and a structure-preserving rebuild, the table below is the decision.
What structure-preserving synthesis actually preserves
Generic synthetic data answers a narrow question: does each column, looked at on its own, resemble the real thing? Age distributions match, transaction amounts fall in a plausible range, category frequencies look familiar. That is enough to demo, and it is enough for many privacy checkboxes.
It is often not enough for a model. A model does not learn from columns in isolation. It learns from the relationships between them: the correlation between income and default, the sequence of events that precedes a machine failure, the layout of a form that tells a document parser where the total sits. Structure-preserving synthesis is built to reproduce those relationships, not just the marginals.
Three things it holds that generic generators tend to lose. First, joint distributions, meaning the way variables move together rather than each variable’s shape alone. Second, rare patterns, the low-frequency events like fraud, defects, or unusual clinical presentations that a model exists to catch. Third, the schema and its constraints, so foreign keys, valid ranges, and required fields still hold after the rebuild. Lose any one of these and the synthetic set trains a model that scores well offline and fails on the cases you care about.
Structure-preserving synthesis vs generic synthetic data, side by side
Here is the comparison on the dimensions that change a production outcome. “Generic synthetic data” here means a general-purpose generator tuned for realism; “structure-preserving synthesis” is the rebuild approach used by CUBIG’s DTS.
The row that decides most enterprise use is rare pattern retention. A generic generator learns the common shape of the data and reproduces it well, which means it reproduces the majority class well and the minority class poorly. For a fraud, anti-money laundering, or defect model, the minority class is the whole point.
Why the rare pattern gap is the expensive one
Consider a card fraud model. Fraud is well under one percent of transactions. A generic synthetic generator, trained to reproduce the overall distribution, will faithfully reproduce that: less than one percent of its rows will be fraud, and the fraud rows it does produce will be blurred toward the average because the model had few examples to learn the pattern from.
Structure-preserving synthesis takes the opposite stance on the rare class. Because it models the structure that separates fraud from normal activity, it can rebuild the rare pattern faithfully and, where you ask for it, augment it: generate more valid rare cases so the downstream model has enough signal to learn from. This is rare-pattern augmentation, and it is the difference between a model that flags novel fraud and one that only recognizes what it has already seen. Financial supervisors are studying the same ground: the UK FCA’s Synthetic Data Expert Group report examines synthetic data across fraud controls, model testing and validation, and data sharing in financial services.
The same logic runs through clinical research, where the cohort you need to study is small by definition, and through manufacturing, where the defect you want to catch happens once in ten thousand parts. In each case the rare rows are the reason for the project, and a generator that smooths them away has quietly deleted the project’s value.
Privacy is not the same as realism
Both approaches promise privacy, and it is worth being precise about what each one actually offers, because a demo of realistic looking rows tells you nothing about re-identification risk. That risk is precisely what a paper in npj Digital Medicine argues patient-centric synthetic data generation removes in biomedical work, where the alternative is analyzing real patient records.
A defensible privacy claim rests on two things: a formal privacy guarantee and a build process that never exposes the raw records. Differential privacy provides the first, a mathematical bound on how much any single individual’s data can influence the output, tunable through a privacy budget. A non-access architecture provides the second, meaning the rebuild runs without a human or a downstream system reading the sensitive rows directly. Structure-preserving synthesis as CUBIG implements it in DTS combines both. Many generic generators offer neither in a form you can put in front of an auditor.
Run this self-diagnostic before you trust a synthetic set
- Does the synthetic set keep the correlation between your two most predictive columns, or only their individual shapes?
- If you filter to the rare class you actually care about, are there enough realistic rows to train on?
- Do foreign keys, valid ranges, and required fields still hold, or did the rebuild produce impossible records?
- Can you state the privacy guarantee as a number, or only as “it looks anonymized”?
- Was the raw data ever read directly during the build, or was it a non-access process?
If you cannot answer two or more of these, you are likely looking at generic synthetic data wearing a structure-preserving label. Run the checks before you train.
Where it fits in CUBIG’s operating layer
Structure-preserving synthesis is the method behind DTS, CUBIG’s AI-ready data transformation engine. DTS diagnoses what makes a dataset unusable for AI, transforms it while holding the structure that carries the signal, and rebuilds restricted, scarce, or unusable data into data a model can actually learn on. It applies differential privacy and a non-access architecture so the rebuild is defensible, not just realistic.
DTS runs on the Syntitan platform, CUBIG’s AI-Ready Data Platform, alongside the rest of the data-readiness work an enterprise needs before a model goes to production. If your blocker is not scarcity or restriction but running AI on confidential data you cannot move, that is a different tool in the same family; the comparison in DTS vs anonymization vs differential privacy walks the boundary, and this decision guide helps you tell which one your project needs. For the readiness foundation underneath both, see what AI-ready data means.
How to choose
If your model works on common, high-frequency behavior and you mainly need to de-risk a demo or a data-sharing agreement, a generic synthetic data generator may be all you need. If the value of your project lives in the rare class, in the correlations between fields, or in a privacy claim you will have to defend to a regulator, structure-preserving synthesis is the approach that survives contact with production. The honest test is not which one looks more realistic on a chart; it is which one still holds up when you train on it and check the cases that matter.
Try it on your data for free. Run a sample proof and see it on your own workflow.
