Data is what makes any modern organization work, and in banking it is also among the most sensitive assets to manage. Models designed to detect fraud, assess risk or improve customer service often depend on information about real people and real money. Synthetic data offers one way to reduce the tension between making data useful and keeping it protected. Across Santander, teams are exploring where that approach can deliver the most value
Synthetic data is already being applied to internal use cases, creating realistic records without placing real customer data inside the resulting datasets. One internal initiative goes a step further: a generator designed to reproduce not just a single table, but an entire relational database including multiple linked tables and the time series embedded within them, such as a customer’s transactions, balances and events over several months.
Generating a realistic version of one table is relatively easy but relationships across multiple tables while keeping each customer history internally consistent is much harder and remains beyond what many off-the-shelf tools are designed to handle.
The distinctive feature is how the generator learns. It is fitted only on aggregate statistics extracted from the source (distributions, correlations, seasonal and sequential patterns) and rebuilds a realistic copy from those alone. Because no model ever sees a real record, there is essentially nothing to trace back to a real person: privacy is built in from the start, not patched on later. The same approach is also designed to work across unfamiliar databases without requiring extensive manual tuning.
For Data & AI Science teams, that can make experimentation significantly easier. Models can be trained and evaluated without giving development teams direct access to the original databases, reducing some of the confidentiality, legal and governance reviews that often arise before an initial experiment can begin. Clearing access to production data can take months, sometimes more than a year. A usable synthetic copy is ready in weeks.
Synthetic datasets still need to meet a defined quality threshold before use. Each copy is evaluated across fields, relationships and temporal patterns to determine how well the structure of the source data has been preserved. Additional tests can assess whether a classifier is able to distinguish synthetic records from real ones, providing another signal about both realism and privacy. A synthetic dataset is used only when those metrics meet thresholds defined in advance.
The point isn't only to avoid using real data, it's that we never have to touch it. Rebuild a whole database from its statistics alone, and a team can start building on day one, with the privacy question largely settled before anyone asks it.
Synthetic data benefits
Synthetic data is neither anonymised real data nor randomly invented information. A generative model learns the statistical structure of a real dataset: the distribution of individual fields and, more importantly, the relationships between them. It then creates new records that reproduce those patterns without directly copying individual observations.
For the predominantly tabular data found in banking, commonly used approaches include CTGAN and TVAE, Gaussian Copulas for simpler cases, and newer diffusion-based generators such as TabDiff.
With a standard library the recipe is short — but note that the model trains directly on the real rows:
```python
from sdv.single_table import CTGANSynthesizer
synth = CTGANSynthesizer(metadata)
synth.fit(real_transactions) # the model reads the real rows to learn their structure
synthetic = synth.sample(1_000_000) # brand-new records, no real customer inside
```
The internal approach separates that first stage into two steps. The source data is accessed once, inside the secure environment where it already resides, solely to compute aggregate statistics. The generator then works from those aggregates rather than from the underlying rows.
```python
# Step 1 — runs once, in the secure zone; only aggregates ever leave it
stats = extract_statistics(real_database) # distributions, correlations, seasonality — not rows
# Step 2 — runs anywhere, with no access to the originals
synth = StatsGenerator(stats)
synthetic = synth.sample(1_000_000)
```
The real data still needs to be processed to calculate those statistics, but that access takes place once, inside the controlled environment where the data already sits, and only for the purpose of extracting non-identifying aggregates. After that point, the individual rows do not need to move, and the generative model cannot memorise records that were never part of its training input. That distinction is important: the goal is not simply to reduce unnecessary exposure, but to redesign the process so that direct access to sensitive data is required at as few stages as possible.
Synthetic data is not automatically safe. A well-established tension exists between fidelity and privacy: the more accurately a synthetic dataset reproduces the statistical structure of its source, the more useful it can become, but the greater the risk that information about the underlying training data may also be inferred.
Membership inference attacks illustrate that problem. Their goal is to determine whether a particular record was included in a model’s training data, and highly faithful generators can be more susceptible to this kind of attack.
Realism alone is therefore not enough. A synthetic dataset needs to be assessed across three dimensions at the same time:
- Fidelity: Does it preserve the important statistical properties of the source data?
- Utility: Can models trained on synthetic data perform effectively when applied to real data?
- Privacy: How much information about individual records can potentially be inferred?
Differential privacy can bound the last dimension, adding calibrated noise so no single record changes the output much, at some cost to fidelity. Choosing that trade-off deliberately is the real engineering task.
Impact on banking
Synthetic data removes friction elsewhere too. Rare but critical patterns, like fraud, can be amplified for training without exposing a single customer.
That use case is already reflected in gen-fraud-graph, an open-source generator for synthetic account networks, transactions and money-laundering patterns. It enables graph-based fraud detection and anti-money-laundering models to be trained and benchmarked against realistic structures without relying on real financial records. Released under Apache-2.0, the project also provides a common foundation on which other researchers and developers can build, test and compare approaches.
The broader regulatory direction reinforces the importance of this work. Data-governance principles under frameworks such as the GDPR and the EU AI Act place strong emphasis on appropriate data management and minimising unnecessary use of personal information. Carefully designed synthetic-data processes can support those objectives.
