Why test data is a regulatory issue for banks
Most regulatory attention goes to production. Test environments, development sandboxes and QA systems often carry the same sensitive data with far less oversight. Account numbers, transaction histories, KYC records and credit decisioning data are regulated wherever they sit, and one unmasked record in a test environment is enough to become a board-level issue.
- DORA expects financial entities to prove operational resilience through regular testing, and its scope reaches into non-production environments, not just live systems. See DORA test data requirements for SAP.
- GDPR applies to personal data in every copy of a system, including test and development.
- PCI DSS covers payment card data wherever it is stored, test systems included. See PCI DSS test data for SAP.
- BCBS 239 governs risk data aggregation and reporting, and in most implementations extends to how test environments are built and validated.
- UK firms also work to FCA and PRA expectations that don't always mirror EU requirements.
Testing AI agents before they touch live systems
Agents in banking operations read emails and documents, update customer records and move money. They need a realistic world to be tested in: the same customer across core banking, CRM, payments and the documents that arrive with each request, with none of it real. Synthesized builds that world inside your environment and resets it for every run, so agent behaviour can be tested, compared and evidenced before release. See the Test Data Agent and the safe-state layer.
Built for core banking and the systems around it
Core banking data is tightly interrelated, and some fields can't change without breaking the logic that depends on them. In Temenos T24, for example, account and customer records are threaded through structures that downstream modules rely on. Mask a field without understanding that chain and the result isn't a safer test environment, it's a broken one.
Synthesized keeps referential integrity and business rules intact across core banking, digital channels, CRM and payments, so the same customer, account and transaction line up in every system and end-to-end tests mean something. Read more about Temenos testing, Avaloq testing, SAP test data and Salesforce.
How Synthesized works in a bank
- Production-realistic data: account structures, transaction histories and relationships are preserved, so tests reflect how the systems actually behave.
- Financial-aware masking: account numbers, KYC records and credit decisioning data are treated with the same rigor as names and addresses, not left to generic PII detection.
- Synthetic edge cases: generate fraud patterns and rare conditions that production data never captures.
- Consistency across systems: the same customer and account across core banking, digital channels and payments.
- On demand, in your pipeline: self-service access for distributed teams and CI/CD integration for continuous testing.
Questions banks ask
Does production data have to leave our environment?
No. Synthesized runs inside your own environment, so masking, subsetting and generation happen under your existing security controls.
How does it help with DORA resilience testing?
DORA expects regular testing of failover, recovery and other scenarios. Synthesized lets teams run that testing on masked or synthetic data, so non-production environments don't hold live customer data.
Can we test AI agents with it?
Yes. The Test Data Agent builds linked customers, accounts, transactions and documents for each agent scenario inside your environment, so agents are validated before they act on live systems.
Can we test fraud and credit risk models?
Yes. AI-driven fraud detection and credit risk models need realistic, governed data before they can be trusted in production. Synthetic data covers the rare and adversarial cases production doesn't contain.
Which banking platforms does it support?
Synthesized works with core banking platforms such as Temenos and Avaloq, with SAP and Salesforce, and with the relational databases behind them, keeping data consistent across all of them.
For a fuller view, read Test data management for financial services: what banks and insurers need to know, or book a demo.
.svg)
