第三方风控服务商怎么选：四种交付形态与八家能力边界

第三方风控服务商怎么选：四种交付形态与八家能力边界

做支付风控的人常把第三方服务商当成同一类东西来比价：都是给一个风险分数，看谁的模型更准。这个前提是错的。同样叫反欺诈服务商，有人交付的是一份建议，有人交付的是一个结果并对结果兜底，有人交付的是一整段流程的接管，还有人只在钱被划走之后才进场。

形态不同，意味着四件事完全不同：谁最终按下放行按钮、谁承担判断错误的钱、你的风控团队还要不要存在、以及你想换供应商时的退出成本。这些都不是功能表能体现的。分层设计见 3DS、风控、拒付三层怎么排，本文只解决一个问题：在这一层里，八家服务商各卖什么，你该按什么顺序筛。

一、选型的第一个问题：你要买的是「判断」还是「结果」

1.1 四种交付形态

把八家放进一个坐标系，会自然分成四组：

这张表最容易被忽略的一列是第三列。「谁承担判断错误」直接决定了另外三件事：你的风控团队规模、你需要的审批流程、以及这笔采购在财务上算成本还是算保险。

1.2 为什么形态比功能表更重要

功能表回答的是「它有什么」，形态回答的是「你之后怎么运转」。同样一套模型能力，以建议形态交付时，你需要有人 7×24 值班看告警、有人定期调阈值、有人对放行决定负责；以担保形态交付时，这些岗位可以精简，但你要接受两件事——按对方决策执行，以及采购成本随你的拒付结构浮动。

先定形态，再比厂商。顺序颠倒的典型结果是：买了一套建议型服务，却按担保型的心态期待它解决问题，最后既有团队负担，也没有责任兜底。

二、八家的能力边界

2.1 Forter：卖的是「这个人是谁」

Forter 的自我定位是身份情报。它不判断「这笔交易像不像欺诈」，而是先判断下单的人是不是同一个人——把注册、登录、设备、历史订单串成一个身份视图，再评估这个身份的行为是否异常。

这带来一个真实优势：单个商户的风控信息边界就是自己的订单表，而身份视角能看到同一身份在其他商户处的行为。代价同样直接——身份图谱的价值来自跨商户信号，所以数据共享是硬前提，你必须持续提供并共享消费者行为数据。冷启动也因此存在：订单量小、客群与网络内其他商户重叠度低时，图谱带来的增量会明显缩水。

它有六条产品线（欺诈管理、支付优化、争议管理、账户保护、滥用防范等）共用同一套判断，并公开提供 ROI 计算器，可以先用自有订单量、客单价与当前误拒率跑一个粗算。这个工具的意义不是给出结论，而是逼你先把「当前误拒率」量化出来——多数团队根本不知道这个数。

2.2 Riskified：卖的是「把不敢放的单放出去」

Riskified 的核心承诺与其他家方向相反。多数服务商的卖点是「拦得更准」，隐含取舍是宁可多拒一点；它的卖点是把原本会被拒的订单放行，并通过拒付责任转移（shift fraud chargeback liability）承担约定范围内的欺诈损失。

换个说法：它把不可控的拒付风险，变成了一笔可预算的固定成本。对处在增长压力下的业务，这个转换很有吸引力——误拒的损失不出现在任何报表上，但漏掉的订单是真实的。

它有两点必须提前想清楚。第一，担保不是全覆盖，合同会界定品类、地区、客单价上限与除外情形，也会要求你按它的决策执行；一旦内部团队出于客户关系或经验判断去推翻模型，担保的基础就不成立了。第二，定价与拒付率挂钩，成本可预测性弱于固定费率方案——拒付结构恶化时费用上行，而拒付结构又受品类、促销节奏与物流时效影响，不完全在你控制之内。

2.3 Signifyd：卖的是「发货或不发货」的二元结果

Signifyd 与 Riskified 同属担保型，但交付物更极致：多数服务商给一个分数，然后由商户决定要不要人工看一眼；Signifyd 给的是发货或者不发货，并对这个结果提供财务担保，覆盖欺诈与消费者滥用造成的损失。

它真正替代的东西值得说清——不是又一个规则引擎，而是人工审核队列。凡是订单需要人看一眼的业务，人工队列的成本大头不在工资，而在三处：夜间与周末的排班、审核标准不一致导致的争议、以及审核员为了安全感而养成的「宁可拒」习惯。担保型方案把这三处一起拿掉，这是它 ROI 的第二处来源，也是最常被忽略的一处。

2.4 Sift：卖的是「这个账号可不可信」

Sift 把判断对象从交易换成了账号。单笔交易的欺诈判断是离散的，一次一判、互不关联；以账号为中心则能把注册、登录、改密、下单、退款串成一条信任曲线。

