数据风控那点事

数据风控那点事

数据风控那点事

活动笔记·大数据

本文优质度：★★★★★ 口感：内蒙古牛肉

笔记侠说：

一、数据风控

是一个什么样的行业？

数据是大数据风控的核心，数据的量级要大，数据的维度要多、数据的迭代速度要快，立体多维迭代快才能体现数据的真正价值。

而风控是对市场、信用及实操层面的风险控制。

大数据风控的直观感受，它是能将相似的人更精准地分群，既能让你看到形形色色的人，又能让你从丰富的单一数据中看到万千的世界。

做数据做模型要了解人和业务场景才能够更准确的进行实践应用。

1.数据风控的目的是什么？

当我们想去银行办一笔贷款时，从客户的角度，大概流程是这样的。

数据风控那点事

当我们换个角度，从银行的角度，流程又是这样的。

数据风控那点事

从上面两张图看起来，其中有一个重要环节，即在贷款申请人提交了申请资料后，银行需要对贷款人的申请资料进行审核。

毕竟银行要给你钱，银行总要知道你的还款能力，而不是说拿了钱就跑。

怎么审核？

只有一个办法，用机器（主要是电脑）来提高劳动生产率，把成本降低到能让企业赚钱的程度。

但用电脑代替人有一个很重要的前提是，用数字去描述人的各种行为，并且要把这些描述逻辑写成电脑程序，以便电脑可执行。

简单来讲，用电脑代替人来进行贷款审核，需要如下四类职位共同来协作完成（毕竟他们需要的专业知识还是有相当差距的），而且实际情况非常复杂。

业务人员：主要确定金融产品的相关细节，他们了解客户的需求和金融相关的知识，同时，他们也是所有需求的发起者。

数据分析师：这类职位的主要作用是把业务需求转化为数学逻辑。

IT研发：这类职位则把数据分析师所得到的数学逻辑写成计算机程序和代码。

IT运维：这类职位的主要作用是保证电脑的正常运行，不要死机。

当然，实际情况是职位之间会相互交叉。

同时也会有更多的职位，大数据风控我认为就是数据分析师和业务人员的结合体，把人对风险的判断转换成电脑可以识别的数学逻辑；

通过数据的分析进一步提供挖掘出更多有利于我们对客户风险的判断。

2. 做好数据风控需要掌握什么技能？

一名合格的数据风控，不仅需要掌握很多技能，还要有各种相关的实操经验。

有些技能是硬功夫，也就是那种通过短期的突击培训就能相对熟练掌握的技能；

有些技能是看的见，摸不着的，需要时间和项目去不断积累才能掌握的技能。

① 代码能力

代码能力是作为一个数据风控的基础中的基础，如果一个入门的员工连这项能力都没有，而其他能力又不够吸引人，那么，在绝大多数急功近利的企业中，根本不会有任何机会。

一名数据风控需要掌握的技能，基础是SQL，R，Python，SAS中的任意一样，不过，其中的SAS目前在国内用的人越来越少。

如果能同时掌握2~3项技能，还有一个精通，那就很棒了。

② 数学基础

这里的数学基础主要是概率论和数理统计中的主要内容，包括均值、方差、假设检验、回归分析等内容。

另外，为了跟上目前机器学习这个热点，最好学习一些相关的决策树算法、离散数学、运筹学、最优化等方面的内容。

③ 数学建模能力

这个既可简单，也可复杂。

往简单来说，就是按照行业已有的套路把模型做出来，虽然很多地方不知道为什么，但只要按照规矩走，跟着做几个项目，就出不了大问题。

往复杂去说，其实，数据风控就是将业务问题转换为一个个数学的问题，去求解和分析。

虽说行业中常碰到的问题也就十几种，但能在不同机构把这些事情实打实的做一遍，而且有自己的思考和发挥，这种机会不会天天有的。

④ 银行业的基础知识

