GDPR in the Financial Sector

Few sectors process personal data with higher stakes than finance. A bank, a non-bank lender, an insurer, a leasing company or a fintech know things about their customers that few other organisations ever see: how much they earn, what debts they carry, how and where they spend, what assets they hold, how reliably they meet their obligations. That is precisely why GDPR compliance here is not an administrative exercise but a condition of trust — and an area where mistakes are penalised firmly.

This article covers the GDPR fundamentals applied to the financial sector: what data is processed, on what bases, how long it may be kept, how to inform the customer correctly and how to handle rights, processors and security. The operational resilience and regulated cyber-security side — including DORA — is dealt with in a separate piece on information security and DORA in the financial sector.

What personal data a financial institution processes

Before any legal basis, you need to know what you process. In finance, the categories of personal data are more numerous and more sensitive than in most industries:

• Identification data: name, national ID number, ID document type and number, date and place of birth, citizenship — essential for opening a business relationship and meeting know-your-customer obligations.
• Contact and socio-demographic data: address, phone, email, occupation, marital status, dependants.
• Financial and transaction data: income, accounts, balances, payments, transfers, credit and repayment history.
• Data on the source and destination of funds, collected in the context of preventing money laundering and terrorist financing.
• Data resulting from scoring and profiling, where the institution automatically assesses a customer's creditworthiness or risk.

Some of this processing may be sensitive or high-impact for individuals — for example automated decisions affecting access to credit. In such cases, the GDPR requires additional safeguards, and a data protection impact assessment (DPIA, Art. 35) usually becomes necessary. Carefully mapping the data flows is therefore the first real step towards compliance.

Legal bases: contract, legal obligation, legitimate interest

The financial specificity is that, for the same customer relationship, several Art. 6 GDPR bases coexist, each covering part of the processing:

• Performance of a contract (Art. 6(1)(b)): opening an account, granting and administering a loan, issuing an insurance policy or a leasing contract. Without this data, the service cannot be provided.
• Legal obligation (Art. 6(1)(c)): the key basis in finance. It covers know-your-customer (KYC) and anti-money-laundering (AML) obligations, reporting to authorities, and the retention of accounting and tax records.
• Legitimate interest (Art. 6(1)(f)): may support fraud prevention, systems security or certain internal analyses — but only after a documented assessment of the balance between the institution's interest and the customer's rights (the legitimate interest assessment, LIA).
• Consent (Art. 6(1)(a)): remains necessary where no other basis applies, in particular for marketing communications. Importantly, consent cannot "cover" processing that actually relies on contract or on the law.

The common mistake is using consent as a universal basis. In reality, most of the processing in a financial institution rests on contract and legal obligation; consent is the exception, not the rule. The correct choice of basis for each purpose must be recorded in the Records of Processing Activities (ROPA).

Minimisation, accuracy and data retention

The principles in Art. 5 GDPR apply in full and raise concrete problems in finance. Data minimisation requires you to collect only what is necessary for the purpose: you cannot ask for copies of documents unrelated to assessing the request, just "in case". Accuracy is equally important — an error in a credit history can block a person's access to financing.

The most delicate is storage limitation (Art. 5(1)(e)). The general rule is that data is kept only for as long as necessary. In finance, however, "necessary" is often defined by law itself: AML documentation and transaction records have statutory archiving periods, and accounting documents are kept under tax and accounting law. These obligations do not contradict the GDPR — they are the basis (legal obligation) for retention over that period.

The key is not to confuse an archiving obligation with an unlimited right to keep everything, forever. Once the relationship ends and the statutory periods expire, data must be erased or anonymised. That is why a clear retention policy, broken down by data category, with periods and owners, is not a window-dressing document but the tool that makes the difference during an inspection.

Transparency and customer rights

The volume and sensitivity of the data make transparency a weighty obligation. Under Art. 13–14 GDPR, the customer must be informed clearly, from the outset, about who processes the data, for what purposes, on what basis, with whom it is shared, how long it is kept and what rights they have. In finance, the privacy notice must explicitly cover the sector-specific points too: scoring, KYC/AML reporting, any automated decisions and consultation of credit bureaus.

On the data subject rights side (Art. 15–22), the sector's particularity is that these rights are not absolute. The right of access (Art. 15) and rectification (Art. 16) apply fully. The right to erasure (Art. 17), by contrast, is often limited by statutory retention obligations — an institution cannot delete AML documentation simply because a customer asks. Special attention is owed to Art. 22: if a credit decision is taken solely by automated means and produces significant effects, the customer has the right to human intervention, to express their point of view and to contest the decision.

Processors, outsourcing and transfers

A financial institution rarely processes data entirely "in house". IT and cloud service providers, payment processing platforms, debt collection firms, archiving services or call centres are, as a rule, processors within the meaning of Art. 28 GDPR. For each one, a data processing agreement is required, imposing safeguards, clear instructions and security and confidentiality obligations. The controller's responsibility does not disappear through outsourcing — it remains liable for choosing processors that provide sufficient guarantees.

Where providers are outside the European Economic Area — including cloud services with infrastructure in other countries — the rules on international transfers (Chapter V GDPR) apply: an adequacy decision or, failing that, standard contractual clauses accompanied by a transfer assessment. For a sector where operational continuity is tightly regulated, mapping these subcontracting chains is part of basic compliance hygiene.

Security of processing (Art. 32)

Art. 32 GDPR requires technical and organisational measures appropriate to the risk — and in finance the risk is, by the nature of the data, high. This means encryption of data in transit and at rest, strict access control on a "need-to-know" basis, logging and monitoring of access, pseudonymisation where feasible, backups and tested restoration procedures, and a clear process for handling incidents and notifying within 72 hours (Art. 33–34) where applicable.

Security is not only a technical matter but an organisational one: training staff reduces the risk of human error, which remains one of the most common causes of incidents. It must be said clearly that information security from a GDPR perspective is distinct from the regulated operational cyber-resilience framework in the financial sector — DORA and the related obligations. Those we detail separately in our dedicated article on information security and DORA in the financial sector; here we stay at the level of the security requirement imposed by the GDPR.

In conclusion

GDPR compliance in a financial institution starts from simple questions that are hard to answer correctly: what data do we process, on what basis, how long do we keep it, how do we inform the customer and to whom do we entrust it. The answers rest on contract, on legal obligation — in particular KYC/AML and accounting records — and, on a case-by-case basis, on legitimate interest, all governed by the principles of minimisation, limited retention, transparency and security. Built correctly, these fundamentals not only avoid fines but reinforce exactly the resource a financial institution actually sells: trust. If you want an assessment tailored to your organisation, see our GDPR services and the outsourced DPO option.

Frequently asked questions