Stripe Radar 升级：全支付方式风控与 AI 反欺诈

Stripe Radar 升级：全支付方式风控与 AI 反欺诈

Stripe 在 2026 年 5 月 27 日的官方博客中，由其支付智能产品负责人 Samuel Bakouch 披露了迄今规模最大的一次 Radar 升级。三件事同时发生了变化：拦截的覆盖面从银行卡扩到 Stripe 支持的全部支付方式；拦截的时点从「事后拒付」推到「事前预测」；风控对象从「这笔支付是否用了盗卡」扩到「这个账户是否会滥用」。本文引用的所有百分比均来自 Stripe 官方披露，是其在特定统计口径与商户组合下得出的结果，不代表任何单个商户的实测值。

一、这次升级到底改了什么

1.1 覆盖广度：从一种支付方式扩到全部支付方式

Stripe 披露，Radar 现在对 Stripe 支持的全部支付方式做风险拦截，包括银行借记、先买后付（BNPL）、加密支付、数字钱包、实时支付与现金凭证。

这解决的是过去几年最尴尬的一类问题：卡收单有成熟模型，而本地钱包、银行借记、BNPL 这些通道往往只有基础校验，甚至只能靠人工抽检。团队一边在开新市场，一边在这些通道上几乎没有风控。

更关键的是信号的跨通道复用。按 Stripe 的说法，一旦在某种支付方式上识别出欺诈模式，该信息会用于保护所有支付方式的交易。例如某个欺诈者在一家商户用盗卡被拦截后，同一 IP 与设备指纹会在全网范围的银行借记、钱包、BNPL 交易中被标记。

Stripe 披露，在使用 Affirm、Cash App、Klarna、PayPal 的商户中，五个月周期内 Radar 使可疑欺诈下降约 71%。这个数字要谨慎解读：它是多种支付方式的聚合结果，说明「跨通道统一风控」本身有杠杆，但打开开关并不等于在你的业务上也能拿到同样的降幅。

1.2 多处理器信号：把「可能出事」提前到事前

新增的多处理器信号（multiprocessor signals）提供两类预测。第一类判断一笔支付是否可能触发卡组织的早期欺诈预警（early fraud warning）；第二类预测一笔支付是否可能演变为欺诈争议。

两者的用法不同。前者用于保护争议率——在预警落地之前主动退款，避免这笔金额进入卡组织的统计；后者用于决策——退款、补证据，还是调整争议策略。

这类信号的价值是把成本从「事后」挪到「事前」。一笔已经变成拒付的交易，除了本金损失，还要付拒付费、占争议额度、留下记录；主动退款只损失一笔订单。但退款过于激进会伤复购与口碑，因此要按客户价值分层：低客单价的一次性客户可以果断退，高客单价、长生命周期的客户值得先补证据。

1.3 自定义欺诈模型：把自有信号变成风控资产

商户可以向 Stripe 传入自有信号，包括商品目录数据、会员等级、行为指标或其他结构化元数据，Stripe 结合其全球网络数据训练定制模型。

通用模型看到的是「这笔交易像不像欺诈」，看不到「这个用户已经在你这里买了三年」。反过来，一个注册十分钟就下大额订单的账户，在通用模型眼里可能只是信息不足，而在你自己的数据里是明确异常。

Stripe 披露，早期采用者在误报不增加的前提下多识别出至少 15% 的欺诈。

这条能力的投入产出高度不对称：信号干净、结构化的团队能拿到增量，信号混乱的团队只是把噪声喂给模型。没有稳定的商品目录、会员体系或行为埋点，就不该把它排进第一优先级。

1.4 新增欺诈类型：多账户、按量付费与机器人

这一批里最值得注意的不是「更强的盗卡识别」，而是风险对象从「交易」换成了「账户」与「用量」。

