Die massive Zunahme des E-Commerce in den letzten Jahren hat auch zu einer Steigerung der betrügerischen Aktivitäten bei Online-Zahlungen geführt. Weltweit verursacht Betrug bei Unternehmen Kosten von geschätzt mehr als 20 Mrd. USD jährlich. Tatsächlich sind die realen Kosten noch wesentlich höher: Online-Betrug führt auch zu höheren Betriebskosten und Netzwerkgebühren sowie zu Kundenabwanderung.

Betrug führt nicht nur zu hohen Kosten, raffinierte betrügerische Akteur/innen finden auch ständig neue Wege, um Schwachstellen auszunutzen. Das erschwert die Betrugsbekämpfung. Deshalb haben wir Stripe Radar entwickelt – eine auf maschinellem Lernen basierende Lösung zur Betrugsprävention, die vollständig in die Stripe-Plattform integriert ist. Das maschinelle Lernen von Radar nutzt die Daten von Zahlungen in Höhe von über Hunderten Milliarden US-Dollar, die jedes Jahr über das Stripe-Netzwerk abgewickelt werden, um Betrug präzise zu erkennen und sich schnell an die neuesten Trends anzupassen, damit Ihr Unternehmen wachsen kann, ohne dass auch der Betrug zunimmt.

Dieser Leitfaden stellt Stripe Radar vor und erklärt, wie wir das Stripe-Netzwerk zur Betrugserkennung einsetzen. Er gibt einen Überblick über die von uns verwendeten Techniken des maschinellen Lernens und erläutert unsere Vorstellungen über die Wirksamkeit und Leistung von Betrugserkennungssystemen. Außerdem wird gezeigt, wie andere Tools der Radar-Suite Unternehmen helfen können, ihre Betrugsbekämpfung zu optimieren.

Einführung in den Online-Kreditkartenbetrug

Eine Zahlung gilt als betrügerisch, wenn Karteninhaber/innen die entsprechende Belastung nicht autorisiert haben. Wenn betrügerische Akteur/innen beispielsweise einen Kauf mit einer entwendeten Karte oder Kartennummer tätigen, deren Diebstahl oder Missbrauch nicht gemeldet wurde, ist es möglich, dass die Zahlung erfolgreich abgewickelt wird. Wenn die Karteninhaber/innen dann die betrügerische Verwendung der Karte entdecken, werden sie die Zahlung bei der Bank anfechten (auch als „Rückbuchung“ bezeichnet).

Unternehmen können einer Rückbuchung durch Vorlage von Beweisen für die Gültigkeit der Zahlung widersprechen. Wird jedoch bei Card-Not-Present-Transaktionen (ohne Vorlage der physischen Karte) von den Netzwerken festgestellt, dass die Zahlung tatsächlich betrügerisch war, liegt das Recht aufseiten der Karteninhaber/innen und das Unternehmen muss für den Verlust von Waren und für Gebühren aufkommen.

Bislang haben Unternehmen mit Brute-Force-Regeln versucht, mutmaßlich betrügerische Transaktionen vorherzusagen und zu blocken. Fest kodierte Regeln, mit denen beispielsweise alle im Ausland genutzten Kreditkarten geblockt werden, können jedoch dazu führen, dass auch zahlreiche legitime Transaktionen unmöglich werden. Durch maschinelles Lernen lassen sich nun differenziertere Muster erkennen, die Ihnen helfen, Ihren Umsatz zu maximieren. Im Sprachgebrauch des maschinellen Lernens spricht man von einem „False Negative“, wenn das System etwas übersieht, das es eigentlich hätte erkennen sollen – in diesem Fall eine betrügerische Transaktion. Ein „False Positive“ liegt vor, wenn das System etwas erkennt, das es nicht hätte erkennen sollen und beispielsweise legitime Kund/innen blockt. Bevor wir uns mit den Einzelheiten des maschinellen Lernens befassen, sollte man sich der damit verbundenen Zielkonflikte bewusst werden.

Bei False Negatives müssen Unternehmen meist den ursprünglichen Transaktionsbetrag zuzüglich Rückbuchungsgebühren (die Kosten, die mit der Rückbuchung der Kartenzahlung durch die Bank verbunden sind), höhere Netzwerkgebühren als Folge der Anfechtung und höhere Betriebskosten für die Überprüfung von Abrechnungen oder für die Bearbeitung von Anfechtungen tragen. Wenn zu viele Streitfälle auftreten, kann es außerdem sein, dass das Unternehmen in ein Programm zur Überwachung von Kreditkartenrückbuchungen aufgenommen wird, was zu höheren Kosten oder in einigen Fällen sogar dazu führen kann, dass es keine Kartenzahlungen mehr annehmen darf.

False Positives bzw. falsche Ablehnungen entstehen, wenn legitime Kund/innen versuchen, Käufe zu tätigen, aber daran gehindert werden. Fälschliche Ablehnungen können für das Unternehmen sowohl einen finanziellen Schaden als auch eine beschädigte Reputation zur Folge haben. In einer kürzlich durchgeführten Umfrage haben 33 % der Verbraucher/innen angegeben, dass sie nach einer falschen Ablehnung nicht wieder bei diesem Unternehmen einkaufen würden.

Zwischen der Vermeidung von mehr Streitfällen (False Negatives) und der Verringerung des Ablehnens legitimer Kund/innen (False Positives) besteht ein Zielkonflikt: Je mehr Sie Streitfälle reduzieren, desto mehr Ablehnung müssen Sie tolerieren (und umgekehrt). Wenn Sie mehr Betrug verhindern, nimmt potenziell auch die Zahl der abgelehnten guten Kund/innen zu. Andererseits erhöht die Verringerung der Zahl der False Positives oft die Wahrscheinlichkeit, dass mehr echte Betrugsfälle durch die Maschen schlüpfen. Unternehmen müssen auf der Grundlage ihrer Margen, ihres Wachstumsprofils und weiterer Faktoren entscheiden, wie sie diese beiden Aspekte gegeneinander abwägen.