同样，如果简单的话，只要搞清楚你们家的房贷利息是怎么算出来的，在各种情况下，违约金怎么算，每个月的还款金额是怎么算出来的，到底有几种还款方式；

往复杂里说，目前主流的个人信贷产品特征、费用构成、主要客群等信息。

像《货币银行学》、《宏观经济学》、《微观经济学》以及近年来特别流行的相关书籍，包括我们国家跟银行业、征信业相关的监管机构、职能及法律法规，跟风控相关的上下游产业以及比较主流的黑产等都需要有所了解。

⑤ 数据知识

数据是数据风控的原材料，没有这些原材料一切都无从谈起。

那么，我们国家目前针对不同等级的个人信贷产品，能够在业务流程中获取到的数据有哪些？每种数据不同来源有哪些？都有哪些数据供应商？

数据的主要获取方式、当前的主流价格、每种数据在使用中涉及到的优点和问题等。

⑥ 行业和业务经验

很多事情就像一层窗户纸一样，原理很简单，但别人不跟你说就很难明白。

这些经验包括在不同场景下常用的风险策略、在突发情况发生时常用的应对方法、风险策略的决策机制、如何与IT部门沟通风控需求以及怎么写各种文档等。

这个行业和其他行业一样，都是从别人告诉你怎么做，到自己明白怎么做，再到告诉别人怎么做这一个曲折上升的过程。

但唯一不变的就是变化，尤其是我们这个行业的相关知识的迭代速度可能相对于其他行业更快，逆水行舟，不进则退。

二、如何从零构建信贷业务的

大数据风控能力？

其实，从零构建信贷业务的大数据风控能力有点浮夸，也没这个水准真正的从0做起，我们都是站在了巨人的肩膀上。

很多人应该都没有经过一项信贷业务真正从零做起，不过，你经历过后，一般都会有“人生大起大落，实在是太刺激了”的感觉。

建立一个名副其实的具有大数据风控能力的金融科技企业，一般会经历这几个阶段：一穷二白、盲人摸象、小有积累、日积月累。

1.一穷二白：拍脑袋

在产品上线前，一般来讲，没有任何数据可以分析，唯一能借鉴的就是我们在之前的工作中积攒的经验。

产品形态：

是最先确定下来的，因为这是后面所有一切的基础。

这里的产品形态包括额度范围、还款方式和综合息费水平；

关于产品，还有一个非常重要的方面则是还款方式和还款提醒这一点经常被人们忽略。

其中现金贷这个市场与传统金融熟知的面向优质人群的信贷市场有一个最大的差别在于：借款人的素质。

这个人群有几个特点需要引起注意：

① 一个人通常一个月有很多个还款节点；

② 不是特别在乎征信，而且平台主动报送的积极性和通道都有问题；

③ 自控能力差，一般都是有钱就花的主。

风险策略和数据供应商：

它们会相互影响，而且是直接取决于我们的产品形态，因为你要参考市场竞品的产品流程，不能为了控制风险而影响了用户的体验；

同时，对于有些数据，如果没有成熟的供应商，那么，在开发力量有限的情况下，也很可能无法完成采集，而能够获取到的数据又会直接影响到我们在不确定风险政策时潜在的可能性。

根据产品逻辑、目标客群以及能够对接到的数据源，拍拍脑袋，把风险策略定下来，就可以进行下面的步骤了。

需要注意的是，这个阶段，模型大概有如下几种情况：

① 这里的模型就是代指拍脑袋的规则；

② 这个模型是从别处“借鉴”来的；

③ 从外部采购了一部分。

在确定了基本的风险策略和数据供应商后，进行接口的对接也有不小的工作量，尤其是大名鼎鼎的运营商强授权数据。

决策引擎：

决策引擎应该很多人听过，不过出于种种原因，它被复杂和神秘化了。

其实，决策引擎最核心的功能是在用户发起申请后，能够从众多数据源或内部数据库中将决策所需要的数据调用过来。

