Die Standardregeln von Stripe nutzen maschinelles Lernen, um eine signifikante Anzahl betrügerischer Zahlungen vorherzusagen und zu blockieren. Für Unternehmen, die mehr Einfluss darauf wünschen, welche Zahlungen überprüft, zugelassen oder blockiert werden sollen, sind Regeln ein leistungsstarkes Tool zur Anpassung der Betrugsvorbeugung.

Dieser Leitfaden enthält verschiedene Themen rund um Radar-Regeln, darunter über 100 Radar-Regeln, die Sie nutzen können, sowie bewährte Verfahren zum Backtesting, zur Erstellung von Regeln und vieles mehr.

Legen wir los.

Die Bedeutung von Reihenfolge und Hierarchie der Regeln

Die Reihenfolge, in der die Regeln auf Ihrer Radar-Seite aufgelistet sind, spielt eine Rolle. Jede Zahlung wird anhand der von Ihnen erstellten Regeln in der folgenden Reihenfolge bewertet und ausgeführt:

1. Request 3DS: Regeln, die eine 3D-Secure-Authentifizierung anfordern, wenn sie mit der Payment-Intents-API oder Checkout verwendet werden. Unabhängig von den Übereinstimmungen mit dieser Regel werden die Regeln Allow, Block und Review danach ausgewertet.
   
2. Allow: Regeln, die die Verarbeitung einer Zahlung ermöglichen. Allow-Regeln sollten sorgfältig implementiert werden, da sie alle anderen außer 3DS-Regeln übergehen – einschließlich der Modelle für das maschinelle Lernen von Stripe, und sollten mit größter Vorsicht verwendet werden. Nur Händler, die mehr als 100.000 USD verarbeitet haben, können Allow-Regeln schreiben.
   
3. Block: Regeln, die eine Zahlung blockieren und ablehnen. Wird eine Zahlung abgelehnt, wird sie nicht anhand von Review-Regeln bewertet.
   
4. Review: Diese Zahlungen werden verarbeitet und beim Kunden abgebucht, werden aber gekennzeichnet, damit Sie gegebenenfalls einen zweiten Blick darauf werfen können.
   

Die folgenden Regeln dienen als praktisches Beispiel. Alle Zahlungen unter 10 $ werden bearbeitet. Dies liegt daran, dass die erste Regel die Zahlung zulässt, ohne dass weitere Regeln ausgewertet werden. Weiterhin wäre auch eine Zahlung von 1.500 USD innerhalb der USA mit einem normalen Risikoniveau zulässig, obwohl Zahlungen über 1.000 $ blockiert werden. Grund dafür ist die zweite Regel in der Liste, die Zahlungen innerhalb der USA mit einem normalen Risikoniveau zulässt. Sobald eine bestimmte Regel ausgelöst wird, werden keine weiteren Regeln mehr ausgewertet.

• Allow payments less than $10

• Allow payments within the US and with a risk level of normal

• Block payments where the risk level is high

• Block payments greater than $1,000

• Review payments with a card issued outside the US

Spickzettel für die Regelsprache

Die Regeln ähneln SQL. Es stehen verschiedene Operatoren zur Verfügung, deren Anwendung vom Datentyp abhängt, den Sie zur Erstellung Ihrer Regel verwenden. Hier ist ein Spickzettel.

Wenn Sie explizit das Vorhandensein eines Attributs oder Metadatenattributs prüfen möchten, verwenden Sie nicht den Operator !=, sondern die Funktion is_missing. Geben Sie für diese Funktion das Attribut oder den Metadatenschlüssel an, das bzw. der möglicherweise fehlt. Sie können beispielsweise eine Regel erstellen, um alle Zahlungen abzugleichen, bei denen Sie keinen Zugriff auf die E-Mail-Adresse der Kundin oder des Kunden haben:

• Review if is_missing(:email_domain:)
  

Alternativ können Sie auch eine Regel erstellen, die alle Zahlungen abgleicht, bei denen die E-Mail-Adresse einer Kundin oder eines Kunden NICHT fehlt:

• Review if !(is_missing(:email_domain:))
  

Schreiben von Regeln in natürlicher Sprache

