Use Case · Finanzdienstleistungen
Geldwäscheprävention, Betrugserkennung & Kreditrisikobewertung—ohne Kundenidentität der KI preiszugeben
The Veil ermöglicht Finanzinstituten KI-gestützte Geldwäscheüberwachung, Betrugserkennung und Kreditrisikobewertung auf pseudonymisierten Token-Streams — das Modell sieht nie Kundennamen, Kontonummern oder andere personenbezogene Daten. Die Architektur richtet sich an den technischen Pseudonymisierungs- und Datenminimierungsanforderungen aus, die DSGVO, AMLD6, DORA und PSD2 stellen — architektonische Ausrichtung, keine vorliegende Zertifizierung unter einer dieser Regelungen.
Das Compliance-Dilemma bei Finanz-KI
Finanzregulierer fordern KI-gestützte Überwachung (AMLD6 Artikel 8 verlangt effektives Transaktions-Monitoring), während Datenschutzbehörden Datenminimierung verlangen (DSGVO Artikel 5(1)(c)). Rohe Kundendaten in ein KI-Modell einzuspeisen erzeugt einen Single-Point-of-Breach. Auf KI zu verzichten bedeutet, hinter den Erkennungsraten zurückzufallen, die Regulierer mittlerweile erwarten.
The Veil löst dieses Dilemma, indem Identität und analytische Nutzlast auf Architekturebene getrennt werden — nicht auf Richtlinienebene.
So funktioniert The Veil für Finanzdienstleistungen
| Phase | Was passiert | Wo |
|---|---|---|
| 1. Erfassung | Transaktionsdaten gelangen in Sandbox A. Kundennamen, Kontonummern und IBANs werden durch kryptographische Token ersetzt. | Sandbox A (PII) |
| 2. KI-Analyse | Pseudonymisierte Datenströme fließen an Sandbox B. Das KI-Modell bewertet Risiken, erkennt anomale Muster und flaggt potentiellen Betrug — ausschließlich auf Token-Basis, nie auf Identitäten. | Sandbox B (KI) |
| 3. Risiko-Output | Die KI liefert Risiko-Scores und Verhaltenscluster, zugeordnet zu Token. Zu keinem Zeitpunkt existieren personenbezogene Daten in Sandbox B. | Sandbox B (KI) |
| 4. Re-Linkage | Nur für Verdachtsmeldungen (SAR): Token werden in Sandbox A zurück mit der Kundenidentität verknüpft. Voraussetzung: Vier-Augen-Prinzip mit zwei autorisierten Compliance-Beauftragten. | Bridge (kontrolliert) |
Finanz-KI Use Cases
Geldwäscheprävention (AML Transaction Monitoring)
Die KI verarbeitet pseudonymisierte Transaktionsflüsse — Beträge, Timing-Muster, geographisches Routing, Gegenpartei-Token — um Strukturierung, Layering und Integration zu identifizieren. Das Modell erstellt Risikoprofile auf Token-Basis, nicht auf Personenbasis.
- Geschwindigkeits- und Volumenanalyse auf Token-Ebene
- Erkennung grenzüberschreitender Routing-Muster ohne Offenlegung des Wohnsitzlandes
- Netzwerkgraph-Analyse auf pseudonymisierten Gegenpartei-Beziehungen
Betrugserkennung mit pseudonymisierten Verhaltensmustern
Verhaltensbiometrie — Session-Timing, Interaktionskadenz, Geräte-Fingerprints — wird gehasht und tokenisiert, bevor das Betrugsmodell sie sieht. Die KI lernt: „Token-7a3f verhält sich anders als seine Baseline“, nie: „John Smith hat sich von einem ungewöhnlichen Gerät angemeldet.“
- Echtzeit-Anomalie-Scoring auf tokenisierten Session-Daten
- Geräte-Fingerprint-Matching ohne Speicherung roher Geräte-IDs in der KI-Sandbox
- PSD2 Strong Customer Authentication (Artikel 97) Signale werden als abstrakte Features verarbeitet
Kreditrisikobewertung ohne Identitätsexposition
Kreditmodelle erhalten Einkommensbereiche, Rückzahlungshistorien-Token und Auslastungsquoten — nie Kontoinhaber-Namen, Geburtsdaten oder Personalausweisnummern. Das Modell gibt eine Risikostufe aus, zugeordnet zu einem Token; das Kreditteam verknüpft nur bei genehmigten Kreditentscheidungen zurück.
- DSGVO Artikel 22 Compliance: automatisierte Entscheidungsfindung auf pseudonymisierten Eingaben
- Modell-Erklärbarkeits-Outputs referenzieren Feature-Kategorien, nicht persönliche Attribute
- Re-Linkage für Kreditangebotserstellung erfordert autorisierte Workflow-Genehmigung
Regulatorisches Ausrichtungs-Mapping
| Regulierung | Anforderung | The Veil Antwort |
|---|---|---|
| DSGVO Art. 5(1)(c) | Datenminimierung | KI-Sandbox empfängt ausschließlich pseudonymisierte Token — minimale Daten für den analytischen Zweck |
| DSGVO Art. 25 | Datenschutz durch Technikgestaltung | Architektonische Trennung erzwingt Pseudonymisierung vor der KI-Verarbeitung, nicht als nachträgliche Maßnahme |
| DSGVO Art. 22 | Rechte bei automatisierter Entscheidungsfindung | Re-Linkage für Kreditentscheidungen erfordert menschliche Genehmigung; Modelleingaben sind auditierbare Feature-Sets, keine Roh-PII |
| AMLD6 Art. 8 | Effektive Transaktionsüberwachungssysteme | KI-Monitoring operiert auf vollständigen Verhaltensdaten (Beträge, Timing, Routing) — nur die Identität wird entfernt |
| DORA Art. 6 | IKT-Risikomanagement-Framework | Sandbox-Isolierung begrenzt den Schadensradius; ein Breach der KI-Umgebung liefert keine kundenbezogenen Daten |
| PSD2 Art. 97 | Starke Kundenauthentifizierung | Authentifizierungssignale werden als abstrakte Feature-Vektoren in Sandbox B verarbeitet; rohe SCA-Daten verbleiben in Sandbox A |
Dies sind architektonische und evidenzschichtliche Ausrichtungen, keine gehaltenen Zertifizierungen. Zertifizierungs-Roadmap auf Anfrage verfügbar.
Breach-Szenario: Was ein Angreifer erhält
Wenn ein Angreifer die KI-Sandbox (Sandbox B) kompromittiert, erhält er:
- Risiko-Scores, zugeordnet zu bedeutungslosen kryptographischen Token
- Verhaltensmuster-Cluster ohne Verbindung zu realen Identitäten
- Transaktionsflussgraphen, in denen jeder Knoten ein Token ist — keine Person, kein Unternehmen
Keine Kundennamen. Keine Kontonummern. Keine IBANs. Das Token-zu-Identität-Mapping existiert ausschließlich in Sandbox A, die der Angreifer nicht erreicht hat.
Kernaussagen für CISOs im Finanzsektor
- The Veil erfüllt gleichzeitig AML-Überwachungsanforderungen und DSGVO-Datenminimierung — auf Architekturebene, nicht auf Richtlinienebene
- Vier-Augen-Re-Linkage für Verdachtsmeldungen schafft einen auditierbaren, regulierungskonformen Workflow
- DORA-Anforderungen an die operationelle Resilienz werden durch Sandbox-Isolierung und begrenzten Schadensradius adressiert
- Kreditrisikomodelle, die nie PII sehen, reduzieren das Risiko automatisierter Entscheidungsfindung nach DSGVO Artikel 22