The open banking revolution induced by PSD2 has transformed payment services into a widespread information infrastructure, where the financial transaction is both a transactional process and a flow of personal data.

Regulated access to payment accounts via standardized interfaces, the proliferation of third-party providers, and the raising of security standards (SCA and secure communications) have multiplied the touchpoints between banking regulation and data protection, making it clear that digital payments are, even before being a transfer of funds, a data processing activity. In this context, the balance between the needs for innovation, system security, and the protection of individuals’ rights cannot be sought through sectoral interpretations, but requires systematic coordination between GDPR and PSD2, as outlined by the EDPB Guidelines 06/2020, and an architectural translation of the principles of minimization, transparency, accountability, and security.

This contribution provides an integrated reading of the regulatory framework, focusing on five aspects: the necessary coordination between PSD2 and GDPR; the conceptual distinction between “explicit consent” and special categories of data; the processing of data of so-called “silent data subjects”; the practical application of data protection principles in the processes and architectures of providers; and the use of data for anti-fraud purposes, including behavioral analysis and transaction monitoring.

The necessary coordination between GDPR and PSD2: EDPB guidelines

The starting point is regulatory: Article 94 of PSD2 requires that any processing of personal data for the purposes of the directive be in accordance with the GDPR and the relevant security regulations, reiterating what was already outlined in recitals 89 and 93. It follows that PSD2 does not introduce an autonomous regime for the lawfulness of processing, nor does it represent a lex specialis that can derogate from the GDPR; rather, it defines the subjective and objective scope of regulated access to accounts and, at the same time, refers to the GDPR for determining the legal basis and ensuring compliance with the principles set out in Article 5.

The EDPB, in its Guidelines 06/2020, clarifies that, for the provision of the service in the strict sense (account access, initiation of the transaction, and technical management of the payment instruction), the typical legal basis is Article 6(1)(b) GDPR (contractual necessity). This legal basis applies both to “traditional” providers (ASPSPs) and to the operators introduced by PSD2 (AISPs and PISPs), provided that the processing is limited to what is strictly necessary to deliver the service expressly requested by the user.

The directive also introduces specific contextual safeguards: Articles 66 and 67 strictly limit the collection and reuse of data by PISPs and AISPs, prohibiting any use for purposes other than the provision of the service. Fraud prevention, referred to in Article 94, does not in itself constitute an autonomous legal basis under the GDPR, but may instead be grounded, on a case-by-case basis, on a legal obligation (e.g. AML or supervisory regulations) or on a legitimate interest that is duly balanced and documented.

From this perspective, PSD2 “enables” access to data within the limits of the regulated service, while the GDPR “enables” the processing by defining its conditions, limits, safeguards, and responsibilities. The case law of the Court of Justice, emphasizing transparency and traceability (as in the Pankki S¹ judgment concerning the right of access to consultation logs), confirms that banking data and related access metadata are fully personal data and that the guarantees under Articles 12–15 GDPR are not diminished in the payments sector.

Operationally, this entails the need for a governance framework that integrates PSD2 regulatory requirements with GDPR principles and obligations, avoiding both purely formalistic compliance and overly technicist, responsibility-shifting approaches.

The different notions of «explicit consent» and «sensitive data»

The common lexicon tends to conflate concepts that, in positive law, have distinct functions.

First of all, the «explicit consent» required by Article 94, paragraph 2, PSD2 does not align with consent as a legal basis under the GDPR. The EDPB clarifies that PSD2 consent has a contractual-regulatory nature: it is the declaration through which the user authorizes access to their account data and its processing/storage as necessary for the provision of the requested payment service; this consent does not replace or complement the legal bases provided by Article 6 of the GDPR.

As a rule, for the execution of the service, the legal basis remains Article 6, paragraph 1, letter b); GDPR consent (Article 6, paragraph 1, letter a)) may only apply for additional purposes, not necessary for the service provision (e.g., optional features, marketing, non-strictly technical profiling), and must meet the stringent conditions of validity and demonstrability set out in Articles 4, 7, and Recitals 32 and 42. Substantively, PSD2 consent defines «who can access what, for which service, and for how long,» whereas GDPR consent, when used, legitimizes specific purposes of processing, revocable without prejudice and in the absence of asymmetries that would undermine the freedom of consent.