• 多账户滥用：单个欺诈者创建多个账户反复领取优惠，或把盗卡行为分散到多个账户以延长被发现的时间。Stripe 披露，在其网络中 AI 公司每 6 个注册里就有超过 1 个与多账户滥用相关。Radar 可实时评估每个新账户，信号包括设备指纹、IP 与邮箱域名。ElevenLabs 借助该能力，在近两个月内每天拦截约 2000 个滥用免费额度的用户。
• 按量付费滥用：按用量计费的业务在账期内累积费用、账期末才付款，恶意用户可以在账期内消耗大量算力然后不付。Radar 可在用量累积过程中预测不付款风险，让商户提前要求预充值或停服。
• 机器人支付评分：Radar 为 Stripe Checkout 上的支付给出 bot 评分，用来区分「代表客户行事的合法智能体」与「恶意机器人」——后者包括抢限量库存、滥用促销价、绕过限购。

这三类问题的共同点，是传统风控工具完全打不到：AVS、CVV、3DS 解决的都是「这张卡是不是本人的」，而不是「这个人会不会赖账」。如果收入来自订阅、免费额度或按量计费，这一节的优先级应该高于卡欺诈。

1.5 平台的商户风险信号与争议处理

面向平台的部分，Stripe 给每个商户、每笔交易一个 0–100 的欺诈评分，配合可解释的 AI 洞察、账户历史与备注，以及争议、拒付、退款、支付等账户级指标。

三个新信号分别是 fraudulent website、fraudulent merchant 与 merchant delinquency risk。第一个像人类分析师一样看站点红旗——不合常理的低价奢侈品、AI 生成文案、拼错的品牌域名；第二个判断新老账户是否存在欺诈风险；第三个预测余额是否可能连续 60 天及以上为负，供平台调整结算节奏或提前处理。

争议侧的升级在 Smart Disputes：它会为具体证据字段给出 AI 建议，例如物流单号、客户使用记录。Stripe 披露，采纳 AI 建议证据的商户胜诉率是从不提交证据的 3 倍。此外新增了证据库，条款、退货政策、服务协议只需上传一次，后续按原因码与卡组织要求自动选用。

二、Radar 的三种决策来源

2.1 规则：确定性最高，也最容易腐化

规则的优势是确定、可解释、可审计，适合硬约束：黑名单、地区禁售、单笔金额上限、同卡短时间内的次数上限。

代价是维护成本随业务扩张线性上升，而且规则是静态的——攻击者只要摸清规则就能绕过。规则堆得越多，误杀与漏杀往往同时增加。

2.2 平台 ML 风险评分：默认的基线

平台评分的价值来自网络效应：同一张卡、同一台设备、同一个 IP 在其他商户的表现都会进入模型。这类评分开箱即用，效果的下限很高，适合作为默认决策依据。

它的局限也很清楚：只能回答「这笔交易像不像欺诈」，回答不了「这个用户值不值得冒险」。后者需要你自己的业务判断来叠加。

2.3 自定义模型：在基线之上做增量

自定义模型的意义，是在平台评分之外引入只有你才有的视角：虚拟商品不可转售、老会员的复购周期、某类行为指标与欺诈的相关性。

前提是标签质量与样本量。欺诈标签天然滞后且稀疏，模型上线前要先确认你有足够的历史争议结果可以训练与验证，否则只是把噪声包装成模型。

2.4 分工与优先级

一个可用的分工是：规则做兜底与硬约束，平台评分做默认决策，自定义模型做增量，多处理器信号做跨通道与事前保护。

按阶段看，交易量还小、争议样本不足的业务，应先把规则与平台评分用透；等基线稳定、历史数据足够，再考虑自定义模型。具体的分层思路可以对照 支付欺诈防范策略。

三、把新能力用起来的顺序

3.1 第一步：先量基线

没有基线就没有优化。至少要量三个数：拒付的笔数与金额、欺诈造成的直接损失、被拦下的真实订单（误报）价值。

不少团队一上来就问「阈值设多少」，但在不知道自己的拒付率、误报率与平均客单价之前，任何阈值都是拍脑袋。

3.2 第二步：定阈值与动作

评分的意义在于映射成动作。常见的一组动作是：放行、挑战（3DS）、人工审核、拦截、主动退款。

每个动作都要挂一个成本：挑战会流失一部分真实订单，人工审核有人力上限，拦截会带来客诉，主动退款损失一笔生意。先算清这几种成本，再决定哪个分数段对应哪个动作。

3.3 第三步：灰度与误报观察

