I watched a payment processor fail a PCI DSS assessment for one reason: they had production PANs in their staging environment. Not in a database dump — in their automated test suite. A developer had copied a batch of real card numbers years earlier to test a tokenization module. The module worked. The test data stayed. The assessor found it.
That was under PCI DSS 3.2.1, where the requirement was softer. Under PCI DSS 4.0 — mandatory since March 31, 2025 — this is an explicit violation with no ambiguity. Requirement 6.5.4 states it directly: production PANs cannot be used in test or development environments.
Key Takeaway: PCI DSS 4.0 Requirement 6.5.4 explicitly prohibits using production account data (including PANs) in test and development environments. Requirement 3.3 restricts PAN display to only authorized personnel with a business need. Born-Synthetic data contains no real PANs by construction — compliance is structural, not procedural.
What PCI DSS 4.0 Actually Says About Test Data
PCI DSS 4.0, published by the PCI Security Standards Council, became mandatory for all entities that store, process, or transmit cardholder data as of March 31, 2025. The transition period from version 3.2.1 is over.
Requirement 6.5.4 is the one that changes everything for test environments. It states that production account data — including primary account numbers (PANs) — shall not be used in test or development environments. This is not guidance. It is a shall-not requirement with no exception mechanism.
The logic is straightforward: test and development environments typically have weaker access controls, broader developer access, less monitoring, and fewer change management procedures than production. Placing real cardholder data in these environments expands the attack surface without a compensating control.
Requirement 3.3 adds a second layer. PAN display must be restricted so that only authorized personnel with a documented business need can see more than the first six and last four digits (or the BIN and last four). This restriction applies wherever PANs appear — and if they appear in test environments, you must apply the same display controls as production.
Requirement 3.4 requires PAN to be rendered unreadable anywhere it is stored — including non-production environments. If PANs exist in a test database, they must be encrypted, truncated, tokenized, or hashed with the same rigour as production storage.
The cumulative effect: even if you could justify having production PANs in test (you cannot under 6.5.4), you would need to apply the full PCI DSS control set — encryption, access control, monitoring, display restrictions — to every test environment that contains them. The cost of compliance exceeds the cost of eliminating the problem.
The Three Ways Payment Teams Get This Wrong
I have reviewed test data practices at payment processors ranging from Series A fintechs to multinational acquirers. The same three patterns recur.
Pattern 1: Legacy test data. Production PANs were copied into test environments years ago, before PCI DSS 4.0 tightened the requirement. Nobody removed them because nobody audited what was in test databases. The data sits in test fixtures, seed files, staging databases, and CI/CD pipelines. Under 4.0, every one of these locations is a finding.
Pattern 2: Masked production data. The team truncates or masks PANs before copying production data to test. This addresses Requirement 3.3 (display restriction) and 3.4 (storage protection) but creates a false sense of security. The non-PAN fields — cardholder name, expiration date, service code, and associated customer data — still constitute cardholder data under PCI DSS scope. And if the masking is reversible (as it often is with format-preserving encryption), the PANs are not truly eliminated.
Pattern 3: Generated but unrealistic data. The team uses random number generators to create fake PANs. The numbers pass Luhn validation but carry no realistic customer context — no associated profiles, no transaction patterns, no geographic distribution, no risk indicators. The test suite passes, but it tests nothing that resembles production behaviour. When a real-world edge case arrives — a high-risk jurisdiction, a PEP cardholder, an unusual transaction pattern — the system has never seen anything like it.
Born-Synthetic: No PANs by Construction
Born-synthetic data eliminates the PCI DSS test data problem at its root. There are no production PANs in the data because no production data was used at any stage of generation.
The profiles are built from mathematical distributions — Pareto for wealth, algebraic constraints for balance sheets, geographic models for jurisdictions. For payment processor use cases, the 29-field KYC-enhanced profiles provide the customer context that makes test scenarios realistic: net worth tiers, geographic distribution across 6 niches, offshore structures, PEP indicators, risk ratings, sanctions screening results, and adverse media flags.
This is the distinction that matters: realistic test data does not require real data. What it requires is structural fidelity — the statistical properties, edge cases, and complexity of real-world populations. Born-synthetic data delivers structural fidelity without any lineage to real individuals or real accounts.
Every dataset ships with a Certificate of Sovereign Origin documenting the generation method and confirming zero real-world data input. When the QSA asks where your test data came from, you hand them the certificate.
PCI DSS Meets GDPR — Double Compliance for European Payment Processors
For European payment processors, PCI DSS 4.0 compounds with GDPR to create a double compliance requirement on test data.
PCI DSS 4.0 prohibits production PANs in test environments (Requirement 6.5.4).
GDPR Article 25 requires data protection by design in all processing environments — including test databases that contain customer personal data. See Why GDPR Article 25 Bans Real Data in Test Environments for the full analysis.
If your test environment contains production data, you are violating both frameworks simultaneously. PCI DSS for the cardholder data, GDPR for the personal data. Two regulators, two sets of penalties, one root cause.
Born-synthetic data resolves both violations with a single substitution. No PANs for PCI DSS. No PII for GDPR. One dataset, double compliance.
For payment processors operating across the EU, DORA adds a third layer — ICT resilience testing requirements that demand realistic but non-production test data. See DORA Requires Synthetic Data for Resilience Testing for how all three frameworks intersect.
Take the GDPR Risk Assessment to see where your current test data practices stand — the scoring applies to PCI DSS exposure as well.
The Cost of Getting It Wrong
PCI DSS non-compliance is not abstract. The PCI Security Standards Council does not impose fines directly — but the card brands (Visa, Mastercard, Amex, Discover) do, through the acquiring banks. Monthly non-compliance fines range from $5,000 to $100,000 depending on the severity and duration. Repeated violations can result in increased transaction fees or, in extreme cases, loss of the ability to process card payments entirely.
A single assessment finding for production PANs in test environments triggers remediation requirements that typically take 3-6 months to close. During that period, the entity may face restricted processing capabilities and increased oversight from the acquiring bank.
Compare that to the cost of replacing your test data with born-synthetic profiles: a one-time substitution that eliminates the finding before it occurs.
FAQ: PCI DSS 4.0 and Synthetic Test Data
When did PCI DSS 4.0 become mandatory?
March 31, 2025. All entities that store, process, or transmit cardholder data must now comply with PCI DSS 4.0. The transition period from version 3.2.1 has ended. Requirement 6.5.4 (no production PANs in test environments) is now fully enforceable.
Does Requirement 6.5.4 apply to all test environments?
Yes. Development, testing, staging, QA, UAT, and any other non-production environment. If the environment is not production and it contains production account data, it violates 6.5.4. There is no exception for “internal only” or “restricted access” environments.
Can I use tokenized production data in test environments?
If the tokenization is irreversible and the tokens cannot be mapped back to real PANs, the tokens are not considered account data under PCI DSS. However, the associated customer data (cardholder name, expiry, transaction history) may still contain personal data subject to GDPR. Born-synthetic eliminates both concerns.
Does born-synthetic data pass Luhn validation and format checks?
Sovereign Forger’s KYC-enhanced profiles focus on the customer identity layer — the 29 fields that describe the person behind the account. For payment-specific fields like PANs, you would pair the customer profiles with your own test card number generators (which produce Luhn-valid numbers without real account backing). The profiles provide the realistic customer context that makes your test scenarios meaningful.
How do I demonstrate compliance to my QSA?
Every Sovereign Forger dataset ships with a Certificate of Sovereign Origin documenting the generation method, the mathematical distributions used, and the absence of real-world data input. This certificate directly addresses the QSA’s evidence requirements for Requirement 6.5.4 compliance.
The March 2025 Deadline Has Passed
PCI DSS 4.0 is not a future requirement — it is the current standard. Every payment processor, acquirer, issuer, and service provider that has not eliminated production PANs from test environments is already non-compliant.
I built born-synthetic financial profiles specifically for compliance testing environments where real data creates regulatory exposure. 29 interlocked fields. Six geographic niches. Deterministic KYC signals. Zero PII. Zero PANs. Documented provenance.
Download 100 free KYC-Enhanced profiles and see what PCI DSS-compliant test data looks like.
