PSD2 + GDPR Combined Compliance Guide 2026: SCA, Open Banking, and Payment Data for SaaS Developers

Post #931 in the sota.io EU Cyber Compliance Series | EU-PAYMENT-SERIE Post #4

The previous posts in this series examined why Stripe and PayPal create structural GDPR risk through their US incorporation and CLOUD Act exposure, and compared Mollie and Adyen as genuine EU-native alternatives. Choosing the right processor is necessary but not sufficient. The deeper compliance question — one that applies regardless of which processor you use — is how PSD2 and GDPR interact at the data layer.

PSD2 (Directive (EU) 2015/2366) and GDPR (Regulation (EU) 2016/679) are the two most consequential EU legal frameworks for any SaaS that touches payment data. They were designed independently, passed in the same legislative cycle, and contain provisions that pull in opposite directions: PSD2 mandates data openness and API access, GDPR mandates data minimisation and purpose limitation. Understanding where they conflict, where they complement each other, and how to resolve the tension is essential for any developer building payment features for EU customers.

This guide covers the five areas where PSD2 and GDPR intersect most concretely: (1) payment data classification under GDPR, (2) SCA implementation and authentication data, (3) Open Banking AISP/PISP data flows and GDPR obligations, (4) Article 94 PSD2 data purpose limitation, and (5) PSP contract requirements under GDPR Article 28.

1. Payment Data Classification Under GDPR

Before examining how PSD2 and GDPR interact, you need to understand how GDPR classifies the data involved in payment transactions — because the classification determines which legal obligations apply.

Personal Data in Payment Transactions

Under GDPR Article 4(1), personal data is "any information relating to an identified or identifiable natural person." Payment transaction data almost always meets this threshold:

• Cardholder name — directly identifies a natural person
• Card number (PAN) — while pseudonymous at rest, links to a specific cardholder account and is personal data under GDPR when processed by a PSP
• IBAN — links to a specific bank account registered to a natural person
• Billing address — identifies a person at a location
• Transaction amount and merchant — when combined with a payment account, reveals spending patterns ("profiling" under GDPR Article 4(4))
• IP address at checkout — personal data under GDPR as confirmed by CJEU case C-582/14 (Breyer)
• Device fingerprint for fraud detection — personal data, often used as special category equivalent in financial context

PSD2 Data and GDPR Special Categories

GDPR Article 9 establishes a higher protection regime for "special categories" of personal data: health data, genetic data, biometric data, political opinions, religious beliefs, and so on. Payment data is not listed as a special category in Article 9.

However, payment transaction patterns can reveal special category data indirectly:

• Regular payments to a pharmacy or hospital reveal health conditions
• Donations to political parties or religious organisations reveal political opinions or religious beliefs
• Subscriptions to specific services may reveal sexual orientation

This is the "inference attack" problem. Payment data is not inherently special category data under GDPR, but aggregated payment history can constitute special category data through inference. This is the primary reason Article 94 PSD2 (discussed below) imposes strict purpose limitation rules on access to payment data — rules that mirror the heightened protection logic of GDPR Article 9, even though payment data is not formally classified as special category data.

Practical implication for SaaS developers: If your product processes payment history for analytics, credit scoring, budgeting features, or any form of customer profiling, you must assess whether the aggregated data can infer special category information. If it can, GDPR Article 9(2) processing conditions apply — typically explicit consent or substantial public interest grounds — not merely Article 6(1) legal bases.

2. Strong Customer Authentication: PSD2 Article 97 and GDPR

Strong Customer Authentication (SCA) is the authentication framework introduced by PSD2 Article 97 and detailed in the EBA Regulatory Technical Standards on SCA and Common and Secure Communication (Commission Delegated Regulation (EU) 2018/389). SCA requires that payment authentication use at least two of three independent factors:

