欺诈预防规则

欺诈预防规则允许您在付款满足特定标准时采取行动。

Stripe Radar 提供内置规则，帮助检测和防范所有 Stripe 用户的银行卡、ACH 和 SEPA 直接借记付款的欺诈风险。

Radar 风控团队版和 Radar for Platforms用户可使用管理平台，根据商家特有的业务逻辑创建自定义规则。例如，您可以：

• 对支持 3DS 验证及新客户进行的所有付款**要求 3DS 验证**
• **允许**来自您的电话中心的 IP 地址的所有付款
• **阻止**来自您的国家或国家以外的银行卡的付款
• **审核**用预付卡支付的所有超过 1000 美元的付款
• 对争议率高的账户进行审核并自动暂停提现（使用 Radar for Platforms）

内置规则

默认情况下，以下规则可供所有 Radar 用户使用，除非被标记为自定义规则，因为自定义规则仅适用于 Radar 风控团队版或 Radar for Platforms 用户。

AI risk checks

All Radar offerings provide a set of default rules based on the judgments of our AI models, which are:

Block if :risk_level: = 'highest'

对于欺诈风险高的付款，该规则会予以阻止，不予处理。默认情况下，所有 Radar 用户都会启用此规则。

Review if :risk_level: = 'elevated'

Stripe 的 Radar 风控团队版和 Radar for Platforms 的默认行为是对我们怀疑欺诈风险较高的付款进行审核。

Radar for Platforms has additional account-level AI models which are incorporated through two default rules:

Review if :acccount_risk_level: = 'highest'

Review if :acccount_risk_level: = 'elevated'

我们利用 KYC 信息、交易、地理信号和行为模式来计算账户级风险。

传统银行卡检查

即使 CVC 或地址 (AVS) 检查失败，付款仍然可以成功，因为发卡行在决定授权付款时会评估大量信号。发卡行可能仍会认为未通过 CVC 或邮政编码验证的付款是合法的，因此会批准该付款。

您可以启用 Radar 的内置规则来阻止发卡行批准的某些付款。启用后，如果同时创建卡和客户，这些规则还会影响向客户关联卡和创建客户。

内置请求 3DS 验证的规则

使用 3DS 验证会提示客户完成额外的身份验证步骤，然后才能完成购买流程。如果对付款进行 3DS 验证，则与该付款的任何欺诈性争议的责任通常会从卖方转移到发卡行。这意味着，在大多数情况下，卖家不需要负责经过 3DS 验证的付款的欺诈成本。

Stripe 自动处理表示发卡行要求 3DS 验证的软拒付代码。我们还会在必要时触发 3DS 验证，遵守 PSD2 规定的强客户认证 (SCA) 等法规。在必要的情况下，禁用 Radar 不会阻止 3DS 被触发。

当在支付意向或设置意向中使用 Radar 时，Stripe 支持三个旧版内置规则来请求 3DS：

1. 请求 3DS 验证 如果 卡片推荐使用 3DS 验证 已弃用
   • Radar 的身份验证欺诈预防控制已取代此规则。
2. 请求 3DS 验证 如果 卡片支持 3DS 验证 已弃用
   • Radar 的身份验证欺诈预防控制已取代此规则。
   • 启用此规则会提示客户进行 3DS 认证，只要他们的卡片支持该功能。
3. 如果要求对某卡进行 3DS 验证Deprecated，则要求 3DS 验证。
   • 如果某张卡曾经要求过 3DS 验证，那么启用此规则会提示客户进行 3DS 验证。
   • 无论此规则如何，Stripe 都会自动触发 3DS 验证：
     • 如果软拒绝代码指示发卡行需要 3DS 验证。
     • 遵守 PSD2 的强客户认证要求等法规。

由于 3DS 验证要求您的客户进行额外一层身份验证，因此不加选择地使用 3DS 验证可能会降低转化率。

要求进行 3DS 验证并不一定意味着发卡行实际上就会执行 3DS 验证。有关可能结果的更多详情，请参考 3DS 验证文档。

自定义规则来请求 3DS 验证并对特定结果采取行动

尝试 3DS 验证后，如果您有 Radar 风控团队版 或 Radar for Platforms，则可以在允许、阻止或查看规则中评估结果。

自定义 Radar 规则的最重要属性是：

