Fintech sits on the most consequential personal data most people generate — what they earn, owe, spend, and where — while operating under two regimes at once: the privacy regulation and the financial rules governing payments, lending, and money laundering. The tension between them is constant. One says delete what you no longer need; another says keep transaction records for years. One says minimise; another demands you profile customers for fraud and credit. Fintechs that treat privacy as a checkbox bolted onto the banking stack find the gaps the expensive way — usually around legal basis, the thing financial firms get wrong most often.
The Special-Category Trap
A surprising number of fintech privacy programmes start from a wrong assumption: that financial data is a “special category” under Article 9. It isn’t. The special categories are things like health, race, religion, and political opinion — financial data is not on the list. That mistake cuts both ways. Some firms over-engineer, wrapping ordinary transaction data in protections meant for medical records; others under-protect, treating it as casually as a mailing list. The accurate position sits in between: financial data isn’t special-category, but it is high-risk processing that attracts mandatory impact assessments, strong security, and close regulator attention — and fintech often touches genuine special-category data by accident, in transaction descriptions that quietly reveal a person’s health, faith, or politics.
Legal Basis Is Where Fintechs Fail
The discipline that separates a defensible fintech from a fragile one is mapping every processing purpose to the lawful basis that actually fits it — and most failures are failures of this single thing. Running the account is contract. Anti-money-laundering and tax records are legal obligation. Fraud detection and risk scoring are legitimate interest, but only with a documented balancing test. Marketing is consent. The trap is muddling them: leaning on consent for processing the customer can’t actually opt out of, or invoking legitimate interest as a catch-all with no analysis behind it. When the basis is wrong, every downstream decision built on it is unlawful too.
| Processing purpose | Lawful basis that fits | The common mistake |
|---|---|---|
| Running the account or payment | Performance of a contract | Asking for consent you can’t honour |
| AML, KYC, tax records | Legal obligation | Treating it as consent the user could withdraw |
| Fraud and risk scoring | Legitimate interest, with balancing | Claiming it with no documented balancing test |
| Marketing and cross-sell | Consent | Bundling it into account opening |
Retention: Two Laws Pulling Opposite Ways
Fintech is where the privacy principle of “delete when no longer needed” collides head-on with financial rules that demand records be kept for years. The resolution isn’t to pick a side — it’s to encode both into the retention schedule. The legal-obligation basis justifies holding transaction and KYC data for the mandated period; once that period expires and no other purpose applies, the same discipline requires deletion. Keeping everything forever “to be safe” fails the privacy regulation; deleting on request what anti-money-laundering law requires you to keep fails the financial regulator. The only safe place to stand is a schedule that knows the difference, per data category.
Profiling and Automated Decisions Have Their Own Rules
Much of what makes fintech work — instant credit decisions, automated risk scoring, eligibility checks — is automated decision-making, and the regulation gives individuals specific rights around it: to be told it’s happening, to obtain a human review, and to contest the outcome. A lending product that auto-declines an applicant with no explanation and no route to a human is not just poor service; it’s a breach of those rights. Building the human-review path and the explanation into the decision flow is part of the product, not a customer-service afterthought.
In 2021 Spain’s data protection authority fined CaixaBank €6 million — the country’s largest GDPR penalty at the time — and the case is instructive precisely because it wasn’t a breach or a leak. The regulator found the bank could not properly justify the legal basis for its processing, leaned on legitimate interest without the analysis to support it, ran consent processes that didn’t meet the standard, and gave customers information about their data that was inconsistent and incomplete across documents. It had also shared data within its corporate group without a lawful footing. For a sector built on trust and already heavily regulated, the message was pointed: handling money lawfully is not the same as handling data lawfully, and the privacy regulator will test the second even when the first looks sound. Legal basis isn’t paperwork — it’s the foundation every downstream processing decision stands on, and it’s the first thing to collapse under scrutiny.
Strong Customer Authentication Is Not Data Protection
Fintechs steeped in payment-security rules often conflate them with privacy, and the two are not interchangeable. Strong customer authentication secures a transaction against fraud; it does nothing for lawful basis, retention, transparency, or a customer’s rights over their data. A firm can have impeccable payment security and still be wide open on privacy — wrong basis, unclear notices, no retention discipline. Both obligations have to be met, and satisfying one says nothing about the other.
Looks Bank-Grade vs. Is Privacy-Compliant
Pattern-matching from real fintech reviews — the gap between looking rigorous and being compliant tends to follow the same shape:
| Looks compliant | Is actually compliant |
|---|---|
| ✗ “It’s financial data, so we treat it as sensitive” | ✓ Risk-assessed processing, with a DPIA where required |
| ✗ Consent collected for everything | ✓ The right basis per purpose, documented |
| ✗ Legitimate interest as a catch-all | ✓ A balancing test on file for each use |
| ✗ Keep all records forever to be safe | ✓ Retention matched to AML and tax duty, then deletion |
| ✗ Auto-decline with no recourse | ✓ Human review and explanation for automated decisions |
| ✗ Authentication treated as data-protection coverage | ✓ Security and privacy handled as separate obligations |
| ✗ Group data shared on assumption | ✓ A lawful basis for every internal and external share |
Build the Basis Register Before the Product Scales
The spine of a defensible fintech privacy programme is a processing register that maps, for every activity, what data is involved, why, on what basis, and for how long. Built early, it makes each new feature a quick addition to a clear map. Built late — or not at all — every new product line becomes a fresh, unexamined liability, and the firm discovers its legal-basis problems the way CaixaBank did: from the regulator, after the fact.
Final Thought
Fintech earns trust by handling money carefully, and assumes that care transfers to data. It doesn’t. The privacy regulation tests a different competence — whether each use of customer data has a basis that holds, information that’s honest, retention that respects two conflicting laws at once, and automated decisions a human can review. That competence is built deliberately, not inherited from a banking licence.
The test: pick any way the firm uses customer data and answer three things without a meeting — what is the lawful basis, where is it documented, and would it survive a regulator asking. If the honest answer for most processing is “consent, probably,” the foundation is already cracked.
Frequently Asked Questions
No. Article 9 special categories cover things like health, race, religion, and political opinion — financial data is not on the list. It is still high-risk processing that attracts mandatory impact assessments, strong security, and close regulator attention, but it doesn’t carry the explicit-consent default that Article 9 demands.
Legal obligation. AML, KYC, and tax records are mandated by other laws, so the basis is legal obligation, not consent. Treating it as consent the customer could withdraw is one of the most common errors — it would put the firm in breach of financial law the moment someone exercised that option.
As long as the financial regulation requires you to — typically several years for AML and tax records — and not a day longer once that basis expires. The retention schedule has to encode both sides: the legal-obligation period that justifies holding the data, and the deletion that follows once no other purpose applies.
Yes. Automated decisions that have legal or similarly significant effects on a person — credit decline, account closure, eligibility — carry specific rights: to be told it’s happening, to obtain a human review, and to contest the outcome. The path to a human has to be built into the product, not added later as customer service.