金融信贷业务-贷前整理

       贷前开通授信是互联网金融信贷业务中是处于一个核心的基础的阶段，解决的最本质的问题就是不同的人和不同资金方的一个匹配定位；金融服务平台要对客户进行充分识别后，推送给不同风险偏好的资金方；平台对客户的识别能力直接影响到客户再资金通道的实际转化率；

       当下各互联网公司因为在其相关业务领域（如电商、OTA、外卖等）内积累了大量的客户资源，已经拥有了大量客户特征、行为数据，所以在获取、识别客户上有相当的成本优势；不必完全依赖用户大量资质证明信息（学历、公积金等）的提供和外部信用评级机构（聚信立、数美、芝麻信用等）的评定；

1、金融平台客群评级策略

       综上，基于用户识别的能力成本高低的考量，通常我们会将开通授信申请用户做客群优劣分级后，再路由到不同资金方；金融平台按识别方式、识别能力的不同，为客户划定不同的优劣评级、预审批通道额度、利率定价；例如：

       内部数据识别A\B级用户平台成本相对较低、额度相对较高、利率相对较低，外部识别用户C/D级用户需要支付评级机构费用，成本相对较高、额度相对较低、利率较高，平台充分识别用户后就能够根据各资金方不同的风险偏好进行路由推客；

2、金融平台客群路由策略

      按资金方不同的风险偏好，推送不同比例（按照相关匹配模型演算而来）风险级别的客群给资金通道,资金通道一般是按优先级别排序的一个通道列表，防止因为某家通道拒绝，用户流失；如下：

3、金融平台资金通道变更

        当金融平台经常会碰到某家合作资金方强制终止合作时，不得不进行补发起授信切换资金方的操作；

        当金融平台经常会碰到某家合作资金方合同到期的情况时，不得不进行合同展期续约的操作；

        当金融平台想要为用户变更额度的时候，也有可能需要切换备用通道，或补发起授信；

4、金融平台业务技术方案实践

（1）、业务方案设计考量

   经验总结任何业务场景，在做方案考量设计的时候无外乎在以下几点作文章：

• 业务流程适合的设计模式、领域模型方便业务扩展；
• 业务流程是否涉及复杂、繁琐的业务规则和状态流转，需要引入规则引擎、状态机 使业务流程更清晰；
• 异步化的几种方式选择，多线程、redis队列、eventBus、mq消息等技术做性能优化；
• 业务流程是否是否存在存储性能的瓶颈，需要缓存、DB做存储性能优化；（redis、mysql分库表、ElasticSearch等）
• 对于高并发请求，如何做好分布式锁，限流&降级等考量；
• 监控、报警相关；

（2）、金融贷前业务分析

   核心流程如下图所示：

• 授信准入前置规则拦截：各信贷产品（指定资金通道）、各资金通道（对身份证、职业、人脸、联系人、人行授权、冻结期、开关、白名单、速率限制、发起总数等）准入条件规则多变，业务系统通常在新接入资金通道或修改、增加业务时需要频繁变更规则；为了降低准入规则接入成本，我们可以引入规则引擎做各业务产品，资金通道准入过滤规则的实现；
• 客群识别（风险模型）：风险系统依据不同的风险相关用户指标训练的大数据模型，对用户风险做内部评级；同时对用户可发起授信资金通道做风险过滤，赋能通道建议额度、建议利率，给出用户与通道匹配度优先顺序；
• 客群路由（宏观调控）：充分识别客户后，对客户可发起授信的资金通道，金融平台可以做宏观调控；避免资金方资金不足、成本太大等问题，造成资金通道和用户的错配；多家可发起资金通道按优先顺序依次轮询发起申请，最先申请通过的资金通道即为用户唯一可用资金通道；为避免用户在一家资金通道审批停留太长时间，严格控制资金通道的审批时间（小于24小时）；
• 用户合同创建：用户授信申请进入金融平台，金融平台为用户创建平台合同；再经金融网关发往资金通道，将资金方最终审批通过结果异步通知到金融平台，金融平台创建用户和资金通道的有效合同；同时通知业务方用户开通申请成功；

（3）、业务规则引擎设计

技术选型背景：

        当前金融贷前业务主要工作集中在资金通道的接入和产品模式的接入（各种贷款衍生产品）；无非就是两种情况：一种是信贷产品领域模型的变更，还有一种是规则的变更。可以说，支撑上层业务，业务规则占了需求的半边天。基于业务需要，希望能建立规则引擎，将规则代码从业务中抽离出来，降低规则迭代成本，降低if else等的规则嵌套，增强代码的维护性和复用性。开发人员不用过多的关注逻辑判断，可以专注与逻辑处理。