Bei Unternehmen mit geringen Gewinnspannen – beispielsweise beim Online-Vertrieb von Lebensmitteln – müssen die Kosten einer betrügerischen Transaktion möglicherweise durch Hunderte von erfolgreichen Transaktionen ausgeglichen werden, was jedes False Negative sehr kostenintensiv macht. Unternehmen mit einem solchen Profil tendieren dazu, potenziellen Betrug sehr weiträumig verhindern zu wollen. Wenn die Gewinnspanne eines Unternehmens hingegen hoch ist, beispielsweise bei einem SaaS-Unternehmen, ist das Gegenteil der Fall. Der entgangene Umsatz von abgelehnten legitimen Kund/innen kann höher sein, als die Kosten für einen erhöhten Betrug.

Stripe Radar und das Stripe-Netzwerk

Radar ist die Stripe-Lösung zur Betrugsvorbeugung und schützt so Unternehmen vor Online-Kreditkartenbetrug. Sie basiert auf adaptivem maschinellem Lernen, dem Ergebnis jahrelanger Arbeit der Stripe-Teams im Bereich Datenwissenschaft und Infrastruktur für maschinelles Lernen. Die Algorithmen von Radar evaluieren jede Transaktion auf ihr Betrugsrisiko und ergreifen entsprechende Maßnahmen. Zahlungen mit hohen Werten werden blockiert und Radar for Fraud Teams stellt Tools bereit, mit denen Nutzer/innen festlegen können, wann andere Maßnahmen ergriffen werden sollen.

Stripe verarbeitet Hunderte von Milliarden an Zahlungen für Millionen von Unternehmen und arbeitet jedes Jahr mit Tausenden von Partnerbanken auf der ganzen Welt zusammen. Diese Größenordnung bedeutet, dass wir Signale und Muster oft viel früher erkennen können als kleinere Netzwerke. Betrugsrelevante Daten aus allen Stripe-Transaktionen – die durch den Zahlungsfluss automatisch erfasst werden – tragen zur einer verbesserten Betrugserkennung bei. Signale wie das Land, in dem die Karte ausgestellt wurde, oder die IP-Adresse, von der aus die Zahlung getätigt wurde, liefern wertvolle Erkenntnisse über die Vorhersage, wie wahrscheinlich es ist, dass es sich um eine betrügerische Zahlung handelt.

Frühere Interaktionen mit einer Karte im Stripe-Netzwerk bieten ebenfalls eine beträchtliche Menge an Daten, die in unsere Risikobewertung einfließt. 90 % der Karten, die im Stripe-Netzwerk verwendet werden, wurden mehr als einmal verwendet, was uns viel umfangreichere Daten liefert, um zu bewerten, ob sie legitim oder betrügerisch eingesetzt werden.

Ein weiterer entscheidender Vorteil unseres maschinellen Lernens besteht darin, dass Radar direkt in Stripe integriert und damit sofort einsatzbereit ist. Andere Lösungen zur Betrugsprävention erfordern in der Regel erhebliche Vorab- und laufende Investitionen. Zunächst müssen Unternehmen das Produkt integrieren. Dies ist mit Entwicklungsarbeit verbunden, um Daten über relevante Ereignisse und Zahlungen zu übermitteln. Anschließend müssen Unternehmen eine Integration vornehmen, um Zahlungs-Labels – eine Kategorisierung, ob es sich um eine betrügerische Transaktion handelt oder nicht – von ihrem Zahlungsabwickler an den Betrugserkennungs-Dienstleister weiterzuleiten bzw. Zahlungen manuell zu kennzeichnen, was extrem zeitaufwändig und fehleranfällig sein kann. Radar hingegen erhält „Ground Truth“-Informationen direkt aus dem üblichen Stripe-Zahlungsfluss und greift auf aktuelle und genaue Daten direkt von den Kartennetzwerken und -ausstellern zu – ganz ohne Entwicklungszeit oder Coding-Aufwand.

Werfen wir einen genaueren Blick auf das maschinelle Lernen und wie wir dieses bei Stripe einsetzen.

Die Grundlagen des maschinellen Lernens

Maschinelles Lernen bezieht sich auf eine Reihe von Techniken, mit denen aus großen Datenmengen Modelle erstellt werden können, mit denen sich Ergebnisse vorhersagen lassen, beispielsweise die Wahrscheinlichkeit, dass eine Zahlung zu einem Betrugsfall wird.

Eine der Hauptanwendungen des maschinellen Lernens ist die Vorhersage: Wir möchten den Wert einer Ausgangsvariablen anhand von Eingabewerten vorhersagen. In unserem Fall ist der Ausgabewert „wahr“, wenn die Zahlung betrügerisch ist und „falsch“, wenn sie nicht betrügerisch ist (derartige binäre Werte werden als boolesch bezeichnet). Ein Beispiel für einen Eingabewert könnte das Land der Kartenausstellung oder die Anzahl der verschiedenen Länder sein, in denen die Karte im Stripe-Netzwerk am vergangenen Tag eingesetzt wurde. Auf der Grundlage früherer Beispiele für Eingabe- und Ausgabedaten legen wir fest, wie eine Vorhersage zu treffen ist.

Daten, die zum Trainieren (oder Generieren) von Modellen verwendet werden, bestehen aus Datensätzen (häufig aus historischen Daten), die sowohl den Ausgabewert als auch die verschiedenen Eingabewerte enthalten, wie im folgenden (stark vereinfachten) Beispiel dargestellt:

Während in diesem Beispiel nur drei Eingaben vorhanden sind, weisen Modelle für maschinelles Lernen in der Praxis oft Hunderte oder Tausende von Eingaben auf. Die Ausgabe des Algorithmus für maschinelles Lernen könnte ein Modell wie der folgende Entscheidungsbaum sein:

