Das KYC-Prinzip – Know Your Customer: Reloaded

KYC bzw. „Know Your Customer“ ist ein Prinzip, das Finanzdienstleister heute unbedingt auf dem Schirm haben müssen. Denn die Umsetzung der Kontrollen, Prozesse und Verfahren zur Identifikation betrügerischer Akteure und zum Schutz legitimer Kunden, die sich dahinter verbergen, werden in den meisten Ländern inzwischen per Gesetz vorgeschrieben. Angerissen haben wir das Thema schon vor einiger Zeit in diesem Blog mit interessanten Einblicken zu den Hintergründen für die Einführung von KYC-Vorgaben und dazu, wie unstrukturierte Zeitreihendaten für ihre Erfüllung nützlich sein können. Insgesamt waren die Ausführungen allerdings eher allgemein gehalten, daher zeigen wir im Folgenden noch einmal Schritt für Schritt auf, wie sich die Lösungen von Splunk in Use Cases rund um KYC einpassen. Beleuchten werden wir das Thema dabei im Hinblick auf technische Aspekte bzw. Konzepte dazu, wie sich bestehende, für KYC obligatorische Lösungen ergänzen bzw. erweitern lassen. Details zu den diversen hierfür geltenden Vorschriften lassen wir jedoch außen vor, da das den Rahmen sprengen würde.

Identität

Die erste und wichtigste Voraussetzung für KYC besteht logischerweise darin, sich zu vergewissern, dass eine Person  auch diejenige ist, für die sie sich ausgibt. Dies im Grunde also noch bevor sie überhaupt zum Kunden werden kann. Hierzu werden in der Regel verschiedene personenbezogene Daten der jeweiligen Person erfasst und anhand einer Reihe von Standardverfahren verifiziert. Diverse Unternehmen erweitern diese heute jedoch um zusätzliche Prüfungsmechanismen, um synthetische bzw. gefälschte Identitäten oder Konten aufdecken und so potenzielle Geldwäsche, Terrorismusfinanzierung oder andere kriminelle Aktivitäten zurückverfolgen zu können.

Dabei helfen können die Lösungen von Splunk. Denn unabhängig davon, ob die hierfür genutzte Anwendung intern entwickelt oder von kommerzieller Quelle bezogen wurde, erfolgt die Identitätsprüfung bei diesen sehr wahrscheinlich über Event-Logs. Splunk Enterprise und die Splunk Cloud Platform können hier für zusätzliche Sicherheit durch Monitoring der Anwendung auf Fehler, Latenz und andere Probleme sorgen. Ergänzt um Splunk Infrastructure Monitoring (SIM) und Splunk APM lässt sich dabei gewährleisten, dass Infrastruktur und Transaktionen zur Erkennung synthetischer Konten reibungslos arbeiten bzw. abgewickelt werden.

Konzeptionell greifen die Monitoring-Features dabei an dem Punkt, an dem die Anwendung die Logs der Webserver verschiedener Kanäle ausliest: Anhand der Client-IP des Antragstellers wird dabei untersucht, ob sich diese in der Nähe seines Wohnorts befindet (sofern kein VPN zur Umleitung der Verbindung über einen Server im Ausland zwischengeschaltet ist). Zudem wird verifiziert, ob die entsprechende Person oder andere Mitglieder ihres Haushalts in letzter Zeit versucht haben, Konten bei demselben Finanzdienstleister zu eröffnen. An dieser Stelle mag man sich fragen, ob so etwas Triviales nicht vom Prüfungstool selbst abgeglichen werden kann. Und ja, das kann es durchaus. Splunk jedoch macht es möglich, derartige Regeln ad hoc zu jedem beliebigen Zeitpunkt einzurichten, ohne dafür Anwendungscode schreiben zu müssen. Veränderte Anforderungen lassen sich so komplett dynamisch erfüllen. So etwa durch die Anpassung von Schwellenwerten zur Erkennung von Anomalien, wenn neue Indikatoren für Identitätsdiebstahl und synthetische Identitäten bekannt werden.