• Knowledge — something the customer knows (password, PIN, security question answer)
• Possession — something the customer has (mobile phone, hardware token, smart card)
• Inherence — something the customer is (fingerprint, face geometry, voice pattern, keystroke dynamics)

The factors must be "independent" — the compromise of one must not compromise the others. Dynamic linking (Article 5 of the SCA RTS) requires that the authentication code be linked to the specific transaction amount and payee, making re-use of an authentication code across transactions impossible.

SCA Data and GDPR Legal Basis

SCA generates authentication data that is subject to GDPR. For each authentication factor:

Knowledge factors (passwords, PINs): Processed on the basis of GDPR Article 6(1)(b) (necessary for contract performance — you cannot pay without authentication) or Article 6(1)(c) (compliance with a legal obligation — PSD2 mandates SCA). Either basis is available. Article 6(1)(b) is typically simpler to document.

Possession factors (SMS OTP, push notification): The phone number or device identifier is processed. GDPR Article 6(1)(b) or (c) applies. Note that phone numbers are personal data under GDPR and must be handled accordingly — including in breach notification under GDPR Article 33 if your SMS OTP provider has a breach.

Inherence factors (biometrics): Biometric data used for authentication is special category personal data under GDPR Article 9(1) — "biometric data for the purpose of uniquely identifying a natural person." This means Article 9(2) processing conditions apply, not merely Article 6(1). The available Article 9(2) grounds for biometric SCA are:

• Article 9(2)(a) — explicit consent: the data subject has given explicit consent. This is the ground most commonly used for biometric authentication in consumer SaaS contexts.
• Article 9(2)(b) — employment law obligations: not applicable in a payment context.
• Article 9(2)(g) — substantial public interest: theoretically applicable for fraud prevention, but requires a specific EU or Member State law — PSD2 alone does not constitute this.

Practical requirement: If your SaaS uses biometric SCA (face ID, fingerprint) on a PSD2-regulated payment flow, you must collect explicit consent separately for the biometric data processing, independent of the general terms of service consent. A bundled checkbox in your payment flow does not meet GDPR Article 7(2) (conditions for consent) combined with Article 9(2)(a).

SCA Exemptions and GDPR Implications

The SCA RTS provides exemptions from SCA for certain transaction types. The most important for SaaS products are:

Merchant-initiated transactions (MIT exemption — Article 10 SCA RTS): Recurring payments where the payer has set up a mandate and is not present at the transaction. The initial mandate setup requires SCA; subsequent MIT transactions are exempt. Under GDPR, the mandate data (payer's authorisation) must be retained as the legal basis record for each subsequent transaction — this is typically an Article 6(1)(b) contract performance basis.

Low-value transaction exemption (Article 16 SCA RTS): Transactions under €30, with cumulative limits (€100 total since last SCA, or 5 transactions). For GDPR, applying this exemption means your payment processor (acting as processor under GDPR Article 4(8)) is making a risk-based decision — your data processing agreement with the PSP under GDPR Article 28 should specify how exemption decisions are documented.

Transaction Risk Analysis exemption (Article 18 SCA RTS): PSPs with low fraud rates can apply TRA exemption for transactions up to €500. TRA involves processing the payer's behavioural and device data to assess fraud risk — this is profiling under GDPR Article 4(4). If your SaaS relies on your PSP's TRA exemption, you must disclose this profiling in your privacy notice under GDPR Article 13(2)(f) (meaningful information about the existence of profiling and its logic).

3. Open Banking: AISP and PISP Data Flows Under PSD2 and GDPR

Open Banking — the obligation under PSD2 for banks (ASPSPs, Account Servicing Payment Service Providers) to provide API access to third parties — is where PSD2 and GDPR tension is most acute. PSD2 creates a legal right to access payment account data; GDPR restricts what can be done with that data once accessed.

AISP: Account Information Service Providers

An Account Information Service Provider (AISP) is a licensed third-party that accesses a customer's bank account data (balances, transactions, account details) with the customer's consent. Common SaaS use cases for AISP access include:

• Personal finance management tools
• Accounting and bookkeeping SaaS
• Credit assessment and lending platforms
• Expense management for business accounts

PSD2 requirement for AISP: AISPs must be licenced by a national competent authority (in Germany: BaFin; in the Netherlands: AFM; in Ireland: Central Bank of Ireland) or hold a PSD2 registration as an AISP. The licence requires demonstrating adequate security measures and organisational capacity.

GDPR obligations for AISPs:

First, legal basis for accessing account data. AISP access is based on the account holder's consent — but this consent operates at two levels:

1. PSD2 consent — the account holder consents through their bank's (ASPSP's) interface to allow the AISP to access their account. This is the PSD2 legal mechanism for access.
2. GDPR consent or contract basis — the AISP must separately establish a GDPR legal basis for processing the data it retrieves. These are legally distinct.