Wenn Sie Regeln einfacher schreiben möchten oder nicht sicher sind, welche Attribute Sie für ein bestimmtes Betrugsszenario verwenden sollten, übersetzt der KI-gestützte Radar-Assistent Ihre in natürlicher Sprache erstellten Eingaben in Regeln in der Syntax von Radar. Sie können die Regel auch direkt im Radar-Assistenten einem Backtesting unterziehen, um zu prüfen, wie sie sich in der Vergangenheit entwickelt hätte, bevor Sie die Regel implementieren.

Beliebte Radar-Regeln

Diese Liste ist keineswegs vollständig, sondern enthält häufig verwendete Radar-Regeln, die auf unterschiedlichen Zielen basieren.

Regeln, die dazu beitragen, das Testen von Karten oder das Einlösen von Karten zu verhindern

Regeln zur Vorbeugung von Betrug mit bekanntermaßen risikoreichen SKUs

Diese Regel erfordert Metadaten oder die Übergabe von SKU-Informationen als Zahlungsbeschreibung. Diese Zahlungen werden verarbeitet und bei den Kund/innen abgebucht. Sie werden allerdings gekennzeichnet, damit Sie einen zweiten Blick darauf werfen können.

Regeln, die Missbrauchsversuche mit Prepaid-Karten verhindern helfen

Analyse Ihrer Betrugsfälle als Grundlage für die Regelentwicklung

Überprüfung von Betrugsfällen

Für die Erstellung der effektivsten Regeln benötigen Sie ein umfassendes Verständnis der Betrugsaktivitäten in Ihrem Konto. Dafür ist es wichtig, die diversen Betrugsvektortypen zu beschreiben. Mögliche Fragen:

• Werden Konten neu registriert und sofort für betrügerische Einkäufe unter Verwendung neuer E-Mail-Adressen und Namen von Karteninhaber/innen genutzt?

• Greifen betrügerische Akteurinnen und Akteure auf ältere Konten zu und tätigen Käufe in ungewöhnlicher Höhe?

• Konzentrieren sich die Betrugsfälle auf bestimmte Kartennetzwerke oder Kartenländer?

• Erfolgt ein hochfrequenter Betrugsversuch, d. h. mehrere Versuche von derselben Karte, E-Mail- oder IP-Adresse innerhalb eines kurzen Zeitraums?

Wenn Sie sich den hochfrequenten Betrug im obigen Screenshot ansehen, könnten Regeln, die authorized_charges_per_card_number_hourly oder authorized_charges_per_ip_address_hourly verwenden, diesen Betrugsvektor möglicherweise bekämpfen.

Gewinnen Sie ein besseres Verständnis der Betrugsfaktoren

Mithilfe von Betrugsinformationen können Sie die Ursachen von Betrug schnell identifizieren und angehen, ohne Transaktionsdaten manuell analysieren zu müssen. Die Registerkarte „Einblicke“ im Dashboard gibt Aufschluss über die wichtigsten Attribute im Zusammenhang mit betrügerischen Transaktionen. Auf der Registerkarte „Einblicke“ können Sie direkt eine Regel für dieses Attribut hinzufügen.

Drei Attributtypen zur Erstellung von Regeln

Typ 1

Post-Authorisation-Attribute: Diese stehen für alle zur Verfügung. Beim Einsatz von Post-Authorization-Attributen müssen Sie Doppelpunkte vor und nach Attributen wie :cvc_check: verwenden.

Hier folgt ein Beispiel für die Verwendung von Post-Authorisation-Attributen:

• Block if :address_line1_check: != 'pass' Mit dieser Regel wird jede Zahlung blockiert, wenn sie die Prüfung des Kartenausstellers nicht besteht, bei der die erste Zeile der angegebenen Rechnungsadresse mit den Informationen abgeglichen wird, die für den Karteninhaber/die Karteninhaberin vorliegen. Das bedeutet, dass die Zahlung blockiert wird, wenn die Prüfung ‘unavailable’ ist, wenn diese Daten beim Aussteller ‘unchecked’ oder ‘not_provided’ sind.
  

Typ 2

Standardattribute: Diese stehen für alle zur Verfügung. Sie müssen Doppelpunkte vor und nach den Standardattributen verwenden, z. B. :card_bin: Wir haben unsere Standardattribute in vier Kategorien unterteilt:

• Attribute, die auf der Häufigkeit basieren – nützlich, um Kartentests oder Card Cashing vorzubeugen
  
• Attribute, die auf Kartenangaben basieren
  
• Attribute, die auf Zahlungsdetails basieren
  
• Attribute, die auf Kund/innendetails basieren
  

