How would you derive test data for a payment system with strict regulatory requirements?

Payment systems combine "money is on the line" with "regulators are watching". Test data design has to satisfy both correctness and compliance.

The non-negotiables:

1. No real PII or card numbers in non-prod environments. PCI-DSS forbids it. Any test card number that resembles a real one is a violation. Use processor-provided test card numbers (e.g. Stripe's 4242 4242 4242 4242, Adyen's test BINs) — they're guaranteed safe and produce predictable outcomes.
2. Synthetic but realistic data. Names, addresses, emails should be synthetic (e.g. test+user1@example.com) but follow real-world patterns — internationally varied, with diacritics, with formats matching the markets you serve.
3. Test-data lineage and audit trail. For each test case, document where the data came from, why those values, and what the expected output is. Auditors will ask. Many teams keep test-data definitions in version control with explicit provenance.

Test data design layers:

Happy path: processor-provided "approve" card numbers, valid name/address/CVV combinations, normal amounts.

EP/BVA on amounts: £0.01 (minimum), £0.00 (boundary — should reject), £999,999 (large), exact processor limit, exact local regulatory limit. Different currencies — high precision (BHD has 3 decimal places), zero-decimal (JPY).

Negative test data: declined cards, fraud-flagged, stolen / lost (all processor-provided), insufficient funds, expired cards, wrong CVV / wrong AVS, card not supported in region.

Regulatory edge cases: 3DS / SCA challenges (Europe) — amounts that trigger Strong Customer Authentication; flow when challenge fails or is abandoned. AML reporting thresholds — amounts at and just above the reporting threshold. Cross-border transactions — currency conversion edges, sanctioned countries (verify they're blocked). Tax calculations — VAT/GST per region; tax-exempt scenarios; reverse-charge. Refund rules — partial, full, after payout; refund of refund (impossible). Chargebacks — simulated dispute flow; evidence submission; system state during dispute.

Compliance-specific design: PCI scope minimisation (test environment shouldn't store any card data; persistence is logged + encrypted; tests verify this). Audit logs (every payment event has a log entry with required fields; tests verify schema and content). Data retention (test data retained per policy — often 7 years for financial; tests for purge of expired data).

Cross-cutting: idempotency (re-submitting the same charge with the same idempotency key produces the same result), race conditions (concurrent refund + charge), reconciliation (test data periodically reconciled against processor's records).

The senior signal: treating test data design as a compliance discipline, not just a technical one. Every test case has a documented "why this data" rationale.