将数据进行处理后，根据预先设定好的风险规则进行判断，并可以输出决策结果（是否授信、额度、利率等），主流的决策引擎软件，包括FICO的BLAZE，Experian的 SMG3等。

决策引擎在开发中的难点主要是兼容性，规则的灵活配置，辅助BI（商业智能）和热拔插。

但在业务的这个阶段，这些功能的优先级都不是那么高，因此，程序员的hard code（指的是在软体实作上,把输出或输入的相关参数 「例如:路径、输出的形式、格式」直接写死在原始码中）是性价比最高的实现方式。

这一阶段团队需要具备的能力：

① 能有一个比较靠谱的风险规则，这个一定需要至少在个人零售信贷领域制定过风险策略的经验；

② 能够针对产品特点，梳理产品可能存在的风险点，经验要求同上；

③ 能够将风险规则和产品需求转化为IT需求，这个经验要求至少是能够做简单的数据分析，能写一些简单的代码的产品经理。

④ 能够将上述需求在后台实现，并且能够保证系统的稳定运行的研发能力，这个主要要求有相当时间的后台开发经验，最好是信贷行业。

⑤ 最好对目前市场上成熟的数据供应商有相当的了解，包括服务形式，大概市场价格等等。

2.盲人摸象：碰运气

这个阶段通常是在产品上线及前三个还款周期结束前，之所以称其为盲人摸象，是因为这个阶段，只有申请数据，而没有足够的还款表现，就像盲人摸象一样，只能摸到片面，而不是整体。

在这个阶段，我们的大数据风控团队除了检测这个规则体系的平稳运行以外，还必须做如下几个事：

① 开发一个定时将业务数据脱敏，并导出到一个独立数据库的功能；

② 确定风险监控的基本框架和观测特征集，建立一个简单的风险BI平台；

③ 通过对申请数据的分析，锚定实际客群的特征；

做这几件事情的目的只有一个，即能够在最短的时间捕捉到客群的风险趋势，做出最快的响应。

这个阶段团队需要具有的能力除了第一阶段的几个外，还需要几个新技能，包括：

① 使用SQL或python或R或SAS从数据库、文本文件中提取想要的数据进行分析的能力，此处的要求至少有类似的数据分析经验，当然，代码能力超强的除外；

② 知道此类数据库的设计，因为做分析的数据库结构，跟做业务用的数据库结构是不太一样的，所以，经验要求至少是在一个成熟的企业做类似的事情。

③ 知道如何设计常规的风险监控报表，这个一般也是要求至少在个人零售信贷领域制定过风险策略的经验；

④ 知道如何设计海量指标的监测的报表和将风险监控数据转化为分析需求的能力，这个要求相对较高，大概就是把上面三个技能的要求加在一起；

⑤ 出色的文档和日志能力，前期策略变化可能会比较频繁，如果不把变化一一记录下来，后面出现问题将无处可查。

3.小有积累 ：打补丁

经历了前期的大起大落，这时已经积累了“具有统计意义的”数据了，这个阶段的主要任务如下：

① 不断做案例分析，积累经验。

做案例分析时，很多人看到所谓的“坏”样本，某种行为发生的频率很高，就断定一个很好的指标。

但其实这才是案例分析的第一步，当发现一个符合“好指标”定义指标后，一定要把它放在你的好客户里，看看是不是也是这样，如果是，那就说明也许只是客群特征而不是“坏客户”特征。

如果不是，那么恭喜，确实“可能”找到了一个很好的指标。

② 尝试做模型。

在这种情况下，由于在中前期的数据量的问题，不是特别推荐使用机器学习算法进行建模，尤其是使用默认参数的机器学习模型，更推荐使用相对传统的评分卡模型或逻辑回归模型，毕竟这些模型是小透明，风险相对可控。

③ 建立一套模型监控和迭代的系统。

由于数据量小，模型的稳定性非常容易受到客群变化的影响，一套行之有效的模型监控和迭代流程是很有必要的。

