Die regulatorische Karte, die jeder Fintech-Data-Leader dabeihaben muss

# Die regulatorische Karte, die jeder Fintech-Data-Leader dabeihaben muss

Ein einzelner Kundendatensatz, etwa Maria in Berlin, die eine Neobank mit US-Hauptsitz und einem britischen Payment-Partner nutzt, kann in dem Moment, in dem sie bei einer Transaktion auf „bestätigen“ tippt, gleichzeitig Pflichten aus vier oder fünf sich überlagernden Datengesetzen auslösen. Ihr Name, ihre IBAN, ihre Ausgabenhistorie und ihr Device-Fingerprint fallen jeweils unter andere Jurisdiktionen, andere Consent-Regeln und andere Löschfristen. Das ist kein Sonderfall. Das ist die Standardarchitektur des modernen Fintech.

Diese Lektion liefert Ihnen die Karte: die zentralen Regulierungen, ihre Konfliktpunkte und die praktischen Checks, mit denen Sie ein Audit überstehen, ohne Ihre Produkt-Roadmap einzufrieren.

Die fünf Regime, die Sie aus dem Stand kennen müssen

DSGVO (Datenschutz-Grundverordnung), EU-Recht, wirksam seit 2018, gilt für alle personenbezogenen Daten von EU-Bürgern, unabhängig davon, wo Ihr Unternehmen sitzt. Kernmechanik: Rechtsgrundlage für die Verarbeitung, Recht auf Löschung („Recht auf Vergessenwerden“), Datenportabilität und verpflichtende Meldung von Datenschutzverletzungen an Aufsichtsbehörden innerhalb von 72 Stunden. Durchgesetzt von nationalen Datenschutzbehörden (DPAs), locker koordiniert über den Europäischen Datenschutzausschuss.

PSD2 (überarbeitete Zahlungsdiensterichtlinie), EU-Richtlinie von 2018, schreibt Open Banking vor: Banken müssen Kontodaten von Kunden über APIs für lizenzierte Dritte zugänglich machen, sofern der Kunde zustimmt. Sie hat die Rechtsgrundlage für Account-Aggregatoren wie Tink (von Visa übernommen) und Plaids Europageschäft geschaffen. PSD2 schreibt außerdem Strong Customer Authentication (SCA) vor, also Zwei-Faktor-Verifizierung bei den meisten Online-Zahlungen.

GLBA (Gramm-Leach-Bliley Act), US-Bundesgesetz von 1999, verlangt von Finanzinstituten, ihre Praxis der Datenweitergabe zu erläutern und nicht öffentliche personenbezogene Informationen (NPI) zu schützen. Durchgesetzt von der FTC und den Bankenaufsichtsbehörden (OCC, Federal Reserve, FDIC). GLBA ist notice-based, nicht consent-based: Institute kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen Daten standardmäßig mit verbundenen Unternehmen teilen, solange der Kunde nicht widerspricht.

CCPA / CPRA (California Consumer Privacy Act, geändert durch den California Privacy Rights Act), wirksam seit 2020 bzw. 2023, gibt Einwohnern Kaliforniens Rechte auf Auskunft, Löschung und Opt-out beim „Verkauf oder Teilen“ personenbezogener Daten. Durchgesetzt von der California Privacy Protection Agency (CPPA). Bemerkenswert: GLBA-regulierte Daten sind vom CCPA weitgehend ausgenommen, eine Ausnahme, über die Compliance-Teams stolpern, die US-Datenschutzrecht für einheitlich halten.

Open-Banking-Regeln außerhalb der EU: Das UK betreibt nach dem Brexit über die Open Banking Implementation Entity ein eigenes Regime, und die USA haben sich von freiwilligen Frameworks hin zu einem verbindlichen Regime nach Section 1033 des Dodd-Frank Act bewegt, wobei das Consumer Financial Protection Bureau (CFPB) ab 2024 Regeln zum Datenzugang für Verbraucher finalisiert. Geltungsbereich und Durchsetzungszeitpläne unterscheiden sich weiterhin deutlich vom PSD2/PSD3-Pfad der EU.

Wo sie an einem Datensatz kollidieren

Zurück zu Maria. So sieht die Kollisionskarte für ihren einen Transaktionsdatensatz aus:

