Stripe 的默认规则利用机器学习来预测和阻止大量的欺诈性付款。对于需要更多控制能力来管理审核、允许或阻止哪些付款的商家，规则是定制您的欺诈保护的强大工具。

本指南涵盖了与 Radar 规则相关的各种主题，包括您可以使用的 100 多种 Radar 规则，以及关于回溯测试、规则编写等方面的最佳做法。

让我们开始吧。

规则顺序和等级的重要性

规则在您的 Radar 页面中的排列顺序非常重要。根据您创建的规则评估每笔付款，并按以下顺序执行：

1. 请求 3DS 验证：该规则与 Payment Intents API 或 Checkout 一起使用时会请求 3DS 验证。即使匹配这个规则，仍会评估允许、阻止和审核规则。
   
2. 允许： 这些规则允许付款被处理。应小心实施允许规则，因为它们会覆盖除 3DS 验证规则之外的其他所有规则，包括 Stripe 的机器学习模型，使用时应最为谨慎。只有处理金额超过 100,000 美元的商家才能编写允许规则。
   
3. 阻止： 这些规则会阻止付款并将其拒绝。如果付款被拒绝，则不会根据任何审核规则进行评估。
   
4. 审核：这些付款仍在处理中，客户已被扣款，但这些付款已被标记，如果愿意，可以重新查看。
   

为了将此付诸实践，我们来看看下面的规则示例。低于 10 美元的所有付款都会被处理。这是因为第一个规则会允许付款通过，因此不再评估其之后的规则。同样，根据这些规则，在美国境内进行的具有正常风险的 1500 美元的付款也会被允许，尽管该规则禁止超过 1000 美元的付款。这是因为列表中的第二条规则，即允许来自美国的风险水平正常的付款。触发了某个特定规则时，不再评估其之后的规则。

• 允许低于$10的付款

• 允许美国境内风险等级normal的付款

• 阻止风险等级high的付款

• 阻止超过greater than $1,000的付款

• 审核用outside the US的卡进行付款

规则语言备忘单

规则类似于 SQL，根据您用来创建规则的数据类型，可以使用不同的运算符。这是一张备忘单。

如果想明确检查某个属性或元数据属性是否存在，那么请勿使用 != 运算符，而应使用 is_missing 函数。为该函数提供可能缺少的属性或元数据属性。例如，可以书写一个规则来匹配您不能访问客户邮件地址的所有付款：

• Review if is_missing(:email_domain:)
  

或者，可以编写一个规则来匹配“不”缺少客户的电子邮件地址的所有付款：

• Review if !(is_missing(:email_domain:))
  

使用自然语言编写规则

如果您想更轻松地编写规则，或者不确定使用哪些属性来解决特定的欺诈场景，AI 驱动的 Radar 助手会将您的自然语言提示转换为 Rdar 语法中的规则。您还可以直接从 Radar 助手对规则进行回溯测试，这样就可以在实施规则之前查看它的历史表现。

常用 Radar 规则

下方为基于不同目标的常用 Radar 规则的非详尽列表。

有助于防止银行卡测试或信用卡套现的规则

有助于防止已知风险 SKU 欺诈的规则

该规则要求提供元数据或传递 SKU 信息作为收款描述。这些付款仍在处理中，客户已被扣款，但它们已被标记，以便您可以再次查看。

有助于防止胡乱试用预付卡的规则

分析您的欺诈行为以指导规则的创建

欺诈审核

为了制定最有效的规则，您必须深入了解您账户上的欺诈活动。描述当前不同类型的欺诈手段非常重要。需思考的一些问题：

• 账户是否使用新的电子邮件地址和持卡人姓名注册并立即进行欺诈性购买？

• 欺诈者是否访问过期账户并以异常高的金额进行购买？

• 欺诈是否倾向于特定的卡组织或发卡国家？

• 是否有高速率欺诈发生，即在短时间内通过同一卡、电子邮件地址或 IP 地址进行多次尝试？

仔细回顾上面截图中的高速率欺诈，利用 authorized_charges_per_card_number_hourly 或 authorized_charges_per_ip_address_hourly 的规则可能会解决这一欺诈方式。

更好理解欺诈的推动因素

欺诈洞察可帮助您快速识别和解决欺诈原因，而无需手动分析交易数据。管理平台中的洞察选项卡显示与欺诈交易相关的主要属性。在这里，您可以添加一个规则，直接从“洞察”选项卡中处理该属性。

