Die Bewertung des Betrugsrisikos ist ein kontinuierlicher Vorgang, bei dem es darum geht, Angriffsvektoren, Muster und Szenarien zu identifizieren und ihnen entgegenzuwirken. In enger Zusammenarbeit mit den Nutzerinnen und Nutzern hat unser Team für Fachdienstleistungen festgestellt, dass die Unternehmen, die dies am effektivsten umsetzen, häufig Betrugsanalysten und Datenanalysten zusammenarbeiten lassen – unter Verwendung einer Kombination aus Stripe Radar for Fraud Teams und Stripe Data-Produkten wie Stripe Sigma oder Stripe Data Pipeline, um sowohl allgemeine Betrugsmuster als auch für ihr Unternehmen spezifische Muster zu ermitteln.

Radar for Fraud Teams unterstützt Sie bei der Aufdeckung und Prävention von betrügerischen Aktivitäten und bietet Ihnen die Möglichkeit, eine auf Ihr Unternehmen zugeschnittene Betrugsbekämpfungslösung mit benutzerdefinierten Regeln, Berichten und manuellen Überprüfungen zu erstellen. Stripe Sigma ist eine Berichtslösung, die alle Ihre Daten zu Transaktionen, Konversionen und Kunden/Kundinnen in einer interaktiven Umgebung im Stripe-Dashboard verfügbar macht. Data Pipeline liefert dieselben Daten, sendet sie jedoch automatisch an Ihr Snowflake- oder Redshift-Data-Warehouse, sodass Sie zusammen mit Ihren anderen Geschäftsdaten darauf zugreifen können.

Diese Tools arbeiten nahtlos zusammen und decken die vier Säulen eines effektiven Verfahrens zur Betrugsbekämpfung ab: Aufdeckung, Untersuchung, Bestätigung sowie Verfeinerung und Schadensbegrenzung – darauf werden wir noch näher eingehen.

Vorteile der Nutzung von Radar for Fraud Teams mit Stripe Sigma oder Data Pipeline

Die Verwendung von Radar for Fraud Teams in Kombination mit Stripe Sigma oder Data Pipeline hat hauptsächlich den Zweck, die Daten von Radar, z. B. Metadaten, zusammen mit Ihren eigenen Daten zu analysieren. Zu den eigenen Daten zählen etwa Informationen zu Vorautorisierung, User Journey, Konversion und Sitzungen. Dadurch können legitime Transaktionen von betrügerischem Kundenverhalten unterschieden werden. Dies ermöglicht folgende Optimierungen:

1. Zeit bis zur Erkennung, um proaktiv Betrug aufzudecken und zu verhindern
   
2. Reaktionszeit für die Entwicklung von Präventions- und Erkennungsregeln
   
3. Kosten durch Betrug, unter anderem aufgrund von Rückerstattungen, Anfechtungsgebühren, Kundenabwanderung und Ablehnung von Ausstellern
   

Unser Bericht Überblick zum Thema Online-Betrug verdeutlicht, wie aufwendig manuelle Prüfprozesse sind, und dass „je größer [Unternehmen] sind, desto weniger Transaktionen geprüft werden“. Wenn Sie diese Prozesse automatisieren, haben Ihre Betrugsanalysefachleute mehr Zeit für die Identifizierung neuer Angriffsvektoren und die Entwicklung von Präventions- und Erkennungsregeln. So können Sie betrügerischen Datenverkehr besser blockieren und gleichzeitig vermeiden, dass legitime Kunden/Kundinnen dadurch zu stark beeinträchtigt werden und möglicherweise abwandern.

Ein grundlegender Prozess zur Handhabung von Betrug bei Transaktionen

Nehmen wir an, Sie verfügen über einen grundlegenden Prozess zur Handhabung von Betrug bei Transaktionen. Dieser besteht aus Erkennung, Untersuchung, Bestätigung sowie Verbesserung und Schadensbegrenzung und erfolgt innerhalb eines größeren Risikorahmens.

• Erkennung, auch bekannt als Identifizierung, Vorhersage oder Reaktion auf einen Vorfall, ist die Entdeckung eines Datenpunkts, der Anlass zu weiterer Untersuchung gibt. Die Erkennung kann manuell (z. B. während eines Vorfalls), halbautomatisch (über Erkennungsregeln oder Vergleiche mit der Ausgangslage), automatisch (über Machine Learning oder Anomalieerkennung) oder durch externe Auslöser (z .B. Feedback von Kundinnen und Kunden oder Anfechtungen) erfolgen. Bei der Erkennung können Machine-Learning-Modelle von Radar automatisch allgemeine Betrugsmuster entdecken, während Sie mit Stripe Sigma eher für Ihr Unternehmen spezifische Muster erkennen können.
  
