Kristian Hoffmann

1.6.2026

Aufwand DSGVO und PSD2 Banking im Vergleich: Anforderungen und Überschneidungen

DSGVO und PSD2 im Banking: Unterschiede, Überschneidungen und Implementierungsanforderungen für Zahlungsdienstleister und Fintech-Unternehmen.

Kristian HoffmannSaaS founder and operator
Minimalist split-screen illustration: left side shows interconnected data nodes and lock symbols representing GDPR data

Aufwand DSGVO und PSD2 Banking im Vergleich

Kurzantwort: Der Aufwand DSGVO und PSD2 Banking im Vergleich bezeichnet die unterschiedlichen Implementierungs- und Compliance-Anforderungen, wenn Banking-Systeme personenbezogene Daten verarbeiten und Zahlungsdienste anbieten. Die DSGVO ist eine EU-Verordnung, die den Schutz personenbezogener Daten branchenübergreifend regelt. Die PSD2 ist eine EU-Richtlinie, die speziell Zahlungsdienste, starke Kundenauthentifizierung und Open Banking regelt. Im Banking überschneiden sich beide Regelwerke bei der Verarbeitung von Zahlungsdaten – erfordern aber unterschiedliche technische Maßnahmen. Der konkrete Aufwand hängt davon ab, ob Sie Zahlungsdienstleister, Kontoinformationsdienst oder reiner Datenspeicherer sind.

> Hinweis: Dieser Artikel ist technische Orientierungshilfe, kein Rechtsgutachten. Für verbindliche Aussagen zu Ihren konkreten Compliance-Pflichten ziehen Sie einen Rechtsanwalt oder Compliance-Berater hinzu.

Was ist DSGVO und was ist PSD2? – Definitionen und Ziele

DSGVO: Schutz personenbezogener Daten in allen Branchen

Die Datenschutz-Grundverordnung (DSGVO) ist eine EU-Verordnung, die seit Mai 2018 unmittelbar in allen Mitgliedstaaten gilt (Volltext auf EUR-Lex). Sie regelt, wie Organisationen personenbezogene Daten erfassen, speichern, verarbeiten und weitergeben – unabhängig von der Branche. Im Banking bedeutet das: Kundennamen, Kontodaten, Transaktionshistorien und IP-Adressen sind personenbezogene Daten und fallen unter die DSGVO.

Leitlinien zur Auslegung einzelner Artikel veröffentlicht der Europäische Datenschutzausschuss (EDPB). Für Deutschland ist die Datenschutzkonferenz (DSK) eine weitere Orientierungsquelle.

Art. 6 DSGVO legt fest, dass Datenverarbeitung einer Rechtsgrundlage bedarf (z. B. Vertrag, Einwilligung, rechtliche Verpflichtung). Art. 5 Abs. 1 lit. e regelt die Speicherbegrenzung. Art. 15–17 gewähren Betroffenen Rechte wie Auskunft, Berichtigung und Löschung. Welche Rechtsgrundlage in Ihrem konkreten Fall greift, ist eine rechtliche Frage – kein technisches Implementierungsdetail.

PSD2: Regulierung von Zahlungsdiensten und Open Banking

Die Payment Services Directive 2 (PSD2) ist eine EU-Richtlinie, die in nationales Recht umgesetzt werden muss (Volltext auf EUR-Lex). In Deutschland erfolgte die Umsetzung im Zahlungsdiensteaufsichtsgesetz (ZAG). PSD2 verfolgt zwei Ziele:

  1. Sichere Zahlungen: Starke Kundenauthentifizierung (SCA) verlangt, dass Zahlungen über mindestens zwei unabhängige Faktoren authentifiziert werden (z. B. Passwort + SMS-Code).
  2. Open Banking: Banken müssen zugelassenen Drittanbietern Zugang zu Kontodaten und Zahlungsfunktionen über sichere APIs ermöglichen.

PSD2 regelt die Sicherheit und Offenheit von Zahlungsprozessen – nicht den Datenschutz im Allgemeinen.

