编辑导读：风控流程方案设计会牵扯到多方系统，需要考虑到各方因素，踩的坑自然也会多。上篇文章分享了搭建风控体系在调研评估和埋点接入时所踩过的坑，这篇把之前在搭建过程中踩过的坑分享给大家，一起来看看吧。

01  风控流程方案设计

风控流程方案设计会牵扯到多方系统，好的设计既考虑策略的优、简、易，同时能兼顾于各系统的耦合，也是风控的重要环节之一，在设计过程中，须清楚如下两点：

1. 大方向须结合自身“资源”

整个风控体系搭建的方向是针对业务关注的某类或者某几类风险，在搭建过程中一方面需要从黑产情报中获知其目前掌握的攻击技术、作案手段以及工具资源，另一方面需要掌握现有业务系统所能支撑的资源情况，比如运营资源、数据资源、处置资源等等。笔者之前参与的一个风控设计项目因为没有深入了解业务侧的实际资源情况，导致交稿方案中的名单落地因为业务方资源跟不上而被推翻。

2. 细节决定方案落地的成败

每一个细节都务必与业务侧以及开发侧确认！每一个细节都务必与业务侧以及开发侧确认！每一个细节都务必与业务侧以及开发侧确认！因为笔者花费最多时间的就在这个环节，所以重要的事情说三遍。一个好的风控体系可以理解为一个资源整合优化的过程：全量的接入数据，经过复杂运算后，通过与各个系统间的耦合，将坏数据“筛选”出来。每一步都是环环相扣，承前启后的，所以设计的时候要考虑好这一步与下一步的关联以及对全局的影响。

笔者曾经在一个风控项目中在业务响应侧就出现过一个问题，由于没有过细考虑过某些维度字段的实际落地细节问题，导致开发在接入的过程中发现由于业务前端本身对接系统太多，无法采集到这个字段，最终导致该字段无法落地到名单标签中，最终导致闭环系统里里缺了这个字段，后面为了解决这个事情让项目耽误了一段时间。

02  测试联调

在这个环节，业务方的开发人员已经完成基本的数据采集以及接口开发工作，后面就进入联调校验阶段，笔者的日常工作中需要使用风控引擎对接各个业务系统，风控引擎其本质是将从各个业务端输入进来的数据，经过各类数据分析计算，最终输出风控处置结果（如下图）。由于业务线复杂多变，每一次的需求变动，以及每个变量的修改/增减、规则调整、模型迭代优化或者代码的优化，都有可能影响引擎性能，因此在每次搭建的测试联调阶段都需要确认接入的数据是否满足风控需求。

在这个过程中，笔者之前踩过的坑有如下这些：

1. 验证问题

风控测试验证不是说通过业务方的测试传入几个必传参数就完事了，这里面有两点须确认：数据、决策结果。

1）关于数据

如上图所示，风控接口一般会收到基础用户数据、业务参数数据、设备指纹采集数据、第三方的名单或者接口调用的数据，在这个环节需要确认数据的准确度与一致性。笔者之前经常在这个环节遇到问题，不同业务线的开发人员经常会错误理解采集点或者经常丢失，导致返回的参数始终无法命中风控策略，需要反复多次的联调验证，因为这个环节的数据将决定生产环境的上线结果，因此这一步需要格外重视。

此外，如果有客户端测试环境，建议通过该环境的操作确认风控埋点位置是否都有采集，这一步做的目的也是为了精准确认数据的采集情况。

2）关于决策结果

如上图所示，风控引擎接收到测试数据后，通过模型及规则的一系列复杂计算，最终输出决策结果，因为决策引擎只输出一个风险评价数据，真正影响到业务的是处置阶段，这个环节重的点是验证决策结果的准确度。决策结果的准确度主要指按照约定好的模型和规则是否可以准确响应，反映准确度的评价标准一般可包含覆盖率、交叉率、误伤率、准确率、WOE、IV值、ROC、KS等，分析完成后，最后根据分析的测试结果，可输出决策评估报告给业务方。

笔者在这一步主要遇到的问题是在做策略时没有深入了解一线业务的真实情况，或者业务方自己也忽视了这些情况，这就导致经常从数据分析角度看用户是有问题的，但实际上这些异常是有合理的业务解释的，所以对于决策结果准确度上，除了要具备严谨的数据分析能力以外，还需要紧密的业务合作。

2. 响应问题

这里笔者想讲的响应问题包含两点：性能响应与业务响应，前者是通过相关指标的监控验证系统间对接后的性能的响应问题，后者是通过客户端的展示验证是否与背后的风控处置结果一致。

1）关于性能响应

业务侧通常需要“零感知”的风控效果，因此对风控系统通常有明显的调用时长（RT）限制，此外，对于体量较大的业务方还会对QPS、TPS等有明确要求，因此在测试联调阶段，也需要考虑增加对此类指标的监控。

笔者之前遇到的问题主要来自于响应时长问题，不同业务方对响应时长的级别不同，对于那些RT可以满足的风控接入，如果需要极短的响应时间，可考虑使用轻量级的接入，因此在测试阶段重点关注该数据是否达标。如果RT不能满足的风控接入，可通过异步接口调用，同样也要验证RT是否达标。

2）关于业务响应

风控决策结果输出之后，业务侧需要按照预期设计好的逻辑响应落地，在这个环节需要验证的是：每一个风控结果的输出都有对应的业务处置落地，并且客户端也有对应的响应话术，以及正确的事后闭环 。展开来说，每个决策结果跟业务现有的处置手段都存在映射关系，不存在有冗余的决策结果或者处置手段，且每个处置手段都在客户端有相应的响应动作，最后，每个需要有处置手段的数据都可以将关键的风控维度落地，并多次使用。

笔者有一次因为在这个环节因为缺乏经验，设计了繁冗复杂的落地方案，结果在测试验证的时候发现业务方并没有做好客户端的相关改造，结果导致在改造完成之前先用临时的急救方案替代正式的方案。

好了，以上就是我在风控领域搭建时遇到的坑以及总结的经验，希望这些能够帮助到大家今后的工作。

作者：小玛，某金融公司风控分析师一枚，专注风控多年，持续更新风控系列文章，“数据人创作者联盟”成员。

本文由@一个数据人的自留地 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议