• Untersuchung oder explorative Analyse ist die Bewertung verdächtiger Zahlungen oder verdächtigen Verhaltens, um die Auswirkungen auf das Unternehmen besser zu verstehen. Dies beinhaltet oft eine Überprüfung anhand weiter gefasster Daten, um Rauschen zu eliminieren. In der Regel verwenden Fachleute für Betrugsanalyse die Überprüfungsliste von Radar oder das Payments-Dashboard von Stripe, um Nachforschungen anzustellen.
  
• Prüfung, auch Modellierung oder Backtesting genannt, ist die Verallgemeinerung des verifizierten Angriffsvektors in Dimensionen und mögliche Modelle. Dies umfasst auch die Validierung und Folgenabschätzung unter Verwendung früherer Daten und anhand anderer Regeln. Die Backtesting- und Simulationsfunktionalität von Radar kann Betrugsanalysefachleuten dabei helfen. Stripe Sigma eignet sich hingegen eher für eine breitere Palette von Szenarien.
  
• Verfeinerung und Schadensbegrenzung, manchmal auch als Aktion oder Einschränkung bezeichnet, ist die Umsetzung des Modells – die Zuordnung der Dimensionen und signifikanten Funktionen zu Radar-Regelprädikaten, um Betrug zu verhindern, zu überwachen oder umzuleiten. Im herkömmlichen Sinne sind dies statische Präventionsregeln. In der heutigen Zeit, in der Machine Learning Unterstützung bietet und das Ziel darin besteht, die Präzision zu erhöhen, ist Verfeinerung passender. Dies umfasst typischerweise Blockregeln oder Listen in Radar.
  

Eine grundlegende Implementierung dieses Prozesses könnte schrittweise Zyklen wie tägliche Überprüfungen, Sprints oder die Veröffentlichung einer regelbasierten Betrugserkennungseinrichtung umfassen. Da die Zykluszeiten jedoch unterschiedlich sein und Feedback-Schleifen gleichzeitig auftreten können, betrachten wir dies eher als einen kontinuierlichen Prozess.

Im Folgenden sehen wir uns jede der vier Säulen im Kontext eines hypothetischen Szenarios im Detail an und zeigen Ihnen, wie Radar for Fraud Teams und Stripe Sigma oder Data Pipeline helfen können.

Unser Szenario

In unserem hypothetischen Szenario analysieren wir ein Verhalten, das über einen bestimmten Zeitraum hinweg auftritt, und nicht etwa einen unerwarteten Anstieg.

Nehmen wir an, Sie sind ein E-Commerce-Unternehmen. Sie haben in Ihrer Observability-Suite, die verschiedene Diagramme für Zahlungstrends in Echtzeit anzeigt, die Überwachung mit Webhooks eingerichtet. Sie haben in den letzten Tagen einen stetigen Anstieg der Ablehnungen einer Kartenmarke namens „Mallory“ festgestellt – für ein Produkt, das normalerweise nicht in der Region verkauft wird, in der diese Kartenmarke üblich ist. (Hinweis: Mallory ist eine fiktive Kartenmarke, die wir verwenden, um dieses Szenario anschaulicher zu gestalten. Es könnte sich beispielsweise um eine Marke handeln, die nicht im Enhanced Issuer Network vertreten ist.) Es gibt keine Verkaufsaktionen oder andere Vorfälle, die diese Veränderung erklären könnten, also muss Ihr Team untersuchen, was passiert ist, und das weitere Vorgehen festlegen.

Erkennung

Die Standardregeln von Stripe verwenden maschinelles Lernen, um eine beträchtliche Anzahl von betrügerischen Zahlungen vorherzusagen, zu erkennen und zu blockieren. Das Radar-Analyse-Dashboard kann Ihnen einen schnellen Überblick über Betrugstrends geben. Und für Unternehmen, die mehr Kontrolle darüber benötigen, welche Zahlungen überprüft, zugelassen oder blockiert werden sollen, sind die Regeln ein leistungsfähiges Tool zur Anpassung des Betrugsschutzes.

Um neue Betrugsmuster erkennen zu können, benötigen Sie zunächst eine Basis von Prognosesignalen, wie z. B. die Leistung Ihrer bestehenden Regeln. Anders ausgedrückt: Sie müssen wissen, was für Ihr Unternehmen „normal“ ist oder wie eine „gute“ Transaktion aussieht. An dieser Stelle arbeiten Ihre Betrugsanalysefachleute und Dateningenieure/Dateningenieurinnen zusammen (sie können auch mit DevOps-Teams und deren Observability-Suite zusammenarbeiten). In unserem hypothetischen Szenario wird ein Anstieg der abgelehnten Transaktionen mit dem Kartentyp „Mallory“ durch laufende Überwachung festgestellt.