Wenn wir eine neue Transaktion betrachten, sehen wir uns die Eingabewerte an und durchlaufen den Baum im „Twenty-Questions-Stil“, bis wir eines seiner „Blätter“ erreichen. Jedes Blatt besteht aus allen Stichproben im Datensatz (die Tabelle oben), die die Frage-Antwort-Paare entlang des Pfades erfüllen, dem wir den Baum hinunter gefolgt sind. Die Wahrscheinlichkeit, dass wir glauben, dass die neue Transaktion betrügerisch ist, ist die Anzahl der Stichproben im Blatt, die betrügerisch sind, geteilt durch die Gesamtzahl der Stichproben im Blatt. Anders ausgedrückt, der Baum beantwortet die Frage: „Welcher Anteil der Transaktionen in unserem Datensatz mit ähnlichen Eigenschaften wie die Transaktion, die wir gerade untersuchen, war tatsächlich betrügerisch?“ Das maschinelle Lernen befasst sich mit der Konstruktion des Baums – welche Fragen stellen wir in welcher Reihenfolge, um die Chancen zu maximieren, dass wir genau zwischen den beiden Klassen unterscheiden können? Entscheidungsbäume sind besonders einfach zu visualisieren und zu verstehen, aber es gibt viele verschiedene Lernalgorithmen, von denen jeder die Beziehungen, die wir zu modellieren versuchen, auf seine eigene Weise abbildet.

Die heutigen Modelle für maschinelles Lernen sind weit verbreitet – hinter den Kulissen versorgen sie viele der Produkte, mit denen wir häufig interagieren – und sind in der Regel viel raffinierter als das Spielzeugmodell oben:

• Google liefert mit seiner Funktion „Meintest Du?“ in der Suche genaue und präzise Vorschläge, indem maschinelles Lernen Millionen von sprachbezogenen Parametern in weniger als drei Sekunden modelliert.
  
• Amazon setzt maschinelles Lernen ein, um mit seinem Empfehlungssystem Käufe auf der Grundlage der Bedürfnisse, Vorlieben und sich ändernden Verhaltensweisen der Nutzer/innen auf der gesamten Plattform vorherzusagen, sogar für neue Nutzer/innen ohne historische Daten.
  

Relevant für unsere Diskussion ist das maschinelle Lernen, auf dessen Grundlage Stripe Radar vorhersagen kann, welche Zahlungen betrügerisch sind.

Wie funktioniert maschinelles Lernen?

Akademische Lehrveranstaltungen zum maschinellen Lernen konzentrieren sich in der Regel auf den Modellierungsprozess – die Methoden zur Übersetzung von Daten (beispielsweise die obige Tabelle) in Modelle (beispielsweise den Entscheidungsbaum), d. h. die Algorithmen, die sagen, wie Eingabewerte (das Land, in dem die Karte ausgestellt wurde, die Anzahl der Länder, in denen die Karte verwendet wurde usw.) den Ausgabewerten zugeordnet werden (war die Transaktion betrügerisch oder nicht?). Der Prozess, der aus der Eingabetabelle oben den „besten“ Baum erzeugt, stellt ein Beispiel für eine bestimmte Methode des maschinellen Lernens dar. Die Modellierung umfasst eine Reihe von Schritten, die von der Art Ihrer Daten und den von Ihnen gewählten Modellen abhängen. Wir wollen hier nicht zu sehr ins Detail gehen, aber es folgt ein Überblick auf hohem Niveau.

Als Erstes müssen wir Trainingsdaten beschaffen. Bevor wir mit der automatischen Betrugserkennung beginnen können, benötigen wir einen Datensatz mit entsprechenden Beispielen. Für jedes Beispiel müssen wir eine Reihe von Eingabeeigenschaften erfasst haben (oder im Nachhinein berechnen können), die für Vorhersagen über den Ausgabewert nützlich sein könnten. Diese Eingabeeigenschaften werden als Funktionen bezeichnet. Die Zusammenstellung der Eingaben für eine bestimmte Stichprobe ist ein Funktionsvektor. In unserem obigen Beispiel hatte der Funktionsvektor eine Länge von drei (das Land, in dem die Karte ausgestellt wurde, die Anzahl der Länder, in denen die Karte am vergangenen Tag verwendet wurde und der Zahlungsbetrag in USD).

Jedoch sind Funktionsvektoren mit Hunderten oder Tausenden von Funktionen keine Seltenheit. Tatsächlich verwendet Radar Hunderte von Funktionen und die meisten davon sind Aggregate, die aus dem gesamten Stripe-Netzwerk berechnet werden. Mit zunehmender Größe unseres Netzwerks wird jede Funktion informativer, da unsere Trainingsdaten immer repräsentativer für den gesamten Datensatz der Funktion werden, einschließlich sämtlicher Nicht-Stripe-Daten. Der Ausgabewert – in unserem laufenden Beispiel die boolesche Aussage, ob die Transaktion betrügerisch war oder nicht – wird oft als Ziel oder Label bezeichnet. Die Trainingsdaten bestehen also aus einer großen Anzahl von Funktionsvektoren und ihren entsprechenden Ausgabewerten.

Als Zweites müssen wir ein Modell trainieren. Angesichts der Trainingsdaten benötigen wir eine Methode zur Erstellung unseres Vorhersagemodells. Klassifizierer für maschinelles Lernen geben in der Regel nicht nur ein Klassenlabel aus, sondern weisen jeder möglichen Klasse Wahrscheinlichkeiten für die Zugehörigkeit der gegebenen Probe zu. Die Ausgabe eines Betrugsklassifizierers könnte zum Beispiel die Bewertung sein, dass die Zahlung mit 65 % Wahrscheinlichkeit betrügerisch und mit 35 % Wahrscheinlichkeit legitim ist.

Es gibt zahlreiche Techniken des maschinellen Lernens, die zum Trainieren von Modellen verwendet werden können. Für die meisten Anwendungen des maschinellen Lernens in der Industrie sind traditionelle Ansätze wie lineare Regression, Entscheidungsbäume oder Random Forests (Zufallswälder) gut geeignet.