Einige Attribute erfordern Werte in Form von Strings, während für andere ein Wert als Zahl erforderlich ist. Zur Verdeutlichung haben wir für jedes Attribut ein Beispiel angegeben. Erfordert das Attribut eine Zeichenkette wie :card_bin:, so sehen Sie im Beispiel, dass der String innerhalb von ' ' liegt. Beispielsweise :card_bin: = ‘424242’ – ist dagegen eine Zahl erforderlich, gibt es keine ‘ ’, so wie in :amount_in_usd: > 250.

Attribute, die auf der Häufigkeit basieren

Es gibt vier Typen von Attributen, die auf der Häufigkeit basieren und besonders nützlich sind, um gestohlene Karten, Kartentests und Card Cashing zu verhindern.

1. Authorization: basierend auf Autorisierungen durch den Aussteller
   
2. Charge: basierend auf Zahlungen
   
3. Decline: basierend auf Ablehnungen durch den Aussteller
   
4. Block: basierend auf den vom maschinellen Lernen von Radar durchgeführten Blockierungen
   

Es gibt auch Attribute, die auf dem Ergebnis der Zahlung basieren, einschließlich Autorisierungen (basierend auf erfolgreichen Autorisierungen durch den Aussteller), Zahlungen (basierend auf Zahlungsversuchen), Ablehnungen (basierend auf Ablehnungen durch den Aussteller), Anfechtungen (frühere Transaktionen, die als betrügerisch angefochten wurden) und Blockierungen (basierend auf Blockierungen durch das maschinelle Lernen von Radar). Um ein Attribut zu bilden, werden die Ergebnisse mit einem Kundendetail (E-Mail, IP-Adresse, Name oder Kunden-ID) kombiniert.

Außerdem können Sie die Häufigkeit eines Kundendetails (E-Mail, Name) mit der bei einer Transaktion verwendeten Karte oder IP-Adresse kombinieren. Anders ausgedrückt: Es gibt zwei Arten von Häufigkeitsregeln:

1. Basierend auf dem Ergebnis der Zahlung (z. B. authorized_charges_per_email_hourly, blocked_charges_per_email_hourly) mit dem Resutat: erfolgreiche Autorisierung, Zahlungsversuch, Ablehnungen, Zahlungsanfechtungen, Blockierungen
   
2. Basierend auf Verbindungen zwischen Kund/in und Karte oder IP (z. B. name_count_for_card_weekly, email_count_for_ip_hourly)
   

Häufigkeitsregeln schließen die Zahlung aus, die Sie gerade verarbeiten. Zum Beispiel gibt authorized_charges_per_email_hourly die Anzahl der bisherigen erfolgreichen Zahlungsversuche von einer E-Mail-Adresse in der vorangegangenen Stunde an. Beim ersten Zahlungsversuch innerhalb einer bestimmten Stunde für eine E-Mail-Adresse hat authorized_charges_per_email_hourly also den Wert 0. War die erste Zahlung erfolgreich, hat der zweite Zahlungsversuch innerhalb der gleichen Stunde von dieser E-Mail-Adresse den Wert 1, und so weiter.

Attribute, die auf Kartenangaben basieren

Attribute, die auf Zahlungsdetails basieren

Attribute, die auf Details von Kund/innen basieren

Hier folgt ein Beispiel für die Verwendung von Standardattributen:

• Block if :card_country: IN ('CA', 'DE', 'AE')
  

Mit dieser Regel wird jede Zahlung von einer in Kanada, Deutschland oder den Vereinigten Arabischen Emiraten ausgestellten Karte blockiert.

Typ 3

Metadatenattribute: Diese Attribute hängen von den Metadaten ab, die Sie an Stripe senden. Bei diesen Attributen müssen Sie Doppelpunkte vor und nach den Standardattributen verwenden, z. B. ::Customer Age::. Metadatenattribute können entweder als Strings oder als Zahlen operieren. Bei der Verwendung von Metadatenattributen als Strings wird zwischen Groß- und Kleinschreibung unterschieden.

Mit Metadaten lassen sich sehr leistungsfähige Regeln erstellen, z. B. für die Aufnahme von Zahlungen in die manuelle Prüfung anhand der SKU oder zur Erleichterung für wiederkehrende Kund/innen. Weitere Informationen zur Übergabe von Metadaten finden Sie in dieser Anleitung.

Die Metadatenattribute werden in der folgenden Struktur geschrieben:

