风控体系：从风险识别到决策闭环

一次优惠活动出现大量新账号，同一设备短时间领取多张优惠券。业务希望尽快阻止批量套利，但一家人共用平板也可能呈现相似特征。把“同设备多账号”写成拒绝规则很容易，回答它应当触发什么动作、是否伤害正常用户、实际减少了多少损失，才是风控体系需要解决的问题。

风控的核心是：在明确的约束下，依据当前证据选择业务动作，再用真实结果检验这个选择。 规则、模型和设备识别都服务于这一过程。只有识别结果，没有执行与反馈，就无法知道系统究竟保护了什么。

本文以电商优惠活动为贯穿案例。文中的场景和数值用于解释设计，不代表某个平台的实测结果。策略与模型讨论如何量化风险，内容安全与平台治理则把这套思路延伸到内容处置。

先定义损失，再定义风险

“异常”描述行为偏离常见模式，“风险”描述它可能带来的不利结果，两者不能直接画等号。新设备登录、海外 IP、短时间重复操作，都可能有正常原因。相反，经过组织和伪装的滥用行为可能非常接近普通用户。

优惠活动首先要区分三种问题：

活动资格不满足不等于欺诈；系统自己重复发券，也不能归责于用户。把这些对象混在一个“风险分”里，会让损失归因、申诉和策略迭代一起失真。

风险目标还必须绑定业务事件。注册反批量、登录防盗号、支付反盗刷和活动反滥用，面对的损失窗口、证据和动作不同。登录异常可以触发重新认证，活动资格问题不必因此冻结整个账号。

从二元拒绝扩展到分级动作

可选动作通常包括放行、限制本次额度、追加验证、暂缓处理和拒绝。它们的成本不同：追加验证增加操作负担，暂缓占用审核能力，直接拒绝可能造成用户流失。

一个简化的决策目标是比较各动作的预期风险损失、正常用户损失与执行成本。但成本不能覆盖全部约束：法定义务、用户权益、数据使用范围和服务承诺都需要先满足。不能因为估算收益更高，就忽略这些边界。

对优惠活动而言，单次补贴有限时可以优先限制可暴露额度；发现可信的批量滥用证据后，再扩大处置范围。动作强度应当跟随证据和潜在影响变化，而非由某个孤立标签直接决定。

把控制放在完整的业务链路中

事前、事中、事后是按业务时间划分的控制环节。它们不同于组织治理中的“三线模型”：后者讨论管理层、风险与合规职能、独立内部审计等职责关系。IIA 三线模型说明

事前约束直接缩小损失空间。例如，原子扣减预算能防止并发超发，它不依赖模型是否识别出某个用户。事中判断处理剩下的不确定性；事后反馈则帮助发现原先的规则是否过宽或遗漏了新的模式。

三者也有时间差。领取后尚未核销、核销后仍可能退款，最近一批用户的结果通常还不完整。此时应记录“待观察”，不能为了及时生成报表，先把他们全部算作正常样本。

数据要回答“当时知道什么”

风险决策需要把事件、主体和证据连起来。常见实体包括账号、设备、会话、支付工具和收货信息，但它们之间的关联强弱不同。

设备指纹会受到浏览器设置、系统升级、共享设备和识别误差影响；相同 IP 可能来自家庭网络、企业出口或运营商地址转换。图上存在一条边，只说明有待解释的联系，不直接证明共同控制或团伙关系。

因此，一项特征除了数值，还应具备可解释的定义：

比如“同设备一小时成功领取账号数”，应由已提交的发券结果更新。若直接统计所有 HTTP 重试，网络差的普通用户就可能被误判为高频领取。更新链路还需要处理重复事件、乱序和迟到，不能假定消息只送达一次。

离线训练同样要遵守时点约束：一条退款发生在决策之后，即使后来能够查到，也不能回填进当时的输入特征。否则模型在离线评估中看到了未来，线上却拿不到相同信息。

数据治理也是系统设计的一部分

同一公司内部的数据也需要明确处理目的、访问权限、保存期限和删除路径，不能默认任意跨业务复用。原始敏感字段应尽量缩小可见范围，调查权限与日常策略开发权限分开。

在中国境内适用的个人信息处理活动中，应结合具体情形确定合法处理依据，并落实目的明确、必要性和相应的个人权益保障；“用于风控”不是无限收集的理由。自动化决策和敏感个人信息还有专门要求。《个人信息保护法》第六、十三、二十四、二十八条

决策引擎组织的是证据和动作

规则擅长表达明确条件与业务约束，模型可以综合多个弱信号。规则也能输出分数，模型也能输出类别，因此不能简单以“二元判断”和“连续打分”区分二者。

在优惠活动中，可以先校验活动资格和额度，再获取关联特征；对证据不足的请求结合模型与追加验证，最后生成一个业务可执行的动作。

这里有两个经常混淆的维度：

• 执行顺序：哪些步骤先运行、哪些可以并行，失败或超时后如何处理。
• 组合逻辑：多个结果按 AND、OR、阈值、优先级还是评分组合。

