Die jüngste, massive Beschleunigung im E-Commerce hat zu einem entsprechenden Anstieg bei Betrug mit Online-Zahlungen geführt. Weltweit kostet Betrug Unternehmen Schätzungen zufolge mehr als 20 Milliarden US-Dollar jährlich. Zudem sind für jeden durch Betrug verlorenen Dollar die tatsächlichen Gesamtkosten für Unternehmen aufgrund erhöhter Betriebskosten, Netzwerkgebühren und Kundenabwanderung weitaus höher.

Betrug ist nicht nur teuer, raffinierte Betrüger finden auch ständig neue Wege, um Schwachstellen auszunutzen, was die Bekämpfung von Betrug erschwert. Aus diesem Grund haben wir Stripe Radar entwickelt, eine KI-basierte 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 Hunderten Milliarden US-Dollar, die jedes Jahr über das Stripe-Netzwerk abgewickelt werden, um Betrug genau zu erkennen und sich schnell an die neuesten Trends anzupassen, sodass Sie wachsen können, ohne dass der Betrug zunimmt.

In diesem Leitfaden stellen wir Stripe Radar vor und erläutern, wie wir das Stripe-Netzwerk zur Betrugserkennung einsetzen. Sie erhalten einen Überblick über die von uns verwendeten Techniken des maschinellen Lernens und erfahren unsere Ansichten über die Wirksamkeit und Leistung von Systemen zur Betrugserkennung. Außerdem zeigen wir, wie andere Tools aus der Radar-Produktfamilie Unternehmen helfen, ihre Betrugsbekämpfung zu optimieren.

Grundlegendes zu Online-Kreditkartenbetrug

Eine Zahlung wird als betrügerisch angesehen, wenn die Karteninhaberin oder der Karteninhaber die Zahlung nicht genehmigt. Wenn betrügerische Akteurinnen und Akteure beispielsweise einen Kauf mit einer gestohlenen Kartennummer tätigen, deren Diebstahl nicht gemeldet wurde, kann es sein, dass die Zahlung erfolgreich abgewickelt wird. Wenn die/der rechtmäßige Karteninhaber/in den Betrug bemerkt, kann sie bzw. er die Zahlung bei der Bank anfechten (und eine Rückbuchung verlangen).

Unternehmen können eine Rückbuchung anfechten, indem sie Belege für die Rechtmäßigkeit der Zahlung einreichen. Falls jedoch bei Card-Not-Present-Transaktionen (ohne Vorlage der physischen Karte) von den Netzwerken festgestellt wird, dass die Zahlung tatsächlich betrügerisch war, wird zugunsten der Karteninhaberin bzw. des Karteninhabers entschieden und das Unternehmen muss für den Verlust von Waren und für Gebühren aufkommen.

In der Vergangenheit haben Unternehmen Brute-Force-Regeln eingesetzt, um mutmaßlich betrügerische Transaktionen vorherzusagen und zu blockieren. Fest programmierte Regeln, wie etwa das Blockieren aller im Ausland verwendeten Kreditkarten, können jedoch dazu führen, dass auch zahlreiche legitime Transaktionen unmöglich werden. Mithilfe von maschinellem Lernen lassen sich heute differenziertere Muster erkennen, die Ihnen helfen, Ihren Umsatz zu maximieren. Im Zusammenhang mit maschinellem Lernen ist der Begriff „False Negative“ (falsch negatives Ergebnis) gebräuchlich, wenn das System etwas übersieht, das eigentlich hätte erkannt werden sollen – in diesem Fall eine betrügerische Transaktion. „False Positive“ (falsch positives Ergebnis) bedeutet, dass das System eine legitime Transaktion fälschlicherweise als betrügerisch einstuft und blockiert. Bevor wir uns genauer mit maschinellem Lernen befassen, müssen wir uns Einblick in die damit verbundenen Kompromisse verschaffen.

Bei „False Negatives“ (falsch negative Ergebnisse) müssen Unternehmen häufig den ursprünglichen Transaktionsbetrag zuzüglich der Rückbuchungsgebühren (die Kosten, die mit der Rückbuchung der Kartenzahlung durch die Bank verbunden sind), die höheren Netzwerkgebühren infolge der angefochtenen Zahlung und höhere Betriebskosten für die Überprüfung von Abbuchungen oder die Bearbeitung von Anfechtungen tragen. Wenn es zu viele angefochtene Zahlungen gibt, wird Ihr Unternehmen möglicherweise in ein Überwachungsprogramm für Rückbuchungen aufgenommen. Dies kann höhere Kosten bedeuten oder in einigen Fällen sogar dazu führen, dass die Annahme von Kartenzahlungen nicht mehr möglich ist.