• ::[metadata attribute name]::[operator] [metadata_value]
  

Angenommen, Zahlungen haben die folgenden Schlüsselwertdaten im Metadatenfeld:

Es kann eine Regel geschrieben werden, um Zahlungen, die die folgenden Kriterien erfüllen, in die Prüfung aufzunehmen.

• Review if ::Customer Age:: < 30
  

Sie können auch Regeln schreiben, die sowohl Metadatenattribute als auch andere in diesem Dokument erwähnte unterstützte Attribute verwenden. Sie können z. B. eine Regel schreiben, die eine Zahlung nur dann in die Prüfung aufnimmt, wenn die Artikel-ID mit 5A381D übereinstimmt und der Zahlungsbetrag 1.000 USD übersteigt.

• Review if ::Item ID:: = '5A381D' and amount_in_usd: > 1000
  

Metadatenattribute unterstützen auch den Operator IN zum Abgleich gegen mehrere Werte. Sie können z. B. eine Regel schreiben, die eine Zahlung in die Prüfung aufnimmt, wenn die Kategorie-ID eine der Kategorien „Lebensmittel“, „Elektronik“ oder „Kleidung“ ist.

• Review if ::Category ID:: IN ('groceries', 'electronics', 'clothing')
  

Der Operator INCLUDES kann mit Regeln für Metadaten-Attribute und andere String-Attribute verwendet werden, um Teilstrings abzugleichen.
Sie können zum Beispiel eine Regel schreiben, die eine Zahlung in die Prüfung aufnimmt, wenn die Artikel-ID den String A381 enthält. Dies entspricht „A381“, „5A381D“, „A381D“, „5A381“ usw.

• Review if ::Item ID:: INCLUDES 'A381'
  

Der Zugriff auf Metadaten ist auch über Kunden- und Zielobjekte möglich (wenn diese für eine bestimmte Zahlung verwendet werden). Diese Attribute werden in der folgenden Struktur geschrieben:

• ::[customer|destination]:[metadata attribute name]::[operator][metadata_value]:
  

Angenommen, Sie haben eine/n Kund/in mit den folgenden Metadaten:

Sie könnten eine Regel schreiben, die Zahlungen immer zulässt, wenn das Metadatenfeld Trusted des Kunden/der Kundin true ist.

• Allow if ::customer:Trusted:: = 'true'
  

Oder angenommen, Sie haben ein Ziel mit den folgenden Metadaten:

Sie könnten eine Regel schreiben, die eine Zahlung in die Prüfung aufnimmt, wenn das Metadatenfeld Category des Ziels new ist.

• Review if ::destination:Category:: = 'new'
  

Verwendung gespeicherter Listen in Ihren Regeln (beispielsweise Erlaubt- oder Blocklisten)

Sie können in Ihren Regeln auf eine Gruppe von Werten verweisen, die Sie zuvor erstellt haben (beispielsweise Erlaubt- oder Blocklisten). Möchten Sie mehrere E-Mail-Adressen blockieren, sollten Sie eine Blockliste erstellen, anstatt mehrere Regeln für jede E-Mail zu erstellen, die Sie blockieren möchten.

Alle Listenalias, auf die in Regeln verwiesen wird, müssen mit @ beginnen. Um eine Regel zu erstellen, die sich auf eine Liste bezieht, müssen Sie der folgenden Struktur folgen:

• {action} [attribute] in [list]
  

Angenommen, Sie haben eine Liste von Kartenländern, die Sie blockieren möchten. Sie könnten eine Regel mit mehreren OR-Klauseln schreiben:

• Block if :card_country: = 'CA' OR :card_country: = 'DE' OR :card_country: = 'AE'
  

Sie könnten auch eine Regel mit einer Inline-Liste schreiben:

• Block if :card_country: IN ('CA', 'DE', 'AE')
  

Sie können auch eine Liste der zu blockierenden Kartenländer erstellen und sie card_countries_to_block nennen. Sie können dann die Länder in die Liste aufnehmen und in einer Regel auf diese Liste verweisen:

• Block if :card_country: in @card_countries_to_block
  

Eine Liste ist nicht nur übersichtlicher, sondern lässt sich auch sehr viel leichter bearbeiten und erweitern.

Komplexe Regeln mit mehreren Bedingungen schreiben

