大数据风控体系建设

背景

在过去的几年,金融科技被大范围传播,风头无量.也有大型银行放出话来,要成为数据公司和科技公司.在数据和科技的背景下又加上过去大数据,AI各种牛逼的名词加持下,风控系统成为这些领域的突破点.

去年的这个时候,黄浦江畔的"老年人俱乐部","当铺思想",曾经的教主跌落神坛,成为互联网上嘲讽的对象.其实我一直觉得,阿里的公关方向是存在严重问题的.其实背后的思维逻辑很简单,因为阿里有非常强大的风控体系和能力,那是不是可以创新一点,放松点监管,而舆论的导向却变成对监管的不尊重,不要监管.

提示

说说2%的资本充足率

试想一下,蚂蚁2%的资本充足率,在当前的金融体系里面,还有哪个同学敢这么做??2020年建设银行年报,被认定的不良贷款总额2607.29亿,贷款总额161910.67亿,简单估算坏账率为1.61%,如果算上没有被认定的不良贷款,再加上只有2%的资本充足率,建行是要倒闭的.(这边只是举个例子,真实的坏账率计算是很复杂的)

我是技术人,主要谈谈为什么阿里的风控那么牛逼.我很侥幸曾经经历过阿里的风控建设和前期讨论,之前一直没有一个很好的时机来整理自己的思路,刚好最近有机会,就顺便发表出来.

风控的分类

一般我们会把风控系统按照业务切入点分为事前风控,事中风控和事后风控,其实原理都类似,都是希望一套系统能解决给定的一个实体通过一些业务逻辑的检查,最终得到对于这个实体的评价.

当然不同的风控切入点的系统,对于系统的表现形式有很大的差别 事前风控:一般要求大量数据的检查,数据量适中,一般需要在亿级数据中的比对,最常见的就是信贷审批,黑名单之类的还是基本的,要求高一点就要看看当前的申请和历史申请的比对.这种系统的难点就是亿级数据的查询匹配,性能要求一般在5s以内就可以,这类系统的技术难点都在查询的算法上,内存数据库,时序数据库都是在被考虑的范围内.

事中风控:就是在交易过程中,我们对当前这笔交易的认定.主要是针对当前交易中涉及的主体的各种行为特征进行检查和匹配.这种系统访问的数据相对是最少的,而且一般不要求100%准确,但是响应时间有严格限制,一般要求100ms以内.其实可以这么理解,可以鉴别不出来这笔交易,但是也不能影响线上的业务.这种类型的系统也是现在的技术大热点,Flink,streaming各种框架层出不穷.

事后风控:主要是贷后,我们能否识别到风险.事后风控针对的是海量的数据,不但是我们业务系统自己的数据,还需要别人的数据,同时需要判断精准,如果不精准一定是判断规则出了问题,就需要不断的调整算法.这类系统就是我们当前讨论的大数据风控,AI风控.主要的特点就是需要判断的数据量特别大,判断的点特别多,逻辑巨复杂,同时变更特别多….我们也可以从另外一个层面看带这个分类,"事前风控"和"事中风控"可以看成在技术发展的前提下,从"事后风控"中剥离出来的一部分需求的小型化和实时化.

由规则引擎说起

从上面的分类,我们可以说无论什么风控,都需要进行规则计算,差别在于有的规则计算是匹配数据,有的规则计算是计算评分.

规则计算,一方面关联了业务,各种业务上的对于计算的要求,所以要求规则本身的变动在允许的范围内,所以规则引擎就应运而生了.规则引擎的诞生就是为了满足在一个体系内的计算逻辑需要灵活的变动.

当前的困境

执行问题

从十几年前,drools的开源到规则引擎的盛行,现在谈论到规则引擎就是drools那套.我们可以简单的看看drools构建的风控引擎是怎么玩的.

上图就是传统的规则引擎的调用流程.

这个缺陷非常明显,规则引擎只做最终的计算,所有依赖的数据都需要外部业务系统传入那么规则引擎的规则在完善和变动,只要需要不同的数据,就需要外部业务系统传入.而风控的业务会有时代热点,需要不断的变更,规则是可以变了,但是需要的数据也会发生变化,而业务系统往往无法承受这种变更.最终的结果是计算逻辑是低成本了,业务系统成本变高了.只要规则引擎的执行逻辑里面需要外部传入数据,系统的变更成本不是降低了,而是转移了.

这种玩法还有一个更致命的问题,假设数据B收费10元/次,为了让规则能顺利执行,我们需要先支付10元钱,拿到数据后再执行规则,而规则引擎在上述的逻辑中往往用不到B的数据,在数据收费的当下,这种浪费是惊人的.对于公司来说,花钱是可以的,但是花钱没用,这个问题如果摆上台面,就不是那么好看的了.