Falsch-positive Ergebnisse oder falsche abgelehnte Zahlungen liegen vor, wenn eine legitime Kundin oder ein legitimer Kunde versucht, einen Kauf zu tätigen, aber daran gehindert wird. Falsche abgelehnte Zahlungen können dazu führen, dass das Unternehmen sowohl einen Verlust des Bruttogewinns als auch einen Reputationsschaden erleidet. Tatsächlich gaben in einer aktuellen Umfrage 33 % der Verbraucherinnen und Verbraucher an, dass sie nach einer falschen abgelehnten Zahlung nicht wieder bei einem Unternehmen einkaufen würden.

Es ist ein permanentes Abwägen zwischen dem Vermeiden von Anfechtungen (False Negatives) einerseits und dem Blockieren legitimer Kundinnen und Kunden (False Positives) andererseits: Je stärker Sie sich auf Ersteres konzentrieren, desto mehr müssen Sie von Letzterem hinnehmen (oder umgekehrt). Wenn Sie mehr Betrug vermeiden, steigt der Anteil der blockierten legitimen Kundinnen und Kunden. Andererseits führt die Reduzierung der falsch positiven Ergebnisse häufig dazu, dass die Wahrscheinlichkeit nicht erkannter Betrugsversuche steigt. Unternehmen müssen basierend auf ihren Margen, ihrem Wachstumsprofil und anderen Faktoren entscheiden, wie sie diese beiden Aspekte gegeneinander abwägen.

Wenn die Margen eines Unternehmens klein sind, wie etwa bei Online-Lebensmittelhändlern, müssen die Kosten einer betrügerischen Transaktion durch Hunderte von legitimen Transaktionen ausgeglichen werden. In dieser Konstellation ist jedes falsch negative Ergebnis sehr kostspielig. Unternehmen mit diesem Profil tendieren unter Umständen eher dazu, ein sehr weites Netz zur Bekämpfung von potenziellem Betrug zu spannen. Für Unternehmen mit hohen Margen, wie etwa SaaS-Anbieter, gilt das Gegenteil. Der entgangene Gewinn aus blockierten, legitimen Kundentransaktionen ist eventuell höher als die Kosten, die durch mehr Betrug anfallen.

Stripe Radar und das Stripe-Netzwerk

Radar ist die Lösung zur Betrugsprävention von Stripe, die Unternehmen vor Kreditkartenbetrug im Internet schützt. Die Lösung basiert auf adaptivem maschinellem Lernen und ist das Ergebnis jahrelanger Data-Science- und Infrastrukturarbeit der speziellen Teams für maschinelles Lernen von Stripe. Die Radar-Algorithmen werten jede Transaktion im Hinblick auf ein mögliches Betrugsrisiko aus und ergreifen entsprechende Maßnahmen. Zahlungen mit hohem Risiko werden blockiert. Radar Plus stellt zudem 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.

Einer der Hauptanwendungsbereiche des maschinellen Lernens sind Vorhersagen: Wir möchten den Wert einer Ausgabevariablen bei Vorliegen bestimmter Eingabewerte vorhersagen. In unserem Fall ist der Ausgabewert „True“ (Wahr), wenn die Zahlung betrügerisch ist, andernfalls „False“ (Falsch). Solche binären Werte werden als Booleans bezeichnet. Ein Beispiel für einen Eingabewert ist das Land, in dem die Karte ausgestellt wurde, oder die Anzahl der verschiedenen Länder, in denen die Karte im gesamten Stripe-Netzwerk am vergangenen Tag verwendet wurde. Wir legen auf Basis früherer Beispiele von Eingabe- und Ausgabedaten fest, wie wir Vorhersagen treffen.

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, sodass 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), sodass 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 mithilfe 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.

Für sich genommen bedeutet eine bimodale Verteilung nicht, dass ein Modell gut ist. (Auch ein leeres Modell, das zufällig Wahrscheinlichkeiten von lediglich 0,0 und 1,0 zuweist, hätte eine bimodale Score-Verteilung.) Gibt es jedoch Beweise dafür, dass Transaktionen mit einem niedrigen Score nicht betrügerisch und Transaktionen mit einem hohen Score betrügerisch sind, ist eine zunehmend bimodale Verteilung ein Zeichen für die verbesserte Wirksamkeit eines Modells.