Sie können komplexe Bedingungen erstellen, indem Sie die Grundbedingungen mit den Operatoren AND, OR und NOT verknüpfen. Alternativ können Sie auch deren symbolische Entsprechungen verwenden: &&, || bzw. !. Wie bei den Programmiersprachen C, Python und SQL unterstützt Stripe die Standard-Operatorpriorität (Operatorrangfolge). Zum Beispiel wird die komplexe Bedingung:

• {condition_X} OR NOT {condition_Y} AND {condition_Z}
  

wie folgt interpretiert:

• {condition_X} OR ((NOT {condition_Y}) AND {condition_Z})
  

Die Gruppierung von Unterbedingungen innerhalb komplexer Bedingungen wird ebenfalls durch Klammern unterstützt. Das vorherige Beispiel ließe sich dahingehend ändern, dass die Auswertungsreihenfolge von Unterprädikaten ausdrücklich geändert wird:

• ({condition_X} OR (NOT {condition_Y})) AND {condition_Z}

• {condition_X} OR NOT ({condition_Y} AND {condition_Z})

Durch die Verwendung von Klammern an verschiedenen Orten führt jede dieser komplexen Bedingungen zu unterschiedlichen Ergebnissen.

Die Funktion is_missing kann auch in OR- oder AND-Konjunktionen verwendet werden:

• Review if is_missing(:email_domain:) OR :email_domain: IN ('yopmail.net', 'yandex.ru')
  

Oder Sie können die Funktion is_missing verwenden, wenn etwas nicht fehlt, in diesem Fall, wenn sie Zahlungen blockiert, wenn :ip_country: NICHT fehlt und die IP entweder aus den USA oder aus Puerto Rico stammt.

• Block if !(is_missing(:ip_country:))AND :ip_country: IN ('US', 'PR')
  

Backtesting von Regeln

Generell gilt für die Regelanalyse, dass es einen Kompromiss zwischen der Verhinderung von Betrug und der Blockierung legitimer Transaktionen bzw. False Positives gibt. Das Backtesting hilft Ihnen, Regeln zu finden, die Ihrer Risikobereitschaft entsprechen oder das richtige Gleichgewicht zwischen vermiedenen Zahlungsanfechtungen und einem Anstieg von False Positives finden. Zum Abschätzen der Auswirkungen einer Regel können Sie über das Radar-Dashboard Backtesting-Kombinationen mit den Transaktionsdaten der letzten sechs Monate durchführen und gezieltere Analysen vornehmen, um zu sehen, was die Regel bewirkt hätte, wenn sie erst kürzlich in Kraft getreten wäre.

Backtesting im Dashboard

Die Definitionen dessen, was betrügerische und andere erfolgreiche Zahlungen ausmacht, unterscheiden sich je nach getestetem Regeltyp:

Blockregel

• Angefochten, frühzeitige Betrugswarnung erhalten, oder Rückerstattung wegen Betrug: erfolgreiche Zahlungen, die angefochten oder wegen Betrug rückerstattet wurden oder erfolgreiche Zahlungen, die in die Prüfung aufgenommen und wegen Betrug angefochten oder rückerstattet wurden

• Sonstige erfolgreiche Zahlungen: erfolgreiche Zahlungen, die nicht angefochten oder wegen Betrug rückerstattet wurden oder erfolgreiche Zahlungen, die in die Prüfung aufgenommen und nicht angefochten oder wegen Betrugs rückerstattet wurden

• Fehlgeschlagene Zahlungsversuche: vom Aussteller abgelehnt oder von Radar gesperrt

Regel überprüfen

• Angefochten, frühzeitige Betrugswarnung erhalten, oder Rückerstattung wegen Betrug: erfolgreiche Zahlungen, die angefochten oder wegen Betrugs rückerstattet wurden

• Sonstige erfolgreiche Zahlungen: erfolgreiche Zahlungen, die nicht angefochten oder wegen Betrug rückerstattet wurden

• Fehlgeschlagen oder bereits in die Prüfung aufgenommen: vom Aussteller abgelehnt, von Radar gesperrt, oder erfolgreiche Zahlungen, die in die Prüfung aufgenommen wurden (unabhängig vom Status der Zahlungsanfechtung oder Rückerstattung)

Erlaubtregel

• Von Stripe oder benutzerdefinierten Regeln blockiert: von Radar blockierte Zahlungen

