GDPR in FinTech: What you need to know when doing business in Poland

Last updated: 08.09.2026

Financial technology firms process some of the most sensitive categories of personal data on the market: transaction histories, creditworthiness assessments, biometric identifiers, fraud prevention signals and entries on blockchain ledgers.

For FinTech entities operating in Poland and the EU, GDPR compliance rests on five key pillars and must be considered alongside sectoral regulations, including MiCA, PSD2/PSD3, MiFID II, EMD2, DORA, NIS2, the AI Act, CCD2 and AML legislation. These issues are particularly relevant for management boards, legal and compliance teams, as well as companies planning to enter the Polish or EU FinTech market.

Key areas include identifying the appropriate legal bases for personal data processing, handling client rights and their limitations, and preparing for personal data breaches and requests from public authorities. In practice, the same processing operation may be subject to both GDPR and sector-specific regulatory requirements, and the approach adopted must be capable of withstanding scrutiny from both financial supervisors and the competent data protection authority.

Legal advice is particularly advisable at the product design stage, before submitting an authorisation application, and whenever automated decision making affects clients.

Key GDPR and data protection requirements for FinTech companies

Why data protection in FinTech requires a sector-specific approach

In most industries on the market, the GDPR can be implemented as a stand-alone compliance project. In FinTech that is impossible.

Almost every data processing activity is simultaneously subject to a sectoral regime:

• strong customer authentication and fraud monitoring – PSD2 and Delegated Regulation 2018/389;
• client onboarding and related data collection– AML/CFT legislation;
• ICT security – DORA and NIS2;
• crypto-asset services – MiCA;
• consumer credit – CCD2;
• investment services and electronic money – MiFID II and EMD2.

Each of these acts either mandates the processing of personal data, or restricts it, or imposes retention periods that must be reconciled with the principles of data minimisation and storage limitation. The decisive compliance questions are therefore questions about the interface of regulations, and the answers must stand up both before the Polish Financial Supervision Authority and before the President of UODO. 

This applies to the full cross-section of market participants: from payment institutions and investment firms, through crypto-asset service providers and currency exchange offices, to non-bank lenders and alternative investment companies (ASI).

Lawful personal data processing in FinTech

Every processing operation in a FinTech product must rest on a correctly selected and documented legal basis under Article 6 GDPR (and, for special categories such as biometrics, under Article 9 GDPR).

Legal bases for processing activities

In practice, almost the entire data lifecycle in the FinTech sector is carried by four bases:

1. Consent and explicit consent: biometric identification and authentication (fingerprint, face recognition), marketing of third-party offers, non-essential cookies and analytics. Consent must be an active, freely given and withdrawable choice; pre-ticked boxes and bundled consents will not survive scrutiny by UODO. Example: a payment app that, at registration, bundles the consent to biometrics with the marketing consent in a single tick-box does not meet the requirement of free choice.
2. Legitimate interests (Article 6(1)(f)): fraud detection and prevention, transaction monitoring, credit scoring, marketing of own services. This basis requires a documented balancing test (LIA) weighing the controller’s interest against the data subject’s rights.
3. Performance of a contract: executing payment transactions, running the account, customer service. The data must be genuinely necessary to provide the service; “useful” is not “necessary”.
4. Legal obligation: AML/CFT customer due diligence, sanctions screening, tax and regulatory reporting. Data collected on this basis must not quietly exceed the scope of the obligation.

Automated decision making and systematic monitoring in anti-fraud systems

Anti-fraud systems call for particular attention. Fraud detection systems profile clients, perform systematic monitoring of transactions in real time, and can automatically block a payment or an account. Such systems may therefore involve automated processing and, in some cases, automated decision making systems capable of producing significant effects for clients.

Recital 47 GDPR and the security obligations under PSD2 support the legitimate interests basis, but only where the controller maintains a documented balancing test, a proportionate data scope and retention, transparency of the analytical model, and a real escalation route from an automatic block to human involvement and review and a complaints procedure.