• is_3d_secure 在银行卡受支持、发卡行尝试了 3DS 验证并且用户未通过验证的情况下，为真。我们通常建议在块规则中使用它。
• is_3d_secure_authenticated 在发卡行尝试了 3DS 验证并且用户成功通过整个验证过程的情况下，为真。在阻止规则中使用该属性将排除合法的交易，这些交易可能具有 SCA 豁免资格，或者不属于明显的失败或成功的身份验证，例如处理错误。
• 在 Stripe 期望责任转移规则涵盖这笔付款的情况下，has_liability_shift 为 true（真）。但在某些地区，可能不会始终与 3DS 验证相同，如 Apple Pay。

对于自定义规则，我们建议根据您的风险偏好，将要求 3DS 验证和阻止规则保持一致。但是，不要阻止不支持 3DS 验证的交易，如一些数字钱包。

以下是一些用例的示例，可据此了解实现方式：

基于 Radar 风险等级要求 3DS 验证

您希望用 Radar 基于 Radar 风险等级及高于某一值的所有收款要求 3DS 验证。

这种情况下，如果没有阻止规则，不会阻止那些不支持 3DS 验证的卡或数字钱包。验证失败的 3DS 验证尝试不会继续收取授权费。

始终基于 Radar 风险等级要求 3DS 验证

您希望用 Radar 基于升高或高的 Radar 风险等级及高于某一值的所有收款要求 3DS 验证。如果卡不支持 3DS 验证，则您不想接受付款。

如果支持 3DS 验证，则仅接受完全通过 3DS 验证的交易

您在强客户认证 (SCA) 等情况下在必要时依赖 Stripe 触发 3DS 验证，但不想接受极端情况，例如处理错误。

基于元数据要求 3DS 验证

您希望用 Radar 对所有具有自定义元数据属性的付款要求 3DS 验证。

这种情况下，如果没有阻止规则，不会阻止那些不支持 3DS 验证的卡或数字钱包。验证失败的 3DS 验证尝试不会继续收取授权费。

始终要求基于元数据的 3DS 验证

您希望用 Radar 对所有具有自定义元数据属性的付款要求 3DS 验证，并阻止不支持该属性的卡。

对所有新卡要求 3DS 验证，并且在不支持 3DS 验证时进行审核

您希望用 Radar 对所有新卡要求 3DS 验证，并手动检查不支持 3DS 验证的卡的收款。

这种情况下，如果没有阻止规则，不会阻止那些不支持 3DS 验证的卡或数字钱包。验证失败的 3DS 验证尝试不会继续收取授权费。

对某些发卡行国家，始终要求 3DS 验证

您希望用 Radar 对来自自定义列表上的国家/地区的发卡行的所有收款要求 3DS 验证，并阻止不支持 3DS 验证的银行卡。

始终基于 Radar 风险级别要求 3DS 验证，并审核极端情况

您希望用 Radar 对所有收款要求基于 Radar 风险级别的 3DS 验证，并阻止不支持 3DS 验证的卡，但手动审核极端情况。

何时创建规则

Stripe 的默认规则可以阻止大量欺诈性付款。需要更好地控制要审查、允许或阻止哪些付款的商家可以通过 Radar 为欺诈团队编写自定义规则。平台可以通过 Radar for Platforms 编写自定义规则，以校准其平台和 Connect 子账户的支付风险，并应用特定于账户的规则。

在决定是否启用自定义规则时，请考虑以下因素：

• 无论您是否认为某些功能或用户行为更有风险（例如，使用一次性电子邮件）。
• 是否要根据支付方式实施规则（例如，自动阻止超过特定风险评分的 SEPA 直接借记）。
• 无论您是否希望基于付款金额或可感知的风险级别实施规则（例如，如果付款超过 500 美元，则自动审核，如果付款低于 5 美元，则自动允许）。
• 无论您现有的争议性付款和退款的付款是否有任何相同的模式（例如，相似的金额、卡类型或国家）。
• Whether you have existing rules you want to migrate to Stripe—many of these rules might already be covered by Stripe’s AI models, and you can check how our system performs for your business before customizing it.
• 平台：您是想自动提请审核，还是选择性地暂停账户提现。

如何创建有效的规则

虽然这些规则可以帮助您自动化现有的工作流，但如果使用不当，也会对您的业务产生负面影响。例如，如果设置不当，规则可能会自动允许大量欺诈性付款，或者阻止大量合法的付款。

设置规则时，需注意以下几点：

