时间: 2021-07-30 09:08:14 人气: 7 评论: 0
编辑导语：“风控是金融的心脏，数据则是风控的血液。”风控系统在业务中是非常重要的，跟多时候都需要风控中有价值的信息来进行参考，并且搭建风控体系还需要从不同的角度考量；本文作者分享了关于搭建风控体系所踩的坑，我们一起来了解一下。
业务部一般找风控部的主要问题是：新上了一个业务，结果发现效果不达标，经过分析后发现有很多不合理的数据结果，怀疑是被黑产盯上了，希望风控部门帮忙解决这些问题。
作为专业的风控人员，业务的需求**转化为一个可大可小的风控项目，如果这家公司的业务部门很多很杂，可能还要涉及到定制化的风控体系搭建。
那么在这个搭建或者项目落地之前，一般都**有遇到可大可小的坑；这篇文章主要是基于笔者的经验，将之前踩过的坑小结出来，供需要的同学参考，由于涉及的内容较多，将分为两篇文章来讲。
前面文章我提过第一步需要调研评估，这一步其实风控的第一个关键点，也是最容易掉坑的一个地方。
业务的同事往往不了解风控实际工作，因此对于风控有价值的信息，不能尽述道来，这就需要风控人员做主动地问询、调研和评估了，一般包含的主要内容有两点：
1）业务描述
风控人员通过了解业务的每一个环节，一来可以大致确认业务可能遭受的风险攻击类型，二来为埋点提供更多细节信息。
2）损失**点
历史损失记录有助于风控人员了解并复**黑产攻击业务的模式、可能使用到的资源、并能评估出业务的短板以及现有的防御能力。
但是，这些调研并不代表调研评估阶段已经完成，后面可以顺顺利利地按照原计划来执行了，在这期间还有一些坑位也需要提前预知。
这一点很重要，务必要贴近业务并且量化！因为这个可以理解为验收标准，将切实地影响整个项目的进展。
虽然业务的需求通常比较明确——解决一个业务风险问题，但在实际立项搭建的过程中，如果只有定性目标，或者目标完全不考虑业务感受，那么这个项目最后一定很难收尾或者得到业务方满意的验收。
另外，如果业务方无法给出明确的量化指标，风控人员需要协助一同制定出项目指标，比如结合风控通用的指标以及业务通用或者关注的指标来制定。
风控体系化的搭建需要多个资源的整合，这里的资源按归属方分为风控资源和业务资源，风控资源来自于风控部门；比如决策引擎、名单库、设备指纹SDK、数据分析工具、看板/预警系统、风控数据仓库等，业务资源来自于业务部门，包括名单系统、处罚中心等。
完整的风控体系需要结合这两部分资源来共同实现，任何一方资源的缺失或不全都**造成风控短板，无法达到优良的风控循环，尤其是业务系统，在实际**点的时候务必要跟业务方确认，否则如果具体的落地方案输出给了业务方，结果业务方说没有那就很尴尬了。
这是个老生常谈的话题，但如果忽略了就是一个巨坑，甚至**让风控部的绩效凉凉。业务漏洞的排查主要存在于风控方案产生之前，主要来自于两方面：
1）业务规则漏洞
主要指业务范畴的漏洞、流程环节的漏洞以及人为失误的漏洞。
这里分别依次举三个例子，比如营销活动的无门槛优惠**问题、用户可重复无限次中奖、活动在凌晨无人值守的时间点上线；这些都需要风控部门在前期排查整改，否则损失无法估计，尤其是又遇到大量客户投诉要求索赔，到时候也只能怪自己疏忽大意了。
2）监控漏洞
主要指风险覆盖率的漏洞、接口的漏洞。覆盖率的漏洞指的是有遗漏的业务接口没被风控监控，比如某个渠道没有**点进来，接口的漏洞指的是业务接口没有做安全封装，比如接口重放的攻击。
埋点接入是将风控人员将关注的场景和数据通过日志埋点的方式输送给风控系统，它的精准度将直接影响后面的风控策略质量，它需要风控人员具备风险敏感度。
尤其对于核心场景的识别，这里简单描述一下核心场景，核心场景指的是最容易产生与业务核心KPI关联的损失的环节，比如对于交易类业务，业务更关心成交量和成交额，那核心场景就是下单或者购买环节，资金来往类业务的核心场景就是在提现或者转账环节；而这些环节以外的其他环节，比如下载、注册、登陆、绑定银行卡、注销都属于关联场景，从这些场景里产生的数据，都将最终累积成核心场景那一个关键动作的风险结果。
因此风控人员需要准确识别出核心风险场景，并切分出与其相关的关联场景。
在这个环节也有许多需要提前知道的坑：
作为风控人员，我们自己是知道什么时候需要调风控接口，但是对于系统开发测试人员，他们并不能准确地知道每个风控点，如果没有及时沟通好，很有可能开发就按照自己理解的位置去埋点取数了，结果就变成了一个坑；因此风控人员务必需要在需求澄清**上与开发测试约定好准确的埋点位置，并且如果有必要，需要使用对方业务系统的测试环境进行相关操作，并根据返回的数据验证是否满足风控需求。
数据是风控的核心之一，数据质量的好坏必然与风控质量相关，因为如果前者很差，极有可能导致风控误判或者漏判，进而导致客户投诉甚至法律纠纷；因此，在该阶段需要对每一个场景入口的数据做质量监控，并将相关异常预警给相关的开发同事，这个维度监控包括两点：
1）空值监控
如果业务不存在空值的可能性，则监控是否出现空值即可，如果业务允许空值的存在，则监控空值的占比是否出现异常。
2）干扰值的监控
如果2C端的业务不存在出现内外IP的情况，则忽然某个业务接口有大量内网IP输入，则需要监控是否存在异常接口数据上报的问题。
风控的接入并不是静止的一次性动作，随着业务的变化，也**有随之而来的新需求，因此如果没有形成规范的接入流程和文档，则**给大家都带来不便，这里的规范统一化包含如下两点：
1）日志格式的统一
日志格式的规范化可以省去很多重新对接的时间成本，比如每个字段都有规范的属性划分，手机号只能传入到mobile这个字段、用户名只能放在username这个字段，而不是手机号即可以存入到mobile字段也可以存放在username字段，这样不规范的存储**让后期策略上线很被动也很复杂。
2）接入文档的统一
接入文档的固化和规范，极能便于开发人员看懂文档中涉及的每个环节以及字段，并且在返回报错时，通过文档的内容找出问题点，而不是反过来问风控或者产品来解决问题。
好了，以上就是我在风控体系搭建前期过程中踩过的一些坑，感谢阅读。
作者：小玛，某金融公司风控分析师一枚；公众号：一个数据人的自留地
本文由@一个数据人的自留地 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