Verschiedene Modelle weisen oftmals unterschiedliche Score-Verteilungen auf. Bei der Veröffentlichung neuer Modelle vergleichen wir die alten und die aktualisierten Verteilungen miteinander, um störende Änderungen durch plötzliche Verschiebungen bei Scores so weit wie möglich zu verringern. Insbesondere berücksichtigen wir die aktuellen Blockierungsrichtlinien von Händlerinnen und Händlern anhand des Schwellenwerts, ab dem sie Transaktionen blockieren. Zudem achten wir darauf, dass der Anteil der Transaktionen, der über diesem Schwellenwert liegt, stabil bleibt.

Berechnen von Präzision und Recall

Wir können die oben genannten Metriken in zwei verschiedenen Kontexten berechnen: während des Modelltrainings unter Verwendung der historischen Daten, die den Modellentwicklungsprozess steuern, und nach der Bereitstellung des Modells unter Verwendung von Produktionsdaten. Dabei handelt es sich um Daten aus der Praxis, wenn das Modell bereits eingesetzt wird, um Maßnahmen zu ergreifen, etwa indem Transaktionen blockiert werden, wenn P (Betrug) > 0,7.

Für den erstgenannten Fall nutzen Data-Scientists für gewöhnlich die ihnen zur Verfügung stehenden Trainingsdaten (siehe Tabelle oben) und weisen einen Teil der Datensätze per Zufallsprinzip einem Trainingssatz und die anderen Datensätze einem Validierungssatz zu. Man könnte sich zum Beispiel vorstellen, dass die ersten 80 % der Zeilen in den Trainingssatz und die letzten 20 % in den Validierungssatz einfließen.

Der Trainingssatz besteht aus den Daten, die in eine Methode des maschinellen Lernens eingespeist werden, um, wie oben beschrieben, ein Modell zu erstellen. Sobald uns ein potenzielles Modell vorliegt, können wir ihm Scores für jede Stichprobe im Validierungssatz zuweisen. Die Validierungssatz-Scores werden zusammen mit ihren Ausgabewerten genutzt, um die ROC- und Präzisions-Recall-Kurven, die Score-Verteilungen usw. zu berechnen. Wir verwenden deshalb einen separaten Validierungssatz, der vom Trainingssatz abweicht, da das Modell die Antwort auf seine Trainingsbeispiele bereits „gesehen“ und daraus gelernt hat. Durch einen Validierungssatz können wir Metriken generieren, die bei neuen Daten einen exakten Wert für die Aussagekraft des Modells liefern.

Machine Learning Operations: sichere und häufige Modellbereitstellungen

Nachdem sich erwiesen hat, dass ein Modell bei einem vorenthaltenen Datensatz eine bessere Leistung erzielt als das aktuelle Produktionsmodell, wird es in einem nächsten Schritt für die Produktion bereitgestellt. Dieser Prozess ist mit zwei wesentlichen Herausforderungen verbunden:

• Echtzeitberechnungen: Wir müssen in der Lage sein, den Wert jeder Funktion für jede neue Zahlung in Echtzeit zu berechnen. Schließlich wollen wir jede Transaktion blockieren können, die von unserer Klassifizierung als wahrscheinlich betrügerisch eingestuft wird. Diese Berechnung wird vollständig getrennt von derjenigen zur Erstellung von Trainingsdaten durchgeführt. Wir müssen für jede Karte, die jemals bei Stripe gesehen wurde, einen aktuellen Status für die beiden am häufigsten verwendeten IP-Adressen verwalten. Der Abruf und die Aktualisierung dieser Zählungen müssen zügig erfolgen, da diese Vorgänge Teil des API-Ablaufs von Stripe sind. Die Teams für die Machine Learning-Infrastruktur von Stripe haben diesen Prozess vereinfacht, indem sie Systeme entwickelt haben, um Funktionen auf deklarative Weise zu spezifizieren und die aktuellen Werte der Funktionen automatisch in der Produktion mit geringer Latenz verfügbar zu machen.

