Synthetic Data for Finance: Generate Realistic Transaction Datasets

Contents

Figure 1: Synthetic data solves the access problem — proving it preserved the behavior your model tunes against is a separate problem

You need thousands of labeled fraud examples to train a detection model, and real fraud data is scarce, privacy-restricted, and legally painful to share across teams or institutions. Synthetic transaction data looks like the obvious answer. It mostly is, but a genuinely important piece of recent research shows synthetic data can quietly undermine exactly the fraud model it's meant to help train, if you don't know what to check for. Let's cover both the real promise and the real limits.

Why Finance Leans on Synthetic Data So Heavily

Two separate problems push financial institutions toward synthetic transaction data. The first is privacy and regulation: raw transaction data can't be freely shared under GDPR and similar frameworks, so when teams need to collaborate across institutions, or share a test dataset with a vendor, synthetic generation is the natural substitute for data that legally can't move. The second is scarcity: fraud is rare by definition, meaning real labeled fraud examples are always a tiny minority class, and insufficient data to train on remains a persistent bottleneck for fraud detection models regardless of how much legitimate transaction volume an institution has.

Generative AI more broadly gives risk teams realistic, privacy-safe examples of fraud activity that let them train and test models without exposing sensitive customer information, and it can help surface new or evolving fraud types by simulating scenarios banks haven't actually encountered yet in their own historical data.

The Three Main Modeling Approaches

Different generation techniques suit different financial data types, and picking the wrong one for your use case is a common early mistake.

GANs (Generative Adversarial Networks) tend to lead specifically for fraud detection and transaction modeling. The generator-discriminator adversarial setup is well-suited to capturing the kind of sharp, non-Gaussian patterns real transaction data exhibits — sudden spikes, categorical merchant codes, bursty timing — that simpler statistical methods struggle to reproduce convincingly. CTGAN, a conditional tabular GAN variant, is one of the most commonly referenced implementations in recent financial synthetic-data research specifically because it handles the mixed categorical-and-continuous nature of transaction records directly.

VAEs (Variational Autoencoders) and copula methods tend to be the stronger choice specifically for credit risk modeling, where capturing the correlation structure between financial variables — income, debt ratios, credit history — accurately matters more than reproducing sharp behavioral spikes the way fraud detection needs.

Knowledge-based, rule-aware generators represent a newer, more specialized category. AMLNet, for instance, is a multi-agent framework pairing a regulation-aware transaction generator with an ensemble detection pipeline, built specifically to address how constrained anti-money-laundering research is by the lack of publicly shareable, regulation-aligned transaction datasets. This category matters because AML patterns — layering, structuring, smurfing — have specific regulatory definitions that a generic statistical generator trained purely on distributional fidelity has no reason to reproduce correctly.

The Critical Caveat: Fidelity Metrics Can Lie to You

Here's the research finding worth taking seriously before you trust any synthetic fraud dataset. Existing synthetic data benchmarks typically measure two things: statistical fidelity (whether marginal distributions and pairwise correlations match the real data) and downstream utility (whether a classifier trained on synthetic data generalizes when tested against real data, a protocol commonly called "train synthetic, test real" or TSTR). Both are necessary, but a recent benchmark specifically on financial fraud found both are insufficient.

The actual finding is concrete and worth internalizing directly: in CTGAN-generated synthetic data, a specific fraud-detection rule fired at an absolute rate 0.36 points lower than in the corresponding real fraud data. A detection threshold tuned to minimize false positives against that synthetic data would be far too permissive once deployed against real fraud, which triggers that same rule at a materially higher rate in reality. The synthetic data passed standard fidelity and utility checks while still silently encoding a behavioral gap serious enough to make a model tuned against it genuinely worse at catching real fraud.

The underlying reason: fraud detection is fundamentally a behavioral problem, built on temporal bursts, velocity rule violations, and shared-infrastructure signals — the kind of time-dependent, relational structure standard tabular generators aren't explicitly built to preserve, even when they nail the marginal distributions and pairwise correlations that conventional fidelity metrics check for.

The practical takeaway: don't trust a synthetic fraud dataset based on distributional fidelity and TSTR accuracy alone. Specifically validate that temporal patterns, velocity-rule firing rates, and multi-account behavioral signals in your synthetic data match real data's rates, not just its shape, before tuning detection thresholds against it.

What a Realistic Synthetic Transaction Record Looks Like

