I. Introduction
Open banking, instant payments and digital wallets – the modernisation of payment services is bringing not only new business models, but also new data protection challenges. New actors such as Payment Initiation Service Providers (PISPs) and Account Information Service Providers (AISPs) raise the question of who is responsible for which data from a data protection perspective.
Table of Contents
For payment service providers, this creates a complex area of tension: on the one hand, smooth payment processing requires the processing of sensitive customer data in real time and across corporate boundaries. On the other hand, this very processing is subject to a dense regulatory framework consisting of the General Data Protection Regulation (GDPR), the Payment Services Directive 2 (PSD2) and the German Payment Services Supervision Act (ZAG) – legal sources that do not always interact without contradiction. In addition, there are regulatory obligations under the German Anti-Money Laundering Act (GwG), which independently require data processing activities.
This article examines the key data protection principles in payment services: from the concept of payment data and the relationship between the relevant legal sources through to the allocation of roles among the parties involved.
II. Particularities of Payment Data
IBAN, account holder, transaction amount, booking date, payment reference and payee – all of these constitute personal data within the meaning of Article 4(1) GDPR. In the context of online banking, personalised security credentials such as PINs and TANs, as well as device data used for strong customer authentication, are added. Almost everything generated during a payment transaction is relevant from a data protection perspective.
However, the catalogue of special categories of personal data under Article 9(1) GDPR does not include payment data. Nevertheless, this should not lead to the conclusion that such data is not sensitive. The actual risk does not lie in the individual data point, but rather in the combination of data: anyone regularly analysing transaction data can draw precise conclusions about lifestyle habits, consumer behaviour and financial circumstances – precisely the personal aspects covered by profiling pursuant to Article 4(4) GDPR. Transfers to medical practices, religious institutions or political parties may also indirectly reveal categories referred to in Article 9(1) GDPR without formally falling within that catalogue.
Special categories of personal data must be distinguished from sensitive payment data under Article 4(32) PSD2 and Section 1(26) ZAG. These include data – including personalised security credentials – that may be used for fraudulent activities. Both categories pursue different protective purposes: while Article 9 GDPR aims to protect against infringements of personality rights, Section 1(26) ZAG is intended to prevent abuse in payment services. Conceptually, they must therefore be treated separately, even though overlaps may arise in individual cases – for example, when biometric authentication features are used.
Payment data therefore occupies an intermediate category under data protection law: it falls under the general regime of Articles 5 and 6 GDPR and does not constitute special categories of data within the meaning of Article 9(1) GDPR. Nevertheless, Article 9 GDPR may apply indirectly where transaction data allows conclusions to be drawn regarding the categories listed therein. In addition, payment data benefits from sector-specific protection – in particular through the consent requirement under Article 94(2) PSD2.
III. Legal Bases for Data Processing
There is no standalone financial data protection regime. Instead, the data protection framework for payment service providers results from the interaction of three regulatory levels: the GDPR, PSD2 as a sector-specific EU directive, and the ZAG as its national implementing legislation.
1. Interaction between ZAG, PSD2 and GDPR
As a directly applicable EU regulation, the GDPR is binding in all Member States and forms the data protection framework for any processing of personal data. It provides the legal bases under Article 6(1) GDPR, the general processing principles under Article 5 GDPR and the rights of data subjects. PSD2, by contrast, is an EU directive that does not apply directly, but requires implementation into national law – in Germany through the ZAG. It specifies the GDPR framework for the payment services sector: Recital 89 PSD2 requires the specification of concrete processing purposes as well as compliance with the principles of necessity, purpose limitation and data minimisation. Article 66(3)(g) PSD2 establishes a strict purpose limitation requirement for payment initiation services. The central data protection provision of PSD2 is Article 94, implemented into German law through Section 59 ZAG, which contains both a legal basis for fraud prevention and an explicit consent requirement of the payment service user for the processing of personal data necessary for the provision of payment services.
2. Legal Bases under Article 6(1) GDPR
a. Performance of a Contract (Article 6(1)(b) GDPR)
The most obvious legal basis is Article 6(1)(b) GDPR: processing is permitted insofar as it is objectively necessary for the performance of the payment services contract – for example, the processing of IBAN, amount and payment reference. The CJEU interprets the concept of necessity narrowly: processing must be “objectively indispensable” in order to achieve a purpose that is an essential component of the contractual service, such that the main subject matter of the contract cannot be fulfilled without that processing. Consequently, expenditure analyses cannot generally rely on Article 6(1)(b) GDPR where they are not objectively necessary for the contractually owed core service (e.g. execution of the payment transfer), but merely constitute non-optional convenience or added-value functions. The position differs where expenditure analysis itself is contractually agreed as an independent core service (for example as a separately bookable service module offered by a payment service provider or an account information or payment initiation service). In such cases, the required processing may be based on Article 6(1)(b) GDPR. Under Article 5(2) GDPR, the controller bears the burden of demonstrating and proving necessity for contractual performance.
b. Legal Obligation (Article 6(1)(c) GDPR)
Another legal basis arises from Article 6(1)(c) GDPR, which permits the processing of personal data insofar as it is necessary to comply with a legal obligation of the controller. Payment service providers are subject to numerous statutory obligations requiring independent data processing activities: identification obligations and transaction monitoring under the GwG, tax retention obligations and regulatory reporting duties under the ZAG. This refers to obligations arising from objective law requiring data processing – not contractually agreed obligations.
c. Legitimate Interests (Article 6(1)(f) GDPR)
According to established CJEU case law, Article 6(1)(f) GDPR requires three cumulative conditions: a legitimate interest, the necessity of the processing and the absence of overriding interests of the data subject. In payment services, this legal basis is particularly relevant for fraud prevention measures – Recital 47 GDPR expressly recognises fraud prevention as a legitimate interest. For analytics and additional services, the decisive factors are the specific processing purpose and the balancing of interests in the individual case; it is also relevant whether the data subject could reasonably expect the processing. The principle of data minimisation under Article 5(1)(c) GDPR must always be taken into account.
3. Specific Provisions under the ZAG and PSD2
The central data protection provision in payment services law is contained in Article 94 PSD2, implemented into German law through Section 59 ZAG. Section 59(1) ZAG permits payment systems and payment service providers to process personal data insofar as this is necessary for the prevention, investigation and detection of fraud in payment services. The provision constitutes a sector-specific legal basis; however, its classification within the GDPR framework – whether as a specification of Article 6(1)(e) or (c) GDPR, or as an expression of the legitimate interest under Article 6(1)(f) GDPR – has not yet been conclusively clarified by the highest courts. It is therefore advisable to maintain documentation that satisfies both requirements.
For processing activities beyond this scope, Section 59(2) ZAG establishes an explicit consent requirement: payment service providers may access, process and store the personal data necessary for the provision of their services only with the user’s explicit consent. Taken literally, this provision would largely deprive the consent-free legal bases of the GDPR of practical effect within the payments sector. However, in its guidelines, the EDPB clarified that Article 94(2) PSD2 is not to be understood as an additional legal basis alongside the exhaustive catalogue in Article 6(1) GDPR, but rather as an additional transparency requirement to be contractually implemented. Accordingly, the legal basis for data processing remains Article 6(1)(b) GDPR.
4. Outlook: PSD3 and the Payment Services Regulation (PSR)
The ongoing legislative work on PSD3 and the PSR introduces a significant substantive change from a data protection perspective. It concerns the processing of special categories of personal data within the meaning of Article 9(1) GDPR in the context of payment services.
Article 9(1) GDPR establishes the principle that the processing of special categories of data is prohibited, subject to the exceptions provided for in Article 9(2) GDPR. For the first time, the draft PSR creates a sector-specific permission within the meaning of Article 9(2)(g) GDPR for the processing of special categories of data in payment services (Article 80 draft PSR), thereby addressing one of the most significant practical gaps in the current legal framework. Until now, payment service providers have had to rely on the hardly manageable consent mechanism under Article 9(2)(a) GDPR for the structurally unavoidable incidental processing of such data. This does not, however, alter the requirement to additionally establish a legal basis under Article 6 GDPR.
As a regulation, the PSR would constitute directly applicable EU law and could – unlike PSD3, which would leave room for national implementation – establish a harmonised framework across Europe. Whether and in what form these provisions will ultimately be included in the final text remains subject to the outcome of the ongoing legislative process.
IV. Data Protection Roles and Responsibilities
1. Fundamental Roles under the GDPR
Under Article 4(7) GDPR, a controller is the entity which alone or jointly with others determines the purposes and means of the processing. What matters is the actual decision-making power – not the formal contractual designation. This must be distinguished from the processor, which does not pursue its own purposes and acts subject to the instructions of the controller (Article 28(3)(a) GDPR). Where a processor develops its own interests in the processing in breach of the GDPR, it becomes a controller itself pursuant to Article 28(10) GDPR.
Joint controllership under Article 26(1), first sentence GDPR requires that two or more entities jointly determine the purposes and means of the processing – whether through a jointly agreed decision or through converging individual decisions of several entities, provided that these complement each other and have a tangible effect on the determination of purposes and means. The decisive factor is that the processing would not be possible without the participation of both parties.
2. Typical Actors and Their Roles
The principal actors in commercial payment services – PSPs, account-servicing institutions, PISPs, AISPs, technical service providers, payers and payees (typically merchants) – are defined in Section 1 ZAG. Their classification under data protection law is not static, but depends on the respective processing phase and the actual influence over the purposes and means of processing.
According to EDPB Guidelines 06/2020, a two-step assessment applies to PISPs and AISPs: at the moment of the initial access to account data, there is generally joint controllership with the account-servicing institution pursuant to Article 26 GDPR. For subsequent processing within their own sphere – for example, the further processing of account information for their own services – PISPs and AISPs are to be regarded as sole controllers.
With regard to technical service providers, a blanket classification as processors is not appropriate in all constellations. Where they participate in the authentication or authorisation of payment transactions and fulfil their own legally defined obligations in doing so, they may, in this respect, qualify partially as controllers. The overview below therefore serves merely as an initial orientation aid. The allocation of data protection roles must always be assessed on the basis of the specific factual and legal structure of the respective business model in the individual case. In particular, distinguishing between (partial) controllership and processing on behalf of another requires a detailed case-by-case analysis taking into account the respective spheres of influence, decision-making powers and obligations of the parties involved.
| Actor | Typical Role |
|---|---|
| Account-servicing institution | Controller |
| PSP (for its own obligations) | Controller |
| PISP / AISP during initial data access | Potentially joint controller with the account-servicing institution (Article 26 GDPR) |
| PISP / AISP for subsequent processing | Sole controller |
| Technical service provider (without own purposes or statutory obligations) | Processor |
| Merchant as payee | Controller (for its own processing activities) |
| Multi-party models | Each party as sole controller or joint controllers pursuant to Article 26 GDPR |
3. Practical Delineation Issues and Legal Consequences
A common misconception is the automatic classification of payment service providers as processors, for example on the basis that they merely “pass through” data. This classification fails to recognise that payment service providers are subject to their own statutory obligations under the GwG and ZAG, which they must fulfil independently of instructions – and therefore determine the purposes and means of processing themselves.
Open banking structures and multi-party models, in which several actors access the same transaction data, are particularly challenging. The decisive factor is always the actual influence exercised – not the formal contractual structure.
The determination of the data protection role directly affects obligations and liability. The controller bears the comprehensive accountability obligation under Article 5(2) GDPR and is liable towards data subjects under Article 82 GDPR also for the conduct of the processor; in addition, the controller is subject to an ongoing obligation to select and monitor processors pursuant to Article 28(1) GDPR. In cases of joint controllership under Article 26 GDPR, the parties must contractually define their respective data protection obligations – in particular regarding the information obligations under Articles 13 and 14 GDPR and the fulfilment of data subject rights. In the event of damages, all parties are jointly and severally liable pursuant to Article 82(4) GDPR.
V. Conclusion
Data protection in payment services results from the interplay between the GDPR, PSD2 and the ZAG, each of which pursues different regulatory objectives while complementing one another.
Although payment data does not constitute special categories of data within the meaning of Article 9(1) GDPR, its combination and analysis may indirectly reveal highly sensitive aspects of private life. The choice of the appropriate legal basis under Article 6(1) GDPR depends on the specific processing purpose, just as the allocation of data protection roles between controllers, joint controllers and processors depends on the actual processing relationships. The latter has direct implications for the obligations under Articles 26 and 28 GDPR as well as for liability under Article 82 GDPR. A classification based solely on contractual arrangements without considering the economic reality does not satisfy these requirements.
The ongoing legislative work on PSD3 and the PSR also signals a forthcoming recalibration of the regulatory framework. In particular, the planned sector-specific permission for the processing of special categories of data under Article 9 GDPR could eliminate existing legal uncertainties, provided that it is included in the final legislative text.