Warum beide Regelwerke im Banking relevant sind

Wenn Sie einen Zahlungsdienst anbieten oder auf Bankdaten zugreifen, müssen Sie beide Regelwerke parallel beachten. Die Anforderungen sind unterschiedlich:

Die Einhaltung eines Regelwerks ersetzt das andere nicht. Erstellen Sie zwei separate Checklisten und prüfen Sie beide.

Wo überschneiden sich DSGVO und PSD2 im Banking?

Überschneidung 1: Verarbeitung von Zahlungsdaten und Kundenauthentifizierung

Workflow-Beispiel (fiktiv): Ein Fintech-Zahlungsauslösedienst initiiert eine Zahlung für einen Nutzer. Der Dienst führt die SCA-Authentifizierung durch (PSD2-Anforderung) und löscht die dabei anfallenden Authentifizierungsdaten nach Abschluss der Transaktion (DSGVO-Speicherbegrenzung gemäß Art. 5 Abs. 1 lit. e).

Überschneidung 2: Speicherung und Weitergabe von Kontoinformationen

Wenn Sie als Kontoinformationsdienst (AIS) auf Kontodaten zugreifen, greifen beide Regelwerke parallel:

Workflow-Beispiel (fiktiv): Eine Budgetierungs-App liest monatlich Kontotransaktionen aus. Sie dokumentiert die Zugriffsrechte des Kunden (PSD2), verschlüsselt die Transaktionsdaten und löscht sie nach einer definierten Frist (DSGVO-Speicherbegrenzung), und zeigt dem Kunden, welche Daten gespeichert sind (DSGVO-Transparenzpflicht gemäß Art. 13/14).

Unterschied: Datenschutz vs. Zahlungssicherheit

| | DSGVO | PSD2 | |---|---|---| | Ziel | Privatsphäre und Rechte der betroffenen Person | Sicherheit von Zahlungen, Wettbewerb durch Open Banking | | Kernpflichten | Transparenz, Speicherbegrenzung, Betroffenenrechte | SCA, sichere APIs, Transaktionsmonitoring | | Geltungsbereich | Alle Branchen, alle personenbezogenen Daten | Zahlungsdienstleister, Banken, Fintechs | | Aufsicht (DE) | Datenschutzbehörden (z. B. LfDI) | BaFin |

Eine technische Maßnahme kann beide Anforderungen adressieren (z. B. Verschlüsselung), aber die Ziele und Prüfpunkte bleiben unterschiedlich.

Aufwand nach Systemtyp

Der Implementierungsaufwand hängt stark davon ab, welche Rolle Ihr System im Zahlungsverkehr spielt. Die folgenden Aufwandswerte sind Orientierungsschätzungen aus typischen Implementierungsszenarien – keine Festpreise oder Garantien. Der tatsächliche Aufwand hängt von Ihrer bestehenden Infrastruktur, Team-Erfahrung und den konkreten regulatorischen Anforderungen in Ihrer Jurisdiktion ab.

Szenario 1: Zahlungsauslösedienst (PIS)

Ein Payment Initiation Service initiiert Zahlungen im Namen des Kunden – z. B. eine App, die Rechnungen direkt aus der App bezahlt.

Orientierungswert Aufwand: 4–8 Wochen für ein MVP mit SCA, Verschlüsselung und Audit-Logs.

Szenario 2: Kontoinformationsdienst (AIS)

Ein Account Information Service liest Kontoinformationen aus, ohne Zahlungen auszulösen – z. B. ein Finanz-Dashboard oder eine Budgetierungs-App.

Orientierungswert Aufwand: 2–4 Wochen für API-Integration, Verschlüsselung und Datenspeicherung.

Szenario 3: Reiner Datenspeicherer (kein Banking)

Sie betreiben keine Zahlungsfunktion und greifen nicht auf Bankdaten zu – z. B. ein CRM-System für eine Praxis oder ein E-Commerce-Shop mit Kundenadressen.

PSD2-Maßnahmen: Nicht relevant.

