Spezifikation der Problemstellung dieser Arbeit

Nach [Böhm02, S. 32] ist ein Problem definiert als eine Diskrepanz zwischen der vorhan-denen, feststellbaren Ist-Situation und der Soll-Vorstellung.

Diese Arbeit behandelt dabei das praktische Problem der Ist-Situation der auftretenden Betrugstransaktionen im Online-Banking im Anschluss an erfolgreiche Identitätsdiebstäh-le. Die Soll-Vorstellung ist, dass unter den auftretenden events, die durch die Transaktio-nen entstehen bzw. die TransaktioTransaktio-nen repräsentieren, diejenigen in Echtzeit (oder nahe Echtzeit) herausgefiltert werden, die auf einen Betrugsversuch hindeuten. Diese events bzw. Transaktionen besitzen bestimmte Attribute, deren Werte zu diesem Zweck analy-siert werden können, z.B. Transaktionsbetrag, Kontonummer des Begünstigten, Wäh-rungskennzeichen usw. [Zent07]. Konkret soll erforscht werden, wie Kombinationen (pat-terns) aus aktuellen und historischen events automatisiert (maschinell) erkannt werden, die zusammen aus der Transaktionshistorie heraus ein bestimmtes Betrugsmuster erge-ben (wie z.B. Kontoplünderung durch Phishing, Pharming usw.) bzw. mit einer gewissen Wahrscheinlichkeit einen Betrugsfall darstellen.

Die Eventquellen der Transaktionen bilden – lt. den Aussagen aus Interviews mit Be-trugsexperten – operative Datenbanken, in denen diese nach dem Anstoßen der Online-Überweisung durch den Kunden zur Weiterverarbeitung (z.B. durch das Rechenzentrum oder einem Rechenzentrumsdienstleister) zwischengespeichert werden.

Eine Transaktion selbst besteht u.a. aus den folgenden Parametern bzw. Attributen, die der Kunde beim Durchführen einer Online-Überweisung explizit angeben muss, siehe [Zent07]:

• Name des Begünstigten

• Kontonummer des Begünstigten

• Bankleitzahl des Begünstigten

• Überweisungsart

• Transaktionsbetrag

• Verwendungszweck

• Name des Kontoinhabers

• Kontonummer des Kontoinhabers

• Datum der Transaktion (optional)

Vervollständigt wird dieser Datensatz durch weitere Attribute, wie z.B. Währungskennzei-chen oder Kreditinstitut des Begünstigten, die der Transaktion noch hinzugefügt werden, siehe dazu [Zent07]. Aus den Interviews mit den Betrugsexperten ergab sich, dass diese oben aufgezählten Attribute alleine nicht ausreichend sind um ein Urteil abgeben zu kön-nen, ob es sich bei einer bestimmten Transaktion um einen Betrugsfall handelt oder nicht.

Der Grund dafür ist, dass sich nach einem erfolgreichen Einloggen ein Betrüger im Web oftmals genau so bewegt wie der eigentliche Kunde. Aus den Interviews ergab sich, dass die nachfolgend aufgezählte Attributteilmenge aus der Attributgesamtmenge einer Über-weisung aussagekräftig ist, um einen Betrugsfall zu identifizieren, wobei zu diesem Zweck nur Online-Überweisungen zu untersuchen sind (auf Basis dieser Attribute ist auch die Simulation der Überweisungen aufgebaut, die im Unterabschnitt 9.1.2 beschrieben wird):

• KundenID

• TransaktionsID

• Transaktionsbetrag

• IP-Adresse des Quellrechners bzw. Inland IP-Adresse

• Zeit für die Online-Überweisung

• Kontostand

• Maximal verfügbarer bzw. übertragbarer Transaktionsbetrag

• Durchschnittliche Anzahl von Transaktionen (pro Monat) zum Zeitpunkt der Trans-aktion einschließlich der Zugriffe auf die Online-Banking Seite z.B. zur

Konto-• Durchschnittlicher Transaktionsbetrag der Online-Überweisungen zum Zeitpunkt der Transaktion

• Kontonummer (Empfänger)

• Bankleitzahl (Empfängerbank)

• Vertrauenswürdiger bzw. bekannter Empfänger

• Bekannte, nicht vertrauenswürdige Zielbanken bzw. Auslandsüberweisung

Zur Erzeugung eines complex events mit diesen genannten Attributen muss von der CEP engine das ursprüngliche event mit einem event, das die zusätzlichen, abgefragten Daten zu einem Kunden enthält, korreliert werden.

