Betrugspräventionsregeln
Schützen Sie Ihr Unternehmen mit Regeln zur Betrugsprävention.
Dank der Regeln zur Betrugsprävention können Sie aktiv werden, sobald eine Zahlung bestimmte Kriterien erfüllt.
Stripe Radar bietet Stripe-Nutzerinnen und -Nutzern integrierte Regeln, um Betrugsrisiken zu erkennen und zu verhindern.
Nutzer/innen von Radar for Fraud Teams können über das Dashboard benutzerdefinierte Regeln basierend auf der bestimmten Geschäftslogik für Ihr Unternehmen erstellen. So können Sie beispielsweise:
- Anfordern von 3D Secure (3DS) für alle Zahlungen, die 3DS unterstützen und von neuen Kundinnen/Kunden getätigt werden
- Zulassen aller Zahlungen von der IP-Adresse Ihres Callcenters
- Blockieren von Zahlungen von einem bestimmten Standort oder einer im Ausland ausgestellten Karte
- Prüfen aller Zahlungen mit einer Prepaid-Karte und einem Betrag von mehr als 1.000 USD
Vorsicht
EU-Händler könnten von der Geoblocking-Verordnung und den dadurch entstandenen Verboten, Zahlungen von Kundinnen und Kunden in EU-Mitgliedstaaten zu blockieren, betroffen sein.
Integrierte Regeln
Die folgenden Regeln sind standardmäßig für alle Radar-Nutzer/innen verfügbar.
Risikoprüfungen für maschinelles Lernen
Stripe Radar und Stripe Radar for Fraud Teams verfügen über Standardregeln, die auf den Beurteilungen unserer Modelle für maschinelles Lernen basieren und wie folgt lauten:
Blockieren if :risk_level: = 'highest'
Die Regel blockiert Zahlungen mit hohem Betrugsrisiko, wodurch diese nicht abgewickelt werden. Diese Regel ist für Nutzer/innen von Radar oder Radar for Fraud Teams standardmäßig aktiviert.
Überprüfen if :risk_level: = 'elevated'
Gemäß dem Standardverhalten von Stripe Radar for Fraud Teams werden Zahlungen zur Prüfung vorgelegt, bei denen der Verdacht auf ein erhöhtes Betrugsrisiko besteht.
Herkömmliche Kartenprüfungen
Eine Zahlung kann selbst dann erfolgreich sein, wenn die Überprüfung der CVC oder die Adressprüfung (AVS) fehlschlägt, da die Kartenaussteller/innen bei ihrer Entscheidung, ob sie eine Zahlung genehmigen oder ablehnen, viele Signale berücksichtigen. In einigen Fällen kann ein/e Kartenaussteller/in eine Zahlung, die er/sie für rechtmäßig hält, auch dann genehmigen, wenn die Prüfung der CVC oder der Postleitzahl fehlschlägt.
Stripe verfügt über integrierte Regeln, sodass Sie Zahlungen blockieren können, auch wenn diese vom Kartenaussteller genehmigt wurden. Sie können diese Regeln über das Stripe-Dashboard aktivieren oder deaktivieren.
Diese Regeln werden auch bei der Kartenvalidierung angewendet, die beim Hinzufügen einer Karte zu einer Kundin/einem Kunden erfolgt. Wenn Karte und Kundin/Kunde gleichzeitig erstellt werden, verhindert ein Fehlschlagen der CVC- oder PLZ-Validierung die erfolgreiche Erstellung des Kundendatensatzes. Diese Regel ist möglicherweise nicht immer standardmäßig für Ihr Konto aktiviert. Sie können sie jederzeit über das Dashboard aktivieren oder deaktivieren.
Block if CVC verification fails
If this rule is enabled, Radar blocks payments that fail a card issuer’s CVC verification check. If the customer doesn’t provide the CVC number, for example because they use a wallet, or their card issuer doesn’t support its verification, the rule can’t block the payment.
Block if postal code verification fails
Wenn diese Regel aktiviert ist, blockiert Stripe Zahlungen, bei denen die Verifizierung der Postleitzahl eines Kartenausstellers fehlschlägt. Wenn die Kundin/der Kunde die Postleitzahl nicht angibt oder der Kartenaussteller die Verifizierung nicht unterstützt, kann die Regel die Zahlung nicht blockieren. Diese Regel ist nicht automatisch für Ihr Konto aktiviert. Sie können sie jederzeit über das Dashboard aktivieren oder deaktivieren.
Integrierte Regeln zum Anfordern von 3D Secure
Bei der Verwendung von 3DS werden Kundinnen/Kunden dazu aufgefordert, einen zusätzlichen Authentifizierungsschritt durchzuführen. Erst dann können sie die Zahlung abschließen. Wenn eine Zahlung mit 3DS authentifiziert wird, geht die Haftung für Anfechtungen aufgrund Betrugs in der Regel vom Verkäufer auf den Aussteller über. In den meisten Fällen haftet der Verkäufer also nicht für Anfechtungskosten für mit 3DS authentifizierten Zahlungen.
Stripe verarbeitet automatisch Codes für vorläufige Ablehnungen, die darauf hinweisen, dass 3DS von den Ausstellern angefordert wird. Wir lösen außerdem bei Bedarf 3DS aus und halten uns an Vorschriften wie die durch PSD2 vorgeschriebene starke Kundenauthentifizierung (SCA). Durch die Deaktivierung von Radar wird nicht verhindert, dass 3DS in Fällen ausgelöst wird, in denen dies erforderlich ist.
Stripe bietet drei standardmäßig deaktivierte Regeln, die Sie aktivieren können, um 3DS dynamisch anzufordern, wenn Sie Radar mit Payment Intents oder Setup Intents verwenden:
Request 3D Secure if 3D Secure is required for card- Standardmäßig deaktiviert. Das Aktivieren dieser Regel fordert die Kundinnen/Kunden automatisch zur 3DS-Authentifizierung auf, wenn die Karte in der Vergangenheit 3DS erforderte.
- Stripe verarbeitet automatisch Codes für vorläufige Ablehnungen, die darauf hinweisen, dass 3DS von den Ausstellern angefordert wird. Darüber hinaus lösen wir bei Bedarf auch 3DS aus und halten uns an Vorschriften wie die von PSD2 vorgeschriebene starke Kundenauthentifizierung.
Request 3D Secure if 3D Secure is supported for card- Standardmäßig deaktiviert, aber vergleichbar mit der vorherigen Regel. Durch die Aktivierung dieser Regel wird die Kundin/der Kunde zur 3DS-Authentifizierung aufgefordert, wenn die verwendete Karte die Authentifizierung unterstützt.
- Verwenden Sie diese Regel statt der vorherigen, wenn Sie die Anzahl der Zahlungen mit Haftungsverlagerung maximieren möchten. Beachten Sie, dass diese zusätzliche Anforderung sich negativ auf die Konversionsrate auswirken kann.
Request 3D Secure if 3D Secure is recommended for card- Standardmäßig deaktiviert. Durch die Aktivierung dieser Regel wird die Kundin/der Kunde zur 3DS-Authentifizierung aufgefordert, wenn Stripe davon ausgeht, dass die 3DS-Authentifizierung nur minimale Auswirkungen auf die Konversionsrate hat.
- Aktivieren Sie diese Regel, wenn Sie die Anzahl der Zahlungen mit Haftungsverlagerung maximieren möchten.
Da 3DS von Ihren Kundinnen/Kunden einen weiteren Authentifizierungsschritt erfordert, kann sich eine undifferenzierte Verwendung von 3DS negativ auf die Konversionsraten auswirken. Stripe empfiehlt Ihnen die Verwendung unserer Standardregeln für das Anfordern von 3DS nur, wenn alle Zahlungen von unterstützten Karten über 3DS gesendet werden sollen.
Das Anfordern von 3DS bedeutet nicht unbedingt, dass der Aussteller 3DS auch tatsächlich durchführt. Weitere Details zu möglichen Ergebnissen finden Sie in der 3D Secure-Dokumentation.
Regeln zum Anfordern von 3D Secure anpassen und entsprechend bestimmten Ergebnissen handeln
Nach dem 3DS-Authentifizierungsversuch mit Radar for Fraud Teams können Sie das Ergebnis in Zulassungs-, Block- oder Prüfregeln auswerten.
Die wichtigsten Attribute für benutzerdefinierte Radar-Regeln sind:
is_3d_secure: Trifft zu, wenn die Karte unterstützt wurde, 3DS durch den Aussteller eingesetzt wurde und die Authentifizierung der Nutzerin/des Nutzers nicht fehlgeschlagen ist. In der Regel empfehlen wir, dies in Blockregeln zu verwenden.is_3d_secure_authenticatedTrifft zu, wenn 3DS durch den Aussteller eingesetzt wurde und der/die Nutzer/in die Authentifizierung vollständig durchlaufen hat. Durch die Verwendung dieses Attributs in einer Blockregel werden legitime Transaktionen ausgeschlossen, für die möglicherweise eine Ausnahme von der starken Kundenauthentifizierung (SCA) gilt oder die nicht eindeutig auf eine fehlgeschlagene oder erfolgreiche Authentifizierung zurückzuführen sind wie z. B. Verarbeitungsfehler.has_liability_shift: Dies trifft zu, wenn Stripe erwartet, dass die Zahlung unter die Haftungsverlagerungsregel fällt. Dabei handelt es sich möglicherweise nicht immer um 3DS, zum Beispiel bei Apple Pay in bestimmten Regionen.
Für nutzerdefinierte Regeln empfehlen wir, die Regeln 3DS anfordern und Blockieren je nach Ihrer Risikobereitschaft aufeinander abzustimmen. Blockieren Sie jedoch keine Transaktionen, bei denen 3DS nicht unterstützt wird, wie z. B. bei einigen Wallets.
Hier sind einige Beispiele, die zeigen, wie dies für verschiedene Anwendungsszenarien erreicht werden kann:
3D Secure basierend auf der Radar-Risikostufe anfordern
Sie möchten Radar verwenden, um 3DS für alle Zahlungen basierend auf der Radar-Risikostufe und ab einem bestimmten Betrag anzufordern.
| Radar-Regel | Beschreibung |
|---|---|
3D Secure anfordern if :risk_level: != | Diese Regel prüft die Risikostufe von Radar und fordert dann 3DS für alle Zahlungen mit einer erhöhten oder hohen Risikostufe ab einem bestimmten Betrag an. |
In diesem Fall würden Karten oder Wallets, die 3DS nicht unterstützen, ohne eine Blockregel nicht gesperrt. 3DS-Versuche mit fehlgeschlagener Authentifizierung belasten die Autorisierung nicht weiter.
3D Secure immer basierend auf der Radar-Risikostufe anfordern
Sie möchten Radar verwenden, um 3DS für alle Zahlungen basierend auf der erhöhten oder der hohen Radar-Risikostufe und ab einem bestimmten Betrag anzufordern. Wenn Karten 3DS nicht unterstützen, möchten Sie diese nicht akzeptieren.
| Radar-Regel | Beschreibung |
|---|---|
3D Secure anfordern if :risk_level: != | Diese Regel prüft die Risikostufe von Radar und fordert dann 3DS für alle Zahlungen mit einer erhöhten oder hohen Risikostufe ab einem bestimmten Betrag an. |
Blockieren if not :is_3d_secure: and :risk_level: != | Diese Regel blockiert Zahlungen ohne 3DS-Ablauf für Zahlungen mit erhöhtem oder hohem Risiko ab einem bestimmten Betrag. Sie akzeptiert jedoch legitime Transaktionen, für die möglicherweise eine SCA-Ausnahme gilt oder bei denen keine eindeutige fehlgeschlagene oder erfolgreiche Authentifizierung vorliegt, wie z. B. attempt_. Sie akzeptiert Off-Session-Zahlungen wie wiederkehrende Abonnementzahlungen und Wallets wie Apple Pay oder Google Pay, um erfolgreich zu sein. |
Nur mit 3D Secure authentifizierte Transaktionen akzeptieren, sofern 3D Secure unterstützt wird
Sie verlassen sich darauf, dass Stripe 3DS auslöst, wenn dies in Fällen wie der starken Kundenauthentifizierung (SCA) erforderlich ist, möchten allerdings keine Grenzfälle, wie Verarbeitungsfehler, akzeptieren.
| Radar-Regel | Beschreibung |
|---|---|
Block if :is_3d_secure: und nicht :is_3d_secure_authenticated: | Diese Regel blockiert Zahlungen, bei denen die Karte bei 3DS registriert ist und 3DS versucht wurde, sich der/die Nutzer/in jedoch nicht erfolgreich authentifiziert hat. Karten, die 3DS, SCA-Ausnahmen, Off-Session-Zahlungen (wie wiederkehrende Abonnementzahlungen) und Wallets (wie Apple Pay oder Google Pay) nicht unterstützen, werden akzeptiert. |
3D Secure basierend auf Metadaten anfordern
Sie möchten Radar verwenden, um 3DS für alle Zahlungen mit einem nutzerdefinierten Metadatenattribut anzufordern.
| Radar-Regel | Beschreibung |
|---|---|
3D Secure anfordern if ::foo:: = | Diese Regel prüft, ob eine Metadatenbedingung vorliegt und fordert dann 3DS an. Um Kunden-Metadaten zu überprüfen, ersetzen Sie ::foo:: = 'bar' durch einen Wert wie ::customer:trusted:: = 'false'. |
In diesem Fall würden Karten oder Wallets, die 3DS nicht unterstützen, ohne eine Blockregel nicht gesperrt. 3DS-Versuche mit fehlgeschlagener Authentifizierung belasten die Autorisierung nicht weiter.
3D Secure immer basierend auf Metadaten anfordern
Sie möchten Radar verwenden, um 3DS für alle Zahlungen mit einem nutzerdefinierten Metadatenattribut anzufordern und Karten zu blockieren, die dies nicht unterstützen.
| Radar-Regel | Beschreibung |
|---|---|
3D Secure anfordern if ::foo:: = | Diese Regel prüft, ob eine Metadatenbedingung vorliegt und fordert dann 3DS an. Um Kunden-Metadaten zu überprüfen, ersetzen Sie ::foo:: = 'bar' durch einen Wert wie ::customer:trusted:: = 'false'. |
Blockieren if ::foo:: = | Diese Regel blockiert Zahlungen ohne 3DS-Ablauf für Zahlungen mit einem nutzerdefinierten Metadatenattribut. Sie akzeptiert jedoch legitime Transaktionen, für die möglicherweise eine SCA-Ausnahme gilt oder bei denen keine eindeutige fehlgeschlagene oder erfolgreiche Authentifizierung vorliegt, wie z. B. attempt_. Sie akzeptiert Off-Session-Zahlungen (wie wiederkehrende Abonnementzahlungen) und Wallets (wie Apple Pay oder Google Pay), um erfolgreich zu sein. |
3D Secure für alle neuen Karten anfordern und prüfen, ob 3D Secure nicht unterstützt wurde
Sie möchten Radar verwenden, um 3DS für alle neuen Karten anzufordern und Zahlungen von Karten, die 3DS nicht unterstützen, manuell zu überprüfen.
| Radar-Regel | Beschreibung |
|---|---|
Request 3D Secure if is_missing(:seconds_since_card_first_seen:) | Diese Regel fordert 3DS für alle Karten an, die nicht für Ihr Konto verwendet wurden. Um Unstimmigkeiten für die Nutzer/innen zu verringern, können Sie eine zusätzliche Bedingung hinzufügen, die 3DS nur in folgendem Falle anfordert: :risk_level: != . |
3D Secure anfordern if :is_new_card_on_customer: | Diese Regel fordert als Alternative zu der obigen Regel 3DS für alle Karten an, die zum ersten Mal für eine/einen Kundin/Kunden verwendet werden. Um Unstimmigkeiten für die Nutzer/innen zu verringern, können Sie eine zusätzliche Bedingung hinzufügen, die 3DS nur in folgendem Fall anfordert: :risk_level: != . |
Überprüfen if not :is_3d_secure and not:is_off_session: and :digital_wallet: != | Diese Regel kennzeichnet Zahlungen, bei denen 3DS erwartet wurde, was aber bei der manuellen Überprüfung nicht unterstützt wird. Die Regel ignoriert Off-Session-Zahlungen (wie wiederkehrende Abonnementzahlungen) und Wallets (wie Apple Pay oder Google Pay). Zur Überprüfung gekennzeichnete Zahlungen werden weiterhin autorisiert und können zusätzliche Hinweise geben, wie z. B. CVC-Prüfungen des Ausstellers. |
In diesem Fall würden Karten oder Wallets, die 3DS nicht unterstützen, ohne eine Blockregel nicht gesperrt. 3DS-Versuche mit fehlgeschlagener Authentifizierung belasten die Autorisierung nicht weiter.
Für bestimmte Ausstellerländer ist immer 3D Secure erforderlich
Sie möchten mit Radar 3DS für alle Zahlungen von Kartenausstellern aus Ländern auf einer nutzerdefinierten Liste anfordern und Karten blockieren, die dies nicht unterstützen.
| Radar-Regel | Beschreibung |
|---|---|
3D Secure anfordern if :card_country: in @enforce_3ds_list | Diese Regel such nach einer Bedingung, die auf Kartenausstellern aus verschiedenen Ländern basiert, und vergleicht sie mit einer nutzerdefinierten Liste. Wenn sie übereinstimmen, wird 3DS angefordert. |
Blockieren if :card_country: in @enforce_3ds_list and not :is_3d_secure and not :is_off_session: and :digital_wallet: != | Diese Regel blockiert Zahlungen ohne 3DS-Ablauf für Zahlungen, die aus Ländern auf der nutzerdefinierten Liste stammen. Sie akzeptiert jedoch legitime Transaktionen, für die möglicherweise eine SCA-Ausnahme gilt oder bei denen keine eindeutige fehlgeschlagene oder erfolgreiche Authentifizierung vorliegt, wie z. B. attempt_. Sie akzeptiert Off-Session-Zahlungen (wie wiederkehrende Abonnementzahlungen) und Wallets (wie Apple Pay oder Google Pay), um erfolgreich zu sein. |
3D Secure immer basierend auf der Radar-Risikostufe anfordern und Grenzfälle überprüfen
Sie möchten Radar verwenden, um 3DS für alle Zahlungen basierend auf der Radar-Risikostufe anzufordern. Außerdem möchten Sie Karten blockieren, die 3DS nicht unterstützen, möchten aber Grenzfälle manuell überprüfen.
| Radar-Regel | Beschreibung |
|---|---|
3D Secure anfordern if :risk_level: != | Diese Regel prüft die Risikostufe von Radar und fordert dann 3DS für alle Zahlungen mit einer erhöhten oder hohen Risikostufe ab einem bestimmten Betrag an. |
Blockieren if not :is_3d_secure: and :risk_level: != | Diese Regel blockiert Zahlungen ohne 3DS-Ablauf für Zahlungen mit erhöhtem oder hohem Risiko ab einem bestimmten Betrag. Sie akzeptiert jedoch legitime Transaktionen, für die möglicherweise eine SCA-Ausnahme gilt. Sie akzeptiert Off-Session-Zahlungen (wie wiederkehrende Abonnementzahlungen) und Wallets (wie Apple Pay oder Google Pay), um erfolgreich zu sein. |
Überprüfen if not :is_3d_secure_authenticated: and :risk_level: != | Diese Regel kennzeichnet Zahlungen zur manuellen Überprüfung, für die 3DS verwendet wurde, was jedoch keinen vollständig authentifizierten Ablauf zur Folge hatte. Dabei werden Grenzfällle wie attempt_ überprüft und legitime Zahlungen trotz SCA-Ausnahmen gekennzeichnet. Da die Überprüfungsregeln nach den Blockregeln ausgewertet werden, werden Karten, die 3DS nicht unterstützen, gesperrt. |
Wann werden Regeln erstellt?
Die Standardregeln von Stripe können eine hohe Anzahl von betrügerischen Zahlungen blockieren. Unternehmen, die sich mehr Kontrolle darüber wünschen, welche Zahlungen geprüft, zugelassen oder blockiert werden sollen, können mit Radar for Fraud Teams benutzerdefinierte Regeln schreiben.
Berücksichtigen Sie die folgenden Punkte, wenn Sie sich für oder gegen die Aktivierung benutzerdefinierter Regeln entscheiden:
- Ob Sie bestimmte Funktionen oder Nutzerverhalten für riskanter halten (zum Beispiel die Verwendung einer temporären E-Mail-Adresse)?
- Ob Sie Regeln implementieren möchten, die auf Zahlungsbeträgen oder der erkannten Risikostufe basieren (zum Beispiel automatisch prüfen, wenn die Zahlung über 500 USD liegt; automatisch zulassen, wenn die Zahlung unter 5 USD liegt)?
- Ob Ihre bestehenden angefochtenen und zurückerstatteten Zahlungen gemeinsame Muster (zum Beispiel ähnliche Beträge, Kartentypen oder Länder) aufweisen?
- Unabhängig davon, ob Sie bereits Regeln haben, die Sie zu Stripe migrieren möchten. Viele dieser Regeln wurden womöglich bereits von den Modellen für maschinelles Lernen von Stripe berücksichtigt. Sie können Sich zunächst informieren, wie unser System für Ihr Unternehmen funktioniert, bevor Sie dieses anpassen.
So werden effektive Regeln erstellt
Regeln können zwar bei der Automatisierung Ihrer bestehenden Abläufe helfen, allerdings können sie sich bei falscher Verwendung auch negativ auf Ihr Unternehmen auswirken. Beispielsweise kann eine nicht richtig eingerichtete Regel automatisch eine hohe Anzahl betrügerischer Zahlungen zulassen oder eine hohe Anzahl legitimer Zahlungen blockieren.
Berücksichtigen Sie beim Einrichten von Regeln Folgendes:
- Die Regeln werden nur für künftige Zahlungen angewendet und gelten nicht für bereits abgewickelte Zahlungen.
- Die Regeln für die Anforderung von 3DS gelten nur bei Verwendung von Stripe Checkout, Payment Intents oder Setup Intents und werden vor der Anwendung von Prüf-, Block- und Zulassungsregeln ausgewertet.
- Vor der Implementierung einer Sperrregel, die alle Zahlungen mit den entsprechenden Kriterien blockieren, sollten Sie eine vorherige Prüfung dieser Zahlungen in Erwägung ziehen.
- Implementieren Sie Zulassungsregeln nur selten und wenn es nötig ist, da sie die Standardregeln von Stripe und alle benutzerdefinierten Regeln, die den gleichen Kriterien entsprechen, überschreiben.
- Pro Konto können maximal 200 Regeln aus allen Regeltypen erstellt werden.
Regeln erstellen
Sie können im Dashboard auf der Registerkarte Regeln der Radar-Seite Regeln hinzufügen und verwalten.
So fügen Sie eine neue Regel hinzu:
- Klicken Sie auf + Regel hinzufügen.
- Wählen Sie den Typregeltyp aus dem Untermenü aus.
- Konstruieren Sie im Regeleditor eine Regel mit der Syntax
{action} if {attribute} {operator} {value}und achten Sie auf folgende Punkte:{action}: Wie Radar reagiert, wenn die Regelkriterien erfüllt sind. Dieser Wert wird basierend auf der von Ihnen ausgewählten Regeltypauswahl vorab ausgefüllt.{attribute}: Das Element der auszuwertenden Transaktion, wie z. B. der Betrag oder der Kartentyp. Beginnen Sie mit:, um eine Liste gültiger Attribute zu öffnen. Sie können Ihre benutzerdefinierten Metadaten auch auswerten, indem Sie sie in zweifache Doppelpunkte einfügen, also z. B.::product_.sku:: {operator}: So vergleichen Sie das Attribut mit dem Wert, z. B.:=,>,!=.{value}: Der Wert des zu bewertenden Attributs.
- Klicken Sie auf Regel testen.
- Korrigieren Sie gegebenenfalls erkannte Validierungsfehler.
- Überprüfen Sie auf der Seite Neue Regel überprüfen, wie sich diese Regel auf Ihre letzten Transaktionen auswirkt, um herauszufinden, ob Sie diese aktivieren sollten.
- Klicken Sie auf Regel hinzufügen, um diese Regel auf alle zukünftigen Transaktionen anzuwenden.
Radar Assistant verwenden
Der Regel-Editor von Stripe verfügt über einen integrierten LLM-Assistenten, der eine Radar-Regel über eine Eingabeaufforderung in natürlicher Sprache erstellt.
So verwenden Sie Radar Assistant:
- Klicken Sie im Dashboard auf der Registerkarte Regeln der Radar-Seite auf + Regel hinzufügen.
- Wählen Sie den Regeltyp aus dem Untermenü aus.
- Klicken Sie im Regel-Editor auf Radar Assistant.
Manuelles Schreiben von Regeln
Radar Assistant
- Geben Sie Ihre Regelanforderung in das Nachrichtenfeld ein. Sie könnten folgende Anfragen stellen:
- Zahlungen überprüfen, bei denen sich das Kartenland und die IP-Adresse des Landes unterscheiden.
- Discover-Kartenzahlungen mit Beträgen über 1.000 USD blockieren.
- Zahlungen von stripe.com-E-Mail-Adressen zulassen.
- Wenn der Assistent mit seinem Vorschlag antwortet, können Sie einen zusätzlichen Befehl eingeben, um die Regel weiter anzupassen. Sie können aber auch direkt auf Regel testen klicken, um zu sehen, wie sich die Regel im Vergleich zu Ihrem letzten Transaktionsverlauf verhält.
- Wenn Sie mit der Regel zufrieden sind, klicken Sie auf Regel hinzufügen, um sie für alle zukünftigen Transaktionen zu aktivieren.
Zustimmung zur Datenerfassung zu Verbesserungszwecken: Durch die Verwendung von Radar Assistant erklären Sie sich damit einverstanden, dass Stripe Ihre Chat-Eingaben protokolliert und verwendet, um die Radar Assistant-Funktionen zu trainieren und zu verbessern. Wenn Sie nicht möchten, dass Ihre Chat-Eingaben für diesen Zweck verwendet werden, können Sie Regeln auch manuell schreiben.
Erfahren Sie mehr über die KI-Optionen von Stripe.
Prüfregeln
Stripe wickelt Zahlungen weiterhin wie gewohnt ab, wenn sie die Kriterien einer Prüfregel erfüllen. Allerdings werden sie in Ihrer Überprüfungsliste gespeichert, damit Ihr Team sie genauer prüfen kann. Eine zu weit gefasste Regel kann unter Umständen dazu führen, dass zu viele Zahlungen in Ihre Überprüfungsliste aufgenommen werden, was Ihre Kund/innen behindert und Ihrem Prüfungsteam zusätzlichen Aufwand bereitet.
Die Stripe-Nutzeroberfläche zum Testen von Regeln führt eine Simulation der Zahlungen der letzten sechs Monate durch. So können Sie ermitteln, wie viele legitime, betrügerische und blockierte Zahlungen von der Regel betroffen wären. Beim Testen einer Regel und Prüfen der letzten sechs Monate sollten Sie Folgendes sicherstellen:
- Gesamtvolumen der Zahlungen ist gering. Die Prüfung dieser Zahlungen sollte keine Belastung für Ihr Team darstellen.
- Menschliche Prüfer schaffen einen Mehrwert. Ein menschlicher Prüfer kann meist mit größerer Sicherheit als das automatisierte System erkennen, ob es sich um eine betrügerische Zahlung handelt.
- Die Regel führt zu einer Mischung aus erfolgreichen und zurückerstatteten oder angefochtenen Zahlungen. Das bedeutet, dass eine zusätzliche Prüfung dieser Zahlungsarten dazu beitragen kann, legitime von betrügerischen Zahlungen zu unterscheiden.
Das folgende Beispiel zeigt, wie eine Prüfregel verbessert werden kann, die von einem Unternehmen zur Prüfung von Prepaid-Kreditkarten erstellt wurde.
| Ursprüngliche Regel | Verbesserte Regel |
|---|---|
Review if :card_funding: = | Review if :is_disposable_email: and :card_funding: = |
| Zu weit gefasst – ergibt zu viele Prüfungen | Fokussierter – ergibt weniger Prüfungen |
Sperrregeln
Sie können Blockregeln verwenden, um Zahlungen zu blockieren, die Sie mit ziemlicher Sicherheit als betrügerisch einstufen oder die bestimmten Einschränkungen Ihres Unternehmens unterliegen (beispielsweise Blockieren von Zahlungen mit Prepaid-Karten). Wenn Sie nicht wissen, wie Sie Blockregeln anwenden, empfehlen wir, Zahlungen mithilfe einer Prüfregel zur Prüfung vorzulegen. Nach der Prüfung dieser Zahlungen auf mögliche falsch positive Ergebnisse können Sie stattdessen eine Blockregel erstellen.
Blockregeln haben nur Auswirkungen auf betrügerische und erfolgreiche Zahlungen, da bereits blockierte Zahlungen ignoriert werden. Stellen Sie beim Testen einer Regel Folgendes sicher:
- Falsch positive Ergebnisse so gering wie möglich halten. Stripe identifiziert beim Testen die Anzahl der erfolgreichen und angefochtenen Zahlungen, die mit der Regel übereingestimmt hätten. Bei einer guten Sperrregel werden erheblich mehr betrügerische Zahlungen als legitime Zahlungen blockiert.
- Unnötige Regeln minimieren. Wenn Ihre Regel zwar sehr gut zu funktionieren scheint, aber bereits durch eine vorhandene Regel abgedeckt ist, ist Ihre neue Regel möglicherweise gar nicht erforderlich. Entsprechend sollten Sie, wenn die Ergebnisse beim Testen unterschiedlich ausfallen, die Einrichtung einer Prüfregel in Betracht ziehen, damit Sie mehr Informationen über diese Arten von Zahlungen sammeln können.
Das folgende Beispiel zeigt, wie eine Sperrregel verbessert werden kann, die von einem Unternehmen erstellt wurde, bei dem es zu vermehrten Betrugsfällen im Zusammenhang mit Zahlungen außerhalb der USA gekommen ist:
| Ursprüngliche Regel | Verbesserte Regel |
|---|---|
Block if :card_country: != | Block if :card_country: != |
| Zu weit gefasst – eine hohe Anzahl legitimer Zahlungen wird blockiert | Fokussierter – ergibt weniger Prüfungen |
Zulassungsregeln
Zulassungsregeln überschreiben Ihre sämtlichen anderen Regeln. Sie sollten sie daher mit Bedacht verwenden. Für viele Unternehmen ist die Implementierung von Zulassungsregeln möglicherweise nicht erforderlich. Wenn Sie Bedenken haben, dass eine Zulassungsregel selbst eine kleine Anzahl an betrügerischen Zahlungen zulassen könnte, sollten Sie vor der Implementierung Anpassungen zur weiteren Einschränkung dieser Regeln prüfen.
Zulassungsregeln gelten für alle neuen Zahlungen, sobald Sie die Regel erstellen. Hierzu gehören auch alle Zahlungen, die zuvor blockierten Zahlungen ähnlich sind. Stellen Sie beim Testen einer Regel Folgendes sicher:
- Die Anzahl der zuvor blockierten Zahlungen prüfen, die zugelassen worden wären. Zulassungsregeln überschreiben alle anderen Regeln und die Risikoeinschätzung von Stripe. Beim Testen einer neuen Zulassungsregel würden alle angezeigten Zahlungen bei aktivierter Regel zugelassen werden. Dies kann auch blockierte oder angefochtene Zahlungen mit einschließen, was sich auf Ihre zukünftige Anfechtungsquote auswirkt.
- Alle Zahlungen mit hohem Risiko blockieren. Dazu können Sie einer Zulassungsregel Folgendes hinzufügen:
and :risk_level: !='highest' - Legitime Transaktionshistorie in Ihrem Unternehmen bewerten. Sie können Verbindungen zwischen Ihren eigenen Kundinnen und Kunden analysieren, um ein höheres Transaktionsvolumen auf Grundlage früherer legitimer Käufe zuzulassen. Dadurch werden weniger Zahlungen von Kundinnen und Kunden blockiert, die zuvor legitime Zahlungen an Ihr Unternehmen geleistet haben. Überprüfen Sie hierfür die Attributliste und suchen Sie nach Attributen, die das Wort „Kundin“ oder „Kunde“ enthalten.
Das folgende Beispiel zeigt, wie eine Zulassungsregel für ein Unternehmen verbessert werden kann, das in der Regel (jedoch nicht immer) legitime Zahlungen von Kund/innen aus Großbritannien erhält:
| Ursprüngliche Regel | Verbesserte Regel |
|---|---|
Allow if :ip_country: = | Allow if :ip_country: = |
| Zu weit gefasst – einige betrügerische Zahlungen werden zugelassen | Fokussierter – eine kleinere Anzahl betrügerischer Zahlungen wird zugelassen |
Pflege Ihrer Regeln
Mit dem stetigen Wachstum Ihres Unternehmens sollten Sie sicherstellen, dass Ihre Regeln auch weiterhin die Arten von Kund/innen abbilden, mit denen Sie zusammenarbeiten möchten. Im Folgenden finden Sie einige Best Practices, um die Regeln für Ihr Unternehmen auf dem aktuellen Stand zu halten.
Regeln regelmäßig überwachen, um Wirksamkeit sicherzustellen
Regelmetriken
Da sich die Betrugsmuster ständig ändern, stellen wir Metriken zur Verfügung, um zu zeigen, wie diese Regeln funktionieren. Diese Metriken variieren je nach Art der Regel, da die Regelarten verschiedene Aktionen durchführen.
Das Diagramm „Regelleistung“ stellt das Verhalten Ihrer Radar-Regeln dar. Achten Sie auf unerwartete Zunahmen oder Rückgänge bei der Anzahl der Zahlungen, die die Regeln erfüllen, wie beispielsweise Regeln, die zu viele Zahlungen zulassen, oder Regeln, die zu viele Zahlungen blockieren. Diese Zunahmen können auf eine Änderung der Arten von Zahlungen hinweisen, die Ihr Unternehmen erhält, oder eine Aktualisierung der Regeln selbst rechtfertigen. Aktualisierungen von Regeln werden als Dreiecke im Diagramm angezeigt, sodass Sie die Auswirkungen der Änderung prüfen können.
Farbige Linien zeigen die Anzahl der Zahlungen an, die 3DS-Regeln, Zulassungsregeln, Blockregeln und Prüfregeln entsprechen. Dreieckige Symbole auf diesen Diagrammlinien stellen Aktualisierungen von Regeln des entsprechenden Typs dar.
Sie können Informationen über die Wirksamkeit Ihrer Regeln abrufen und prüfen, bei wie vielen Zahlungen die einzelnen Regeln zur Anwendung gekommen sind. Außerdem können Sie eine gefilterte Liste aller Zahlungen anzeigen und herunterladen, auf die eine Regel angewendet wurde. Werten Sie diese Informationen aus, um entscheiden zu können, ob Sie Änderungen an Regeln vornehmen oder sie ganz entfernen müssen.
Um zusätzliche Befehle anzuzeigen, klicken Sie auf das Überlaufmenü (). Zu den weiteren Befehle zählen: Deaktivieren, Aktivieren, Bearbeiten oder Löschen für jede Regel.
Sie können auch unsere Berichtsprodukte Sigma und Data Pipelines verwenden, um Daten zu angefochtenen Zahlungen und Betrug abzufragen, einschließlich Regelentscheidungen und Attribute für jede einzelne Zahlung.
Wirksamkeit der Regel bewerten
Sie können sich über die Wirksamkeit Ihrer Regeln informieren und sehen, wie viele Zahlungen von den einzelnen Regeln betroffen waren. Sie können auch eine gefilterte Liste aller Zahlungen, auf die eine Regel angewendet wurde, anzeigen und herunterladen. Überprüfen Sie die Beispielfragen in der folgenden Tabelle, um zu entscheiden, ob Sie Änderungen an Regeln vornehmen oder sie ganz entfernen müssen.
| Regeltyp | Bewerten | Zu erwägende Maßnahmen |
|---|---|---|
| Allgemein | Wenn diese Regel mit keinen Zahlungen mehr übereinstimmt | Entfernen Sie die Regel. |
| Wenn diese Regel ein anomales Verhalten hat, wie z. B. die Zulassung von mehr Zahlungen als in früheren Zeiträumen. | Überprüfen Sie Zahlungen, die dieser Regel entsprechen, manuell, um festzustellen, ob dies das gewünschte Verhalten ist. | |
| 3DS | Wenn die 3DS-Abschlussquote hoch ist, die Anzahl der Zahlungsanfechtungen/frühzeitigen Betrugswarnungen aber gering ist. | Entfernen Sie die Regel, da Sie möglicherweise gute Nutzer/innen behindern. |
| Wenn der Betrug bei Transaktionen, die 3DS bestehen, hoch ist. | Erwägen Sie, Ihre 3DS-Regel in eine Sperrregel umzuwandeln, um zu verhindern, dass diese Nutzer/innen den reibungslosen (von den Ausstellern kontrollierten) Datenfluss passieren oder einen Erstbetrug begehen. | |
| Wenn die Konversionsrate für 3DS niedrig ist. | Dies könnte eine gute Regel sein, da sie hauptsächlich Betrüger/innen blockieren würde. Ziehen Sie jedoch auch in Betracht, übereinstimmenden Zahlungen manuell zu prüfen, um sicherzustellen, dass Ihre vertrauenswürdigen Nutzer/innen Käufe nicht aufgrund unnötiger Schwierigkeiten abbrechen. | |
| Zulassen | Wenn die Anzahl der Zahlungsanfechtungen, frühzeitigen Betrugswarnungen, Rückerstattungen oder fehlgeschlagenen Zahlungen hoch ist. | Entfernen Sie die Regel, die fehlerhafte Zahlungen zulässt. |
| Blockieren | Nimmt die Anzahl der Blockierungen ab, aber Ihre Betrugsfälle sind immer noch konstant oder nehmen zu? | Ändern Sie Ihre Regel, da sie möglicherweise nicht mehr wirksam ist. |
| Wenn die Anzahl der Blockierungen steigt, aber Ihre Betrugsfälle immer noch konstant sind oder zunehmen. | Ändern Sie Ihre Regel, da sie möglicherweise vertrauenswürdige Nutzer/innen blockiert. | |
| Wenn die Anzahl der Blockierungen steigt und Ihr Betrug zurückgeht. | Dies deutet darauf hin, dass Ihre Regel wirksam ist. Sie sollten jedoch in Betracht ziehen, einige Transaktionen manuell zu überprüfen, um sicherzustellen, dass Sie nicht zu viele legitime Nutzer/innen blockieren. | |
| Manuell überprüfen | Wenn der Anteil der Zahlungen, die überprüft werden, niedrig ist. | Gestalten Sie die Regel restriktiver, da sie möglicherweise zu weit gefasst ist. |
| Wenn die Anzahl erfolgreicher oder genehmigter Zahlungen hoch ist. | Entfernen Sie die manuelle Überprüfungsregel vollständig oder erstellen Sie eine Zulassungsregel für diese Zahlungen. | |
| Wenn es viele Rückerstattungen, Zahlungsanfechtungen und frühzeitige Betrugswarnungen gibt. | In eine Blockregel konvertieren. |
Regeln zum Anfordern von 3DS
Für Regeln zum Anfordern von 3DS wird Folgendes angezeigt:
- 3DS angefordert: Wie oft eine Regel eine 3DS-Anforderung ausgelöst hat.
Klicken Sie auf eine 3DS-Regel, um die folgenden Metriken anzuzeigen:
Zulassungsregeln
Für Zulassungsregeln können Nutzer/innen von Radar for Fraud Teams Folgendes anzeigen:
- Zugelassene Zahlungen: Die Gesamtzahl der gemäß Ihren Regeln zugelassenen Zahlungen.
- Volumen, zulässige Zahlungen: Der Gesamtbetrag in Ihrer lokalen Währung, der aus gemäß Ihren Regeln zugelassenen Zahlungen stammt.
- Risikobewertung: Die entsprechenden Risikoergebnisse, die von den Stripe-Modellen für maschinelles Lernen den gemäß Ihren Regeln zugelassenen Zahlungen zugewiesen wurden.
- Anfechtungen aus Überschreibungen: Die Gesamtanzahl der Anfechtungen aus zugelassenen Zahlungen.
- Volumen, Anfechtungen aus Überschreibungen: Der Gesamtbetrag in Ihrer lokalen Währung, der von Anfechtungen aus zugelassenen Zahlungen stammt.
Klicken Sie auf eine Zulassungsregel, um die folgenden Metriken anzuzeigen:
Blockregeln
Für Blockregeln wird Folgendes angezeigt:
- Blockierte Zahlungen: Die Gesamtzahl der durch Ihre Regeln blockierten Zahlungen.
- Volumen, blockierte Zahlungen: Der Gesamtbetrag in Ihrer lokalen Währung, der aus gemäß Ihren Regeln blockierten Zahlungen stammt.
Nutzer/innen von Radar for Fraud Teams können auch Folgendes anzeigen:
- Risikobewertung: Die entsprechenden Risikoergebnisse, die von den Stripe-Modellen für maschinelles Lernen den gemäß Ihren Regeln zugelassenen Zahlungen zugewiesen wurden.
- Geschätzte Falsch-Positiv-Erkennungsquote: Der geschätzte Prozentsatz nicht betrügerischer Zahlungen, die sowohl für Ihre Blockregeln insgesamt und auch für einzelne Regeln blockiert wurden. (Diese Schätzungen beruhen auf den geschätzten Falsch-Positiv-Erkennungsquoten der entsprechenden Risikobewertungen für maschinelles Lernen, die wir mit Experimenten überall im Stripe-Netzwerk ermitteln).
- Geschätzte Anzahl der verhinderten betrügerischen Zahlungen – Die geschätzte Anzahl betrügerischer Zahlungen, die durch deine Blockregeln verhindert wurde. Stripe verwendet Risikobewertungen für maschinelles Lernen, die durch die Analyse von Millionen von Transaktionen über das Stripe-Netzwerk berechnet werden, um Zahlungen mit einer hohen Wahrscheinlichkeit zu prognostizieren, dass sie aufgrund von Betrug angefochten oder abgelehnt werden, und um zu schätzen, welche dieser Zahlungen durch Ihre Regeln erfolgreich blockiert wurden.
Klicken Sie auf eine Blockregel, um die folgenden Metriken anzuzeigen:
Prüfregeln
Für Prüfregeln können Nutzer/innen von Radar for Fraud Teams Folgendes anzeigen:
- Zur Prüfung vorgelegte Zahlungen: Die Gesamtzahl der Zahlungen, die durch Ihre Regeln zur manuellen Prüfung gesendet wurden.
- Volumen, genehmigte Prüfungen: Der Gesamtbetrag in Ihrer lokalen Währung, der aus genehmigten Zahlungsprüfungen stammt.
- Rückerstattungsrate: Der Prozentsatz der zurückerstatteten Überprüfungen.
- Anfechtungen aus genehmigten Prüfungen: Die Gesamtzahl der Zahlungen, die bei Ihrer Überprüfung genehmigt wurden, aber letztlich angefochten wurden.
- Volumen, Anfechtungen aus genehmigten Prüfungen: Der Gesamtbetrag in Ihrer lokalen Währung, der von Zahlungsanfechtungen aus genehmigten Zahlungsprüfungen stammt.
Klicken Sie auf eine überprüfen, um die folgenden Metriken anzuzeigen:
Manuelle Überprüfungsliste regelmäßig überwachen
Wenn Ihre Überprüfungsliste zu lang wird, sollten Sie kontrollieren, ob Sie die richtigen Regeln eingerichtet haben. Wenn die meisten Prüfungsergebnisse dazu führen, dass Zahlungen als betrügerisch eingestuft und zurückerstattet werden, sollten Sie zusätzliche Regeln zum Blockieren von Zahlungen festlegen. Entsprechend sollten Sie, wenn die meisten Zahlungen genehmigt werden, Ihre Prüfregeln genauer definieren.
Angefochtene und zurückerstattete Zahlungen analysieren
Zahlungsanfechtungen sind zwangsläufig mit Betrug verbunden. Je mehr Sie also zur Reduzierung von Betrug tun, desto niedriger ist Ihre Anfechtungsquote. Prüfen Sie, ob angefochtene Zahlungen ähnliche Eigenschaften haben (zum Beispiel von gleichen Standorten oder mit ähnlichen Beträgen). Diese Art von Nachforschung können Sie auch durchführen, indem Sie nach Zahlungen suchen, die während einer Prüfung zurückerstattet wurden. Wenn Sie Trends erkennen, können Sie geeignete Regeln testen und erstellen. Wenn es sich bei einer Zahlung offenbar um eine betrügerische Zahlung handelt, sollten Sie diese zurückerstatten und als Betrugsfall melden, um mögliche Zahlungsanfechtungen zu vermeiden.
Sie können auch unsere Produkte Sigma und Data Pipelines zur Berichterstattung verwenden, um Daten zu angefochtenen Zahlungen und Betrug abzufragen.
Sie können auf alle eingehenden Zahlungsanfechtungen über das Dashboard oder die API reagieren. In unserer Dokumentation zu Zahlungsanfechtungen finden Sie einige Vorschläge zur Darstellung eines gut dokumentierten Falls.
Wichtige Veränderungen im Unternehmen mit Auswirkungen auf Ihre Betrugsquote antizipieren
Wenn Sie größere Produkteinführungen oder Änderungen an Ihren Dienstleistungen beabsichtigen (zum Beispiel ein neues, höherwertiges Produkt oder die Ausweitung Ihrer Dienstleistungen auf neue Länder), empfiehlt es sich, diese Zahlungen anfangs zu überwachen. Sie können für solche Änderungen bestimmte Prüfregeln einrichten, um alle Zahlungen überprüfen zu können. Wenn Sie diese Zahlungen überprüfen und mögliche Muster identifizieren, können Sie neue Regeln definieren, um Ihr Unternehmen besser vor Betrug zu schützen.