并行执行不等于“全部命中才拒绝”，串行执行也不等于“任一命中就拒绝”。它们应当分别配置和测试。

冲突与降级必须有确定结果

同一请求可能同时命中历史信誉规则和本次异常规则。引擎需要明确适用范围、优先级、覆盖关系和最终动作，不能依赖规则加载顺序偶然得到结果。白名单也要有用途与有效期，不应无限覆盖账号安全或法定限制。

依赖超时后如何降级，则由业务风险窗口决定。查询非关键画像失败时可以使用较少证据继续判断；关键资格或额度状态不明时，可能需要暂缓。统一“超时即放行”或“超时即封禁”都会把基础设施故障放大成业务问题。

每次决策至少要能关联这些信息：请求和主体、业务对象及版本、输入快照或可回放引用、特征与模型版本、命中证据、最终动作、有效期。规则、模型、阈值和特征配置应按兼容的版本包发布，避免只更新了一半。

可靠执行才让判断产生价值

风险服务返回“允许领取”，并不证明优惠券已经发出。返回“拒绝”，也不证明业务方真的停止了发券。系统需要把决策与业务执行状态分别记录，再用回执关联起来。

以发券为例，一次完整处理应满足：

1. 决策绑定活动、账号、领取请求和相关对象版本，不能复用到另一笔领取。
2. 发券前再次检查仍有效的资格和额度；决策过期或关键状态变化时重新判断。
3. 业务端以稳定的请求标识做幂等处理，原子记录额度变化、发券结果和待发送事件。
4. 风控侧接收执行回执；结果不明时按业务标识查询和对账，不能把超时当成失败后再发一张。

“模型识别正确但动作未执行”和“动作执行成功但判断错误”需要不同的修复路径。前者检查调用契约、版本与一致性，后者检查证据、标签与策略。

配置回滚也只改变后续决策，不会撤销已经发出的券、解除已经实施的限制或恢复被取消的订单。这些需要单独的补偿动作及授权，并记录是否真正完成。

效果评估要保留分母和未知结果

为便于说明，暂时把动作简化为“拦截”和“放行”，把结果简化为“风险”和“正常”。多级动作应分别分析，而不是全部压进一个指标。

其中 TP 为拦住的风险，FP 为误拦的正常，FN 为放过的风险，TN 为放行的正常。稀少风险场景中，Accuracy 很容易被大量正常样本主导；它不能代替对误杀与漏过的检查。分类指标定义

假设一组已完成独立复核的说明性样本有 10,000 次领取，其中风险 100 次；系统拦截 200 次，包含 80 次风险，则：

• Precision 为 80 / 200 = 40%。
• Recall 为 80 / 100 = 80%，FNR 为 20%。
• FPR 为 120 / 9,900，约 1.21%。
• Accuracy 为 (80 + 9,780) / 10,000 = 98.6%。

98.6% 看起来很好，但误拦数量仍超过正确拦截。业务还要结合受影响用户、券的实际核销损失、验证放弃率和审核成本，决定是否采用这套策略。

被拦截的金额不是已经挽回的损失

申请领取的券不一定会核销，正常用户也会被拦截。一张券面额是多少、补贴成本是多少、原本会发生多少滥用，是不同问题。直接把“拦截次数 × 券面额”称作挽损，会把意图、暴露和真实损失混为一谈。

更可靠的评估需要记录成熟标签，并说明损失观察窗口。随机抽查放行和拦截样本有助于估计两侧错误；只看申诉，会漏掉没有申诉的误伤用户。申诉成功也要区分原判错误、新增证据、政策变化和特殊救济，不能一律写成同一种训练标签。

如果要估计策略带来的增量收益，需要合适的对照设计，控制用户、设备或团伙跨组干扰，并保留必要的安全约束。影子运行只能比较判断差异与资源消耗，不能直接测出真正执行新动作后的转化和损失。

迭代要同时观察数据、决策和执行

风险模式变化、正常用户构成变化、埋点故障，都可能造成命中率上升。只有命中率曲线，无法区分这些原因。

上线后的监控应连接三层事实：

输入分布变化 P(X) 不必然意味着风险关系 P(Y｜X) 已改变；分布稳定也不能保证模型一直有效。是否重训、改规则或恢复数据链路，应由具体证据决定，而不是固定每隔几周替换模型。

新策略先用历史时点回放检查逻辑和兼容性，再通过影子运行观察在线输入差异，最后按受控范围逐步启用真实动作。每一步都有不同的证明范围。回放通过不代表在线依赖可靠，灰度期短期损失下降也不代表长期效果已经确定。

闭环需要明确的责任归属

业务方定义活动承诺与可承受的损失，风控团队设计证据和策略，研发确保决策及执行契约，运营处理复核与申诉，数据团队维护标签与评估口径。独立监督关注这些过程是否遵守既定要求。它们可以由不同规模的组织承接，但责任不能悬空。

对于开篇的同设备多账号问题，一个成熟的处理结果应能回答：当时使用了哪些证据，为什么选择该动作，实际执行了什么，后续结果支持还是推翻了原判断。设备、规则和模型都可能更新，这条可追溯的业务链路应当一直成立。