Skip to content

Non-functional

Data privacy testing and test data management

Data privacy and test data management verifies how fintech products collect, mask, retain, and delete personal and cardholder data, and supplies synthetic data for testing. Buyers receive a personal and cardholder data flow map, masking and synthetic test data sets, consent, retention, and deletion test results, and data residency checks for US, EU, and Canada.

What data privacy testing covers

Privacy defects in a financial product sit where two duties meet: a customer asks for erasure, and the ledger and anti-money laundering records must stay intact.

Data inventory and leak scans

The personal and cardholder data flow map starts from sign-up forms, KYC vendor responses, open banking connections, and card processor callbacks. It follows each field into databases, the data warehouse, analytics events, the support tool, backups, and test environments. For cardholder data, the map is input to the data-flow diagram in PCI DSS v4.0.1 requirement 1.2.4 and the scope confirmation in requirement 12.5.2. Scans then search logs, error payloads, and event streams for PANs, IBANs, national identifiers, and dates of birth. A typical find is a payment reference field that carries a customer name into the analytics tool.

Data subject request flows

The GDPR testing requirements page sets out the articles. Tests cover the request paths that break in practice:

  • Access export. The export reads every store in the data flow map, including the warehouse and the support tool, and completes by the Article 12(3) due date, with the extension notice path tested separately.
  • Portability format. For data the person provided, where processing rests on consent or contract and runs by automated means, the export is structured, commonly used, and machine-readable, as Article 20(1) states. Tests parse the transaction export and compare its totals with the statement.
  • Recipient notice. Article 19 requires the controller to communicate a rectification or erasure to each recipient of the data, unless this proves impossible or involves disproportionate effort. Tests confirm the change reaches the KYC vendor, the email tool, and the card processor, and that a failed call is retried.
  • Requester identity. An access request from an unverified email address or a session without step-up authentication returns no export.

Retention and deletion against record-keeping duties

A ledger keeps every posting, so an erasure that cascades to transactions breaks balances, statements, and retention duties at once. Tests run on closed synthetic accounts with backdated records:

  • Split by data category. Erasure deletes marketing, device, and analytics data. Identity and transaction records stay under a hold with an end date and a legal basis, and ledger postings keep their amounts and dates.
  • US record retention. 31 CFR 1010.430(d) (checked on 2026-09-16) requires records under that chapter to be retained for five years. Tests confirm the purge job deletes no such record before five years from the start date your retention schedule sets.
  • Canada. PIPEDA Schedule 1 clause 4.5.3 (checked on 2026-09-16) says personal information no longer required for its purposes should be destroyed, erased, or made anonymous. Tests confirm the scheduled job acts on records past their hold end date.
  • Held records stay out of use. Records under a hold are excluded from marketing audiences, model training extracts, and support search.
  • Card data. Requirement 3.2.1 of the PCI DSS testing requirements covers retention and disposal for all locations of stored account data, and requirement 3.3.1 forbids storing sensitive authentication data after authorisation.

Consent records

  • Each consent record holds the purpose, notice version, channel, and timestamp, so the controller can demonstrate consent under Article 7(1).
  • A withdrawal in the app stops events to every downstream tool, and a delayed "granted" event that arrives after the withdrawal does not grant consent again.
  • A new notice version asks again only for the purposes it changed.
  • For open banking access, consent expiry and revocation remove stored tokens and stop scheduled data pulls.

Masking and synthetic data in test environments

PCI DSS requirement 6.5.5 keeps live PANs out of pre-production environments unless those environments are inside the cardholder data environment, and 6.5.6 requires test data and test accounts to be removed before production. Masking tests check:

  • Referential integrity. One customer maps to the same masked value in ledger, card, and KYC tables, so joins and reconciliation queries still work.
  • Valid formats. Masked IBANs keep valid check digits, and substitute card numbers pass the Luhn check inside published test card number ranges.
  • Free text. Payment references, support notes, and uploaded document names are masked or dropped.
  • Separated key. The mapping key sits outside the test environment, which GDPR Article 4(5) sets as a condition of pseudonymisation.

The comparison of synthetic test data and test data masking explains when each fits.

Data residency

Residency checks compare the declared region of each database, replica, backup, log platform, support tool, and processor with its actual configuration and with traffic captured from the test environment. For EU data, a transfer outside the EU is flagged for the conditions of GDPR Chapter V, Article 44. For Canada, PIPEDA clause 4.1.3 keeps an organisation responsible for information transferred to a third party for processing. Partner banks ask for this evidence in vendor due diligence.