技术什么是规则引擎：

规则引擎是一种嵌入在应用程序中的组件，实现了将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。接受数据输入，解释业务规则，并根据业务规则做出业务决策。

规则本质上是一个函数，如y=f(x1,x2,..,xn)

规则引擎由三部分：

• 事实（Fact）：就是用户输入的已经事实，可以理解为推理前的已知对象。
• LHS(Left Hand Side)：可以理解为规则执行需要满足的条件。
• RHS(Right Hand Sike)：可以理解为规则执行后的返回对象。

两个重要模块：

• 规则管理：可以理解为逻辑上管理规则，主要涉及规则、事实对象和规则集三个实体。涉及到规则变更时，最好对规则加个版本，可通过规则版本控制，可以平滑灰度地方式改变规则，也便于更有信心在测试规则正确性。
• 规则执行：通过规则库数据，通过规则引擎的规则解析、规则编译将可执行代码缓存起来，避免每次和DB交互，然后每次规则的变更也通过ZK或者DCC实时通知给规则执行器。规则执行器的实现方式，可以多种多样，不依赖于规则库的存储方式，可以根据需求，选用Drools、Aviator等第三方引擎，甚至可以基于ANTLR定制。

• 各类规则引擎对比：https://www.jianshu.com/p/41ea7a43093c
• 规则引擎drools的rete算法：https://cloud.tencent.com/developer/article/1477434

最终方案采用：基于Aviator求值表达式引擎+EasyRules规则框架引擎 相结合的一套适合业务使用的规则引擎；

支持特性：

• Aviator性能高、轻量级；其实现原理与其他轻量级的求值器很不相同，其他groovy|IKExpression这些表达式引擎的求值器一般都是通过解释的方式运行，而Aviator则是直接将表达式编译成Java字节码，交给JVM去执；
• 支持大部分运算操作符，包括算术操作符、关系运算符、逻辑操作符、正则匹配操作符(=~)、三元表达式?: ，并且支持操作符的优先级和括号强制优先级。支持函数调用和自定义函数。能够满足业务需求；
• 在解决了单个规则求值性能的前提下；我们还应考虑 N多事实Fact的动态获取，N多的规则并行&串行、规则的监控、规则的中断&跳过、规则优先级、规则评估后对应的执行的事件等；所以需要一套完整的规则引擎框架去完善；
• EasyRules ：集成了mvel表达式，后续可能集成SpEL的一款轻量，支持注解；它主要包括几个主要的类或接口：Rule,RulesEngine,RuleListener,Facts 后续模块划分详细描述；
• 规则通过情况监控、预警，规则引擎线程性能监控；

整个规则引擎分为规则引擎部分实现，业务系统部分实现；

规则配置模块：

   依托公司配置中心公共组件（自带数据缓存实时更新功能）代替规则DB库，进行规则配置的动态加载，可以保规则获取效率；

• 最小规则是业务执行的最小规则simpleRule；
• 每个最小规则由一个or多个规则因子构成（建议不超过3个），规则因子分为常量值、非常值（动态获取）；
• 多个最小规则组成一个规则组，规则组内的规则要保证顺序；
• 完整的短信业务活动逻辑，可以通过配置多个规则组实现，多个规则组要保证顺序；

规则执行模块：

• 规则组运行监听器RulesEngineListener：包含前置监听器beforeEvaluate（默认做相关入参打印），后置监听器afterExecute（默认空实现），可自定义扩展监听器实现；
• 规则运行监听器RulesListener：包含前置监听器beforeEvaluate（默认做相关入参打印），后置监听器afterExecute（默认空实现），可自定义扩展监听器实现并注册，实现自己的业务逻辑；
• 抽象最小规则AbstractSimpleRule： 定义最小规则属性（名称、描述、表达式、优先级），对规则表达式进行编译评估（evaluate）是否通（ 默认基于AviatorEvaluator对规则进行编译），评估通过后执行(execute)规则对应事件action；
• 规则组SimpleRules：定义规则组，注册、移除规则组内的最小规则；
• 规则因子RuleFactors，规则名称和规则值的 键值对存储；
• 规则引擎RulesEngine， 负责规则监听器的注册、获取，对规则组的评估，规则action的执行；

业务接入规则引擎模块：

• 支持指定不同类型的规则引擎，并行&串行；可进行中断或者跳过&不可中断跳过；
• 支持指定并行规则引擎可指定其并行度，指定特定规格的线程池执行；
• 配置文件的形式配置各业务场景映射的规则编号；