风控系统场景分析
本文地址：https://www.cnblogs.com/hchengmx/p/15228092.html
1. 背景
风控是一个非常大的概念，不同的领域对风控有不同的需求，像跟钱打交道的一些行业，比如 电商、银行、金融机构对风控的要求也就更多。
这篇文章就来简单介绍一下，风控包括什么，以及设计一个风控系统过程中，需要考虑什么？
电商风控：风控在电商行业代表是 “反撸羊毛”、“刷单”、“爆单”，“被盗号” 等
银行放贷风控：贷前调查来判断 还款能力以及还款意愿，贷中审查来判断 逾期风险，贷后管理来判断 催收反应等
银行信用卡：虚假商户骗积分、信用卡提现等
卡组织：反欺诈、反洗钱、盗刷等
2. 数据获取
一般来说，风控的非实时数据采集，不能直接从线上的数据库中读取，这会把数据库打死。主要的数据采集方式有从库采集，日志采集和pingback三种方式。
2.1 数据库从库
主流数据库，如Hbase，Mysql都提供同步数据进从库的功能，几个数据库数据完全相同，主库可以读写，从库只读，读取从库不会影响主库操作。
2.2 数据同步
上游异步把数据送给风控系统，一种方式是通过上游系统主动送，比如说RocketMQ，上游完成数据采集后，把数据异步送给下游。
另外一种方式是通过日志采集，将风控需要的数据输出到日志中，风控数据对对接日志异步进行采集。
2.3 pingback
Pingback指在页面上埋入脚本来监测用户的操作，特别是点击操作和键盘操作，将检测到的用户行为异步发送到服务器端。这可以侦测到用户在页面停留时间，鼠标点击的区域等信息，由此可以推断用户偏好，情绪等信息。 pingback的挑战在于如何在服务器端应对流量洪峰。pingback数据一般不直接入库，可以先写入Kafka，风控系统对接Kafka来分析pingback数据。
3. 规则
规则是用来判断一笔交易、一笔订单是不是违反了系统中的已有规则，规则我认为可以分为两大类，一类是名单类的规则，一个是规则引擎类的规则。
这两类规则的特点不同，也就拥有不同的技术方案。
3.1 名单类
名单类来说相对比较简单，一个名单通常情况下包括 “名单类型 + 名单类别 + 名单唯一键 + 生效/失效时间”。
所以名单类的规则也通常是 实时计算的。
3.1.1 名单类型
名单类型包括：黑白灰三种名单。
黑名单：必须阻止
白名单：必须放行
灰名单：不是直接阻止，而是延迟交易，需要人工确认后再决定放行不放行
3.1.2 名单类别
注册登录：手机号黑名单
银行实时交易系统：商户黑名单、终端黑名单
商城系统：IP黑名单
3.1.3 外部名单
除了公司内部维护名单，在还可以引入一些外部名单加入名单。
联合国安理会发布的恐怖分子制裁名单1
全国法院失信被执行人名单信息公布与查询2
中国裁判文书网3。
3.2 规则引擎类
在设计规则引擎的时候，需要考虑以下几个方面。
3.2.1 规则的实时性
业务方首先需要确定规则的实时性需求，实时处理当然是最好的，但是实时处理就对于系统的性能要求极高。大多数风控系统也不会采取大量的实时处理，就算实时处理，也通常采用比较简单的规则，也有用准实时处理 或者 非实时处理的，准实时时效性没有那么强，可能几分钟或者几小时再进行处理。
实时性的系统：联机交易系统，比如用户A在凌晨给海外汇款，1个亿的交易涉及到了反洗钱，要是不实时拒绝的话，这一个亿可能就没了。
准实时处理：银行贷款系统，因为银行贷款系统并不需要说，立即给客户反馈放不放款，但也不能太慢，就可以用准实时处理。
3.2.2 规则的范围
规则需要对于全网都生效吗？还是只针对某些商户类型、某些银行卡、某个地区生效就行。
要是需要的话，在创建规则的时候，就需要添加一个属性，范围。
3.2.3 命中规则的后续处理
命中这个规则后，后续该执行什么操作，有几种选择。
警告，拒绝掉这一笔交易，把这个账户加入黑名单。
3.2.4 规则的条件
- 且、或。
例子1：发生一笔消费，商户类型为 大型超市 并且 (交易时间在 00：00 - 02：00 或者 22：00 - 23：59)
例子2：发生一笔交易，交易金额 > 10w元 并且 交易类型 != 消费
这种规则就需要把报文中的某几个字段取出来，再判断是不是满足规则条件。常见的操作符包括 等于=，不等于!=，大于 >，小于 <，在某几个值中 in，不在某几个值中 out。
- 累计
上面的几个例子，都是静态的数据，但系统中可能还存在动态的数据，某用户当月的消费额，就要累计计算。
例子3：在银行系的风控中，统计一张卡在同一个终端下，连续交易的天数，要是超过20天，就认为是刷单。
例子4：在电商系统中，同一个账号在同一个商户下，过去30分钟内，有超过5次购买记录，就认为是刷单。
例子5：电商系统中，某用户当月的无门槛优惠券超过10张，就认为是系统bug。
以例3为例，这种规则的需要分为两步：1. 把累计值算出来，先统计连续交易的天数 2. 规则里面再配置，连续交易的天数是不是大于20，要是大于20，才算命中规则
- 数学表达式
在更复杂的一些风控系统中，还会支持这样的规则。涉及到了数学中的一些计算。
例子6：同一张卡在同一个商户下当月的消费金额 占这张卡当月所有消费金额的 95%以上 并且 此张卡当月消费金额 > 10笔
例子7：统计某店铺当月的消费笔数 和 它上个月的消费笔数，要是当月的消费笔数 > 上月消费笔数的10倍，就算命中规则
这就需要先把数值累计算出来，再来判断数学表达式的值是真是假。
3.3 两类规则对比
名单数据在使用上的特点：
- 使用频率高，实时性要求高。各种名单匹配基本都需要在线上做实时计算。
- 数据粒度小，总量大小不一，但存储空间需求都不高。大部分名单都是一些号码表，几个G的空间都能存储。
- 更新频率低。名单数据一般都比较稳定，按天更新
在使用中，名单数据一般直接存储在内存中，或者使用内存数据库（Redis，Couchbase）
而规则引擎的特点
- 配置灵活，要支持基本字段的 且、或、非
- 复杂一点的，还需要支持累计 以及数学表达式
在使用中，规则引擎类的，会使用drools、Jess、ILog。
3.4 风控显示大屏以及告警
对于实时风控来说，时效性比较重要。经常会出现 某半个小时内，某个规则被集中命中，需要人工介入进行进一步的处理的情况。
要是确认该用户有违法操作，就需要把该用户加入黑名单，或者进行限流等操作，要是该规则配置要问题，就需要对规则进行及时下线的操作。
对于运维人员就需要有一个风控监控大屏，来及时显示什么规则被命中，统计某规则过去多长时间内的命中次数。
业界常见采用的方法是通过，开发代码中命中规则以后，打印日志，监控平台再通过异步分析日志把数据以图表的方式显示出来。
4 评分卡
评分卡多用于贷款机构，通过对客户实行打分制，以期对客户有一个优质与否的评判。这种的风控跟规则类的风控不一样，一个人过来贷款，他可能之前没有在机构贷过款，没有任何历史记录参考，那怎么来决定放不放款给TA呢？
4.1 评分卡的分类
A卡 申请评分卡（Application scorecard）：用于贷前审批阶段对借款申请人的量化评估
B卡 行为评分卡（Behavior scorecard）：通过借款人的还款及交易行为，结合其他维度的数据预测借款人未来的还款能力和意愿
C卡 催收评分卡（Collection scorecard）：当借款人当前还款状态为逾期的情况下，预测未来这笔贷款变成坏账的概率，由此衍生出 滚动率、还款率、失联率等细分的模型。
4.2 评分卡的基本原理
评分卡的核心，我理解就是通过评分，来判断出来 什么是 “好客户”、什么是 “坏客户”。
- 构建评分模型
通过几个渠道来构建评分模型
- 本公司其他平台，比如 台账系统、监管系统、理财平台等
- 人民银行的征信系统
- 第三方合作机构的系统，比如其他商业银行等
通过一系列建模，就得到类似于这样的一张图（建模细节和公式这篇文章不细讲）：
WOE(Weight of Evidence)叫做证据权重，IV(Information Value)叫做信息价值，是一组评估变量的预测能力的指标。也就是说，当我们想要拿出证据证明“年龄”这个变量对于违约概率是否有影响的时候，可以使用这个指标评估年龄到底对违约概率的影响有多大。
下面表格展示的就是年龄、性别及婚姻状况三个变量相关的好坏样本数据以及计算出的对应的WOE及IV值。WOE的计算公式是：ln[(违约/总违约)/(正常/总正常)]。比如对于年龄18~25的组别，WOE=In[(131/总违约样本数)/(1016/总正常样本数)]。根据WOE值，可以进一步计算出IV值。
建模细节和公式这篇文章不细讲了，具体可参考：
这一次，真正搞懂信用评分模型（上篇） - 知乎4
WOE信用评分卡--R语言实例_军军的专栏-CSDN博客5
- 打分
用户的基本信息：学历、年龄、婚否、是否有抵押物、年薪等进行打分。最终看这个分数在哪个区间，再来判断 是否放款、放宽多少。
5. 参考文章
1. 联合国安理会发布的恐怖分子制裁名单
2. 全国法院失信被执行人名单信息公布与查询
3. 中国裁判文书网
4. 这一次，真正搞懂信用评分模型（上篇）
5. WOE信用评分卡--R语言实例_军军的专栏-CSDN博客
6. 这一次，真正搞懂信用评分模型（之二） - 知乎
6. 推荐阅读
如何看待拼多多出现 100 元无门槛优惠券的漏洞？可能的技术原因是什么？羊毛党行为是否具有法律风险？ - 半佛仙人的回答 - 知乎
评分卡都看不懂，怎么能说自己是做风控的？ | 人人都是产品经理
支付风控系统设计：支付风控场景分析(一) | 人人都是产品经理
