风控|那些年搭建风控体系所踩的坑后续( 二 )_便利店|茶饮|咖啡师|便利蜂|消

2）关于决策结果
如上图所示，风控引擎接收到测试数据后，通过模型及规则的一系列复杂计算，最终输出决策结果，因为决策引擎只输出一个风险评价数据，真正影响到业务的是处置阶段，这个环节重的点是验证决策结果的准确度。决策结果的准确度主要指按照约定好的模型和规则是否可以准确响应，反映准确度的评价标准一般可包含覆盖率、交叉率、误伤率、准确率、WOE、IV值、ROC、KS等，分析完成后，最后根据分析的测试结果，可输出决策评估报告给业务方。
笔者在这一步主要遇到的问题是在做策略时没有深入了解一线业务的真实情况，或者业务方自己也忽视了这些情况，这就导致经常从数据分析角度看用户是有问题的，但实际上这些异常是有合理的业务解释的，所以对于决策结果准确度上，除了要具备严谨的数据分析能力以外，还需要紧密的业务合作。
2. 响应问题这里笔者想讲的响应问题包含两点：性能响应与业务响应，前者是通过相关指标的监控验证系统间对接后的性能的响应问题，后者是通过客户端的展示验证是否与背后的风控处置结果一致。
1）关于性能响应
业务侧通常需要“零感知”的风控效果，因此对风控系统通常有明显的调用时长（RT）限制，此外，对于体量较大的业务方还会对QPS、TPS等有明确要求，因此在测试联调阶段，也需要考虑增加对此类指标的监控。
笔者之前遇到的问题主要来自于响应时长问题，不同业务方对响应时长的级别不同，对于那些RT可以满足的风控接入，如果需要极短的响应时间，可考虑使用轻量级的接入，因此在测试阶段重点关注该数据是否达标。如果RT不能满足的风控接入，可通过异步接口调用，同样也要验证RT是否达标。
2）关于业务响应
风控决策结果输出之后，业务侧需要按照预期设计好的逻辑响应落地，在这个环节需要验证的是：每一个风控结果的输出都有对应的业务处置落地，并且客户端也有对应的响应话术，以及正确的事后闭环。展开来说，每个决策结果跟业务现有的处置手段都存在映射关系，不存在有冗余的决策结果或者处置手段，且每个处置手段都在客户端有相应的响应动作，最后，每个需要有处置手段的数据都可以将关键的风控维度落地，并多次使用。
笔者有一次因为在这个环节因为缺乏经验，设计了繁冗复杂的落地方案，结果在测试验证的时候发现业务方并没有做好客户端的相关改造，结果导致在改造完成之前先用临时的急救方案替代正式的方案。
好了，以上就是我在风控领域搭建时遇到的坑以及总结的经验，希望这些能够帮助到大家今后的工作。
作者：小玛，某金融公司风控分析师一枚，专注风控多年，持续更新风控系列文章，“数据人创作者联盟”成员。
本文由@一个数据人的自留地原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议