本系列的上一篇文章搭建风控系统道路上踩过的坑02-风险分析，我们介绍了在采集信息后如何去分析这些数据产出风险事件，而产出的报警已经脱离了业务系统并不能被采用的。

说白了：分析出来的东西不能光自己看着High，还得去阻拦这些风险才能真正产生业务价值。

在开始前，我们还是回顾下业务风控主要做的四件事：

1、拿到足够多的数据
2、做足够灵活的分析平台去分析数据
3、产出风险事件进行阻拦风险
4、量化风险拦截的价值和不断分析案例进行策略优化

到了第三步我们离整个系统核心框架的搭建就只剩一步之遥了，那么让我们看看这个环节要考虑什么：

1、最终呈现给业务研发直白的判定结果

我们最终从数据中发现的报警和问题最终是要在业务逻辑中去阻拦的，在接入这些结果的时候，往往分析师觉得可以提供的信息有很多，比如命中了什么规则、这些规则是什么、什么时候命中的、什么时候过期，其中最让接入方心烦的当属风险分值当仁不让了，很多接入风控的研发看到这些分值就一脑袋包：

你到底想让我做什么，拦还是不拦？这时候如果你喏喏的再丢出个多少分值以上要拦，研发多半都会跟你说直接给我结果就好了。 

是的，很多风控接口设计的都十分累赘，无用信息多到研发会觉得你在故意浪费带宽，其实一个code list给他们说明对应希望做的操作就好，一定把你觉得那些很牛逼的中间结果等等包装成最终结果再给出去。

2、T＋0还是T＋1

举个例子来解释实时(T+0)和异步（T＋1）风险判断的区别。

T+1

你在打拳击比赛，选手A只会打脸，上来就照着你脸来了一拳，你分析了一下打脸很疼而且不科学，在第二拳往脸挥过来时你突然告知对方不可打脸，对方就成功的被你克制住了。这就是T+1的特点，至少要在第二次风险攻击才可以生效；

T＋0

拳击比赛第二场对阵选手B，同样被打脸后你说不可打脸，对方说好，结果冲着肚子就来了一拳。你说禁止打肚子，对方又一拳打腋下。这时你发现要在对方挥拳马上打到你之前就要禁止。

这就是T＋0了。

因为T＋0在接入的时候要额外承担很多计算成本，结果要现场算出来而延时要求又很高，所以一般都只在攻击者得手关键步骤采取实时判断（比如订单支付或者提现请求）。而对于其他场景可以选择T＋1方式，比如登录或者提交订单等。

3、阻断逻辑到阻断产品

这一点我们岂安在对外演讲的时候介绍过很多，在阻断风险的时候事件发生的点是不同的，但短期又不可能让业务研发在所有的地方接入风险阻断怎么办？

所以我们需要考虑几个基本的保底措施，比如统一的验证码验证页面在IP层全局防止任何爬虫脚本行为，在账号层通过登录态管理统一拦截单个账号在登录后任何风险行为（全局强制登出）。

可能这些措施在体验上不是最好的，但是在发生特殊问题的时候要等研发给你临时加阻断逻辑这个时间就没法控制了。

坑位

1、接入风控阻断的逻辑位置

登录的时候账号输入框鼠标失焦就要去走风控了，登录结果出来之后再去判断就没意义，而资金相关的一般是在跳转去收银台之前，你会发现一般风险判断都是在结果出来之前（收集本次行为完整日志之前），所以如果你要做T+0判断，就要求研发在进行风险判断的时候要提供更完整的信息，而不是只给个IP或者账号名就行了（往往T＋1就之要这些就够）。

2、对业务流量充分调研并关注

平时可能流量很小的业务，突然因为某个活动（比如秒杀）流量大增，除了在接入之初要对风险判断请求有了解，对后续的活动也要提前准备，否则如果资源预估不足，突然又赶上这个点接了T+0接口有很多要现场计算的逻辑，陡增的业务流量分分钟教你做人。

3、bypass ！ bypass ! bypass

风控风险判断的最基本原则就是要不影响业务逻辑，所以超时机制在一开始就要严格约定并执行，一旦发现风控接口超过预计响应时间立马放行业务请求。

4、让一线同事们知道你在做什么

任何风控准确率都不是100%的，所以在和研发沟通好接入后一定要告诉一线同事们风控阻断可能出现的表象，以及大致的原因，以避免一线客服们对风险拦截的投诉不知道如何解释，并给出具体的阻断回复措施（加白名单、删除黑名单等等，上帝们在某些日子比如315维权意识是非常强的）。

结语

阻断是最终产生真实价值的环节，另外也是关联部门最敏感的环节（吓唬我半天逼着我把风控接了，结果一天到晚给我出毛病？生产环境是给你们玩的？！），请保护这至关重要的信任，你后面会越做越顺的。

最后，请期待我们本系列的最终话：《量化风险拦截的价值和不断分析案例进行策略优化》。