风控建模：催收评分卡（四）--变量整理除了跟数据获取相关外还跟什么有关系？

  之前被一篇叫《你有什么资格嘲笑毛坦厂中学的学生》的文章刷屏，中国的阶级固化的趋势在可预见的未来会越来越严重，底层的人来苦苦挣扎，中产在整天焦虑，中国的太大，我们自以为的大学生是白菜价，现状在底层的考生那里还是难得一求的一张门票，无奈的现状除了每个阶层都付出非常大的努力外，还有其他办法能改变吗？大家感兴趣可以读读。

  记得我在做数据入门前，就有一个前辈跟我说，数据领域，特别是在我国的数据领域，很多数据你都只能智取，不能强夺，切记切记。那个时候，懵懂的我，还不知道这个是什么鬼理论。现在的我，经过多年的沉淀，慢慢地懂了里面的真谛，把所有做数据的人的苦逼简单粗暴的写一下吧。

  先贴点干货的图片，引出我需要阐述的主题。

  催收评分的变量整理是过程，是在业务定义后的第二个非常重要需要完成的部分，这个过程你大概是需要理清楚自己家究竟有什么数据，也就是需要知道自家的数据有哪些库存，前期先整理出一版合适的数据汇总结果：

  对于一些常见的指标比如PTP、KPTP这些，相信都是有的。但是这里重要但非常用的指标，在标准化的体系的数据库中有，但是不一定能获取到，即使获取到，你也需要再结合具体的业务做一次变量输出。

  我们在介绍过程中，先从简单到复杂，一层一层来剥离来看，会发现很多有意思的问题跟业务逻辑：

首先介绍客户档案里的数据：
房产情况—
  介绍房产情况这个变量，这个变量主要是甄别客户的固有资产情况的。你可能会说，这个变量有多复杂，不就是看客户名下有房没房就行了吗？没错，表面是这样，但是还不仅如此。如果还不明白，可能是你对整个数据层面里的业务逻辑还没吃透。

  试问：客户A名下虽无房，但是却有3套房贷记录？能不能算他有房？也许这种情况还算较易分析。有可能是A可能房产已经过户，只能算有过房产。

  但另一种情况：客户B名下无房，但是家庭名下有房，这种情况，能不能算有房的情况？如果再复杂点，客户已经离婚了，房产名下之前是双方共有，但是你在处理数据的时候，发现客户是离异状态，房产却在夫妻共同名下，此时你判断客户是有房还是没房？

  我记得当时单单在处理这个变量的时候，最后输出的规则一共是二十行代码去判断客户的房产状态。没错，实际的业务形态就是这样，然而比这复杂的更多的是系统层面的问题。

其次催收库里的数据：
1.contact的次数
  联系次数也算是比较有用的数据了。但是有些公司因为历史问题，一般也会在客户还款日到来之前给客户打温馨提醒电话，提醒还款。这时就会出现跟催收电话叠加的数据。

  试想没逾期的客户也同样地被催收系统拨叫，此时的数据在后台处理时候肯定会有所失真，而且最重要的两者如果没有做标识，根本就没法区分。

  现在知道，做的比较好，至少在后台是有标签可以区分这两类数据的。但是很遗憾，我还是看到很多公司是人工标识的还没做到自动化处理的程度。而且，有些像上面提到的打标签的事情也没做。

2.有效联系人的数量
  对于拨打处于M2的客户，越往上失联的客户的概率会越大，这个时候可能联系上客户的有效联系人的就只有亲戚或者朋友了。

  其实这时，在联系人上的做区分，如果能稍微精准写区分下客户本人，父母（直系亲属），兄弟（嫡系亲属），或者好友，策略或者模型的部门估计是无限欢迎的，但是对于这些精准区分的数据前期的业务整理当然是比较累。前期业务部门吐槽，做着做着，越来越没动力，数据就越做越变形了。到了最后，会发现，这个变量成为了无用的垃圾变量。自动化重复性的东西，最好还是交给机器去做。

  但是现阶段，有些公司是连是否客户本人或者非本人都没有区分的，都没做到。对于这样的数据区分度，有时候真的让人抓急。

3.合同的数量
  最后说下合同情况这个变量。合同情况，如果一些客户，只在我们公司贷过一次款的，那很好讲，合同情况只为1个。

  然而随着公司业务的扩张，对于前期优质的客户，常常会选择让客户尝试续贷或者再贷业务。如果客户同意，，这时合同的资料就会上传到另一个系统上去。新系统是为了续贷或者再贷业务开发的新产品。当这两个新旧系统接口没有打开的时候，会发现新旧系统完全是个割裂的板块，你要通过客户的身份证号码关联合同信息，对不起，臣妾做不到。再一次风控被IT击败。

  现实生活中，都是这样，我们想取的数，总是无法获取。我们总是想获取客户的收入能力，对于这样的指标，我们总是不停得去计算客户每个月的银行流水判断等等。

  最后提个问题：为什么在系统中，总有变量是业务需要，而无法获取的事情。其实最大的难点除了数据的获取外，必须从负责信贷的系统说起来。

信贷系统，主要分几大系统：
  核心系统：存储客户的账务信息，还款计划，还款流水等；完成客户开户、放款、冻结额度等操作。
  客户端系统：客户在使用终端的一些交互内容，与后台逻辑；将对应的数据存储。
  数据计算平台：满足风控实时审批过程中需要变量的实时计算，对接业务范围内审批需要的内部系统数据。
  征信平台：统一对接所有外部数据源，进行统一管理；满足审批过程中的灵活调用。
  审批系统：组织所有风控吸配合完成审批；告知核心客户与放款。
  资管系统;匹配开户资金方与放款时资金方的选择；P2P模式中单个资产的撮合。
  服务端系统：客户在终端上操作的行为与数据的留存；与风控系统交互。
  决策引擎：承接风控策略的部署；出具审批的决策建议。
  反欺诈系统：主要做关系网络的生成与衍生变量的计算；定义网络中节点的黑白。

  我改天会找个专门的专题，介绍信贷部门里的各个系统的模块。

  十年职场生涯，这个长期混迹在风控界和科技界，摸爬滚打的大叔，曾经就职于全国最大的固网运营商平台、国内最大的ERP软件公司和一家老牌的互金公司，如果你想了解他，欢迎加入" 番茄风控大数据"一起学习一起聊！

标签：变量,系统,建模,风控,催收,获取,客户,数据
来源： https://blog.csdn.net/weixin_45545159/article/details/100065899