规则之坑

黑白名单的“陷阱”

在业务风控里，黑白名单是最好用的，也是最简单粗暴的，简单粗暴意味着容易出现问题，一不留神就会把自己“坑死”，一次随意添加黑名单数据可能会直接侵害大部分的正常用户，同样的，白名单的随意添加直接可能为恶意用户打开便捷之门。

一般我们在建立风控策略的时候，黑白名单策略永远是我们的第一个选择，矗立于所有策略前，原因有两点

1） 黑白名单应该是我们最有把握的，黑白名单的每一次添加和移除都需要经过深思熟虑严格审核，我们来分别看下黑白名单：

黑名单的来源与注意点：

从历史恶意样本中提取，这部分数据由于是从业务历史数据中提取出来，是最贴近业务的，也是后期风险模型最为宝贵的数据源，通常我们会从中提炼出一些黑设备、黑IP、黑身份证等信息。

第三方平台，论坛、IM、收码平台、代理/VPN IP、司法公示信息等都可以作为有用的信息来源，在获取上可以通过一些爬虫手段来丰富数据来源，对于爬虫，不同语言都有不少较为成熟的框架，如heritrix、scrapy等。亦可以通过一些特定环境下的技术手段，如端口扫描，目标论坛的已有账户爆破等，此类获取途径一般都具有极强的针对性。

其他来源，恶意用户一定会使自己的成本（猫池设备的花销，卡的维护，购买泄露账号信息等等）利益最大化，在各家业务的“风眼”进行薅羊毛、多头借贷，此时“互联”的思想在风控过程中尤为重要，众人拾材火焰高，所以黑名单也需要考虑从其他公司进行共享，联防，但这部分数据加入到黑名单需要通过业务的契合对比和较长时间的灰度测试，在后期应用时也需要做一定的区分

另外黑名单还尤为值得注意的是“进”和“出”，对于“进”，黑名单不能只是个大池子，内部必须切分成多个小池子，在进行黑名单匹配的时候应该也必须有能力去观察是否在哪几个池子中出现，标签是个不错的选择。而对于“出”，纵使对某个黑数据再置信，都需要对其有洗白的机制，不然这个“暗雷”总有一天会爆发，通常，洗白的手段有通过设置过期时间（TTL），被特定业务场景触发等，这里我们简单描述下过期时间（TTL）如何制定，一般TTL的制定分固定时间和动态时间两种，前者更为方便和普遍，这里主要说下后者，本人更偏向使用动态时间来指定TTL，所谓动态时间，即通过不同的因素制定权重来设定TTL，通过影响其的因子有以下几类：

数据的置信度，不同数据源对TTL的贡献需要被权重化，通常历史恶意样本的权重会相对更高
业务的契合度，相同数据在不同业务场景的得分也会不同，这里需要考虑业务场景的契合情况
数据类型，不同维度的数据类型对于TTL的影响也相当大，如IP的黑属性跃迁将明显比手机频繁

还有一种比较普遍的方法是通过计算得分来判断是否达到了黑属性的阈值，此时一般就不再使用过期时间，而是通过数据在池子中的时间来做衰弱递减，并结合其他的因子给出不同的得分情况，当得分随着时间推移衰减导致最终得分小于黑名单的阈值，则认为不命中黑名单。这种方式去除了过期的概念，而将风险属性分值化，时间也作为一个因子参与评分。

我们再说下白名单，白名单的来源会相对更为集中：

通常白名单来源会有一些公司出口IP、移动运营出口IP，特殊的设备指纹等
还有一些企业允许用户可以通过客服或者IVR来进行添加白名单的自助服务

这里需要注意的白名单的添加需要谨慎，如果所有的添加都是由风控人员操作的，那么只需要关注添加的筛选方式，而如果部分添加是暴露给用户的，那么需要关注自助添加的流程是否存在漏洞，是否可能被恶意用户进行利用来规避规则命中情况的发生。

