Die Bewertung des Betrugsrisikos ist ein kontinuierlicher Prozess zur Erkennung von Angriffsvektoren, -mustern und -szenarien sowie deren Minderung. Durch enge Zusammenarbeit mit Nutzer/innen hat unser Team für Fachdienstleistungen festgestellt, dass dabei die Unternehmen erfolgreichsten sind, bei denen Betrugs- und Datenanalyst/innen gemeinsam mithilfe einer Kombination aus Stripe Radar for Fraud Teams und Stripe Data-Produkten wie Stripe Sigma oder die Stripe Data Pipeline sowohl allgemeine Betrugsmuster als auch unternehmensspezifische Muster ermitteln.

Radar for Fraud Teams unterstützt Sie bei der Erkennung und Vorbeugung von Betrug und gibt Ihnen die Möglichkeit, mit benutzerdefinierten Regeln, Berichten und manuellen Prüfungen ein maßgeschneidertes System der Betrugserkennung speziell für Ihr Unternehmen zu erstellen. Sigma ist eine Lösung für die Berichterstattung, die alle Ihre Transaktions-, Konversions- und Kundendaten in einer interaktiven Umgebung im Stripe-Dashboard verfügbar macht. Data Pipeline stellt dieselben Daten zur Verfügung, sendet sie aber automatisch an Ihr Snowflake- oder Redshift-Data-Warehouse, sodass sie zusammen mit Ihren anderen Unternehmensdaten abgerufen werden können.

Diese Tools arbeiten nahtlos zusammen, um die vier Säulen eines effektiven Prozesses zur Betrugsbekämpfung abzudecken: Erkennung, Untersuchung, Bestätigung sowie Verbesserung und Schadensbegrenzung – darauf werden wir noch näher eingehen.

Der Vorteil des Einsatzes von Radar for Fraud Teams mit Sigma oder Data Pipeline

Das Hauptziel der Verwendung von Radar for Fraud Teams mit Sigma oder Data Pipeline besteht darin, die Daten von Radar, wie z. B. Metadaten, zusammen mit Ihren eigenen Daten zu analysieren – einschließlich Vorautorisierung, Nutzererfahrung, Konversion und Sitzungsinformationen – um legitime Transaktionen von betrügerischem Kundenverhalten zu trennen. Auf diese Weise können Sie Folgendes optimieren:

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

Unser Bericht Stand des Online-Betrugs macht den Betriebsaufwand für manuelle Überprüfungsprozesse sowie die Tatsache deutlich, dass „je größer die [Unternehmen] sind, desto kleiner der Anteil der tatsächlich geprüften Transaktionen ist“. Durch die Automatisierung dieser Prozesse können Sie Ihren Betrugsanalyst/innen mehr Zeit für die Erkennung neuer Angriffsvektoren und die Entwicklung präventiver und ermittlungstechnischer Regeln einräumen. Entsprechend können Sie ein besseres Gleichgewicht zwischen dem Blockieren von betrügerischem Verkehr und der Verringerung von Reibungspunkten bei legitimen Kund/innen (Abwanderung) finden.

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 als Identifizierung, Vorhersage oder Reaktion auf Vorfälle bezeichnet, ist die Entdeckung eines Datenpunkts, der eine weitere Untersuchung erfordert. Die Erkennung kann manuell (z. B. während eines Vorfalls), halbautomatisch (über ermittlungstechnische Regeln oder Überwachung anhand Ihres Ausgangswertes), automatisch (über maschinelles Lernen oder Anomalieerkennung) oder extern (z. B. durch Kundenfeedback oder angefochtene Zahlungen) ausgelöst werden. Bei der Erkennung können durch das maschinelle Lernen von Radar automatisch allgemeine Betrugsmuster ermittelt werden, während Sigma helfen kann, für Ihr Unternehmen spezifische Muster zu finden.
  
• Untersuchung oder explorative Analyse ist die Auswertung verdächtiger Zahlungen oder verdächtigen Verhaltens, um die geschäftlichen Auswirkungen besser zu verstehen. Dies beinhaltet oft eine Überprüfung anhand umfassenderer Daten, um Unregelmäßigkeiten auszuschließen. In der Regel verwenden Betrugsanalyst/innen die Radar-Überprüfungsliste oder Stripes Dashboard für Zahlungen, um Untersuchungen durchzuführen.
  