Allerdings sind für viele Fortschritte in diesem Bereich ausgefeilte Techniken verantwortlich, nämlich neuronale Netze und Deep Learning, die von der Architektur der Neuronen im Gehirn inspiriert sind, wie z. B. AlphaFold's Vorhersagen für 98 % aller menschlichen Proteine. Die wirklichen Vorteile neuronaler Netze kommen aber erst dann zum Tragen, wenn sie mit sehr großen Datensätzen trainiert werden, so dass viele Unternehmen in der Praxis nicht in der Lage sind, sie voll auszunutzen. Dank der Größe unseres Netzwerks ist Stripe in der Lage, diesen innovativeren Ansatz zu verfolgen, um unseren Nutzer/innen konkrete Ergebnisse zu liefern. Unsere neuen Modelle haben die Leistung des maschinellen Lernens bei Radar im Vergleich zum Vorjahr um über 20 % verbessert und uns dabei geholfen, mehr Betrugsfälle zu erkennen und gleichzeitig die Zahl der False Positives gering zu halten.

Feature Engineering

Einer der am stärksten involvierten Teile des industriellen maschinellen Lernens ist das Feature Engineering. Es umfasst zwei Teile:
Erstens die Formulierung von Funktionen mit Vorhersagewert auf der Grundlage umfassender Kenntnisse des Problembereichs und zweitens die Werte dieser Funktionen sowohl für das Modelltraining als auch für die Evaluierung des Modells in der „Produktion“ verfügbar zu machen.

Bei der Formulierung einer Funktion könnte ein/e Datenwissenschaftler/in von Stripe die Annahme treffen, dass eine nützliche Funktion darin bestehen würde, zu berechnen, ob die Kartenzahlung von einer IP-Adresse stammt, die für diese Karte üblich ist. Zum Beispiel ist eine Kartenzahlung, die von IP-Adressen stammt, die schon einmal beobachtet wurden (z. B. der Wohnort oder der Arbeitsplatz des Karteninhabers/der Karteninhaber/in), weniger wahrscheinlich betrügerisch, als wenn die IP-Adresse aus einem anderen Staat stammt. In diesem Fall ist die Idee sehr naheliegend, aber im Allgemeinen beruhen diese Annahmen auf der Untersuchung tausender von Betrugsfällen. Beispielsweise mag es Sie überraschen, dass die Berechnung der Differenz zwischen der Uhrzeit auf dem Gerät des Nutzers/der Nutzerin und der aktuellen koordinierten Weltzeit (UTC) oder die Anzahl der Länder, in denen die Karte erfolgreich autorisiert wurde, bei der Betrugserkennung helfen.

Sobald wir eine Idee für die Funktion haben, müssen wir ihre historischen Werte berechnen, damit wir ein neues Modell trainieren können, das die Funktion enthält – so läuft es ab, wenn wir eine neue Spalte zur „Tabelle“ der Daten hinzufügen, die wir zur Erstellung unseres Modells verwenden. Um dies für unsere Funktion zu erreichen, müssen wir für jede Zahlung in der Historie von Stripe die zwei häufigsten IP-Adressen berechnen, von denen aus die vorhergehenden Zahlungen mit der Karte getätigt wurden. Wir könnten dies auf verteilte Weise mit einem Hadoop-Job tun, aber selbst dann könnte es sein, dass der Job zu viel Zeit (oder Speicher) benötigt. Dann könnten wir versuchen, die Berechnung zu optimieren, indem wir eine platzsparende probabilistische Datenstruktur verwenden. Selbst für Funktionen, die intuitiv einfach sind, erfordert die Erstellung von Daten für das Modelltraining eine spezielle Infrastruktur und etablierte Workflows.

Nicht alle Funktionen müssen von den Entwickler/innen manuell erarbeitet werden. Einige können dem Modell überlassen werden, um sie zu berechnen und vor der Implementierung zu testen. Kategorische Werte wie das Ursprungsland einer Karte oder der Händler, der eine Transaktion abgewickelt hat (im Gegensatz zu numerischen Funktionen), eignen sich gut für diesen Ansatz. Diese Funktionen weisen häufig eine große Bandbreite an Werten auf und dies gut darzustellen, kann sehr herausfordernd sein.

Bei Stripe werden Modelle trainiert, um auf der Grundlage von Transaktionsmustern eine Einbettung für jeden Händler zu lernen. Eine Einbettung kann man sich als Koordinaten des einzelnen Händlers im Vergleich zu anderen vorstellen. Ähnliche Händler haben oft ähnliche Einbettungen (gemessen anhand der Kosinus-Ähnlichkeit), so dass das Modell das Gelernte von einem Händler auf den nächsten übertragen kann. Die folgende Tabelle zeigt, wie diese Einbettungen aussehen könnten, da Uber und Lyft einander wahrscheinlich mehr ähneln als Slack. Bei Stripe werden Einbettungen für eine Vielzahl kategorischer Funktionen verwendet, z. B. für die ausstellende Bank, das Land des Händlers und des Nutzers/der Nutzerin, den Wochentag usw.

Der Einsatz von Einbettungen ist bei groß angelegten industriellen Anwendungen für maschinelles Lernen immer häufiger anzutreffen. Worteinbettungen wie diese helfen zum Beispiel dabei, die komplexen semantischen Beziehungen zwischen Wörtern zu erfassen, und waren an Meilensteinen der Verarbeitung natürlicher Sprache wie Word2Vec, BERT und GPT-3 beteiligt. Stripe erzeugt Einbettungen, um Ähnlichkeitsbeziehungen zwischen verschiedenen Entitäten im Stripe-Netzwerk auf die gleiche Weise zu erfassen, wie die oben genannten Methoden Ähnlichkeiten zwischen Wörtern erfassen. Einbettungen sind eine leistungsfähige Methode, um Konzepte auf höherer Ebene ohne explizites Training zu lernen. Zum Beispiel sind Betrugsmuster oft geografisch ungleich verteilt, und wenn unser System mit Hilfe von Einbettungen ein neues Betrugsmuster in Brasilien identifiziert, kann es ohne weiteres Training automatisch dasselbe Muster in den USA erkennen. Auf diese Weise helfen algorithmische Fortschritte, den sich verändernden Betrugsmustern voraus zu sein und unsere Kund/innen zu schützen.