We analysed these issues in detail in the legal chapter of the Bezpieczeństwo Płatności Cyfrowych (Digital Payments Security) report published by the Future Finance Poland foundation with the support of partners including Mastercard, co-authored by lawyers from our PayTech team.

Data protection impact assessment for high-risk processing operations

Lawfulness is completed by accountability and transparency: an up-to-date record of processing activities (RoPA), balancing tests for every operation based on legitimate interests, data protection impact assessments (DPIAs) for high-risk processing such as automated scoring or biometric onboarding, and privacy notices that genuinely explain how client data are used, including the logic of automated decisions and the automation involved.

Data subject rights and automated decisions in FinTech

FinTech clients most often exercise the right to erasure, the right to object, and the right not to be subject to a solely automated decision (Article 22 GDPR). The provider must be operationally ready to handle data subject requests (from clients and counterparties) within one month, with escalation routes in customer service and compliance.

Just as important is knowing where these aspects are subject to limitations. The right to erasure yields to AML retention obligations (as a rule five years from the end of the relationship, with the possibility of extension); an objection may be overridden by a properly documented interest in fraud prevention; and Article 23 GDPR permits statutory restrictions, for example in the AML context.

These limitations must be communicated transparently, so that a refusal to erase does not come as a surprise to the client. Example: a client requesting account deletion should be told in the very reply that their KYC data will remain in the AML archive for five years, with the legal basis indicated.

Two FinTech-specific data subject rights problems require attention at the product and process design stage, not only after launch.

First, blockchain immutability: for CASPs, a ledger to which records can only be appended is hard to reconcile with the rights to erasure and rectification. The EDPB Guidelines 02/2025 state clearly that, as a rule, personal data should not be written on-chain in a directly identifying form; from the design stage onwards, off-chain storage should be considered, with only irreversible digests of the data (hashes) and cryptographic commitments recorded on the ledger, and a DPIA will usually be necessary. We discussed the Guidelines in our analysis: Blockchain and the GDPR – what do the new EDPB guidelines say?.

Second, AI-based creditworthiness assessment: under the AI Act these are high-risk artificial intelligence systems, and Article 22 GDPR and CCD2 guarantee the borrower human involvement, an explanation and a review of the decision. Where machine learning systems are used for credit scoring, this makes the interaction between automated analysis and human decision making particularly important.

Compliant data sharing in partnerships and integrations

No FinTech operates alone: KYC and sanctions screening vendors, credit reference bureaus (BIK), cloud providers, acquirers, open banking interfaces and card schemes all touch client data.

Every relationship must be correctly classified and documented:

1. Processors (Article 28 GDPR): vendors processing data on the institution’s behalf require due diligence, a processing agreement, documented instructions and audit rights. In regulated FinTech this overlaps with the outsourcing requirements of DORA and the KNF. ICT contracts must satisfy both regimes at once.
2. Separate or joint controllers: partnerships with banks or card schemes, and co-branded products, require arrangements allocating responsibility for information duties, data subject requests and breach response.
3. International transfers (Chapter V GDPR): group structures, cloud regions outside the EEA and public blockchain nodes outside the EEA all constitute transfers. Standard contractual clauses with a transfer impact assessment, adequacy decisions (including the EU–US Data Privacy Framework) or binding corporate rules must be identified at the design stage. For blockchain networks, the EDPB suggests incorporating standard contractual clauses (SCCs) into node participation agreements.

Data protection breaches: Prevention, reporting and response

A personal data breach under the GDPR is a broader concept than a leak, as it covers any accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, data, including a temporary loss of access to the client database.

Prevention rests on the security measures of Article 32 GDPR (encryption, access control, participant authentication, anomaly monitoring), a tested response plan with clearly assigned roles, and regular staff training.

In a FinTech institution, a single incident can trigger several parallel notification regimes: notification to UODO within 72 hours under Article 33 GDPR, communication to clients under Article 34 GDPR, major ICT incident reporting under DORA, NIS2 obligations for in-scope entities, and payment reporting to the KNF.