2）黑白名单矗立于所有策略前的另外一个原因是效率，很多时候在一些复杂场景下，风控人员会配置大量的规则策略，有些是可以通过自有变量直接计算的，有些是维护在内存中进行累计对比的，还有需要做一次甚至多次关系型数据库的检索结果对比的，

当然也可能是大数据离线任务做的准实时结果参与的计算，这些都告诉我们，策略规则的计算是非常“重”的，从逻辑上讲，当事件命中了某个黑名单或是白名单，后续的策略也没有必要继续下去，风控结果也会直接返回。从技术角度出发，每次过“重”的策略规则将占据大量的线程资源、内存资源，也会造成不必要的资源浪费，在某些极端情况可能会造成线程排队等情况的发生。

常见风控规则的“陷阱”

除了刚提到的黑白名单策略，风控系统应该还具备配置其他的常见策略，而这些常见策略在配置过程中很多时候也会遇到不少雷区，这里我们不讨论具体策略，一起来看下可能遇到的问题

基于次数的统计类策略

对于频繁访问，频繁交易，缓慢定点攻击等场景，我们第一反应会考虑使用统计类策略来进行防御，将那些具备相同特征的用户、IP、设备等维度挡在风控的墙外，这里会遇到的问题是对于“频繁”的解读，何为频繁？多少次算频繁？如何定性阈值就成了关键，定小了，查准率无法保证容易误伤，定大了，查全率又下降的厉害，并且又由于节假日，业务高峰、低谷、活动营销等多种因素，导致固定的阈值可能会带来很多问题，这里更倾向于变量，此时比较合理的做法是将阈值支持公式加载，而不是常量，比如你可以任性的使用99线的x倍、平均数的y倍、中位数的z倍等作为一个一直在变化的阈值，有能力的话，依赖于模型会更好。

用户画像策略

同样的，在建立一些用户画像策略时候也会遇到这样的问题，如常用地策略，在风控中，我们经常会去判断用户当前行为的设备、地理位置等是否是其常用设备、常用地，而对于常用的概念也推荐是可配置的，因为一旦固化，那么被绕过的可能性将大幅增大（可配置本身并不能提高任何安全性，但是它却可以帮助我们快速变更策略，并且可以结合模型来适应当前环境）。

举个常用归属地的配置参数：

1.常用维度定性：

X天里出现过Y天
X次里出现过Y次
X周期内出现百分比大于Y%
混合使用

2.是否去除干扰：

短期内连续出现是否需去燥
单位周期内连续出现是否需去燥

3.应对极端情况：

无历史数据的或少量历史数据时（如新用户或冷号）如何筛选
极大量历史数据如何截取有效数据区间

另外一些投资购买偏好等画像更需要跟随业务做快速变更，一旦业务发生调整，或有新的业务线或者活动，策略也应该快速变更。这里还有一点需要注意，每一个策略的作用域一定要控制，这就如同永远不要在sql里使用select *，抛开性能不谈，一旦如果在中间插入某列，你原来的代码就极其有可能需要改造，所以同样的，如果你没办法让所有的业务方第一时间通知你新上的业务，那么你在运行的策略就得与新业务保持距离。

CEP策略

越来越多的规则引擎都崇尚对CEP策略的支持，但一来规则引擎本身维护CEP策略的方式就很“黑盒”，需要技术人员专门对其进行深入了解，如内存的管理，性能的调优，这里暂且抛开技术不谈，个人并不是非常推荐使用CEP策略，原因是过于复杂，风控策略可以从各个维度去侧写，一个场景可以有多条，但是个人认为每一条应该尽可能保持简单，就如同你可以将多个策略编写成一个复杂策略集，但这样其实会让可读性下降，保持多个简单策略可以让风控运营人员在人工审核时更便捷。如果一些无法避免的场景需要用到复杂策略的时候，一定要将逻辑和边界写清楚，否则会埋下很多“伏笔”。