Kontinuierliche Überwachung: Verhaltensanalyse nach dem Onboarding
Die kontinuierliche Überwachung trägt der Tatsache Rechnung, dass sich das beim Onboarding ermittelte Risiko im Laufe der Zeit verändert. Truvali gleicht jede Transaktion mit der Historie und dem deklarierten Profil des Kunden ab, generiert bei Abweichungen Warnmeldungen und aktualisiert die Risikoklassen.
Die kontinuierliche Überwachung (Continuous Monitoring) bezeichnet die fortlaufende Analyse des Transaktionsverhaltens und des Risikoprofils eines Kunden während der gesamten Geschäftsbeziehung. Die beim Onboarding erfassten Informationen sind lediglich ein Ausgangspunkt: Die deklarierte Aktivität eines Kunden und seine tatsächlichen Transaktionen können im Laufe der Zeit voneinander abweichen – und das verpflichtete Unternehmen ist verpflichtet, genau diese Abweichungen zu erkennen.
Womit werden die Daten abgeglichen?
Eine einzelne Transaktion ist für sich genommen wenig aussagekräftig. Ihre Bedeutung erschließt sich erst durch den Vergleich mit Referenzwerten.
| Abgleich | Was erkannt wird |
|---|---|
| Eigene Historie des Kunden | Beträge, Häufigkeiten oder Zeiten, die von den Gewohnheiten abweichen |
| Deklarierte Aktivität | Transaktionstypen oder Gegenparteien, die nicht mit den Angaben übereinstimmen |
| Peer-Group | Verhalten, das innerhalb desselben Segments ungewöhnlich erscheint |
| Unterschwellige Muster | Strukturierte Transaktionen, die knapp unter den Meldegrenzen aufgeteilt werden |
| Netzwerkbeziehungen | Cluster, die über gemeinsam genutzte Geräte, IPs, Adressen oder Konten verbunden sind |
Diese Vergleiche werden über Aggregationsfenster berechnet: Die Anzahl, Summe und der Durchschnitt der Transaktionen eines Kunden über einen bestimmten Zeitraum können direkt bei der Regelerstellung verwendet werden. Details finden Sie auf der Seite Regel- und Szenario-Engine.
Warum ist die Risikoklasse nicht statisch?
Die Risikoklasse des Kunden wird beim Onboarding zugewiesen, bleibt jedoch nicht unveränderlich. Ein neuer Sanktionseintrag, negative Medienberichte (Adverse Media), eine Reihe von Transaktionen, die nicht mit den Angaben übereinstimmen, oder eine Änderung der Eigentümerstruktur können die Risikoklasse erhöhen. Steigt die Risikoklasse, ändern sich auch die Überwachungsfrequenz, die erforderlichen Dokumente und die Intervalle für die regelmäßige Überprüfung.
Da sich Sanktionslisten ständig ändern, wird der bestehende Kundenstamm fortlaufend neu überprüft: Ein Datensatz, der heute unauffällig ist, kann morgen einen Treffer erzielen. Der Screening-Prozess wird auf der Seite Sanktions-Compliance näher erläutert.
Was passiert bei einer Flut von Warnmeldungen?
Die eigentliche Herausforderung beim Continuous Monitoring besteht nicht darin, Risiken zu übersehen, sondern in einer Flut von Warnmeldungen (Alerts) unterzugehen. Eine Regel mit einem zu niedrig angesetzten Schwellenwert generiert so viele Fehlalarme, dass echte Bedrohungen übersehen werden – und nach einer Weile stumpft das Team ab. Daher muss vor der Liveschaltung gemessen werden, wie viele Warnmeldungen eine Regel erzeugen wird: Der neue Schwellenwert wird anhand historischer Transaktionsdaten getestet. Genau dafür gibt es die Regelsimulation und das Backtesting.
Für die Erstellung einer Regel sind keine technischen Fachkenntnisse erforderlich: Die gewünschte Kontrolle kann in natürlicher Sprache formuliert werden, woraufhin ein entsprechender Regelentwurf generiert wird. Die Seite Regelerstellung mit Prompts erklärt dieses Prinzip.
Wenn eine Warnmeldung ausgelöst wird
Aus einer Warnmeldung wird ein Fall (Case). In diesem Fall werden die Transaktion, die Historie des Kunden, die genaue Version der ausgelösten Regel und die Begründung des Analysten zentral zusammengeführt. Die lückenlose Dokumentation der Regelversion ist für Audits entscheidend: Wenn Sie gefragt werden, auf Basis welches Regelsatzes vor sechs Monaten eine Entscheidung getroffen wurde, liefert die Historie die präzise Antwort.
Als Ergebnis der Untersuchung wird der Fall geschlossen, vorübergehend stummgeschaltet (snoozed) oder zu einer Meldung eskaliert. Der Workflow wird auf der Seite Alert- und Case-Management beschrieben, und das Meldewesen finden Sie unter Regulatorisches Meldewesen.
Monitoring wird erst durch das Onboarding sinnvoll
Die beim Onboarding erfassten Informationen bilden die Referenzlinie (Baseline) für die Überwachung. Ohne deklarierte Aktivität lassen sich Abweichungen nicht messen. Deshalb ist es von entscheidender Bedeutung, dass beide Prozesse auf demselben Datensatz basieren: Die Seite Kunden-Onboarding beleuchtet diese Perspektive.
Häufige Fragen
- Was gleicht die kontinuierliche Überwachung ab?
- Sie bewertet Transaktionen im Vergleich zur eigenen Historie des Kunden, seiner deklarierten Aktivität, Peer-Groups, unterschwelligen Strukturierungsmustern sowie Netzwerkbeziehungen, die über gemeinsam genutzte Geräte, IPs oder Konten bestehen.
- Kann sich die Risikoklasse eines Kunden ändern?
- Ja. Ein neuer Sanktionseintrag, negative Medienberichte, eine Reihe von Transaktionen, die nicht mit den Angaben übereinstimmen, oder eine Änderung der Eigentümerstruktur erhöhen die Risikoklasse. In der Folge passen sich die Überwachungsfrequenz und die Überprüfungsintervalle entsprechend an.
- Werden Bestandskunden erneut überprüft?
- Ja. Da sich Sanktions- und Watchlists ständig ändern, wird der bestehende Kundenstamm fortlaufend neu überprüft (Re-Screening), da ein heute unauffälliger Datensatz morgen einen Treffer erzielen kann.
- Wie wird das Risiko einer Flut von Fehlalarmen minimiert?
- Bevor eine Regel live geht, wird sie auf historische Transaktionsdaten angewendet, um das zu erwartende Alert-Volumen zu messen. Ein Schwellenwert, der das Team überlastet, ist ebenso problematisch wie einer, der echte Risiken übersieht.
- Sind für die Regelerstellung technische Fachkenntnisse erforderlich?
- Nein. Die gewünschte Kontrolle kann in natürlicher Sprache formuliert werden. Daraus wird automatisch ein entsprechender Regelentwurf generiert, der erst nach Freigabe live geschaltet wird.
- Lässt sich im Nachhinein nachvollziehen, welche Regel zu einer Entscheidung geführt hat?
- Ja. Die genaue Version der Regel, die den Alert ausgelöst hat, wird direkt beim Ereignis dokumentiert. So lässt sich eine frühere Entscheidung jederzeit auf Basis des an jenem Tag aktiven Regelsatzes auditierungssicher begründen.
- Wie läuft der Prozess nach dem Auslösen einer Warnmeldung ab?
- Aus einer Warnmeldung wird ein Fall (Case). Nach der Untersuchung wird dieser geschlossen, vorübergehend stummgeschaltet oder als Meldung eskaliert. Die Begründung und die Entscheidung werden revisionssicher im Audit Trail protokolliert.
- Ist das Monitoring unabhängig vom Onboarding-Prozess?
- Nein. Die beim Onboarding erfassten Angaben und Profile dienen als Referenzlinie (Baseline) für die Überwachung. Ohne diese Ausgangsdaten lassen sich Abweichungen im Verhalten nicht messen.