Regeln
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 für alle Zahlungen, die 3D Secure unterstützen und von neuen Kund/innen 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 werden standardmäßig für alle Radar-Nutzer/innen aktiviert.
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. Diese Regeln können über das Stripe-Dashboard aktiviert oder deaktiviert werden.
Diese Regeln werden auch bei der Kartenvalidierung angewendet, die beim Hinzufügen einer Karte zu einem Kunden/einer Kundin 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 Stripe-Dashboard aktivieren oder deaktivieren.
Block if CVC verification fails
Stripe blockiert Zahlungen, bei denen die CVC-Prüfung eines Kartenausstellers/einer Kartenausstellerin fehlschlägt. Wenn der Kunde/die Kundin die CVC -Nummer nicht angibt, zum Beispiel weil er/sie eine Wallet verwendet oder sein Kartenaussteller/ihre Kartenausstellerin die Überprüfung nicht unterstützt, kann die Regel die Zahlung nicht blockieren.
Block if postal code verification fails
Stripe blockiert Zahlungen, wenn die Verifizierung der Postleitzahl eines Kartenausstellers fehlschlägt. Wenn der/die Kund/in die Postleitzahl nicht angibt oder der Kartenaussteller die Verifizierung nicht unterstützt, kann die Regel die Zahlung nicht blockieren. Diese Regel ist nicht immer standardmäßig für Ihr Konto aktiviert. Sie können sie jederzeit über das Stripe-Dashboard aktivieren oder deaktivieren.
Integrierte Regeln zum Anfordern von 3D Secure
Bei der Verwendung von 3D Secure werden Kundinnen/Kunden dazu aufgefordert, einen zusätzlichen Authentifizierungsschritt durchzuführen. Erst dann können sie die Zahlung abschließen. Wenn eine Zahlung mit 3D Secure 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 3D Secure 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 3D Secure 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 3D Secure-Authentifizierung auf, wenn die Karte in der Vergangenheit 3D Secure 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 3D Secure-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 3D Secure-Authentifizierung aufgefordert, wenn Stripe davon ausgeht, dass die 3D Secure-Authentifizierung nur minimale Auswirkungen auf die Konversionsrate hat.
- Aktivieren Sie diese Regel, wenn Sie die Anzahl der Zahlungen mit Haftungsverlagerung maximieren möchten.
Da 3D Secure von Ihren Kundinnen/Kunden einen weiteren Authentifizierungsschritt erfordert, kann sich eine undifferenzierte Verwendung von 3D Secure negativ auf die Konversionsraten auswirken. Stripe empfiehlt Ihnen die Verwendung unserer Standardregeln für das Anfordern von 3D Secure nur, wenn alle Zahlungen von unterstützten Karten über 3D Secure gesendet werden sollen.
Das Anfordern von 3D Secure bedeutet nicht unbedingt, dass der Aussteller 3D Secure 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 3D Secure-Authentifizierungsversuch mit Radar for Fraud Teams können Sie das Ergebnis in Zulassungs-, Blockier- oder Prüfregeln auswerten.
Die wichtigsten Attribute für benutzerdefinierte Radar-Regeln sind:
is_3d_secure
: Trifft zu, wenn die Karte unterstützt wurde, 3D Secure durch den Aussteller eingesetzt wurde und die Authentifizierung des Nutzers/der Nutzerin nicht fehlgeschlagen ist. Wir empfehlen im Allgemeinen, dies in Blockregeln zu verwenden.is_3d_secure_authenticated
Trifft zu, wenn 3D Secure durch den Aussteller eingesetzt wurde und der/die Nutzer/in eine vollständige Authentifizierung durchlaufen hat. Die Verwendung dieses Attributs in einer Blockregel schließt legitime Transaktionen aus, 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 3D Secure, zum Beispiel bei Apple Pay in bestimmten Regionen.
Für nutzerdefinierte Regeln empfehlen wir, die Regeln 3D Secure anfordern
und Blockieren
je nach Ihrer Risikobereitschaft aufeinander abzustimmen. Blockieren Sie jedoch keine Transaktionen, bei denen 3D Secure 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 3D Secure 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 3D Secure 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 3D Secure nicht unterstützen, ohne eine Blockregel nicht gesperrt. Aber 3D Secure-Versuche mit fehlgeschlagener Authentifizierung belasten die Autorisierung nicht weiter.
3D Secure immer basierend auf der Radar-Risikostufe anfordern
Sie möchten Radar verwenden, um 3D Secure für alle Zahlungen basierend auf der erhöhten oder der hohen Radar-Risikostufe und ab einem bestimmten Betrag anzufordern. Wenn Karten 3D Secure 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 3D Secure 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 3D Secure-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_acknowledged . 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 3D Secure 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 3D Secure registriert ist und versucht wurde, 3D Secure durchzuführen, sich der/die Nutzer/in jedoch nicht erfolgreich authentifiziert hat. Karten, die 3D Secure, SCA-Ausnahmen, Off-Session-Zahlungen wie wiederkehrende Abonnementgebühren 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 3D Secure 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 3D Secure 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 3D Secure nicht unterstützen, ohne eine Blockregel nicht gesperrt. Aber 3D Secure-Versuche mit fehlgeschlagener Authentifizierung belasten die Autorisierung nicht weiter.
3D Secure immer basierend auf Metadaten anfordern
Sie möchten Radar verwenden, um 3D Secure 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 3D Secure 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 3D Secure-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_acknowledged . 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 3D Secure für alle neuen Karten anzufordern und Zahlungen von Karten, die 3D Secure nicht unterstützen, manuell zu überprüfen.
Radar-Regel | Beschreibung |
---|---|
Request 3D Secure if is_missing(:seconds_since_card_first_seen:) | Diese Regel fordert 3D Secure 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 3D Secure nur anfordert, wenn :risk_level: != . |
3D Secure anfordern if :is_new_card_on_customer: | Diese Regel fordert als Alternative zu der obigen Regel 3D Secure für alle Karten an, die zum ersten Mal für einen Kunden/eine Kundin verwendet werden. Um Unstimmigkeiten für die Nutzer/innen zu verringern, können Sie eine zusätzliche Bedingung hinzufügen, die 3D Secure nur anfordert, wenn :risk_level: != . |
Überprüfen if not :is_3d_secure and not:is_off_session: and :digital_wallet: != | Diese Regel kennzeichnet Zahlungen, bei denen 3D Secure 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 3D Secure nicht unterstützen, ohne eine Blockregel nicht gesperrt. Aber 3D Secure-Versuche mit fehlgeschlagener Authentifizierung belasten die Autorisierung nicht weiter.
Für bestimmte Ausstellerländer ist immer 3D Secure erforderlich
Sie möchten mit Radar 3D Secure für alle Zahlungen von Kartenausstellern aus Ländern auf einer nutzerdefinierten Liste anfordern und Karten sperren, 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 3D Secure 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 3D Secure-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_acknowledged . 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 3D Secure für alle Zahlungen basierend auf der Radar-Risikostufe anzufordern und Karten, die 3D Secure nicht unterstützen, zu sperren, 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 3D Secure 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 3D Secure-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 3D Secure verwendet wurde, was jedoch keinen vollständig authentifizierten Ablauf zur Folge hatte. Dabei werden Grenzfällle wie attempt_acknowledged überprüft und legitime Zahlungen trotz SCA-Ausnahmen gekennzeichnet. Da die Überprüfungsregeln nach den Blockregeln ausgewertet werden, werden die Karten, die 3D Secure 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 Fragen, wenn Sie sich für oder gegen die Aktivierung benutzerdefinierter Regeln entscheiden:
- Halten Sie bestimmte Funktionen oder Nutzerverhalten für riskanter (zum Beispiel die Verwendung einer temporären E-Mail-Adresse)?
- Möchten Sie Regeln implementieren, 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)?
- Weisen Ihre bestehenden angefochtenen und zurückerstatteten Zahlungen gemeinsame Muster (zum Beispiel ähnliche Beträge, Kartentypen oder Länder) auf?
- Haben Sie bereits erstellte Regeln, 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 sollten sich daher zunächst informieren, wie unser System für Ihr Unternehmen funktioniert, bevor Sie es 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.
Im Folgenden finden Sie einige hilfreiche Tipps, die Sie beim Einrichten von Regeln beachten sollten:
- 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 3D Secure gelten nur bei Verwendung von Stripe Checkout, Payment Intents oder Setup Intents und werden vor der Anwendung von Prüf-, Sperr- 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 Typregeltyp 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 sollen, 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.
Sperrregeln 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, könnte Ihre neue Regel gar nicht erforderlich sein. 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 alle anderen Regeln, einschließlich der Modelle für maschinelles Lernen von Stripe. 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 von betrügerischen Zahlungen zulassen könnte, sollten Sie vor der Implementierung Anpassungen zur weiteren Einschränkung dieser Regeln prüfen. Da Zulassungsregeln alle anderen Regeln überschreiben, einschließlich der auf dem maschinellen Lernen von Stripe basierenden Entscheidungen, sollten Sie Zulassungsregeln erstellen, die weiterhin alle von uns als betrügerisch eingestuften Zahlungen blockieren.
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'
- Evaluieren Sie eine Historie rechtmäßiger Transaktionen in Ihrem Unternehmen. Sie können Verbindungen zwischen Ihren eigenen Kund/innen nutzen, um ein höheres Transaktionsvolumen basierend auf einer Historie rechtmäßiger Transaktionen zuzulassen. Auf diese Weise können Sie weniger Zahlungen von Kund/innen blockieren, die eine nachgewiesene Historie in Ihrem Unternehmen haben. Überprüfen Sie hierfür die Attributliste und suchen Sie nach Attributen, die das Wort “customer” (Kund/in) 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 Zahlung von betrügerischen 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 3D Secure-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.
Weitere Befehle werden angezeigt, wenn Sie auf das Symbol (•••) klicken. Zu den weiteren Befehlen zählen Deaktivieren, Aktivieren, Bearbeiten oder Löschen für die jeweilige Regel.
Optional können Sie 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 | Stimmt diese Regel mit keinen Zahlungen mehr überein? | Entfernen Sie die Regel. |
Zeigt diese Regel ein anomales Verhalten, 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 | Ist die 3DS-Abschlussquote hoch, aber die Anzahl der Zahlungsanfechtungen/EFWs ist gering? | Entfernen Sie die Regel, da Sie möglicherweise gute Nutzer/innen behindern. |
Ist Betrug hoch bei Transaktionen, die 3DS bestehen? | 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. | |
Ist die Konversionsrate für 3DS niedrig? | Dies mag eine gute Regel sein, da sie hauptsächlich Betrüger/innen blockieren könnte, aber erwägen Sie, die übereinstimmenden Zahlungen manuell zu untersuchen, um sicherzustellen, dass Ihre guten Nutzer/innen nichtaufgrund zusätzlicher Schwierigkeiten abbrechen. | |
Zulassen | Ist die Anzahl der Zahlungsanfechtungen, EFWs, Rückerstattungen oder fehlgeschlagenen Zahlungen hoch? | 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 gültig ist. |
Steigt die Anzahl der Blockierungen, aber Ihre Betrugsfälle sind immer noch konstant oder nehmen sie zu? | Ändern Sie Ihre Regel, da sie vertrauenswürdige Nutzer/innen blockieren könnte. | |
Steigt die Zahl der Blockierungen und geht Ihr Betrug zurück? | Dies lässt vermuten, dass Ihre Regel wirksam ist. Sie sollten jedoch in Betracht ziehen, einige Transaktionen manuell zu überprüfen, um sicherzustellen, dass Sie nicht zu viele gute Nutzer/innen blockieren. | |
Manuell überprüfen | Ist der Anteil der Zahlungen, die überprüft werden, niedrig? | Gestalten Sie die Regel restriktiver, da sie möglicherweise zu weit gefasst ist. |
Ist die Anzahl erfolgreicher oder genehmigter Zahlungen hoch? | Entfernen Sie die manuelle Überprüfungsregel vollständig oder erstellen Sie eine Zulassungsregel für diese Zahlungen. | |
Gibt es viele Rückerstattungen, Zahlungsanfechtungen und Frühzeitige Betrugswarnungen? | 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 mit den gemäß Ihren Regeln zugelassenen Zahlungen verbunden ist.
- Risikobewertung – Die entsprechenden Risikoergebnisse, die von den Stripe-Modellen für maschinelles Lernen den gemäß Ihren Regeln zugelassenen Zahlungen zugewiesen wurden.
- Volumen, Anfechtung aus Überschreibungen – Der Gesamtbetrag in Ihrer lokalen Währung, der Anfechtungen aus zugelassenen Zahlungen zugeordnet ist.
- Volumen, Anfechtung aus Überschreibungen – Der Gesamtbetrag in Ihrer lokalen Währung, der Anfechtungen aus zugelassenen Zahlungen zugeordnet ist.
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 mit den gemäß Ihren Regeln blockierten Zahlungen verbunden ist.
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 vermiedene Zahlungsanfechtungen – Die geschätzte Anzahl der Zahlungsanfechtungen, die aufgrund Ihrer Blockregeln verhindert wurden. Dies wird anhand der Genauigkeit der entsprechenden Risikobewertungen des maschinellen Lernens geschätzt, die wir mit Experimenten überall im Stripe-Netzwerk ermitteln.
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:
- Zahlungen zur Prüfung vorgelegt – 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 mit den genehmigten Zahlungsprüfungen verbunden ist.
- 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 mit Zahlungsanfechtungen aus genehmigten Zahlungsprüfungen verbunden ist.
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. Sie sollten prüfen, ob angefochtene Zahlungen ähnliche Eigenschaften haben (zum Beispiel von gleichen Standorten oder mit ähnlichen Beträgen). Diese Art von Untersuchung 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.
Optional können Sie unsere Reporting-Produkte Sigma und Data Pipelines 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.