Equally important is the distinction between «sensitive data related to payments» in the functional sense of PSD2 and «special categories of data» under Article 9 GDPR. PSD2 qualifies as «sensitive» information that can facilitate fraud, including personalized security credentials, and regulates their protection, even regarding the ability of AISPs and PISPs to request or retain them. The GDPR, on the other hand, qualifies as «special» the exhaustive categories listed in Article 9 (e.g., health data, religious or trade union beliefs, sexual orientation, biometric data, etc.), generally prohibiting their processing unless specific exceptions apply.

Payment data, as such, does not fall under Article 9 by default; however, individual transactions may indirectly reveal information belonging to such categories (e.g., payments to clinics, political donations, contributions to religious organizations), triggering the safeguards of Article 9 and the need for explicit consent under Article 9, paragraph 2, letter a), or another applicable derogatory basis.

This leads to the practical obligation for providers to design information flows and data schemas to minimize exposure to such inferential information, limiting – where possible – the collection and retention of sensitive descriptive fields, and adopting technical solutions (filters, masking, selective exclusions) that prevent the circulation of special categories, particularly with respect to third-party data.

The processing of data of the ‘silent data subject’

In the payments ecosystem, the data subject does not always coincide with the provider’s contractual customer: beneficiaries of transfers, transaction counterparties, and individuals mentioned in payment descriptions constitute “silent data subjects” (silent parties), whose data are processed without any direct relationship with the operator executing or enabling the transaction.

The EDPB Guidelines recognize the lawfulness of such processing within clearly defined boundaries. First, the appropriate legal basis is generally the legitimate interest of the controller or of third parties (Article 6(1)(f) GDPR), consisting in performing the payment services contract entered into with the user and ensuring the regular and secure functioning of the system. This legal basis does not apply automatically: it requires a documented balancing test assessing the strict necessity of the processing, its foreseeability for the third party, and the adoption of appropriate measures to safeguard the data subject’s rights and freedoms, including a prohibition on reuse for further purposes.

Second, the principle of transparency is implemented through the information notice under Article 14 GDPR: it is neither realistic nor proportionate to require individual communication to every potential counterparty; instead, providers are required to make available a dedicated notice for silent data subjects, published in an easily accessible manner and drafted by reference to categories of data, purposes strictly connected with the transaction (execution, legal obligations, fraud prevention), legal bases, retention periods, and channels for exercising data subject rights.

Third, any further processing of the data of silent data subjects is permitted only within the limits arising from specific legal obligations (for example, AML/CFT measures) or from valid consent where applicable, without prejudice to the prohibition of uses incompatible with the original purpose.

This approach strikes a balance between enabling intermediaries to execute transactions without prohibitive burdens and protecting third parties, whose processing perimeter is limited to what is reasonably foreseeable in light of the nature of the transaction and the rules of the system.

From theory to practice: minimization, transparency, accountability, and security

Compliance in the payment domain is never merely documental: it is primarily the design of processes and systems.

The principle of minimization requires determining in advance which categories of data are truly necessary for each service and for each flow: identifiers, IBAN, balance, transaction history, access and device metadata, reasons. For account information services, access must remain confined to the designated accounts and the strictly necessary period; for order initiation services, the collection must not exceed the data indispensable for the specific execution. This determination must be reflected in the API specifications, authorization profiles, logging and retention policies, in accordance with the privacy by design and by default logic under Article 25.

The principle of transparency requires multilayered, clear, and specific information that distinguishes the roles and responsibilities of the different parties (ASPSP, AISP, PISP), clarifies the legal grounds for “core” and “additional” purposes, exposes the effects of anti-fraud measures and automated controls, and specifies the essential logic of decisions that produce legal or similarly significant effects. In the Pankki S case, the Court of Justice reiterated the right of the data subject to know the circumstances of the consultation of their data (dates, reasons, categories of recipients), while excluding the need to reveal the identity of employees who accessed the data, confirming the necessity of granular and verifiable audit trail systems.