• Nutzeranwendung in der Praxis: Die Bereitstellung eines Modells für maschinelles Lernen ist nicht dasselbe wie die Bereitstellung von Code. Während Codeänderungen oftmals anhand genauer Testfälle validiert werden, werden Modelländerungen in der Regel an einem großen aggregierten Datensatz unter Verwendung von Metriken wie den oben definierten getestet. Es muss jedoch nicht sein, dass ein Modell, das Betrug insgesamt besser erkennt, auch für alle Stripe-Nutzer/innen besser ist. Unter Umständen ist die Leistungsverbesserung ungleichmäßig verteilt, sodass einige wenige große Händler/innen starke Zuwächse verzeichnen, während es bei vielen kleinen Händlerinnen und Händlern zu leichten Rückgängen kommt. Ein Modell weist möglicherweise einen höheren Recall auf, führt jedoch zu einem sprunghaften Anstieg der Blockierungsrate, was sich störend auf Unternehmen (und deren Kundinnen und Kunden) auswirkt. Bevor wir ein Modell veröffentlichen, verifizieren wir, dass es auch in der Praxis eine gute Leistung erbringt. Zu diesem Zweck messen wir für eine Untergruppe von Stripe-Nutzerinnen und -Nutzern aggregiert und händlerbasiert, welche Veränderungen jedes Modell bei einer Vielzahl von Metriken wie beispielsweise der Falsch-Positiv-Rate, der Blockierungsrate und der Autorisierungsrate bewirken würde. Stellen wir fest, dass ein neues Modell eine unerwünschte Verschiebung bei einer dieser Kontrollmetriken verursachen würde, passen wir es vor der Veröffentlichung für verschiedene Nutzeruntergruppen an, um Störungen auf ein Minimum zu reduzieren und eine optimale Leistung zu gewährleisten.

Wir haben festgestellt, dass eine möglichst weitgehende Automatisierung des Trainings- und Evaluierungsprozesses immer mehr Vorteile für die Iterationsgeschwindigkeit von Modellen bietet. Im vergangenen Jahr haben wir in Tools investiert, um Modelle mit unseren neuesten Funktionen und unserer neuesten Modellarchitektur automatisch und regelmäßig zu trainieren, abzustimmen und zu evaluieren. Zum Beispiel aktualisieren wir Leistungs-Dashboards laufend, nachdem ein Modell trainiert wurde – und zwar noch vor dessen Veröffentlichung. Auf diese Weise können Techniker/innen ganz einfach feststellen, ob eine Modellvariante bei einer Teilmenge des Datenverkehrs veraltet ist, noch bevor sie sie veröffentlichen, und sie proaktiv neu trainieren.

Nachdem wir ein Modell veröffentlicht haben, überwachen wir seine Leistung und beginnen mit den Vorbereitungen für die nächste Veröffentlichung. Da sich Betrugstrends schnell ändern, ist bei Machine Learning-Modellen rasch ein sogenannter „Drift“ zu beobachten: Die Daten, mit denen sie trainiert wurden, sind nicht mehr repräsentativ für den heutigen Betrug.

Durch den Einsatz dieser Tools konnten wir die Geschwindigkeit, mit der wir Modelle veröffentlichen, verdreifachen, was unmittelbar zu erheblichen Leistungssteigerungen in der Produktion führt. Tatsächlich können wir durch das erneute Training eines Modells aus dem Vormonat mit aktuelleren Daten (unter Verwendung derselben Funktionsdefinitionen und Architektur) und dessen anschließende Veröffentlichung unseren Recall jeden Monat um bis zu einen halben Prozentpunkt steigern. Wenn wir Modelle häufig und sicher veröffentlichen können, können wir die Gewinne aus der Entwicklung von Funktionen und der Modellierung nutzen und weiter ausbauen sowie uns an die veränderten Betrugsmuster von Radar-Nutzerinnen und -Nutzern anpassen.

Sobald wir ein Modell in die Produktion überführen, überwachen wir fortwährend die Leistung des Paars aus Modell und Richtlinie. Bei Zahlungen mit Scores unterhalb des Schwellenwerts für die Blockierung können wir das endgültige Ergebnis ablesen: Wurde die Transaktion von der karteninhabenden Person aufgrund von Betrug angefochten? Zahlungen, deren Scores über dem Schwellenwert liegen, werden jedoch blockiert. Daher können wir nicht wissen, wie sie ausgegangen wären. Die Berechnung der vollständigen Präzisions-Recall- oder ROC-Kurve für die Produktion ist also aufwendiger als die Berechnung der Validierungskurven, da sie eine kontrafaktische Analyse erfordert. Wir müssen statistisch fundierte Schätzungen darüber einholen, was passiert wäre, selbst wenn die Zahlungen blockiert worden wären. Im Laufe der Jahre hat Stripe Methoden hierfür entwickelt. Weitere Informationen hierzu erhalten Sie in diesem Video.