The deadlines, thresholds and required content differ, so the response procedure should combine all of them in advance in a single internal process agreed beforehand, not during the incident.

Law enforcement data requests: GDPR requirements and disclosure limits

Payment institutions, CASPs and lenders regularly receive requests for client data from the Police, prosecutors, tax authorities and the General Inspector of Financial Information (GIIF) in fraud cases, account blocks and AML proceedings. A correct response requires:

1. Verification: confirming the identity and competence of the authority and the legal basis of the request before any disclosure.
2. Scope control: disclosing only the data covered by the request; the duty to cooperate is not a blank cheque for the entire client file. Example: a request concerning three transfers from a specific month does not justify handing over the full account history since the day it was opened.
3. Documentation: keeping a register of requests and responses for accountability and future inspections.
4. Transparency: informing the data subject of the disclosure unless the law prohibits it (as is usual in AML matters and pending criminal proceedings).

A voluntary report by the institution itself, for example where it detects fraud and decides to notify the prosecutor’s office, is subject to the GDPR, not the Law Enforcement Directive, and requires its own assessment of necessity and proportionality. Our criminal and regulatory teams support clients in cybercrime cases, bank account fraud and account blocks.

Practical example: Automated decision making in anti-fraud monitoring

A foreign payment institution entering the Polish market deployed a transaction monitoring system configured by its group head office. The system automatically blocked accounts flagged as high risk, retained all fraud prevention signals indefinitely, and provided no human review route.

In the Polish regulatory environment this meant three parallel risks: a GDPR challenge to the legal basis and retention of the profiling data, a consumer risk connected with wrongful blocks, and a supervisory risk in the dialogue with the KNF.

As part of our support, the decision process was redesigned so that every automatic block goes to review by a member of staff, a documented balancing test was prepared, differentiated retention periods for the signals were introduced, and the handling of blocks was linked to the complaints process. As a result, the risks were removed without any loss of fraud detection effectiveness.

How we support FinTech companies with GDPR and data privacy compliance

Our FinTech practice combines GDPR advice with financial regulation in coherent projects. We support clients on:

• GDPR audits and gap analyses for FinTech products, including mapping data flows in payment, lending and crypto-asset services (e.g. a review of a payment app ahead of its Polish market launch);
• Full GDPR documentation: the record of processing activities, balancing tests, DPIAs, privacy and cookie policies, retention schedules, intra-group transfer agreements, including the documentation required in licensing proceedings before the KNF (KIP/MIP, EMI, CASP);
• Designing and legally defending anti-fraud and transaction monitoring systems: legal bases, safeguards for automated decisions, retention of high-risk signals, integration with the complaints process (e.g. defending the justification for automatic account blocks);
• Blockchain and MiCA projects: on-chain/off-chain data architecture consistent with the EDPB Guidelines 02/2025, DPIAs for CASP services;
• AI Act and CCD2 compliance for AI-based creditworthiness assessment and scoring models (e.g. reviewing model variables for discrimination risk);
• Vendor and outsourcing compliance: processing agreements, DORA-compliant ICT contracts, transfer mechanisms (SCCs, TIAs, BCRs);
• Incident and breach response: the notification strategy towards UODO, the KNF and clients, and representation in post-breach proceedings (e.g. managing a notification to UODO within the 72-hour deadline);
• Handling requests from law enforcement and supervisory authorities, and responses to enquiries from UODO and the KNF.

Contact us

If you are building or developing a FinTech product in Poland, our team will audit your data flows, prepare the GDPR documentation required in proceedings before the KNF, and defend your processing architecture before the supervisory authorities.

We regularly support companies from the UK, the US and the EU entering the Polish market across the full regulatory spectrum: GDPR, MiCA, PSD2/PSD3, DORA, NIS2, the AI Act, CCD2 and AML.

FAQ: GDPR and data protection in FinTech