Tabellen mit relevanten Betrugsdaten in Stripe Sigma

Um sich abzeichnende Muster zu erkennen, sollten Sie zunächst mit Funktionen wie dem Anteil abgelehnter Zahlungen/Autorisierungen von Ausstellern und der Blockquote von Radar eine Basisleistung ermitteln. Dann sollten Sie Anfechtungen aufgrund von Betrug, frühzeitige Betrugswarnungen (Issuer Fraud Records) und Zahlungstransaktionen mit hoher Geschwindigkeit, viele Ablehnungen von Ausstellern oder hohe Risikobewertungen durch Radar abfragen. Idealerweise planen Sie diese Abfrage täglich basierend auf verfügbaren Daten und visualisieren alle Dashboards mit früheren Daten, einschließlich wöchentlicher und monatlicher Daten. Dafür müssen Sie nicht einmal manuelle Abfragen in Stripe Sigma oder Ihrem Data Warehouse vornehmen. So können Sie schneller auf Vorfälle reagieren.

Hier sind die wichtigsten Tabellen:

Ihre Betrugs- oder Geschäftsanalyst/innen sollten eine Vorstellung davon haben, welche zusätzlichen Aufschlüsselungsdimensionen vor dem Hintergrund Ihres Geschäftsfelds wichtig sind. Die Tabelle Radar-Regelattribute in Radar for Fraud Teams enthält detaillierte Informationen zu den bestehenden von Radar bewerteten Transaktionen. Sie reicht jedoch nicht weiter als April 2023 zurück und enthält weder Metadaten noch endgültige Ergebnisse. Zuvor hätten Sie diese Felder abgefragt:

Die neue Tabelle Radar-Regelattribute verfolgt dieselben sowie viele weitere Dimensionen für jede von Radar bewertete Transaktion, und zwar mit dem genauen Namen der Radar-Attribute. Sie können beispielsweise Geschwindigkeitstrends wie name_count_for_card_weekly im Blick behalten.

Trends lassen sich auf verschiedene Arten visualisieren, aber ein einfaches anpassbares Liniendiagramm pro Aufschlüsselung ist eine gute Möglichkeit für den Vergleich mit anderen Faktoren. Wenn Sie die Daten in der Untersuchungsphase aufschlüsseln, können Sie verschiedene Aufschlüsselungen kombinieren. Die folgende Beispieltabelle zeigt die Aufschlüsselung nach Produktsegmenten für den Anstieg der abgelehnten Transaktionen mit dem Kartentyp „Mallory“:

Sie können die Tabelle auch in einem Tabellenkalkulationsprogramm Ihrer Wahl so darstellen:

Sehen wir uns das Beispiel einer Stripe Sigma- oder Data Pipeline-Abfrage zur Erfassung von Ausgangsdaten einmal genauer an. In der Abfrage unten sehen Sie unter anderem die täglichen angefochtenen und abgelehnten Zahlungen sowie die Blockquoten als separate Spalten. Bei der Erkennung und Untersuchung sind umfangreiche und wenige Daten in separaten Spalten oft übersichtlicher. Außerdem lassen sich die Spalten später leichter den Radar-Prädikaten zuordnen. Ihre Fachleute für Datenanalysen bevorzugen jedoch möglicherweise ein hohes und dichtes Format für die explorative Analyse während der Untersuchung oder für das Machine Learning in den Phasen der Bestätigung sowie der Verfeinerung und Schadensbegrenzung.

In diesem Beispiel fügen wir Metadaten über die Zahlung ein, um eine Aufschlüsselung nach Produktsegmenten vorzunehmen. Bei einem breit angelegten Ansatz würden wir ähnliche Abfragen für die Kartenmarke („Mallory“) und die Art der Finanzierung gemäß unserem Szenario benötigen. Wir deduplizieren hier die Wiederholungsversuche, um uns auf die eigentlichen Absichten zu konzentrieren und ein besseres Gefühl für die Größenordnung zu bekommen. Wir haben uns für die Deduplizierung von Zahlungsabsichten entschieden. Erweiterte Integrationen können ein Feld (z. B. eine Bestell-ID in den Metadaten) senden, um die Deduplizierung über die gesamte User Journey hinweg sicherzustellen. Dieses Beispiel zeigt, wie Sie die Präzision Ihrer Maßnahmen zur Betrugsbekämpfung durch das Hinzufügen eines weiteren Faktors erhöhen können. In unserem Szenario wäre dies das Produktsegment „Geschenkkarten“. Wir kommen später im Abschnitt „Verfeinerung und Schadensbegrenzung“ auf die Möglichkeiten zurück, wie sich die Präzision erhöhen lässt.

