风控系统的事中与事后一致性与闭环

问题

在风控系统的设计与实践中，我们经常会遇到两难：

在落地时会遇到类似的问题：

风控系统的核心价值是"在对的时间点，做对的决策"。然而，如果事中与事后的数据不一致，风控就只能"盲人摸象"，得不到真实的反馈。比如：

这些问题不解决，风控就很难做到精准、持续优化。

如图，展示了简易的登录流程，在原系统和风控系统交互时自己维护了一个上下文保存当次事件的信息，维护的主要目的就是为了解决在登录完成后反馈到风控系统时省去重复组装数据的步骤。当然如果整个流程中不会中断，那么上下文的意义好像也不是很大，但不可避免的会有中断，增强验证等等情况，这时上下文就比较有用了。

好的，问题：如果所有的原系统都维护一份这样的上下文，那么原系统对接风控系统成本就比较高了；

另外，风控系统所需数据维度多、来源广、动态变化频繁，调试成本高、维护复杂、联调周期长的特点必然带来的问题不止这些。

出于架构解耦和降低接入复杂度的目的，就要做"复杂内移"（复杂留给自己，易用留给别人）。

再如下图

箭头所指是个整体，表示风控收集的信息（图上只是分组，并非割裂），由原系统（当然很多信息也是从客户端收集而来）发起的事件如果本就是业务所需大可从其他服务直接获取，然后汇集到风控系统，这是比较常见的方式。但是如果原系统业务并没有这个需要，就可以把这个复杂性交给风控系统，风控系统可以对接各种三方服务。

1、重复

如果原系统就已经完成了这些信息的收集，风控就没有必要重复去做了，这就可以依赖风控系统的决策流了。

以下是一个简单的例子

2、长期与短期

长期指的主要是IP、经纬度、客户信息等等这些一旦确定，那么总有一个地方能确认的吧？真假？尤其展开的详细信息总是有的吧？

短期主要是说临时token，比如登录token、验证token，这些都是有时效性的。

针对于这种其实差别也不大，归根结底都是目标服务需要提供外部服务的入口，IP服务提供的可能是ip解析接口，登录服务可能提供的是临时token获取用户信息的接口。

这样一部分复杂就完成了内移，当然对于风控流程设计和规划考验就更高了。

上面主要讨论的是来源数据的问题

还有一个很重要的问题------事中事后数据一致性

前面也提到了，事前和事后数据几乎完全一致，原系统不得不重复组装一份数据发给风控，造成大量冗余。

为此风控系统可以自己维护一份上下文，在事中事件到风控系统后维护一份上下文，将本次信息保存，在响应时将决策结果和上下文id同时返回原系统，当对应的事后事件完成后，原系统只需要将此上下文id同步到风控系统即可，由风控系统来完成数据的关联。

除了上下文维护的方法之外，还可以做统一数据契约，简单来讲就是将事中事后维护在同一份数据，事中先补充部分数据，然后再加上决策结果，事后结果等等。不过这样设计的话的就要考虑数据更新的问题了。

另外，如果想要做回溯，那么就更复杂了，历史数据重跑怎么做？

开启了标签页，主要目的是方便页面跳转，并保留缓存

如下，在菜单配置了缓存的页面切换间页面保留缓存，切换不变，这样之前的查询条件都可以保存了。

如下，运行区点击行，即展开详细配置，不需要再点开弹框了，方便了一点。

事件详情优化，头部不随滑轮滚动，侧边增加关闭按钮，指标、策略集、策略、规则增加tooltip和快捷跳转

公用演示账号支持多端登录，satoken的能力