How to build realistic banking and card test data that keeps balances reconciling and card numbers valid, without exposing cardholder data.
Tutorial
Banking, lending and card platforms revolve around customers, accounts, cards, transactions and statements. Test data for these systems has to satisfy strict validation rules — check digits, account formats, balances that add up — while never exposing real customers or cardholder data.
A single customer may hold joint and sole accounts across several core systems, each with its own copy of the customer key. Test data that breaks those links, or that produces statements that no longer reconcile, is of little use to a test team.
A financial-services entity graph (illustrative). An illustrative financial model: a customer owns accounts; accounts have cards, transactions and statements. Subsets and masking must keep these links intact and balances consistent.Text description
Financial applications reject bad data early. A card number that fails its checksum never reaches the fraud engine you wanted to test; a transaction whose account is missing is dropped by the ledger. Naive masking therefore tends to produce data that is private but untestable. On the other side, copying production into QA spreads account numbers, balances and transaction descriptions to people and places that were never meant to hold them, and makes every non-production environment part of your cardholder-data scope. Regulators, auditors and customers all expect firms to keep that scope as small as possible.
Referential integrity across tables and systems. Parent records such as customers and accounts must exist for every child record such as transactions, cards and statements. When a key is masked, the same masked value must be used everywhere it appears so that joins still work across tables and systems.Text description
All values below are synthetic and invented for illustration.
Field
Before (synthetic)
After (synthetic)
Customer key
C-1001
C-8420
Account
A-2001, owner C-1001
A-6177, owner C-8420
Card number
4000 0012 3456 7899
4000 0098 7654 3210
Balance
1,250.00
1,250.00
The card substitute keeps the same length and prefix and still passes the checksum, so the application accepts it. The customer key is replaced the same way in core banking, card and statement systems, so joins work. Balances are preserved, or transformed in a way that keeps opening balance plus transactions equal to closing balance, so statements still reconcile.
How DataNivra approaches it
The financial-services industry pack provides an entity model for parties, accounts, cards, transactions and statements, detectors for card numbers (with checksum validation) and account-style identifiers, and presets for format-preserving substitution and deterministic keys. You approve them as your own policy versions.
All of the work is customer-resident processing: the agent reads your sources locally, builds a subset driven by customers or accounts, masks, validates referential integrity and balance rules, and certifies the result. The control plane only sees metadata such as table names, counts and certification outcomes.
The pack supports PCI DSS–oriented and privacy programmes by keeping cardholder and customer data inside your environment. It does not certify any system. See the financial-services pack.
Common pitfalls
Masked account numbers that fail validation. Card numbers, IBANs and sort codes carry check digits. A random replacement is rejected by the application before the test even starts; use format-preserving strategies that keep the structure valid.
Balances that no longer add up. Perturbing each transaction independently breaks the link between ledger entries and balances. Keep amounts where reconciliation is under test, or perturb consistently at the account level.
Different pseudonyms in different systems. Core banking, cards, payments and CRM must agree on who a customer is. One deterministic key across all extracts keeps them joined.
Dropping the rare cases. Dormant accounts, joint holders, chargebacks and sanctions hits are exactly what tests need, and random sampling rarely includes them. Select them deliberately as edge-case roots.
Leaving card data in logs and extracts. Payment card numbers turn up in free-text fields, file names and application logs. Classify those locations too, and keep extracts on protected storage until masking and certification are complete.
Check which of your sources are supported on the integrations page, plan subset size with the free tools, and see the database-specific guides. To try the workflow on synthetic banking data first, start free; installation is covered in the documentation.
Key takeaways
Masked values must still pass the application's own validation.
Keep customer and account keys consistent across every system.
Preserve reconciliation, not just individual values.