基于规则引擎的风控黑名单管理设计

        公司之前有个黑名单的风控系统，是基于Java开发，数据加载进内存进行比较的，现在公司开发了一套规则引擎系统，基于此，对原来的风控系统改为使用规则引擎系统进行重构。

原风控名单管理实现

系统是基于微服务开发的，原风控系统是一个单独服务模块，对外暴露一个接口，其中之一是主要实现名单的过滤，包括黑名单，白名单和灰名单。

这里主要讲讲黑名单。黑名单管理中，根据数据库中的业务数据，识别出来了一些明显异常的用户数据，主要包括一些邮箱，手机号，地址，卡号等，这些字段名与值被加入不同的字段表进行存储，例如手机号黑名单表，邮箱黑名单表等等。

tg：优点是在这种方式下，每个字段被单独存储，程序读取时也可以根据业务，进行选择性的获取，不必全部加载，业务划分十分直观。但是缺点也很明显，就是十分不容易扩展，如果新增一个IP的拉黑字段，则需要额外建表，编写对应的service代码。再加入碰上系统紧急情况，需要拉黑某一个IP地址所有请求，那不仅要开发service，调试，并且重新更新上线系统，还意味着有几个辛苦的程序员，得加班几个通宵。。。。。。所以，为了尽量避免这个情况，或者减少加班的时间，把黑名单这种加入到规则引擎是有必要的。

加入规则引擎的风控黑名单设计

1 首先，当然是调整表结构了。要知道，所谓的黑名单，白名单，灰名单，描述的只是一个字段的处理逻辑。

比如匹配手机号136**********，对用户的一个请求，请求中存在手机号字段，匹配到规则引擎的逻辑，那么就获取该字段的值进行处理。先利用哈希快速查找，是否在黑名单里（跟布隆过滤器类似），如果在，拦截。其次匹配白名单，是否在，如果在，直接通过，如果不在，则触发灰名单处理逻辑，进行组合字段的判断。

在这个过程中，只需要三个表就可以，黑白灰，每一个表中都有这两个字段（fieldID，value），字段ID关联是规则引擎的字段管理ID（有些系统把规则和字段分开，这里为了简便），例如手机号字段的ID可能是10019，value就是对应的值，就是具体的手机号136******。之后就是基于规则引擎的匹配了。

tg:这种方式，好处就是结构简单，只需要黑白灰三个表就可以实现了，哪怕新增一个字段的黑名单管理，那也就是规则引擎人的任务，去写一个增加字段的服务，而对于风控系统，咱只需要在数据库里插入几条记录就可以了，一边喝茶，一边看着他们加班。

基于风险评分的名单管理系统

上面提到，本身黑白灰只是一种处理逻辑，那是不是意味还可以再抽象一点呢？当然啦，我们只需要在字段中增加一个riskScore就可以了，三个表合并为一个表。

举例来讲，就是加入一个风险分值的处理（满分一百，分越高风险越大，分为30，70两个阈值）。

对于一个手机号136**********，

假如系统给他一个风险评分90分，大于70，毫无疑问，直接给他拦下来，把请求拒绝掉，就跟55岁程序员找开发的工作一样，不要想，简历都过不了。

假如风险评分只有20分，低于30那就可以直接通过，就像是985的硕士且有三年工作经验（别问我三年经验怎么来的）的投中小厂简历，大佬直接进。

假如风险评分50分，那就得估摸着了，还得看看其他情况，给你个面试机会，再看看你的其他能力，比如家庭住址（IP字段），加班意愿（邮箱），实际工资（银行卡号）等等，进行一个加权估计，再决定要不要你通过。

问题来了，谁给他评分呢？这个分准不准？能不能动态评分？

这个目前，就只能一些大大大企业使用啦，那些有大数据和大模型训练的公司，他们训练模型，对不同的字段进行风险评分，自己使用，同时还可以卖给中小公司，别误会，只是给你一个风险评分的接口，不是给你数据，每月收你接口调用服务费（也有次数服务），不同的字段不同的价格。

图片的话，会更好理解，但是我外卖到了，下次补上。