CoolGuard风控系统基于“会话”构建可信任的验证降级机制（理论篇）

目标

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

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

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

核心思路与流程梳理

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

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

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

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

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

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

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

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

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

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

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

json 复制代码

{
  "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：

makefile 复制代码

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

降级检查伪代码：

ini 复制代码

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

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

风控轨迹审计与可视化

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

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

注意

类别	注意点
安全性	- 严格定义验证等级不能被绕过 - 降级不适用于高风险行为（如提现到新账户、修改收货人等）- 若发现会话被篡改或重放攻击，应立即终止信任关系并重新验证- 会话验证机制，不仅仅是"会话"还可以加上IP、设备等
会话隔离性	- 保持多种设备（app/web/xcx）会话隔离
风控规则兼容性	- 验证等级的定义与风险引擎需解耦 - 方便策略灵活调整
数据存储	- 验证状态建议短期存 Redis，长期落 DB - 支持多维（用户、设备、订单），多应用（租户）
时效性	- 验证状态应有有效期，如人脸识别通过后仅在 15 分钟内降级有效
审计性	- 所有跳过验证都应有完整的风控轨迹日志