Orientierungswert Aufwand: 1–2 Wochen für Verschlüsselung, Audit-Logs und Datenschutzrichtlinie.

Szenario 4: Zahlungsdienstleister mit eigenem Konto-Zugang

Sie betreiben ein eigenes Zahlungskonto und ermöglichen Kunden, Geld zu überweisen oder zu empfangen – z. B. ein Fintech oder eine digitale Geldbörse. Für diesen Systemtyp sind regulatorische Zulassungen erforderlich; die konkreten Anforderungen variieren je nach Jurisdiktion und sollten mit einem Compliance-Berater und Rechtsanwalt geklärt werden.

Orientierungswert Aufwand: 8–16 Wochen für Implementierung und interne Compliance-Prozesse, ohne regulatorische Zulassungsverfahren.

Aufwand-Entscheidungsmatrix

| Systemtyp | DSGVO-Anforderungen | PSD2-Anforderungen | Aufwand (Orientierung) | Beispiel-Technologien | |---|---|---|---|---| | Zahlungsauslösedienst (PIS) | Verschlüsselung, Speicherfristen, Datenschutzrichtlinie | SCA, sichere API, Transaktionsmonitoring | 4–8 Wochen | OAuth 2.0, mTLS, AES-256, Audit-Logs | | Kontoinformationsdienst (AIS) | Verschlüsselung, DSFA prüfen, Speicherfristen | Sichere API, Zugriffsprotokoll | 2–4 Wochen | API-Gateway, Verschlüsselung, TTL-Datenspeicher | | Datenspeicherer (kein Banking) | Verschlüsselung, Speicherfristen, Betroffenenrechte | Nicht relevant | 1–2 Wochen | Verschlüsselung, Zugriffskontrolle, Audit-Logs | | Zahlungsdienstleister | KYC, Authentifizierung, Speicherfristen, Betroffenenrechte | SCA, sichere APIs, Fraud-Detection, Meldepflichten | 8–16 Wochen | HSM, Fraud-Detection, Compliance-Tools |

*Alle Aufwandswerte sind Orientierungsschätzungen aus typischen Implementierungsszenarien, keine Festpreise oder Garantien.*

Technische Anforderungen: DSGVO vs. PSD2

DSGVO: Datenschutz by Design, Verschlüsselung, Zugriffskontrolle

Verschlüsselung: Kundendaten werden verschlüsselt gespeichert und übertragen. Verbreitete Praxis ist AES-256 für Speicherung und TLS 1.2+ für Übertragung.

Zugriffskontrolle: Rollenbasierte Zugriffskontrolle (RBAC) und Audit-Logs dokumentieren, wer wann auf welche Daten zugegriffen hat.

Datenspeicherfristen: Kundendaten werden nicht länger gespeichert als nötig. Welche Frist konkret gilt, hängt vom Verarbeitungszweck und der Rechtsgrundlage ab – das ist eine rechtliche Frage, keine technische.

Datenschutzrichtlinie: Sie dokumentieren, welche Daten Sie speichern, warum, wie lange und an wen Sie sie weitergeben.

PSD2: SCA, sichere APIs, Transaktionsmonitoring

Sichere APIs: Verbindungen zwischen Ihrem System und der Bank werden mit mTLS (mutual TLS) oder OAuth 2.0 authentifiziert und verschlüsselt.

Transaktionsmonitoring: Regeln erkennen verdächtige Muster – z. B. Transaktionen, die deutlich über dem Kundendurchschnitt liegen, Zahlungen in neue Länder oder viele Transaktionen in kurzer Zeit.

Maßnahmen, die beide Anforderungen gleichzeitig adressieren

| Maßnahme | DSGVO-Nutzen | PSD2-Nutzen | |---|---|---| | Verschlüsselung (AES-256, TLS 1.2+) | Schutz personenbezogener Daten | Schutz von Zahlungsdaten | | Audit-Logs | Dokumentation von Datenzugriffen | Nachweis von Zahlungstransaktionen | | Sichere APIs (mTLS, OAuth 2.0) | Schutz von Kundendaten bei Übertragung | Sichere Verbindung zur Bank | | Authentifizierung (RBAC, MFA) | Zugriffskontrolle auf Kundendaten | SCA für Zahlungen |

