Stripe 的默认规则利用机器学习算法，可预测和阻止大量的欺诈性付款。对于希望更深入控制付款审核、允许或阻止标准的商家而言，定制化的规则是增强欺诈保护的有效手段。

本指南详尽介绍了与 Radar 规则相关的内容，涵盖了 100 多种实用 Radar 规则，并提供关于回溯测试、规则编写等方面的最佳实践建议。

让我们直奔主题。

规则顺序和等级的重要性

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

1. 请求 3DS 验证：与 Payment Intents API 或 Checkout 结合使用时，此规则会请求 3DS 验证。即便触发此规则，系统仍将评估允许、阻止和审核规则。
   
2. 允许： 这类规则允许付款被处理。实施允许规则时应格外小心，因为它们会覆盖除 3DS 验证规则之外的其他所有规则使用时应最为谨慎。只有处理金额超过 100,000 美元的商家才能编写允许规则。
   
3. 阻止： 这类规则会阻止付款并将其拒绝。一旦付款因阻止规则被拒绝，就不会根据任何审核规则进行评估。
   
4. 审核：这些付款仍在处理中并已扣款。但此类付款已被标记为需审核，商家可按需进行复审。
   

为了更清晰地说明实际操作，我们可以通过以下规则示例来探讨具体的应用场景。由于第一条规则的存在，所有低于 10 美元的支付都将被自动允许。一旦满足这个条件，之后的规则将不再适用。同理，根据这些规则，在美国境内且风险等级为 normal（正常）的 1,500 美元付款也将被允许。虽然第四条规则禁止超过 1,000 美元的付款，但由于其排序靠后，来自美国、风险等级为 normal 的规则具有更高优先权。一旦触发特定规则，系统将不再评估随后的规则。

• 允许低于$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 助手会将您的自然语言提示转换为 Radar 语法中的规则。您还可以直接利用 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’。而对于需要数字的属性，就不会有单引号，如 :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 包 gzip 压缩后大小为 29.6kb
  
  • 未来状态：radar.js 将能够独立于 stripe.js 单独引入
    

结论

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

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

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

其他事项

平台对 Radar 的使用

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

Terminal 上的 Radar 使用

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