由于模型不是那种“一出场就稳了”的科技，因此，把指标监控和案例分析及配套的策略管理做好，是非常重要的。

4.日积月累：筑城墙

通过不断的业务积累，对于企业来讲已经获得了下面几样非常宝贵的东西，尤其是第一个：

三、如何“谨慎的”进行数据评估？

不管是引入一个外部评分还是企业内部研发了一个新的内部评分，基于这个新评分制定相应的策略、再到新策略的上线是一个非常漫长、复杂和涉及多部门协作的过程。

但作为一个一线的模型人员或者数据测试人员来说，后面这个过程的变数很大，时间和人力成本很高，不可能每评估一个模型都把全流程走一遍；

另一个方面，如前面强调的，那些数学指标更多的是参考价值，毕竟数学和业务中间还是有一段距离。

那么，是否有什么简易的方法相对合理，又比较快速的评估模型的效能是非常重要的。

下面是一个相对完整的评估流程，一个相对来说较完整的流程包括如下三大模块：

预评估；

测试评估；

运营监控

1.预评估

这个阶段的主要任务是通过历史数据的分析、数据测试（如果引入外部测试数据的话）对新的模型（数据字段）、策略进行预先评估。

这个阶段完全是由分析师在线下完成，不涉及到任何生产环境。

这个模块主要按照顺序完成以下几项工作：

2.对数据进行测试

现在所有金融机构在测试外部机构的数据测试时都会做外部测试，但方法都不太一样，个人认为做数据测试时主要考察两方面：

a.真实性测试

也就是说我们要准备一些样本，我们是能够完全了解真实情况的人，因此，这个样本不会太多，但这个测试能给我们一个对数据直观的了解；

b.回溯测试

做回溯测试的主要目的是要拿有足够还款表现的账户作为测试样本，要求数据提供方将数据回溯到样本真实的申请时间去匹配数据。

回溯的重要性我就不过多强调了，很多公司提供的评分或黑名单产品由于在测试时没有回溯。

或仅仅是号称回溯却没有回溯，在测试时可以得到很高的KS，但是将模型或评分应用到真实的业务中时却差强人意。

如果说是一个新的内部评分，我们也一定要将这个新的评分，放到一个有足够还款表现的样本上，用当时的数据进行打分，这个过程就叫做Backward。

为什么一定要进行数据回溯？

不管是做策略分析，还是做评分模型，都有一个假设和一个前提。

一个假设：

用户行为在时间维度上是保持相对稳定的，这个假设保证了用历史数据做分析，得到的结论是在我们应用策略和做模型时还能适用。

一个前提：

在应用策略和模型时，都是在用截止到应用时间点能够获得的所有信息，这时是无法得知关于未来任何确定的信息的。

所以，我们需要研究的是“历史加现状和未来的关系”。

从上面的假设和前提，就知道在做分析、数据测试时，就要保证这个前提。

通常我们测试时，都会采取那些已知还款表现的样本，比如，这些样本都是在2017年1月通过测试的，如果在测试和分析时，我们把2017年2月之后的数据剔除掉。

那么，通过分析得到的结论其实是“未来和未来的关系。”而不是符合应用场景的“历史加现状和未来的关系”。

我们把观察用户表现的那个时间段叫表现窗（performance window），把在审批时用来决定审批结果获取数据的那个时间窗口叫观察窗（observation window）。

因此，表现窗和观察窗是绝对不可能重合的，如果说再做分析提取数据和做测试数据时，如果不作回溯的话，那么，其实用表现窗的数据去分析表现窗的数据，这样得到的结论是有很大偏差的。

① 评估数据效能（如果涉及到新的数据字段或评分）

在这一步骤中，根据回溯测试的数据，对数据字段或评分进行评估。

如果不是评分，而是一个数据字段，我们完全可以把这个数据字段看作一个自由度比较低的评分。

然后，我们就可以直接应用我之前的速算评估公式来进行判断了。