新规则先以观察模式运行，只看命中不做处置，先确认命中名单的构成是否合理；再放小比例流量，观察真实订单的流失。

误报的代价是真实订单与真实客户，而这些客户不会告诉你「我被误拦了」，他们只是不再下单。这是灰度不能省的根本原因。

3.4 第四步：再扩到多处理器信号与自有模型

等基线稳定、误报可控，再往上叠加：多处理器信号用于事前退款决策，自定义模型用于增量识别，机器人评分用于限购与促销场景。

顺序做反的典型后果是：模型先上线，误报暴涨，团队失去信任，最后连基础规则都不敢调。想同时兼顾授权率与风险，可以对照 支付成功率优化 里的指标拆解。

四、和 3DS 的关系：责任转移之后 Radar 该管什么

4.1 责任转移意味着什么

3DS 挑战通过之后，欺诈拒付的责任转移给发卡行，你在这些交易上承担的风险已经很小。

在这个前提下继续拦截，收益是「少了一笔可能的损失」，代价是「确定丢掉一笔真实订单」。对已完成挑战的交易，这笔账通常不划算。

4.2 认证覆盖不到的地方才是主战场

风控资源应该压到认证覆盖不到的场景：

• 免验证交易：低风险豁免、小额免验，以及发卡行直接放行、不弹挑战的流程；
• 商户发起交易：订阅续费、MOTO、分期扣款，这些没有持卡人实时参与；
• 不走卡组织链路的方式：银行借记、BNPL、钱包、实时支付，这些通道根本没有 3DS 这层保护。

这几块怎么组合，可以对照 支付风控分层 与 3DS2 认证接入 两篇一起看。前者讲层次与职责划分，后者讲豁免条件与责任转移的边界。

五、拒付与争议：统计口径先对齐

5.1 三个口径不能混用

讨论拒付时至少有三个口径：拒付笔数比、拒付金额比、欺诈在支付中的占比。

笔数比对高频小额业务更敏感，一笔大额欺诈在笔数口径上几乎看不出来；金额比会被大额订单显著放大，适合评估资金风险，不适合评估运营质量；欺诈占比混合了欺诈拒付与非欺诈拒付，不能直接用来判断风控效果。

5.2 必须把「是否经过挑战」分开统计

真正有用的口径是分层的：经过 3DS 挑战的交易、免验证交易、商户发起交易，三者的拒付应分开计算。

混算会带来两个后果：把责任已经转移的拒付算到自己的风控头上，同时掩盖真正失控的那一类。分层监控项的设计可以参照 拒付监控体系，具体到原因码与证据准备，可以对照 拒付原因码与证据手册。

六、落地时的四个注意

• 厂商披露的百分比是特定口径下的结果。71%、15% 这些数字来自 Stripe 的商户组合与统计周期，能说明这件事有杠杆，不能说明你能拿到同样的结果，把它当方向而不是承诺。
• 自定义模型的收益取决于你传入的信号质量。传结构化元数据是低成本动作，但模型效果取决于信号与欺诈的真实相关性；没有验证过的信号，不如不加。
• 误报的代价是真实订单。每次拦截都要问一句：这笔被拦下的订单值多少钱？客单价越高，拦截的期望成本越可能超过欺诈本身。
• 多处理器信号偏事前预防，不等于事后免责。它可以降低争议发生的概率，但不改变已经发生的争议，也不改变卡组织的监控机制。

七、适合谁先上

四条判断标准：

• 支付方式多且跨境：通道越分散，跨通道复用带来的收益越大。
• 订阅或按量计费：账户滥用与不付款是主要损失来源，这次升级正对着这两块。
• 平台型业务：商户风险信号与账户级指标可以直接接进入驻审核流程。
• 已有结构化自有数据：商品目录、会员体系、行为埋点齐全，自定义模型才有输入。

反过来，单市场、单通道、交易量还小、连基线都还没量清楚的业务，先把基础风控与统计口径做对，收益比追新功能大得多。整体位置可以参考 Stripe 的能力矩阵，也可以放进 支付架构分层 里一起规划。

来源：Stripe 官方博客《Expanding Stripe Radar to protect more of your business》，产品能力与数据以 Stripe 官方公告为准。