GDPR testing requirements for fintech products
The GDPR, Regulation (EU) 2016/679, has applied since 25 May 2018 to firms established in the EU and to non-EU firms serving people in the EU. GDPR testing verifies consent withdrawal, access and erasure requests against AML retention, default settings, security controls, and breach detection. FintechAssuranceLabs produces data flow maps, deletion test results, and synthetic test data.
- Jurisdiction
- EU (directly applicable in all Member States); UK under the UK GDPR
- Primary source
- eur-lex.europa.eu
Engineering interpretation of testing requirements, not compliance advice.
What the GDPR requires of a fintech product
Regulation (EU) 2016/679, the General Data Protection Regulation, applies from 25 May 2018 (Article 99(2)). The GDPR text on EUR-Lex (checked on 2026-09-16) applies to processing in the context of an EU establishment and to non-EU firms that offer goods or services to people in the EU (Article 3(1) and 3(2)(a)). Personal data covers any information relating to an identifiable person, including identification numbers and factors of economic identity (Article 4(1)). In the UK, the UK GDPR on legislation.gov.uk (checked on 2026-09-16) is the retained version.
The articles that change test scope in a product that holds customer account data:
- Consent, Article 7. The controller can demonstrate that the person consented (7(1)). Withdrawal is possible at any time and is as easy as giving consent (7(3)). Onboarding and payments usually rest on other lawful bases in Article 6(1), such as contract or legal obligation.
- Data subject rights, Articles 12 to 22. The controller answers a request within one month of receipt, extendable by two further months with notice inside the first month (12(3)). Access includes a copy of the personal data (15(1), 15(3)). Erasure applies on the grounds in 17(1), but 17(3)(b) excludes data that a legal obligation requires the controller to keep. When a solely automated decision, such as a credit decline, rests on contract or explicit consent, Article 22(3) gives the person the right to human intervention and to contest the decision.
- Storage limitation, Article 5(1)(e). Identifying data is kept no longer than its purpose needs, and in financial services AML law sets that purpose for many records. Directive (EU) 2015/849 Article 40(1) (checked on 2026-09-16) requires obliged entities to keep customer due diligence documents and transaction records for five years after the business relationship ends, then delete personal data unless national law allows a further period of at most five years. From 10 July 2027, Regulation (EU) 2024/1624 Article 77(3) (checked on 2026-09-16) sets the same five years, also counted from a refused onboarding, followed by deletion. National accounting and tax laws add their own periods for invoices and ledgers.
- Data protection by design and by default, Article 25. Measures such as pseudonymisation are built into the processing (25(1)). By default, only data necessary for each purpose is processed, which covers the amount collected, the extent of processing, the storage period, and accessibility (25(2)).
- Security of processing, Article 32. Measures include pseudonymisation and encryption (32(1)(a)), the ability to restore access to personal data after an incident (32(1)(c)), and a process for regularly testing the effectiveness of the measures (32(1)(d)).
- Breaches, Articles 33 and 34. The controller notifies the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a breach (33(1)). Every breach is documented with its facts, effects, and remedial action (33(5)). A breach likely to result in a high risk is communicated to the affected people (34(1)), unless measures such as encryption made the data unintelligible (34(3)(a)).
GDPR requirements that testing verifies
| Requirement | What we test | Evidence produced |
|---|---|---|
| Article 7(3): withdrawal of consent is as easy as giving consent | Withdrawal of marketing and data-sharing consent in the app, on the web, and through the API, and the stop of events to the email and analytics tools | Consent state trace from the withdrawal action to each downstream system |
| Article 12(3): a response to a data subject request within one month | Due date calculation, the extension notice, and the overdue alert in the request workflow | Request workflow test log with the due date per request type |
| Articles 15(1) and 15(3): a copy of the personal data | The access request export against every data store that holds customer data, including the data warehouse and the support tool | Export completeness check against the personal data flow map |
| Articles 17(1) and 17(3)(b): erasure with legal retention exceptions | An erasure request on a closed account: marketing and device data deleted, due diligence and transaction records kept under a hold with an end date | Deletion test results per data category with the legal basis for each kept record |
| Article 5(1)(e): deletion when the retention period ends | The scheduled deletion job on records whose five-year AML retention period under Directive (EU) 2015/849 Article 40(1) has ended | Retention job test result with record dates before and after the run |
| Article 22(3): human intervention in a solely automated decision | The review request path after an automated credit or instalment plan decline | Decision path test cases with the human review record |
| Article 25(2): only necessary data by default | Default privacy settings on a new account, and the fields each API response returns to the app | Default settings check and API response field inventory |
| Article 32(1)(a): pseudonymisation and encryption | Application logs, analytics events, and non-production databases scanned for names, IBANs, and national identifiers | Personal data scan results with each unmasked field and its location |
| Article 32(1)(c): restore of access to personal data after an incident | A customer database restored from backup, with erasures made after the backup point applied again | Restore test record with the erasure replay check |
| Article 33(1) and 33(5): breach awareness and documentation | A bulk export by a support account raises an alert and creates an incident record with the detection time | Event-to-alert trace with the detection timestamp per injected event |
Artifacts a supervisory authority or partner bank requests
A data protection authority, the data protection officer, or a partner bank during due diligence typically requests:
- the record of processing activities with the time limits for erasure per data category and the description of security measures (30(1)(f), 30(1)(g));
- the retention schedule that maps each data category to its legal basis, such as due diligence records under Directive (EU) 2015/849 Article 40(1);
- consent records that show which notice version a person accepted or withdrew, and when (7(1));
- the data subject request log with receipt date, response date, and any extension notice (12(3));
- the data protection impact assessment for systematic automated credit scoring that decides applications (35(3)(a), 35(7));
- test results that show the security measures were regularly tested and evaluated (32(1)(d));
- the breach register with the facts, effects, and remedial action for every breach (33(5));
- processor contracts with the Article 28(3) terms, and the transfer terms for access to EU data from outside the EU under Chapter V.
Common GDPR testing findings
- Withdrawal harder than consent. Onboarding grants marketing consent with one tap, but withdrawal needs an email to support, and events keep flowing to the email tool after the request. The defect breaks 7(3).
- Erasure deletes AML records. The erasure job hard-deletes the customer row and cascades to identity documents and transaction records still inside the five-year retention period. Article 17(3)(b) does not require this deletion, and the deletion breaks Directive (EU) 2015/849 Article 40(1).
- Retention hold with no end date. Closed accounts flagged for AML retention are never deleted, because the deletion job reads the account status and ignores the hold end date. The defect breaks 5(1)(e).
- Access export misses data stores. The export reads the core database but skips the data warehouse and the support tool. The defect breaks 15(1) and 15(3).
- Restore brings back erased customers. A database restore returns profiles that were erased after the backup point, and no deletion log is applied again. The defect breaks 17(1).
- "Masked" staging copy that still identifies people. The copy replaces names but keeps IBANs and dates of birth, so records link back to real customers. The copy stays personal data under Recital 26, and staging lacks the controls of 32(1).
- Detection time not recorded. The incident tool stores the ticket creation time, which comes hours after the alert fired. The team cannot show when it became aware of a breach, which breaks the documentation duty in 33(5) for the 72-hour limit in 33(1).
How we cover GDPR testing
The data privacy and test data management service covers Articles 5(1)(e), 7, 15, 17, 25, and 32. It delivers 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". The comparison of synthetic test data and test data masking explains when a masked copy still counts as personal data.
KYC, AML, and fraud testing runs the onboarding and verification scenario suite, including the Article 22 review path after an automated onboarding decline. The AML and KYC testing requirements page lists the retention rules behind erasure holds. Data migration testing checks that consent states, erasure flags, and retention holds survive a core system migration. The DORA testing requirements page covers the backup restoration tests that also serve Article 32(1)(c).
We test GDPR requirements for neobanks, lending and buy now pay later products, remittance, wealthtech, insurtech, payroll, open banking providers, and KYC and AML vendors. In these products, an erasure defect either deletes records that AML law requires or keeps data past its retention end. Our own engineers access personal data only under an Article 28 data processing agreement.
Related
Services
Segments
- Neobanks and digital banking
- Consumer lending and credit marketplaces
- Buy now pay later
- International transfers
- Robo-advisors and wealthtech
- Insurtech
- Payroll and global hiring
- Open banking and data aggregation
- KYC/AML and anti-fraud
- Tax software
- Accounting and invoicing
- Payment acquiring
- Banking-as-a-Service and card issuing
- Subscription billing and revenue management
- Business banking
- Cap table and equity management
- Cashback and rewards
- Chargeback management
- Debt collection and loan management software
- Crypto tax and portfolio trackers
- Expense reporting
- Family and youth banking
- Revenue-based financing and factoring
- Spend management and corporate cards
- Trading terminals and analytics
- Investing and trading apps
Questions
What is GDPR?
What is considered personal data under GDPR?
Can I use production data for testing?
Is anonymised data subject to GDPR?
Scope your testing
Send FintechAssuranceLabs your product, segment, money flows, and the standards that need evidence, and get a proposed test scope with its deliverables.
Scope your testing