Banks and insurers operate under some of the strictest data regulations of any industry, and most of that regulatory attention is aimed at production systems. What gets less scrutiny, until something goes wrong, is everything sitting just outside production: the test environments, development sandboxes, and QA systems that carry the same sensitive data with considerably less oversight.
It's a gap that's becoming harder to justify. Modernization programs are moving faster, AI-driven testing is becoming standard, and continuous delivery means there's rarely a natural point to stop and check compliance properly.
Why financial services test data is different
Every industry deals with test data challenges. Financial services carries a specific combination of factors that make the problem harder to solve with generic tooling.
Every piece of this data is regulated for a reason. Account numbers, transaction histories, KYC records, credit decisioning information, none of it is casual, and slipping up with any of it doesn't stay quiet for long. One unmasked record in a test environment is enough to put something in front of the board.
Then there's the complexity of the platforms themselves. Core banking systems hold data that's tightly interrelated, and certain fields can't be changed at all without breaking the logic that depends on them. In Temenos T24, for example, account and customer records are threaded through CONCAT structures and live files that downstream modules depend on. Mask a field without understanding that dependency chain, and the result isn't a safer test environment, it's a broken one.
A masking tool built for an ordinary relational database won't know the difference. It either misses what's sensitive or breaks the environment outright.
The regulatory picture is broader than most teams plan for
Most compliance conversations around test data default quickly to GDPR. That's necessary but incomplete for financial services specifically.
DORA expects financial entities to prove operational resilience through regular testing, failover, recovery scenarios, all of it, without exposing live customer data along the way. Regulators can levy substantial fines for ICT governance failures, and DORA's scope reaches explicitly into non-production environments, not just live systems.
BCBS 239 belongs in this picture, too. It governs data aggregation and risk reporting accuracy, and in most implementations that standard extends to how test environments are built and validated, not just production reporting. PCI-DSS isn't limited to production either. Payment card data falls under it wherever it sits, including test systems. UK firms carry an extra burden on top, since the FCA and PRA set expectations that don't always mirror what the EU requires.
Manual masking, updated whenever someone remembers as schemas change, can't keep pace with all of this stacked together. Every new requirement adds another layer of obligation, and a spreadsheet of masking rules was never built to track that reliably.
Where testing actually breaks down
The most consistent source of late-stage defects in financial services testing is cross-system complexity. Core banking platforms rarely operate in isolation.
Take customer onboarding as an example. The core platform generates the account. The digital front end captures KYC documents. The CRM logs the relationship. The payments processor sets up the mandate. Four teams, four independently built test datasets, none of them referencing the same customer ID or account number.
Every system test passes. The end-to-end process fails the moment it's tried for real, and by then it's UAT, or worse, production.
What modern test data management looks like in this context
The organizations making genuine progress here have stopped treating test data as a manual, one-off task. Instead, they're building a governed capability across four areas.
- Production-realistic data: account structures, transaction histories, and referential integrity preserved, so tests reflect how the system actually behaves.
- Financial-aware masking: account numbers, KYC records, and credit decisioning data treated with the same rigor as names and addresses, not left to generic PII detection.
- Synthetic data for the edge cases production never captures: fraud patterns and rare conditions that a system needs to be tested against before they happen for real.
- Consistency across every connected system: the same customer, account, and transaction data lines up across core banking, digital channels, and payments, so cross-system tests actually mean something.
None of this happens by accident. It requires treating test data as a platform capability rather than something each team solves for itself.
Why this matters now
A few pressures are converging at once:
- Core system modernization is moving forward while regulatory requirements shift quarterly
- AI-driven fraud detection and credit risk models need realistic, governed data before anyone can trust them in production
- The cost of a non-production compliance failure has never been higher, financially or reputationally
Getting the test data layer right is no longer a technical nicety. It's becoming one of the clearer signals of whether a financial services organization is actually ready for the pace of change it's committing to.
Want to see what this looks like for your organization? Book a demo and find out how Synthesized provisions compliant, production-realistic test data for core banking and insurance platforms, without expanding your compliance exposure into every environment that touches it.