• Unterschiedliche Consent-Modelle: Die DSGVO verlangt für die meisten Verarbeitungen eine aktive Opt-in-Einwilligung. GLBA arbeitet standardmäßig mit Opt-out. Wenn Ihre Plattform US- und EU-Kunden aus einer Data-PipelinePipelineAlle aktiven Verkaufschancen über die Phasen des Vertriebsprozesses hinweg, zusammen mit ihrem gesamten potenziellen Wert und ihrer Abschlusswahrscheinlichkeit.Vollständige Definition ansehen → bedient, kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen Sie nicht mit einem einzigen Consent-Flag arbeiten. Sie brauchen einen jurisdiktionsbewussten Consent-Status pro Datensatz.

• Löschkonflikte: Das Recht auf Löschung der DSGVO heißt: auf Anfrage löschen. Aber die Aufbewahrungspflichten im Finanzbereich (in der EU die Anti-Geldwäsche-Richtlinien, in den USA die vom FinCEN durchgesetzten Anforderungen des Bank Secrecy Act) schreiben vor, Transaktionsdaten fünf bis sieben Jahre aufzubewahren. Ihre Datenarchitektur muss „Soft Delete mit Legal Hold“ unterstützen, nicht echtes Löschen, und Sie müssen diesen Unterschied einer Aufsichtsbehörde oder einem wütenden Kunden erklären kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen.

• Zugriff Dritter unter Open Banking: PSD2 verpflichtet Sie, Marias Kontodaten jedem lizenzierten Third-Party-Provider (TPP) zugänglich zu machen, den sie autorisiert. Die DSGVO macht Sie trotzdem zum Verantwortlichen für das, was danach mit diesen Daten passiert. Wenn der TPP unsauber damit umgeht, kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen Aufsichtsbehörden weiterhin Sie für die ursprüngliche Offenlegung und das Consent-Design in den Blick nehmen.

• Grenzüberschreitende Übermittlung: Wenn Marias Daten eine US-Cloud-Region berühren (bei globalen Architekturen mit AWS, GCP, Azure üblich), greifen die DSGVO-Regeln zur internationalen Datenübermittlung. Nach dem *Schrems II*-Urteil (2020, Gerichtshof der EU) sind Standardvertragsklauseln und seit 2023 das EU-US Data Privacy Framework die wichtigsten Rechtsmechanismen. Machen Sie hier einen Fehler, und Ihr gesamter in den USA gehosteter Analytics-Stack ist ein Haftungsrisiko. Referenz: der Überblick der Europäischen Kommission zum Data Privacy Framework.

Die Architektur-Tradeoffs, die daraus folgen

Weil diese Regeln nicht harmonisiert sind, treffen Data Leader bewusste Architekturentscheidungen:

1. Partitionierung nach Datenresidenz: Viele Fintechs betreiben EU-Kundendaten in Cloud-Infrastruktur in EU-Regionen (Datenlokalisierung), auch wenn das technisch nicht immer zwingend ist, einfach um das Risiko aus Übermittlungsmechanismen und die Audit-Komplexität zu senken.

2. Consent als First-Class-Datenobjekt: Der Consent-Status (wer, welcher Zweck, welche Jurisdiktion, Zeitstempel, akzeptierte Policy-Version) wird als eigene auditierbare Tabelle modelliert, nicht als Boolean-Flag irgendwo im Nutzerprofil.

3. Governance auf Feld-, nicht auf Tabellenebene: NPI nach GLBA, besondere Kategorien personenbezogener Daten nach DSGVO (dazu gehören etwa biometrische Identifikatoren) und die Kategorie „sensitive personal information“ des CCPA entsprechen keinen identischen Feldlisten. Das Tagging muss auf Spalten- oder Feldebene erfolgen, mit angehängten Jurisdiktions-Metadaten.

Ein vereinfachtes SchemaSchemaEin Schema ist der formale Bauplan, der festlegt, wie Daten in einer Datenbank, einer Datei oder einer Nachricht strukturiert, benannt, typisiert und miteinander verknüpft sind.Vollständige Definition ansehen →, wie das in der Praxis aussieht:

-- consent_ledger: eine Zeile pro Consent-Ereignis, nicht pro Nutzer
CREATE TABLE consent_ledger (
    consent_id UUID PRIMARY KEY,
    customer_id UUID NOT NULL,
    jurisdiction VARCHAR(10) NOT NULL,   -- 'EU', 'US-CA', 'US-FED', 'UK'
    legal_basis VARCHAR(50) NOT NULL,    -- 'GDPR_ART6_1A', 'GLBA_OPT_OUT', 'CCPA_OPT_OUT'
    purpose VARCHAR(100) NOT NULL,       -- 'MARKETING', 'OPEN_BANKING_SHARE'
    granted_at TIMESTAMP,
    revoked_at TIMESTAMP,
    policy_version VARCHAR(20)
);