Due Diligence

Neben der Verifizierung der Identität stellen Bestimmungen rund um KYC zudem den Aspekt der „Due Diligence“ heraus. Was allgemein so viel wie „allgemeine Sorgfaltspflicht“ bedeutet, meint hier, einen Kunden nicht nur im Hinblick auf von ihm gemachte Angaben zu seiner Person zu prüfen. Vielmehr werden dabei auch verschiedene Parameter zum Hintergrund einer Person betrachtet, anhand derer sich auf den finanziellen Umfang ihres Kontos und dementsprechend auf ihr Risikolevel schließen lässt. Denn logischerweise wäre etwa mit der Geschäftsführung eines großen Unternehmens oder einem gewählten Regierungsmitglied ein anderes Risikolevel verbunden als mit einem eher unbedeutend ausgestatten Konto einer Einzelperson, die nicht in der Öffentlichkeit steht. Eine solche Beurteilung umfasst verschiedene Prüfschritte und entsprechend auch Workflow-Logs, daher lassen sich auch hier die Monitoring-Features von Splunk Enterprise und der Splunk Cloud Platform für Analysen und zu Troubleshooting-Zwecken implementieren. Denn nachdem die für die Prüfung relevanten Daten zum Kunden zusammengetragen wurden, werden diese sehr wahrscheinlich in einer lokalen Datenbank als System of Record erfasst. Die Lösungen von Splunk können darauf anhand von Lookup-Features zugreifen und zudem weitere Kundendaten ergänzen, um tiefergehende Untersuchungen zu ermöglichen.

Durchgängiges Monitoring

An diesem Punkt im KYC-Verfahren spielen Splunk Enterprise und die Splunk Cloud Platform ihr Potenzial noch deutlich weiter aus. Denn nachdem ein Kunde gewonnen ist, ist gemäß Compliance-Vorgaben vonseiten des Finanzdienstleisters sicherzustellen, dass von einem Kunden auch weiterhin keine kriminelle Aktivitäten ausgehen. Umzusetzen ist dies durch durchgängiges Monitoring der Aktivitäten des Kunden, was wir uns nachfolgend etwas genauer ansehen.

In Splunkbase findet sich hierfür mit Splunk Security Essentials eine ganz hervorragende App. Für uns nützlich sind dabei insbesondere die umfassenden Features rund um das erste Auftreten einer Aktivität ("first time seen"), die die App neben der Erkennung von Ausreißern bereits seit ihrer Einführung mitbringt. Als erstes Auftreten zu verstehen wäre beispielsweise der erstmalige Versuch eines Benutzers, ein Konto zu eröffnen. Ebenso aber auch das erste Mal, dass er sich bei einem Konto angemeldet oder eine Transaktion über das Konto vorgenommen hat. In Kontext betrachtet sind dies allesamt relevante Vorgänge bzw. Events. Denn will etwa ein Kunde ein neues Konto eröffnen, lässt sich darüber feststellen, ob von diesem bereits in der Vergangenheit ein Antrag zur Kontoeröffnung eingereicht wurde und wann dieser einging. Falls dieser Antrag aufgrund von KYC-Bestimmungen abgelehnt wurde, hat man eben diesen Kontext bereits zur Hand. Oder nehmen wir folgenden Fall: Ein Kunde eröffnet ein Konto und zahlt Geld ein. Anschließend ist das Konto nach seiner Eröffnung 18 Monate lang inaktiv, und nun hebt der Kunde zum ersten Mal Geld ab, wobei sich die Auszahlung auf fast das gesamte Guthaben beläuft. Erst 18 Monate nach Kontoeröffnung wird also überhaupt einmal eine Transaktion getätigt (= first time seen). Und dann auch noch eine, bei der der Kunde das Konto fast leer räumt.  Könnte hier eine Kontoübernahme vorliegen oder wird das Konto vielleicht dazu genutzt, Gelder zum Zweck der Geldwäsche zu parken? So oder so ist das erste Auftreten eines Events ein zentrales Element im Kontext von KYC. Implementieren lässt sich dies anhand der Splunk Processing Language (SPL), was wir uns nun näher ansehen.

