Stripe 的默认规则利用机器学习来预测并拦截大量的欺诈类付款。对于希望更深入地控制哪些付款应被审核、允许或拦截的企业而言，规则是自定义欺诈防护的强大工具。

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

让我们直奔主题。

规则顺序和等级的重要性

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

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

为了更清晰地说明实际操作，我们可以通过以下规则示例来探讨具体的应用场景。由于第一条规则的存在，所有低于 10 美元的支付都将被自动允许。一旦满足这个条件，之后的规则将不再适用。同理，根据这些规则，在美国境内且风险等级为 normal 的 1500 美元付款也将被允许。虽然第四条规则拦截超过 1000 美元的付款，但由于其排序靠后，来自美国、风险等级为 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 支持银行卡、银行借记、先买后付 (BNPL)、钱包等。请查看我们的文档了解详情，并获取 Radar 对其他支付方式的使用权限。

:risk-score: 和 :risk-level: 属性仅适用于银行卡、ACH 和 SEPA 交易。我们还支持其他适用于任何支付方式的交易规则属性。

如果您已被添加到预览版，可通过 :payment_method_type: 属性，对特定支付方式的交易进行回测并创建适用的 Radar 规则。如果您未使用 :payment_method_type:，只要不使用特定支付方式属性（例如，:card_count_for_ip_address_daily:），则您的规则将适用于所有支持的支付方式。

常用 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' 实施此规则后，如果任何收款未明确通过发卡行检查（即将提供的账单地址第一行与其存档的持卡人信息进行匹配），该收款将被拦截。这意味着，如果此检查为 ‘unavailable’，或者发卡行将此数据标记为 ‘unchecked’，又或者发卡行将其标记为 ‘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
  

You can also write rules using both metadata attributes and other supported attributes mentioned in this document. For example, you can write a rule that only places a payment in review if the Item ID matches 5A381D and the payment amount exceeds US$1,000.

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

元数据属性还支持 IN 运算符，用于匹配多个值。例如，如果 Category ID 是“groceries”、“electronics”或“clothing”中的一个，可以编写规则将付款纳入审核。

• 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 归属地为美国或波多黎各时拦截付款。

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

回测规则

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

在管理平台中进行回测

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

拦截规则

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

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

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

审核规则

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

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

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

允许规则

• 被 Stripe 或您的自定义规则拦截：被 Radar 拦截的收款

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

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

执行自定义回测分析

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

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

使用 Stripe 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 或 gomail.co 这样的域名，它们试图掩盖欺诈分子的身份。银行卡所在国家/地区和 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 失败或邮编检查失败的规则有助于防范这种行为。

交叉支付方式欺诈途径

随着业务从银行卡扩展到银行借记、Klarna 等先买后付选项，以及其他本地支付方式，欺诈分子调整了策略，以利用每种支付类型的独特特性和漏洞。了解这些不断演变的欺诈形式对于建立全面保障至关重要。

支付方式切换

欺诈分子系统性地循环使用不同的支付方式，以绕过针对特定支付类型设计的速度控制。他们可能会用尽银行卡额度，然后切换到 ACH，再切换到 Klarna，这样在触发任何单一支付方式控制之前，交易能力实际上提升至三倍。

针对这一模式，建议的属性是：

• total_charges_per_email_daily
  
• total_charges_per_ip_address_hourly
  
• payment_method_type，结合速度控制
  

针对特定支付方式的利用

• 异步支付方式重复退款欺诈：通过银行借记和部分本地支付方式，欺诈分子利用收货与支付处理之间的时间差。他们同时向银行（声称交易未经授权）和商家（声称不满意）请求退款，企图在双方察觉重复退款之前均完成处理。

• 先买后付服务的首期欺诈：欺诈分子通过购物，支付首期款项后收货，随后便拖欠剩余的分期还款，针对先买后付 (BNPL) 服务实施欺诈。他们常使用被盗账户或合成身份，使先买后付服务商难以收取剩余分期款项。

监管与政策套利

• 针对争议友好型支付方式：欺诈分子研究哪些支付方式拥有对买家最友好的争议解决流程，并专门针对这类支付方式实施欺诈购买。

  • dispute_count_on_ip_all_time，结合特定高风险 payment_method_type 值
    
  • is_disposable_email，结合争议友好支付方式
    
  • 争议法规有利于买家的地理模式
    

其他最佳实践

以下最佳实践可进一步帮助您优化 Radar 规则编写。

使用 Stripe.js 的重要性

• 将 stripe.js 包含在完整的支付路径中，以最大化欺诈信号
  
• 为了在不影响页面加载时间的情况下充分利用 Radar，请在非支付页面上异步加载 stripe.js
  
• 最容易放在 Google Analytics 脚本标签旁边
  
• 完整 stripe.js 包 gzip 压缩后大小为 29.6kb
  
  • 未来状态：radar.js 将能够独立于 stripe.js 单独引入
    

结论

规则可以成为帮助您定制欺诈防护的极其强大的工具。通过实施独特的逻辑，并参考本指南中列出的一些最佳实践，您可以在 Radar 中创建针对您业务需求的欺诈防范设置。

进一步了解 Radar Plus。

如果您已经在使用 Radar Plus，请查看您管理平台中的规则页面，开始使用规则编写功能。

其他注意事项

Radar Terminal 版

Terminal 收款不会经过 Radar 筛查。这意味着，如果您使用 Terminal，您可以基于 IP 频率制定规则，而无需担心会拦截您的线下付款。