Diese Abfrage enthält nicht den tatsächlichen Anfechtungszeitpunkt, der ein nachlaufender Indikator ist. Wir haben aber einige Beispielindikatoren aufgenommen – z. B. die Wiederholungsversuche als Indikator für Kartentests. In dieser Abfrage erhalten wir auf einfache Weise ein paar tägliche Messwerte:

• Das Volumen der Zahlungen, sowohl dedupliziert als auch als Rohwert: Zum Beispiel 1.150 Zahlungen pro Tag, von denen 100 abgelehnt und 50 von Radar blockiert werden, bei 1.000 Zahlungsabsichten.
  
• Die Autorisierungsquote: In diesem Beispiel 90 % für Zahlungen, da gesperrte Zahlungen nicht an den Aussteller gehen, und 100 % für Zahlungsabsichten, da sie schließlich alle erfolgreich wiederholt werden.
  
• Das hohe Risiko und die Blockquote: In diesem Fall betragen beide 1,6 % (alle 50 Vorgänge mit hohem Risiko wurden auch blockiert).
  
• Die rückwärtsgerichtete Anfechtungsquote für Zahlungen aus demselben Zeitraum: Zum Beispiel wurden 5 von 1.000 Zahlungen angefochten. Die Anzahl pro Zahlungstag steigt, wenn mehr Zahlungsanfechtungen eingehen. Daher beziehen wir die Ausführungszeit der Abfrage mit ein, um die Veränderung nachzuvollziehen.
  

Wie bereits erwähnt haben wir diese Abfragen zur besseren Lesbarkeit vereinfacht. In Wirklichkeit hätte diese Abfrage noch weitere Dimensionen wie beispielsweise Trends, Abweichungen oder Verlustdifferenzen.

Wir haben auch ein Beispiel für einen sich wiederholenden Durchschnitt von 30 Tagen unter Verwendung einer Fensterfunktion hinzugefügt. Komplexere Ansätze, wie z. B. die Betrachtung von Prozentwerten anstelle von Durchschnittswerten, um sogenannte Long-Tail-Angriffe zu erkennen, sind möglich, aber für die erste Betrugserkennung nur selten erforderlich, da Trendlinien wichtiger sind als ganz präzise Zahlen.

Sobald Sie die Ausgangssituation kennen, können Sie Anomalien und Trends beobachten, um z. B. einen Anstieg der Betrugs- oder Blockquote aus einem bestimmten Land oder mit einer bestimmten Zahlungsmethode zu untersuchen (in unserem hypothetischen Szenario wäre dies die Kartenmarke „Mallory“). Anomalien werden in der Regel mit Berichten oder manuellen Analysen im Dashboard oder mit Ad-hoc-Abfragen in Stripe Sigma untersucht.

Untersuchung

Sobald Ihr Analyseteam eine zu untersuchende Anomalie gefunden hat, besteht der nächste Schritt in einer Abfrage in Stripe Sigma (oder Ihrem Data Warehouse über Data Pipeline), um die Daten zu untersuchen und eine Hypothese aufzustellen. Auf der Grundlage Ihrer Hypothesen empfiehlt es sich, einige Aufschlüsselungsdimensionen einzubeziehen, z. B. Zahlungsmethoden (Kartennutzung), Kanal oder Darstellung (Metadaten), Kunden/Kundinnen (Reputation) oder Produkte (Risikokategorie), die anfällig für Betrug sind. In der Phase der Prüfung können Sie später diese Dimensionen als „Merkmale“ bezeichnen. Diese werden dann Radar-Prädikaten zugeordnet.

Kommen wir zurück zu unserer Hypothese, dass ein großes Volumen an Transaktionen mit Prepaid-Karten vom Typ „Mallory“ höhere Betrugsraten aufweist. Sie können diese als gruppierte Dimension darstellen, um sie mit Ihrem Analysetool anzupassen. In dieser Phase wird die Abfrage in der Regel schrittweise durchgeführt und optimiert – es empfiehlt sich also, verschiedene Prädikatskandidaten als reduzierte oder erweiterte Versionen der Hypothesen einzubeziehen und dabei weniger relevante Merkmale zu entfernen, um ihre Auswirkungen abzuschätzen. Einige Beispiele:

So erhalten Sie eine Vorstellung davon, in welchem Umfang Sie die Auswirkungen priorisieren sollten. Aus der Tabelle geht mit hinreichender Sicherheit hervor, dass Regelkandidat 3 die meisten betrügerischen Transaktionen abzufangen scheint. Eine differenziertere Bewertung würde auf Genauigkeit, Präzisierung oder Rückruf basieren. Eine solche Ausgabe können Sie mit der folgenden Abfrage erstellen.