Evaluierung von Modellen für maschinelles Lernen

Nachdem wir ein Modell für maschinelles Lernen zur Klassifizierung von Betrug entwickelt haben, das Hunderte von Funktionen einsetzt und jeder eingehenden Transaktion eine Wahrscheinlichkeit (oder einen Wert) zuweist, dass es sich um eine betrügerische Zahlung handelt, müssen wir bestimmen, wie effektiv das Modell bei der Betrugserkennung ist.

Schlüsselbegriffe

Um besser zu verstehen, wie wir unsere Systeme für maschinelles Lernen evaluieren, ist es sinnvoll, einige Schlüsselbegriffe zu definieren.

Nehmen wir an, wir haben eine Richtlinie erstellt, die eine Zahlung blockt, wenn das Modell für maschinelles Lernen der Transaktion eine Betrugswahrscheinlichkeit von mindestens 0,7 zuweist. (Wir schreiben dies als P(Betrug) > 0,7). Hier sind einige Größen, die zur Beurteilung der Leistung unseres Modells und unserer Richtlinie hilfreich sind:

– Precision: Die Precision unserer Richtlinie ist der Anteil der von uns geblockten Transaktionen, die tatsächlich betrügerisch sind. Je höher die Precision ist, desto weniger False Positives gibt es. Nehmen wir an, von 10 Transaktionen ist P(Betrug) > 0,7 für sechs und von diesen sechs sind vier tatsächlich betrügerisch. Die Precision beträgt dann 4/6=0,66.

– Recall: Der Recall, auch Sensitivität oder True-Positive-Quote genannt, ist der Anteil aller Betrugsfälle, die durch unsere Richtlinie erkannt werden, d. h. der Anteil der Betrugsfälle, für die P(Betrug) > 0,7 ist. Je höher der Recall ist, desto weniger False Negatives gibt es. Nehmen wir an, von 10 Transaktionen sind fünf tatsächlich betrügerisch. Wird vier dieser Transaktionen von unserem Modell ein P(Betrug) > 0,7 zugewiesen, beträgt der Recall 4/5 = 0,8.

– False-Positive-Quote: Die False-Positive-Quote ist der Anteil aller legitimen Zahlungen, die von unserer Richtlinie fälschlicherweise blockiert werden. Nehmen wir an, von 10 Transaktionen sind fünf legitim. Wird zwei dieser Transaktionen von unserem Modell ein P(Betrug) > 0,7 zugewiesen, dann beträgt die False-Positive-Quote 2/5 = 0,4.

Obwohl es noch weitere Größen gibt, die bei der Evaluierung eines Klassifizierers berücksichtigt werden, werden wir uns auf diese drei konzentrieren.

Precision-Recall- und ROC-Kurven

Die nächste Frage ist natürlich, welche Werte für Precision, Recall und False-Positive-Quote gut sind. In einer theoretisch idealen Welt wäre die Precision 1,0 (100 % der als Betrug eingestuften Transaktionen sind tatsächlich Betrug), womit die False-Positive-Quote 0 wäre (keine einzige legitime Transaktion wurde fälschlicherweise als Betrug eingestuft), und der Recall wäre ebenfalls 1,0 (100 % der Betrugsfälle werden als solche erkannt).

In der Realität gibt es einen Kompromiss zwischen Precision und Recall – je höher der Wahrscheinlichkeitsschwellenwert für die Blockierung, desto höher die Precision (da das Kriterium für die Blockierung strenger ist) und desto geringer der Recall (da weniger Transaktionen das hohe Wahrscheinlichkeitskriterium erfüllen). Für ein bestimmtes Modell zeigt eine Precision-Recall-Kurve den Kompromiss zwischen Precision und Recall, wenn der Richtlinienschwellenwert variiert wird:

Während unser Modell immer besser wird – durch das Trainieren mit immer mehr Daten aus dem gesamten Stripe-Netzwerk, das Hinzufügen von Funktionen, die gute Prognosen für Betrug liefern, und das Optimieren weiterer Modellparameter – ändert sich die Precision-Recall-Kurve, wie oben im Beispiel zu sehen ist. Da es den Kompromiss für Unternehmen bei Stripe steuert, überwachen wir die Auswirkungen auf die Precision-Recall-Kurve genau, wenn unsere Datenwissenschaftler/innen und Entwickler/innen für maschinelles Lernen Modelle ändern.

Bei der Betrachtung eines Precision-Recall-Diagramms ist es wichtig, zwischen den beiden Bedeutungen von „Leistung“ zu unterscheiden. Für sich genommen ist ein Modell umso besser, je mehr es sich dem oberen rechten Rand des Diagramms nähert (wo Precision sowie Recall 1,0 betragen). Die Operationalisierung eines Modells erfordert jedoch in der Regel die Auswahl eines Betriebspunkts auf der Precision-Recall-Kurve (in unserem Fall der Schwellenwert für das Blocken einer Transaktion), der die konkreten Auswirkungen des Modells auf ein Unternehmen bestimmt.

Kurz gesagt gibt es zwei Probleme:

– Das datenwissenschaftliche Problem der Entwicklung eines guten Modells für das maschinelle Lernen mittels Hinzufügen der richtigen Funktionen. Das Modell steuert die Form der Precision-Recall-Kurve.

