本文档来自“支付产品技术交流群”在2017年6月16日的讨论，以及6月17日的专题分享。

专题分享：信用评分模型

1.1、信用评分模型开发背景

传统信贷审批采取信审人员人工作业形式，审批依据是审批政策、客户提供的资料及审批人员的个人经验进行审批判断，该方式存在以下问题：

  1. 信审人员对申请人所提交申请资料真实性的认定基本依赖于受理申请资料的基层网点业务营销人员的职业操守和业务素质，审批人员对申请人资料的核实手段基本依赖于电核，对申请核准与否基本依赖于自己的信审业务经验，授信审查成本高、效率低而又面临很大的欺诈风险，这种状况很难应对大规模的业务需要。
  2. 审批决策容易受主观因素影响、审批结果不一致，审批政策调控能力相对薄弱。
  3. 不利于量化风险级别，无法进行风险分级管理，影响风险控制的能力及灵活度，难以在风险与市场之间寻求合适的平衡点。
  4. 审批效率有较大提升空间。

1.2、信用评分模型初创人

为有效改善传统信贷的授信审批方式，FICO等公司发明了信用评分模型。

1.3、信用评分模型定义及分类

1、定义
信用评分模型，又叫信用评分卡，是运用先进的数据挖掘技术和统计分析方法，对目标客户和现有客户的信用历史记录和行为特征进行系统的分析，以发掘符合自身市场目标的客户和预测其未来的信用表现。

2、分类

  1. 根据评价主体不同信用评分模型可分为个人信用评分卡和企业信用评分卡。
  2. 根据适用的业务类型不同信用评分模型又分为经营信贷评分卡、消费信贷评分卡。
  3. 根据适用的业务流程不同信用评分模型又分为申请信用评分卡、贷后（行为）信用评分卡、催收信用评分卡。
    以上三种评分卡业内分别称作A卡、B卡、C卡。

1.4、信用评分模型开发通用流程

1、梳理业务逻辑并定义好坏客户
这一步跟大多数教材不太一致，但个人认为这是最关键的一步，鼓励有不同见解。
在实际的模型开发中，负责模型开发的同学往往没有多少信贷业务或风控经验，对管理层在信贷业务规划上的认识也可能存在偏差。所以在该阶段需要充分与管理层、产品、政策、业务、风控，甚至贷后和催收进行沟通梳理，了解他们从自身视角对于业务逻辑和风险管理的看法以及对评分模型的需求。
该步骤对于模型检验而言也是一个基础，模型的需求方就是该阶段的沟通对象，模型到底好不好他们有绝对的发言权。
沟通完成之后结合管理层的风险偏好，就可以进行定义好坏客户了。所谓定义好坏客户就是确认一个标准。比如是否逾期就是一个标准，只要逾期了（>=1次）就是坏客户，没有逾期就是好客户。也有以是否累计逾期三次作为定义标准，具体怎么定义得根据管理层的风险偏好决定，或者是经营策略决定。

2、根据业务逻辑选取数据源出业务宽表

ID 年龄 性别 婚姻 收入 支出 资产 负债 职业 住房 历史逾期 逾期次数 逾期金额 是否涉诉 … 是否逾期
1 23 男 未婚 3000 1200 1500 1000 收银员 租房 是 1 100 否 … 1
2 34 女 已婚 50000 - - - 老师 按揭 否 0 0 是 … 0
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
10000 55 男 离异 60000 50000 1 医生 自有 否 0 0 是 … 0  

3、数据缺失异常预处理和数据探索
通常业务数据宽表会存在缺失、异常等问题，该问题需要优先处理；
预处理后，通常会进行众数、中位数、100位分布、变量P值、相关性检验，通过以上检验识别出辨识度高、相关性低的变量用于建模；

4、模型选择和建模
所谓的模型根据公司实际业务开展阶段不同，选择的模型也各不相同。
如果是一家刚起步的信贷公司，则通常会选择——专家打分+层次分析法；
如果是已经有上万笔实际放款的信贷公司，则通常会选择——逻辑回归、决策树、神经网络等算法进行建模，这三种算法通常适用最终变量控制在20个以内的情况；
目前，也出现像随机森林等新的算法应用到建模，通常适用最终变量控制在50个以内的情况；

5、模型检验和修正

1.5、信用评分模型开发工具篇###

二、Q&A