Accountability integrates and strengthens the other principles, requiring accurate mappings of processing activities, separation of purposes (execution, fraud security, legal compliance, optional purposes), necessity and proportionality analyses, impact assessments when large-scale processing or systematic monitoring occurs, as well as governance of joint control relationships or litigation allocation of roles between providers.

Finally, security is the area of closest integration between PSD2 and GDPR: Article 32 of the GDPR mandates measures appropriate to the risk; the RTS on strong customer authentication and secure communications requires multi-factor authentication mechanisms, segregation of environments, strict management of credentials, and, above all, transaction monitoring systems capable of detecting anomalous patterns.

The consistency between security and data protection is measured by the ability to tailor monitoring tools to the risk, limiting their scope to only the necessary data and metrics, with reduced retention periods, logical and organizational separation of anti-fraud datasets from other purposes, and strictly need-to-know access controls.

Use of data to detect fraud: behavioral analysis and transaction monitoring

Fraud prevention is a systemic interest and a structural requirement of payment services; without effective anti-fraud measures, the system would not be able to function.

However, this does not justify unlimited or generalized approaches. PSD2 acknowledges the legitimacy of processing for anti-fraud purposes, but its implementation must be grounded, in the sense of the GDPR, in specific legal obligations or a legitimate interest of the provider that is proportionate and properly balanced.

The evolution of tools has led beyond static rules to models based on behavioral analysis and machine learning: continuous monitoring of transactional patterns, spatiotemporal correlation of access, detection of anomalous sequences (micro-transaction tests, escalation of amounts, geographical triangulation). Such processing often involves profiling activities under Article 4, point 4, and may result in automated decisions that produce legal or similarly significant effects (payment blocking, request for authentication step-up, temporary suspension).

Recent case law (Schufa and Dun & Bradstreet cases²) has broadened the system’s sensitivity to the impacts of automated decisions, requiring strengthened safeguards: meaningful explanations of the underlying logic, the ability to obtain human intervention, to express one’s opinion, and to contest the decision, traceability of revisions, calibration and auditing of models, periodic checks for bias and error rates.

The purpose limitation principle prevents data and signals collected for anti-fraud purposes from being reused for different purposes without an assessment of compatibility under Article 6(4), or without an independent legal basis. Accountability also imposes quality metrics for models, differentiated and time-limited retention of raw data and derived features, as well as a segregation architecture to prevent commingling of anti-fraud environments with business domains.

From this perspective, it is crucial to recognize that proportionality and minimization are not antithetical to fraud prevention effectiveness but are a condition for it: more accurate and narrowly focused tools, with relevant and minimized datasets, generate fewer false positives, reduce informational overload, and improve the overall protection of the system and the individuals involved.

Conclusions

The coordination between PSD2 and GDPR, as outlined by the EDPB, is not an exegetical exercise, but rather an organizational and technical project. PSD2 defines access rights and the regulatory boundaries of services; GDPR sets the conditions for legality, principles, and guarantees of data processing. In between, we find the application architectures, APIs, anti-fraud models, access logs, information flows, rights management processes, retention and security policies.

It is on this level that the effectiveness of protection is at stake: in the ability of providers to translate the contractual necessity into minimal informational perimeters; to clearly distinguish PSD2 contractual consent from GDPR consent; to process the data of tacitly involved individuals within predictable and protected boundaries; to build security systems that do not become excuses for excessive processing; to train and verify transparent, contestable, and proportionate anti-fraud models.

The upcoming European reforms of the payments framework (PSD3 and the Payment Services Regulation) appear to continue along this line: strengthening guarantees for users, greater control over access, and stricter oversight on security and fraud prevention. In this scenario, data protection is not an external constraint to the payment market, but a condition for its sustainability: GDPR does not limit open banking; it makes it possible, reliable, and trustworthy.

1. CGUE, judgment Pankki S (C‑579/21). ↩︎
2. GUE, judgments Schufa (C‑634/21), Dun & Bradstreet (C‑203/22). ↩︎