• Bestätigung, auch als Modellierung oder Backtesting bezeichnet, ist die Verallgemeinerung des verifizierten Betrugsangriffsvektors in Dimensionen und Modellkandidaten. Dies gilt auch für die Validierung und Folgenabschätzung unter Verwendung früherer Daten und im Vergleich zu anderen Regeln. Die Backtesting- und Simulationsfunktionen von Radar können Betrugsanalyst/innen dabei helfen, aber Dateningenieur/innen können Sigma für ein breiteres Spektrum von Szenarien verwenden.
  
• Verbesserung und Schadensbegrenzung, manchmal auch als Aktion oder Einschränkung bezeichnet, ist die Umsetzung des Modells – die Abbildung der Dimensionen und signifikanten Merkmale auf die Radar-Regelprädikate, um Betrug zu verhindern, zu überwachen oder umzulenken. Traditionell wären dies statische Präventionsregeln gewesen, aber nachdem nun maschinelles Lernen ein wichtiges Gegenstück zum Menschen ist und das Ziel darin besteht, die Präzision zu erhöhen, ist Verbesserung der passendere Begriff. Dies umfasst normalerweise 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 können und Feedback-Schleifen gleichzeitig auftreten können, ziehen wir es vor, dies als einen kontinuierlichen Prozess zu betrachten.

Im Folgenden sehen wir uns jede dieser vier Säulen im Kontext eines hypothetischen Szenarios im Detail an und zeigen Ihnen, wie Radar for Fraud Teams und 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 Betrugsanalyst/innen und Dateningenieur/innen 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.

Sigma-Tabellen mit wichtigen Betrugsdaten

Um sich abzeichnende Muster zu erkennen, sollten Sie zunächst die Ausgangsleistung anhand von Merkmalen wie der Ablehnungs-/Autorisierungsquote des Ausstellers und der Blockquote von Radar ermitteln. Als Nächstes empfehlen wir eine Datenabfrage der folgenden Punkte: Anfechtungen aufgrund von Betrug, das Betrugsfrühwarnsystem, (Fälle von Ausstellerbetrug) und Zahlungstransaktionen mit hoher Geschwindigkeit, eine hohe Anzahl von Ausstellerablehnungen oder hohe Radar-Risikowerte. Im Idealfall planen Sie diese Datenabfrage so, dass sie täglich auf der Grundlage der verfügbaren Daten ausgeführt wird, und haben alle Dashboards mit älteren Daten visualisiert, einschließlich wöchentlicher und monatlicher Schnitte, ohne Sigma oder Ihr Data Warehouse manuell abfragen zu müssen. Auf diese Weise beschleunigen Sie die Reaktionszeit auf Vorfälle.

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 Sigma- oder Data Pipeline-Abfrage zur Erfassung von Ausgangsdaten genauer an. In der Abfrage unten sehen Sie unter anderem die täglichen angefochtenen Zahlungen, abgelehnte Zahlungen und Blockquoten als separate Spalten. Bei der Erkennung und Untersuchung sind umfangreiche und spärliche Daten in separaten Spalten oft übersichtlicher. Außerdem lassen sich die Spalten später leichter den Radar-Prädikaten zuordnen. Ihre Datenanalyst/innen bevorzugen jedoch möglicherweise ein hohes und dichtes Format für die explorative Analyse während der Untersuchung oder für das maschinelle Lernen in den Phasen der Bestätigung sowie Verbesserung 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 – tiefere Integrationen können ein Feld (z. B. eine Bestell-ID in den Metadaten) senden, um die Deduplizierung über die gesamte Nutzerreise 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 „Verbesserung und Schadensbegrenzung“ auf die Möglichkeiten zur Erhöhung der Präzision zurück.

Diese Abfrage enthält nicht den tatsächlichen Zeitpunkt der angefochtenen Zahlung, der ein nachlaufender Indikator ist, sondern wir haben einige Beispielindikatoren aufgenommen, wie z. B. Wiederholungsversuche als Indikator für Kartentests. In dieser Abfrage erhalten wir auf einfache Weise einige tägliche Metriken:

• Das Volumen der Gebühren, 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 rollierenden 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 mit der Verfolgung von Anomalien und Trends beginnen, 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 Sigma untersucht.

Untersuchung

Sobald Ihre Analyst/innen eine zu untersuchende Anomalie gefunden haben, besteht der nächste Schritt in einer Abfrage in 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), Kund/innen (Reputation) oder Produkte (Risikokategorie), die zu Betrug neigen. In der Phase der Bestätigung können Sie später diese Dimensionen als „Merkmale“ bezeichnen. Diese werden auf Radar-Prädikaten abgebildet.