Q: 关于数据源怎么获取？
A：大家都在从事金融类工作，所以应该不会太陌生，这些数据通常会通过用户提交直接爬虫抓取或者向第三方征信数据公司购买 或者与银行合作获取，另外目前移动端应用程序比较火，所以还有直接通过APP采集的方式来获取，如通讯录、通话清单、短信、APP安装列表等。

Q: 数据缺失异常预处理和数据探索这一部分内容较少，可否详细说明以下？
A：这部分写的比较简单，实际数据探索会很耗时间，主要目的就是为了选取辨识度高的变量，舍弃常规判断都觉得表现不明显的变量

Q：模型选择和建模中目前使用最多的算法是什么？建模的原理能否详细说明一下？
A：目前使用最多的算法是逻辑回归，该算法表现稳定，历史也最悠久，逻辑回归有一个最大的有点就是就是适用于二值逻辑，关于业内贝叶斯算法几乎没有应用过。建模的原理跟函数一样，通过一些因变量得到自变量

Q：关于常用的数理检验部分可否做一个详细说明？或者需要用到什么工具？哪些工具最常用
A：这些检验其实就是一个衡量标准，举个例子：KS检验至少应该超过0.3，如果模型通过这些检验 则可以提交给所有需求方进行检验，举个例子：如果模型中的变量中有年龄这个变量，模型如果认为年龄越小越不容易违约，这显然与风控常识不一致，说明模型有误，类似的常识性的东西就需要各个需求方去验证，避免模型通过了数理检验而与实际脱节的情况，如果模型未通过两类检验则需要重新来过。正态分布、P值、T、F检验通过SAS工具模型完成后会自动实现，交换曲线、KS、基尼、AR通常也需要用工具来辅助进行计算。对于建模工具，建议在初期哪个顺手就用哪个，能把有效的模型做出来才是Key Point，目前我用的是SAS9.4，后面的课程我也会用SAS给大家分享。

Q：提到的模型检验，是不是可以认为是一种模型的训练过程？利用历史数据对模型进行训练？
A：其实建模是训练，检验是对拟合程度的检验，检验这部分需要在实际操作中给大家讲，才能更明白。

Q：公司主业是多信贷风控服务，不管哪类（企业经营、消费信贷），风控模型都是LR的评分卡（每个信贷模型都至少是几百个变量）。反馈下来：反馈LR容易解释，且评分卡这套模型已经经过N多个机构的M个信贷周期的校验。
A：模型确实是需要完整的信贷周期进行检验的 多个机构就不一定了 因为每个机构的目标客户和风险偏好不一致

Q：一般模型确认后，经过一段时间后需要修正，这个修正周期建议是多少？是否有必要更多的模型参数进来？
A：模型的修正通常有两种维度需要考量，一个是新增业务量适中的数量要求在1万条左右，另外一个是信贷周期，通常最短的周期是新模型上线后开始形成坏账这个周期。关于模型参数的个数确认，有两种方式：一种是经过探索后保留尽可能多的变量，然後在建模时不启用best这个参数，这个参数是认为限制进入模型的参数个数的；另外一种就是启用best，但把值在原个数上放大。

Q： 敦煌都是自营的，还是有其他商家？模型是不是用来评估买家信用的？
A： 敦煌网是一个跨境电商平台, 目前敦煌网对商户的评级没有用评分卡 评分卡用在自营信贷产品。

Q： 变量越多，体系越完善吗？
A：不一定，变量太多就有可能太过复杂，不一定是往好的方向

Q：想更多的参数进模型，有没有其它方法？
A：有一种分层的方法，这种通常用在企业模型里，有点类似芝麻信用的五个维度，每个维度下面若干变量，这样就有点像平衡记分卡的模式，可以避免某一个维度导致整体的偏差，不过这个对于数据量的要求比较高，估计也就几个大企业能做得到。

Q：关于地址拆分模型可以详细说明一下不？
A：也就是把个人的地址按照省市、地区、小区、道路进行记录，从而建立的模型进行评分，比如信用卡反欺诈系统，主要是应用于信用卡申请的审批，目前很多银行能够做到秒批，就是依赖这个评分模型。另外模型内部还细分高危地区：比如福建、河南等是欺诈的高危区，一般打分会调低，不过目前只有银行和少量大型的互金公司才有这个实力做到特别细化。

Q：目前有没有免费的数据源获取途径？
A：有的，比如最高法院的失信被执行人信息，通常可用爬虫对这些数据源进行抓取。