Aus Gründen der Lesbarkeit haben wir in dieser Abfrage die Deduplizierung entfernt, aber die Anfechtungsquote und das Betrugsfrühwarnsystem, die für Beobachtungsprogramme der Kartenmarken wichtig sind, mit aufgenommen. Dies sind aber nachlaufende Indikatoren, die wir in dieser vereinfachten Abfrage nur rückwirkend verfolgen. Wir haben auch willkürliche Zahlungsbeispiele zur Gegenprüfung und tieferen Untersuchung der in der Abfrage gefundenen Muster einbezogen – darauf gehen wir später näher ein.

Eventuell können Sie zusätzliche Metriken in einem Histogramm aufschlüsseln, um Cluster zu ermitteln. Dies kann nützlich sein, um Geschwindigkeitsregeln zu definieren, die Sie zur Ratenbegrenzung verwenden können (z. B. total_charges_per customer_hourly).

Die Erkennung von Trends mittels Histogramm-Analyse ist eine hervorragende Möglichkeit, das gewünschte Kundenverhalten über den gesamten Lebenszyklus und den Konversionstrichter zu ermitteln. Das Hinzufügen zu der obigen Abfrage wäre zu komplex, aber hier ist ein einfaches Beispiel dafür, wie man dies ohne die komplexe Logik eines rollierenden Fensters aufschlüsseln kann, vorausgesetzt, Sie haben einen Kundentyp in den Metadaten (z. B. Gastnutzer/innen):

In unserem Szenario möchten Sie vielleicht nicht alle Prepaid-Karten von „Mallory“ blockieren, aber dennoch andere zugehörige Risikofaktoren zuverlässig ermitteln. Diese Geschwindigkeitsabfrage kann die Zuverlässigkeit erhöhen, um beispielsweise das Blockieren von Gastkunden/Gastkundinnen zu vermeiden, die Ihre Dienste selten nutzen.

Eine einfache Möglichkeit zur Untersuchung besteht darin, direkt im Dashboard über die Ansicht „Verbundene Zahlungen“ Muster zu betrachten. Sie können so das Verhalten – also den Angriffsvektor oder das Betrugsmuster – und die damit verbundene Risikobewertung durch Radar besser erkennen. Deshalb haben wir in die Abfrage oben beliebige Beispiele für Zahlungen aufgenommen. So können Sie auch aktuelle Zahlungen sehen, die in Stripe Sigma noch nicht verfügbar sind. Ein defensiverer und individuellerer Weg ist, Ihre Hypothese als Prüfregel zu modellieren, die Zahlungen weiterhin zulässt, sie aber zur manuellen Prüfung an Ihr Analyseteam weiterleitet. Einige Kunden/Kundinnen tun dies, um die Rückerstattung von Zahlungen unterhalb der Anfechtungsgebühr zu berücksichtigen, während Zahlungen oberhalb blockiert werden.

Prüfung

Gehen wir davon aus, dass das von Ihnen identifizierte Muster nicht einfach ist, nicht durch Rückerstattung und Sperrung betrügerischer Kundenkonten entschärft werden kann und nicht unter eine Standardsperrliste fällt.

Nachdem Sie ein neues Muster identifiziert und priorisiert haben, müssen Sie dessen potenzielle Auswirkungen auf Ihre legitimen Umsätze analysieren. Dies ist kein einfaches Optimierungsproblem, denn die optimale Menge an Betrug ist ungleich Null. Wählen Sie aus den verschiedenen Modellkandidaten das Modell aus, das Ihre Risikobereitschaft am besten darstellt, entweder nach einfacher Größe oder nach Präzision und Rückruf. Dieser Prozess wird manchmal als Backtesting bezeichnet, insbesondere dann, wenn die Regeln zuerst geschrieben und dann anhand Ihrer Daten validiert werden. (Sie können dies auch umgekehrt tun, d. h. erst Muster entdecken und dann Regeln schreiben.) Anstatt eine Regel pro Land zu schreiben, können Sie zum Beispiel eine Regel wie die folgende zur einfacheren Prüfung schreiben:

Block if :card_funding: = 'prepaid and :card_country: in @preaid_card_countries_to_block

Die oben im Abschnitt „Untersuchung“ beschriebene Abfrage könnte auch als Modell verwendet werden, allerdings würden dann andere Werte hervorgehoben – darauf gehen wir später näher ein, wenn wir uns mit den Techniken für Verfeinerung und Schadensbegrenzung befassen.