• 默认情况下，规则适用于所有 Radar 支持的支付方式，除非您使用 payment_method_type 属性在规则谓词中定义特定的支付方式。
• 规则只适用于未来的付款，不适用于已经处理的任何付款。
• 仅在使用 Stripe Checkout、Payment Intents 或 Setup Intents 时才要求 3DS 验证规则，并在应用审核、阻止和允许规则之前先对其进行评估。
• 实施任何阻止规则来阻止所有付款或暂停符合其条件的账户的提现之前，请考虑您是希望先审核此类付款还是账户。
• 最低限度地实现允许规则，因为它们会覆盖 Stripe 的默认规则以及匹配相同条件的任何其他自定义规则。
• 您最多可以创建 200 条交易规则和 100 条账户规则。

构建交易规则

您可以从管理平台的 Radar 规则选项卡页面添加规则。

如何添加新规则：

1. 点击 + 添加规则。
2. 从子菜单中选择规则类型。
3. 在规则编辑器中，用语法 {action} if {attribute} {operator} {value} 构建一个规则，其中：
   • {action}: 满足规则标准时，Radar 的响应情况。此值是根据您选择的规则类型预先填充的。
   • {attribute}: 要评估的交易元素，例如金额或银行卡类型。以 : 开始输入内容，打开有效属性列表。您还可以通过加上双冒号来评估您的元数据，例如 ::product_sku::。
   • {operator}: 如何对比属性和值，例如 =、>、!= 等。
   • {value}: 要评估的属性的值。
4. 点击测试规则。
5. 如有必要，修改检测到的验证错误。
6. 在审核新规则页面，查看此规则对您近期的交易的表现情况，确认您是否要启用它。如果规则可能会影响来自多种支付方式的交易，请使用支付方式筛选器按支付方式（例如 ACH 或银行卡）查看规则效果。
7. 点击添加规则，开始将该规则应用到未来的所有交易。

使用 Radar 助手：

Stripe 的规则编辑器有一个内置的 LRM 助手，可根据自然语言提示构建 Radar 交易规则。

要使用 Radar 助手：

1. 在管理平台中的 Radar 规则选项卡页面，点击 + 添加规则。
2. 从子菜单中选择规则类型。
3. 在规则编辑器中，点击 Radar 助手。

手动规则编写

Radar 助手

1. 在消息字段，输入您请求的规则。您可以要求：
   • 审核银行卡和 IP 国家不同的付款。
   • 阻止超过 1000 美元的 Discover 付款。
   • 允许从 stripe.com 邮件地址付款。
2. 当助手返回其建议时，您可以输入额外指令来调整规则，也可以点击测试规则，根据您近期的交易记录查看该规则的执行情况。
3. 如果您对规则满意，点击添加规则，为未来的所有交易启用它。

**训练数据许可。**使用 Radar 助手，即表示您同意 Stripe 可以记录和使用您的聊天记录来训练和提升 Radar 助手的功能。如果您不希望将您的聊天记录用于此目的，请手动编写规则。

了解有关 Stripe AI 服务的更多信息。

审核规则

满足审核规则的标准时，Stripe 仍会正常处理付款。但我们会将其放入您的审核队列，以便您的团队可以更深入查看。设置过于宽泛的规则可能会导致过多的付款被放入审核队列，拖慢您的客户的速度并加重您的审核团队的负担。

Stripe 的规则测试界面会模拟过去 6 个月内的收款，确定实施该规则后，会有多少合法的、欺诈性的和被阻止的付款受到影响。在测试规则及检查过去 6 个月内的付款时，您应该确保：

• 付款总额低。审核这些付款不应该给您的团队造成负担。
• 人工审核员增加价值。人工审核员通常比自动化系统更准确地识别付款是否存在欺诈。
• 该规则导致成功的付款和退款或有争议付款混合在一起。这意味着对这些类型的付款进行额外检查有助于区分合法付款和欺诈性付款。

下例中的公司希望审核预付信用卡付款，看看如何提升他们创建的审核规则。

阻止规则

您可以用阻止规则来阻止您确定是欺诈性的付款，也可以基于您现有的任何限制（例如，阻止预付卡付款）。如果不确定如何应用阻止规则，则建议使用审核规则来审核付款。在花了一些时间检查这些付款是否有可能属于误报后，您便可确认是否要创建阻止规则。

阻止规则只影响欺诈性付款和成功的付款，因为已经被阻止的付款不会受到影响。测试规则时，需确保：