• Angefochten, frühzeitige Betrugswarnung erhalten, oder Rückerstattung wegen Betrug: erfolgreiche Zahlungen, die angefochten oder wegen Betrug rückerstattet wurden oder erfolgreiche Zahlungen, die in die Prüfung aufgenommen und angefochten oder wegen Betrug rückerstattet wurden

• Sonstige erfolgreiche oder von der Bank abgelehnte Zahlungen: erfolgreiche oder vom Aussteller abgelehnte Zahlungen, die nicht angefochten oder wegen Betrugs rückerstattet wurden oder erfolgreiche Zahlungen, die in die Prüfung aufgenommen und nicht angefochten oder wegen Betrugs rückerstattet wurden

Durchführung von kundenspezifischen Backtesting-Analysen

Die Backtesting-Funktion im Radar-Dashboard konzentriert sich auf die Transaktionen der letzten sechs Monate und umfasst Zahlungsanfechtungen, frühzeitige Betrugswarnungen und als betrügerisch rückerstattete Zahlungen.

Sie können eine gezieltere Analyse durchführen, wenn Sie beispielsweise Gefahr laufen, in einem Visa Betrugsüberwachungsprogramm (das sich ausschließlich auf frühzeitige Betrugswarnungen konzentriert) identifiziert zu werden, oder wenn Sie in letzter Zeit eine Häufung von Betrugsfällen von einer bestimmen IP-Region oder einem bestimmten Wallet-Typ feststellen. Dazu können Sie eine SQL-Abfrage in Sigma erstellen oder Berichte über Zahlungsdaten im Dashboard exportieren und analysieren. Das benutzerdefinierte Backtesting ermöglicht flexible Zeitrahmen (über sechs Monate hinaus) und gezieltere Analysen (z. B. können Sie sich nur auf angefochtene Zahlungen oder frühzeitige Betrugswarnungen konzentrieren). Die nachstehende Beispielabfrage führt Backtesting für frühzeitige Betrugswarnungen (EFWs) von Visa bei Transaktionen > 100 USD durch, wenn Sie annehmen, dass das Betrugsvolumen in letzter Zeit bei höheren Werten in die Höhe geschnellt ist und dass Transaktionen mit erhöhtem Wert ein Überwachungsprogrammrisiko erstellen:

Felder und Tabellen sind in Sigma verfügbar

with base as (
    select
        c.id,
        c.amount,
        c.captured,
        e.created as efw_created
    from charges c
    left join early_fraud_warnings on e.charge_id = c._id
    where card_brand = ‘visa’
    and (c.amount / 100) >= 100
    and c.captured >= dateadd(‘day’, -180, current_date)
)

select
    count(case when efw_created >= dateadd(‘day’, -60, current_date) then id else null end) as fraud_charge_count,

sum(case when efw_created >= dateadd(‘day’, -60, current_date) then amount else null end) as fraud_amount,

count(case when efw_created is null and captured between dateadd(‘day’, -120, current_date) and dateadd(‘day’, -60, current_date) then id else null end) as false_positive_charge_count,

count(case when efw_created is null and captured between dateadd(‘day’, -120, current_date) and dateadd(‘day’, -60, current_date) then amount else null end) as false_positive_amount

from based

Das Backtesting der letzten 60 Tage nach dem EFW-Erstellungsdatum konzentriert sich auf die aktuellsten Betrugsfälle, während das Backtesting der letzten 60 bis 120 Tage der nicht betrügerischen Verkäufe die Betrugsfälle besser erkennen lässt.

Häufige Betrugsvektoren

Die meisten betrügerischen Akteurinnen und Akteure gehen nach einem bestimmten Muster vor. Zunächst validieren sie gestohlenen Zahlungsinformationen (beispielsweise Karten). Nachdem sie sich davon überzeugt haben, dass sie funktionieren, nutzen sie diese Anmeldedaten, um Werte in Form physischer Waren für den persönlichen Gebrauch oder den Weiterverkauf (Luxusgüter oder Elektronik), Dienstleistungen für den persönlichen Gebrauch oder den Weiterverkauf (Lebensmittellieferdienste) oder Dienstleistungen und Produkte, mit denen weitere Betrugsdelikte begangen werden können (z. B. Web-Hosting-Dienste, Nachrichten-Spamming-Dienste usw.), zu erwerben.

Lesen Sie weiter, um mehr über die häufigsten Betrugsvektoren zu erfahren und wie Sie Radar-Regeln einsetzen können, um diese zu entschärfen.

Tests