Kommen wir zurück zu unserer Hypothese, dass ein großes Volumen an Transaktionen mit Prepaid-Karten vom Typ „Mallory“ höhere Betrugsraten aufweist, die Sie als gruppierte Dimension darstellen können, 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 Gastkund/innen mit geringer Häufigkeit zu vermeiden.

Eine einfache Möglichkeit zur Untersuchung besteht darin, sich Beispiele direkt im Dashboard anzusehen, und zwar über die Ansicht „Verbundene Zahlungen“, um ein Verständnis für das Verhalten – d. h. den Angriffsvektor oder das Betrugsmuster – und die damit verbundenen Radar-Risikoeinblicke zu erhalten. Aus diesem Grund haben wir in der Abfrage oben beliebige Zahlungsbeispiele eingefügt. So können Sie auch neuere Zahlungen finden, die in Sigma noch nicht verfügbar sind. Eine defensivere High-Touch-Methode wäre es, Ihre Hypothese als Überprüfungsregel zu modellieren, die weiterhin Zahlungen zulässt, diese aber an Ihre Analyst/innen zur manuellen Überprüfung weiterleitet. Einige Kund/innen tun dies, um die Erstattung von Zahlungen unterhalb der Anfechtungsgebühr zu erwägen, während Zahlungen oberhalb blockiert werden.

Bestätigung

Gehen wir davon aus, dass das von Ihnen erkannte Muster nicht einfach ist, nicht durch Rückerstattung und Blocken des/der betrügerischen Kunden/Kundin eingedämmt werden kann und nicht nur unter eine Standard-Blockliste fällt.

Sobald Sie ein neues Muster erkannt und als vorrangig eingestuft haben, müssen Sie dessen potenzielle Auswirkungen auf Ihre legitimen Einnahmen analysieren. Das ist kein triviales Optimierungsproblem, denn der optimale Betrugsbetrag ist nicht gleich Null. Wählen Sie aus den verschiedenen Modellkandidaten das Modell aus, das Ihrer Risikobereitschaft am besten entspricht, entweder anhand der einfachen Größenordnung oder der Präzision und der Wiedererkennung. Diesen Prozess nennt man mitunter Backtesting, vor allem dann, wenn die Regeln zuerst geschrieben und dann anhand Ihrer Daten validiert werden. (Das geht auch in umgekehrter Richtung – erst Muster entdecken und dann Regeln schreiben.) Statt eine Regel pro Land zu schreiben, können Sie zum Beispiel eine Regel wie diese schreiben, die die Bestätigung erleichtert:

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 Verbesserung und Schadensbegrenzung befassen.

Zuordnung des Sigma-Schemas zur Radar-Regel

Es ist an der Zeit, Ihre explorativen Abfragen aus Sigma oder Data Pipeline zu übersetzen, damit Sie Radar-Regeln für das Backtesting in Sigma abbilden können. Hier finden Sie 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 maschinellem Lernen. 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 sich für die Implementierung von Prüfregeln entscheiden. Dies ist zwar ein eher manueller Prozess und kann die Kundenerfahrung 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 Kund/innen 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 Überwachung ihrer Leistung

Um die Leistung der Regel zu überwachen, können Sie das Objekt des Zahlungsergebnisses in der Payment Intents API, insbesondere das Regelobjekt, überprüfen. Auf ähnliche Weise können Sie in Sigma die Felder charges.outcome_rule_id, charges.outcome_type und payment_intents.review_id zur Analyse verwenden. Das folgende Beispiel zeigt, wie die Leistung einer Regel in Sigma mit Hilfe der speziellen Tabelle Entscheidungstabelle für Radar-Regeln verfolgt werden kann:

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.

Fazit

In diesem Leitfaden haben wir erfahren, wie Sigma oder Data Pipeline verwendet werden können, um sowohl eine Grundlage als auch verschiedene Betrugsmodelle zu erstellen, die Angriffsszenarien und Muster darstellen, die nur Sie und Ihr Unternehmen beurteilen können. Außerdem haben wir gezeigt, wie Sie Radar erweitern und optimieren 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, um mit der Entwicklung Schritt zu halten – das haben wir in unserem Modell zur Erkennung, Untersuchung, Bestätigung sowie zur Verbesserung 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, besuchen Sie die Seite Regeln in Ihrem Dashboard, um mit dem Schreiben von Regeln zu beginnen.

Weitere Informationen über Sigma finden Sie hier und über die Stripe Data Pipeline hier.