Wir haben soeben einige der Maßnahmen zur Messung der Modelleffizienz beschrieben, die Data-Scientists und Techniker/innen für maschinelles Lernen bei der Entwicklung von Modellen für maschinelles Lernen berücksichtigen. Als Nächstes werden wir erörtern, wie Unternehmen über das Thema Betrugsprävention denken sollten.

So kann Stripe Sie unterstützen

Wer sich bei der Erfassung seiner Betrugsleistung auf nur eine Zahl konzentriert, trifft unter Umständen Entscheidungen, die für das eigene Unternehmen nicht optimal sind. Wir haben festgestellt, dass Unternehmen falsch negativen Ergebnissen oftmals eine zu große und falsch positiven Ergebnissen eine zu kleine Bedeutung beimessen (sie befürchten sehr, dass unentdeckte Betrugsfälle übersehen werden). Diese Denkweise führt häufig zu unwirksamen und kostspieligen „Brute-Force-Maßnahmen“, wie der Sperrung aller internationalen Karten. Ganz generell sollten Sie überlegen, wie all die verschiedenen Leistungskennzahlen zusammenhängen und welche Kompromisse angesichts Ihrer spezifischen Umstände die richtigen sind. Hier ist ein Beispiel dafür, wie diese Metriken zusammenhängen, um Ihnen bei der Ermittlung der Wirksamkeit Ihres Betrugspräventionssystems zu helfen:

NÄHERUNGSMODELL FÜR DIE BREAK-EVEN-PRÄZISION

Wenn Ihr durchschnittlicher Umsatz 26,00 USD bei einer Marge von 8 % beträgt, beläuft sich Ihr Gewinn pro Verkauf auf 26,00 USD × 8,00 % = 2,08 USD. Wenn Ihr Produkt im Durchschnitt 26,00 USD – 2,08 USD = 23,92 USD in der Herstellung kostet und Ihnen eine Rückbuchungsgebühr von 15,00 USD in Rechnung gestellt wird, beläuft sich Ihr Gesamtverlust bei einem betrügerischen Verkauf auf 23,92 USD + 15,00 USD = 38,92 USD. Folglich kostet Sie ein betrügerischer Verkauf den Gewinn aus 38,92 USD / 2,08 USD = 18,71 legitimen Verkäufen und Ihre Break-Even-Präzision liegt bei 1 / (1 + 18,71) = 5,07 %.

Die Schwellenwerte für maschinelles Lernen von Radar stellen einen Kompromiss zwischen der Optimierung der Händlermargen und der Stabilisierung der Blockierungsraten in unserem Nutzerstamm dar. Über ein Dashboard können Sie einsehen, wie sich das maschinelle Lernen von Radar auf Ihr Unternehmen auswirkt. Wenn Sie Radar Plus nutzen, können Sie hier zudem die Leistung Ihrer benutzerdefinierten Regeln abrufen. Anhand dieser Tools können Sie die Raten für Ihre Anfechtung aufgrund von Betrug, die Falsch-Positiv-Raten und die Blockierungsraten ganz einfach mit denen ähnlicher Unternehmen vergleichen. Die Basis dafür bilden aggregierte, nutzerdefinierte Kohorten von Unternehmen aus ähnlichen Branchen oder ähnlicher Größe.

Mehr Leistung mit Regeln und manuellen Prüfungen

Neben den eher automatischen Algorithmen für maschinelles Lernen ermöglicht Radar Plus einzelnen Unternehmen auch das Erstellen benutzerdefinierter Regeln (z. B. „Alle Transaktionen über 1.000,00 USD blockieren, wenn das IP-Land nicht mit dem Land der Karte übereinstimmt“), das Anfordern von Eingriffen und das manuelle Überprüfen gekennzeichneter Zahlungen im Dashboard.

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, dass dieser Leitfaden Ihnen dabei hilft, nachzuvollziehen, wie maschinelles Lernen bei Stripe zur Betrugsprävention eingesetzt wird und wie Sie die Wirksamkeit Ihrer Betrugssysteme beurteilen können. Sie können mehr über die Funktionen von Radar erfahren oder unsere Dokumentation durchsuchen.

Wenn Sie Fragen haben oder mehr über Stripe Radar erfahren möchten, können Sie uns gerne kontaktieren.