Das ist keine Dekoration. Prüfer und Aufsichtsbehörden werden fragen: „Zeigen Sie mir die Einwilligung für genau diesen Verarbeitungszweck, zu diesem Datum, für diesen Kunden.“ Wenn diese Abfrage einen Data Engineer drei Tage Log-Archäologie kostet, haben Sie ein Governance-Problem.

Die praktischen Checks

Sektorkompetenz heißt zu wissen, wie ein echtes Audit oder ein interner Kontrollzyklus aussieht, nicht nur die Gesetze benennen zu kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen.

Quartalsweises Data-Mapping-Audit: Führen Sie ein lebendes Verzeichnis von Verarbeitungstätigkeiten (Record of Processing Activities, ROPA), ein von der DSGVO vorgeschriebenes Inventar darüber, welche personenbezogenen Daten Sie halten, warum, wo sie gespeichert sind und wer darauf zugreifen kann. Die meisten reifen Fintechs automatisieren das mit Data-Catalog-Tools (z. B. Collibra, Alation) statt mit Spreadsheets.

Review der Zugriffsrechte: Prüfen Sie Least-Privilege-Zugriff auf NPI und besondere Kategorien von Daten. Ein häufiger Audit-Befund: Support-Mitarbeiter mit breitem SQLSQLSales Qualified Lead: ein Prospect, den das Sales-Team als bereit für direkte Ansprache und ein Angebot validiert hat, weil er klare Qualifizierungskriterien erfüllt.Vollständige Definition ansehen →-Zugriff auf Produktionstabellen, die sie für ihre Rolle nicht brauchen.

Breach-Simulation / Incident-Response-Übung: Die 72-Stunden-Frist der DSGVO beginnt mit der Kenntnisnahme, nicht mit der Bestätigung. Führen Sie Tabletop-Übungen durch, um zu prüfen, ob Ihr Team eine Meldung in diesem Zeitfenster tatsächlich erkennen, eingrenzen und entwerfen kann.

Risiko-Review für Drittanbieter-APIs: Prüfen Sie nach PSD2 und den CFPB-Open-Banking-Regeln, welche TPPs aktive Access TokensTokensEin Token ist die grundlegende Texteinheit, die Sprachmodelle verarbeiten, oft ein Wortfragment, ein ganzes Wort oder ein Satzzeichen und nicht ein einzelnes Zeichen.Vollständige Definition ansehen → haben, wann Consent abläuft und ob ein Widerruf tatsächlich durch Ihre Systeme propagiert, nicht nur durch Ihre Datenbank.

Inventar grenzüberschreitender Übermittlungen: Listen Sie jedes System auf, in dem personenbezogene EU-Daten die EU-Infrastruktur verlassen, und bestätigen Sie, dass der rechtliche Übermittlungsmechanismus aktuell ist (das EU-US-Framework hat rechtliche Angriffe bislang überstanden, bleibt aber angreifbar).

Für einen Überblick aus Aufsichtsperspektive über Durchsetzungsmuster ist die Enforcement-Datenbank des ICO (UK Information Commissioner's Office) eine wirklich brauchbare, kostenlose Quelle echter Fälle, nützlich zum Mustererkennen bei dem, was tatsächlich mit Bußgeldern belegt wird.

Key Takeaways

• Kein einziges globales Datenschutz-Framework regelt Fintech-Daten. DSGVO, PSD2, GLBA und CCPA/CPRA folgen unterschiedlichen Logiken (Consent vs. Notice, Löschung vs. Aufbewahrung), und ein einzelner Kundendatensatz kann allen vier gleichzeitig unterliegen.
• Löschanfragen nach DSGVO müssen mit den Aufbewahrungspflichten im Finanzbereich (AML, Bank Secrecy Act) in Einklang gebracht werden; die praktische Antwort ist Soft Delete mit Legal Hold, nicht echtes Löschen.
• Consent sollte als auditierbares, mit Jurisdiktion getaggtes Datenobjekt modelliert werden, nicht als einzelnes Flag, denn Aufsichtsbehörden verlangen zweckbezogene, zeitgestempelte Nachweise.
• Grenzüberschreitende Datenübermittlungen (besonders von der EU in US-Cloud-Infrastruktur) brauchen einen aktiven Rechtsmechanismus (SCCs oder das EU-US Data Privacy Framework), der nachgehalten und periodisch erneut verifiziert werden muss.
• Führen Sie wiederkehrende, konkrete Checks durch: ROPA-Data-Mapping, Reviews der Zugriffsrechte, Breach-Übungen und TPP-Zugriffsaudits, denn genau das prüfen echte Examiner und DPAs zuerst.