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. DSGVO regelt den Schutz aller personenbezogenen Daten, PSD2 regelt speziell Zahlungsdienste, starke Kundenauthentifizierung und Open Banking. 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 nur Datenspeicherer sind.

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

DSGVO: Schutz personenbezogener Daten in allen Branchen

Die Datenschutz-Grundverordnung (DSGVO) ist ein EU-weites Datenschutzgesetz, das seit 2018 in Kraft ist. Sie regelt, wie Organisationen personenbezogene Daten erfassen, speichern, verarbeiten und weitergeben – unabhängig von der Branche. Im Banking bedeutet das: Kundennamen, Kontodaten, Transaktionshistorien, IP-Adressen und Geolokationen sind personenbezogene Daten und unterliegen der DSGVO.

Die DSGVO sieht vor, dass Datenverarbeitung auf einer rechtlichen Grundlage beruht (z.B. Vertrag, Einwilligung, rechtliche Verpflichtung), dass Daten nur so lange gespeichert werden, wie nötig, und dass Betroffene Rechte wie Auskunft, Berichtigung und Löschung haben. Die Verantwortung liegt bei der Organisation, die die Daten verarbeitet. Offizielle Orientierung bietet die EDPB-Guidance zu GDPR.

PSD2: Regulierung von Zahlungsdiensten und Open Banking

Die Payment Services Directive 2 (PSD2) ist eine EU-Richtlinie speziell für Zahlungsdienste. Sie regelt, wie Zahlungsdienstleister, Kontoinformationsdienste und Zahlungsauslösedienste arbeiten dürfen. PSD2 zielt auf zwei Ziele ab:

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

PSD2 regelt also nicht den Datenschutz allgemein, sondern die Sicherheit und Offenheit von Zahlungsprozessen.

Warum beide Regelwerke im Banking relevant sind

Im Banking greifen beide Regelwerke ineinander. Wenn Sie einen Zahlungsdienst anbieten oder auf Bankdaten zugreifen, müssen Sie beide Regelwerke parallel beachten:

• DSGVO: Kundendaten schützen, Speicherfristen einhalten, Betroffenenrechte gewähren.
• PSD2: Sichere Authentifizierung implementieren, APIs sicher gestalten, Transaktionen monitoren.

Ein häufiges Missverständnis: DSGVO und PSD2 sind nicht dasselbe. DSGVO ist der Datenschutz-Rahmen, PSD2 ist die Zahlungs-Regulierung. Beide müssen parallel erfüllt werden.

Wo überschneiden sich DSGVO und PSD2 im Banking?

Überschneidung 1: Verarbeitung von Zahlungsdaten und Kundenauthentifizierung

Beide Regelwerke regeln, wie Kundendaten bei Zahlungen verarbeitet werden:

• DSGVO sieht vor, dass Zahlungsdaten (Kontonummer, Name, Betrag) nur mit Rechtsgrundlage verarbeitet werden und dass Betroffene wissen, was mit ihren Daten passiert.
• PSD2 sieht vor, dass Zahlungen durch starke Kundenauthentifizierung (SCA) geschützt sind – also zwei unabhängige Authentifizierungsfaktoren (z.B. Passwort + biometrische Daten oder Hardware-Token).

• Praktisches Beispiel: Ein Fintech-Zahlungsauslösedienst (PIS) ruft die Bank des Kunden auf und initiiert eine Zahlung. Der Dienst muss:
• Die Kundenauthentifizierung über SCA durchführen (PSD2-Anforderung).
• Die Authentifizierungsdaten sicher speichern und nach Abschluss der Transaktion löschen (DSGVO-Anforderung).

Überschneidung 2: Speicherung und Weitergabe von Kontoinformationen

Wenn Sie auf Kontoinformationen zugreifen (z.B. als Kontoinformationsdienst, AIS), regeln beide Regelwerke:

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

• Praktisches Beispiel: Eine Budgetierungs-App (AIS) liest monatlich die Kontotransaktionen des Kunden aus. Sie muss:
• Die Zugriffsrechte des Kunden dokumentieren (PSD2).
• Die Transaktionsdaten verschlüsseln und nach 90 Tagen löschen (DSGVO).
• Dem Kunden zeigen, welche Daten gespeichert sind und wie lange (DSGVO).

Unterschied: DSGVO fokussiert auf Datenschutz, PSD2 auf Zahlungssicherheit

Der Kern-Unterschied liegt in der Zielsetzung:

• DSGVO schützt die Privatsphäre und Rechte der betroffenen Person.
• PSD2 schützt die Sicherheit von Zahlungen und fördert Wettbewerb durch Open Banking.