Datenschutzfolgenabschätzung (DSFA): Wann und wie

Wann ist eine DSFA sinnvoll?

Eine DSFA ist ein Prozess zur Bewertung von Risiken bei der Verarbeitung personenbezogener Daten. Sie ist sinnvoll, wenn:

Ob eine DSFA in Ihrem konkreten Fall verpflichtend ist, ergibt sich aus Art. 35 DSGVO und den Listen der zuständigen Aufsichtsbehörden – das ist eine rechtliche Einschätzung, keine technische.

Checkliste: Fragen für eine DSFA im Banking-Kontext

  1. Welche Daten verarbeiten Sie? (z. B. Kontonummern, Transaktionshistorien, Namen)
  2. Warum verarbeiten Sie diese Daten? (z. B. Zahlungen auslösen, Budgets berechnen)
  3. Wie lange speichern Sie die Daten, und auf welcher Rechtsgrundlage?
  4. Wer hat Zugriff auf die Daten? (Mitarbeiter, Partner, Banken)
  5. Welche Risiken entstehen? (z. B. Datenverlust, unbefugter Zugriff)
  6. Wie mindern Sie diese Risiken? (Verschlüsselung, Zugriffskontrolle, Audit-Logs)
  7. Welche Rechte haben Betroffene, und wie setzen Sie diese technisch um?

Workflow-Beispiel: DSFA für einen fiktiven Kontoinformationsdienst

Szenario (fiktiv): Eine Budgetierungs-App liest monatlich Kontotransaktionen aus.

Verarbeitete Daten: Kontonummern, Transaktionsdaten (Datum, Betrag, Empfänger), Kundennamen.

Bei der Entwicklung von Banking-Apps mit sensiblen Daten fokussiere ich auf praktische Automation, Sicherheit und dokumentierte Übergabe. Eine DSFA ist kein Compliance-Häkchen, sondern ein Risiko-Management-Werkzeug, das Probleme früh sichtbar macht.

Häufige Fallstricke

Fallstrick 1: DSGVO und PSD2 als dasselbe behandeln

Beide Regelwerke haben unterschiedliche Ziele, Prüfpunkte und zuständige Aufsichtsbehörden. Die Einhaltung eines Regelwerks ersetzt das andere nicht. Erstellen Sie zwei separate Checklisten und prüfen Sie beide.

Fallstrick 2: Aufwand für sichere APIs unterschätzen

Banken-APIs erfordern mTLS oder OAuth 2.0, Zertifikatsverwaltung, Fehlerbehandlung und regelmäßige Sicherheitstests. Kalkulieren Sie für sichere API-Integration mindestens 1–2 Wochen zusätzlich ein. Nutzen Sie etablierte Bibliotheken statt eigener Implementierungen.

Fallstrick 3: Speicherfristen nicht automatisiert

Manuelle Löschprozesse werden vergessen. Implementieren Sie TTL-Mechanismen in der Datenbank oder automatisierte Lösch-Jobs von Anfang an. In Supabase lässt sich das z. B. über `pg_cron`-Jobs oder Row-Level-Security-Policies mit Zeitstempel-Bedingungen umsetzen.

Fallstrick 4: Compliance als Nachgedanke behandeln

DSGVO- und PSD2-Anforderungen, die erst nach der Entwicklung eingebaut werden, sind teurer und fehleranfälliger als solche, die von Anfang an in der Architektur berücksichtigt werden. Datenschutz by Design ist in Art. 25 DSGVO verankert – kein optionaler Zusatz.

Implementierungs-Checkliste: DSGVO und PSD2 im Banking

Verwenden Sie diese Checkliste als technischen Ausgangspunkt – nicht als Ersatz für rechtliche Beratung.

DSGVO-Checkliste

PSD2-Checkliste