# Betrugspräventionsregeln Nutzen Sie Regeln zur Betrugsprävention, um Ihr Unternehmen zu schützen. Mit den Regeln zur Betrugsprävention können Sie immer dann Maßnahmen ergreifen, wenn eine Zahlung bestimmte Kriterien erfüllt. Stripe Radar bietet integrierte Regeln, mit denen Sie betrügerische Aktivitäten bei Karten-, ACH- und SEPA-Lastschriftzahlungen erkennen und sich davor schützen können. Mit Radar for Fraud Teams und [Radar für Plattformen](https://docs.stripe.com/radar/radar-for-platforms.md) können Sie über das [Dashboard](https://dashboard.stripe.com/test/radar/rules) benutzerdefinierte Regeln erstellen, die auf der für Ihr Unternehmen spezifischen Geschäftslogik basieren. Sie können 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 per Prepaid-Karte und einem Betrag von mehr als 1.000 USD - **Prüfen und Auszahlungen automatisch unterbrechen** bei Konten mit einer hohen Rate an Zahlungsanfechtungen (mit Radar für Plattformen) > EU-Unternehmen könnten von der [Geoblocking-Verordnung](https://support.stripe.com/questions/eu-geo-blocking-regulation-changes) und deren Verboten zur Blockierung von Zahlungen von Kundinnen und Kunden mit Sitz in EU-Mitgliedstaaten betroffen sein. ## Integrierte Regeln Die folgenden Regeln sind standardmäßig verfügbar, sofern sie nicht als nutzerdefinierte Regeln gekennzeichnet sind. Diese sind nur verfügbar, wenn Sie Radar for Fraud Teams oder Radar für Plattformen verwenden. > #### Betrug automatisch blockieren > > Alternativ können Sie Radar-[Risikokontrollen](https://docs.stripe.com/radar/risk-settings.md) verwenden, um Betrugsversuche automatisch zu blockieren. Die Risikokontrollen verwenden [frühzeitige Betrugswarnungen](https://docs.stripe.com/radar/risk-settings.md#early-fraud-warning) , um Zahlungen mit dem höchsten Risiko zu ermitteln und zu blockieren. ### KI-Risikoprüfungen Alle Radar-Angebote enthalten eine Reihe von auf den Bewertungen unserer KI Modelle basierten Standardregeln. | Radar-Regel | Beschreibung | | ------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `if :risk_level: = 'highest'` (Deprecated) | Die Regel blockiert Zahlungen mit hohem Betrugsrisiko, wodurch diese nicht abgewickelt werden. Diese Regel ist standardmäßig für alle Radar-Nutzer/innen aktiviert. | | `if :risk_level: = 'elevated'` | Gemäß dem Standardverhalten von Radar for Fraud Teams und Radar für Plattformen werden Zahlungen zur Prüfung vorgelegt, bei denen der Verdacht auf ein erhöhtes Betrugsrisiko besteht. | Radar für Platformen verfügt über zusätzliche KI-Modelle auf Konto-Ebene, die durch zwei Standardregeln integriert sind: `if :account_risk_level: = 'highest'` `if :account_risk_level: = 'elevated'` Wir berechnen das Risiko auf Konto-Ebene anhand von KYC-Informationen, Transaktionen, geografischen Risikofaktoren und Verhaltensmustern. ### Herkömmliche Kartenprüfungen Eine Zahlung kann auch dann erfolgreich sein, wenn die Prüfung der *Prüfziffer* (The address verification system (AVS) is used to pass billing address information to issuers to verify the data if available) oder Adresse (*AVS* (The address verification system (AVS) is used to pass billing address information to issuers to verify the data if available)) fehlschlägt, da Aussteller bei der Entscheidung, eine Zahlung zu autorisieren, zahlreiche Risikofaktoren bewerten. Ein Aussteller einer Karte kann eine Zahlung, bei der die Prüfziffer oder Postleitzahl nicht verifiziert wurde, dennoch für legitim halten und sie daher genehmigen. Sie können die in Radar integrierten Regeln aktivieren, um bestimmte Zahlungen zu blockieren, die vom Kartenaussteller genehmigt wurden. Wenn diese Regeln aktiviert sind, wirken sie sich auch auf das Anhängen einer Karte an eine Kundin/einen Kunden und das Erstellen eines Kunden/einer Kundin aus, wenn Sie Karte und Kundin/Kunden zusammen erstellen. #### CVC- und AVS-Regeln Ab dem 17. Dezember 2024 zeigt werden diese Regeln neuen und bestehenden Kundinnen/Kunden angezeigt, die die älteren CVC- oder AVS-Regeln nicht verwendet haben. | Radar-Regel | Beschreibung | | ------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `wenn die CVC-Verifizierung basierend auf dem Risikoscore fehlschlägt` | Aktivieren Sie diese Regel, um Zahlungen zu blockieren, bei denen die Verifizierungsprüfung der Prüfziffer eines Kartenausstellers fehlschlägt, es sei denn, Stripe bewertet sie als risikoarm. Diese Regel blockiert keine Zahlungen, bei denen der Kunde/die Kundin die Prüfziffer nicht angibt, da er/sie beispielsweise ein *Wallet* verwendet oder der Kartenaussteller die Verifizierung nicht unterstützt. | | `, wenn die Verifizierung der Postleitzahl basierend auf dem Risikoscore fehlschlägt` | Aktivieren Sie diese Regel, um Zahlungen zu blockieren, bei denen die Überprüfung der Postleitzahl durch den Kartenausstellers fehlschlägt, es sei denn, Stripe bewertet sie als risikoarm. Diese Regel blockiert keine Zahlungen, bei denen der Kunde/die Kundin die Postleitzahl nicht angibt oder der Kartenaussteller ihre Verifizierung nicht unterstützt. | #### Ältere CVC- und AVS-Regeln Ab dem 17. Dezember 2024 zeigt das Dashboard diese Regeln bestehenden Kundinnen und Kunden an, die mindestens eine der Regeln aktiviert haben. | Radar-Regel | Beschreibung | | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `if CVC verification fails` | Aktivieren Sie diese Regel, um Zahlungen zu blockieren, die die Verifizierung der Prüfziffer durch den Kartenaussteller nicht bestehen. Diese Regel blockiert keine Zahlungen, bei denen der Kunde/die Kundin die Prüfziffer nicht angibt, z. B. weil er/sie eine *Wallet* (A digital wallet is a contactless payment method that stores payment options, such as credit and debit cards, allowing customers to use a smart device to make a purchase) verwendet oder sein/ihr Kartenaussteller die Verifizierung nicht unterstützt. | | `if postal code verification fails` | Aktivieren Sie diese Regel, um Zahlungen zu blockieren, wenn die Überprüfung der Postleitzahl durch den Kartenaussteller fehlschlägt. Diese Regel blockiert keine Zahlungen, bei denen der Kunde/die Kundin die Postleitzahl nicht angibt oder der Kartenaussteller ihre Überprüfung nicht unterstützt. | ### Integrierte Regeln zum Anfordern von 3D Secure Bei der Verwendung von *3D Secure (3DS)* (3D Secure (3DS) provides an additional layer of authentication for credit card transactions that protects businesses from liability for fraudulent card payments) werden Kundinnen/Kunden dazu aufgefordert, einen zusätzlichen Authentifizierungsschritt durchzuführen. Erst dann können sie den Kaufablauf abschließen. Wenn eine Zahlung mit 3DS authentifiziert wird, geht die [Haftung](https://docs.stripe.com/payments/3d-secure/authentication-flow.md#disputed-payments) für Anfechtungen dieser Zahlung aufgrund Betrugs in der Regel von der Verkäuferin oder vom Verkäufer auf die Ausstellerin bzw. den Aussteller über. In den meisten Fällen haftet die Verkäuferin bzw. der Verkäufer also nicht für Kosten aufgrund betrügerischer Aktivitäten bei mit 3DS authentifizierten Zahlungen. Stripe verarbeitet automatisch Codes für vorläufig abgelehnte Zahlungen, 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](https://stripe.com/guides/strong-customer-authentication) (SCA). Durch die Deaktivierung von Radar wird nicht verhindert, dass 3DS in Fällen ausgelöst wird, in denen dies erforderlich ist. Stripe unterstützt drei ältere integrierte Regeln zur Anforderung von 3DS, wenn Radar mit [Payment Intents](https://docs.stripe.com/payments/accept-a-payment.md) oder [SetupIntents](https://docs.stripe.com/payments/save-and-reuse.md) verwendet wird: | Radar-Regel | Beschreibung | | ------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `wenn 3D Secure wird für die Karte empfohlen` (Veraltet) | Aktivieren Sie diese Regel, um die Kundin/den Kunden je nach Risiko zur 3DS-Authentifizierung aufzufordern. | | `wenn 3D Secure wird für diese Karte unterstützt` (Veraltet) | Aktivieren Sie diese Regel, um die Kundin oder den Kunden zur 3DS-Authentifizierung aufzufordern, solange ihre/seine Karte dies unterstützt. | | `wenn 3D Secure für Karte erforderlich` (Deprecated) | Aktivieren Sie diese Regel, um Kundinnen und Kunden zur 3DS-Authentifizierung aufzufordern, wenn die Karte in der Vergangenheit [3DS erforderte](https://docs.stripe.com/payments/3d-secure/authentication-flow.md#three-ds-cards). Unabhängig von diesen Regeln löst Stripe automatisch 3DS aus: - Wenn ein Soft Decline-Code darauf hinweist, dass der Aussteller 3DS verlangt. - Einhaltung von Vorschriften wie dem Mandat PSD2 [starke Kundenauthentifizierung](https://stripe.com/guides/strong-customer-authentication). | Da 3DS von Ihren Kundinnen und Kunden eine zusätzliche Authentifizierungsebene verlangt, kann die wahllose Verwendung von 3DS die Konversionsraten senken. Die Anforderung von 3DS bedeutet nicht unbedingt, dass der Aussteller 3DS tatsächlich durchführt. Erfahren Sie mehr über [mögliche Ergebnisse](https://docs.stripe.com/payments/3d-secure.md). ### Regeln zum Anfordern von 3D Secure anpassen und entsprechend bestimmten Ergebnissen handeln Nach dem 3DS-Authentifizierungsversuch mit [Radar for Fraud Teams](https://stripe.com/radar/fraud-teams) oder [Radar for Platforms](https://docs.stripe.com/radar/radar-for-platforms.md) können Sie das Ergebnis in Zulassungs-, Block- oder Prüfregeln auswerten. Nachfolgend finden Sie die wichtigsten Attribute für benutzerdefinierte Radar-Regeln. | Attribut | Beschreibung | | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `is_3d_secure` | Dies trifft zu, wenn die Karte unterstützt wird, 3DS vom Aussteller versucht wurde und die Authentifizierung der Kundin/des Kunden nicht fehlgeschlagen ist. Wir empfehlen in der Regel, dies in Blockierregeln zu verwenden. | | `is_3d_secure_authenticated` | Dies trifft zu, wenn 3DS vom Aussteller versucht wurde und die Kundin oder der Kunde eine vollständige Authentifizierung erfolgreich abgeschlossen hat. Die Verwendung dieses Attributs in einer Blockierregel schließt legitime Transaktionen aus, für die möglicherweise eine Ausnahme für die starke Kundenauthentifizierung (SCA) gilt oder die nicht eindeutig fehlgeschlagen sind bzw. erfolgreich authentifiziert wurden, wie es z. B. bei Verarbeitungsfehlern der Fall sein kann. | | `has_liability_shift` | Dies trifft zu, wenn Stripe erwartet, dass die Zahlung durch *Haftungsverlagerung* (With some 3D Secure transactions, the liability for fraudulent chargebacks (stolen or counterfeit cards) shifts from you to the card issuer) abgedeckt wird. Dies ist möglicherweise nicht immer dasselbe wie bei [3DS](https://docs.stripe.com/payments/3d-secure/authentication-flow.md#disputed-payments), z. B. Apple Pay in bestimmten Regionen. | Für nutzerdefinierte Regeln empfehlen wir, die Regeln %}3DS anfordern`` und `Blockieren` auf Ihre [Risikobereitschaft](https://stripe.com/guides/improve-fraud-management-with-radar-for-fraud-teams-and-stripe-data) abzustimmen. Blockieren Sie jedoch keine Zahlungen, bei denen 3DS nicht unterstützt wird, z. B. von einigen Wallets. Hier sind einige Beispiele, die zeigen, wie dies für verschiedene Use Cases 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: != 'normal' and :amount_in_usd: > 25` | Diese Regel prüft die Radar-Risikostufe, bevor 3DS für alle Zahlungen mit erhöhtem oder hohem Risiko ab einem bestimmten Betrag angefordert wird. | In diesem Fall würden Karten oder Wallets, die 3DS nicht unterstützen, ohne eine Blockierregel 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 zur Anforderung von 3DS für alle Zahlungen verwenden, basierend auf einem erhöhten oder hohen Risiko und ab einem bestimmten Betrag. Sie möchten keine Karten unterstützen, die 3DS nicht unterstützen. | Radar-Regel | Beschreibung | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `3D Secure anfordern if :risk_level: != 'normal' and :amount_in_usd: > 25` | Diese Regel prüft die Radar-Risikostufe 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: != 'normal' and :amount_in_usd: > 25 and not :is_off_session: and :digital_wallet: != 'apple_pay' and not (:digital_wallet: = 'android_pay' and :has_cryptogram:)` | Diese Regel blockiert Zahlungen ohne 3DS-Ablauf mit erhöhtem oder hohem Risiko ab einem bestimmten Betrag. Sie akzeptiert legitime Zahlungen, für die möglicherweise eine Ausnahme für eine starke Kundenauthentifizierung (SCA) gilt oder bei denen keine eindeutige fehlgeschlagene oder erfolgreiche Authentifizierung vorliegt, wie z. B. `attempt_acknowledged`. Die Regel akzeptiert Off-Session-Zahlungen wie wiederkehrende Abonnementzahlungen und Wallets wie Apple Pay oder Google Pay, um erfolgreich zu sein. | #### Nur mit 3D Secure authentifizierte Zahlungen akzeptieren, sofern 3D Secure unterstützt wird Sie verlassen sich darauf, dass Stripe 3DS bei Bedarf in Fällen wie der [starken Kundenauthentifizierung](https://stripe.com/guides/strong-customer-authentication) (SCA) aktiviert, möchten aber keine [Grenzfälle](https://docs.stripe.com/api/charges/object.md#charge_object-payment_method_details-card-three_d_secure-result) 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 für 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:: = 'bar'` | Diese Regel prüft, ob eine Metadatenbedingung vorliegt und fordert dann 3DS an. Um Kunden-Metadaten zu überprüfen, ersetzen Sie `::foo:: = 'bar'` mit einem Wert wie `::customer:trusted:: = 'false'`. | In diesem Fall werden Karten oder Wallets, die 3DS nicht unterstützen, ohne eine Blockierregel 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:: = 'bar'` | Diese Regel prüft, ob eine Metadatenbedingung vorliegt und fordert dann 3DS an. Um Kunden-Metadaten zu überprüfen, ersetzen Sie `::foo:: = 'bar'` mit einem Wert wie `::customer:trusted:: = 'false'`. | | `Blockieren if ::foo:: = 'bar' and not :is_3d_secure and not :is_off_session: and :digital_wallet: != 'apple_pay' and not(:digital_wallet: = 'android_pay' and :has_cryptogram:)` | Diese Regel blockiert Zahlungen ohne 3DS-Ablauf für Abbuchungen mit einem nutzerdefinierten Metadatenattribut. Sie akzeptiert jedoch legitime Zahlungen, 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), so dass diese erfolgreich abgewickelt werden. | #### 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: != 'normal'`. | | `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](https://docs.stripe.com/api/customers.md) 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: != 'normal'`. | | `Überprüfen if not :is_3d_secure and not:is_off_session: and :digital_wallet: != 'apple_pay' and not(:digital_wallet: = 'android_pay' and :has_cryptogram:)` | 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 Risikofaktoren beinhalten, wie z. B. CVC-Prüfungen des Ausstellers. | In diesem Fall werden Karten oder Wallets, die 3DS nicht unterstützen, ohne eine Blockierregel 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](https://docs.stripe.com/radar/lists.md) anfordern und Karten blockieren, die dies nicht unterstützen. | Radar-Regel | Beschreibung | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `3D Secure anfordern if :card_country: in @enforce_3ds_list` | Diese Regel prüft, ob eine Bedingung (basierend auf dem Ursprungsland des Kartenausstellers) vorliegt und vergleicht sie mit einer [nutzerdefinierten List](https://docs.stripe.com/radar/lists.md). Wenn es Übereinstimmungen gibt, fordern wir 3DS an. | | `Blockieren if :card_country: in @enforce_3ds_list and not :is_3d_secure and not :is_off_session: and :digital_wallet: != 'apple_pay' and not(:digital_wallet: = 'android_pay' and :has_cryptogram:)` | Diese Regel blockiert Zahlungen ohne 3DS-Ablauf, die aus Ländern auf der nutzerdefinierten Liste stammen. Sie akzeptiert legitime Zahlungen, für die möglicherweise eine Ausnahme für die starke Kundenauthentifizierung (SCA) 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 die Zahlung erfolgreich abzuwickeln. | #### 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 Risikostufe anzufordern. Außerdem möchten Sie Karten blockieren, die 3DS nicht unterstützen, möchten aber Grenzfälle manuell prüfen. | Radar-Regel | Beschreibung | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `3D Secure anfordern if :risk_level: != 'normal'` | Diese Regel prüft die Radar-Risikostufe, bevor 3DS für alle Zahlungen mit erhöhtem oder hohem Risiko ab einem bestimmten Betrag angefordert wird. | | `Blockieren if not :is_3d_secure: and :risk_level: != 'normal' and not :is_off_session: and :digital_wallet: != 'apple_pay' and not (:digital_wallet: = 'android_pay' and :has_cryptogram:)` | Diese Regel blockiert Zahlungen ohne 3DS-Ablauf bei Abbuchungen mit erhöhtem oder hohem Risiko ab einem bestimmten Betrag. Sie akzeptiert legitime Zahlungen, für die möglicherweise eine Ausnahme für die starke Kundenauthentifizierung (SCA) gilt. Sie akzeptiert Off-Session-Zahlungen (wie wiederkehrende Abonnementzahlungen) und Wallets (wie Apple Pay oder Google Pay), um die Zahlung erfolgreich abzuwickeln. | | `Überprüfen if not :is_3d_secure_authenticated: and :risk_level: != 'normal' and not :is_off_session: and :digital_wallet: != 'apple_pay' and not (:digital_wallet: = 'android_pay' and :has_cryptogram:)` | Diese Regel kennzeichnet Zahlungen, die 3DS verwendet haben, aber keinen vollständig authentifizierten Ablauf ergeben haben, für die manuelle Prüfung. Dadurch werden [Grenzfälle](https://docs.stripe.com/api/charges/object.md#charge_object-payment_method_details-card-three_d_secure-result) wie `attempt_acknowledged` überprüft und auch legitime Zahlungen trotz Ausnahmen von der starken Kundenauthentifizierung (SCA) markiert. Da Prüfregeln nach Blockierregeln die Bewertung durchlaufen, blockieren wir Karten, die 3DS nicht unterstützen. | ## Regeln erstellen Nur Kontoinhaber/innen, Administratoren und Entwickler/innen können Regeln erstellen. Wenn [Teammitglieder](https://support.stripe.com/questions/can-i-invite-other-team-members-or-my-developer-to-use-my-stripe-account) Regeln erstellen müssen, überprüfen Sie Ihre [Teameinstellungen](https://dashboard.stripe.com/settings/team), um sicherzustellen, dass diese über Administratorzugriff verfügen. Die Standardregeln von Stripe können eine beträchtliche Anzahl betrügerischer Zahlungen blockieren. Unternehmen, die mehr Kontrolle darüber benötigen, welche Zahlungen sie prüfen, zulassen oder blockieren möchten, können über Radar for Fraud Teams benutzerdefinierte Regeln erstellen. Plattformen können nutzerdefinierte Regeln über Radar für Plattformen erstellen, um das Zahlungsrisiko für ihre Plattform und verbundenen Konten zu kalibrieren und kontospezifische Regeln anzuwenden. Berücksichtigen Sie die folgenden Punkte, wenn Sie sich für oder gegen die Aktivierung benutzerdefinierter Regeln entscheiden: - Wenn Sie bestimmte Funktionen oder Nutzerverhaltensweisen für riskanter halten (zum Beispiel die Verwendung einer temporären E-Mail-Adresse). - Wenn Sie Regeln auf Grundlage der Zahlungsmethode implementieren möchten (z. B. automatisches Blockieren von Zahlungen per SEPA-Lastschrift, die eine bestimmte Risikobewertung überschreiten). - Wenn 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). - Weisen Ihre bestehenden angefochtenen und zurückerstatteten Zahlungen gemeinsame Muster (zum Beispiel ähnliche Beträge, Kartentypen oder Länder) auf? - Wenn Sie bereits Regeln haben, die Sie zu Stripe migrieren möchten. Viele dieser Regeln wurden womöglich bereits vom KI-Modell von Stripe berücksichtigt. Sie können sich zunächst informieren, wie unser System für Ihr Unternehmen funktioniert, bevor Sie dieses anpassen. - Wenn Sie automatisch Prüfungen durchführen und optional Auszahlungen für Konten unterbrechen möchten. Dies gilt nur für Plattformen. ### Effektive Regeln erstellen Regeln können zwar bei der Automatisierung Ihrer bestehenden Workflows 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 an Zahlungen mit erhöhtem Risiko zulassen oder eine hohe Anzahl legitimer Zahlungen blockieren. Denken Sie beim Einrichten von Regeln an Folgendes: - Standardmäßig gelten Regeln für alle von Radar unterstützten Zahlungsmethoden, es sei denn, Sie definieren mithilfe des Attributs `payment_method_type` eine bestimmte Zahlungsmethode im Regelprädikat. - Die Regeln gelten nur für künftige Zahlungen und nicht für bereits abgewickelte Zahlungen. - Die Regeln für die Anforderung von 3DS gelten nur bei Verwendung von [Stripe Checkout](https://docs.stripe.com/payments/checkout.md), [Payment Intents](https://docs.stripe.com/payments/accept-a-payment.md) oder [Setup Intents](https://docs.stripe.com/payments/save-and-reuse.md) und werden vor der Anwendung von Prüf-, Block- und Zulassungsregeln ausgewertet. - Bevor Sie eine Blockierregel implementieren, um alle Zahlungen zu blockieren oder Auszahlungen für Konten zu unterbrechen, die die Kriterien erfüllen, sollten Sie überlegen, ob Sie die Zahlungen oder Konten zuerst prüfen möchten. - Implementieren Sie Zulassungsregeln nur in geringem Umfang, da sie die Standardregeln von Stripe und alle benutzerdefinierten Regeln, die den gleichen Kriterien entsprechen, überschreiben. - Sie können maximal 200 Transaktionsregeln und 100 Kontoregeln erstellen. ## Transaktionsregeln erstellen Sie können Regeln auf der Seite [Radar-Regeln](https://dashboard.stripe.com/test/radar/rules) im Dashboard hinzufügen und verwalten. #### So fügen Sie eine Transaktionsregel hinzu 1. Klicken Sie auf **+ Regel hinzufügen**. 1. Regeltyp auswählen. 1. 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 dem von Ihnen ausgewählten Regeltyp vorab ausgefüllt. - `{attribute}`: ist das Element der zu bewertenden Zahlung, wie z. B. der Betrag oder der Kartentyp. Beginnen Sie Ihre Eingabe mit `:`, um eine Liste gültiger Attribute zu öffnen. Sie können Ihre nutzerdefinierten 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.: `=`, `>`, `!=` usw. - `{value}`: Der Wert des zu bewertenden Attributs. 1. Klicken Sie auf **Regel testen**. 1. Korrigieren Sie gegebenenfalls erkannte Validierungsfehler. 1. Prüfen Sie auf der Seite **Neue Regel prüfen**, wie diese Regel im Vergleich in Bezug auf Ihre letzten Zahlungen abschneidet, um zu entscheiden, ob Sie sie aktivieren möchten. Wenn sich die Regel auf Zahlungen von mehr als einer Zahlungsmethode auswirken könnte, verwenden Sie den Filter, um die Regelleistung nach Zahlungsmethode anzuzeigen (zum Beispiel ACH oder Karten). 1. Klicken Sie auf **Regel hinzufügen**, um diese Regel auf alle zukünftigen Transaktionen anzuwenden. ### Radar Assistant verwenden Der Stripe Regel-Editor verfügt über einen integrierten LLM-Assistenten, der eine Radar-Transaktionsregel aus einer Eingabeaufforderung in natürlicher Sprache erstellt. Erfahren Sie mehr über [AI-Dienste von Stripe](https://support.stripe.com/questions/use-of-artificial-intelligence-\(ai\)-in-stripe-services). > #### Zustimmung zu den Schulungsdaten > > 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. #### So verwenden Sie Radar Assistant 1. Klicken Sie auf der Seite [Radar-Regeln](https://dashboard.stripe.com/test/radar/rules) auf **+ Regel hinzufügen**. 1. Regeltyp auswählen. 1. Klicken Sie im Regel-Editor auf **Radar Assistant**. 1. 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.* 1. 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. 1. Wenn Sie mit der Regel zufrieden sind, klicken Sie auf **Regel hinzufügen**, um sie für alle zukünftigen Transaktionen zu aktivieren. > #### Geben Sie uns Feedback > > Helfen Sie uns, den Radar Assistant weiter zu verbessern. Klicken Sie auf **Feedback geben** und lassen Sie uns wissen, wie der Assistent für Sie funktioniert hat und was wir noch verbessern können. Wir freuen uns über alle Rückmeldungen, egal ob sich diese um die Genauigkeit des Vorschlags, die Nutzeroberfläche oder einen anderen Aspekt Ihrer Interaktion drehen. ### Prüfregeln Stripe wickelt Zahlungen weiterhin wie gewohnt ab, wenn sie die Kriterien einer Prüfregel erfüllen. Wir fügen diese Zahlungen Ihrer [Überprüfungsliste](https://dashboard.stripe.com/test/radar) hinzu, damit Ihr Team sie genauer prüfen kann. Eine zu weit gefasste Regel kann dazu führen, dass zu viele Zahlungen in Ihre Überprüfungsliste aufgenommen werden. Das verlangsamt die Abläufe Ihrer Kundinnen und Kunden und bereitet Ihrem Prüfungsteam zusätzlichen Aufwand. 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 gewesen wären, wenn die Regel umgesetzt worden wäre. 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/innen schaffen einen Mehrwert**. Ein/e menschliche/r Prüfer/in kann meist mit größerer Sicherheit als das automatisierte System erkennen, ob es sich um eine Zahlung mit erhöhtem oder hohem Risiko 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 | | -------------------------------------------------------------- | -------------------------------------------------------------------------------- | | `if :card_funding: = 'prepaid'` | `if :is_disposable_email: and :card_funding: = 'prepaid'` | | Diese Regel ist zu weit gefasst und führt zu vielen Prüfungen. | Diese Regel ist fokussierter und führt zu einer geringeren Anzahl von Prüfungen. | ### Sperrregeln Sie können Blockierregeln 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 Blockierregeln 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 Blockierregel 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, stattdessen 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 Blockierregel 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 | | ----------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- | | `if :card_country: != 'US'` | `if :card_country: != 'US' and :risk_level: = 'elevated'` | | Diese Regel ist zu weit gefasst und blockiert eine hohe Anzahl legitimer Zahlungen. | Diese Regel ist fokussierter und führt zu einer geringeren Anzahl von Prüfungen. | ### Zulassungsregeln Wenn Sie Zulassungsregeln erstellen möchten, [kontaktieren Sie uns](https://support.stripe.com/contact). 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 umfassen, was sich auf Ihre zukünftige Anfechtungsquoten 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](https://docs.stripe.com/radar/rules/reference.md#supported-attributes) 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 Kundinnen und Kunden aus dem Vereinigten Königreich erhält: | Ursprüngliche Regel | Verbesserte Regel | | ------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------- | | `if :ip_country: = 'GB'` | `if :ip_country: = 'GB' and :risk_level: != 'highest'` | | Diese Regel ist zu weit gefasst und ermöglicht einige betrügerische Zahlungen. | Diese Regel ist fokussierter und führt dazu, dass weniger betrügerische Zahlungen zugelassen werden. | ## Ihre Regeln beibehalten Mit dem stetigen Wachstum Ihres Unternehmens sollten Sie sicherstellen, dass Ihre Regeln auch weiterhin auf die Arten von Kundinnen und Kunden zugeschnitten sind, 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. ### Überwachen Sie die Regeln regelmäßig, um ihre Wirksamkeit sicherzustellen #### Regelmetriken Da sich die Betrugsmuster ständig ändern, stellen wir [Metriken](https://dashboard.stripe.com/settings/radar/rules) 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. ![](https://b.stripecdn.com/docs-statics-srv/assets/rule-performance.8d495f28c352641ff7b710df3c3df2ed.png) Vielleicht fällt Ihnen ein Unterschied zwischen der Anzahl der Zahlungen auf, die die Prüfregeln erfüllten, und der Anzahl der Zahlungen, die im gleichen Zeitraum an Ihre Überprüfungsliste gesendet wurden. Da nur *erfolgreiche* Zahlungen geprüft werden sollen, werden Zahlungen, die zwar den Kriterien einer Prüfregel entsprechen, aber z. B. vom Aussteller abgelehnt werden, nicht in die Überprüfungsliste aufgenommen. Verwenden Sie das **Regelleistungsdiagramm**, um das Verhalten Ihrer Radar-Regeln zu verstehen. Suchen Sie nach unerwarteten Spitzen oder Ablehnungen der Anzahl der Zahlungen, die Ihren Regeln entsprechen. Beispiele dafür sind Zulassungsregeln, die zu viele Zahlungen zulassen, oder Blockierregeln, die zu viele blockieren. Diese Spitzen können auf eine Änderung der Arten von Zahlungen hinweisen, die Ihr Unternehmen erhält, oder die Aktualisierung der Regeln erfordern könnten. **Farbcode-Linien** verfolgen die Anzahl der Zahlungen, die den [3DS](https://docs.stripe.com/issuing/3d-secure.md)-Regeln entsprechen – Zulassungsregeln, Blockierregeln und Prüfregeln. Aktualisierte Regeln werden als **dreieckige Symbole** auf den Diagrammlinien angezeigt und können Ihnen helfen, die Auswirkungen einer Änderung durch den Vor- und Nachhervergleich zu ermitteln. Klicken Sie auf das Überlaufmenü (⋯), um zusätzliche Befehle für eine beliebige Regel anzuzeigen, einschließlich **Deaktivieren**, **Aktivieren**, **Bearbeiten** oder **Löschen**. Sie können auch unsere Berichtsprodukte Sigma und Data Pipelines verwenden, um [Daten zu angefochtenen Zahlungen und Betrug](https://docs.stripe.com/stripe-data/query-disputes-and-fraud-data.md) abzufragen, einschließlich Regelentscheidungen und Attribute für jede einzelne Zahlung. #### Wirksamkeit der Regel bewerten Sie können Daten zur Wirksamkeit Ihrer Regeln ermitteln und sehen, wie viele Zahlungen von jeder Regel betroffen waren. Sie können auch eine gefilterte Liste jeder Zahlung anzeigen und herunterladen, auf die eine Regel angewendet wurde. Prüfen Sie die Beispielfragen in der folgenden Tabelle, um zu entscheiden, ob Sie Änderungen an Regeln vornehmen oder diese 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. | Prüfen Sie Zahlungen, die dieser Regel entsprechen, manuell, um festzustellen, ob dies das gewünschte Verhalten ist. | | 3DS | Wenn die 3DS-Abschlussquote hoch ist, aber die Anzahl der Zahlungsanfechtungen oder frühzeitigen Betrugswarnungen gering ist. | Entfernen Sie die Regel, da Sie Ihren Nutzer/innen die Abläufe erschweren könnte. | | | Wenn der Betrug bei Transaktionen, die 3DS bestehen, hoch ist. | Erwägen Sie, Ihre 3DS-Regel in eine Blockierregel 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, die betreffenden 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 | Wenn die Anzahl der Blockierungen sinkt, aber Ihre Betrugsfälle immer noch konstant sind oder zunehmen. | Ä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 gute Nutzer/innen blockiert. | | | Wenn die Anzahl der Blockierungen steigt und Ihre Betrugsquote zurückgeht. | Dies könnte eine effektive Regel sein. Erwägen Sie, einige Transaktionen manuell zu überprüfen, um sicherzustellen, dass Sie nicht zu viele gute 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 Prüfregel 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 die Anforderung von 3DS-Regeln zeigen wir **3DS angefordert** an, d. h. wie oft eine Regel eine 3DS-Anforderung ausgelöst hat. Sie können auf eine 3DS-Regel klicken, um die folgenden Kennzahlen anzuzeigen. ![](https://b.stripecdn.com/docs-statics-srv/assets/request-credentials-rule-details.c22b65bc432aafec9e5bcb6079c53528.png) **Zulassungsregeln** Wenn Sie Radar for Fraud Teams verwenden, können Sie die folgenden Zulassungsregeln einsehen: - **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](https://docs.stripe.com/radar/risk-evaluation.md#risk-outcomes), die von unseren KI-Modellen den nach Ihren Regeln zulässigen Zahlungen zugewiesen werden. - **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. > Wenn die Kennzahlen zur Anzahl der Zahlungsanfechtungen hoch ist, empfiehlt es sich ggf., gezieltere Zulassungsregeln zu erstellen, damit keine Zahlungen zugelassen werden, die letztendlich angefochten werden. Wählen Sie eine Zulassungsregel aus, um die folgenden Metriken anzuzeigen: ![](https://b.stripecdn.com/docs-statics-srv/assets/allow-rule-details.e8da078613fdbca5592d2f9330c0f6d4.png) **Blockregeln** Sie können die folgenden Blockierregeln anzeigen: - **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. Wenn Sie Radar for Fraud Teams verwenden, können Sie auch Folgendes anzeigen: - **Risikobewertung**: Die entsprechenden [Risikoergebnisse](https://docs.stripe.com/radar/risk-evaluation.md#risk-outcomes), die von unseren KI-Modellen den nach Ihren Regeln zulässigen Zahlungen zugewiesen werden. - **Geschätzte Falsch-Positiv-Erkennungsquote**: Der geschätzte Prozentsatz nicht betrügerischer Zahlungen, die sowohl gemäß Ihren Blockierregeln insgesamt als gemäß einzelner Regeln blockiert wurden. Diese Schätzungen beruhen auf den geschätzten Falsch-Positiv-Erkennungsquoten der entsprechenden KI-Risikobewertungen, 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 Ihre Blockierregeln verhindert wurden. Stripe verwendet KI-Risikobewertungen, die durch die Analyse von Millionen von Transaktionen über das Stripe-Netzwerk berechnet werden. So kann Stripe bei Zahlungen mit einer hohen Wahrscheinlichkeit prognostizieren, dass sie aufgrund von Betrug angefochten oder abgelehnt werden, und eine Schätzung dazu abgeben, welche dieser Zahlungen durch Ihre Regeln erfolgreich blockiert wurden. > Falls die geschätzten Kennzahlen zur Falscherkennungsquote hoch sind, empfiehlt es sich möglicherweise gezieltere Blockierregeln zu erstellen oder zu überprüfen, welche Zahlungen von der Regel abgedeckt werden. So werden weniger nicht betrügerische Zahlungen blockiert. Wählen Sie eine Blockierregel aus, um die folgenden Metriken anzuzeigen: ![](https://b.stripecdn.com/docs-statics-srv/assets/block-rule-details.5df9a2e8652f228cf61b525a32ef56da.png) **Prüfregeln** Wenn Sie Radar for Fraud Teams verwenden, können Sie die folgenden Prüfregeln einsehen: - **Zur Prüfung vorgelegte Zahlungen**: Die Gesamtzahl der Zahlungen, die gemäß Ihrer Regeln zur manuellen Prüfung gesendet wurden. - **Volumen, Zahlungen, die bei Prüfungen genehmigt wurden**: Der Gesamtbetrag (in Ihrer lokalen Währung) der Zahlungen, die in Prüfungen genehmigt wurden. - **Rückerstattungsrate**: Der Prozentsatz der überprüften Zahlungen, die zurückerstattet wurden. - **Angefochtene Zahlungen, die ursprünglich bei der Prüfung genehmigt wurden**: Die Gesamtzahl der Zahlungen, die bei Ihrer Prüfung genehmigt wurden, aber letztlich angefochten wurden. - **Volumen, Angefochtene Zahlungen, die ursprünglich bei der Prüfung genehmigt wurden**: Der Gesamtbetrag (in Ihrer lokalen Währung) der Zahlungen, die angefochten wurden, nachdem sie in Prüfungen genehmigt wurden. Wählen Sie eine Prüfregel aus, um die folgenden Metriken anzuzeigen: ![](https://b.stripecdn.com/docs-statics-srv/assets/review-rule-details.10851302ef65dee05ffce64f7989528f.png) #### Regelverlauf anzeigen Sie können einen Verlauf der Änderungen an Ihren Radar-Regeln anzeigen. Anhand dieses Prüfpfads können Sie nachvollziehen, wann eine Regel erstellt, bearbeitet, aktiviert oder deaktiviert wurde und von welchem Nutzer/in in Ihrem Team. Um die Aktivitäten für eine bestimmte Regel zu sehen, gehen Sie auf der Seite Radar auf die Registerkarte [Regeln](https://dashboard.stripe.com/radar/rules) und klicken Sie auf den Namen der Regel. Das Protokoll **Regelaktivität** zeigt eine Zusammenfassung aller Änderungen. Klicken Sie auf ein bestimmtes Ereignis, um weitere Details anzuzeigen, z. B. das vollständige Regelprädikat vor und nach der Aktualisierung. Sie können nur die Regeländerungen der letzten 180 Tage sehen. Wenn Sie diese Aktivität regelmäßig prüfen, können Sie Änderungen an den Regeln mit deren Auswirkungen auf Ihr Unternehmen in Beziehung setzen. ### Ihre Manuelle Überprüfungsliste regelmäßig überwachen Wenn Ihre Überprüfungsliste zu groß ist, um sie zu verwalten, stellen Sie sicher, dass Sie über die richtigen Regeln verfügen. Wenn die meisten Überprüfungen aufgrund von Betrug zu einer Rückerstattung führen, sollten Sie zusätzliche Regeln in Betracht ziehen, um Zahlungen zu blockieren. Wenn die meisten Zahlungen zugelassen werden, sollten Sie in Erwägung ziehen, Ihre Prüfregeln gezielter zu gestalten. ### Angefochtene und zurückerstattete Zahlungen analysieren [Zahlungsanfechtungen](https://docs.stripe.com/disputes.md) sind zwangsläufig mit Betrug verbunden. Je mehr Sie also zur Reduzierung von Betrug tun, desto niedriger ist Ihre Anfechtungsquote. Prüfen Sie, ob es bei den angefochtenen Zahlungen jegliche ähnliche Merkmale gibt (zum Beispiel stammen sie von den gleichen Standorten oder haben ähnliche 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](https://docs.stripe.com/stripe-data/query-disputes-and-fraud-data.md). Sie können auf alle eingehenden Zahlungsanfechtungen über das Dashboard oder die API reagieren. In unserer [Dokumentation zu Zahlungsanfechtungen](https://docs.stripe.com/disputes.md) 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 neuen 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. ## Regeln unterstützen mehrere Zahlungsmethoden (New) Standardmäßig prüfen Radar-Regeln Zahlungen für Karten, ACH- und SEPA-Lastschriften für die meisten Nutzer/innen. Wir unterstützen die Blockierregel für Zahlungen mit hohem Risiko für alle diese Zahlungsmethoden. Wenn Sie Radar for Fraud Teams oder Radar für Plattformen nutzen, unterstützen wir auch nutzerdefinierte Regeln mithilfe des Attributs `:payment_method_type:`, um Regeln zu erstellen, die nur für bestimmte Zahlungsmethoden gelten. Zum Beispiel: `if :payment_method_type: = 'us_bank_account'`. Erfahren Sie mehr über [unterstützte Attribute](https://docs.stripe.com/radar/rules/supported-attributes.md). ## Kontoregeln erstellen Mit Radar für Plattformen können Sie Konto-Regeln auch über die Registerkarte **Regeln** auf der Radar-Seite im Dashboard hinzufügen und verwalten. #### So fügen Sie eine Kontoregel hinzu 1. Klicken Sie auf **+ Regel hinzufügen**. 1. Wählen Sie den Regeltyp aus: **Prüfung** oder **Auszahlungsunterbrechung** (wodurch eine Prüfung UND Auszahlungsunterbrechung ausgelöst werden). 1. 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 dem von Ihnen ausgewählten Regeltyp vorab ausgefüllt. - `{attribute}`: ist das Element der auszuwertenden Zahlung, z. B. der Betrag oder Kartentyp. Beginnen Sie mit der Eingabe von `:`, um eine Liste gültiger Attribute zu öffnen. - `{operator}`: So vergleichen Sie das Attribut mit dem Wert, z. B.: `=`, `>`, `!=` usw. - `{value}`: Der Wert des zu bewertenden Attributs. 1. Klicken Sie auf **Regel testen**. 1. Korrigieren Sie gegebenenfalls erkannte Validierungsfehler. 1. Zeigen Sie auf der Seite **Neue Regel prüfen** die Konten an, die heute mit dieser Regel übereinstimmen würden, um zu bestätigen, ob Sie sie aktivieren möchten. 1. Klicken Sie auf **Regel aktivieren**, um diese Regel auf alle bestehenden und zukünftigen Konten anzuwenden. Das Testen von Regeln auf Konto-Ebene dauert länger als das Testen von Transaktionen. Wir empfehlen jedoch, Tests durchzuführen, um zu vermeiden, dass unbeabsichtigt Konten zur Überprüfung vorgemerkt oder automatische Auszahlungen unterbrochen werden. Testen Sie zunächst das Verhalten beim Vormerken von Konten zur Überprüfung. Testen Sie dann die Unterbrechung der automatischen Auszahlung, nachdem Sie sicher sind, dass sich die Regel wie erwartet auf die Konten auswirkt. ## See also - [3DS-Regelbeispiele](https://docs.stripe.com/radar/rules.md#request-3d-secure) - [Leitfaden zum kontinuierlichen Betrugsmanagement](https://stripe.com/guides/improve-fraud-management-with-radar-for-fraud-teams-and-stripe-data) - [Daten zu angefochtenen Zahlungen und Betrug abfragen](https://docs.stripe.com/stripe-data/query-disputes-and-fraud-data.md) - [Regelverzeichnis](https://docs.stripe.com/radar/rules/reference.md) - [Unterstützte Attribute](https://docs.stripe.com/radar/rules/supported-attributes.md)