Synthetic Data Generation Pipelines for Financial Services
Generating Data That Is Useful Enough to Train On and Safe Enough to Share
Synthetic data arrives in most banks as a solution to an obvious problem: teams need realistic data to build and test with, real customer data cannot be copied into development environments, and masked production data is either unrealistic or not as anonymous as everyone assumes. Generating data that looks like the real thing seems like the clean answer.
It can be, and the projects that disappoint are the ones that never defined what looking like the real thing has to mean. Synthetic data financial services teams can actually use is validated against a specific purpose across three axes, and the balance between them is different for a test environment than for model development.
What is synthetic data actually for?
Test environments, augmenting rare cases, and enabling sharing, in descending order of reliability.
| Use case | Suitability | What matters most |
|---|---|---|
| Development and test environments | Strong | Referential integrity, business rule validity, edge cases |
| Performance and load testing | Strong | Volume, distribution shape, realistic cardinality |
| Augmenting rare events for model training | Good | Fidelity of the rare pattern, no leakage into evaluation |
| Sharing with vendors for evaluation | Good | Privacy, sufficient realism to differentiate solutions |
| Demonstration and training environments | Strong | Plausibility rather than statistical accuracy |
| Wholesale replacement of real training data | Weak | Causal structure and tail behaviour rarely survive |
| Regulatory or audit evidence about real portfolios | Not appropriate | Real data is the point |
Being explicit about which row you are in resolves most disagreements before they start, because the validation work differs completely. A test environment needs data that exercises the code, not data that reproduces the joint distribution of customer behaviour.
Which use cases fail most often?
Replacing real training data entirely, and treating synthetic data as automatically shareable.
Both failures come from the same assumption, that fidelity high enough to look convincing is fidelity high enough for any purpose. A generator can reproduce marginal distributions beautifully and lose the conditional relationships a model needs, and it can produce data that appears anonymous while memorising rare records. Neither problem announces itself, which is why measurement rather than inspection is the whole discipline here.
What are the three axes?
Utility, fidelity, and privacy, with the balance set by the use case.
The FCA published research from a roundtable it hosted with the Information Commissioner's Office and the Alan Turing Institute in March 2023, framing synthetic data validation across exactly those dimensions. Two of its findings are directly useful for design. First, use case is central to the discussion, and it distinguishes broad measures such as statistical similarity from narrow measures such as comparing model performance on synthetic against real data. Second, on privacy it advocates shifting toward a risk-based model that accepts some level of inherent risk rather than seeking absolute guarantees, and notes that whether data will be retained internally or shared externally changes what validation is needed.
Why does the internal versus external distinction matter so much?
Because external sharing raises the privacy bar and lowers the tolerance for memorisation.
Data that stays inside your environment under existing access controls can accept more residual disclosure risk than data leaving for a vendor evaluation. Set the validation standard per destination, document it, and never let a dataset generated for internal testing be reused for external sharing without re-validation. That reuse is the most common governance failure in practice, because the dataset already exists and looks fine.
Do you validate synthetic datasets differently depending on whether they leave your environment?
How do you validate synthetic data?
With a battery of tests per axis, chosen for the use case and re-run when the generator changes.
| Test | Axis | What it shows |
|---|---|---|
| Marginal distribution comparison | Fidelity | Whether individual fields look right |
| Correlation and joint distribution comparison | Fidelity | Whether relationships survive |
| Business rule validation | Utility | Whether records are legal in your domain |
| Referential integrity checks | Utility | Whether the relational structure holds |
| Train on synthetic, test on real | Utility | Whether models learn transferable signal |
| Discriminator or distinguishability test | Fidelity | Whether a classifier can separate real from synthetic |
| Membership inference attack | Privacy | Whether presence of a real record is detectable |
| Attribute disclosure test | Privacy | Whether sensitive attributes can be inferred |
| Nearest-neighbour distance to real records | Privacy | Whether the generator copied rare records |
The train-on-synthetic, test-on-real measure is the most decision-relevant one for model development work, because it answers the actual question rather than a proxy for it. Run it before investing in a generator, not afterwards.
Why is anonymous by construction the wrong assumption?
Because generators memorise, particularly outliers, which are exactly the records most identifiable.
A model trained on a portfolio with one unusually large exposure can reproduce something very close to it, and that record is identifiable to anyone who knows the market. Test for it explicitly with nearest-neighbour distance and membership inference, treat rare records as the highest-risk population rather than a rounding error, and consider excluding or perturbing extreme outliers before generation. Then re-assess periodically, since privacy risk evolves as attack techniques improve, which is why the FCA research emphasises continuous monitoring and periodic re-assessment of privacy metrics rather than a one-time sign-off.
Which generation approaches exist?
Five, and financial data usually needs a hybrid.
| Approach | Strengths | Weaknesses |
|---|---|---|
| Rule-based simulation | Full control, business rules by construction, no leakage | Limited realism, misses learned patterns |
| Statistical models and copulas | Preserves marginals and simple dependence | Struggles with complex structure and sequences |
| Generative neural models | Learns complex joint structure | Memorisation risk, compute cost, opacity |
| Sequence models for transactions | Handles temporal behaviour | Hard to constrain, drift over long sequences |
| Language model generation | Good for unstructured text and documents | Weak numerical consistency, leakage risk |
A practical financial pipeline usually combines rule-based scaffolding for entities, relationships, and business constraints with learned generation for behavioural detail, which gives you integrity by construction and realism where it matters. Pure learned generation tends to produce records that violate domain rules in ways that break the systems consuming them.
What makes financial data particularly hard?
Sequences, hierarchy, referential integrity, hard rules, and rare events carrying most of the value.
Transactions are sequential and bursty, with weekly and monthly periodicity and life-event structure. Customers own accounts which hold products which generate transactions, so realism requires consistency up and down a hierarchy. Referential integrity must hold or downstream systems reject the data. Business rules are hard constraints rather than tendencies: balances must reconcile, dates must order, statuses must follow permitted transitions. And the events you most want, fraud, default, distress, are rare, which is precisely where generators are weakest and where augmentation is most tempting and most dangerous.
How do you preserve business rules and integrity?
By generating structure deterministically and behaviour statistically, then validating every rule before release.
Generate the entity graph first with correct keys and relationships, apply hard business rules as constraints during generation rather than as a post-hoc filter, then layer learned behavioural detail inside those constraints. Validate every rule on the output as a gate, and reject the dataset rather than patching it, since patched data develops artefacts that mislead later. For test environments specifically, coverage of edge cases matters more than distributional accuracy, which is a different objective from model development and is well described in this guide to test data management.
Would your synthetic dataset pass your production system's own validation rules?
Where does synthetic data fail as training data?
On tail behaviour, causal structure, and any distribution shift the generator never saw.
A generator learns from history, so it cannot invent the rare pattern it never observed, and augmenting a rare class by generating more of what you already have adds volume without information. Causal relationships are frequently lost, meaning a model trained on synthetic data can learn correlations that do not hold in the real process. And training generations on largely synthetic inputs degrades over time, a compounding failure worth avoiding by keeping real data in the loop. So the defensible pattern is real data anchoring any model that makes decisions, with synthetic data used for pre-training, augmentation of specific under-represented cases, and testing. Where the goal is analysis across institutions rather than augmentation, privacy-preserving computation is often the better route, as covered in federated fraud intelligence sharing and evidenced by the BIS Innovation Hub's Project Aurora finding that privacy-enhancing technologies with network analysis detected up to three times more complex schemes with up to eighty percent fewer false positives than siloed approaches.
Should production decision models be trained on synthetic data?
Rarely on synthetic alone, and never without evaluating on real held-out data.
If a model influences customer outcomes, its evaluation must use real data, and its training should be anchored in real data with synthetic augmentation documented and quantified. State the synthetic proportion, the generator version, and the augmentation rationale in the model documentation, because a validator will ask and the answer materially affects how much weight the performance results carry. Fraud models are the common exception where augmenting rare positives genuinely helps, and even there the evaluation set must be real, which is also true of the linkage work described in synthetic identity fraud detection.
How should synthetic data be governed?
With provenance, permitted uses, validation records, and a link to every model trained on it.
Record for each dataset the source data and its access basis, the generator and its version, the parameters used, the validation results per axis, the permitted uses and destinations, retention and deletion rules, and the models or environments it was used in. That record is what lets you answer two questions that will eventually arrive: whether a model's training data included synthetic records, and whether a dataset shared externally was validated for that purpose. Register the generator itself in your model inventory, since it is a model, and remember that current model risk guidance leaves AI systems out: OCC Bulletin 2026-13 of 17 April 2026 states the revised guidance explicitly excludes AI and generative AI models. Use your own policy plus the NIST AI Risk Management Framework 1.0 and its 2024 Generative AI Profile, held in the platform described in model risk management platform design.
How should delivery be phased?
Test environments first, then rare-event augmentation, then external sharing.
| Phase | Duration | Deliverable |
|---|---|---|
| Use case definition and standards | 1 month | Purpose, axis priorities, validation standard per destination |
| Rule-based structural generation | 2 to 3 months | Entity graph, referential integrity, business rule enforcement |
| Test environment adoption | 2 months | Development and test data at volume, replacing masked production copies |
| Behavioural generation | 3 to 4 months | Learned transaction and behavioural detail inside constraints |
| Privacy testing capability | 2 months | Membership inference, attribute disclosure, outlier distance testing |
| Augmentation for model development | 2 to 3 months | Documented augmentation with real evaluation held back |
| External sharing | Per case | Higher validation bar, legal review, recorded permitted use |
Start with test environments because the value is immediate and the privacy standard is achievable, and because it displaces masked production copies, which are a real and underrated exposure. The masking practices those environments currently rely on are covered in this guide to data masking and tokenisation for non-production.
Which metrics matter?
Validation pass rates per axis, distinguishability, train-synthetic-test-real performance gap, privacy test results, and adoption.
Report business rule and referential integrity pass rates as gates rather than as scores. Track distinguishability, since a classifier that separates real from synthetic easily indicates low fidelity. Measure the performance gap between models trained on synthetic and on real data for the specific task, which is the utility number that matters. Report privacy test results per dataset and per destination, with re-assessment dates. And measure adoption, meaning the share of non-production environments running on synthetic rather than copied production data, because that is where the risk reduction actually lands. Pipeline discipline for all of this sits alongside the practices in this guide to MLOps for regulated workloads.
Synthetic data is genuinely useful for the problems it fits and quietly misleading for the ones it does not. The institutions that get value from it decided the purpose first, measured utility against that purpose rather than against a general notion of realism, and treated privacy as something to test repeatedly rather than to assert once.
Frequently Asked Questions
What is synthetic data actually good for?
Test and development environments, augmenting rare cases, and enabling sharing where real data cannot travel. It is weakest as a wholesale replacement for real training data.
What are the three axes synthetic data is judged on?
Utility, fidelity, and privacy. The FCA, ICO and Alan Turing Institute framed validation that way, and the balance depends entirely on the use case.
Why is the use case central to validation?
Because fidelity that matters for one purpose is irrelevant for another. Test data needs referential integrity and edge cases, while model development needs distributional realism.
Is synthetic data automatically anonymous?
No. Generators can memorise and reproduce rare records, so privacy has to be measured through disclosure and inference testing rather than assumed by construction.
What makes financial data hard to synthesise?
Sequential transaction behaviour, hierarchical relationships across customers and accounts, referential integrity, hard business rules, and rare events that carry most of the value.
Should production models be trained on synthetic data?
Rarely on synthetic data alone. It works better for augmenting under-represented cases, pre-training, and testing, with real data anchoring the model that makes decisions.
How should privacy risk be assessed?
As a risk-based judgment accepting some inherent risk, tested with membership inference and attribute disclosure attacks, and re-assessed periodically rather than signed off once.
What governance does synthetic data need?
Provenance recording the source data, generator version, validation results, and permitted uses, plus retention rules and a record of which models were trained on it.