Mit Kartentests überprüfen betrügerische Akteurinnen und Akteure unter Zuhilfenahme von Skripten oder manuellen Prozessen, ob die gestohlenen Kartennummern noch aktiv sind. Diese Betrugsphase dient nicht der Beschaffung physischer Waren oder Dienstleistungen, sondern der Überprüfung, ob die Karten aktiv sind. Diese Zahlungen sind in der Regel Transaktionen mit geringen Beträgen oder Autorisierungen. Die Prüfungen erfolgen in der Regel in schneller Folge und mit hoher Geschwindigkeit. Hilfreiche Attribute sind Merkmale zur Gruppierung und Geschwindigkeit, wie beispielsweise:

• total_charges_per_customer

• card_count_for_email

• card_count_for_ip_address

• total_charges_per_ip

Betrügerische Akteurinnen und Akteure versuchen in der Regel, diese zu umgehen, indem sie fingierte E-Mails versenden und unterschiedliche E-Mail-Adressen nutzen. Fortgeschrittenere Akteurinnen und Akteure maskieren IP-Adressen oder haben sogar mehrere Geräte, um individuelle Gerätedaten zu liefern. An diesem Punkt ist es wichtig, gute und typische Verhaltensweisen der Kundschaft zu kennen. Merkmale wie die E-Mail-Domain und das IP-Land können neben anderen breiteren Kategorien helfen, Transaktionen mit höherem Risiko zu erkennen. Viele betrügerische Kundinnen und Kunden nutzen beliebte E-Mail-Domains von etablierten Anbietern wie gmail.com. Möglicherweise begegnen Ihnen Domains wie gmail.comms oder gomail.co, mit denen betrügerische Akteurinnen und Akteure ihre Identität zu verschleiern versuchen. Kartenland und IP-Land können auch der Segmentierung der Kundschaft dienen und sicherstellen, dass die Transaktionen aus Gebieten stammen, die für Ihren Kundenstamm typisch sind. Transaktionen außerhalb dieser Regionen kämen dann für eine Überprüfung oder Blockierung infrage.

Eine weitere Funktionalität zur Eindämmung von Kartentests ist die Verwendung von CAPTCHA.

Sobald unser maschinelles Lernen einen Kartentest-Angriff feststellt, werden in Stripe Checkout automatisch CAPTCHA-Aufgaben gestellt. Um Kartentests einzudämmen, setzt Stripe eine Reihe automatischer und manueller Kontrollen ein, darunter Ratenbegrenzungen, Warnungen und kontinuierliche Prüfungen sowie Trainingsmodelle für Kartentests, um Angriffe automatisch aufzudecken. Diese Modelle stellen nur dann eine Aufgabe, wenn ein Kartentest-Angriff stattfindet, sodass echte Nutzer/innen fast nie ein CAPTCHA zu sehen bekommen, sondern nur Bots. Für Unternehmen, die Stripe Checkout verwenden, hat sich dadurch die Anzahl der Kartentests um stattliche 80 % verringert, ohne dass eine Auswirkung auf die Konversionsraten zu erkennen war.

Beachten Sie bitte, dass Sie auch benutzerdefinierte Regeln nach dem Modell „Bei mehr als drei Ablehnungen von einer bestimmten IP-Adresse aus blockieren“ aufstellen können, um entsprechende Angriffe abzuwehren.

Wertextraktion

Gestohlene Kreditkarten (neues Verhalten)

Bei diesem Betrugsvektor verwendet die betrügerische Akteurin oder der betrügerische Akteur die validierte gestohlene Karte auf ihrem bzw. seinem persönlichen Gerät oder auf einem Gerät, das für den Betrug verwendet wird.

Dieser Vektor wird in der Regel entweder mithilfe von skriptgesteuerten Massenangriffen oder in kleinerem Maßstab mit gezielteren Betrügereien missbraucht. Die Verwendung von Regelattributen, die die Neuheit eines Kontos auf Stripe ermitteln, wie z. B. hours_since_email_first_seen_on_stripe, in Kombination mit risks_core und anderen Funktionen, halten brandneue Karteninhaber/innen in Schach. Darüber hinaus schützen Geschwindigkeitsbegrenzungen für IP, E-Mails und Karten Händler vor Massenangriffen, bei denen betrügerische Akteurinnen und Akteure versuchen, gestohlene Zugangsdaten so schnell wie möglich zu monetarisieren.