创建规则时的三类属性

第 1 类

授权后属性：任何人都可使用这些属性。使用这些属性时，需要在授权后属性前后使用冒号，如:cvc_check:。

以下是如何使用授权后属性的示例：

• Block if :address_line1_check: != 'pass' 有了这条规则后，如果没有通过发卡行的检查，无法将所提供的账单地址的第一行与持卡人档案中的信息进行匹配，那么任何收款都将被阻止。这意味着，如果这项检查“不可用”，如果该数据“未经发卡行检查”，或者如果发卡行“not_provided”，则付款将被阻止。
  

第 2 类

标准属性：任何人都可使用这些属性。您需要在标准属性前后使用冒号，例如 :card_bin: 我们将标准属性分为四类：

• 基于频率的属性——有助于防止银行卡测试或信用卡套现
  
• 基于银行卡详情的属性
  
• 基于付款详情的属性
  
• 基于客户详情的属性
  

一些属性需要字符串形式的值，而另一些属性需要数字形式的值。我们为每个属性提供了一个示例来阐明这一点。如果属性需要像 :card_bin: 这样的字符串，那么在示例中您会看到这个数字加上了 ‘ ’。例如，:card_bin: = ‘424242’，但它要求一个号码，不会有 ‘ ’ like :amount_in_usd: > 250。

基于频率的属性

基于频率的属性有四类，在防止盗卡欺诈、银行卡测试和信用卡套现方面特别有用。

1.授权：基于发卡行的授权
2.收款：基于收款
3.拒付：基于发卡行的拒付
4.阻止：基于 Radar 机器学习执行的阻止操作

还有基于收款结果的属性，包括授权（基于发卡行的成功授权）、收款（基于收款尝试）、拒付（基于发卡行的拒付）、争议（之前的交易被以欺诈之名提出争议）和阻止（基于 Radar 机器学习执行的阻止操作）。结果与客户详情（电子邮件、IP 地址、姓名或客户 ID）结合在一起构成一个属性。

此外，您可以将客户详情（电子邮件、姓名）的频率与交易中使用的卡或 IP 地址结合起来。换句话说，频率规则有两种类型：

1.基于收款结果（例如，authorized_charges_per_email_hourly, blocked_charges_per_email_hourly）。其中，结果为成功授权，收款尝试、拒绝、争议、阻止
2.基于客户信息与卡或 IP 之间的联系（例如，name_count_for_card_weekly, email_count_for_ip_hourly）

频率规则不包括您当前正在处理的付款。例如，authorized_charges_per_email_hourly 表示前一小时内对某个电子邮件地址成功收款的次数。因此，对于某个邮件地址在具体某一小时内的第一次收款尝试，authorized_charges_per_email_hourly 的值为 0。如果第一次成功，那么同一小时内对这个邮件地址的第二次收款尝试，其值为 1，以此类推。

基于银行卡详情的属性

基于付款详情的属性

基于客户详情的属性

以下是如何标准属性的方法示例：

• Block if :card_country: IN ('CA', 'DE', 'AE')
  

有了这项规则，在加拿大、德国或阿拉伯联合酋长国发行的信用卡的任何收款都将被阻止。

第 3 类

元数据属性：这些属性将取决于您发送到 Stripe 的元数据。对于这些属性，您需要在标准属性前后使用双冒号，如 ::Customer Age::。元数据属性可以作为字符串或数字来操作。用作字串时，元数据属性要区分大小写。

元数据可以用来创建非常强大的规则，比如根据购买订单的 SKU 将收款放入人工审核，或者减小回头客的支付阻力。要了解如何传递更多元数据，请阅读本指南。

元数据属性以下列结构书写：

• ::[metadata attribute name]:: [operator] [metadata_value]
  

假设我们的一些付款具有元数据字段中存储的以下键值数据：

您可以编写一个规则，将匹配以下标准的付款放入审核。

• Review if ::Customer Age:: < 30
  

还可以将元数据属性与本文档中提及的其他支持属性结合使用来编写规则。例如，可编写一个规则，仅当 Item ID 匹配 5A381D 且付款金额大于 1,000 美元才将付款放入审核。

• Review if ::Item ID:: = '5A381D' and :amount_in_usd: > 1000
  

元数据属性还支持 IN 运算符来匹配多个数值。例如，可编写一个规则，在 Category ID 为“杂货店”、“电子产品”或“服饰”时将付款放入审核。

