风控系统设计假想与表设计的多维分割

金融行业中，风控部门一直是一个重点，风控人员通过风控系统将寻求金融业务的客户信息进行风险样本的比较，将风险过高的客户排除在提供业务的范围，避免由于高风险客户给公司造成的经济损失。

风控系统如同找茬的游戏，通过已有的RULE （规则），来将用户的信息与RULE 进行比对，通过比对，找出客户不符合公司最低标准的点，通过对这些点的进一步计算，得出客户是否应该被接受，或者拒绝。

而风控中主要做的一般来说，可能有以下几件事

1 尽量收集多的数据

2 可以更加灵活变动的规则库

3 并发的比对和变量运算

4 更人性化和动态的界面输出

一，尽量收集多的数据

数据的收集分为，提前数据收集和事后数据收集，事前数据收集主要是通过收集已经在各个系统中公布的失信人的数据，将这些数据存储进系统将这些数据作为一个前期比对。

      而前期的比对，对排除风险是最有效和快速的，并且节省大量时间和费用。例如如果我们拿到了收集到的失信人的身份证号，则可以将其存储进REDIS 中，在每次比对先将申请人的身份证号，进行一次比对，快速的将最危险的人拒之门外。

      但一般来说，如果收集的数据不多，或者比对的时间过长，则会影响风控系统的运行效率和准确率以及功效比，造成系统设计的失败。所以第一步，数据尽量的要多，对比尽量的快，是这一块设计的要点。

      有同学可能提到，为什么不并行比对，其实这里设计到免费和收费的事情，每次比对一个客户的信息可以由两种方式，免费（自己收集失信人的数据）和 收费（调用收费系统进行信息的比对），而这里面不能并行的原因是，如果免费的即可解决问题，为什么要花公司的钱，进行收费的比对。

所以这里提到的就是一个矛盾点，如果信息不足够的多，对比不足够的块，则这个系统开始就设计失败了。 总结  多，快，是success 的 first step.

      如果客户在第一步没有被淘汰，基本上就要走到第二个步骤，收费接口的比对，一般通过收费的接口可以得到更加详细和稳妥的数据，而这里边在比对的过程中，消耗的时间和效率，个人认为有以下几点。

1 那个接口费用最低

2 那个接口的反映最快

3 那个接口的信息最全

其实这三点也是矛盾的，一般来说，信息最全的，费用一般不低，而信息反映最快的也可能是费用不低的，总结服务好的一般收费都贵。

这里大家都有一个想法就是，我得到的数据是否有必要存储，个人觉得，分行业，如果是互金，绝对是有必要，那些质量低下的人，可能没完没了的去申请贷款，所以如果动用了花钱的方式去收集数据，那数据一定不要丢弃，壮大自己的免费的信息库，尽量让那些质量低下的人，都进入黑名单。 而如此又会回到第一个问题，对比的是否会更快。

2 更加灵活的规则库

规则可以看做学校体育运动会上，撑杆跳的那个横杆，而一个可以上下灵活变动的，可长可短的，可粗可细的横杆就是这个规则库的关键点，风控部门很可能要添加一个风险辨识点，例如去年还是年龄55岁的人就不能贷款，今年由于银行政策变动，50的人就不可以进行贷款行为了，或者某个省份的人，由于当地的特殊政策或者地缘问题，我们45岁就不贷款了等等问题，造成规则库匹配和定义会异常的灵活和需要快速响应。

个人能想到的就是，匹配的规则的顺序，例如我们有评分卡，如果100分为满分的情况下，一个人如果达到50分以下就是垃圾客户的情况。我们是否可以将一些规则中分数值比较高的进行提前比较，例如（以下仅为假设不具有任何实际意义）

年龄，性别， 城市，收入，职业等等

如果分别数值设置在 

年龄  30   性别 10  城市 10  收入30  职业 20

变量运算时我们是否可以节省时间，可以不完全比对，

1 如果年龄超过 55 则不可以贷款，直接比对结束，其他的条件根本就不用比对了

2  如果年龄OK ，职业是无业， -20  收入 4000 元以下 -30， 直接OUT 

这里想说的是，是否可以将一些敏感度高的分值高的，拍在前面，直接节省比对的时间。

其实到这里，矛盾又出现了，如果一次比对全部的变量需要时 30秒，而设计部分比对的复杂度，和效率（如果大多数时间比对后，都需全部比对），则部分比对存在的必要性在哪里，这是一个问题。

而还有另外一个问题，并行比对，这也是很多互金公司采用的方法，既然我辨别不了比对的顺序以及通过部分比对快速OUT 客户，都失效的状态下，我们采用并行比对，也就是拿到客户的信息，快速的多线程的，将信息分散后进行比对，提高速度，这样是一个好方法，但提提高了系统的复杂度。

另外在设计时我在想，并行度提高，对其他系统的影响可能不是很敏感，但对数据库的压力，则是显而易见的（同时处理的线程，以及热点表的访问提高了），如何将压力分散，让数据库能扛过去这是一个问题。如果是并行的比对，我们存储信息的方式，是否可以由行存储，将其打散，划块存储，这都是值得讨论和深思的。

 

3 处理后数据的利用

在一个单一的数据处理后，这些数据其实大部分时间就么有用了，而如果深层次的去想问题的情况下，这些已经失效的数据是否还可以被利用。

可以有以下的几个方面来考虑问题

1  缓存数据，是否在后续的催收或者其他步骤还需要使用数据，我们是否需要继续保持这些数据，并且被其他系统调用

2  建模分析，在数据越来越值钱的今天，积累的数据是否可以帮助业务部门分析出更适合当前的形式，建立更多模型和规则

——————————————————————————————

作为现在一个多元化的时代，一个业务系统的稳定，少不了多元化的数据库的支撑，如上所述，当前有两种流行的信息传输的方式 XML 和  JSON，而后者被众多的程序员追捧。

大数据库中少不了JSON 这样的格式，而存储和处理这样的格式就少不了MONGO DB ， 另外快速的初期比对，快速的比对可能少不了内存数据库的支撑，例如REDIS ， 而如果频繁的增加变量，（字段），在选择数据库上也是有选择的，要知道那种数据库更适合频繁的快速的不影响系统的添加字段扩展变量。另外快速的数据分散存及聚合，字段的灵活设计，也在风控系统中存在，例如，风控中如果多个系统都需要调用数据，我们是单张表，还是根据调用，减少HOT TABLE ，建立多个维度的表。

如果建立多张表的情况下，字段在多张表上基本一致，还有不同点，怎么维护多张表的统一性，等等都是问题，解决查询的灵活性，带来数据插入的问题，有没有方法解决（例如触发器），或者有比触发器更好的方法。

比如，我们需要三个表，基本字段有ID， NAME ，不同的是 主表A 只有这些信息，B 表 多了一个字段 AGE，并且B 表只存储TYPE =1  ，C 表多了一个字段  STATE,并且只存储TYPE =2 的数据

怎么控制，让横向的分表在数据插入不在使用触发器，等等问题的解决，其实目前有数据支持横向分表，这样的操作可以更灵活的处理多种需求任务以及分散数据的存放。