在这种场景下,规则引擎就好比一个刚出生的婴儿,需要业务系统给规则引擎喂数据,然后规则引擎负责嚼和拉.规则引擎需要外部系统提供完美的呵护才能正常运行.

规则安全

做风控的一定要自身硬.如果风控系统本身就被人攻克了,那风控就成了笑话.所以规则的安全就是核心保护的对象.一般做安全的,会采取如下几种措施

1. 把规则引擎系统独立于公司其他系统的部署,独立设置安全权限比较高,比如只有某类人员可以查看/编辑规则.
2. 风控独立成立小组/部门,和业务人员,技术人员独立办公,减少交互
3. 在合同上限定风控人员独有的竞业协议
4. 采取各种侦查措施,或者建立各种侦查手段,比如不允许拍照,不能截屏,规则页面上增加水印等等

但是纵然有上面列出和未列出的措施,在互联网金融起来的那段时间,还是有很多风控人员没能抵制住诱惑.那些年薪100-200W的CRO能提供的本身的价值以外,有部分是因为,他们对之前的规则比较了解,能在一定的条件下,在新的环境中能复制出来.

而传统的规则引擎在安全方面,只能在系统层面上提供更为苛刻的权限控制以外,就没有任何能力了.

规则测试

无论多么高级的规则,当规则出现变动的时候,我们是否应该进行测试???当然还有可能这个变动就是把某个规则里面的阈值从0.1变成0.12.我们如何来衡量当前的改动对整体业务的影响???

如果按照开发流程中的一个理念来理解的话:所有的系统在上线前都必须经过回归测试,那么上面的问题就是毫无疑问的.

规则测试和软件测试不一样,软件测试一般是需要保证系统功能是完备的.而规则测试却需要证明,当前的规则不但是完备的,而且还要比之前的版本更厉害,那么问题来了,如何来证明当前的版本比之前的版本更厉害???

我了解了很多公司,前期规则的回归测试都很少做,更不要说后面的证明了. 而因为规则测试没有能力解决,从而导致运营人员害怕规则的变更引发各种系统不适,导致做决策的时候,一个规则能不变动就不变动,往下传导就是规则的安全问题.

当前问题的一些解决方案

1. 为了解决数据的问题,设计出了反人性的规则的规则.就是再建一个流转规则,在每请求一次真实的规则前,先判断需要请求哪个规则,然后只获取这个规则的数据.(完全破坏规则的执行方式,不顾规则引擎本身的规则流/规则集不用,也不顾及规则设计人员的思维方式,拆散规则逻辑)

2. 给规则设定出很多系统外的规矩,禁用规则引擎部分功能,比如一个规则里面只能使用一种类型的数据,不允许规则的嵌套等等.

3. 建设规则引擎的外围辅助系统,专门在业务系统和规则引擎之间辅助数据的传递,帮业务系统缓解数据变动的压力.这种变动只是在缓减规则变动时候,在系统层面的影响,并没有从根本上解决.

4. 为了解决测试问题,我们会分割请求,让2%-10%的请求访问新版本的规则,98%-90%的请求访问稳定版本的规则,美其名曰,冠军挑战,我实在忍不住想问问搞风控的朋友,不同的请求之间有可比性么???

而在技术大发展的当代,一个可变动的执行逻辑不是技术难点和重点,从简单的表达式引擎到动态语言再到自定义语法都对这种场景能很好的支持.就传统的规则引擎来看,无论PPT写的有多少,还是IDE做的多炫酷,还是设定的规矩有多具体,提供的解决方法在多少家公司成功实施,本质上没有解决根本性问题.如果要从根本上解决这个问题,只有一种方法,那就是规则引擎本身需要具备数据访问能力.而规则引擎要具备数据访问能力,将会涉及风控领域整体的工具集在风控生态圈中的重新定位.

解决问题

分析问题

所谓的规则,在技术人员看来用编程语言中的函数的概念来表达会更容易理解,而且规则本身一般不会有复杂的业务逻辑,只有各种属性的判断逻辑,所以规则可以简化为只有判断逻辑和阈值的函数.

解决思路

数据依赖问题

外依赖的问题也可以简化为,执行逻辑需要数据,而数据又在系统外传入,而函数的运行只需要再执行到数据前,对应的数据存在即可.所以更进一步,所谓的规则引擎需要具备的数据访问能力,使用一般人能听懂的话来说就是在规则内,在使用数据前,得到需要使用的数据.