• Review if ::Category ID:: IN ('groceries', 'electronics', 'clothing')
  

可以将 INCLUDES 运算符与元数据属性和其他字符串属性的规则结合使用来匹配子串。例如，可编写一个规则，在 Item ID 中包含字串 A381 时将付款放入审核。这将匹配到 “A381”、“5A381D”、“A381D”、“5A381”，等。

• Review if ::Item ID:: INCLUDES 'A381'
  

还可以访问客户和收款账户对象上的元数据（如果它们被用于特定的付款）。这些属性以下列结构书写：

• ::[customer|destination]:[metadata attribute name]::[operator][metadata_value]:
  

假设您有一个具有以下元数据的客户：

如果客户的 Trusted 元数据字段为 true，则您可以写一个规则始终允许付款。

• Allow if ::customer:Trusted:: = 'true'
  

或者，如果您的目的地有下列元数据时：

如果目的地的Category元数据字段为new，则您可以写一个规则将付款放入审核。

• Review if ::destination:Category:: = 'new'
  

使用您的规则中保存的列表（例如，允许列表，阻止列表）

您可以通过以前创建的列表（例如，允许列表或阻止列表）在规则中引用一组值。如果您试图阻止一系列电子邮件地址，应创建一个阻止列表，而非为想要阻止的每个邮件地址创建多个规则。

在规则中引用的所有列表的别名都应以 @ 开头。要构建一个引用列表的规则，应遵循以下结构：

• {action} [attribute] in [list]
  

例如，假设您想阻止一个银行卡国家列表。可以用OR子句来编写规则：

• Block if :card_country: = 'CA' OR :card_country: = 'DE' OR :card_country: = 'AE'
  

您也可以用内联列表来编写规则：

• Block if :card_country: IN ('CA', 'DE', 'AE')
  

也可以创建一个您想要阻止的银行卡国家列表，命名为 card_countries_to_block。然后将您选择的国家添加到该列表并在规则中引用：

• Block if :card_country: in @card_countries_to_block
  

使用列表的规则不仅更简洁，而且更容易编辑和添加大量项目。

通过多个条件编写复杂规则

可以用运算符AND、OR和NOT组合基本条件来构建复杂的条件。还可以使用它们的符号等值：&&、||以及!。与 C 语言、Python 和 SQL 等编程语言类似，Stripe 支持标准运算符 优先级 （运算符的顺序）。例如，复杂条件：

• {condition_X} OR NOT {condition_Y} AND {condition_Z}
  

解析为：

• {condition_X} OR ((NOT {condition_Y}) AND {condition_Z})
  

使用括号也支持复杂条件中的子条件分组。例如，可以修改前面的示例以显式更改子谓词的评估顺序：

• ({condition_X} OR (NOT {condition_Y})) AND {condition_Z}

• {condition_X} OR NOT ({condition_Y} AND {condition_Z})

通过在不同位置使用括号，这些复杂条件中的每一个都会导致不同的结果。

is_missing 函数也可以用于 OR 或 AND 连词中：

• Review if is_missing(:email_domain:) OR :email_domain: IN ('yopmail.net', 'yandex.ru')
  

或者也可以在不缺少的情况使用 is_missing 函数。在这种情况下，在“不”缺少 :ip_country:并且 IP 来自 US 或 PR 时，它将阻止付款。

• Block if !(is_missing(:ip_country:))AND :ip_country: IN ('US', 'PR')
  

回溯测试规则

作为规则分析的一般原则，在防止欺诈和阻止良好交易或误报之间需要做出取舍。回溯测试有助于确定符合您风险偏好的规则，或者在预防争议和增加误报之间取得适当平衡。要估计规则的影响，您可以通过 Radar 管理平台使用过去六个月的交易数据对组合进行回溯测试，并进行更有针对性的分析，以了解规则在最近实施时的表现情况。

管理平台中的回溯测试

根据您测试的规则类型，欺诈性付款和其他成功付款的定义有所不同：

阻止规则

• 被提出争议、收到早期欺诈预警或因欺诈而退款：因欺诈而被提出争议或退款的成功收款或因欺诈而被提出争议或退款的审核中的成功收款

• 其他成功的付款：未因欺诈而被提出争议或退款的成功收款或被放入审核且未因欺诈而被提出争议或退款的成功收款

• 失败的付款尝试：被发卡行拒绝或被 Radar 阻止

审核规则