Gestohlene Kreditkarten (Maskierungsverhalten)

Bei diesem Betrugsvektor nutzen betrügerische Akteurinnen und Akteure die validierte gestohlene Karte auf ihrem persönlichen Gerät oder auf einem Gerät, das rein für Betrugszwecke verwendet wird, oder die betrügerischen Akteurinnen und Akteure haben ein Abonnement-Konto kompromittiert und sich Zugang zu den im Konto gespeicherten Kreditkarteninformationen verschafft.

Die betrügerischen Akteurinnen und Akteure geben ihr Bestes, um ihre Existenz zu verschleiern durch:

• Verwendung des gleichen Namens wie bei früheren abgeschlossenen Transaktionen

• Verwendung der gleichen Rechnungsadresse wie bei früheren abgeschlossenen Transaktionen

• Verwendung eines VPN, um vorzutäuschen, dass sie die ursprüngliche Karteninhaberin oder der ursprüngliche Karteninhaber sind. Mittels VPN können sie dieselbe Stadt und manchmal sogar denselben Wohnblock vortäuschen.

• Änderung von kleinen Details, wie E-Mail-Adresse oder Telefonnummer

• Änderung der Lieferadresse aus früheren Transaktionen für eine physische Ware, wobei die Entfernung zwischen Rechnungs- und Versandadresse sehr groß sein kann. Dies ist ein ungenaues Signal.

Das oben beschriebene Maskierungsverhalten macht es schwierig, herauszufinden, wer die Transaktion tatsächlich vornimmt – die ursprüngliche Karteninhaberin oder der ursprüngliche Karteninhaber oder aber betrügerische Akteurinnen und Akteure, die das Konto kompromittiert haben. Das bedeutet oft, dass diese Art von Betrug sowohl für den Händler als auch für die ursprüngliche Karteninhaberin oder den ursprünglichen Karteninhaber länger unentdeckt bleiben kann.

Die Strategie ist hier dieselbe: Betrügerische Akteurinnen und Akteure versuchen, so viel Wert wie möglich aus den gestohlenen Anmeldedaten zu extrahieren. Regeln, die geschwindigkeitsbegrenzende Funktionen zusammen mit „riskscore“, „cvccheck fails“ oder „zip check fails“ verwenden, können zum Schutz vor diesem Verhalten beitragen.

Andere Best Practices

Im Folgenden finden Sie weitere Best Practices, die Ihnen helfen, das Aufstellen von Regeln in Radar zu optimieren.

Die Verwendung von Stripe.js ist wichtig

• Binden Sie stripe.js in den gesamten Zahlungspfad ein, um eine maximale Signalisierung von Betrugsversuchen zu gewährleisten
  
• Um das Beste aus Radar herauszuholen, ohne die Seitenladezeit zu beeinträchtigen, laden Sie stripe.js asynchron auf Nicht-Zahlungsseiten
  
• Am einfachsten neben Google-Analytics-Skript-Tags zu setzen
  
• Das komplette stripe.js Paket hat eine Größe von 29,6 kB (gzip)
  
• Künftig wird radar.js getrennt von stripe.js eingebunden werden können
  

Fazit

Regeln können ein äußerst leistungsfähiges Tool sein, mit dem Sie Ihre Betrugsvorbeugung individuell gestalten können. Durch die Implementierung einer eigenen Logik, die sich an den in diesem Leitfaden beschriebenen Best Practices orientiert, können Sie in Radar eine Betrugsprävention erstellen, die genau auf die Anforderungen Ihres Unternehmens ausgerichtet ist.

Weitere Informationen zu Radar for Fraud Teams finden 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 beginnen.

Weitere Hinweise

Radar für Plattformen

Sind Sie eine Plattform, die Stripe Connect verwendet? In diesem Fall gelten alle von Ihnen erstellten Regeln nur für Zahlungen, die auf dem Konto der Plattform erstellt werden (in der Connect-Sprache destination oder on-behalf-of).
Zahlungen, die direkt auf dem verbundenen Konto erstellt werden, unterliegen den Regeln dieses Kontos.

Radar für Terminal

Terminal-Zahlungen werden von Radar nicht überprüft. Das bedeutet, dass Sie sich bei der Verwendung von Terminal keine Sorgen darüber machen müssen, dass persönliche Zahlungen blockiert werden könnten, falls Sie Regeln auf der Grundlage der IP-Häufigkeit erstellen.