这个视角对平台型业务几乎必要：批量注册的假账号本身不产生拒付，却会消耗补贴、刷走促销、污染数据。它还有一条实用的设计——Sift Score API 允许已有自建决策系统的团队只调用评分，不迁移到它的控制台，这让「只买能力不换架构」成为可能。

它的短板同样清晰：账号视角对游客结账无效。如果你的业务以未登录下单为主，Account Defense 与假账号拦截基本用不上，只剩下支付环节的判断，而那一块正是竞争最同质的部分。

2.5 Ravelin：卖的是滥用，以及市场平台的两端

Ravelin 的覆盖面比一般支付风控宽，共七类：在线支付欺诈、退款滥用、促销滥用、账户安全与盗用、3D Secure、市场平台合作方欺诈、交易优化。

两个差异点值得单独说。第一，退款滥用与促销滥用这两类损失不进拒付报表，通常被分散记在售后成本与营销费用里，只有专门看账的人才会发现；支付风控的常规指标根本照不到它们。第二，市场平台的风险在两端——买家侧是盗刷，卖家侧是空壳商户与自买自卖，普通支付风控只看买家侧付款，看不全。

它把 3DS 当成优化对象而非合规开关，会提供按国家的挑战成功率参考。这个数据只能当参考，不能当承诺——实际结果取决于你的收单行、发卡行组合与客群结构。

2.6 Feedzai：卖给受监管机构的一整套治理

Feedzai 的产品形态不是「给一个分数」，而是「接管一段流程」。它把反欺诈与金融犯罪治理放在同一个框架里，覆盖开户、交易、账户存续到可疑活动上报的客户全生命周期。

理解它的关键是客群：它的主场是银行与收单机构，不是商户结账页。收单方既要管商户准入、又要管商户的交易质量、还要向卡组织交代，这三件事在商户侧的支付风控里完全不存在。它提供多语言多地区部署，也说明主要战场在拉美与欧洲的受监管机构。

对普通商户，它属于能力过剩——商户结账页需要的只是「放行或拦下」，而按监管机构需求设计的产品会带来沉重的数据接入与流程维护成本。判断标准很直接：你需不需要向监管证明 AML 是系统性的？ 需要，这类产品成立；不需要，它只是负担。

2.7 Sardine：卖的是可模块装配的合规能力

Sardine 与 Feedzai 同处机构侧，差别在装配方式。它把欺诈预防、AML 合规与实时交易监控统一到一个平台，但按模块化交付，客户可以按需组合——先上反欺诈模块解决拒付，等 AML 义务落地了再补上对应模块。

这个设计针对的是一种真实的困境：合规压力是逐步到来的，不是一次性到位的。买「全家桶」型平台，等于为两三年后才需要的能力提前付费，还要提前承担集成复杂度。代价是模块越多，接口越多，阈值与策略之间的相互影响越难排查——模块化的自由，最终要用配置管理的能力来换。

2.8 Chargebacks911：卖的是拒付之后的追回

Chargebacks911 的位置和前面七家完全不同：它不在结账页上，而在拒付已经发生、钱已经被划走之后。事前拦截不是它的主业，它做的是举证、代表权（representment）、预拒付干预与追回。

它的方法论是三步闭环：减少拒付发生量、追回已损失营收、修复与收单行和卡组织的关系。第三步最容易被忽略，但对拒付率已经超标、甚至被纳入卡组织监控的商户，它往往决定还能不能继续收单——监控与解除的完整路径见 拒付率红线与商户监控。

两条商业约束要提前问清。第一，收益高度依赖拒付结构：友好欺诈（持卡人本人购买却声称未收到或未授权）占比越高，可举证空间越大；如果是纯粹的货物未达或服务质量争议，能追回的比例会低得多。第二，收费与追回挂钩的口径必须写进合同——所谓「追回」是毛额还是扣掉卡组织费用后的净额，哪些原因码计入，追回失败是否收费。这一条在实际结算时最容易扯皮。

三、五个真正决定选型的维度

3.1 谁承担损失

这是最贵的一条，也是一票否决项。建议型、流程型、补救型的损失都在你自己账上；只有担保型把约定范围内的损失转移出去。如果采购的动机是「减少损失」，却选了建议型服务，最后你会得到一个更准的分数和一个仍然要自己赔的账单。

3.2 判断对象是交易、账号还是商户

三者的信息结构完全不同。交易视角适合客单价高、笔数少的业务；账号视角适合有登录体系、需要防批量注册与薅羊毛的业务；商户视角只对平台型与收单机构成立。选错视角，等于用错坐标系——游客结账为主的站点买账号型服务，钱基本白花。

3.3 覆盖范围是否要延伸到滥用与 AML

只做支付欺诈，还是连退款滥用、促销滥用、退货欺诈一起管？有没有 AML 与可疑上报义务？这两个问题会把候选名单压缩到原来的三分之一。损失不进拒付报表的部分，往往才是被长期忽视的漏损。