Q：关于信用评分方面有没有不错的书籍可以推荐一下？
A：有的，比如《信贷风险管理》，是工行首席风险官写的，本书系统地总结了转型期间我国商业银行信贷风险管理的具体实践，同时紧密跟踪国外活跃银行风险管理的发展趋势，在进行历史梳理和横向比较中深入分析信贷风险管理的各个风险点。 还有宜信编写的《小额信贷》，内容很全适合入门。

《信贷风险管理》出版社:中国金融出版社;第1版(2008年10月1日)
《小额信贷》作者:宜信，北京联办财经研究院编著，出版社:中信出版社出版时间:2014年11月。

Q：信用、风控的核心怎么说？如何做好互联网信贷？
A：风控、信用这方面不能说的太细，其实核心就是依据用户的行为数据或客户模型得到的一个评分，关键点还是风险识别，除了依赖丰富的数据，还要合理的模型去客观的评估，比如对于我们的信贷，重点是团伙欺诈，重点就是各个个体的共性识别上。
互联网信贷，欺诈风险高于信用风险，银行的信用欺诈还好点，可以选择报警，互联网信贷就比较难处理了，成本也较高，只能随着欺诈手段的进步，不断完善系统，并能通过各维度数据发现这些问题，如此就要求公司必须加强这方面的深度学习了。

Q：对于一个公司来说，怎么样来平衡风控与业务的发展
A：怎么来平衡，太严了就进不来人，太松了风险就太大了，过滤掉的究竟有没有价值，还得公司根据自己的承受能力来制定。

三、自由讨论

1、关于项目外包团队人员配置问题的讨论

Q：对于纯外包的研发团队，自住研发人员不到15%的情况下，自住研发从那一块切入比较好一点，我考虑是服务接口层，把服务封装住

A1：15%，包括管理人员吗？这个比例，研发同学能够把概要设计做好就非常不错了。

A2：架构是核心，这个必须完全把控，接口还好点，关键是业务逻辑

A3：整体基调是逐步全部自开发？还是以后也是一直依赖外包？这个很重要。

A4：对于你们这种研发主要靠外包的情况，行方人员要切入我个人觉得，主要还是从:需求分析，架构设计，方案设计，方案决策，项目计划管理，代码质量和测试管理，版本管理，投产组织和生产运维这些维度去把控好。至于代码开发和测试这些具体工作，只能交给他们来做。可能我说得范围很大，但是这些都是整个项目过程中至关重要的。

A5：研发人员的比例也太低了，完全是甲方模式。

A6：我公司正在经历外包为主过渡到内勤主导外包辅助的阶段。要几个关键的内勤人员到位是很重要的。否则就会被牵着鼻子走。

2. 某行外包团队配置讨论及说明

人员配置方案：从我们现在做的统一支付平台项目来看，我们行方全职的5，6个左右。

  1. 一个总负责（10+年支付系统经验）:需求的分析和总体方向管控。
  2. 2个技术经理（10+年核心+支付设计开发经验）:负责制定编码规范，测试规范，方案设计，问题决策，测试缺陷跟进分析，性能测试跟进，投产演练组织，投产计划工作安排。
  3. 1个项目管理人员（15+年项目经验）做计划管理和督办。
  4. 1个（10+年核心经验）做投产演练和投产工作

具体实施

  1. 今年整个平台，上半年接: 二代支付大小额，XXX省金服（同城支付）。
  2. 今年下半年接：网联清算平台，超级网银同构，银联代付，银联无卡快捷支付，XX同城票据交换系统。

还是很多东西顾不上来。技术经理要承担的工作太多~也要做需求分析，接口也得一起设计。多数银行自主研发实力不强，其实我们行就不强，多数行方做的是经办管理协调，左手交右手的工作。

你这5个人 不夸张的说 已经可以抵掉别人一个二十人的团队了。真的达到上面描述的要求，一年费用2-3百万是肯定要的。

Q：银行选择外包团队的原因

A1：多数银行技术是外包的，人头的限制，企业性质的原因

A2：很多银行和群里绝大多数的支付公司比起来，我觉得自主研发实力差的很多，因为基本靠外包。

A3：外包的好处在于可以随叫随停 不符合需求可以扣钱

A4：外包自主研发都有好处，外包起码保证能接触业界新技术，银行的思维不是互联网思维，倒不是技术能力的问题

Q：外包团队不足或有风险的地方

A1：外包技术方面很多不行