• 因欺诈而被提出争议、收到早期欺诈预警或被退款：因欺诈而被提出争议或退款的成功收款

• 其他成功的付款：未因欺诈而被提出争议或退款的成功收款

• 失败或已被放入审核：被发卡行拒绝、被 Radar 阻止，或被放入审核的成功收款（无论争议或退款状态如何）

允许规则

• 被 Stripe 或您的自定义规则阻止：被 Radar 阻止的收款

• 被提出争议、收到早期欺诈预警或因欺诈而退款：因欺诈而被提出争议或退款的成功收款或因欺诈而被提出争议或退款的审核中的成功收款

• 其他成功或银行拒绝的付款：被发卡行拒绝，未被提出争议的成功收款或因欺诈而被退款或被放入审核且未因欺诈而被提出争议或退款的成功收款

执行自定义回溯测试分析

Radar 管理平台中的回溯测试功能专注于过去六个月的交易，包括争议、早期欺诈预警和因欺诈而被退款的收款。

例如，如果您在 Visa 欺诈监控计划中面临被识别的风险（专门关注早期欺诈预警），或者您注意到最近来自特定 IP 国家或钱包类型的欺诈激增，那么您可能希望执行更有针对性的分析。为此，您可以在 Sigma 中构建 SQL 查询，或者在管理平台中导出和分析付款数据报告。自定义回测允许时间范围的灵活性（超过六个月）和更有针对性的分析（例如，您可以只关注争议或早期欺诈预警）。如果您假设发现最近更高价值上的欺诈量激增，并且交易的高风险评分带来了监控计划风险，那么可通过下面的查询示例对大于 100 美元的交易的 Visa 早期欺诈预警 (EFWs) 进行回溯测试：

Using fields and tables available in Sigma

with base as (
    select
        c.id,
        c.amount,
        c.captured,
        e.created as efw_created
    from charges c
    left join early_fraud_warnings on e.charge_id = c._id
    where card_brand = ‘visa’
    and (c.amount / 100) >= 100
    and c.captured >= dateadd(‘day’, -180, current_date)
)

select 
    count(case when efw_created >= dateadd(‘day’, -60, current_date) then id else null end) as fraud_charge_count,

sum(case when efw_created >= dateadd(‘day’, -60, current_date) then amount else null end) as fraud_amount,

count(case when efw_created is null and captured between dateadd(‘day’, -120, current_date) and dateadd(‘day’, -60, current_date) then id else null end) as false_positive_charge_count,

count(case when efw_created is null and captured between dateadd(‘day’, -120, current_date) and dateadd(‘day’, -60, current_date) then amount else null end) as false_positive_amount

from base

根据早期欺诈预警创建日期对过去 60 天进行回溯测试可以锁定最近的欺诈行为，而对过去 60-120 天的非欺诈销售进行回测，则可以让欺诈行为有足够的时间完全暴露出来或变得更明显。

常见欺诈模式

大多数欺诈者都遵循一种常见的欺诈模式。首先，他们验证被盗的支付信息（例如，银行卡）。一旦验证这些凭证有效，他们就会利用这些凭证提取价值，形式包括用于个人使用或转售的实物商品（奢侈品或电子产品）、用于个人使用或转售的服务（食品配送服务），或用于进一步实施欺诈的服务和产品（例如，网络托管服务、消息群发服务等）。

请继续阅读，了解一些最常见的欺诈手段的更多详情，以及推荐的使用 Radar 规则来减少欺诈的方法。

测试

银行卡测试是指欺诈者使用脚本或手动流程来测试被盗的原始卡号是否仍然有效。这个阶段的欺诈并不是为了获取实物商品或服务，而是为了验证这些卡片是否有效。这些交易通常是金额较低的交易或授权。测试通常在短时间内迅速连续进行，并且具有高频率。可能有帮助的属性是分组和速度特征，例如：

• total_charges_per_customer

• card_count_for_email

• card_count_for_ip_address

• total_charges_per_ip

欺诈者通常会通过创建虚假电子邮件和使用不同的电子邮件地址来规避检测。更高级的欺诈者会隐藏 IP 地址，甚至使用多个设备来提供独特的设备数据。在这一点上，了解正常的和典型的客户行为变得非常重要。电子邮件域名和 IP 国家等特征，以及其他更广泛的类别，可以帮助识别高风险交易。许多实施欺诈的客户会使用知名电子邮件提供商的流行域名，例如 gmail.com。您可能会看到像 gmail.comms 或 gmail.comms 这样的域名，它们试图掩盖欺诈者的身份。银行卡所在国家和 IP 所在国家也可用于帮助细分客户，并确保交易来自您的用户群的典型地区。来自这些地区以外的交易可能需要进行审核或将其阻止。