Der nachfolgende Code zeigt einen recht einfachen Use Case für die Umsetzung des ersten Events eines Kunden mit der SPL. Darin rufen wir über das Feld „Last Touched“ das Event auf, zu dem nach der erstmaligen Kontoeröffnung durch einen Kunden mindestens sechs Monate verstrichen sind, bis von diesem wieder irgendeine Art von Vorgang bei der Bank registriert wird. Damit ist zwar nicht per se böswilliges Verhalten in Verbindung zu bringen. Als Faktor zur Erhöhung des Risikolevels des Kunden wird dies aber dennoch gewertet.

index=transacations sourcetype=account_opening| eval prev_epoch=strptime(last_touched, "%m/%d/%Y %H:%M:%S")|sort - last_touched |join customer [ index=transactions sourcetype=banking]|where epoch>relative_time(prev_epoch, "+6mon") |fields - prev_epoch, balance|rename accountID as current_accountID action as current_action account_type as current_account_type |eval current_balance=tostring(round(current_balance, 2),"commas"), other_balance=tostring(round(other_balance, 2),"commas")|convert timeformat="%m/%d/%Y %H:%M:%S" ctime(epoch) AS current_time|fields - epoch

Womöglich erschließt sich der Code nicht jedem direkt, gehen wir ihn also Stück für Stück durch: Über die erste und zweite Zeile erfassen wir alle Transaktionen im Zusammenhang mit der Kontoeröffnung. Darin haben wir den Zeitstempel im Feld „Last Touched“ in klassischem, von Menschen lesbaren Format. Diesen wandeln wir in Epoch-Zeit um, die in der Zahl der Sekunden angegeben wird, die seit 1. Januar 1970 verstrichen sind. Der Grund dafür: Computer können Zeiträume leichter über Ganzzahlen berechnen als in dem für uns üblichen Format. Als Nächstes verbinden wir diese Daten mit aktuellen Banktransaktionen unserer Kunden. Über die Where-Klausel ermitteln wir Ausreißer, also alle Events, deren aktuelle Epoch-Zeit größer ist als der entsprechende Wert zum Zeitpunkt der Kontoeröffnung. Ist der Zeitraum größer als sechs Monate, erfüllt dies unser Kriterium für das „erste Auftreten“ ("first time seen") von Kunden, die seit der Kontoeröffnung mindestens sechs Monate lang keinerlei Transaktionen über ihr Konto durchgeführt haben. Der restliche Code dient nur zur Formatierung: In der ausgegebenen Tabelle wird die Epoch-Zeit wieder in einem von Menschen lesbaren Format angezeigt und der betreffende Wert in eine einfache Ganzzahl umgewandelt. Uns geht es hier jedoch um den Inhalt, daher gehen wir nicht näher darauf ein. Die Ausgabe dieses SPL-Codes sehen wir im Folgenden.
 

Das Event „Erstes Auftreten“ ("first time seen") ist äußerst variabel definierbar und daher äußerst nützlich zum Monitoring von Kunden. Bevor wir das Konzept aber aus allgemeiner Perspektive betrachten, wollen wir uns zunächst mit Ausreißern und damit einer der Kernsäulen im Kontext von durchgängigem Monitoring beschäftigen. Dies am Beispiel eines Konzepts, bei dem wir nicht auf Machine Learning zurückgreifen müssen, sondern mit einfachen statistischen Methoden auskommen.

Die SPL gibt uns dazu mit „eventstats“ einen praktischen Befehl an die Hand, über den wir Statistiken übergreifend für alle Events in der Suche ermitteln können, ohne dass dabei Ergebnisse verändert werden. So erhalten wir neben den Durchschnittswerten auch die Standardabweichung für alle Events innerhalb einer gefilterten Datenauswahl. Hierzu nachfolgend ein einfaches Beispiel:
 