A properly built synthetic financial dataset typically includes transaction amounts drawn from category-aware distributions, since a grocery transaction and a mortgage payment have genuinely different realistic ranges, timestamps reflecting plausible temporal spending patterns rather than uniform randomness, merchant categories, running account balances that stay internally consistent across a simulated account's transaction history, and configurable fraud labels covering multiple distinct fraud types rather than one undifferentiated binary flag.

That last point matters more than it might seem. Real fraud isn't one pattern: card-not-present fraud, account takeover, synthetic identity fraud, and first-party fraud all have genuinely different behavioral signatures. A synthetic dataset that labels everything "fraud" versus "not fraud" without distinguishing these types trains a model that's less useful for the kind of fraud-type-specific detection most real fraud teams actually need.

A Basic Generation Workflow

Here's the general shape of a CTGAN-based approach, since it's the most commonly referenced technique for this specific use case:

from ctgan import CTGAN
import pandas as pd

# Your real (or carefully anonymized) transaction data,
# with amount, merchant_category, hour_of_day, is_fraud, etc.
real_data = pd.read_csv("transactions.csv")

discrete_columns = ["merchant_category", "is_fraud", "channel"]

model = CTGAN(epochs=300)
model.fit(real_data, discrete_columns)

synthetic_data = model.sample(100_000)

That gets you a baseline synthetic dataset quickly, but given the fidelity gap covered above, treat this as a starting point, not a finished product. Before using it to tune detection thresholds, validate specifically: does the synthetic data's rate of velocity-rule triggers (multiple transactions in a short window, rapid geographic movement, shared device or IP signals) match the real data's rate, not just its overall fraud percentage? If it doesn't, your thresholds will be miscalibrated in exactly the way the benchmark research found.

Established Domain-Specific Generators

Beyond general-purpose GANs, a couple of purpose-built generators show up repeatedly in the fraud detection research literature specifically because they were built around financial transaction structure from the start, rather than adapted from a generic tabular GAN. PaySim and Banksformer are the two most commonly cited, both built specifically to generate realistic transaction information with the behavioral structure fraud detection needs. Worth evaluating these as a starting point before building a custom pipeline from scratch, since they've already absorbed some of the domain-specific lessons a generic approach would need to rediscover — and the SDV tutorial elsewhere in this series covers the general tabular toolkit these build on.

For teams that want a managed, ready-to-use option rather than training a generator themselves, hosted synthetic financial data generators exist specifically for this use case, producing bank-statement-quality transactions with category-aware amounts, temporal spending patterns, running balances, and configurable fraud labels without requiring any real customer data as a seed. These suit fintech QA pipelines and data platform development well; for a production fraud model's actual threshold tuning, still apply the behavioral-fidelity validation covered above regardless of the source.

Privacy Isn't Fully Solved Just Because Data Is Synthetic

A genuinely important governance point: synthetic data significantly reduces privacy risk, but it does not eliminate it. Membership inference attacks — where an adversary determines whether a specific individual's real data was used to train the generation model in the first place — remain a real concern even against purely synthetic output. If your generator overfits to its training data, a well-crafted query against the synthetic output can sometimes reveal whether a specific real customer's transaction pattern was part of what the model learned from.

The practical mitigation that shows up consistently across the literature: differential privacy mechanisms, with carefully chosen epsilon values, bounding how much any single training record can influence the generator's output. This isn't optional for anything feeding a regulated financial use case. Legal and compliance teams should be involved in evaluating any synthetic data program before it goes into production, including the specific epsilon values chosen, rather than treating "it's synthetic" as sufficient privacy cover on its own — the same discipline the synthetic data privacy piece applies in healthcare contexts, and the data governance evaluation framework covers for platform selection.

Regulatory Reality: Frameworks Are Still Catching Up

Worth setting honest expectations here: financial regulators are still actively developing frameworks for evaluating whether a given synthetic dataset provides adequate representation of real-world risk and behavior. That means "we used synthetic data" isn't yet a fully settled, universally accepted compliance answer the way it might eventually become — your specific regulator and jurisdiction may not have a mature position on exactly what validates a synthetic dataset as adequate for a given regulated use case. Treat synthetic data as a tool that reduces risk and enables collaboration that raw data sharing wouldn't allow, not as a blanket substitute for your existing data governance program.

A Practical Validation Checklist

Before trusting a synthetic transaction dataset for anything that touches real fraud detection thresholds:

1. Check distributional fidelity first — do marginal distributions and pairwise correlations between amount, merchant category, time, and other fields reasonably match the real data.
2. Then go further and check behavioral fidelity specifically — do velocity-rule trigger rates, temporal burst patterns, and multi-account signal rates in the synthetic data match real data's rates, not just its shape, since this is exactly where the documented CTGAN gap showed up.
3. Run the TSTR protocol — train a classifier on synthetic data and test it against held-out real data — but treat that result as necessary, not sufficient, given the documented cases where this check alone didn't catch the behavioral gap.
4. Evaluate privacy exposure explicitly through differential privacy guarantees and membership inference testing, not just an assumption that synthetic equals private.
5. Involve legal and compliance before production use, specifically reviewing the generation methodology and privacy parameters against your actual regulatory obligations.

Common Mistakes to Avoid

• Trusting standard fidelity and TSTR-utility metrics alone to validate synthetic fraud data is the single most consequential mistake given the documented research — those checks can pass while behavioral signals that matter for threshold tuning remain meaningfully off.
• Treating "synthetic" as automatically equivalent to "private" skips the real, documented membership inference risk that persists even in purely generated data, especially from an overfit generator.
• Using a generic tabular GAN without domain-specific validation for AML or regulatory-pattern use cases misses the specific behavioral structure — layering, structuring, specific regulatory definitions — that a purpose-built tool like AMLNet was built to address directly.
• Skipping legal and compliance review because the data "isn't real" leaves a genuine regulatory gap, given that frameworks for evaluating synthetic data adequacy are still actively developing rather than settled.

Recommended Books

Unlock AI That Actually Works

Get lifetime access to GPT-6 Astra, Claude Fable 5.1, Gemini 3.5, Grok 4.5, and more — all in one platform. Build websites, apps, videos, content, and digital products from a single command. No monthly fees. No tool-hopping.

Click here to get GPTAstra Max now — one-time payment, lifetime access.

Frequently Asked Questions

Why do financial institutions use synthetic transaction data?

Two problems push in the same direction. Privacy and regulation: raw transaction data can't be freely shared under GDPR-like frameworks, so synthetic generation substitutes for data that legally can't move between teams or institutions. Scarcity: fraud is rare by definition, so real labeled fraud examples are always a tiny minority class, and insufficient positive data remains the persistent bottleneck for fraud detection models regardless of legitimate transaction volume.

Which modeling approach works best for synthetic financial data?

GANs — especially CTGAN — lead for fraud detection and transaction modeling, since the adversarial setup captures sharp non-Gaussian patterns like sudden spikes, categorical merchant codes, and bursty timing. VAEs and copula methods suit credit risk better, where correlation structure between financial variables matters more than behavioral spikes. For AML, purpose-built rule-aware generators like AMLNet matter because layering and structuring have regulatory definitions a distributionally-faithful generic generator has no reason to reproduce.

Can synthetic data pass fidelity checks and still hurt my fraud model?

Yes — this is the documented research finding the article is built around. In CTGAN-generated synthetic data, a specific fraud-detection rule fired at an absolute rate 0.36 points lower than in real fraud data, while the dataset still passed standard statistical-fidelity and train-synthetic-test-real utility checks. A threshold tuned to minimize false positives against that synthetic data would be far too permissive against real fraud, which triggers the rule at a materially higher rate.

Is synthetic data automatically privacy-safe?

No. Synthetic data significantly reduces privacy risk but does not eliminate it: membership inference attacks can reveal whether a specific individual's real data was used to train the generator, especially an overfit one. The consistent mitigation in the literature is differential privacy with carefully chosen epsilon values bounding any single record's influence, plus legal and compliance review of the generation methodology and privacy parameters before production use — not an assumption that synthetic equals private.

Wrapping Up

Synthetic transaction data genuinely solves real problems in finance — privacy-constrained collaboration, scarce fraud labels, and regulatory-safe model testing — and GANs, particularly CTGAN variants, lead for fraud-specific use cases while VAEs and copula methods suit credit risk modeling better. But the documented gap between passing standard fidelity checks and actually preserving the behavioral signals fraud detection depends on is a real, measured limitation, not a theoretical concern: a model tuned against synthetic data that looks statistically sound can still end up meaningfully too permissive against real fraud.

Will synthetic data replace the need for real transaction data entirely? No, and the honest regulatory and research consensus right now is that it's a powerful complement with real limits, not a complete substitute. Validate behavioral fidelity specifically before tuning any production threshold against synthetic fraud data, bring legal and compliance in early on the privacy mechanics, and treat the distributional fidelity and TSTR checks as a floor, not a finish line.

Related Articles

• Synthetic Data for Privacy: Anonymize Sensitive Datasets
• SDV Tutorial: Generate Synthetic Tabular Data with Python
• Best Data Governance Platforms for Enterprise ML
• Model Monitoring in Production: Detect Drift Before It Hurts You (2026)