Chapter 1. Payment data is personal data.
The GDPR (Regulation (EU) 2016/679, in effect since May 25, 2018) protects any information relating to an identified or identifiable natural person. An IBAN, a card number (PAN), a wallet ID, or a transaction history falls squarely within that definition, because each identifies a person. More importantly, they tell the story of a person's life. Who pays for what, where, when, and how much reveals their movements, their habits, and sometimes their health (pharmacy purchases), beliefs (donations), or family situation.
One common misconception needs clearing up. Financial data is not “sensitive data” under Article 9 of the GDPR, which covers health, political opinions, biometrics, and similar categories. But the European Data Protection Board (EDPB) classifies it as highly personal data, and that label weighs in the risk assessment: stricter security requirements, a data protection impact assessment (DPIA) that is often required, and near-zero tolerance from regulators when things go wrong.
Chapter 2. Legal bases: which one for which processing?
All processing must rest on one of the six legal bases in Article 6 of the GDPR. Four dominate in payments: performance of a contract, legal obligation, legitimate interests, and consent. The classic mistake is to base everything on consent. That is unnecessary, because paying for an order performs the contract and requires no consent, and it is risky, because consent can be withdrawn at any time.
| Processing | Legal basis | Why |
|---|---|---|
| Collect payment for an order | Performance of a contract | No card data processing, no sale: the processing is necessary for the contract |
| Charge recurring subscription payments | Performance of a contract | Storing the card is necessary to perform the contract the customer signed up for |
| Store the card for future purchases (one-click payment) | Consent | A convenience for the customer, not necessary for the contract: a checkbox, never prechecked, that can be withdrawn at any time |
| Keep the transaction as evidence (13 or 15 months) | Legitimate interests / legal obligation | Defend against a dispute over an unauthorized transaction (CMF art. L. 133-24) |
| Fraud prevention (scoring, rules) | Legitimate interests | An interest recognized by the CNIL and GDPR Recital 47, subject to proportionality |
| KYC, screening, TRACFIN reports | Legal obligation | The Monetary and Financial Code requires this processing of obliged entities |
| Marketing based on payment data | Consent | A purpose unrelated to the payment: it requires freely given, specific, and informed consent |
The CNIL's position on storing cards is set out in its recommendation on payment card data (Deliberation No. 2018-303 of September 6, 2018). The merchant or its PSP may store the card number and expiration date for a subscription, on the basis of the contract. Storing them to make future purchases easier for a one-time customer, however, requires that customer's explicit consent, given through an affirmative act: a dedicated checkbox, separate from the terms and conditions.
One last, subtler trap is Article 94(2) of PSD2, which requires the customer's “explicit consent” for their PSP to process their personal data. The EDPB clarified this in its Guidelines 06/2020 on the interplay between PSD2 and the GDPR. This “consent” is contractual: a clause the customer accepts knowingly. It is not consent as a legal basis under the GDPR. The two texts overlap without merging.
Chapter 3. Minimization and retention: 13 or 15 months, the CVV, AML/CFT.
The data minimization principle (Article 5 of the GDPR) means collecting only data that is adequate, relevant, and limited to what the purpose requires. A €30 payment requires no date of birth, ID document, or social security number. Its corollary is storage limitation: every piece of data has a lifespan set in advance, after which it is deleted or anonymized. In payments, CNIL guidance and the law largely set those periods.
| Data / purpose | Term | Legal basis |
|---|---|---|
| Card data used to process the transaction | Until the payment is fully completed (including delivery, if applicable) | Performance of a contract |
| Transaction kept as evidence | 13 months after the debit date, in intermediate (restricted-access) archive storage | Window to dispute an unauthorized transaction, CMF art. L. 133-24 |
| Same, for a deferred debit card | 15 months (13 months + debit delay) | CNIL payment card recommendation |
| Security code (CVV) | Never stored after the first transaction is authorized | Longstanding CNIL position + PCI DSS (sensitive authentication data) |
| Card saved for future purchases (one-click) | Until consent is withdrawn or the card expires | Consent, never including the CVV |
| KYC files and AML/CFT records | 5 years after the business relationship ends | CMF art. L. 561-12 |
| Accounting records (invoices, entries) | 10 years | Commercial Code art. L. 123-22 |
The CNIL distinguishes the active database (data teams can access for day-to-day operations) from intermediate archiving (access restricted to authorized staff for a defined need, such as litigation or an audit). The 13 or 15 months of evidence retention belong in intermediate archiving, where the marketing team has no business. Deletion must be automated and provable. A retention commitment without an automatic deletion mechanism won't hold up in an inspection.
retention_policy:
cvv:
storage: prohibited
comment: "purge from memory immediately after authorization"
transaction_evidence:
zone: intermediate_archive
duration_months: 13
duration_months_deferred_debit: 15
start: debit_date
access: ["compliance", "litigation"]
one_click_card:
legal_basis: consent
duration: "consent withdrawn or card expired"
data: ["tokenized_pan", "expiration_date"]
kyc_file:
duration_years: 5
start: end_of_business_relationship
purge:
job: "daily 03:00 UTC"
evidence: "timestamped purge log, kept 3 years"Chapter 4. PSP: processor or controller?
How GDPR obligations are allocated depends entirely on who determines the purposes and means of the processing. That party is the controller. A party that processes data on behalf of and on the instructions of another is a processor (Article 28). In the payment chain, the answer varies by processing operation, because the same PSP is often both.
| Company | Processing | Typical role |
|---|---|---|
| Merchant | Managing orders and collecting payments from its customers | Controller |
| PSP / gateway | Technical payment processing for the merchant | Merchant's processor (art. 28 agreement) |
| PSP / acquirer | Its own obligations: KYC/KYB, AML/CFT, regulatory reporting | Separate controller |
| PSP | Fraud prevention pooled across all its merchants | Controller (it sets the purposes and means) |
| Issuing bank | Account management, authorizations, cardholder-side 3-D Secure | Controller |
| Wallet (Apple Pay, PayPal…) | Wallet management and user-side tokenization | Controller |
This purpose-based reading comes from the EDPB's Guidelines 07/2020 on the concepts of controller and processor. It explains why large PSPs openly take on both roles in their data processing agreements (DPAs). They are processors for the services they provide to the merchant (payment collection, reporting) and controllers for their own regulatory obligations and pooled fraud prevention systems. When negotiating a contract, watch one point closely: the boundary between the two roles must be spelled out, not just asserted.
The Article 28 processing agreement is not a formality. It sets out the subject matter, duration, nature, and purpose of the processing, the categories of data, the controller's documented instructions, and confidentiality and security. It also governs sub-processors (prior authorization, flow-down obligations), assistance (data subject rights, breaches, DPIAs), what happens to the data when the contract ends, and the right to audit. In practice, a merchant audits its PSP through certifications (PCI DSS, ISO 27001) and the audit reports the PSP makes available.
Chapter 5. Transfers outside the EU and data breaches.
The payment chain is global by design, spanning international card networks, US PSPs, cloud providers, and fraud tools. But Chapter V of the GDPR prohibits transferring personal data outside the European Economic Area without appropriate safeguards. There are three routes: a Commission adequacy decision, standard contractual clauses (SCCs, June 2021 version) supported by a transfer impact assessment, or binding corporate rules (BCRs).
In practice, a European merchant or PSP starts by mapping its data flows: where payment data goes, which group entities are involved, and which sub-processors. It then checks that each US recipient holds an active DPF certification, and covers the rest of the world with SCCs plus an assessment of local law. Because payment data is highly personal, regulators expect especially thorough transfer documentation.
The second topic is data breaches, governed by Articles 33 and 34. Every breach (of confidentiality, integrity, or availability) must be documented in an internal register. It must be reported to the CNIL within 72 hours of discovery if it poses a risk to individuals, and communicated to the individuals affected without undue delay if the risk is high. In payments, a leak of PANs or IBANs almost always crosses those thresholds, because it opens the door to direct fraud.
Chapter 6. How PCI DSS, tokenization, and the GDPR fit together.
That leaves the question of how the GDPR fits with PCI DSS, the card data security standard, which first requires a clarification. PCI DSS is not a law. It is a standard issued by the PCI Security Standards Council (founded by the Visa, Mastercard, Amex, Discover, and JCB networks) and imposed by contract along the acceptance chain. Version 4.0 has been mandatory since March 31, 2024, and its “future-dated” requirements since March 31, 2025 (version 4.0.1).
| RGPD | PCI DSS v4.x | |
|---|---|---|
| Type | EU regulation, with the force of law | Private standard, imposed by contract |
| Data covered | All personal data | Card data (PAN, track data, CVV, PIN) |
| Goal | Protect people's rights and freedoms | Prevent card data compromise |
| Enforced by | The CNIL and European regulators | QSAs (qualified security assessors), acquirers, card networks |
| Penalties | Up to €20M or 4% of global revenue | Contractual penalties, higher fees, exclusion from the networks |
| Where they overlap | Security of processing (Article 32) | The 12 technical and organizational security requirements |
PCI DSS compliance goes a long way toward meeting Article 32 of the GDPR (security of processing) for card data (encryption, segmentation, access control, logging, testing). But PCI compliance ≠ GDPR compliance. PCI DSS does not address legal bases, informing individuals, retention periods other than for the CVV, data subject rights, or transfers. Conversely, the GDPR covers IBANs, 3-D Secure data, and fraud scores, which are outside PCI scope.
Tokenization replaces the PAN with a token that is useless outside its context. It serves both regimes: it drastically shrinks the merchant's PCI DSS scope (the PAN never touches its systems), and it is a textbook case of pseudonymization under the GDPR. But pseudonymization is not anonymization. As long as the detokenization service can identify the cardholder, the token is still personal data, and the GDPR still applies in full.
Finally, there is the data protection impact assessment (DPIA) under Article 35, required when processing is likely to result in a high risk. The list the CNIL adopted in 2018 specifically includes pooled processing of contractual breaches (shared fraudster blacklists) and profiling based on external data sources. A PSP's large-scale fraud scoring almost always checks these boxes. The DPIA documents the risk and the measures taken, and it makes all the difference in an inspection.