3.4 数据共享的边界与退出成本

几乎所有机器学习型风控都要求你持续传输订单、设备与行为数据。要提前问三件事：数据传输范围与合规基础是否成立（跨境业务涉及个人信息出境的合规路径，见 支付数据出境合规）；模型是否依赖你的历史数据、换供应商后能否平滑迁移；以及退出时你的判据还剩什么——如果所有规则都在对方系统里，换供应商等于从零重建。

3.5 你的业务形态先决定了候选名单

四、误拒与漏判：代价不对称怎么量化

风控的每一次判断都有两种错法，而两者的代价几乎从不相等：

• 漏判（放行欺诈）：损失是货值 + 拒付费 + 卡组织罚金 + 争议处理人力。数额有限但会累积成拒付率，进而触发监控与预留金。
• 误拒（拒掉好客户）：损失是毛利 + 客户终身价值 + 可能永久的差评与流失。单笔看不见，总量往往大于漏判。

多数团队只统计第一种，因为它有报表；第二种需要你自己建口径。做法是把误拒率当成一个必须被测量的经营指标：取同一批被拒订单，按一定比例放行做对照，观察其真实拒付率与复购率。没有这个基线，任何风控服务商的效果都无法评估——你连「改善了多少」都说不出来。

成功率的整体优化方法见 支付成功率优化；策略层的设计见 支付风控防欺诈策略。

五、担保类方案的四个合同细节

如果决定走担保路线，谈判时有四项必须落到纸面，否则「担保」这两个字会在第一次大额拒付时失效：

1. 覆盖范围：品类、地区、客单价上限、发货方式、物流可追踪性要求。折扣品类、虚拟商品、预售这些通常有额外限制。
2. 除外情形：常见的是未按决策执行、超时发货、未提供可追踪物流、以及持卡人声称未授权的「友好欺诈」在部分合同里单列。
3. 成本浮动机制：费率与拒付率、客单价的联动公式，以及调整的触发条件与通知期。
4. 退出与追责：合作终止后历史订单的担保是否继续有效，有效多久；争议时的举证责任在谁。

这四项谈完之后，再去看模型准不准。顺序不能反——模型再准，条款不利也换不来实际收益。

六、事后补救什么时候才值得

事后补救的适用条件比想象中窄。它成立需要两个前提同时具备：拒付里有相当比例是可举证的（友好欺诈、未授权、与描述不符），以及你内部没有能力按时限完成举证（卡组织对举证窗口有硬性要求，超时即视为放弃）。

如果拒付主要来自货物未达或物流纠纷，那么追回空间有限，钱应该花在改善履约上，而不是买家补救服务。如果内部已有专门的争议团队且时效达标，外部服务的边际价值就只剩「渠道无关的经验复用」这一项。

判断顺序：先看拒付结构，再看内部时效，最后才谈价格。举证材料的具体准备方法见 拒付原因码与举证手册，整体争议流程见 退款争议处理流程。

七、落地顺序与验收指标

无论选哪一家，落地都建议按同一个顺序走：

1. 先建基线：连续四周统计误拒率、漏判率、人工审核占比、平均审核时长。没有基线就没有验收。
2. 单渠道灰度：先在一个市场或一条产品线上线，比例从低到高。风控的误判会直接损伤真实订单，不能一次性切换。
3. 双跑对照：新服务与旧规则并行一段时间，比对同一批订单的判断差异，而不是只看总量指标。
4. 把动作写进 SOP：谁在什么时候覆盖模型决策、覆盖需要什么审批、覆盖后如何复核。没有覆盖流程的风控系统，最终会被人绕开。
5. 定期复算：客群、品类、促销节奏变化后，阈值与策略必须重算。

验收指标建议固定四个：误拒率、每万元交易额的欺诈损失、人工审核占比、以及争议举证按时率。它们分别对应放行质量、损失控制、运营成本与事后能力，四个都要看，只看一个必然失衡。

八、五个常见误判

1. 把服务商当收单方：这八家都不接触资金、不参与清算，它们不改变你的结算周期与资金路径，资金架构仍要单独设计，见 平台型业务的资金架构。
2. 以为买了风控就不用管 3DS：认证完成后的责任转移与风控拦截是两套机制，已完成挑战的交易再加拦截，收益小代价大。
3. 用总分代替分层指标：一个「风险分」不能同时优化放行率与损失率，必须拆开看。
4. 忽略数据共享的合规前提：跨境传输个人信息需要合规路径，不是签了合同就能传。
5. 指望服务商替你做业务判断：品类风险、促销节奏、物流时效都在你手里，模型只能投影你已经做过的经营决策。

来源：16IDC 原创，各服务商的产品范围、担保条款与计费口径以对应官网文档及商务合同为准。