欺诈预防规则

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

Stripe Radar 提供内置规则，帮助所有 Stripe 用户检测和防范欺诈风险。

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

• 对支持 3DS 验证及新客户进行的所有付款**要求 3DS 验证**
• **允许**来自您的电话中心的 IP 地址的所有付款
• **阻止**来自您的国家或国家以外的银行卡的付款
• **审核**用预付卡支付的所有超过 1000 美元的付款

内置规则

默认所有 Radar 用户都可以使用以下规则。

机器学习风险检查

Stripe Radar 和 Radar 风控团队版会基于我们的机器学习模型的判断提供一套默认规则，具体是：

Block if :risk_level: = 'highest'

对于欺诈风险高的付款，该规则会予以阻止，不予处理。对于 Radar 或 Radar 风控团队版用户，该规则默认是启用的。

Review if :risk_level: = 'elevated'

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

传统银行卡检查

即使 CVC 或地址 (AVS) 检查失败，付款仍然可以成功，因为发卡行在决定是否批准或拒绝付款时会考虑许多信号。某些情况下，即使 CVC 或邮编验证检查失败，发卡行仍然可以批准他们认为合法的付款。

Stripe 已将规则内置，因此即使在发卡行批准了付款的情况下，您仍可将其阻止。您可以随时在 Stripe 管理平台启用或禁用这些规则。

这些规则也适用于向某个客户绑定卡时的银行卡验证流程。如果您是同时创建银行卡和客户，则 CVC 或邮编验证失败会阻止成功创建客户记录。默认情况下，可能未为您的账户启用该规则。您可以随时在 Stripe 管理平台启用或禁用它。

Block if CVC verification fails

如果启用了该规则，Radar 将阻止未通过发卡行银行卡安全码 (CVC) 验证检查的付款。如果客户没有提供 CVC 号码，例如，因其使用的是电子钱包，或者客户的发卡行不支持其验证，则该规则不阻止付款。

Block if postal code verification fails

如果启用该规则，则在付款未通过发卡行的邮编验证检查时，Radar 将阻止付款。如果客户未提供邮编，或其发卡行不支持其验证，则该规则不阻止付款。您的账户可能未默认启用该规则。您可以随时在 Stripe 管理平台启用或禁用它。

内置请求 3DS 验证的规则

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

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

Stripe 提供三种默认禁用的规则，您可以启用它们，在使用 Radar 时用 Payment Intents 或 Setup Intents 动态要求 3DS 验证。

1. Request 3D Secure if 3D Secure is required for card
   • 默认情况下禁用。如果银行卡曾经要求 3DS 验证，则启用该规则会提示客户进行 3DS 验证。
   • Stripe 自动处理表示发卡行要求 3DS 验证的软拒付代码。此外，我们还会在必要时触发 3DS 验证，遵守 PSD2 规定的强客户认证等法规。
2. Request 3D Secure if 3D Secure is supported for card
   • 默认情况下禁用，但与之前的规则类似。只要客户的卡支持，启用该规则就会提示客户进行 3DS 验证。
   • 如果您想将能够获得责任转移的付款数量达到最多，请使用此规则，不要使用之前的规则。请注意，此额外的要求可能会降低转化率。
3. Request 3D Secure if 3D Secure is recommended for card
   • 默认情况下是禁用的。当 Stripe 认为进行 3DS 验证对转化率影响极小时，启用此规则会提示客户进行 3DS 验证。
   • 如果您想最大化具有责任转移的付款的数量，请启用此选项。

由于 3DS 验证要求您的客户进行额外一层身份验证，因此不加选择地使用 3DS 验证可能会降低转化率。Stripe 建议您仅在需要通过 3DS 验证从支持的卡中付款时，才启用默认的“要求 3DS 验证”规则。

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

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

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

自定义 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 为欺诈团队编写自定义规则。

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

• 无论您是否认为某些功能或用户行为更有风险（例如，使用一次性电子邮件）。
• 无论您是否希望基于付款金额或可感知的风险级别实施规则（例如，如果付款超过 500 美元，则自动审核，如果付款低于 5 美元，则自动允许）。
• 无论您现有的争议性付款和退款的付款是否有任何相同的模式（例如，相似的金额、卡类型或国家）。
• 无论您是否有想要迁移到 Stripe 的现有规则——Stripe 的机器学习模型可能已经涵盖了其中的许多规则，因此在自定义它们之前，您可以看看我们的系统是否适合您的业务。

如何创建有效的规则

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

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

• 规则只适用于未来的付款，不适用于已经处理的任何付款。
• 仅在使用 Stripe Checkout、Payment Intents 或 Setup Intents 时才要求 3DS 验证规则，并在应用审核、阻止和允许规则之前先对其进行评估。
• 实施任何阻止规则来阻止符合其标准的所有付款之前，应考虑您是否希望先审核这些付款。
• 最低限度地实现允许规则，因为它们会覆盖 Stripe 的默认规则以及匹配相同条件的任何其他自定义规则。
• 每个账户可创建的各类型规则最多为 200 个。

构建规则

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

如何添加新规则：

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

• 允许的付款——您的规则允许的总付款笔数。
• 交易额，允许的付款——与您的规则允许的付款有关的总金额，用您的本地货币表示。
• 风险评分 — Stripe 的机器学习模型为您的规则允许的一批付款所分配的相应风险结果。
• 来自覆盖的争议——允许的付款中被提出争议的总笔数。
• 交易额，来自覆盖的争议——与来自允许的付款的争议有关的总金额，用您的本地货币表示。

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

阻止规则

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

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

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

• 风险评分 — Stripe 的机器学习模型为您的规则允许的一批付款所分配的相应风险结果。
• 估计的误报率——被您的阻止规则集中阻止或被个别规则阻止的非欺诈性付款的估计百分比。（这些估计值是利用相应的机器学习风险评分得来的，其计算依据的是我们基于整个 Stripe 网络的实验。）
• 估计阻止的欺诈性付款 — 您的阻止规则阻止的欺诈性付款的估计数量。Stripe 使用通过分析 Stripe 网络中的数百万笔交易计算出的机器学习风险得分，预测 Stripe 有可能被争议或因欺诈而被拒绝的付款，并估计您的规则成功阻止了其中的哪些付款。

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

审核规则

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

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

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

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

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

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

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

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

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

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

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