Das führt zu unterschiedlichen Anforderungen: DSGVO verlangt Transparenz und Kontrollrechte, PSD2 verlangt Authentifizierung und API-Standards. Eine Maßnahme kann beide erfüllen (z.B. sichere Verschlüsselung), aber die Ziele sind unterschiedlich.

Aufwand nach Systemtyp: Entscheidungsmatrix

Der Implementierungsaufwand für DSGVO und PSD2 hängt stark davon ab, welche Rolle Ihr System im Zahlungsverkehr spielt. Nicht jedes System braucht beide Regelwerke in vollem Umfang.

Szenario 1: Sie betreiben einen Zahlungsauslösedienst (PIS)

Ein Zahlungsauslösedienst (Payment Initiation Service) initiiert Zahlungen im Namen des Kunden. Beispiel: Eine App, die dem Nutzer erlaubt, Rechnungen direkt aus der App zu bezahlen.

• DSGVO-Anforderungen:
• Authentifizierungsdaten (Passwort, PIN, biometrische Daten) sicher speichern und nach Transaktion löschen.
• Transaktionsdaten verschlüsseln und Zugriffskontrolle implementieren.
• Datenschutzrichtlinie und Einwilligung des Kunden dokumentieren.

• PSD2-Anforderungen:
• Starke Kundenauthentifizierung (SCA) implementieren – mindestens zwei unabhängige Faktoren.
• Sichere API-Verbindung zur Bank aufbauen (mTLS, OAuth 2.0).
• Transaktionen monitoren und verdächtige Aktivitäten melden.

Geschätzter Aufwand: Hoch (4–8 Wochen für ein MVP mit SCA, Verschlüsselung und Audit-Logs). Dies ist eine Schätzung basierend auf typischen Implementierungsszenarien; der tatsächliche Aufwand hängt von Ihrer bestehenden Infrastruktur ab.

Szenario 2: Sie betreiben einen Kontoinformationsdienst (AIS)

Ein Kontoinformationsdienst (Account Information Service) liest Kontoinformationen aus, ohne Zahlungen auszulösen. Beispiel: Eine Budgetierungs-App oder ein Finanz-Dashboard.

• DSGVO-Anforderungen:
• Kontoauszüge und Transaktionsdaten verschlüsseln.
• Speicherfristen definieren (z.B. 90 Tage für Analyse, dann Löschung).
• Datenschutzfolgenabschätzung (DSFA) durchführen, da sensible Finanzdaten verarbeitet werden.

• PSD2-Anforderungen:
• Sichere API-Verbindung zur Bank aufbauen.
• Kundenauthentifizierung dokumentieren (wann und wie hat der Kunde Zugriff gewährt?).
• Zugriff auf Kontoinformationen auf die vom Kunden autorisierten Daten beschränken.

Geschätzter Aufwand: Mittel (2–4 Wochen für API-Integration, Verschlüsselung und Datenspeicherung). Schätzung basierend auf typischen Projekten; individuelle Anforderungen können variieren.

Szenario 3: Sie speichern nur Kundendaten (reine DSGVO-Anforderungen)

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

• DSGVO-Anforderungen:
• Kundendaten (Name, Adresse, E-Mail) verschlüsseln.
• Speicherfristen beachten (z.B. 3 Jahre nach letztem Kontakt).
• Datenschutzrichtlinie und Einwilligung dokumentieren.
• Betroffenenrechte (Auskunft, Löschung) implementieren.

PSD2-Anforderungen: Nicht relevant.

Geschätzter Aufwand: Gering (1–2 Wochen für Verschlüsselung, Audit-Logs und Datenschutzrichtlinie).

Szenario 4: Sie sind Zahlungsdienstleister mit eigenem Konto-Zugang

Sie betreiben ein eigenes Zahlungskonto und ermöglichen Kunden, Geld zu überweisen oder zu empfangen. Beispiel: Ein Fintech-Zahlungsdienstleister oder eine digitale Geldbörse.

• DSGVO-Anforderungen:
• Alle oben genannten Anforderungen (Verschlüsselung, Speicherfristen, Betroffenenrechte).
• Zusätzlich: Kundenauthentifizierung und Verifizierung (KYC – Know Your Customer) dokumentieren.

• PSD2-Anforderungen:
• Starke Kundenauthentifizierung (SCA) für alle Zahlungen.
• Sichere API-Verbindungen zu anderen Zahlungsdienstleistern oder Banken.
• Transaktionsmonitoring und Fraud-Detection implementieren.
• Regulatorische Meldepflichten erfüllen (z.B. verdächtige Transaktionen melden).

