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

Überschneidung 1: Verarbeitung von Zahlungsdaten und Kundenauthentifizierung

• DSGVO verlangt, dass Zahlungsdaten (Kontonummer, Name, Betrag) nur mit Rechtsgrundlage verarbeitet werden und dass Betroffene wissen, was mit ihren Daten passiert.
• PSD2 verlangt, dass Zahlungen durch SCA mit zwei unabhängigen Faktoren geschützt sind.

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:

• DSGVO: Wie lange dürfen Kontoauszüge gespeichert werden? Wer darf darauf zugreifen? Wie informieren Sie den Kunden?
• PSD2: Welche Informationen darf der Dienst abrufen? Muss der Kunde erneut authentifizieren?

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.

---

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.

DSGVO-Maßnahmen: - Authentifizierungsdaten sicher speichern und nach Transaktion löschen. - Transaktionsdaten verschlüsseln und Zugriffskontrolle implementieren. - Datenschutzrichtlinie und Einwilligung dokumentieren.

PSD2-Maßnahmen: - SCA implementieren – mindestens zwei unabhängige Faktoren. - Sichere API-Verbindung zur Bank aufbauen (mTLS, OAuth 2.0). - Transaktionen überwachen und verdächtige Aktivitäten melden.

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.

DSGVO-Maßnahmen: - Kontoauszüge und Transaktionsdaten verschlüsseln. - Speicherfristen definieren und automatisiert durchsetzen. - Datenschutzfolgenabschätzung (DSFA) prüfen, da sensible Finanzdaten verarbeitet werden (ob sie verpflichtend ist, ergibt sich aus Art. 35 DSGVO und den Listen der zuständigen Aufsichtsbehörden).

PSD2-Maßnahmen: - Sichere API-Verbindung zur Bank aufbauen. - Kundenauthentifizierung dokumentieren. - Zugriff auf die vom Kunden autorisierten Daten beschränken.

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.

DSGVO-Maßnahmen: - Kundendaten verschlüsseln. - Speicherfristen beachten. - Datenschutzrichtlinie und Einwilligung dokumentieren. - Betroffenenrechte (Auskunft, Löschung) implementieren.

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.

DSGVO-Maßnahmen: - Verschlüsselung, Speicherfristen, Betroffenenrechte. - KYC-Daten (Know Your Customer) und Authentifizierungsnachweise dokumentieren.

PSD2-Maßnahmen: - SCA für alle Zahlungen. - Sichere APIs zu anderen Zahlungsdienstleistern oder Banken. - Transaktionsmonitoring und Fraud-Detection. - Regulatorische Meldepflichten – konkrete Anforderungen je nach Zulassung und Jurisdiktion individuell prüfen.

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

---

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.

---

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

Starke Kundenauthentifizierung (SCA): Zahlungen werden durch mindestens zwei unabhängige Faktoren geschützt: - Etwas, das Sie wissen (Passwort, PIN) - Etwas, das Sie haben (SMS-Code, Authenticator-App, Push-Benachrichtigung) - Etwas, das Sie sind (Fingerabdruck, Gesichtserkennung)

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

---

Wann ist eine DSFA sinnvoll?

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

• Sie sensible Daten verarbeiten (Finanzdaten, Gesundheitsdaten, biometrische Daten).
• Sie Daten in großem Umfang verarbeiten.
• Sie neue Technologien einsetzen, deren Risiken noch unklar sind (z. B. KI-basierte Fraud-Detection).

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.

Identifizierte Risiken: - Datenverlust durch Angriff auf die Datenbank - Unbefugter Zugriff durch interne Mitarbeiter - Abfangen von Daten bei der API-Verbindung zur Bank

Technische Maßnahmen: - AES-256-Verschlüsselung in der Datenbank, TLS 1.2+ in der API - RBAC: Nur der Datenbank-Administrator darf auf Kundendaten zugreifen - Audit-Logs für alle Datenzugriffe - TTL-Mechanismus: Transaktionsdaten werden nach einer definierten Frist automatisch gelöscht (konkrete Frist abhängig von Rechtsgrundlage und Zweck – rechtlich prüfen lassen) - Datenschutzrichtlinie mit Angaben zu gespeicherten Daten und Speicherdauer

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.

---

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.

---

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

DSGVO-Checkliste

• [ ] Rechtsgrundlage für jede Datenverarbeitung identifiziert und dokumentiert (Art. 6 DSGVO)
• [ ] Datenschutzrichtlinie erstellt und für Nutzer zugänglich (Art. 13/14 DSGVO)
• [ ] Verschlüsselung implementiert (Speicherung und Übertragung)
• [ ] Rollenbasierte Zugriffskontrolle (RBAC) eingerichtet
• [ ] Audit-Logs für Datenzugriffe aktiviert
• [ ] Speicherfristen definiert und automatisiert durchgesetzt (TTL oder Lösch-Jobs)
• [ ] Betroffenenrechte technisch umgesetzt (Auskunft, Berichtigung, Löschung – Art. 15–17 DSGVO)
• [ ] DSFA-Pflicht geprüft (Art. 35 DSGVO) und ggf. durchgeführt
• [ ] Auftragsverarbeitungsverträge mit Dienstleistern abgeschlossen (Art. 28 DSGVO)

PSD2-Checkliste

• [ ] Starke Kundenauthentifizierung (SCA) mit zwei unabhängigen Faktoren implementiert
• [ ] Sichere API-Verbindung zur Bank aufgebaut (mTLS oder OAuth 2