A2：外包人员都是干完这个项目，不知道下一个项目在哪里的，外包人员的心态在甲方的不太一样

A3：位置不同，心境不同

A4：外包还是得看公司，绝大多数外包公司在新人培训这块没做好，基本代码规范，单元测试规范，一些设计理念都不不教。

A5: 大部分外包公司没有核心产品，核心产品就是外包人员，压低外包人员收入，外包人员的流动性大，质量不好。有核心框架、核心技术的，会店大欺客，牵着你走, 外包人员里技术比较好的，都是冲着能转到甲方的目标去的

Q：项目外包是否合适？存在哪些风险

A1：人力外包可行，项目外包不建议

A2：项目外包不建议，会涉及到核心数据安全问题

A3: 不是自主研发的，面临很多风险。之前呆过的某股份制银行，客户的数据是可以流转到外包哪里的…

Q：小规模城商行项目技术问题的处理方法 A：有一些小点的城商行，技术长期处于不够用的状态，有很多都是从外包挖人的

Q：关于外包源讯公司

A：我们信用卡核心整个项目外包给源训公司，源训的卡核心占了国内绝大部分银行信用卡核心系统的份额。现在一个普通人力一个月要7,8万~源训是垄断性的公司，建行，招行，中信等等信用卡核心都是用他们的产品，有AS400，也有ibm大型机上的

Q：XXX银行业务50个系统的团队配置情况：纯技术经理就6个人，其余测试运维不算

A1：有时候挺佩服你们的 几个人都可以搞那么多系统 而且都是非常核心的系统 我们之前做聚合支付 虽然研发人员有项目共用 但是单单后端JAVA 我印象中就有 4个 不算测试 不算前段 不算移动端

A2：我在XX总行时候，一个项目怎么也要10个月啊，新一代光核心架构设计就做了2年。民营银行节奏太快，业务等不起

A3： EXCEL里面的 每个系统 在我之前的公司 随便一个最少都要几个月开发，而且要上线都是要反复测试的

A4：后面再换，我想法是服务封装把厂商的服务封一层，封的这层我们自己做，确保可以随时换产品

Q：为什么大银行的项目周期都比较长

A：用户基数和资产规模不一样的结果吧，还有历史包袱…大行的历史包袱太大了，民营银行都是最近几年才成立的，毫无历史包袱

Q：银行系统、支付系统相关系统内容趋同

A1：银行同质化太严重了。。因为用的都是同一批厂商同一批产品。

A2：银行的业务都差不多吧？ 里面的系统能不能产品化？ 或者半产品化 除基础组件外 再对常见业务做一个半成品的抽象层（只涉及到结构和流程） 实施的时候再实现具体业务细节

3、卡片闪付安全问题

Q：关于卡片的闪付功能，小额免密的，如果有人拿个设备区人多的地方偷偷扫，会不会偷到很多钱？

A1：之前交通卡有人这么干过

A2：假pos不能请款，真pos能直接抓人

A3：去年就有人这么干，微信中流传了小视频（小视频流传的场景是，现在很多ETC卡支持小额免密，车主如果不取车上的银行卡，拿个pos机隔着玻璃就可以扣款成功，车主如果不主动查询，根本不知道被盗刷）

Q：那玩意不是接触过程会有声响的吗 还是说可以调静音

A1：但是手持pos可以没有声音的，但是每个pos机具都有记录的 结算的时候有问题 不给钱那不是很尴尬

A2：手持的能感应距离比那种大台的机器感应距离要短吧

A3：用户根本发现不了，小额也没有人在意

A4：感应距离可以调整的，不是说银联的机具能够强大到35cm么，和频率有关的，公交车载机具是为了防止重复扣款，所以都是把感应距离放到3-5cm。这个和卡也有关系

A5：硬件这块接触的很少，之前就见过公司的收银台智能pos 反正看起来是很麻烦的东西 A6：非接读取距离，理论值是1-10cm，常见的最大距离在5-7cm左右

Q：关于银联云闪付盗刷赔付

A：银联联合银行，对于联机闪付盗刷，的确是会赔付，但好像有额度限制吧

Q：云闪付如何防盗刷？

A1：如果查肯定知道转给谁了 这种偷不成立 相当于入室盗窃先验证个身份

A2：对。毕竟单笔客户也有300的限制，一年一万的赔付额度限制也比较合理。一年如果被盗刷30次以上的话，那就可疑了。