Geschätzter Aufwand: Sehr hoch (8–16 Wochen für vollständige Implementierung, regulatorische Registrierung und Compliance-Prozesse). Hinzu kommen regulatorische Anforderungen, die je nach Jurisdiktion variieren.

Aufwand-Entscheidungsmatrix: Welche Anforderungen gelten für Ihr Banking-System?

*Hinweis: Diese Aufwand-Schätzungen basieren auf typischen Implementierungsszenarien. Der tatsächliche Aufwand hängt von Ihrer bestehenden Infrastruktur, Team-Erfahrung und regulatorischen Anforderungen in Ihrer Jurisdiktion ab. Für verbindliche Aussagen zu regulatorischen Anforderungen konsultieren Sie einen Compliance-Berater oder Rechtsanwalt.*

Technische Anforderungen: DSGVO vs. PSD2

DSGVO-Anforderungen: Datenschutz by Design, Verschlüsselung, Zugriffskontrolle

Die DSGVO sieht technische und organisatorische Maßnahmen zum Schutz personenbezogener Daten vor. Das bedeutet konkret:

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

Zugriffskontrolle: Nur autorisierte Mitarbeiter dürfen auf Kundendaten zugreifen. Das erfordert rollenbasierte Zugriffskontrolle (RBAC) und Audit-Logs, die dokumentieren, wer wann auf welche Daten zugegriffen hat.

Datenspeicherfristen: Kundendaten werden nicht länger gespeichert als nötig. Beispiel: Transaktionsdaten einer Budgetierungs-App sollten nach 90 Tagen automatisch gelöscht werden.

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

PSD2-Anforderungen: Starke Kundenauthentifizierung (SCA), sichere APIs, Transaktionsmonitoring

PSD2 sieht technische Maßnahmen speziell für Zahlungssicherheit vor:

• Starke Kundenauthentifizierung (SCA): Zahlungen werden durch mindestens zwei unabhängige Authentifizierungsfaktoren geschützt. Typisch sind:
• Passwort oder PIN (etwas, das Sie wissen)
• SMS-Code, Authenticator-App oder Push-Benachrichtigung (etwas, das Sie haben)
• Biometrische Daten wie Fingerabdruck (etwas, das Sie sind)

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

• Transaktionsmonitoring: Verdächtige Transaktionen werden erkannt und gemeldet. Das erfordert Regeln wie:
• Transaktion größer als üblich (z.B. 10x des durchschnittlichen Betrags)?
• Transaktion in ein neues Land?
• Mehrere Transaktionen in kurzer Zeit?

Überlappung: Welche Maßnahmen erfüllen beide Anforderungen gleichzeitig?

Einige technische Maßnahmen erfüllen beide Regelwerke:

• Verschlüsselung: Schützt Kundendaten (DSGVO) und Zahlungsdaten (PSD2).
• Audit-Logs: Dokumentieren Datenzugriffe (DSGVO) und Zahlungstransaktionen (PSD2).
• Sichere APIs: Schützen Kundendaten (DSGVO) und Zahlungsfunktionen (PSD2).
• Authentifizierung: Kontrolliert Zugriff auf Kundendaten (DSGVO) und schützt Zahlungen (PSD2).

Bei der Implementierung sollten Sie diese Überlappungen nutzen: Eine gut gestaltete Authentifizierungs- und Verschlüsselungsinfrastruktur erfüllt oft beide Regelwerke.

Datenschutzfolgenabschätzung (DSFA) und Risikoanalyse

Wann ist eine DSFA sinnvoll?

Eine Datenschutzfolgenabschätzung (DSFA) ist ein Prozess, um Risiken bei der Verarbeitung personenbezogener Daten zu bewerten. Sie ist sinnvoll, wenn:

• Sie sensible Daten verarbeiten (z.B. Finanzdaten, Gesundheitsdaten, biometrische Daten).
• Sie Daten großflächig verarbeiten (z.B. von vielen Kunden).
• Sie neue Technologien einsetzen, deren Risiken unklar sind (z.B. KI-basierte Fraud-Detection).

Im Banking ist eine DSFA praktisch immer sinnvoll, weil Finanzdaten sensibel sind und Missbrauch erhebliche Schäden verursachen kann.

Checkliste: Welche Fragen Sie in einer DSFA beantworten sollten

Eine DSFA sollte folgende Fragen klären:

1. Welche Daten verarbeiten Sie? (z.B. Kontonummern, Transaktionshistorien, Namen)
2. Warum verarbeiten Sie diese Daten? (z.B. um Zahlungen auszulösen, um Budgets zu berechnen)
3. Wie lange speichern Sie die Daten? (z.B. 90 Tage, 3 Jahre)
4. Wer hat Zugriff auf die Daten? (z.B. Mitarbeiter, Partner, Banken)
5. Welche Risiken entstehen? (z.B. Datenverlust durch Hacker, unbefugter Zugriff durch Mitarbeiter)
6. Wie mindern Sie diese Risiken? (z.B. Verschlüsselung, Zugriffskontrolle, Audit-Logs)
7. Welche Rechte haben Betroffene? (z.B. Auskunft, Berichtigung, Löschung)

Beispiel: DSFA für einen Kontoinformationsdienst

Szenario: Sie entwickeln eine Budgetierungs-App (AIS), die monatlich Kontotransaktionen ausliest.

• Datenverarbeitung:
• Kontonummern, Transaktionsdaten (Datum, Betrag, Empfänger), Kundennamen.

• Risiken:
• Datenverlust durch Hacker: Kontonummern und Transaktionsdaten könnten gestohlen werden.
• Unbefugter Zugriff: Ein Mitarbeiter könnte Kundendaten einsehen.
• Datenleck bei API-Verbindung zur Bank: Transaktionsdaten könnten während der Übertragung abgefangen werden.

• Maßnahmen:
• Verschlüsselung aller Daten (AES-256 in der Datenbank, TLS 1.2+ in der API).
• Rollenbasierte Zugriffskontrolle: Nur der Datenbank-Administrator darf auf Kundendaten zugreifen.
• Audit-Logs: Alle Datenzugriffe werden protokolliert.
• Speicherfrist: Transaktionsdaten werden nach 90 Tagen automatisch gelöscht.
• Datenschutzrichtlinie: Kunden werden informiert, welche Daten gespeichert werden und wie lange.

Bei der Entwicklung von Banking-Apps mit sensiblen Daten fokussiere ich auf praktische Automation, Sicherheit und dokumentierte Übergabe – nicht auf Marketing-Versprechen. Eine DSFA ist kein Compliance-Häkchen zum Abhaken, sondern ein echtes Risiko-Management-Werkzeug, das Ihnen hilft, Probleme früh zu erkennen.

Häufige Fallstricke und Missverständnisse

Fallstrick 1: Annahme, dass DSGVO und PSD2 dasselbe sind

Das Problem: Viele Entwickler und Compliance-Teams verwenden die Begriffe synonym oder denken, dass die Einhaltung der einen Regelwerk automatisch die andere erfüllt.

Die Realität: DSGVO und PSD2 haben unterschiedliche Ziele und Anforderungen. DSGVO schützt Daten, PSD2 schützt Zahlungen. Eine Maßnahme kann beide erfüllen (z.B. Verschlüsselung), aber Sie müssen beide Regelwerke separat prüfen.

Praktischer Tipp: Erstellen Sie zwei separate Checklisten – eine für DSGVO, eine für PSD2 – und prüfen Sie beide.

Fallstrick 2: Unterschätzung des Aufwands für sichere APIs

Das Problem: Entwickler unterschätzen oft, wie komplex sichere API-Verbindungen zu Banken sind. Sie denken, dass ein einfaches HTTP-Request ausreicht.

Die Realität: Banken-APIs erfordern mTLS (gegenseitige TLS-Authentifizierung), OAuth 2.0 oder ähnliche Mechanismen. Das erfordert Zertifikatsverwaltung, Fehlerbehandlung und regelmäßige Sicherheitstests.

Praktischer Tipp: Kalkulieren Sie für sichere API-Integration mindestens 1–2 Wochen zusätzlich ein. Nutzen Sie etablierte Bibliotheken (z.B. für OAuth 2.0) statt eigene Implementierungen.

Fallstrick 3: Speicherfristen nicht automatisiert

Das Problem: Viele Systeme speichern Kundendaten unbegrenzt, weil die Löschung manuell erfolgt oder vergessen wird.

Die Realität: Speicherfristen erfordern TTL-Mechanismen (Time-To-Live) in der Datenbank oder automatisierte Lösch-Jobs.

Praktischer Tipp: Implementieren Sie Speicherfristen von Anfang an. Beispiel: PostgreSQL mit `pg_cron` für automatisierte Lösch-Jobs, oder Supabase mit automatisierten Funktionen.

Fallstrick 4: