How does synthetic data support open banking and PSD2 compliance?

Synthetic data supports open banking and PSD2 compliance by replacing real customer financial records with statistically accurate, artificially generated datasets that carry no personal information. This allows banks, fintechs, and third-party providers to build, test, and share data-driven systems without exposing sensitive customer data to privacy risks or regulatory breaches. The sections below explore each dimension of that relationship in detail.

What data privacy challenges do open banking APIs create?

Open banking APIs create significant data privacy challenges because they require banks to share customer financial information with third parties by design, while simultaneously demanding that every data transfer comply with strict regulations like GDPR. This structural tension between mandated openness and mandatory protection is the defining compliance challenge for any institution operating under PSD2.

The scale of the problem is growing alongside the market itself. As financial data flowing through APIs becomes more valuable, it also becomes a more attractive target. Open banking API vulnerabilities have increased sharply in recent years, with API-related attacks in financial services rising at a pace that has made them the fastest-growing attack vector in digital banking. A single compliance failure can be costly: a Spanish bank received a multi-million-euro GDPR fine in 2024 for inadequate security measures under Article 32, illustrating the financial exposure that open banking API incidents carry.

Beyond security, the consent architecture itself is structurally complex. GDPR requires explicit consent, data minimization, and a 72-hour breach notification window for all API-related incidents. The IAPP has identified multi-party consent management in open banking as one of the most significant structural compliance challenges, because GDPR obligations must be tracked and enforced across every party in the data-sharing chain, not just the originating bank.

PSD2 adds further precision requirements. Account servicing payment service providers are legally restricted to sharing payment account information only. There is no legal basis under PSD2 to expose data from savings, mortgage, or investment accounts through the same API layer, meaning technical access controls must be deliberately scoped to match legal permissions. Managing those boundaries consistently, across dozens of API integrations with third-party providers, is where many institutions find their compliance posture most vulnerable.

How does synthetic data replace real customer financial records?

Synthetic financial data replaces real customer records by using machine learning algorithms to analyze the statistical patterns in real datasets and then generate entirely new records that reproduce those patterns without containing any actual customer information. The result is a dataset that behaves like real financial data for analytical and development purposes, but carries no personal identifiers that could be traced back to a real individual.

The generation process is more sophisticated than simply scrambling or anonymizing existing records. Modern approaches use techniques such as generative adversarial networks, variational autoencoders, and Gaussian copulas to capture complex relationships between variables like account balances, transaction histories, credit utilization, and payment behaviors. The synthetic output preserves those correlations, which is what makes it analytically useful rather than just statistically inert.

Major financial institutions have already moved in this direction. U.S. Bank, JPMorgan Chase, NatWest, Monzo, and Santander have all deployed synthetic data ecosystems to train AI models and test financial products, replacing live customers with AI-generated synthetic profiles for product testing. Santander’s approach is particularly instructive: real source data is accessed once inside a secure environment to compute aggregate statistics, and the generator then creates new records that reproduce those patterns without directly copying any individual observation. This privacy-by-design architecture means real data never leaves the secure perimeter.

At the regulatory level, the European Commission’s EU Digital Finance Platform Data Hub was built on the same principle. National supervisors generated synthetic datasets from their real supervisory data to enable cross-institutional data sharing without exposing confidential records. The Joint Research Centre confirmed the synthesized data successfully replicated the main patterns of the original, validating the approach for high-stakes regulatory contexts.

One important nuance: synthetic data derived from real financial records is not automatically outside GDPR’s scope. The EDPB’s Opinion 28/2024 requires a case-by-case assessment of anonymity, meaning institutions cannot assume that generating synthetic data from real records automatically removes GDPR obligations. The generation process must be robust enough that no real individual’s information can be recovered or inferred from the synthetic output.

Which PSD2 compliance requirements does synthetic data directly address?

Synthetic data directly addresses PSD2’s data minimization requirements, its prohibition on purpose-limited data use, and its mandate that all personal data processing comply with GDPR. By replacing real customer records in development and testing workflows, synthetic data allows institutions to meet these obligations structurally rather than relying solely on access controls and policy enforcement.

Data minimization and purpose limitation

PSD2 Articles 66 and 67 prohibit payment initiation service providers and account information service providers from using, accessing, or storing data beyond what is explicitly required for the service the customer requested. In practice, this means every development environment, test pipeline, and analytics workflow that touches customer data must be scoped to the minimum necessary information. Synthetic data environments allow developers to build and validate against these requirements without touching real customer records at any stage of the process.

Strong Customer Authentication testing

PSD2 mandates Strong Customer Authentication for online payments across the European Economic Area, requiring at least two authentication factors from the categories of knowledge, possession, and inherence. Testing SCA flows thoroughly requires realistic transaction data and user behavior patterns. Synthetic data provides that realism without exposing real user credentials or payment details, making it possible to stress-test authentication systems, simulate edge cases, and validate 3D Secure 2 implementations in a fully controlled environment.

GDPR alignment under PSD2 Recital 89

Recital 89 of PSD2 specifies that all personal data processing must comply with GDPR, including requirements around necessity, proportionality, purpose limitation, and data retention. Synthetic data supports compliance with each of these principles by removing personal data from the processing chain entirely at the development stage. The remaining caution, as noted above, is that synthetic datasets derived from real records must be generated with sufficient rigor to satisfy a case-by-case GDPR anonymity assessment.

Looking ahead, PSD3 and the accompanying Payment Services Regulation, for which provisional political agreement was reached in late 2025, will strengthen API performance standards and mandate customer permission dashboards. The PSR is expected to apply across EU member states from mid-to-late 2027. Institutions that build synthetic data practices into their compliance infrastructure now will be better positioned to adapt to those strengthened requirements without rebuilding their data workflows from scratch.

Can synthetic data be used to test open banking APIs safely?

Yes, synthetic data is actively used to test open banking APIs safely, and it is now the standard approach in regulatory sandboxes across multiple jurisdictions. By populating test environments with synthetic financial records that mirror the structure and behavior of real data, developers can validate API integrations, authentication flows, and compliance logic without any risk of exposing live customer information.

The FCA’s Digital Sandbox is the most prominent example. It provides access to hundreds of synthetic, anonymized, and pseudonymized datasets alongside thousands of API endpoints covering transactions, loans, financial statements, and more, all within a GDPR-compliant environment. In 2026, the FCA collaborated with the Alan Turing Institute and other partners to publish a synthetic AML dataset and run a dedicated sprint enabling firms to test AI-driven anti-money laundering detection approaches without handling any real customer data. That initiative demonstrates how synthetic data testing has moved from a niche workaround to a formally supported regulatory mechanism.

Other frameworks reinforce the same approach. The Open Bank Project’s regulatory sandbox provides hundreds of APIs alongside localized synthetic datasets, giving third-party providers a controlled testing environment with relaxed regulatory requirements during the development phase. The Inter-American Development Bank’s APIBox tool enables open finance API testing using synthetic data with real interaction patterns, specifically designed to lower the cost of compliance testing for new market entrants such as account information service providers and payment initiators.

For institutions building their own infrastructure, sandbox environments populated with synthetic data can replicate authentic response formats, realistic transaction flows, proper error handling, and regulatory compliance features. When combined with security controls like OAuth 2.0, mutual TLS, and JWT authentication, and maintained with a complete air gap from production systems, these environments allow thorough API testing without creating any pathway to live customer records.

What are the limits of synthetic data for PSD2 use cases?

Synthetic data has meaningful limitations in PSD2 contexts, particularly for fraud detection and anti-money laundering applications. Current synthetic generation methods struggle to reproduce the temporal, velocity-based, and multi-account behavioral signals that fraud models depend on, which means synthetic-only training environments can produce models that are miscalibrated when deployed against real transaction patterns.

The FCA’s synthetic AML project report was explicit about this constraint. Synthetic datasets can only capture known money laundering typologies. They cannot reflect laundering methods that have not yet been identified or codified, which creates a fundamental gap for any compliance system that needs to detect novel or evolving financial crime patterns. The report also flagged internal coherence challenges: preserving realistic relationships between customers, accounts, and transactions is technically difficult when records are generated independently rather than as part of a coherent behavioral sequence.