index=payments|stats avg(amount) as avg_accountID by accountID|eventstats avg(avg_amountID) as avg_amount stdev(avg_amountID) as stdev_amount|where avg_accountID>(3*stdev_amount + avg_amount)

Zunächst berechnen wir bei dieser Suche den durchschnittlichen Zahlungsbetrag nach Konto-ID (accountID). Im nächsten Schritt ermitteln wir Durchschnittswert und Standardabweichung des Betragswerts aller Zahlungen, die in einer vom Benutzer oder durch eine gespeicherte Suche ausgewählten Zeitspanne aufgetreten sind (im Screenshot nicht zu sehen). Den Ausreißer bildet dann eine Zahlung, die größer ist als der Durchschnittsbetrag plus das Dreifache der Standardabweichung aller Zahlungen in der Datenauswahl. Diese Methode zur Ermittlung von Ausreißern ist tatsächlich recht banal. Denn ebenso könnten wir hierzu auch mit einem Durchschnitt mit statischem Multiplikator, gleitenden Durchschnitten mit Standardabweichung und verschiedensten anderen statistischen Verfahren arbeiten. Umso erfreulicher, dass mit Discovered Intelligence ein Partner von Splunk einen kompakten Leitfaden zur Erkennung von Ausreißern in Splunk zur Verfügung stellt.

Beim hier beschriebenen Verfahren rund um das erste Auftreten und die Erkennung von Ausreißern wäre es wenig zielführend, Zahlen und Feldnamen in einer Suche als hartcodierte Werte zur mehrfachen Verwendung zu definieren. Als praktischer erwiesen haben sich hierfür die Makros die sich mit Splunk einrichten lassen. Für das „erste Auftreten" und unser Beispiel zur Erkennung von Ausreißern haben wir entsprechende Makros im Paket TA For SplunkStart Basic Security Essentials für euch zusammengestellt. Ihr könnt es in Splunkbase kostenlos herunterladen, in der Datei „macros.conf“ sind die Makros zu finden.

Wie bereits erwähnt, basiert das Beispiel oben auf einfacher Statistik. Komplexere Verfahren könnt ihr über das Splunk Machine Learning Toolkit kostenlos nutzen. So etwa Density Function, Local Outlier Factor, One Class SVM und diverse weitere ML-basierte Algorithmen. Mit dem Smart Outlier Detector Assistant bietet das Toolkit zudem einen webbasierten Assistenten, mit dem die Anwendung auch ohne weiter reichende Data-Science-Kenntnisse unkompliziert möglich ist.

Baselining

Einigen aufmerksamen Lesern ist es womöglich bereits aufgefallen: Zur Ermittlung von Ausreißern innerhalb einer Gesamtpopulation ist der Befehl „eventstats“ nicht unbedingt zielführend, wenn unter ihren Vertretern solche sind, die abweichendes Verhalten in Bezug auf Routinetransaktionen zeigen. So wäre es etwa möglich, dass eine Kunde regelmäßig Überweisungen von 500 Euro pro Monat tätigt, während sich das Transaktionsvolumen bei einem anderen konstant auf 50.000 Euro beläuft. Für sich alleine sind die beiden Verhaltensmuster nicht ungewöhnlich. Doch ermittelt man den Durchschnittswert der für beide Kunden anfallenden Summe, so ist dieser wenig aussagekräftig, da stark in Richtung des höheren Transaktionswerts verzerrt. Weniger verzerrte Werte erhalten wir bei unserer Methodik zur Ermittlung von Ausreißern, indem wir durch Erfassung der Transaktionen für jeden einzelnen Kunden auf Tages- oder Wochenbasis eine Baseline bilden. Nachfolgend sind hierfür mögliche Ergebnisse beispielhaft aufgeführt. Erhalten haben wir diese, indem wir über die Befehle „stats“ und „collect“ Daten zu einer geplanten gespeicherte Suche für einen durchschnittlichen Überweisungsbetrag in einem Index zusammengefasst haben.
 