• 尽可能减少误报。在测试过程中，Stripe 会识别与规则匹配的成功付款和有争议付款的数量。一个好的阻止规则会导致被阻止的欺诈性付款比合法付款多得多。
• 尽量减少不必要的规则。如果您的规则看起来效果很好，但已经被当前规则覆盖，则您可能不需要那个较新的规则。同样，如果测试期间的结果比较混杂，应考虑设置一个审核规则，从而可以收集有关这些类型付款的更多信息。

下例中的公司来自美国以外的欺诈付款特别多，我们看如何提升他们创建的阻止规则：

允许规则

允许规则会覆盖您的所有其他规则，因此请谨慎使用。很多公司可能不需要实施允许规则。如果您担心允许规则会允许少量的欺诈性付款通过，可以考虑进行调整，以进一步限制这些规则，然后再实施这些规则。

创建规则后，允许规则会立即应用到所有新付款。其中包括与之前阻止的付款类似的任何付款。测试规则时，需确保：

• 检查之前被阻止的本应被允许的付款数量。允许规则会覆盖所有其他规则及 Stripe 的风险评估。测试新的允许规则时，如果此规则有效，则显示的所有付款都是已经被允许的。这可能包括已被阻止或有争议的付款，这些付款将影响您未来的争议率。
• 继续阻止任何高风险的付款。为此，可向您的允许规则中添加以下内容：and :risk_level: != 'highest'
• 评估您的业务中合法交易的记录。您可以分析您自己的客户之间的关联，根据合法交易的记录来允许较高金额的交易。这有助于减少阻止在您这里有良好交易记录的客户的付款。为此，可以查看属性列表并查找包含关键词“customer”的属性。

下例中的公司通常（但并不总是）遇到的来自英国客户的付款都是好的，我们看一下如何改善他们的允许规则：

维护您的规则

随着您的业务不断增长，您将希望确保您的规则能继续反映您希望与之开展业务的客户类型。以下是一些最佳做法，可以让您的规则符合您的业务需要。

定期监测规则，确保其始终有效

规则指标

欺诈模式是不断变化的，因为我们提供指标来显示这些规则的表现效果。这些指标依规则类型而不同，因为不同类型的规则执行不同的操作。

使用规则性能图表来理解您的 Radar 规则的行为。寻找与您的规则匹配的付款笔数的意外峰值或下降点，例如是否有某些允许规则让过多的付款通过，或是否有阻止规则阻止了过多的付款。这些峰值可能表明您收到的付款类型发生了变化，或者可能需要对规则本身进行更新。对规则进行的更新以图表上的三角形表示，可帮助您比较更改前后的影响。

彩色线条跟踪匹配 3DS 验证规则、允许规则、阻止规则和审核规则的付款笔数。这些图线上的三角形符号表示相应类型规则的更新。

您可以找到有关您的规则效率的信息，并查看每个规则对多少付款采取了行动。您还可以查看并下载已应用了规则的各笔付款的筛选列表。评估这些信息，帮助您决定是否需要更改任何规则或完全将之删除。

要查看其他命令，请点击溢出菜单 ()。额外命令包括：任意规则的禁用、启用、编辑或删除。

您还可以使用我们的报告产品、Sigma 和 Data Pipeline 来查询争议和欺诈数据，包括每单笔付款的规则决定和属性。

评估规则的有效性

您可以找到有关您的规则效果的信息，并查看每个规则影响了多少笔付款。您还可以查看并下载已应用了规则的各笔付款的筛选列表。检查下表中的问题示例，以帮助您决定是否需要对任何规则进行更改或将其完全删除。

请求 3DS 验证

对于请求 3DS 验证的规则，我们显示：

• 要求 3DS 验证——某个规则触发 3DS 验证请求的次数。

点击 3DS 规则，可查看以下指标：

允许规则

对于允许规则，Radar 风控团队版用户可以查看：

• 允许的付款——您的规则允许的总付款笔数。
• 交易额，允许的付款——与您的规则允许的付款有关的总金额，用您的本地货币表示。
• Risk score—The corresponding risk outcomes assigned by our AI models to the set of payments allowed by your rules.
• 来自覆盖的争议——允许的付款中被提出争议的总笔数。
• 交易额，来自覆盖的争议——与来自允许的付款的争议有关的总金额，用您的本地货币表示。

点击“允许”规则，可查看以下指标：

阻止规则

对于阻止规则，我们会显示：

• 阻止的付款——您的规则阻止的总付款笔数。
• 交易额，阻止的付款——与您的规则阻止的付款有关的总金额，用您的本地货币表示。