通过数据效能评估，我们可以大概知道这个数据或模型能否满足我们的基本需求，是否值得我们花精力去开发响应的规则策略而产生额外的数据购买成本。

② 模型与策略开发

如果数据字段的区分能力已经可以直接用到规则中，那么，这时可以直接通过数据表现来确定阈值，将该字段放入规则中。

如果数据字段的区分能力不足以直接进入规则，那么，就需要开发一个新的模型，将这个字段引入已有的A卡或B卡中，然后再将新的模型引入规则。

对新策略进行盈利分析。

根据新的字段或模型研发出的审核策略，除了在开发流程中要考虑的通过率和逾期率的影响以外，还应该全面的评估新策略对于审核成本，获客成本，客户体验，对坏账的影响等等。

考虑的因素基本就可以参照我的速算公式，但是在进行财务预测的时候要更加的严谨，各项参数还要考虑到未来的变化。

③ 测试评估

经过了一个完整的预测评估流程，说明经过历史数据的评估，已经证明将要上线的数据、模型、策略是有价值的。

同时，之前的评估都是由数据部门或风险部门的分析师完成的，还未涉及到系统的开发对接。

测试评估主要分为两个阶段：

a 模拟上线阶段

通过系统对接、开发、测试，那么，新模型和策略已经在系统中等待调用了。

但从谨慎角度看，这并不能直接将相关策略应用在真实的用户上，很多同学都知道要做冠军挑战者的测试，但从测试完整性和谨慎的角度，模拟上线测试是要先进行的。

模拟线上测试其实是将新策略在真实的业务环境中运行一段时间，记录相关结果，但运行哦不影响真实的业务运行。模拟测试中要注意两点：

b 冠军挑战者测试

通过模拟上线测试下一步，就要开始将一小部分真实的用户切换到新的策略中了，将现有的规则（冠军）和新规则（挑战者）进行比较；

同时，冠军挑战者测试并不是一次性的，而是一个动态的过程。

应该根据测试的结果，不断调整冠军和挑战者的用户比例，根据产品的用户规模，这个动态的过程可快可慢，但总的方向是不断扩大挑战者测试的用户规模。

通过了冠军挑战者测试，就可以将现有策略淘汰了，但并不是数据评估的过程就结束了，下面就要开始第三个模块了。

3.运营监控

在新的模型、策略规则完全上线后，并不意味着可以当甩手掌柜了，因为运营监控是一个长期且没有止境的过程，直到这个新模型“退休”。

运营监控需要做如下几项工作：

第三方数据源的稳定性。包括查得率，字段数据分布等。

模型和策略的后端的稳定性。包括模型各项数据指标的稳定性；各个规则的漏斗率。

举个例子：

数据风控那点事

这是某个指标连续14天的变化趋势，往返上升或下降，通常在第14个点会触发我们的监控规则。

如上面三个方面的稳定性发生明显偏差时，就需要采取相应对策了，对数据源、策略、模型进行调整。

大数据风控是Fintech中的一项跟我们行业息息相关的技术，因为它能显著提高企业的生产率和盈利能力，能为客户提供更好的服务体验。

我们要把金融科技风控能力赋能合作伙伴，进行全流程的金融科技转型需要的不仅仅是技术。

万事开头难，如果各位有志青年想进入这个行业时，顺势而为，有兴趣的好好学数学，做做模型风控。希望行业越来越好，大家越来越好！

数据风控那点事

ZRobot是由数字科技公司京东金融成立的金融科技公司。

基于高维度变量，结合丰富的应用场景，利用数据挖掘和机器学习等专业技术，致力于构建大数据背景下的信用生态体系。

作为京东金融旗下智能数据技术服务商，以大数据和灵活完善的风控模型为基础，实时评估业务风险，为银行、消费金融公司、汽车金融等金融机构提供智能化风控管理解决方案，提升企业整体风控能力。

*文章为讲者独立观点，不代表笔记侠立场。