如果我们可以把规则引擎的规则和调用逻辑稍加改造,变成如下图所示,就会简单不少.

在上述图形中,我们需要做到一个事情就能解决数据依赖的问题.

• 把取A的数据和取B的数据抽象为取数据(X,参数),然后把A和B作为参数传递,从而让上面的方法变成A=取数据(A,ID) 和B = 取数据(B,ID)

如果做到了在规则引擎内部有一个获取数据的方式,外部的业务系统也不是什么数据都不传,而是只传关键数据.

这个关键数据是依据业务来定的,拿授信业务来举例,外部系统需要把当前的授信的记录传入,在授信记录里面会有授信的实体id,金额,时长,抵押物id等要素,而不需要把授信实体的所有信息包括授信实体的关联信息传入,通过这种方式,能让规则引擎在很大程度上减少对外部数据的依赖,同时外部系统也不需要跨越多个系统去取数据.

如果涉及到非自有数据,那也是在使用之前进行获取,规则引擎不再需要数据传入,把外部矛盾转化为内部矛盾.就算数据收费,也能做到用多少取多少,不会吃亏.

从规则逻辑上来看,规则的设计逻辑就是实现逻辑,只要中间不需要人工干预,就能从头执行到尾,如果中间需要人工干预,也可以分成几段调用,而不是把规则拆成单个规则调用.

规则测试

造成规则变动的缘由主要是

• 新增数据的引入
• 老规则漏洞

规则漏洞又有唯二的2种

• 该抓的没抓 ,所谓漏判
• 不该抓的反而抓了,所谓的误判

最终决定规则准确有效的依据,应该是对之前的记录做了多少矫正.

而规则测试本身也是依赖于数据,全系统总共1亿用户的数据,不可能都拿来做规则测试,我们一般会抽取其中的5W到10W左右的数据用于测试就可以了,这边还会衍生出一个数据取样的标准.

这边给出一个我认为比较合理的数据取样标准.假设用户的数据存在3个维度

• 性别---男,女
• 年龄---10-20,21-30,31-40...
• 职业---医生,老师,警察...

那么最终可以通过对不同数据的笛卡尔积,得到下面一个表格

样例	性别	年龄	职业
1	男
2	女
3	男	10-20
4	男	21-30
5	男	31-40
6	男	10-20	医生
7	男	10-20	老师
8	男	10-20	警察
6	男	21-30	医生
7	男	21-30	老师

因为是笛卡尔积,所以有必要去掉一些组合,比如10-20,职业中不应该包含医生等条件,这样可以减少这张取样表的数量.

某一条原始的业务数据都能在这种采样方式下,找到对应的数据,最终体现在最后的采样报表里面就是哪些影响维度是提高的,哪些影响维度是上升的,可能还有一些维度是没有测试到的.

另外,也可以使用单元测试中的覆盖率来检测规则执行的覆盖率,统计分析规则内部的所有分支,在规则引擎执行过程中记录执行轨迹,就可以得到当前数据的模拟执行中对规则的覆盖率了.

规则安全

不要谈谈"没有绝对的安全"这样的空话,如果我们希望做到尽可能的安全,衡量标准就是"如果不安全,能不能是影响很小的",当这个影响约等于0的时候,那就是尽我们最大能力做到的安全程度.

解决安全的思路有以下几点

1. 系统和运维结合,多变化,分权

接上面规则测试的话题,如果规则测试系统化,类似于Devops那样,每天都自动跑测试,自动出结果,那么规则的变更频率就会上去,真实运行的规则的多样性在很大程度上可以满足安全的需要了.

在规则操作层面引入三权分立的理念

• 规则设计:提供规则逻辑和原始参数
• 规则开发:开发规则逻辑,所有参数都是用占位符的方式替代,只有执行逻辑,没有调用逻辑
• 规则运维:通过测试结果修改权重和常量

通过这种运维设计,谁也不知道当前生产上运行的规则的具体信息,无从复制.

2. 扩大规则数量,降低单规则的权重 很容易理解,一旦资料泄露,影响的也是之前没有变动过的规则,而没有变动的规则,我们可以影响规则的权重.当整个系统里面的规则数量非常大的时候,单个规则的判断影响面就会很小,从而增加整体系统的容错性.

而规则的数量很大程度上取决于数据的数量.最终还是增加数据的多样性,提高数据使用率.

规则的数量其实更多的影响一些心理.如果系统内规则的数量只有100条,那么决策者就会天天担心会不会有人偷拍屏幕,会不会有员工被人请吃饭.如果系统内的规则有100000条,反而不会担心有人拍我屏幕了,请吃饭了,拍个屏幕吃个饭能带走多少东西,只要保证基本的安全措施就可以.