Zuordnung von Stripe Sigma-Schemas zu Radar-Regeln

Sie sollten nun Ihre explorativen Abfragen aus Stripe Sigma oder Data Pipeline übersetzen, damit Sie die Regeln von Radar für das Backtesting in Stripe Sigma abbilden können. Hier sind einige gängige Zuordnungen, vorausgesetzt, Sie senden die richtigen Signale an Radar:

Die letzten beiden Elemente, risk_level und risk_score, sind nicht mit den anderen vergleichbar, da das Modell für maschinelles Lernen aus den anderen Faktoren abgeleitet wird. Statt übermäßig komplexe Regeln zu schreiben, empfehlen wir Ihnen, sich auf das maschinelle Lernen in Radar zu stützen – mehr dazu erfahren Sie im Abschnitt Verbesserung mit maschinellem Lernen.

Die neue Tabelle Radar-Regelattribute verfolgt dieselben sowie viele weitere Dimensionen für jede tatsächlich von Radar bewertete Transaktion, und zwar mit dem genauen Namen der Radar-Attribute.

Die Tabelle oben zeigt den Standardsatz von Attributen und lässt absichtlich Signale aus, die Sie an Ihre Customer Journey anpassen würden, wie z. B. Radar-Sitzungen oder Metadaten.

Gehen wir von der obigen Untersuchung aus und nehmen wir an, dass Sie zu einer Regel kommen, die wie folgt aussieht:

Block if :card_funding: = 'prepaid' and :card_funding: = 'mallory' and :amount_in_usd: > 20 and ::CustomerType:: = 'guest' and :total_charges_per_customer_hourly: > 2

Im nächsten Schritt bestätigen Sie die Auswirkungen dieser Regel auf Ihre tatsächlichen Zahlungstransaktionen. Dies erfolgt normalerweise mit Blockregeln. Lesen Sie unseren Leitfaden Radar for Fraud Teams: Das Regel-Einmaleins um zu erfahren, wie Sie die richtige Regelsyntax schreiben. Eine einfache Möglichkeit, eine Blockregel zu testen, besteht darin, sie im Test-Modus zu erstellen und manuelle Testzahlungen zu erstellen, um zu überprüfen, ob sie wie gewünscht funktioniert.

Sowohl Blockregeln als auch Überprüfungsregeln können in Radar mit der Radar for Fraud Teams-Simulationsfunktion rückgetestet werden.

Ein Vorteil der Verwendung von Radar for Fraud Teams-Simulationen ist, dass sie die Auswirkungen anderer bestehender Regeln berücksichtigen. Die Pflege von Regeln ist zwar nicht der Schwerpunkt dieses Leitfadens, doch das Entfernen und Aktualisieren von Regeln sollte ebenfalls Teil Ihres kontinuierlichen Verbesserungsprozesses sein. Im Allgemeinen sollte die Anzahl Ihrer Regeln so gering sein, dass jede Regel isoliert ist und mit den in der Erkennungs- und Untersuchungsphase entwickelten Basisabfragen überwacht und eindeutig rückgetestet werden kann, ohne das Risiko von Nebeneffekten (z. B. Regel 2 funktioniert nur, weil Regel 1 etwas anderes herausfiltert).

Sie können dies auch durch die Verwendung von Überprüfungsregeln anstelle von Blockregeln erreichen. Dies wird im nachfolgenden Abschnitt behandelt.

Verbesserung und Schadensbegrenzung

Nachdem Sie Ihre Blockregeln getestet haben, wenden Sie schließlich das Modell an, um Betrug zu verhindern, zu überwachen oder umzuleiten. Wir nennen dies Verbesserung, weil es darum geht, die Präzision Ihrer gesamten Maßnahmen zur Betrugsbekämpfung zu erhöhen, insbesondere in Verbindung mit Machine Learning. Zur Steigerung der Präzision können Sie eine Vielzahl von Techniken einsetzen. Manchmal wird dieser Schritt, der auch als Eindämmung oder Schadensbegrenzung bezeichnet wird, gleichzeitig mit der Bestätigung durchgeführt, wobei Sie anstelle von Überprüfungsregeln, A/B-Tests (Metadaten) oder Simulationen zur Bewertung Ihres Modells die verdächtigen Zahlungen sofort sperren, um das unmittelbare Risiko zu mindern.

Auch wenn Sie bereits Maßnahmen ergriffen haben, gibt es einige Techniken, mit denen Sie das in den Schritten 1 bis 3 entwickelte Modell verfeinern können, um die Ergebnisse langfristig zu verbessern:

Verbesserung mit Prüfregeln