The GDPR legal basis for AISP data processing is typically Article 6(1)(b) (contract performance — the AISP is providing the service the customer signed up for) rather than Article 6(1)(a) (consent) for the core service. Using Article 6(1)(b) is cleaner than consent because it does not require a separate consent mechanism and cannot be withdrawn independently.

However, if your AISP SaaS uses the retrieved account data for secondary purposes (analytics, training ML models, cross-selling), you cannot rely on Article 6(1)(b) — these secondary uses require either consent (Article 6(1)(a)) or compatible purpose analysis under Article 6(4).

Second, data minimisation under GDPR Article 5(1)(c). PSD2 Article 36(1)(b) requires that AISPs "only access, process and retain personal data necessary for the provision of the account information service." This directly encodes GDPR data minimisation logic into PSD2. In practice, this means:

• You can only retrieve account data fields necessary for the specific AISP feature you are providing
• If your product needs only the account balance, you cannot retrieve the full 12-month transaction history
• API queries to the ASPSP should be scoped to the minimum data needed — this is not just a GDPR requirement, it is also an explicit PSD2 obligation

Third, data retention. PSD2 Article 35 requires AISPs to keep records sufficient to demonstrate compliance. GDPR Article 5(1)(e) requires data not be kept longer than necessary. The resolution: retain the minimum AISP transaction log required for PSD2 audit purposes (EBA guidelines suggest 5 years for PSD2 record-keeping), but purge the underlying payment data (individual transactions, balances) as soon as it is no longer needed for the service.

PISP: Payment Initiation Service Providers

A Payment Initiation Service Provider (PISP) initiates payment transactions on behalf of a customer, directly from the customer's bank account. PISPs bypass card networks — the payment goes bank-to-bank, typically as a SEPA Credit Transfer. For SaaS, common PISP use cases include checkout-by-bank-transfer (an alternative to card payments), invoice-triggered payment initiation, and marketplace payouts.

GDPR obligations for PISPs:

PISPs process the payee's IBAN (the merchant's bank account number) and the payer's account data (sufficient to initiate a transfer). The payer's IBAN is personal data if the payer is a natural person.

PISP processing of payer data is typically covered by GDPR Article 6(1)(b) (necessary for contract performance) — the customer initiated the payment and providing the payer IBAN to the PISP is necessary to execute it.

Critical GDPR requirement for PISPs: You cannot store the payer's IBAN for future use without a separate legal basis. The PISP legal basis covers the specific payment transaction. If your SaaS wants to store the payer's IBAN for recurring PISP-initiated payments, you need either a mandate (Article 6(1)(b) under a separate agreement) or consent (Article 6(1)(a)).

4. PSD2 Article 94: Data Purpose Limitation

Article 94 PSD2 is the provision that most directly encodes GDPR-equivalent obligations into payment law, and it applies specifically to payment service providers — including PSPs you contract with as a SaaS developer.

Article 94(1) PSD2: "Member States shall permit processing of personal data by payment systems and payment service providers when necessary for the prevention, investigation and detection of payment fraud."

