Synthetic data are artificially created records designed to reproduce useful characteristics of real data without simply copying the original observations. They can help teams test software, train models, represent rare events and collaborate where direct access to sensitive data is limited. Yet “synthetic” does not automatically mean accurate, unbiased or anonymous.
The central question is not whether a dataset looks realistic. It is whether it is fit for a declared purpose, preserves the relationships that matter, avoids harmful disclosure and remains under appropriate control. A dataset suitable for demonstrating a dashboard may be dangerously weak for training a credit-risk model. One designed for aggregate research may fail at individual-level prediction.
This guide explains the main synthetic data generation methods, the tests that make results defensible and EPW’s SAFE governance framework for moving from an idea to controlled use.
What is synthetic data?
Synthetic data are generated rather than directly observed. A generator may be built from rules, a physical simulation, statistical distributions or a machine-learning model trained on source data. The output can include tabular records, text, images, video, transactions, network events or time-series signals.
Fully synthetic data replace every original record and value. Partially synthetic data retain some original fields while replacing selected values. Hybrid datasets may mix observed and generated examples to improve coverage. These categories matter because the privacy and utility claims differ.
The UK Office for National Statistics describes synthetic microdata as records created to improve utility while preventing disclosure of confidential respondent information. The UK Information Commissioner’s Office includes synthetic data among privacy-enhancing technologies, but its broader guidance makes an important point: a technology supports data protection only when it is selected, configured and governed for the particular risk.
Why organisations generate synthetic data
- Access: analysts can develop queries or prototypes before tightly controlled real data are available.
- Testing: software teams can create large, varied test populations without placing production records in development systems.
- Rare cases: generated examples can increase exposure to uncommon failures, fraud patterns or safety conditions.
- Simulation: engineers can model conditions that are expensive, slow or dangerous to reproduce physically.
- Collaboration: organisations can share lower-risk representations while retaining the source data in a controlled environment.
- Data minimisation: some uses may be met without distributing directly identifiable records.
These benefits are hypotheses, not guarantees. Synthetic data can reproduce bias, smooth away rare but important patterns, create implausible combinations or leak information about source records. It can also create false confidence because clean generated data often lack the missingness, drift and operational noise found in production.
Main synthetic data generation methods
| Method | How it works | Good fit | Main limitation |
|---|---|---|---|
| Rules and templates | Values are sampled inside explicit business rules and constraints | Software tests, edge cases and controlled demonstrations | May miss complex dependencies and unexpected behaviour |
| Mechanistic simulation | A physical, operational or agent-based model produces scenarios | Robotics, industrial systems, transport and safety analysis | Results inherit assumptions and calibration errors |
| Statistical synthesis | Estimated distributions and conditional relationships generate new rows | Structured data and explainable baselines | Complex high-dimensional interactions can be weakened |
| Generative neural networks | GANs, variational autoencoders or diffusion models learn a data distribution | Images, signals and complex tabular patterns | Training instability, memorisation and difficult validation |
| Language-model generation | A model creates text or structured examples from prompts and constraints | Conversation tests, extraction examples and scenario coverage | Factual errors, duplication, unsafe content and uncertain provenance |
| Privacy-enhanced generation | Differential privacy or other controls limit source-record influence | Uses requiring a formal privacy objective | Stronger protection can reduce fidelity or minority-group detail |
The most sophisticated generator is not always the best. A rule engine is often easier to audit for application testing. A calibrated simulator can be more meaningful than a generic generative model for physical systems. Statistical methods provide a useful baseline. The choice should follow the use case, data type, risk and evidence requirements.
The three tests: fidelity, utility and privacy
A single “quality score” hides important trade-offs. A credible evaluation separates at least three dimensions.
1. Fidelity: does the dataset resemble the source?
Fidelity tests compare distributions, correlations, conditional relationships, missingness and sequence behaviour. For tabular data, teams may compare summary statistics, category frequencies and pairwise relationships. Images may require feature-distribution and diversity checks. Time series need autocorrelation, seasonality and event-duration tests.
High fidelity is not sufficient. A generator could achieve an excellent resemblance by memorising source records, which creates privacy risk. It could also match overall averages while erasing a small group that matters operationally.
2. Utility: does it work for the declared task?
Task-based evaluation asks whether conclusions or models developed on synthetic data transfer to real conditions. A common experiment trains a model on synthetic data and tests it on a protected real hold-out set. For analytics, teams can compare query results, coefficients, rankings or confidence intervals.
Utility must be use-specific. Data that support interface testing may not preserve causal relationships. A dataset that produces comparable overall accuracy may still change recall for rare faults or protected groups.
3. Privacy: can source information be inferred?
Privacy testing examines whether generated records are too close to source records and whether attackers can infer membership, attributes or identities. Useful controls include nearest-neighbour analysis, duplicate detection, membership-inference testing and documented adversarial review. Where differential privacy is used, teams should record the privacy unit, mechanism, clipping, noise and privacy budget.
The Financial Conduct Authority’s work on synthetic-data validation highlights the need to assess privacy, utility and fidelity together. Improving one dimension can reduce another; governance should make the accepted balance explicit.
EPW’s SAFE synthetic data framework
- S — Specify purpose and risk. Define the authorised use, users, source population, important subgroups and unacceptable outcomes. Decide whether the output is for demonstration, testing, analysis or model training. Set acceptance criteria before generation.
- A — Assemble data, constraints and method. Establish lawful access to the source, minimise fields, document provenance and choose a generator matched to the task. Encode impossible combinations, ranges and domain rules. Separate training, validation and protected real test data.
- F — Falsify quality and privacy claims. Try to prove the dataset unfit. Test fidelity, downstream utility, rare cases, fairness, duplicates and disclosure risk. Use independent reviewers for higher-risk releases. Record failures rather than averaging them away.
- E — Enforce controls and evolve. Approve named uses, label versions, restrict redistribution, monitor downstream performance and retire unsuitable datasets. Regenerate when source populations, regulations or intended uses change.
A worked example: generating industrial fault data
An asset-management team has vibration and temperature readings from 180 pumps. Failure events are rare, and the real records contain commercially sensitive operating information. The team wants more data for an anomaly-detection experiment.
Under Specify, it defines one authorised use: pre-production model development. Safety decisions will not be made from synthetic records. Critical measures include failure recall on real hold-out data, false-alarm burden and performance by pump type.
Under Assemble, engineers document sensor ranges, relationships, operating modes and failure sequences. They compare a mechanistic simulator with a time-series generative model. Entire pumps—not random rows—are assigned to training and hold-out sets, preventing leakage across repeated readings.
Under Falsify, the team checks distributions, cross-sensor relationships, temporal patterns and coverage of recognised failure modes. It searches for copied sequences and tests whether a classifier can distinguish synthetic from real samples. Models trained on generated data are evaluated only against the protected real hold-out set.
Under Enforce, the synthetic dataset is versioned with its generator, source period, tests and restrictions. Access is limited to the project. Any production decision requires validation on current real data and approval from engineering and safety owners.
The outcome may be that simulation improves rare-event coverage while the learned generator better reproduces normal variability. A controlled hybrid can then be more useful than selecting one method for every condition.
Minimum validation scorecard
- Purpose, intended users and prohibited uses are documented.
- Source provenance, lawful basis and access controls are recorded.
- Univariate and multivariate fidelity tests meet declared thresholds.
- Rare categories, boundary conditions and temporal behaviour are inspected.
- Downstream performance is tested on protected real data.
- Fairness and subgroup results are reported separately.
- Exact and near-duplicate source records are checked.
- Membership, attribute or linkage attacks are considered.
- Generator code, parameters, seeds and versions are reproducible.
- Dataset labelling communicates that records are synthetic.
- Release, redistribution, retention and retirement rules are approved.
Common mistakes to avoid
Calling synthetic data anonymous by default. A model can memorise or reveal information. Privacy must be evidenced in context.
Validating only averages. Aggregate similarity can hide broken relationships and missing minorities.
Testing on the generator’s training data. Utility should be evaluated against independent, protected real observations.
Using generation to repair bias silently. Rebalancing may help a model, but invented examples can distort reality. The intervention and assumptions should be explicit.
Allowing purpose drift. A low-fidelity dataset released for training exercises should not quietly become the basis for operational prediction.
Building practical capability
EPW’s Synthetic Data Generation Techniques for AI course develops practical skills across generation methods, validation, privacy, bias and governed deployment. It complements EPW’s wider Artificial Intelligence and Machine Learning courses and the article on AI and machine-learning benefits for organisations.
Conclusion
Synthetic data are useful when they are treated as a controlled engineering product, not a magic substitute for real evidence. Rules, simulations, statistical synthesis and generative models each serve different needs. Their outputs must be tested for fidelity, task utility, privacy and fairness.
The SAFE framework keeps the work anchored to purpose: specify the risk, assemble an appropriate method, falsify quality and privacy claims, then enforce lifecycle controls. That discipline turns synthetic data from an attractive demo into a defensible organisational capability.