防止这种测试行为的一个最终功能是引入 CAPTCHA。

在 Stripe Checkout 中，当我们的机器学习检测到银行卡测试攻击时，会自动提供 CAPTCHA 验证。为了减少银行卡测试，Stripe 使用了一系列自动化和手动控制措施，包括速率限制器、警报和持续审查，同时训练银行卡测试模型以自动检测攻击。这些模型只有在银行卡测试攻击进行时才会提供验证，因此真实用户几乎不会看到 CAPTCHA，只是机器人看到。这将使用 Stripe Checkout 的商家的银行卡测试减少了高达 80%，对转化的影响，微乎其微。

注意，您还可以编写诸如“如果一个 IP 地址被拒绝超过 3 次，则将其阻止”这样的自定义规则来减少银行卡测试攻击。

价值提取

被盗信用卡（新行为）

在这种欺诈方式中，欺诈者在其个人设备或用于实施欺诈的设备上使用经过验证的被盗信用卡。

这种方式通常通过脚本化的大规模攻击或较小规模的更有针对性的欺诈团伙和小组来实施。不管是哪种方式，使用衡量 Stripe 上账户的新旧度的规则属性（例如，hours_since_email_first_seen_on_stripe），结合 risk_score 和其他特征，可以防止这些全新的持卡人进入。此外，对 IP、电子邮件和卡片的速率限制可以进一步保护商家，使其免受那些试图尽快利用被盗凭证获利的欺诈者的大规模攻击。

被盗信用卡（伪装行为）

在这种欺诈方式中，欺诈者在其个人设备或用于实施欺诈的设备上使用经过验证的被盗信用卡，或者欺诈者已经攻破了一个订阅账户并获得了该账户中存储的信用卡信息。

欺诈者会尽力掩盖其存在，具体方式有：

• 使用与之前完成的交易相同的名称

• 使用与之前完成的交易相同的账单地址

• 使用 VPN 试图使其看起来像是持卡人本人。他们可能通过 VPN 进入同一个城市，有时甚至是同一个街区

• 只更改小细节，如电子邮件地址或电话号码

• 对于实物商品，更改以前交易的发货地址，账单和发货地址之间的距离可能会有存在较大差异。这是一个松散的信号

上面描述的伪装行为使得很难解析出谁是真正进行交易的人——持卡人本人还是盗取了账户的欺诈者。这通常意味着这种欺诈在更长时间内不会被商家和持卡人本人发觉。

这种情况的应对策略是相同的：欺诈者将试图从盗来的凭证中提取尽可能多的价值。使用速率限制功能以及 riskscore, cvccheck 失败或邮编检查失败的规则有助于防止这种行为。

其他最佳做法

以下是帮助您优化在 Radar 中编写规则时的其他最佳做法。

使用 Stripe.js 的重要性

• 将 stripe.js 包含在完整的支付路径中，以最大化欺诈信号
  
• 为了在不影响页面加载时间的情况下充分利用 Radar，请在非支付页面上异步加载 stripe.js
  
• 最容易放在 Google Analytics 脚本标签旁边
  
• 完整的 stripe.js 包大小为 29.6kb 的 gzipped
  
  • 未来的 state: radar.js 将可以从 stripe.js 中独立出来
    

结论

规则可以是一个非常强大的工具，帮助您定制您的欺诈保护。通过实施独特的逻辑，并参考本指南中概述的一些最佳做法，您可以在 Radar 中创建一个特定于您的业务需求的防欺诈设置。

如果您想了解更多有关 Radar 风控团队版的信息，请参见此处。

如果您已经是 Radar 风控团队版用户，请查看管理平台中的规则页面开始编写规则。

其他注意事项

平台对 Radar 的使用

您是使用 Stripe Connect 的平台吗？如果是，那么您创建的任何规则仅适用于在平台账户上创建的付款（在 Connect 术语中，这些是指定向或代为收款)。
在 Connect 子账户上直接创建的付款需遵循该账户的规则。

Terminal 的 Radar

Radar 不对 Terminal 收款进行筛查。这意味着，如果您使用 Terminal，那么可以根据 IP 频率编写规则，而不必担心阻止您的线下付款。