3. 增加数据的多样性 站在数据部门的角度看,数据只有2类,自有的数据和别人的数据.站在多样性的角度看,这种理解是不够的,数据的多样性,更多的应该指代是现实数据还是抽象数据.

• 现实数据,也就是说,是基于某种发生的现实,我们记录下的数据.比如,交易流水,当前账户余额等等,这些都是现实的记录而已,在时间维度上真实发生的.
• 抽象数据,目前更多的是使用各种工具从现实数据上抽象生成的.比如,个人的爱好,个人的品位等等.

如果规则中分拆使用到了这些数据,那么这些规则就没人可以搬走.要搬走这些规则的难度会大到相当于搬迁整个系统.

警告

从数据分析再生产数据,是目前最为稀缺的,也是每个企业最为个性化的.我个人认为,这块领域才是未来AI的主要切入点.

杰克马曾经说,阿里现在最需要的不是技术人才,而是大量的社会学家,心理学家,各种非技术领域里面的专家,结合数据分析,自我体会.

难点分析

从技术难点上来考虑,唯一的问题,就是如何实现取A的数据变成取数据(X,参数)

在数据目标明确的前提下,获取数据从技术上来说,没有那么困难,困难的是一个统一数据的访问入口.

主要的难点有下面几种

1. 不同的介质的访问表现形式是不一样的,存储在DB里面的数据和存储在Hbase上的数据,在访问过程中,涉及到的驱动程序,调用接口都是不同的.
2. 有时候我们并不是需要静态数据,而是实时的数据,比如余额,额度
3. 不同数据的存储结构不一样,规则引擎里面的使用结构更不一样,在不同的结构下面如何做到统一
4. 在公司合纵连横下,今天的盟友会不会变成明天的仇人,今天的仇人会不会变成明天的兄弟,数据的变化无法预估,但总体上看,数据量是增加的.
5. 如果系统建成,会不会面临迁移问题,现有的存量数据呢??

上面是随便列举的一些问题,至少当前系统需要考虑的问题子集.上述问题本质上都是数据存储引发的问题,一个统一的数据访问接口,会不会引发存储结构的变化,能不能兼容各种存储结构.

最终的问题,归结在一起,就是为了取A的数据==取数据(A,参数),这个函数取数据(X,参数)的过程应该怎么来处理.

X的业务含义

规则设计人员要使用X的数据,不一定需要知道每个传入数据的X的值,但是希望知道X的结构,为了在下面的规则逻辑中,使用具体的X的数据.

所以无论从哪个角度考虑,都需要建立一个关于X的目录,这个X就代表使用"传入数据"能获取到的所有的数据目录,以及获取到数据以后的数据结构.

文件柜:就是指代不同的实体类型,比如人,组织,车辆,也可以是贷款单,保单

文件夹:一个文件夹就是一个实体的所有信息,如果文件柜是人,那么每个文件夹就是这个人的所有信息.

纸张:纸张就会指代具体的数据.

X可以看成在文件柜上,我们有个目录,可以查询当前的文件柜里面,每个文件夹所能提供的所有数据的目录

取数据(X,参数)的业务含义就是,查找某个文件柜内的某个文件夹的某项数据,传入数据的含义就是具体文件夹的编号,而X就是某项数据的编号.

如何获取

针对于X对外描述的是一个数据项的定位和数据项的结构.对内还要解决查询问题.查询问题面对以下几类问题

1. 多类型的存储平台 通过X绑定一个数据源,绑定一个查询SQL,能适用绝大部分的存储平台,甚至能做到数据源都是动态创建的

2. 实时数据,直接查询接口 实时数据,这个是一个难点,如果在做成工具话,需要考虑接口的协议,报文的格式,以及报文内容的转换.如果不再系统内考虑,我们针对一个外部数据源,写一套对接程序,对内使用相同的通讯协议,那么接口访问就能统一化.

3. 只有一个变量,怎么样支持各种各样的查询

我们举一个例子来说明这个问题,假定我们需要查询贷款人A的贷款记录,然后规则里面使用3个月贷款总额和6个月贷款总额进行计算.而数据库里面存储的是这样的情况

主键	贷款人	金额	时间	状态
0	0	0	0	0

常见的处理方式可能是先从数据库查询用户A在6个月内的记录,然后再内存中根据时间分别统计3个和6个月的数据.

但是这种方式是不能统一化的.这个问题就转变为针对X的模型和粒度的问题,如何能做到通过不同的条件设置取各种各样数据.

上面的问题可以转化为

• X1 = 3个月内有效贷款总额
• X2 = 6个月内有效贷款总额

