Perpetual KYC ersetzt die kalendergesteuerte Prüfung durch eine ereignisgetriebene. Statt jeden Kunden in einem Ein-, Drei- oder Fünf-Jahres-Zyklus zu aktualisieren, beobachten Sie einen Strom von Signalen zu jedem Kunden und öffnen nur dann eine Prüfung, wenn sich etwas Wesentliches ändert. Die Uhr existiert weiterhin als Long-Stop, doch der Großteil der Arbeit wird jetzt durch Evidenz ausgelöst und nicht durch ein Datum.
Die periodische Prüfung ist aus einem einfachen Grund eine Backlog-Maschine: Sie plant Aufwand entlang der Zeit statt entlang des Risikos. Ein Kunde, der seit achtzehn Monaten keine Transaktion getätigt hat und dessen Daten unverändert sind, bekommt denselben Prüftermin wie einer, der gerade einen neuen wirtschaftlich Berechtigten in einer sanktionierten Jurisdiktion registriert hat. Die Warteschlange füllt sich mit Ersterem, und die Analysten, die sich eigentlich Letzterem widmen sollten, verbringen ihren Tag damit, kalendergetriebene Tickets abzuarbeiten, die meist mit „keine Änderung” enden. Das Quartalsende macht es schlimmer, denn die Aktualisierungstermine ballen sich, und der Backlog schnellt genau dann in die Höhe, wenn der Rest der Financial-Crime-Operations ohnehin ausgelastet ist.
Was tatsächlich als Ereignis zählt
Das gesamte Modell hängt davon ab, das Trigger-Set sauber zu definieren, und genau hier sind die meisten Implementierungen entweder zu grob oder zu verrauscht. Ein Ereignis ist eine Veränderung in der Welt, die die Risikoeinstufung eines Kunden verschieben könnte. Es stammt aus einigen wenigen Quellen:
- Internes Verhalten: ein sprunghafter Anstieg von Transaktionsvolumen oder -wert, eine neue Kontrahenten-Geografie, ein Produkt-Upgrade, ein aus dem Ruhezustand erwachtes Konto, eine Änderung des Zahlungskorridors.
- Änderungen an Stammdaten: eine neue Adresse, ein Wechsel bei Geschäftsführung oder Anteilseignern eines Firmenkunden, eine aktualisierte Struktur der wirtschaftlich Berechtigten, ein abgelaufenes Ausweisdokument.
- Externe Signale: ein Update einer Sanktionsliste, das nun auf eine Entität passt, ein Adverse-Media-Treffer, eine Änderung des Risikoscores einer Jurisdiktion, in der der Kunde tätig ist, Klagen oder Insolvenzanträge.
Jede dieser Quellen braucht ein Quellsystem, ein Schema und eine definierte Latenz. Ein Sanktions-Delta sollte die Trigger-Engine innerhalb von Stunden erreichen, ein Media-Treffer verträgt einen Tag. Die Engineering-Arbeit besteht überwiegend aus Plumbing und Entity Resolution: Das Transaktionssystem, das CRM, der Screening-Anbieter und das Handelsregister identifizieren denselben Kunden jeweils unterschiedlich, und ein Trigger ist wertlos, wenn er sich nicht mit Gewissheit auf einen einzigen Kundendatensatz zurückführen lässt. Wir behandeln Entity Resolution hier als Fundament, nicht als Nachgedanken, denn eine falsche Verknüpfung führt entweder zu einer verpassten Prüfung oder zu einer Prüfung, die auf der falschen Partei eröffnet wird.
Eine Regel, an der wir festhalten: Jeder Trigger trägt seine Evidenz mit sich. Das Ereignis hält Details fest. „Wirtschaftlich Berechtigter X wurde an diesem Datum hinzugefügt, aus dieser Registereintragung, passend zu diesem Datensatz” ist ein Trigger, auf den ein Prüfer handeln kann. „Das Risiko hat sich möglicherweise verändert” ist es nicht. Niemand sollte erst herausfinden müssen, warum das Ticket überhaupt existiert.
Point-in-Time-Korrektheit und der Audit-Trail
Perpetual KYC steht und fällt mit der Fähigkeit, rekonstruieren zu können, was Sie wann wussten. Eine Aufsichtsbehörde, die 2028 nach einem Kunden fragt, will den Zustand der Kundenakte so sehen, wie er am Tag der Entscheidung war, nicht so, wie er heute ist. Das ist ein Problem der Point-in-Time-Korrektheit, und es ist leicht falsch zu machen, wenn der Kundendatensatz eine einzige veränderliche Zeile ist, die bei jedem Update überschrieben wird.
Wir modellieren die Kundenakte als append-only History. Jedes Attribut hat ein Valid-from und, wo relevant, ein Valid-to. Eine Risikoeinstufung wird als Folge bewerteter Intervalle gespeichert, von denen jedes die Evidenz und die Entscheidung trägt, die es hervorgebracht haben, statt als ein einzelnes Feld, das überschrieben wird. Das verschafft Ihnen einiges, was die periodische Prüfung nie hatte:
- Sie können die Frage „Welche Einstufung hatte dieser Kunde am Tag jener Transaktion?” beantworten, ohne zu raten.
- Sie können Eval-Sets aus echter Historie aufbauen, indem Sie die Trigger-Engine gegen vergangene Ereignisse abspielen, um zu prüfen, ob sie ausgelöst hätte, wann sie es sollte.
- Sie vermeiden Lookahead: Wenn Sie eine Änderung der Risikoeinstufung testen, speisen Sie das Modell nur mit den Daten, die zum Trigger-Zeitpunkt existierten, nicht mit später hinzugefügten Attributen.
Lineage zählt ebenso viel wie Historie. Jede Risikoentscheidung sollte über den Trigger, die Evidenz und das Quellsystem zurückverfolgbar sein, damit ein Prüfer oder die interne Revision die Kette nachvollziehen kann, ohne sie aus Logs zu rekonstruieren. Wenn wir den Feature Store bauen, der ein Risikomodell speist, trägt jedes Feature den As-of-Timestamp der Daten, aus denen es berechnet wurde. Die Abstimmung gegen die Source of Truth läuft nach Zeitplan, denn ein Feature Store, der still vom Transaktions-Ledger abdriftet, erzeugt Einstufungen, die Sie nicht verteidigen können.
Automatisierung mit einem menschlichen Pfad für echte Veränderungen
Der Sinn des Ganzen ist Straight-Through Processing für den Regelfall und menschliche Aufmerksamkeit für den seltenen. Die meisten Trigger lösen sich ohne Person: ein abgelaufenes Dokument, das der Kunde neu hochlädt, ein Volumenanstieg, der einem bekannten saisonalen Muster entspricht, ein Media-Treffer, bei dem die Entity Resolution zeigt, dass er sich auf eine andere Person mit ähnlichem Namen bezieht. Diese schließen sich automatisch, mit protokollierter Begründung.
Die Entscheidungen, die wir an einen Menschen weiterleiten, sind jene mit echten Konsequenzen. Ein Downgrade der Risikoeinstufung geht, wie erwähnt, immer an einen Prüfer. Ebenso jede Änderung, die einen Kunden über eine regulatorische Grenze bewegen würde, etwa in die verschärfte Sorgfaltspflicht (Enhanced Due Diligence) hinein oder aus ihr heraus. Ebenso ein Trigger, bei dem das Modell nicht sicher ist, ihn korrekt aufgelöst zu haben, weshalb jede automatisierte Entscheidung einen Kalibrierungsscore ausgibt statt eines nackten Ja oder Nein.
Sie steuern die Prüf-Warteschlange über ein False-Positive-Budget, genau wie beim Transaction Monitoring. Wenn das Trigger-Set mehr menschliche Prüfungen erzeugt, als das Team abarbeiten kann, funktioniert es nicht, und die Antwort lautet, die Trigger-Definitionen zu schärfen und die Entity Resolution zu verbessern, statt blind Schwellenwerte anzuheben. Wir tunen gegen ein zurückgehaltenes Set vergangener Fälle, bei denen das korrekte Ergebnis bekannt ist, und achten auf Drift: ein Korridor, der letztes Jahr risikoarm war, eine Medienquelle, deren Trefferquote sich verändert hat, ein Modell, dessen Konfidenz nachgelassen hat, weil sich der Kundenstamm verschoben hat. Wenn sich die Zahlen bewegen, wird das Trigger-Set erneut überarbeitet. Perpetual KYC endet nie. Wie jede andere Kontrolle muss es gepflegt werden.
Häufige Fragen
Worin unterscheidet sich Perpetual KYC von einem kürzeren periodischen Prüfzyklus?
Eine periodische Prüfung aktualisiert einen Kunden nach festem Kalender, unabhängig davon, ob sich etwas verändert hat. Perpetual KYC beobachtet Ereignisse, die das Risikobild verändern, und öffnet nur dann eine Prüfung, wenn eines davon eintritt. So folgt der Aufwand der tatsächlichen Veränderung und nicht der Uhr.
Hebt Perpetual KYC die Pflicht zur periodischen Prüfung vollständig auf?
Nicht für sich allein. Die meisten Aufsichtsbehörden erwarten weiterhin eine belastbare Aktualisierungskadenz für Kunden mit höherem Risiko. Deshalb behalten wir einen Long-Stop-Timer bei, der eine Prüfung erzwingt, wenn innerhalb des Höchstintervalls der Risikoklasse kein Ereignis eine solche ausgelöst hat. Der Ereignisstrom verkürzt den durchschnittlichen Abstand, der Timer garantiert eine Obergrenze.
Was verhindert, dass das Modell einen riskanten Kunden stillschweigend herabstuft?
Änderungen der Risikoeinstufung sind in unserem Design asymmetrisch. Ein Upgrade in eine höhere Risikoklasse kann automatisiert werden, sobald die Evidenz einen Schwellenwert überschreitet. Ein Downgrade wird dagegen immer an einen menschlichen Prüfer weitergeleitet, mit der auslösenden Evidenz im Anhang. Begründung und Identität des Prüfers werden im Audit-Trail festgehalten.