Deliverables

  • Personal and cardholder data flow map

    A map of each personal data and cardholder data field from collection to every database, processor, log, backup, and test environment, with its purpose, retention period, and storage region, used by the data protection officer and the PCI DSS assessor.

  • Masking and synthetic test data sets

    Synthetic customers, accounts, cards, and transactions that follow the client's data model, plus masking rules for approved production copies and a scan for real names, IBANs, and card numbers, used by engineering and QA teams.

  • Consent, retention, and deletion test results

    Test results per data category for consent capture and withdrawal, access and erasure requests, retention holds, and scheduled deletion, with the legal retention basis of each record the tests keep, used by the data protection officer and auditors.

  • Data residency checks for US, EU, and Canada

    Checks of the region where each database, backup, log platform, support tool, and third-party processor stores or accesses personal data, compared with the declared regions in the data flow map, used by legal teams and partner bank due diligence reviewers.

How privacy tests fit your release process

  • Schema and event changes. A CI check compares new database columns, API response fields, and analytics event properties with the data flow map. A field with no classification fails the pipeline until someone assigns its category, purpose, and retention period.
  • Every pipeline run. Synthetic data generators build a fresh data set with seeded edge cases: closed accounts with residual balances, customers under a retention hold, withdrawn consents, and cards issued with test card numbers. Leak scanners run on test logs, fixtures, and snapshots, and a PAN or IBAN pattern outside the allowed test ranges fails the build.
  • Pre-release. Access, portability, erasure, and consent suites run in staging against processor sandboxes. The deletion job runs with a shifted clock on backdated records, so a five-year hold is tested without waiting five years.
  • Approved production copies. When a defect needs production volume, masking runs inside your environment before any copy leaves production, and the scan result is attached to the copy request. Our own data handling follows the procedures on our security page.
  • Scheduled checks. Residency checks read your cloud resource inventory and processor list on a cadence you set. The deletion verification query can support the verification every three months that PCI DSS requirement 3.2.1 sets for stored account data past its retention period.
  • Migrations. When customer records move to a new core system, data migration testing checks that consent states, erasure flags, and retention holds move with them.

Generators, masking rules, scanners, and suites live in your repository. Each release stores its consent, retention, and deletion test results with the change record. The data flow map and residency checks are input to your record of processing activities, your data protection impact assessment, and your PCI DSS scope confirmation; they are not those assessments.

Your team owns the retention schedule and its legal basis, lawful basis decisions, processor contracts, production access, and sign-off by the data protection officer.

Sample deliverable

Sample, synthetic data