A3：关键看被盗刷用户是否能及时知情，理论上只要是正规pos就可以了，但银联好像是有相关风控机制的，商户白名单、卡种卡片分步纳入（信用卡优先）等等。A4：有意外风险 次数多的就嫌疑 所以银联再通过赔付来对冲这种风险

4、云闪付的应用场景及发展情况讨论

Q：云闪付应用场景

A1：广州地铁支持银联卡，ODA方案，算是云闪付的场景化应用了，这种方案简单点说，就是只验卡片真伪，不验持卡人是否匹配。

A2：云闪付的载体介质，可以是手机，不一定是卡片，比如说各种pay，apple pay不久后估计要上线，某一线城市地铁

Q：云闪付的产生背景及实现方案

A1：云闪付产品，是两大巨头二维码支付大行其道之时，为抗衡二维码而推出，当时银联的线下支付体验相去甚远，非接的脱机闪付体验巨坑

A2：确实便捷性可以抗衡at二维码 对现存卡桩的地方很方便 不要预存了 越来越直接 一个银行账户就可以

A3：以前的线下脱机闪付，需要预先圈存到电子现金账户，现在升级到联机闪付，直接从主账户扣款，甚至在地铁的ODA方案中，只是实时的脱机验证卡片真伪，异步延时发送交易请求，用于满足地铁的交易场景：没有条件实时联机，以及刷卡效率

Q：公交卡这类的预付卡是否会被云闪付、支付宝这些替代？比如广州的羊城通

A1：这个可能也不好说，公交系统不是通用性市场，其中地方利益纠葛甚重，不是简单的技术或用户体验问题，核心在于商业模式上如何平衡各方利益

A2：应该是 地方利益 只要国家政策不过时都还能继续存在

A3：杭州公交系统全面支持支付宝，也全面接了银联云闪付

A4：支付宝杀入公交系统，大概可以追溯到2011年，到现在也只在大本营有个展示页面，这不是它的主航道。

Q：如何平衡各方利益？

A1：一是就看如何弥补它的损失了，二是现在一般是通过售卖卡片数据补足，以前是卖实体卡片，现在是卖卡片数据

Q：卖卡片数据？公交卡没有用户数据的

A：不是用户数据，就是卡片数据，数据载体可以是公交卡，可以是银联卡，也可以是手机，介质不重要。直接卖数据，还少了生产维护实体卡片的成本

Q：现行的ODA方案有什么高见嘛？

A：银联系能守住的场景，可能真的不多了，公共交通场景上，云闪付比二维码有天然的优势；ODA方案不错，而且已有伦敦地铁成功案例在前，就看银联推动落地的力度，四大一线城市公共交通是刚需，攻下这块阵地，培养用户习惯，反攻尚有可为

Q：云闪付推广现状讨论

A1：银联钱包那app，不知道是谁开发的。更新后重新登录，尼玛绑卡数据全清空了

A2：云闪付的使用率很低

Q：很久很久以前看新闻韩国的公交车可以支持手机刷卡（应该是手机sim卡感应的吧） 不知道现在银联还是谁做到没？

A1：NFC产品家族，有运营商主推的NFC-sim；有银联主推的NFC-sd，还有手机厂商主推的NFC-全手机方案，历史堆里还有sim-pass辫子卡、贴膜卡、全卡等等，百花齐放。最后，被二维 A2：现在主要推全终端的，有一些在用hce的，历史堆里还有sim-pass辫子卡、贴膜卡、全卡等等；百花齐放 hhhhhh 都很鸡肋

5、其他

Q：问下 财务对账跨天的情况 怎么处理？比如差异 存疑的数据怎么处理

A：跨天不跨天一样处理的，之前这个问题讨论了不少了。详见20170526专题讨论整理稿

Q：各位了解的支付系统生产环境 单节点的服务的TPS（QPS） 一般是多少？

A：这个不好说吧，你这个事务数根据业务不同性能也不同

待回复：请问有没有好的安全密码键盘控件厂商推荐，app端 pc端？

本文档来自支付产品技术交流群的聊天记录整理，由志愿者整理并发布到本网站。如需要及时收到来自支付产品技术交流群的最新消息，请扫码关注“凤凰牌老熊”的微信公众号。 本群面向支付行业的有经验（2年以上）的产品经理、软件工程师、架构师等，提供交流平台。如想加入本群，请在本文评论中留言（不公开），说明所在的公司、负责的工作、入群分享的主题和时间。