按照数据要求可以通过2次查询来实现

获取数据("3个月的贷款总额" , 用户A) 真实的sql可能是:Select sum(金额) from 贷款表 where 贷款人=用户A and 时间<3个月 group by 贷款人

获取数据("6个月的贷款总额" , 用户A) 真实的sql可能是: Select sum(金额) from 贷款表 where 贷款人=用户A and 时间<6个月 group by 贷款人

对于这个SQL来说,虽然中间涉及多个条件,但是针对这个贷款记录和A来说,是唯一的参数条件,其他的参数条件都已经隐含在了X上,在真正查询的时候,唯一条件使用参数传入,其他条件使用静态写死的方式.

这种解决方案是把一次查询变成二次查询来解决,如果贷款表记录很多,很容易造成性能问题,这种情况又有2种解决方案

1. 建立中间表,让X的查询,直接查询中间表
2. 提供接口,数据存放缓存,异步刷新

通过对上述需求的分解,对于X来说,不是按照数据的种类在进行建模,而是按照数据使用的方式来进行建模.

数据引擎

我们可以通过抽象,把上述的功能包含进一个子系统,我这边暂时命名为数据引擎.所以,系统结构会进行变更.

数据引擎不但承接统一数据访问的功能,同时承接使用数据的元数据功能,在承上启下的风控生态环境里,数据引擎可以看成风控访问数据的唯一入口,其他的系统要么是使用数据引擎的接口,要么是给数据引擎提供数据.

而从数据引擎的角度看,数据引擎为了能很好的融入风控体系,本身不做存储,只是提供信息路由和访问对接,所以不管是业务系统的数据,还是大数据部门的数据,还是外围的数据,都可以被纳入数据引擎的元数据管理.数据引擎本身的性能没有瓶颈,但是整体风控的计算,因为牵涉大量数据访问,可能会导致计算缓慢,这个计算缓慢是数据本身的缓慢造成的,可以通过优化存储的方式进行提高.比如上面举的3个月内的交易额,6个月内的交易额,完全可以使用每日跑P提前计算,存储在磁盘或者内存里,达到性能提升.

当数据引擎被引入风控以后,整个风控系统的信息访问流程发生了变动,会涉及一些工具子系统在风控系统内的重新定位.

前面在举例文件柜的时候,其实是想说明数据引擎内部模型的关系.如果把整个文件夹看成是对应用户的一张照片的话,那么每个属性对应的都是这张照片的像素点,当一张照片的像素很少的时候,看清这张照片是很费力的,随着像素点越来越多,照片也就越来越清晰.

数据引擎中的数据项的数量,就是一个风控系统内的数据多样性的指标.这个数据量越大,风控系统的质量越高,元数据中包含有自己的个性化数据越多,风控系统就越安全.

系统生态

在引入数据引擎以后,整个系统的结构和访问流程基本可以画出来.

系统职能转变

在规则类计算的风控体系下,规则引擎作为风控的唯一入口,作用显著增强.

数据引擎作为风控的数据访问的唯一入口,中枢作用明显.

大量系统都会演变为数据提供者的角色,主要是为数据引擎提供数据.

组织协调转变

数据部门原本是为了整个计算提供数据访问的.现在规则类的数据访问全部通过数据引擎进行路由和访问,数据部门对于规则类的数据访问可以完全按照使用建模,业务需求对于模型的影响降低,更容易的沉淀模型.

ETL工具原来存在数据模型和访问不匹配,通过ETL变形的过程会逐渐减少.但是从数据完整性的角度考虑,从现实数据获得抽象数据,统计数据的需求会增加.

和AI的关系

目前AI在国内大范围的兴起,在图中主要表现为AI决策和AI分析

• AI决策,是针对目前国内大量的智能风控.只要看到新闻上特斯拉出车祸等新闻,就知道AI作为完全的决策是不能实现的.在现阶段,AI决策只能作为规则引擎的下游系统,参与部分规则的计算,给规则引擎提供AI变量.随着AI的成熟,不排除AI可以完全掌控,那只不过对于AI变量的权重编程100%而已.

• AI数据分析,这个是下一阶段各个大厂的热点区域,能区分企业个性化的最大变量.从技术的角度看,技术还在演变,但是,最大的变数不在技术,而在于社会学,心理学,行为学等人文学科的理论突破.

写在最后

这里讨论风控体系,难道这套体系只能用于风控的场景么???我们在生活中处处都充满了选择,有选择就有放弃,就有机会成本,在这种成本下风控本质上是一种决策的一个应用场景.

一旦各种人文学科的理论把人研究透彻...