Der Weg zu diesen Ergebnissen führt über den Befehl „stats“, mit dessen Hilfe wir den durchschnittlichen Überweisungsbetrag für eine beliebige Konto-ID (accountID) ermitteln, um so eine Baseline für frühere Transaktionen zu erhalten. Durch Abgleich mit dem aktuellsten erfassten Betrag lassen sich dann potenzielle Ausreißer ermitteln. Dies wiederum macht durchgängiges Monitoring möglich, indem wir die neuesten Transaktionen mit dem erwarteten Kundenverhalten vergleichen. Denn bei jeder Transaktion des Kunden kann über eine gespeicherte Suche der neue Wert im zusammengefassten Index ergänzt und der aktuelle Betrag mit dem historischen Durchschnitt für den Kunden verglichen und so Ausreißer ausgemacht werden. Die nachfolgend gezeigte Suche zeigt ein Beispiel für dieses Szenario. Dabei wurde der Durchschnitt und die Standardabweichung des zusammengefassten Index für eine Konto-ID an die aktuelle Transaktion angefügt und die aktuelle Zahlung (Durchschnitt der Zahlungen im aktuellen Zeitraum) mit der Summe der historischen Durchschnittswerten und dem Dreifachen der Standardabweichung verglichen.
 

index=payments accountID=”456” | append [ search index=payments_summary accountID=”456” earliest=-1Y| stats avg(amount) as avg_payment stdev(amount) as stdev_payment]|stats avg(amount) as current_payment values(avg_payment) as avg_payment values(stdev_payment) as stdev_payment values(accountID) as accountID|where current_payment > avg_payment + (3*stdev_payment)

Müsste man das Ganze auf Millionen von Konten anwenden, wäre aber wohl eine effizientere Methodik zur Erfassung der zusammengefassten Daten zu täglichen oder wöchentlichen Transaktionen für die einzelnen Konto-IDs vonnöten. Hierfür bietet Splunk mit kvstore den passenden Speicher für Schlüssel-Wert-Paare. Dieser ist standardmäßig im Rahmen unserer Lösung verfügbar und kann als Universaldatenbank für Vorgänge rund um die Erstellung, Modifikation und Lösung verwendet werden, um Daten mit Kontext aus anderen Suchen anzureichern.

Dies ist jedoch nur eine von vielen Methodiken zum Baselining mit Splunk. In diesem Blog gehen wir etwa auf das Baselining auf Grundlage von Verhältnissen ein. Hierbei wird das Verhältnis der Einzelwerte je Entität bezogen auf die Gesamtzahl aller Transaktionen ermittelt. Ausreißer bilden dann die Werte, bei denen das Verhältnis ungewöhnlich stark abweicht. Hierdurch wird bessere Skalierbarkeit erreicht, wenn statt Durchschnittswerten und Standardabweichungen die Auftrittshäufigkeit als Ermittlungsgrundlage dient. Unabhängig davon, anhand welcher Methodik durchgängiges Monitoring angewandt wird, gilt jedoch stets: Ausreißer mögen zwar auf Sicherheitsprobleme oder Betrug hindeuten, doch ist Kundenverhalten äußerst individuell und erfordert somit auch eine spezifisch darauf abgestimmte Baseline.

Risikoermittlung