Das Einbinden der Transaktionshistorie und die damit verbundene Bildung eines Transak-tionsprofils eines Kunden ist lt. den Aussagen aus den Interviews von Bedeutung, weil der Fall auftreten kann, dass bei zwei Transaktionen mit identischen Attributausprägungen von zwei verschiedenen Kunden eine der beiden Transaktionen eine höhere Betrugs-wahrscheinlichkeit aufweist als die andere, ansonsten identische, Transaktion. Der Grund dafür liegt in der unterschiedlichen Verhaltens- bzw. Transaktionshistorie der beiden Kun-den. Dazu folgendes Fallbeispiel: Ein Kunde überweist regelmäßig einen Betrag, der nahe an der maximalen Kapitalverfügbarkeitsgrenze des online geführten Kontos liegt, ein zweiter Kunde transferiert immer nur kleine Beträge im Verhältnis zu seinem verfügbaren Maximalbetrag. Bei dem zweiten Kunden ist die Wahrscheinlichkeit eines Betrugsfalls bei einer Überweisung in der Höhe seines Kontostands höher als bei dem erstgenannten Kunden. Das bedeutet, eine einzelne Transaktion für sich allein dargestellt reicht nicht aus, um einen Betrugsfall eindeutig zu identifizieren, was auch von [Reol07, S. 3] bestätigt wird. In [Reol07, S. 20] wird das Bilden von solchen Verhaltensmustern als „Relationalisie-rung der Transaktionen“ bezeichnet. Allerdings können diese Verhaltensmuster nicht für Neukunden erstellt werden, die noch keine historischen Transaktionen durchgeführt ha-ben. Kundenspezifische Transaktionsprofile werden beispielsweise auch zur Identifikation von Kreditkartenbetrug auf Basis von Transaktionsmustern verwendet, siehe dazu [Xu06, S. 1], [Xu05, S. 1], [Kou04, S. 3], [Bolt02, S. 18] oder bei der Betrugserkennung im Wert-papierhandel, siehe [Conz07].

Für die Optimierung der Betrugsanalyse beim Online-Banking ist es wichtig, dass einer-seits ein hoher Anteil der Betrugstransaktionen identifiziert wird und anderereiner-seits so wenig wie möglich Nicht-Betrugstransaktionen fälschlicherweise als Betrugstransaktionen klassi-fiziert werden (false positive).

Eine falsch klassifizierte Nicht-Betrugstransaktion ist ebenfalls kritisch für ein Kreditinstitut, da hierbei die Gefahr besteht, die Kundenzufriedenheit zu verringern oder den Kunden an

einen Mitbewerber zu verlieren, falls eine legale Transaktion aufgrund eines Betrugsver-dachts gestoppt wird [Agge06, S. 2].

Die Identifikation der Betrugstransaktionen muss so schnell wie möglich, d.h. in Echtzeit oder nahe an Echtzeit erfolgen um sie vor dem Abschluss verhindern zu können, worauf z.B. auch [Conz07], [Bose06, S. 1] und [Xu06, S. 1] in ihren Arbeiten hinweisen. Dies ist ebenfalls notwendig, da die Opfer selbst einen Betrugsfall in der Regel viel zu spät (z.B.

oftmals erst nach einer Woche) bemerken [Agge06, S. 1]. Diese Problemstellung, die rich-tige Information (in diesem Fall über einen Betrugsvorgang) komprimiert zur exakten Zeit an den benötigten Ort zu transferieren wird in den Artikeln von F. Hayes-Roth als Valued Information at Right Time-Problem (VIRT) bezeichnet, siehe [Haye06] und [Haye07], wo-bei in diesen Publikationen der militärische Sektor das untersuchte Anwendungsgebiet darstellt. Von den interviewten Betrugsexperten wird dieses Problem bei einer Erken-nungsgenauigkeit von 99,0% und zeitnaher Verteilung der Information an die entspre-chenden Stellen durch ein automatisiertes Verfahren als gelöst angesehen. Der Rest, d.h.

die nicht exakt zuordenbaren Transaktionen würden lt. den befragten Betrugsexperten von den Mitarbeitern der Revisionsabteilungen der Kreditinstitute manuell geprüft werden.

Somit soll im Rahmen dieser Arbeit ein inverses Problem nach [Bung08, S. 16] gelöst werden, da die genannten Anforderungen im Vorfeld feststehen und nachfolgend nach einem geeigneten Modell geforscht wird, welches diese Anforderungen erfüllt.