Fintech-Daten steuern: Consent, Lineage und regulatorische Nachweisfähigkeit

# Fintech-Daten steuern: Consent, Lineage und regulatorische Nachweisfähigkeit

Die Montagmorgen-E-Mail, die niemand will

Ihr Compliance-Team leitet ein Schreiben einer Aufsichtsbehörde weiter. Darin steht eine trügerisch einfache Frage: „Zeigen Sie uns für das Kundenkonto mit der Endziffer 4471 jede Stelle, an der die Daten verwendet wurden, wer worin eingewilligt hat und wann. Sie haben 30 Tage.“

Jetzt die Panik. Die Daten dieses Kunden liegen in Ihrem Onboarding-System, in Ihrem Fraud-Modell, in einem Marketing-Warehouse, in zwei Vendor-APIs und in einem Backup, dessen Existenz Sie vergessen hatten. Die Einwilligung von 2023 galt für „Kontoservices“. Ihr Fraud-Modell wurde letzten Monat auf der Transaktionshistorie dieses Kunden neu trainiert. 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 belegen, dass ererDas Verhältnis von Interaktionen (Likes, Kommentare, Shares) zur Reichweite eines Inhalts. Zeigt, wie stark die Zielgruppe reagiert, gemessen an der Zahl der Personen, die den Inhalt gesehen haben.Vollständige Definition ansehen → dem zugestimmt hat?

In dieser Lektion geht es darum, Systeme so zu bauen, dass diese E-Mail eine Routineabfrage auslöst und keine Feuerwehrübung.

Die drei regulatorischen Druckpunkte, klar benannt

Data GovernanceData GovernanceData Governance umfasst die Regeln, Rollen und Prozesse, die sicherstellen, dass Daten in einer Organisation korrekt, sicher, klar definiert und verantwortungsvoll genutzt werden.Vollständige Definition ansehen → im Fintech unterliegt sich überschneidenden Regeln. Drei sind am wichtigsten.

DSGVO (Datenschutz-Grundverordnung): das EU-Datenschutzrecht. Sie gibt Personen Rechte an ihren personenbezogenen Daten, darunter das Recht zu erfahren, wie sie verwendet werden, sie löschen zu lassen und die Einwilligung zu widerrufen. Sie gilt für jeden, der EU-Bürger bedient, unabhängig vom Sitz des Unternehmens.

GLBA (Gramm-Leach-Bliley Act): ein US-Gesetz, das Finanzinstitute verpflichtet, Finanzdaten von Kunden zu schützen und ihre Praktiken zur Datenweitergabe offenzulegen. Also Datenschutz plus verpflichtende Offenlegung, mit wem Sie Daten teilen.

Open-Banking-Vorgaben: Regeln (wie PSD2 in der EU und der Open-Banking-Standard in Großbritannien), die Banken verpflichten, Kundendaten mit Dritten zu teilen, aber nur mit ausdrücklicher Zustimmung des Kunden. In den USA treibt die Section-1033-Regel der CFPB ähnliche Rechte zur Datenportabilität voran.

Der Widerspruch liegt auf der Hand. Open Banking sagt „teilt die Daten“. DSGVO und GLBA sagen „schützt sie und weist die Einwilligung nach“. Sie brauchen eine Architektur, die beides gleichzeitig leistet.

Consent: das Fundament, auf dem alles steht

Consent ist keine Checkbox. Im regulierten Fintech ist Consent ein Record mit Struktur: wer hat zugestimmt, zu welchem konkreten Zweck, wann, über welchen Kanal und für wie lange.

Der typische Fehler ist, Consent als ein großes Ja zu behandeln. Wer „Kontoservices“ zugestimmt hat, hat nicht zugestimmt, dass seine Ausgabemuster in ein Kreditrisikomodell fließen, das an einen Partner verkauft wird. Regulatoren nennen das Zweckbindung: Daten, die zu einem Zweck erhoben wurden, dürfen nicht stillschweigend für einen anderen wiederverwendet werden.

Consent als zweckbezogene Grants modellieren

Speichern Sie Consent als granulare, maschinenlesbare Records, die an konkrete Zwecke gebunden sind.

{
  "customer_id": "cust_4471",
  "purpose": "fraud_detection",
  "scope": ["transaction_history", "device_id"],
  "granted_at": "2026-02-10T14:22:00Z",
  "channel": "mobile_app_v3",
  "expires_at": "2027-02-10T14:22:00Z",
  "legal_basis": "consent",
  "withdrawn_at": null
}