Radar 风控团队版还可以查看：

• Risk score—The corresponding risk outcomes assigned by Stripe’s AI models to the set of payments allowed by your rules.
• Est. false positive rate—The estimated percentage of non-fraudulent payments that were blocked for both your block rules as a set and by individual rules. (These estimates are made using the estimated false positive rates of the corresponding AI risk scores, which we calculate with experiments across the Stripe network.)
• Est. fraudulent payments prevented—The estimated number of fraudulent payments that your block rules prevented. Stripe uses AI risk scores, calculated by analyzing millions of transactions across the Stripe network, to predict payments with a high probability of being disputed or declined due to fraud and estimate which of those payments were successfully blocked by your rules.

点击“阻止”规则，可查看以下指标：

审核规则

对于审核规则，Radar 风控团队版用户可以查看：

• 付款已送至审核——被您的规则送入人工审核的付款的总笔数。
• 交易额，批准的审核——与已批准的付款有关的总金额，用您的本地货币表示。
• 退款率——被退款的审核的百分比。
• 来自已批准审核中的争议数——审核批准通过但最终又被提出争议的付款的总笔数。
• 交易额，来自已批准审核的争议——与来自已批准的付款的争议有关的总金额，用您的本地货币表示。

点击“审核”规则，可查看以下指标：

定期监控您的人工审核队列

如果您的审核队列变得太大而难以管理，请看看您是否有合适的规则。如果大多数审核最终都因欺诈而退款，可考虑一些额外的规则来阻止付款。同样，如果大多数付款都通过，可考虑让您的审核规则更有针对性一些。

分析您有争议的付款和退款

争议的背后涉及欺诈行为，因此采取防争议措施越多，争议率就越低。检查发生争议的付款是否具有任何相似的特征（例如，来自于相同地点或金额相似）。也可以通过在审核过程中查看已退款的付款来执行此类调查。如果发现某种趋势，则可以测试并创建适当的规则。如有任何付款看似具有欺诈性，则发放退款并将其作为欺诈进行报告，避免潜在的争议。

您还可以使用我们的报告产品、Sigma 和 Data Pipeline 来查询争议和欺诈数据。

您可通过管理平台或 API 回应收到的任何争议，我们的争议文档包含一些关于如何有效提交证据的建议。

预测可能会影响您的欺诈率的重大业务变化

如果您正在计划重大的产品发布或服务变更（例如，新的高价值产品或将服务扩展到新的国家/地区），则您可能想在一开始就监控这些付款。对于这些类型的更改，最好设置一些审核规则，以检查任何新的付款。审核这些付款并识别模式可以帮助您建立新的规则来保护您的业务免受欺诈。

规则支持多种支付方式 New

默认情况下，Radar 规则会筛选大多数用户的银行卡、ACH 和 SEPA 直接借记付款。对于所有 Stripe Radar 用户，我们都支持其所有这些支付方式的高风险阻止规则。对于 Radar 风控团队版或 Radar for Platforms 用户，我们还支持使用 :payment_method_type: 属性编写仅适用于特定支付方式的自定义规则，例如：Block if :payment_method_type: = 'us_bank_account'。详细了解受支持的属性。

构建账户规则

借助 Radar for Platforms，您还可以从管理平台中 Radar 页面的规则选项卡添加和管理账户规则。如何添加新规则：

1. 点击 + 添加规则。
2. 选择规则类型：“审核”或“提现暂停”（分别提请审核或暂停提现）。
3. 在规则编辑器中，用语法 {action} if {attribute} {operator} {value} 构建一个规则，其中：
   • {action}: 满足规则标准时，Radar 的响应情况。此值是根据您选择的规则类型预先填充的。
   • {attribute}：要评估的交易元素，例如金额或银行卡类型。先键入 : 以打开有效属性列表。
   • {operator}: 如何对比属性和值，例如 =、>、!= 等。
   • {value}: 要评估的属性的值。
4. 点击测试规则。
5. 如有必要，修改检测到的验证错误。
6. 在查看新规则页上，查看当前与此规则匹配的账户，以确认是否要启用它。
7. 点击激活规则，开始将此规则应用到所有现有账户和将来的账户。

与交易测试相比，测试账户级规则需要更长的时间，但我们建议进行测试，以避免无意中将账户提请审核或暂停自动提现功能。首先测试将账户提请审核的行为。然后，在您确信该规则会如预期影响账户后，测试暂停自动提现功能的情况。