– Das unternehmerische Problem der Auswahl einer Richtlinie für die Entscheidung darüber, wie viele potenzielle Betrugsfälle zu blocken sind. Die Richtlinie steuert, wo auf der Kurve wir arbeiten.

Eine weitere Kurve, die bei der Evaluierung eines Modells für maschinelles Lernen untersucht wird, ist die ROC-Kurve (receiver operating characteristic – ROC, ein Überbleibsel des Ursprungs der Kurve in der Signalverarbeitung). Die ROC-Kurve ist ein Diagramm der False-Positive-Quote (auf der x-Achse) und der True-Positive-Quote (die dem Recall entspricht) auf der y-Achse für verschiedene Werte des Richtlinienschwellenwerts.

Die ideale ROC-Kurve befindet sich oben links im Diagramm (wo der Recall bei 1,0 und die False-Positive-Quote bei 0,0 liegt), und je besser das Modell wird, desto mehr bewegt sich die ROC-Kurve in diese Richtung. Eine Möglichkeit, die Gesamtqualität des Modells zu erfassen, ist die Berechnung der Fläche unter der Kurve (area under the curve – AUC). Im Idealfall beträgt die AUC 1,0. Bei der Entwicklung unserer Modelle beobachten wir die Veränderungen der Precision-Recall-Kurve, der ROC-Kurve und der AUC.

Wertverteilungen

Angenommen, wir haben ein Modell, das einer Transaktion zufällig eine Betrugswahrscheinlichkeit zwischen 0,0 und 1,0 zuweist. In der Praxis kann dieses Modell nicht zwischen legitimen und betrügerischen Transaktionen unterscheiden und ist daher für uns von geringem Nutzen. Diese Zufälligkeit wird durch die Wertverteilung des Modells abgebildet - der Anteil der Transaktionen, die jeden möglichen Wert erhalten. Im völlig zufälligen Fall wäre die Wertverteilung in etwa ausgeglichen:

Ein Modell wird eine gleichmäßige Wertverteilung wie oben dargestellt aufweisen, wenn das Modell beispielsweise keine Funktionen hat, die auch nur im Entferntesten auf Betrug hindeuten. Wird ein Modell verbessert – etwa durch Hinzufügen von Vorhersagefunktionen, Training mit mehr Daten usw. –, nimmt seine Fähigkeit zur Unterscheidung zwischen den betrügerischen und den legitimen Klassen zu und die Wertverteilung wird bimodaler, mit Maxima bei etwa 0,0 und 1,0.

Nur weil eine bimodale Verteilung vorliegt, heißt das noch nicht, dass ein Modell gut ist. (Auch ein nichtssagendes Modell, das nach dem Zufallsprinzip Wahrscheinlichkeiten von 0,0 oder 1,0 zuweist, hätte eine bimodale Wertverteilung.) Gibt es jedoch Anhaltspunkte dafür, dass Transaktionen mit einem niedrigen Wert nicht betrügerisch und Transaktionen mit einem hohen Wert betrügerisch sind, ist eine zunehmend bimodale Verteilung ein Zeichen für eine verbesserte Wirksamkeit eines Modells.

Verschiedene Modelle haben oft verschiedene Wertverteilungen. Wenn wir neue Modelle veröffentlichen, vergleichen wir alte mit aktualisierten Verteilungen, um disruptive Änderungen zu minimieren, die durch eine plötzliche Verschiebung der Werte verursacht werden. Insbesondere berücksichtigen wir die aktuellen Blockierungsrichtlinien der Händler, gemessen an der Schwelle, ab der sie Transaktionen blockieren, und versuchen, den Anteil der Transaktionen, der über der Schwelle liegt, stabil zu halten.

Berechnung von Precision und Recall

Wir können die vorstehenden Kennzahlen in zwei verschiedenen Kontexten berechnen: zunächst im Zuge des Modelltrainings mit historischen Daten für die Modellentwicklung und dann nach der Implementierung des Modells mit Daten aus der Produktion – mit Daten aus der Welt, in der das Modell zum Einsatz kommt, um Maßnahmen zu ergreifen, wie beispielsweise das Blockieren von Transaktionen mit P(Betrug) > 0,7.

Im ersten Fall nehmen Datenwissenschaftler in der Regel die ihnen zur Verfügung stehenden Trainingsdaten (siehe die Tabelle oben) und weisen einen Teil der Datensätze nach dem Zufallsprinzip einem Trainingssatz und die anderen Datensätze einem Validierungssatz zu. Beispielsweise könnten die ersten 80 % der Zeilen in die erste und die letzten 20 % in die zweite Gruppe fallen.

Der Trainingssatz sind die Daten, die einem Verfahren des maschinellen Lernens zugeführt werden, um ein Modell wie oben beschrieben zu erstellen. Sobald ein Kandidatenmodell vorliegt, können wir damit jeder Stichprobe im Validierungssatz Werte zuweisen. Zusammen mit den Ausgabewerten dienen die Werte des Validierungssatzes zur Berechnung der ROC- und Precision-Recall-Kurven, der Wertverteilungen usw. Der Grund für die Verwendung eines separaten Validierungssatzes – getrennt vom Trainingssatz – ist, dass das Modell die Antwort für seine Trainingsbeispiele bereits „gesehen“ und aus diesen Antworten gelernt hat. Ein Validierungssatz hilft, Kennzahlen zu erstellen, die ein genaues Maß für die Vorhersagekraft des Modells für neue Daten sind.

Maschinelles Lernen: Sichere und häufige Implementierung von Modellen

Sobald sich zeigt, dass die Leistung eines Modells die des aktuellen Produktionsmodells übertrifft, besteht der nächste Schritt darin, es in der Produktion einzusetzen. Dabei gibt es zwei zentrale Herausforderungen:

• Echtzeit-Berechnungen: Wir müssen den Wert jedes Merkmals jeder neuen Zahlung in Echtzeit berechnen können, um alle Transaktionen zu blocken, die unser Klassifizierer als „wahrscheinlich betrügerisch“ einstuft. Diese Berechnung ist völlig unabhängig von der Berechnung, die der Erzeugung von Trainingsdaten dient – wir benötigen einen aktuellen Status der zwei am häufigsten verwendeten IP-Adressen für jede Karte, die jemals bei Stripe gesehen wurde. Das Abrufen und Aktualisieren dieser Zählungen muss schnell ablaufen, da diese Vorgänge als Teil des Stripe-API-Flusses stattfinden. Die Infrastrukturteams für maschinelles Lernen bei Stripe haben dies vereinfacht, indem sie Systeme zur deklarativen Festlegung von Merkmalen entwickelt haben und die aktuellen Werte der Merkmale automatisch und mit geringer Latenz in der Produktion bereitstellen.

• Reale Anwendung: Die Implementierung eines Modells für maschinelles Lernen unterscheidet sich von der Implementierung von Programmcode: Während Code-Änderungen oft mit präzisen Testfällen validiert werden, werden Modelländerungen in der Regel anhand eines großen aggregierten Datensatzes mit Kennzahlen wie den oben beschriebenen getestet. Ein Modell, das Betrugsfälle insgesamt besser erkennt, ist aber nicht unbedingt für alle Stripe-Nutzer/innen besser geeignet. Die Leistungssteigerung könnte ungleichmäßig verteilt sein, wobei einige wenige große Händler große Verbesserungen erzielen, während bei vielen kleinen Händlern kleine Rückschritte zu verzeichnen sind. Ein Modell kann einen höheren Recall aufweisen, aber einen Spitzenwert bei der Blockierquote aufweisen, was für die Unternehmen (und ihre Kund/innen) schädlich wäre. Bevor wir ein Modell freigeben, überprüfen wir, ob es in der Praxis gut funktioniert.

Dazu messen wir die Veränderung, die jedes Modell bei Kennzahlen wie False-Positive-Quote, Blockierquote und Autorisierungsquote auf aggregierter Basis und pro Händler für eine Untergruppe von Stripe-Nutzer/innen verursachen würde. Wenn wir feststellen, dass ein neues Modell eine unerwünschte Veränderung in einer dieser Kennzahlen verursacht, passen wir es für verschiedene Untergruppen von Nutzer/innen an, bevor wir es freigeben, um Störungen zu minimieren und für eine optimale Leistung zu sorgen.

Wir haben festgestellt, dass die Automatisierung eines möglichst großen Teils des Trainings- und Evaluierungsprozesses die Geschwindigkeit der Modelliterationen beschleunigt. Im letzten Jahr haben wir in Tools investiert, um Modelle unter Verwendung unserer neuesten Funktionen und Modellarchitektur automatisch und regelmäßig zu trainieren, abzustimmen und zu evaluieren. So aktualisieren wir beispielsweise kontinuierlich die Leistungs-Dashboards, nachdem ein Modell trainiert wurde – bevor es veröffentlicht wird. Auf diese Weise können Entwickler/innen leicht erkennen, ob ein Modellkandidat auf einer Teilmenge des Traffics veraltet ist, bevor dieser überhaupt freigegeben wird, und ihn proaktiv neu trainieren.

Nachdem wir ein Modell veröffentlicht haben, überwachen wir seine Leistung und arbeiten an der Folgeversion. Da sich Betrugstrends schnell ändern, kommt es bei Modellen für maschinelles Lernen schnell zu Verschiebungen: Daten, mit denen sie trainiert wurden, sind nicht mehr repräsentativ für aktuelle Betrugsfälle.

Mit diesen Tools konnten wir die Geschwindigkeit, mit der wir Modelle veröffentlichen, verdreifachen, was sich direkt in deutlichen Leistungssteigerungen in der Produktion niederschlägt. Selbst wenn wir ein Modell vom letzten Monat auf aktuellere Daten umtrainieren (mit denselben Merkmalsdefinitionen und derselben Architektur) und es dann freigeben, können wir unseren Recall jeden Monat um einen halben Prozentpunkt steigern. Da wir in der Lage sind, Modelle häufig und sicher freizugeben, können wir die Verbesserungen aus dem Feature-Engineering und der Modellierung nutzen und uns an die veränderten Betrugsmuster für Radar-Nutzer/innen anpassen.

Sobald wir ein Modell in der Produktion einsetzen, überwachen wir kontinuierlich die Leistung unseres Modell-Richtlinien-Paares. Bei Zahlungen, deren Werte unter dem Schwellenwert für das Blockieren liegen, können wir das Endergebnis beobachten: Wurde die Transaktion von dem/der Karteninhaber/in als Betrug angefochten? Zahlungen, deren Werte über dem Schwellenwert liegen, werden jedoch geblockt, so dass wir nicht wissen können, wie sie ausgegangen wären. Die Berechnung der vollständigen Precision-Recall- oder ROC-Kurve ist daher aufwändiger als die Berechnung der Validierungskurven, da sie eine kontrafaktische Analyse beinhaltet - wir müssen statistisch fundierte Schätzungen darüber erhalten, was auch mit den von uns geblockten Zahlungen passiert wäre. Im Laufe der Jahre hat Stripe hierfür Methoden entwickelt, über die Sie in diesem Vortrag weitere Informationen finden.

Wir haben einige Indikatoren für die Modellwirksamkeit beschrieben, die Datenwissenschaftler/innen und Entwickler/innen für maschinelles Lernen bei der Entwicklung von Modellen für maschinelles Lernen berücksichtigen. Als Nächstes erläutern wir, was Unternehmen bei der Betrugsprävention beachten sollten.

Wie Stripe helfen kann