consent and disclosure test reportConsent and disclosure test report: child accounts, debt validation notices, money transfers, instalment loans, and insurance sales
Consent and disclosure test report: child accounts, debt validation notices, money transfers, instalment loans, and insurance sales
Check IDFlowRequirement referenceWhat the test checkedEvidence fileResult
CD-01Family banking: parent adds a child profile in the mobile appCOPPA Rule, 16 CFR 312.5(a)(1): an operator is required to obtain verifiable parental consent before any collection, use, or disclosure of personal information from childrenThe app sends no child name, date of birth, or photo to the backend before the parent completes a card transaction consent under 16 CFR 312.5(b)(2)(ii)CD-01_coppa-312.5-a-1_request-capture.harPassed: 6 of 6 test cases, and no request before the consent record contains a child field
CD-02Family banking: EU teen account sign-up in the mobile appGDPR, Regulation (EU) 2016/679, Article 8(1): where consent under Article 6(1)(a) applies to information society services offered directly to a child, processing of the personal data of a child below 16, or below a lower Member State age that is not below 13, is lawful only if and to the extent that the holder of parental responsibility gives or authorises consentTest users one year below and at the configured age for each Member State in scope are routed to parental consent below that age and to their own consent at that age, and the age configuration rejects a value below 13CD-02_gdpr-art8-1_age-routing-per-member-state.csvPassed: 15 of 15 test cases, 14 for age routing across 7 Member State configurations and 1 for the minimum age rule
CD-03Debt collection: electronic validation notice generationRegulation F, 12 CFR 1006.34(c)(2)(viii): a debt collector must provide an itemization of the current amount of the debt reflecting interest, fees, payments, and credits since the itemization dateFor a synthetic account, 1,200.00 XTS on the itemization date plus 36.00 XTS interest and 25.00 XTS fees minus 150.00 XTS payments equals the 1,111.00 XTS current amount on the noticeCD-03_regf-1006.34-c-2-viii_itemization-recalc.csvPassed: 5 of 5 test cases, including an account with a payment credited after the itemization date
CD-04Debt collection: validation period end date on the noticeRegulation F, 12 CFR 1006.34(c)(3)(i): the notice must state the date the debt collector will consider the end of the validation period, and 12 CFR 1006.34(b)(5) ends that period 30 days after the consumer receives the notice or is assumed to receive it on a date at least five days after it is provided, excluding legal public holidays, Saturdays, and SundaysA notice provided on 2026-11-23 has an assumed receipt date no earlier than 2026-12-01, because 2026-11-26 is Thanksgiving Day, so the stated end date is no earlier than 2026-12-31CD-04_regf-1006.34-c-3-i_end-date-holiday-calendar.pdfFailed: the notice states 2026-12-30 because the business day calendar omits Thanksgiving Day, defect DEF-214, high severity, release blocker
CD-05International transfer: review screen before payment in the mobile appRegulation E, 12 CFR 1005.31(b)(1)(iv): a remittance transfer provider must disclose the exchange rate used for the transfer, rounded consistently for each currency to no fewer than two and no more than four decimal places, using the term Exchange Rate or a substantially similar termThe Android and iOS review screens show the rate for each of 4 test corridors with the same rounding per currency, between two and four decimal places, under the label Exchange RateCD-05_rege-1005.31-b-1-iv_rate-display-per-corridor.pdfFailed: one corridor shows the rate with six decimal places on Android, defect DEF-221, medium severity, fix before release after DEF-214
CD-06International transfer: order of disclosure and payment stepsRegulation E, 12 CFR 1005.31(e)(1): except as provided in 12 CFR 1005.36(a), the pre-payment disclosure must be provided to the sender when the sender requests the remittance transfer, but prior to payment for the transferThe pre-payment disclosure renders before the payment step on web, Android, and iOS, and a deep link that opens the payment step directly returns the sender to the disclosureCD-06_rege-1005.31-e-1_step-order-per-channel.mp4Passed: 9 of 9 test cases
CD-07Buy now pay later: loan agreement screen for a 12-month plan with a finance chargeRegulation Z, 12 CFR 1026.18(e): the creditor shall disclose the annual percentage rate, using that term, and 12 CFR 1026.22(a)(2) treats the rate as accurate if it is not more than 1/8 of 1 percentage point above or below the rate determined under 12 CFR 1026.22(a)(1)The APR on the agreement for 1,000.00 XTS financed and 12 monthly payments of 90.00 XTS matches an independent actuarial reference model within the 1/8 point toleranceCD-07_regz-1026.18-e_apr-reference-model.xlsxPassed: disclosed APR 14.45%, reference model 14.4521%
CD-08Insurance: renters policy purchase in the mobile app, EU marketInsurance Distribution Directive (EU) 2016/97, Article 20(5): for non-life insurance products listed in Annex I to Directive 2009/138/EC, the information in Article 20(4), due prior to the conclusion of a contract, shall be provided by way of a standardised insurance product information document on paper or on another durable mediumBefore the buy step, the app offers a downloadable PDF with the title required by Article 20(7)(f) and the items listed in Article 20(8)(a) to (i)CD-08_idd-art20-5_blocked-run-log.txtBlocked: the staging document service returns HTTP 503, and the check reruns after the service stub is deployed

Amounts use XTS, the ISO 4217 code reserved for testing; accounts, corridors, dates, defect IDs, and evidence file names belong to a fictional release, and no real child, parent, or consumer appears.

Questions

What is test data management?

Test data management is the practice of creating, masking, provisioning, refreshing, and deleting the data that test environments use. In a fintech product, test data management supplies customers, accounts, cards, and transactions with rare edge cases, keeps real personal data and live card numbers out of non-production systems, and resets data sets so automated tests return repeatable results.

What are the benefits of test data management?

Test data management gives automated tests repeatable data sets that contain rare financial cases, such as a closed account with a residual balance or a refund larger than the captured amount. Synthetic test data keeps personal data out of test environments. Managed card test data keeps live PANs out of pre-production environments, which PCI DSS v4.0.1 requirement 6.5.5 requires unless those environments are inside the cardholder data environment.

What is data masking?

Data masking replaces sensitive values, such as names, IBANs, and card numbers, with realistic substitutes so that a data set can be used outside production. GDPR Recital 26 treats pseudonymised data that additional information can attribute to a person as personal data, so a masked copy with a retained mapping key stays in scope of the GDPR.

Scope your data privacy testing

Send your data stores, processors, retention schedule, and target regions, and we return a test scope per data category with the deletion, consent, and residency checks it needs.

Scope your testing