Beachten Sie legal_basis. Nach DSGVO braucht nicht alles eine Einwilligung. Betrugsprävention läuft oft über „berechtigtes Interesse“ oder eine rechtliche Verpflichtung. Marketing braucht ausdrückliche Einwilligung. Ihr System muss festhalten, welche Rechtsgrundlage gilt, denn davon hängt ab, ob ein Kunde sie widerrufen kann.

Die praktische Regel: Jede Data Pipeline sollte vor der Verarbeitung prüfen, ob ein gültiger Purpose Grant vorliegt. Zieht ein Marketing-Job einen Record, dessen Consent abgelaufen oder widerrufen wurde, muss der Job verweigern.

Lineage: nachweisen, wohin Daten gegangen sind

Data LineageData LineageData Lineage zeigt, wie Daten sich durch Systeme bewegen und dabei transformiert werden, von der Quelle bis zur Nutzung: woher sie kommen, was sie verändert hat und wohin sie gehen.Vollständige Definition ansehen → ist die dokumentierte Spur, woher Daten kamen, wie sie transformiert wurden und wohin sie geflossen sind. Wenn Consent die Erlaubnis ist, ist Lineage der Audit Trail, der belegt, dass Sie sie eingehalten haben.

Im Fintech muss Lineage etwas Zusätzliches abdecken: Model Lineage. Wenn ein Machine-Learning-Modell eine Kredit- oder Betrugsentscheidung trifft, wollen Regulatoren zunehmend wissen, welche Daten es trainiert haben und welche Daten für die Entscheidung genutzt wurden.

Was Model Lineage erfassen muss

Stellen Sie sich vor, Ihr Fraud-Modell lehnt eine Transaktion ab. Eine Aufsichtsbehörde oder der Kunde fragt, warum. Sie müssen beantworten:

• Welche Modellversion die Entscheidung getroffen hat (Modelle ändern sich ständig).
• Welche Input-Features verwendet wurden.
• Welcher Trainingsdatensatz diese Modellversion erzeugt hat.
• Ob jeder Record in diesem Trainingsset eine gültige Rechtsgrundlage hatte.

Am letzten Punkt scheitern die meisten Firmen. Ein Modell, das auf Daten trainiert wurde, die Records mit widerrufener Einwilligung enthielten, ist ein Compliance-Risiko, auch wenn das Modell gute Ergebnisse liefert.

Ein praktikables Lineage-Muster

Taggen Sie Daten bei der Ingestion mit einem unveränderlichen Identifier und führen Sie dieses Tag durch jede Transformation mit. Tools des modernen Data Stack (dbt für Transformationen, OpenLineage für standardisierte Lineage-Events und Data Catalogs wie DataHub) machen das machbar, ohne alles selbst zu bauen.

Das OpenLineage-Projekt ist ein kostenloser, offener Standard zum Erfassen von Lineage über Pipelines hinweg und eine gute Referenz dafür, wie diese Events strukturiert sind.

Aufbewahrung: Daten genau so lange halten wie erlaubt

Hier die Falle. Die DSGVO sagt: personenbezogene Daten nicht länger aufbewahren als nötig. GLBA und Anti-Geldwäsche-Regeln (AML) verlangen jedoch, bestimmte Finanzunterlagen jahrelang aufzubewahren (üblicherweise fünf Jahre oder mehr für Transaktions- und Identitätsprüfungsdaten, wobei die genauen Fristen je nach Jurisdiktion variieren).

Ein Gesetz sagt also löschen, ein anderes behalten. Das aufzulösen ist eine Governance-Aufgabe, keine technische.

Aufbewahrung nach Zweck, nicht nach Tabelle

Knüpfen Sie Aufbewahrungsregeln an den Zweck, nicht an den Speicherort.

• Transaktionsdaten für AML: gemäß dem geltenden regulatorischen Minimum aufbewahren, dann löschen.
• Marketing-Engagement-Daten: löschen, wenn die Einwilligung widerrufen wird oder nach einem definierten Inaktivitätsfenster.
• Snapshots von Modelltrainings: nur so lange aufbewahren, wie nötig, um eine Entscheidung für ein Audit reproduzieren 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, danach personenbezogene Identifier entfernen.

Eine gängige Technik ist Pseudonymisierung: direkte Identifier (Name, Kontonummer) werden durch ein TokenTokenEin 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 → ersetzt, sodass ein Trainings-Snapshot für Audit und Modellreproduktion nutzbar bleibt, das Risiko aber sinkt. Die DSGVO behandelt pseudonymisierte Daten günstiger als rohe personenbezogene Daten, reguliert sie aber weiterhin.

„Recht auf Vergessenwerden“ versus Backup-Problem