Die Fixierung auf nur eine Größe zur Messung Ihrer Betrugsbekämpfung kann zu suboptimalen Entscheidungen für Ihr Unternehmen führen. Wir haben die Erfahrung gemacht, dass Unternehmen False Negatives häufig überbewerten – sie zeigen sich sehr besorgt über nicht erkannten Betrug – und False Positives unterbewerten. Dies führt häufig zu ineffektiven und teuren Brute-Force-Maßnahmen wie dem Blocken aller internationalen Karten. Generell sollten Sie sich Gedanken darüber machen, wie sich die verschiedenen Leistungsindikatoren zueinander verhalten und welche Kompromisse Sie unter Ihren individuellen Umständen eingehen sollten. Hier ein Beispiel dafür, wie diese Kennzahlen zusammenhängen, um die Wirksamkeit Ihres Betrugspräventionssystems zu bestimmen:

NÄHERUNGSMODELL FÜR DIE BREAK-EVEN-PRECISION

Wenn Ihr durchschnittlicher Verkauf 26 USD und Ihre Gewinnspanne 8 % beträgt, ist Ihr Gewinn je Verkauf 26,00 USD × 8,00 % = 2,08 USD. Wenn Ihr Produkt im Durchschnitt 26,00 USD - 2,08 USD = 23,92 USD kostet und Ihnen eine Rückbuchungsgebühr von 15 USD berechnet wird, beträgt Ihr Gesamtverlust bei einem betrügerischen Verkauf 23,92 USD + 15,00 USD = 38,92 USD. Ein betrügerischer Verkauf kostet Sie also den Gewinn von 38,92 USD / 2,08 USD = 18,7 legitimen Verkäufen und Ihre Break-Even-Precision beträgt 1 / (1 + 18,71) = 5,07 %.

Die Schwellenwerte für das maschinelle Lernen bei Radar bieten einen Kompromiss zwischen der Optimierung der Margen von Händlern und der Stabilisierung der Blockierquoten in unserer Nutzerbasis. Wenn Sie Radar for Fraud Teams verwenden, können Sie auf ein Dashboard zugreifen, um die Leistung des maschinellen Lernens von Radar für Ihr Unternehmen sowie die Leistung Ihrer benutzerdefinierten Regeln anzuzeigen. Mit diesen Tools können Sie Ihre Anfechtungsquoten, False-Positive-Quoten und Blockierquoten auf Grundlage aggregierter, benutzerdefinierter Kohorten von Unternehmen ähnlicher Branchen oder Größen mit anderen ähnlichen Unternehmen vergleichen.

Mehr Leistung mit Regeln und manuellen Prüfungen

Mit Radar for Fraud Teams können Sie Ihren Schutz optimieren, indem Sie durch Anpassung Ihrer Risikoschwelle entweder mehr Zahlungen ablehnen oder zulassen. Neben den automatischen Algorithmen für maschinelles Lernen können Unternehmen mit Radar for Fraud Teams auch individuelle Regeln aufstellen (z. B. „alle Transaktionen über 1.000 USD blockieren, wenn das Land der IP-Adresse nicht mit dem der Karte übereinstimmt“), Interventionen anfordern und markierte Zahlungen im Dashboard manuell prüfen.

Solche Regeln können als einfache „Modelle“ betrachtet werden (sie können in Form von Entscheidungsbäumen dargestellt werden) und sollten wie Modelle evaluiert werden – unter Berücksichtigung des Kompromisses zwischen Precision und Recall. Wenn Sie mit Radar eine Regel erstellen, präsentieren wir Ihnen historische Statistiken zur Anzahl passender Transaktionen, die tatsächlich angefochten, erstattet oder akzeptiert wurden, um Sie bei diesen Berechnungen zu unterstützen, noch bevor die Regel implementiert wird. Sobald die Regel in Kraft ist, können Sie die Auswirkungen auf die False-Positive- und Anfechtungsquoten nach Regel sehen.

Ebenso wichtig ist, dass Regeln, Interventionen und manuelle Überprüfungen es Nutzer/innen ermöglichen, die Form der Kurve für Precision und Recall in ihrem Sinne zu verändern, indem sie eine proprietäre, unternehmensspezifische Logik hinzufügen (Regeln) oder einen gewissen zusätzlichen Aufwand betreiben (manuelle Überprüfung).

Wenn Sie feststellen, dass die Algorithmen des maschinellen Lernens häufig eine bestimmte Art von Betrug übersehen, die bei Ihrem Unternehmen typischerweise vorkommt (und diese Betrugsart für Sie leicht zu erkennen ist), können Sie eine Regel erstellen, um diese Betrugsart zu unterbinden. Diese spezifische Intervention erhöht in der Regel den Recall bei geringem Einfluss auf die Precision und verschiebt den Betriebspunkt entlang einer weniger steilen, günstigeren Precision-Recall-Kurve.

Wenn Sie bestimmte Transaktionsklassen der manuellen Überprüfung unterwerfen, anstatt sie grundsätzlich zu blocken, können Sie die Precision erhöhen, ohne den Recall zu beeinträchtigen. Analog können Sie den Recall erhöhen, ohne die Precision zu beeinträchtigen, indem Sie einige Transaktionen manuell überprüfen, anstatt sie grundsätzlich zu blocken.
Natürlich erkaufen Sie sich diese Vorteile mit zusätzlicher menschlicher Arbeit (und setzen sich der Quote zutreffender Bewertungen Ihres Teams aus), aber mit der manuellen Überprüfung, den Regeln und den Interventionen zur Authentifizierung von Hochrisikokunden als zusätzlichen Instrumenten haben Sie einen weiteren Hebel zur Optimierung der Betrugsbekämpfung in der Hand.

Nächste Schritte

Wir hoffen, dieser Leitfaden hilft Ihnen dabei zu verstehen, wie maschinelles Lernen bei Stripe zur Betrugsprävention eingesetzt wird und wie Sie die Wirksamkeit Ihrer Betrugssysteme bewerten können. Lesen Sie mehr zu den Funktionen von Radar – oder werfen Sie einen Blick auf unsere Dokumentation.

Wenn Sie Fragen haben oder weitere Informationen über Stripe Radar benötigen, kontaktieren Sie uns einfach.