Wenn Sie keine höhere Falsch-Positiv-Rate riskieren wollen, die sich auf Ihre Umsätze auswirken könnte, können Sie Prüfregeln implementieren. Dies ist zwar ein eher manueller Prozess und kann die Nutzerfreundlichkeit beeinträchtigen, aber die Prüfregeln können dazu beitragen, dass letztendlich mehr legitime Transaktionen durchgeführt werden können. (Für langsamere Transaktionen können Sie auch eine Drosselung in Form von Geschwindigkeitsregeln in bestehende Blockregeln einbauen.) Eine fortschrittlichere Option für den Einsatz von Überprüfungsregeln sind A/B-Tests. Sie sind besonders nützlich, um die Gesamtzahl der Fälle in der Überprüfungsliste zu verwalten. Sie können Metadaten aus Ihren Zahlungen nutzen, um während der A/B-Tests eine kleine Menge an Datenverkehr zuzulassen, z. B. von bekannten Kundinnen und Kunden oder einfach mittels einer Zufallszahl. Wir empfehlen, dies zu den Blockregeln hinzuzufügen, anstatt Zulassungsregeln zu erstellen, da Zulassungsregeln die Blockregeln außer Kraft setzen und es daher schwieriger ist, die Leistung der Blockregel über einen längeren Zeitraum zu verfolgen.

Optimierung der Regeln durch Beobachten ihrer Leistung

Um die Leistung der Regeln zu überwachen, können Sie das Objekt „charge outcome“ in der Payment Intents API überprüfen, insbesondere das Regelobjekt. In ähnlicher Weise können Sie in Stripe Sigma die Felder charges.outcome_rule_id, charges.outcome_type und payment_intents.review_id zur Analyse verwenden. Hier ein Beispiel dafür, wie Sie die Leistung einer Regel in Stripe Sigma mit Hilfe der speziellen Tabelle zu den Radar-Regelentscheidungen verfolgen können:

Verbesserung mit maschinellem Lernen

Nachdem ein unmittelbarer Angriff abgewehrt wurde, besteht der nächste Schritt oft darin, die Regel neben maschinellem Lernen zur Reduzierung von falsch positiven Resultaten schrittweise zu verbessern, sodass mehr legitimer Datenverkehr und damit mehr Umsätze durchgelassen werden.

Nehmen Sie zum Beispiel das Blockieren von BIN oder IIN (Issuer Identification Number). Während eines Kartentest-Angriffs haben Sie möglicherweise vorübergehend eine BIN zu einer Blockliste hinzugefügt, was den Ausstellern Zeit verschafft, ihre Schwachstellen zu beheben. Eine vollständige Blockierung eines Kartenausstellers könnte jedoch zu Umsatzeinbußen führen. Ein raffinierterer Ansatz besteht darin, das Modell nach und nach genauer zu prüfen und zu verbessern. Das ist der richtige Zeitpunkt, um die Erstellung effektiver Regeln und die Risikobewertung noch einmal zu überdenken, insbesondere die Risikobewertung von Radar. Im Allgemeinen empfehlen wir, das maschinelle Lernen von Radar mit Ihrer Intuition zu kombinieren. Statt nur eine Regel zu haben, die alle Transaktionen mit hohem Risiko blockiert, bietet die Kombination aus der Bewertung und manuellen Regeln, die ein Risikomodell oder Szenario darstellen, oft ein besseres Gleichgewicht zwischen dem Blockieren von schädlichem Datenverkehr und dem Zulassen von Umsätzen. Einige Beispiele:

Block if :card_funding: = 'prepaid' and :card_funding: = 'mallory' and :card_country: in @high_risk_card_countries_to_block and :risk_score: > 65 and :amount_in_usd: > 10

Verbesserung mit 3DS

Wie bereits erwähnt deckt dieser Leitfaden zwar nicht den gesamten Umfang der 3D Secure(3DS)-Authentifizierung ab, Sie sollten sie jedoch als Teil Ihrer Strategie zur Risikobegrenzung ansehen. Zum Beispiel kann Haftungsverlagerung zwar Ihre Anfechtungsgebühren für betrügerische Transaktionen senken, aber diese Transaktionen zählen immer noch zu Kartenbeobachtungsprogrammen – und damit zu Ihrer Nutzererfahrung. Anstelle eines festen Betrags könnten Sie diese Regel von „alle relevanten Zahlungen blockieren“ auf „3DS anfordern“ anpassen:

Request 3DS if :card_country: in @high_risk_card_countries_to_block or :ip_country: in @high_risk_card_countries_to_block or :is_anonymous_ip: = ‘true’ or :is_disposable_email: = ‘true’

Und dann eine Regel verwenden, um Karten zu sperren, die sich nicht erfolgreich authentifiziert haben oder aus anderen Gründen keine Haftungsverlagerung ermöglichen:

Block if (:card_country: in @high_risk_card_countries_to_block or :ip_country: in @high_risk_card_countries_to_block or :is_anonymous_ip: = ‘true’ or :is_disposable_email: = ‘true’) and :risk_score: > 65 and :has_liability_shift: != ‘true’

Verbesserung mit Listen

Die Verwendung der Standardlisten oder das Führen benutzerdefinierter Listen kann eine sehr effektive Methode sein, um einen Angriff während eines Vorfalls zu blockieren, ohne das Risiko einer Regeländerung einzugehen – beispielsweise durch das Blockieren eines/einer betrügerischen Kunden/Kundin, einer E-Mail-Domäne oder eines Kartenlandes. Ein Teil der Verbesserung besteht darin, zu entscheiden, welche Muster eine Regel sein sollten, welche ein Regelprädikat ändern sollten und welche einfach einen Wert zu einer bestehenden Liste hinzufügen können. Einbruchalarm-Regeln sind ein gutes Beispiel für eine Zwischenlösung während eines Vorfalls. Diese können anschließend entweder zu einer Liste oder zu einer Änderung einer bestehenden Regel aufgewertet werden.

Feedback-Prozess

Verbesserung bedeutet auch, dass Sie zu Schritt 1 zurückkehren, also Ihre Regelleistung und Betrugsmuster überwachen. Eine gute Überwachung hängt von festgelegten Grundregeln und einzelnen, punktuellen Änderungen ab, um eine optimale Rückverfolgbarkeit, Präzision und Rückrufquote beim Backtesting zu gewährleisten. Aus diesem Grund empfehlen wir, Regeln und Prädikate nur in klar abgegrenzten Fällen zu ändern und sich ansonsten auf Listen, Überprüfungen und proaktive Sperrungen und Rückerstattungen zu verlassen.

So kann Stripe Sie unterstützen

Radar für Plattformen

Verwendet Ihre Plattform Stripe Connect? Wenn ja, gelten alle von Ihnen erstellten Regeln nur für Zahlungen, die auf dem Plattformkonto erstellt wurden (in Connect heißen sie „Destination Charges“ oder „On-behalf-of-
Charges“). Für Zahlungen, die direkt über das Connect-Konto erstellt werden, gelten die Regeln dieses Kontos.

Radar für Terminal

Stripe Terminal-Zahlungen werden von Radar nicht überprüft. Das bedeutet, dass Sie, wenn Sie Terminal verwenden, Regeln auf der Grundlage der IP-Häufigkeit erstellen können, ohne sich Gedanken über die Blockierung Ihrer persönlichen Zahlungen zu machen.

Fachdienstleistungen von Stripe

Das Team für Fachdienstleistungen von Stripe kann Ihnen bei der Implementierung eines kontinuierlich verbesserten Prozesses zur Betrugsbekämpfung helfen. Von der Verbesserung Ihrer aktuellen Integration bis zur Einführung neuer Geschäftsmodelle – unser Expertenteam begleitet und unterstützt Sie beim Aufbau auf Ihren bestehenden Stripe-Lösungen.

Zusammenfassung

In diesem Leitfaden ging es darum, wie Stripe Sigma oder Data Pipeline verwendet werden können, um sowohl eine Grundlage als auch verschiedene Betrugsmodelle zu erstellen, die speziell auf Ihr Unternehmen zugeschnittene Angriffsszenarien und Muster darstellen. Außerdem haben wir gezeigt, wie Sie Radar erweitern und verfeinern können, um auf der Grundlage Ihrer benutzerdefinierten Regeln auf ein breiteres Spektrum an betrügerischen Transaktionen zu reagieren.

Da sich Betrug im Zahlungsverkehr ständig weiterentwickelt, muss auch dieser Prozess ständig weiterentwickelt werden – das haben wir in unserem Modell zur Erkennung, Untersuchung, Prüfung sowie Verfeinerung und Schadensbegrenzung deutlich gemacht. Die kontinuierliche Durchführung dieser Zyklen mit einer schnellen Feedbackschleife ermöglicht es Ihnen, weniger Zeit mit der Reaktion auf Vorfälle und mehr Zeit mit der Entwicklung einer proaktiven Strategie zur Betrugsbekämpfung zu verbringen.

Mehr über Radar for Fraud Teams erfahren Sie hier. Wenn Sie bereits Nutzer/in von Radar for Fraud Teams sind, sehen Sie sich die Seite Regeln in Ihrem Dashboard an, um mit der Erstellung von Regeln zu starten.

Mehr über Stripe Sigma erfahren Sie hier und über Stripe Data Pipeline hier.