Financial data privacy in open banking

Why financial data is particularly sensitive

The transaction history of a bank account is one of the most comprehensive pictures of a person's life. It can reveal income level, place of residence, spending habits, hobbies, health-related purchases, memberships and even religious or political beliefs. Although the General Data Protection Regulation (GDPR) does not classify financial data as such among the special categories of personal data, transaction data can reveal precisely this kind of information.

Open banking increases the mobility of financial data. When a customer grants an account information service access to their account, the data moves from the bank's closed environment to a new party, which may in turn use subcontractors. Every transfer is a potential point of leakage and every new purpose a potential privacy risk.

Legal framework

The processing of financial data is governed by several parallel pieces of legislation:

The GDPR (EU) 2016/679 sets out the general principles of personal data processing, the legal bases and the rights of data subjects.
The Finnish Data Protection Act (tietosuojalaki 1050/2018) supplements the GDPR in Finland and lays down specific national rules.
PSD2 imposes its own data protection obligations on payment services, such as the requirement for the customer's explicit consent to the use of personal data for the provision of a payment service.
The Finnish Anti-Money Laundering Act (rahanpesulaki) and Accounting Act (kirjanpitolaki) require certain data to be retained for a set period, which affects when data can be deleted.
DORA (EU) 2022/2554 imposes ICT risk management obligations on the financial sector, which also supports the protection of data.

The European Data Protection Board (EDPB) has published Guidelines 06/2020 on the relationship between PSD2 and the GDPR, which are a key interpretative aid for operators in the sector.

Two different kinds of consent

One of the most common misconceptions is that PSD2 "explicit consent" and GDPR consent are the same thing. According to the EDPB guidelines, they are different concepts.

Characteristic	PSD2 explicit consent	GDPR consent as a legal basis
Nature	An additional contractual requirement: the customer agrees to the use of their data in the payment service.	One of the six legal bases for processing personal data (Article 6(1)(a)).
Typical legal basis	Processing is often based on the performance of a contract (Article 6(1)(b)).	Consent itself is the legal basis.
Withdrawal	Linked to the service contract and its terms.	Can be withdrawn at any time as easily as it was given.

In practice, an account information service provider must therefore identify the correct GDPR legal basis for each processing operation and, in addition, ensure that the customer has given the explicit consent required by PSD2. If the data is to be used for anything other than providing the service itself, such as marketing, a separate assessment and often separate consent are needed.

Silent party data

Account transactions inevitably contain data about other people as well. When a customer has paid rent, transferred money to a friend or received a salary, the names and account numbers of these parties appear in the transactions. The EDPB calls them silent parties: they are not customers of the service and have not given their consent.

According to the EDPB guidelines, silent party data may be processed where this is necessary to provide the service to the customer and the processing is based on legitimate interest. However, the data may not be used for other purposes, and its processing must be kept to a minimum by technical means.

Data minimisation in practice

The data minimisation principle in Article 5 of the GDPR requires that only data necessary for the purpose is processed. In open banking services, this may mean, for example, the following:

In payment initiation, the service provider needs to know whether the payment succeeded, not the payer's entire transaction history.
When verifying account ownership, the account holder's name and IBAN are often sufficient.
When verifying identity in connection with bank authentication, only the identity data genuinely required by the purpose should be requested.
In analytics, data should be pseudonymised or aggregated at the earliest possible stage.

Minimisation is particularly important in solutions where authentication and payment are combined in the same user journey. When both identity data and account data are obtained in a single transaction, care must be taken that neither is used or retained more broadly than the purpose requires.

Retention periods and their conflicts

Data protection requires data to be deleted when it is no longer needed. In the financial sector, however, several laws require data to be retained. In Finland, for example, the Accounting Act requires vouchers to be retained for at least six years from the end of the year in which the financial period ended, and the Anti-Money Laundering Act requires customer due diligence data to be retained for five years after the end of the customer relationship.

The conflict is resolved by delimiting the data to be retained: data subject to statutory retention is kept separately, access to it is restricted and it is used only for the purpose for which retention is prescribed. Other data is deleted once its purpose has been fulfilled. Retention periods should be documented in the privacy notice and in the record of processing activities.

Technical safeguards

Article 32 of the GDPR requires technical and organisational measures appropriate to the risk. For financial data, established measures include:

Encryption in transit and at rest. TLS 1.2 or later in transit, strong encryption in storage and key management kept separate from the data.
Tokenisation and pseudonymisation. Account numbers and personal identity codes are replaced with identifiers that have no meaning outside the system.
Access control. The principle of least privilege, multi-factor authentication for administrators and comprehensive access logging.
Log protection. Account data or identifiers are not stored in logs in plain text.
Test environments. Production data is not used for testing without anonymisation.
Impact assessment. A data protection impact assessment under Article 35 of the GDPR is carried out for large-scale processing of financial data.

DORA and third-party risk

The Digital Operational Resilience Act (DORA) has applied since 17 January 2025. It requires financial entities to have comprehensive ICT risk management, to report major incidents, to test their digital operational resilience and to manage the risks of ICT service providers. Although DORA is not a data protection instrument, its requirements directly support the protection of financial data.

In open banking, the chain is often long: the bank, the aggregator, the payment service, the merchant and their cloud service providers. At each link, it must be assessed who is the controller and who is the processor, and contracts under Article 28 of the GDPR must be concluded. If data is transferred outside the EEA, the transfer requires a legal basis, such as the European Commission's standard contractual clauses.

Upcoming regulation

In June 2023, the Commission also presented a proposal for a framework for financial data access (FIDA), which would extend data sharing beyond payment accounts. The final content and timetable of the proposal should be checked from up-to-date sources.

Checklist

The following list helps you assess whether the processing of financial data is in order. It does not replace a legal assessment.

A GDPR legal basis has been identified for each processing operation.
The explicit consent required by PSD2 is collected and documented separately.
Silent party data is not used for other purposes.
Only data strictly necessary for the purpose is processed.
Retention periods are defined and statutory retention is kept separate.
Data is encrypted in transit and at rest, and keys are managed separately.
Processor agreements and the legal bases for international transfers are in place.
An impact assessment has been carried out and is updated when changes occur.
There is a working process for fulfilling data subjects' rights.

Sources and further reading

Disclaimer

This guide has been prepared carefully from public sources, but regulation and service features change. Always check current information from official sources and the providers' own documentation. Corrections: support@brevixoo.com.