信贷风控中的名单库挖掘、使用和维护

求是汪在路上

致力于风控领域有所建树

风控业务背景

在反欺诈和风控建模中，名单库一直是一种可解释性强、有效、精准的风控手段。常见的名单库包括电话号码库（例如网贷中介、催收、传销）、App名单库（例如借贷、赌博、高炮、传销）等等。

那么我们如何挖掘、使用和维护名单库，尽可能发挥名单库的价值，以及策略灵活迭代呢？本文以号码库为例讨论这一命题。

目录
Part 1. 如何挖掘号码库？
Part 2. 如何使用号码库？
Part 3. 如何维护号码库？
版权声明

Part 1. 如何挖掘号码库？

1. 可用数据源

通讯录。从网上资料显示，一般网贷平台都会要求用户授权导入手机本地通讯录，那么通讯录备注便是一个有效的数据源。某一个人的职业、教育等信息会被其他用户打上相应的标签。例如，"房产中介_小陈"、"保洁_王阿姨"等等。利用这类短文本标签，通过简单的SQL正则匹配统计，即可得到号码的标签。
短信。根据短信内容，也可以正则匹配得到短信号码的标签。
微信昵称。不同于通讯录的被动打标签，这种属于用户主动打标签。在微信搜索好友中，输入手机号码即可找到相应的注册用户。如果是中介，为了推销自己的业务，常会在昵称中就注明，例如“网贷包过_小王”。做信息核验时可根据此方法查询。
论坛文本。根据用户注册手机号码和发言内容进行推测，但论坛文本存在口语化严重、表情符号多、上下文语义弱等问题，文本处理难度高。大部分公司应该缺少这类数据。
百度数据。这种数据可以得到一定程度上的补充，但返回的长文本增加了处理难度。

以上数据源操作可行性递减，可以根据自家平台所能获取的数据来灵活选择。

2. 号码打标签

短文本正则匹配。通常是最有效但最累的方法，操作方法是需要调研案例得到各类词库。例如逾期词库：text rlike '.*(已逾期|已经逾期|发生逾期|逾期金额|逾期应还|拖欠我司|拖欠款项|严重逾期|逾期欠款|逾期未还金额|已经出现逾期|已违约|多次提醒仍未还款).*'。
用户标签逆推。号码背后的属性本质上是人的属性，那么就可以利用app等其他数据构建用户画像，比如定义安装借贷类app较多的用户为多头借贷严重用户。进一步可以给用户所注册手机号打上相同的标签。

目前调研发现，虽然还有其他更牛的算法，但大家最常用的方案也就以上两种，应该能满足80%的场景。

Part 2. 如何使用号码库？

1. 反欺诈策略

在反欺诈规则中应用非常直接，根据申贷用户号码是否在（黑）名单库中就予以拦截。

如果做成单变量规则（比如最近与号码库中号码通话次数），则需要制定cutoff，评估圈中人群的贷后逾期表现lift是否足够高（一般在3以上即可），以及拦截率是否相对稳定（按月对历史样本评估订单通过率和bad rate是否稳定）。

2. 风控建模特征工程

常见做法是把号码库应用在通讯录、运营商通话记录数据特征工程中，构造一些RFM类特征变量。例如：

contact_agent_ratio                  double           comment '通讯录中命中中介号码的个数占比',
carrier_agent_call_time_l7d	     bigint           comment 'userid与所有中介在订单申请时间前7天总通话时长合计'

Part 3. 如何维护号码库？

离线名单库

最近为迭代风控模型做特征需要。于是四处搜集前人所挖掘的各类号码库，最终得到网贷中介号码库（200w+）、催收号码库（5w+）...... 然而，在准备构造特征时，却发现一个非常严重的问题——这些号码库都没有时间快照。这会导致什么问题呢？

在风控建模中，需要把特征X（限定在下单前的历史信息，避免信息泄漏）和Y（未来逾期表现）关联到历史订单上，得到可供建模的样本。

在这个环节，很多同学犯的一个错误就是，直接把全量号码库关联到历史订单上，却不管挖掘出这个号码库所依赖的数据采集时间是否在订单时间之后。熟练地写好SQL特征开发逻辑，回溯样本特征，评估特征IV，sklearn模型调包拟合，发现模型KS相当不错。然而上线后发现KS快速下降，这就是因为信息泄漏了。

那么正确的做法呢？—— 名单库应该以分区表存储，分区为dt，存放截止到dt的快照数据。

比如，用2019-08-01之前的历史全量通讯录备注数据打标得到一个号码库，那就存在2019-08-01这个分区。在与下单用户通讯录号码交叉做特征时，2019-08-01的订单就可以使用此号码库。但2019-07-31的订单就不能使用了，因为用到了相对于订单的未来信息。

因此，虽然最终目的是为了挖掘出更多的号码，但号码库得有一个时间快照概念。这样就能保证号码库在不断扩充（每个分区存放全量号码库），但又能用在特征工程里用于风控建模。

笔者在设计离线名单库时，一般会包含的字段有：

phone（号码）、tag1（父标签）、tag2（子标签）、data_source（挖掘所依赖的数据源）、dt（分区，全量更新）

笔者后来向负责名单库挖掘的技术同学建议如果按以上方案实施，那么名单库会有更多的业务应用场景。技术同学反馈，由于业务方（反欺诈）需求通常只要求召回足够多的号码以入库。

为满足需求，技术同学都会用历史全量数据离线挖掘一批，然后交给业务同学验收。业务同学则进一步抽样人工核验一下，入库。OK，需求完成。这是目前常见的做事流程，原因更多在于业务同学也只局限在自己的业务场景中（反欺诈规则不需要快照），并没有想到这个工作的其他意义。因此，建议业务同学在提需求时能尽可能考虑做这件事的其他价值。

2. 在线名单库

为保证线上规则稳定，一般上线时都是截止某个时间节点的名单库来做规则。实践中遇到的痛点在于，每次名单库更新，为配合策略规则调整，需要把线上名单库进行更新。由于缺乏一个线上名单库管理系统，每次技术同学都是将名单列表写死在代码中。为此，不得不每次让技术同学更新一下代码再发布。