Synthetic financial data

Synthetic financial data can be generated from statistical relationships in existing records or from explicitly designed simulations. Account references, transaction amounts and timestamps need consistent relationships when an application depends on those connections. A dataset that resembles individual payments can still misrepresent the sequence of activity within an account.

The FCA Synthetic Data Expert Group examined financial applications including data augmentation, system testing and model validation. For a payment migration, teams could define expected balances, rejected transfers and duplicate requests before generation begins. Those criteria make the resulting records assessable against the banking process being tested.

In April 2026, the FCA published an anti-money-laundering synthetic data project developed with research and industry partners. The project modeled UK retail banking activity and added realistic money-laundering scenarios. This creates a research setting for evaluating detection approaches, without establishing their effectiveness across every production environment.

For AI fraud detection, useful synthetic scenarios can connect multiple accounts, transaction sequences and changing activity patterns. Teams should specify the behavior they expect a detector to recognize and the legitimate activity it should accept. An artificial scenario library supports controlled comparisons, while observed production outcomes remain necessary for assessing actual performance.

Matching average transaction values does not establish that a dataset supports its intended task. A model may depend on seasonal patterns, relationships between counterparties or rare combinations of attributes. The relevant checks therefore need to follow the financial process and the decisions being evaluated.

FCA research distinguishes privacy, utility and fidelity when evaluating synthetic data. Fidelity concerns resemblance to relevant source characteristics, while utility concerns usefulness for a particular application. Teams should agree acceptance criteria before generation and compare results with an appropriately protected reference dataset.

Generated records can retain information about the people represented in their source data. Rare combinations of attributes and memorized examples can create disclosure risks even when direct identifiers have disappeared. A privacy assessment should examine the generation method, the source population and the information available to potential recipients.

The CNIL identifies memorization and inference risks in AI development, alongside measures for securing development data. Synthetic therefore does not automatically mean anonymous or exempt from data protection requirements. Institutions need an assessment appropriate to their actual records, recipients and proposed sharing arrangement.

A generator and a predictive model can inherit the same weaknesses when both learn from closely related records. Evaluating the model only against generated examples can then conceal failures affecting real customers. Teams should preserve an independent evaluation strategy and explain which questions the synthetic dataset can answer.

Model validation in banking should examine whether performance persists under relevant changes in financial activity. Rare scenarios help challenge assumptions, but their artificial frequency cannot establish real-world prevalence. Comparisons should also inspect errors affecting different customer groups when those differences matter to the intended decision.

The European Commission Data Hub supports financial innovation with synthetic datasets through the EU Digital Finance Platform. Such environments can give participating teams a common starting point for experiments. Their usefulness still depends on whether the available attributes and relationships match the proposed financial application.

The University of St. Gallen studied a synthetic data ecosystem with two banks in the SynDEc project. For a comparable collaboration, participants should identify the required patterns, the responsible validators and the authorized recipients. Research participation alone does not establish that a dataset is suitable for unrestricted commercial distribution.

A procurement brief should identify the banking process, the expected test decisions and the relationships that generated records must preserve. Providers should explain how they handle time sequences, rare events, reproducibility and changes between dataset versions. Buyers should request separate evidence for privacy and task performance because one overall quality score can conceal important differences.

AI governance in banking connects those decisions to accountable ownership and documented approvals. An institution should establish who can access source records, approve generated datasets and withdraw a version after a problem. An initial experiment should produce a clear acceptance decision before the dataset reaches additional teams or partners.

The answer depends on the question and the evidence needed to resolve it. Synthetic records can support repeatable tests, controlled failure scenarios and development where direct access to customer records is restricted. They cannot prove how frequently an invented scenario occurs in an actual customer population.

A production decision therefore needs evidence covering the relevant real operating conditions. Financial institutions should document where generated records provide useful evidence and where additional observations remain necessary. That boundary makes synthetic data a defined testing instrument within a broader evaluation process.