The governance dimension is equally important. There is currently no industry-standard benchmark for what constitutes sufficiently high-quality synthetic financial data. A rigorous validation framework should include statistical fidelity tests, downstream model performance comparisons against real-data baselines, and adversarial testing designed to probe for privacy leakage and distributional gaps. Without that validation layer, institutions risk building compliance systems on synthetic data that appears accurate but diverges from real-world behavior in ways that only become visible after deployment.

Regulatory expectations are also tightening. The EU AI Act’s high-risk AI obligations, taking effect in 2026, require institutions to document the full lineage of synthetic datasets used in regulated models, including source, generation method, purpose, and exposure history. If a compliance model or board-level policy relies on synthetic data, its provenance must be audit-ready. Separately, the EDPB’s Opinion 28/2024 clarified that synthetic outputs derived from real financial data cannot automatically be assumed to fall outside GDPR scope, requiring institutions to conduct case-by-case anonymity assessments rather than treating synthetic generation as a blanket privacy solution.

The practical conclusion from both regulators and independent researchers is consistent: synthetic data should complement real-world data in PSD2 compliance workflows, not replace it entirely. Treating synthetic datasets as a definitive representation of real-world risk, without ongoing calibration against live data, introduces the very compliance vulnerabilities the approach is meant to eliminate.

How do banks and fintechs share data securely using synthetic datasets?

Banks and fintechs share data securely using synthetic datasets by generating privacy-safe replicas of real financial data that can be distributed to partners, developers, and regulators without triggering data transfer restrictions or GDPR obligations tied to personal information. This approach allows analytically useful datasets to flow across organizational and national boundaries while the underlying customer records remain inside secure, controlled environments.

The EU Digital Finance Platform Data Hub demonstrates this at a regulatory scale. National supervisors generate synthetic datasets from the real supervisory data they hold, then contribute those synthetic versions to a shared hub where other supervisors and financial firms can access them for testing and model development. No real customer data leaves any national authority’s secure perimeter, yet the shared datasets retain enough statistical fidelity to support meaningful cross-institutional analysis.

In commercial open banking partnerships, the same logic applies. A fintech building a credit assessment tool on top of a bank’s API can receive a synthetic replica of the bank’s transaction dataset to train and validate its models during development, then integrate with live data only at the point of production deployment under full regulatory controls. This staged approach reduces the volume of real data that third parties ever need to access, directly supporting PSD2’s data minimization requirements.

The question of cross-border synthetic data transfers deserves careful attention. While synthetic data derived from real records may not carry personal information in the conventional sense, the EDPB’s case-by-case anonymity standard means institutions should not assume that sharing synthetic datasets internationally is automatically free of data transfer obligations under GDPR. This is an area where legal counsel familiar with both the generating institution’s jurisdiction and the recipient’s jurisdiction is essential before establishing a data-sharing arrangement.

For institutions evaluating how to implement this in practice, the key design principle is privacy by architecture rather than privacy by policy. Santander’s internal approach illustrates this well: real source data is accessed once, solely to compute aggregate statistics, and the generator then creates new records that reproduce patterns without retaining any link to individual observations. That separation between the statistical learning phase and the generation phase is what makes the output safe to share. We follow a similar philosophy at BlueGen AI, ensuring that synthetic datasets generated from real financial data are structurally incapable of re-identifying the individuals whose records informed the generation process.

The open banking landscape is moving quickly, with PSD3, the Payment Services Regulation, and the forthcoming Financial Data Access regulation all set to expand both the scope of mandatory data sharing and the precision of compliance requirements over the next two years. Institutions that build synthetic data practices into their compliance and development workflows now will be better placed to absorb those changes without disrupting live customer data environments. If you want to see how a purpose-built synthetic data platform handles these challenges in practice, request a demo and we will walk you through it.

window.addEventListener(‘scroll’, function() { var bar = document.getElementById(‘sticky-cta’); if (window.scrollY > 600) { bar.style.display = ‘block’; } else { bar.style.display = ‘none’; } });