Article 94(2) PSD2: "Payment service providers shall only access, process and retain personal data necessary for the provision of their payment services, with the explicit consent of the payment service user."

The critical implication of Article 94(2) is that your PSP — the party processing payment data on your behalf — is itself restricted in what it can do with that data. This is directly relevant when evaluating PSP data practices:

Stripe's analytics and ML training: Stripe processes payment data to improve its fraud detection models (Stripe Radar), train machine learning systems, and benchmark fraud rates across its network. Whether this constitutes "personal data necessary for the provision of payment services" under Article 94(2) is a contested compliance question. Stripe's reliance on Legitimate Interests (GDPR Article 6(1)(f)) for these secondary uses is arguably in tension with Article 94(2)'s explicit consent requirement for secondary processing.

EU-native PSPs and Article 94: Mollie B.V. and Adyen N.V., as DNB-regulated entities, are subject to PSD2 Article 94 through the Dutch Wft implementing legislation. Their published DPAs should specifically address Article 94 compliance. Developers should request Mollie's and Adyen's processing purposes documentation and verify that secondary uses of payment data require explicit consent rather than merely legitimate interests.

What Article 94 means for your Data Processing Agreement: When you contract with a PSP under GDPR Article 28 (processor agreement), your DPA should explicitly include Article 94(2) compliance obligations. Specifically:

• The PSP should commit to processing payment data only for the purposes specified in your DPA
• Any use of aggregate anonymised payment data (e.g., for fraud benchmarking) should be explicitly identified as a legitimate purpose in the DPA
• Your customers' explicit consent should be documented where Article 94(2) requires it — typically for any use of payment data beyond the immediate transaction

5. PSP Contract Requirements: GDPR Article 28 for Payment Processors

Your payment processor is a data processor under GDPR Article 4(8) — they process personal data on your behalf. GDPR Article 28 requires a Data Processing Agreement (DPA) that specifies the processing in detail.

Standard PSP DPA provisions that are legally required under Article 28:

Mollie DPA: Mollie publishes its Data Processing Agreement at mollie.com/en/privacy. The Mollie DPA covers Article 28 requirements and specifies EEA-only processing. Mollie does not require negotiation for standard DPA terms.

Adyen DPA: Adyen's DPA is included in its standard merchant agreement. Adyen's DPA covers Article 28 requirements and specifies that payment data is processed on Adyen's infrastructure in the Netherlands and Germany (for EU transactions). Enterprise merchants can negotiate specific DPA clauses.

Sub-processor audit obligation: Under Article 28(3)(d), you must have the right to object to new sub-processors. PSPs with large sub-processor networks (card networks, fraud screening services, 3DS authentication providers) introduce significant sub-processing chain complexity. Before going live with any PSP, obtain the current sub-processor list and assess whether each sub-processor introduces cross-border transfer risk.

6. PSD2 3.0 / PSD3 and GDPR: What Is Coming

The European Commission published its PSD3 proposal in June 2023 (COM(2023) 366 final), along with the Payment Services Regulation (PSR) proposal (COM(2023) 367 final). PSD3/PSR is expected to be adopted in 2025-2026 with a transposition deadline of 18 months after adoption — putting full implementation likely in 2027.

PSD3/PSR changes relevant to PSD2+GDPR compliance:

Open Banking data quality obligations: PSD3 Article 50 will require ASPSPs (banks) to make their Open Banking APIs available without dedicated interfaces (i.e., through the same API their own mobile apps use, not a degraded "compliance-only" interface). This improves AISP data quality but also increases the volume of personal data accessible through Open Banking — making GDPR data minimisation compliance more important, not less.

Explicit Financial Data Sharing Scheme (FIDA): The proposed Financial Data Access Regulation (FIDA, COM(2023) 360 final) extends Open Banking logic beyond payment accounts to investment accounts, insurance, pensions, and credit data. FIDA will create a new licensed entity category (Financial Information Service Provider, FISP) with GDPR data minimisation and purpose limitation obligations built into the licence conditions.

