目标

在保证安全的前提下，减少用户重复验证的打扰，从而提升用户体验。

• 在一个用户“会话”上下文中，已经通过高级别验证后，可以跳过或自动通过低级别验证。
• 降低重复验证带来的用户流失，提高交互效率。
• 前提是保证整体风控策略的安全性和可解释性。

风控系统本身并不直接管理业务系统的会话，各业务系统应该要有自己的会话管理，业务系统本身就可以做会话管理的验证降级方案，比如，在完成一笔订单验证支付后，在极短的时间内与上一笔订单相同地址和收件人的订单无需额外验证，直接完成下单，省去额外的验证。类似于这样的减少打扰的还有设备绑定，在web端登录一些网站后常常会提示“是否信任此浏览器”，如果确定，那么也会在之后的使用中减少一些不必要的打扰。等等，这些都是属于业务系统自己的提升用户体验的方式。当然这次讨论的不是这些，而是在这些业务系统接入风控系统后有可能产生的重复验证而带来的交互体验降低的问题。

核心思路与流程梳理

信任传递+“会话”上下文管理

这里的“会话”有必要展开一下，因为它不只是真实的会话，还可以订单，动作或者是子会话等等。

区分验证由来，一种是业务流程本身的，一种是风控附加的，作为本篇讨论的，只是风控附加的，业务本身的风控不应该直接干预。

1、业务应用发送风控系统进行决策

附带非常多的信息，事件时间、IP、经纬度、设备、具体其他信息等等

2、风控系统决策，当然这是笼统的说是决策，事实上并不是那么简单

风控决策出最终结果，此时应该要判断此次是否可降级？

a、业务系统决定是否可降级，通过修改“会话”的value来控制，如原sessionId是
y9kIpo5JDzcwAZRXsU8YdfqNQELtHjCn，如果想控制更细的纬度，那么就可以设置sessionId为
y9kIpo5JDzcwAZRXsU8YdfqNQELtHjCn.submit、为
y9kIpo5JDzcwAZRXsU8YdfqNQELtHjCn_change等等之类，此时风控根据“会话”来检查是否有已验证粒度就更细，甚至再加上随机数就可以做到业务控制是否可降级，所以前面才讲“不只是真实的会话，还可以订单，动作或者是子会话等等。”

b、风控系统决定是否可降级，这个就更方便了更灵活了，本身风控就有规则引擎这一套，要控制是否可降级，简单的就是加开关，在一些敏感的危险的操作上设置不可降级。

3、可降级时，判断是否降级

按照具体的要求，如果对安全性要求更高一些，那么就不仅仅是验证同一“会话”已验证等级>当前决策等级和已验证时间还在有效期内的问题了，还可以附加同一IP、设备ID、经纬度附近等等（好像又多了一道策略规则）。

{
  "userId": "u_123456",
  "sessionId": "sess_abc123.order_1",
  "verifiedLevel": 3,
  "verifiedAt": "2025-07-10T16:23:00Z",
  "expiresAt": "2025-07-10T16:38:00Z",
  "ip": "10.10.10.10",
  "deviceId": "device_abc",
  "geoHash": "w21z",
  "verifiedType": "FACE_RECOGNITION",
  "riskContext": ["withdraw", "same_device"]
}

4、可降级，则输出降级方案

存储与校验

以Redis为例使用复合 Key + TTL：

Key:  vrf:u_123456:sess_abc123.order_1
Value: JSON 验证记录
TTL: 15min（可配置）

降级检查伪代码：

String key = "vrf:" + userId + ":" + sessionId;
VerificationResult result = redis.get(key);

if (result != null && result.level >= requiredLevel && result.expiresAt > now) {
    return AllowVerificationSkip();
}
return RequireVerification();

风控轨迹审计与可视化

每次风控的降级都保留完整的记录便于后续数据分析和审查

可视化方向的话，规划中是将同一笔事件合并，包含事中、验证结果、事后结果等等整合一起，下面仅是示例图

注意