Ungewöhnliches Verhalten eines Kunden bedeutet nicht per se, dass auch wirklich ein Problem vorliegt. Deshalb gilt es, das Risiko für jeden Ausreißer einzeln zu bewerten und mit einem kumulierten Gesamtwert der für den jeweiligen Kunden bestehenden Risikobewertungen abzugleichen. Durch Erfassung dieses Werts nach Konto-ID lassen sich False Positives vermeiden und potenziell kriminelles Verhalten zudem zuverlässiger aufdecken. Als Datengrundlage dient uns hierfür die weiter oben angesprochene Due-Diligence-Prüfung. Über die entsprechenden Daten können wir Risikowerte für Suchvorgänge zur Ermittlung von Ausreißern verwenden, wobei ggf. noch eine numerische Gewichtung gegenüber dem ursprünglichen Risikowert vonnöten ist. Umsetzen lässt sich dies durch Abruf der Due-Diligence-Daten via Lookup, die ihrerseits in eine weitere Lookup-Suche einfließen, um eine numerische Gewichtung als Multiplikator für den ursprünglichen Risikowert zu erhalten. Die über diesen Suchvorgang ermittelten Informationen werden dabei in einem Risikoindex erfasst und beim Überschreiten von Schwellenwerten Warnmeldungen ausgelöst.

Verschiedene Verfahren zur Risikoermittlung in Splunk beleuchten wir in diesem Blog  zum Thema Erkennung von Finanzkriminalität. Im Fokus stehen dabei Methodiken, bei denen Risikowerte für das Verhalten über gespeicherte Suchvorgänge erfasst werden. Interessant dabei: Beim Monitoring von Kunden auf Anomalien und Ausreißer wird es über diese Werte möglich, die Risikobewertung im KYC-Kontext zu automatisieren. entsprechend zu reagieren und dabei auch SOAR-Playbooks zu implementieren.

Wer all dies noch deutlich einfacher lösen will, sollte einen Blick auf Splunk Enterprise Security werfen. Kunden der Lösung können die Splunk App For Fraud Analytics  kostenlos nutzen, mit der sich Account-Übernahmen und -Missbrauch aufspüren lassen. Zwei der Kernsäulen beim Monitoring und Schutz von Kunden sind mit der App also bereits abgedeckt. Gestützt auf Features für Risk-Based Alerting (RBA) von Splunk ES ist es mit ihr außerdem möglich, entsprechend den zuvor ausgeführten Methodiken kumulierte Risikowerte zu erfassen. Damit sind zwar noch immer nicht alle Anforderungen von KYC im Kontext von durchgängigem Monitoring abgedeckt. Mithilfe der im Rahmen der App out-of-the-box verfügbaren Inhalte lassen sich aber dennoch einige wichtige Schritte in diese Richtung machen.

Customer Journey

Die Monitoring-Anforderungen im Kontext der KYC-Bestimmungen betreffen weder Kundenerlebnis noch irgendeine Art von Unterstützung von Kunden dabei Investitionsentscheidungen. Entsprechend sind diese Use Cases auch nicht Gegenstand dieses Artikels, da wir hier ja speziell auf Compliance-Aspekte eingehen. Interessant zu erwähnen ist aber dennoch, dass einige der Daten, die wir zu Compliance-Zwecken erfassen, auch im Kontext der Customer Journey äußerst nützlich sind. Ein Beispiel wäre eine Kontoeinzahlung, die um das Hundertfache über dem Durchschnitt liegt. Einmal wäre das natürlich ein Ausreißer. Womöglich erweist sich dies aber als günstiger Zeitpunkt für ein renditestarkes Investment-Angebot an den entsprechenden Kunden – dies natürlich unter der Voraussetzung, dass der Ausreißer harmlos ist. Einzelheiten zu Use Cases rund um die Customer Journey findet Ihr in diesem Blog.

Fazit

Neben den Kernsäulen des KYC-Prinzips haben wir ausgeleuchtet, wie ihr die damit verbundenen Bestimmungen mit den Prudukten von Splunk effektiv erfüllen könnt. Indem Ihr sämtliche Kundeninteraktionen als Zeitreihenereignisse erfasst, Basiswerte für das Kundenverhalten ermittelt und statistische oder ML-basierte Methodiken zur Erkennung von Anomalien und Ausreißern einsetzt, könnt Ihr durchgängiges Monitoring nicht nur effizient und skalierbar ausweiten, sondern flexibel an neue Anforderungen anpassen.