Wenn ein Kunde die Löschung nach DSGVO verlangt, müssen Sie seine personenbezogenen Daten löschen, dürfen aber Unterlagen rechtmäßig behalten, zu deren Aufbewahrung Sie gesetzlich verpflichtet sind (etwa AML-Transaktionsprotokolle). Der nachweisbare Weg: alles löschen, was nicht unter einem Legal Hold steht, dokumentieren, was Sie behalten haben und warum, und das Löschbegehren selbst festhalten.

Backups sind der stille Verstoß. Wenn Sie ein sechs Monate altes Backup einspielen, holen Sie womöglich einen gelöschten Kunden zurück. Reife Programme führen ein Deletion Log, das Löschungen nach jedem Restore erneut anwendet.

Alles zusammen: die Antwort an die Aufsicht

Zurück zu dieser Montagsmail. Mit der beschriebenen Architektur wird aus der 30-Tage-Hektik eine Abfrage.

Schritt 1: Consent-Ledger abrufen. Für Kunde 4471 alle Purpose Grants, deren Rechtsgrundlage, Zeitstempel und etwaige Widerrufe abrufen. Das zeigt genau, wozu und wann ererDas Verhältnis von Interaktionen (Likes, Kommentare, Shares) zur Reichweite eines Inhalts. Zeigt, wie stark die Zielgruppe reagiert, gemessen an der Zahl der Personen, die den Inhalt gesehen haben.Vollständige Definition ansehen → zugestimmt hat.

Schritt 2: Lineage-Trace ausführen. Über das unveränderliche Daten-Tag des Kunden jede PipelinePipelineAlle aktiven Verkaufschancen über die Phasen des Vertriebsprozesses hinweg, zusammen mit ihrem gesamten potenziellen Wert und ihrer Abschlusswahrscheinlichkeit.Vollständige Definition ansehen →, jedes Warehouse und jedes Modell auflisten, das seine Records berührt hat. Jede Nutzung gegen einen passenden gültigen Purpose Grant abgleichen.

Schritt 3: Aufbewahrungskonformität zeigen. Nachweisen, dass Daten jenseits ihres Aufbewahrungsfensters gelöscht wurden und dass alles Aufbewahrte unter einer dokumentierten Rechtsgrundlage steht (etwa AML).

Schritt 4: Modellverantwortung zeigen. Für jede automatisierte Entscheidung, die den Kunden betrifft, die Modellversion und ihre Inputs benennen und bestätigen, dass die Trainingsdaten gültige Rechtsgrundlagen hatten.

Das ist regulatorische Nachweisfähigkeit: compliant sein und es schnell, mit Belegen und auf Anforderung *beweisen* 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.

Die organisatorische Realität

Nichts davon funktioniert als reines Technologieprojekt. Es braucht einen Data-Governance-Verantwortlichen (oft ein Chief Data Officer oder Datenschutzbeauftragter), der Zwecke definiert, neue Datennutzungen genehmigt und Aufbewahrungsfristen freigibt. Engineering baut die Leitungen; Governance entscheidet die Regeln, die die Leitungen durchsetzen.

Firmen, die Anfragen von Aufsichtsbehörden gelassen abarbeiten, haben eines gemeinsam: Sie haben ihre Governance-Regeln festgelegt, *bevor* sie Pipelines gebaut haben, sodass Consent-Prüfungen und Lineage-Tagging eingebaut und nicht nachträglich angeflanscht wurden.

Wichtigste Erkenntnisse

• Consent ist ein strukturierter, zweckbezogener Record, keine Checkbox. Halten Sie fest, wer zugestimmt hat, zu welchem konkreten Zweck, wann und unter welcher Rechtsgrundlage, und lassen Sie Pipelines vor der Verarbeitung einen gültigen Grant prüfen.

• Lineage muss bis zu den Modellen reichen. Sie müssen jede automatisierte Entscheidung auf ihre Modellversion, ihre Input-Features und die Rechtsgrundlage ihrer Trainingsdaten zurückführen 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.

• Knüpfen Sie Aufbewahrungsregeln an den Zweck, nicht an den Speicher. So erfüllen Sie das „löschen, wenn erledigt“ der DSGVO und halten zugleich die Mindestaufbewahrung nach AML und GLBA für denselben Kunden ein.

• Backups und Löschung kollidieren; planen Sie dafür. Führen Sie ein Deletion Log, das Löschungen nach jedem Restore erneut anwendet, sonst holen Sie vergessene Kunden unbemerkt zurück.

• Nachweisfähigkeit ist Tempo plus Belege. Bauen Sie so, dass eine Anfrage der Aufsicht zu einer Abfrage über Ihren Consent-Ledger und Ihren Lineage-Graph wird und nicht zu einer 30-tägigen Feuerwehrübung.