SCA under PSD3: PSD3 modifies the SCA exemption framework. The low-value transaction exemption thresholds are under review, and the TRA exemption criteria are being tightened. The biometric SCA rules are likely to be explicitly cross-referenced with GDPR Article 9 requirements in PSD3's implementing regulation.

Developer action: If you are building AISP/PISP features today, design your data architecture for GDPR Article 5 data minimisation from the start — PSD3 will increase regulatory scrutiny of Open Banking data practices, not reduce it.

7. Practical Compliance Checklist

For SaaS developers integrating EU payment processing:

PSD2 SCA compliance:

• Identify which payment flows require SCA (all remote card-initiated transactions unless an exemption applies)
• Document the SCA exemptions your PSP applies (MIT, low-value, TRA) and the GDPR implications of each
• If using biometric SCA, implement explicit Article 9(2)(a) consent separately from your general terms
• Implement dynamic linking — verify your 3DS2 integration links authentication codes to specific transaction amounts and payees
• For MIT subscriptions: document the mandate as the legal basis record for each subsequent transaction

GDPR data minimisation in payment flows:

• Audit what payment data fields your application stores post-transaction — do you need the full PAN, or only the last 4 digits for display?
• Define retention periods for payment data by field: transaction IDs (5 years for accounting), raw card data (zero — store tokenised references only), IP addresses at checkout (defined retention period)
• If using AISP access, scope API queries to the minimum fields needed per feature

Open Banking AISP/PISP implementation:

• Verify your AISP/PISP licence or confirm you are relying on a licenced intermediary (e.g., via Open Banking API aggregators like Tink, Nordigen/GoCardless, or Token.io)
• Document two-level consent: PSD2 consent at the bank interface + GDPR Article 6 legal basis in your privacy notice
• Implement data minimisation: do not retrieve more account history than your feature requires
• Address secondary use: if aggregated account data is used for analytics or ML training, implement explicit consent under GDPR Article 6(1)(a)

Article 94 and PSP DPA:

• Obtain the current DPA from your PSP and verify all Article 28(3) elements are present
• Obtain the current sub-processor list and assess cross-border transfer risk
• Verify Article 94(2) compliance: PSP should process payment data only for purposes specified in the DPA
• Confirm PSP infrastructure is EEA-based for EU transaction data (verify in DPA schedules, not marketing copy)

Privacy notice updates:

• Disclose TRA profiling under GDPR Article 13(2)(f) if your PSP applies TRA exemptions
• Disclose AISP sub-processor chain in your sub-processor list
• Include payment data retention periods per field in your privacy notice

Summary: PSD2 and GDPR Are Complementary, Not Contradictory

The apparent tension between PSD2 (open data, API access) and GDPR (data minimisation, purpose limitation) resolves when you understand that PSD2 Article 94 and GDPR Article 5 are designed to achieve the same underlying goal: ensuring that payment data flows only where necessary and only for legitimate purposes.

The compliance requirements are layered:

• PSD2 creates the permission to share payment data (via Open Banking consent)
• GDPR defines how that data can be used once shared (legal basis, minimisation, purpose limitation)
• Article 94 PSD2 binds your PSP to GDPR-equivalent obligations independently of your contract with them

For EU-native payment processing that reduces structural risk on both dimensions, the earlier posts in this series cover Mollie and Adyen — both DNB-regulated Dutch entities with no CLOUD Act exposure — as the primary EU-native alternatives to Stripe and PayPal for SaaS developers.

The next post in the EU-PAYMENT-SERIE covers Paddle and Lemon Squeezy as EU-alternative Merchants of Record — including why Lemon Squeezy's 2024 acquisition by Stripe changes the CLOUD Act analysis for Merchant of Record arrangements.

sota.io is an EU-sovereign cloud platform for developers. Start free — no credit card required.