智能风控决策引擎-中后台设计策略1：设计原则、业务解构、服务抽象

本系列分享是基于我们SaaS平台建设中因业务需要在智能风控引擎方向的产品设计、研发建设及系统落地中踩过的坑，以及持续迭代中的业务思考和产品处理策略的复盘总结，进而帮助大家达到以下内容。

1）澄清风控系统的相关术语概念、底层原理，概念理清了，原理明白了，我们的知识图谱就建立起来，知识图谱有了，我们对风控系统的很多未知和疑虑也就荡然无存。

2）掌握智能风控的业务链路、业务解构、设计原则、设计策略、架构设计、迭代建设策略等；结合一些具有代表意义的实践case（采坑、填坑打怪之路），纵向上分别从“贷前-贷中-贷后”和“准入-反欺诈拦截-信用评分-信用定价-资产定价-利率定价-电核-放款-贷后风险预警”两个角度向大家分享智能风控决策引擎中后台的建设经验。

横向上从指标设计、规则设计、流程设计、策略设计、计费策略设计、用户授权设计、数据表结构设计等场景进行服务抽象；帮助大家吃透智能风控中后台的产品设计、研发建设、迭代演进知识体系，从而实务中少走弯路或不走弯路。

3）延展思维：传统的风控模型主要是告诉你是否能放行，我们的设计策略则是除了“申请A时告诉你A是否可行”还需要做到“告诉你，A不行还有B、C、D业务可行”；智能风控系统与我们的业务推荐系统、CRM系统、信审系统无缝连接。

4）具备从0到1的“需求挖掘、业务抽象、前后端及中后台产品的整体考量及设计能力”，并能将这种优秀的产品基本功变成自己的惯性从业能力；方法论相通，空降到任何以个项目上都可快速上手并成为该领域的产品专家、赋能业务前行。

阅读对象：从事互金行业的运营人员、风控人员、贷后管理人员、产品经理、架构师。

一、开篇三问1. 优秀的对手在哪里？

“命中率高、误杀率低”是考量一个风控决策引擎是否有价值的核心指标，业内做风控的头部玩家基本都能做到这一点，不足为奇。

因为这些头部玩家是基于海量数据（阳光手段、非阳光手段获取的），一般的互金平台或正规金融公司限于数据获取的能力（财力、人力、持续投入和法规的敬畏），在数据储备方面必然落后于蚂蚁、同盾、百融、天机等独立玩家。

2. 我们的锚究竟要设在哪里？

作为科技金融众多中小玩家，采用大数据做风控、自动化批贷是一个必然命题；然而很多互金平台甚至所接触的银行、信托等合作机构依旧采用地球上最原始的方案，采购进行大数据风控；做的好的是API自动对接，做的差的是登录商户后台人工查询。

此外，业务不同，批贷控制条件不同，直接采用第三方大数据评测结果只能告诉这个用户有多大的风险无法做出是否要放贷、放多少款定多高利率合适——这是因为风控数据厂商不了解业务无法深度涉足；譬如信用贷、车抵贷、房抵贷三个完全不同的业务，信贷模型不一样。

前者可控性差追求高可靠用户，业务特点是：优质用户（征信无瑕疵）、低额度（5万以内）、高利率（踩着国家线走）、短时间（最长一年，多为1个月周转）、流程简（秒批）；后者的业务特点是：资质有瑕疵、额度大（10万起）、利率低（12%左右）、附加收费多（担保费、保险费、服务费等）、流程多（下户、抵押、公证、担保等）。

而且，我们的机构不像传统金融或传统科技金融，只做自己的资金业务，而是类似“淘宝”的一个B2C撮合业务，公司谈不同的资金合作方给用户提供不同尺度的资金方案；这就决定我们不能像传统风控引擎因为风控系统对用户申请“业务A”被风控拒绝而直接将客户PASS；还需要基于平台接入的“其它资金通道”向用户推荐最合适的“资金业务”，风控系统不能简单的回答“YES or NO”,更需Recommendation；智能风控系统需要与我们SaaS平台的推荐系统、CRM系统、信审系统无缝连接，不是做业务的刹车器而是做业务的离合器。

此外，付费调用第三方API只做简单的查询和决策，而不对获取的“元数据做加工入库处理再利用”将极大的降低数据的复用价值，这不是一个有情怀的产品经理的应有的行事方式。

基于我们的业务现状，风控只是业务中的一环，在有限财力、有限人力如何设计、落地一款“低成本、高可用、自进化、智能决策的风控引擎”是我们的产品明线。

基于我们的SaaS演进战略、初期内部业务用、孵化成功后平滑支持外部调用，将外采数据成本平滑对冲掉是我们的暗线。

3. 你打算怎么做？

基于我们的客观现况，借鉴行业主流做法，我们梳理如下几个设计原则，整个智能风控决策引擎建设将围绕几个原则进行迭代演进、边行进边射击的策略进行落地：

1）不可漏杀：自己没有的，外采第三方。

2）自动式梯度查询：多级串行准入规则，上一级命中“绝对禁止”规则，自动终止流程。

3）人机耦合：命中“相对禁止”时，自动触发人工审批机制，智能风控走完后送审人工信审进行分级审批。

4）成本节流内控：先查自有数据源，自有数据源无数据时再转发查询第三方数据。

5）成本开源内控：查询第三方数据后自动更新我方自有数据源。

6）有损查询：针对每个指标配置自有数据源的初审时效性（15天）、终审时效性（1天）参数，也即自有数据源的更新时差在初审时差内直接放行，譬如“批贷场景我方的司法引擎、公安刑事案件引擎、车辆维修事故引擎、查询安全后则不再查询第三方数据源”；但在平台放款节点，则取终审时效性，依旧跳过第三方，否则再强制查询第三方。

7）可配置：所有规则的条件参数、所有流程的条件参数可配置，无需动用研发修改。

8）可审计：生产环境任意运营参数调整都需要审批通过后方可放行、历史版本可追溯。

9）可透视：当事人可透视、规则调用结果可透视、案件质量可透视。

10）可回朔：由于数据量不够海量、由于机器算法不绝对自信，我们对所有放款案件进行动态监控，回朔批贷指令，为后续修正算法提供“非常规数据”。

11）可商用：部分指标可对外封装支持外部渠道调用，部分指标只对内部使用。

12）隐私与合规：数据获取上我们采用了三种授权方式：用户主动查询授权策略、用户被动查询授权策略、商户保证金线下授权策略。

13）可扩展：这里的扩展指的用户在申请“业务A（如招商银行业务）”被风控拦截，我们要自动检测是否符合“业务B（农商银行放款）或业务C（X信托放款）”是否符合避免将用户一棒子打死。

14）财务互通：计费引擎与SaaS财务引擎互通，支持商户预付费（详见《金融支付财务融合业务-实践分享2：SaaS租户、资金账户、财务账套、记账及对账系统架构设计》、单次计费。

二、需求挖掘、业务解构1. 用户是谁？

客户维度：上班族、个体工商户、小企业主。

用户维度：运营配置人员、风控人员、面签人员、信审人员、电核人员、贷后管理人员、产品经理、研发工程师、财务人员。

渠道维度：测试使用、自有孵化使用、SaaS商户使用、公开API市场调用。

业务维度1：消费场景、信用贷场景、车抵贷场景、房抵贷场景、供应链金融场景（不涉及，但须考虑）。

业务维度2：自有资金放款、银行渠道A资金放款、银行渠道B资金放款、信托渠道C资金放款、小贷渠道D资金放款、P2P平台E资金放款、典当渠道F资金放款。

业务维度3：额度测评、信用查询、进件准入、反欺诈查询、放款安全自查、贷后动态预警。

2. 业务解构

1）人群解构

有哪些人？分别要干什么？如何落实到系统上？

2）诉求解构

老板关心什么？客户关心什么？风控关心什么？信审关心什么？销售关系什么？财务关心什么？研发关心什么？运营关心什么？

3）术语解构

贷前、贷中、贷后是什么？宽限期、M1、呆账是什么？黑名单、准入、欺诈、多头是什么？指标、规则、规则集是什么？绝对命中、相对命中、自动批贷、人工批贷是什么？版本、定价决策、引擎、计费、数据层、特征层、策略层、决策层是什么？路由、配置、参数又是什么？

上述概念有的是业务概念、有的是前台业务概念、有的是中台业务概念、有的是后台业务概念、有的是技术概念，有的是交差概念，这里不再一一展开讲。

如果这里术语不理清吃透、不深入业务一线体验，将很难设计出接地气的系统，因为你顾及了A，可能漏掉了B，当把B的补丁打齐时，又出问题C，疲与应酬C时，D右迎面扑来；业务吃透了，则可运筹帷幄、优雅有序的梯度布局、迭代演进。

4）场景解构

消费场景、信用贷场景、车抵贷场景、房抵贷场景、供应链金融场景（不涉及，但须考虑），每个场景都有每个场景的行业属性；是每个场景都开发一遍，还是通过需求挖掘，将叫法不同但可以抽象为同一类的进行配置化管理，通过条件及流程设置来控制不同的业务路由呢？

5）主流程解构

贷前流程是什么？贷中流程是什么？贷后流程是什么？

何时自动化授信、自动化批贷？何时人工介入审批？何时移交销售地面跟进？

通过上述贷款流程的梳理，我们可以透视整个贷款业务所涉及的节点及各节点之间的业务链路关系；通过梳理业务，将自己下沉到业务中去，和具体的业务操作人员、业务管理人员进行访谈、去挖掘每个节点下面更细的业务知识，自上而下透视整个业务。

譬如准入流程是什么？反欺诈流程如何做？黑名单如何维护？信用评分如何做？资产定价如何做？动态预警流程如何做？

例如风控岗的人员会告诉我们“XX类型客户”不能过，“YYY类型客户”需要增加人工审批，“ZZ客户额度可以高一点”，如果我们只从风控这个方向设计会把我们框进去。

因为销售岗或业务的老大甚至老板某一天会拍拍你的肩膀说，“招商银行业务拒贷的客户为什么不让走北京农商行、或者咱们的信托通道或者咱们合作的某P2P平台信托放款呢？”这其实是要求我们将“业务诉求”与“风控诉求”整合考虑。

要求我们具有系统思维、要求我们具有很好的抽象能力、要求我们在产品设计之初应当极尽可能的做好“架构处理”，譬如将上述场景逐级抽象为“风控引擎”、“推荐引擎”，而“推荐引擎”与“风控引擎”抽象后的共同模型是“规则引擎”。

通过逐级抽象，我们会发现看似完全不一样的需求，其实可以用同一个模型处理，我们只需在模型中多配置几个场景参数即可。

6）子流程解构

大的流程只是一个框架指导，具体实施需要将上述每个节点进一步解构，如同俄罗斯套娃，层层嵌套。

下面我抽取几个典型流程分别同大家分享下：

case1：准入流程解构

准入流程的关键点不在于准入规则、准入尺度的设计，因为这些是“准入引擎”的入门要求。

有想法的产品经理应该重点考虑“性能”与“成本”；“性能”代表“对用户负责”，“成本”代表“对老板负责”，成本节省机制做好了，这一个功能点一年就能帮老板节省个几十万。

如何提升性能、如何控制成本是考验产品经理整体考虑、系统整合的架构设计能力，上面的“准入引擎业务链路图”设计原则凝练如下：

• 先调自有库再调用第三方库（基本上所有的竞品都这样干）；
• 先简单后复杂：年龄>行业>黑名单>司法准入>刑事准入>欺诈准入>逾期行为（差的平台就一马平川或顺序随意了）；
• 时间安全线：我方库中有数据要看我方更新库的时间是否在安全线内（绝大多数平台无）；
• 粒度要足够细：譬如上面2提到的各节点，每个节点都有更新时间安全线（弹性可编辑）；
• 割韭菜：只要我们查询第三方，就增量更新我方库（每家的更新策略不一样，能做到及时更新即可）。

case2：评分流程解构

评分卡设计原则及实务中的应对策略如下：

• 数据库层：粒度足够细；
• 数据库层：聚类分组：譬如个人类、家庭类、收入类、负债类、工作类、行业类等；
• 策略层1：权重系数；
• 策略层2：先自有再第三方数据；
• 策略层3：数据复用，查询第三方时，异步更新我方数据；
• 策略层4：分级原则与分值设计综合考虑；
• 策略层5：定性与定量双维度考虑；
• 策略层6：多个三方平台竞赛校正“算法合理性”；
• 策略层7：分场景案件数据回朔来校正“算法合理性”。

case3：信用额度引擎-流程解构

额度环节主要基于信用评分计算，但是不能一刀切，也即张三和李四都是700分，系统给一样的额度为什么呢？

大家看如下两个例子：

例1：假如张三的700分，但是“月净可供”指标只有“6000元”，李四“月净可供”指标是“20000元”；两者的授信额度将会非常大，懒惰的思维模式给一个额度是不可以的。

例2：同样是张三，但其买手机的授信和买二手车两个场景的授信额度也必将不一样，前者是个小额消费金融，后者是个大额汽车金融，两者所依托的模型不一样。

那是不是还有其他控制因素呢？这些因素是否和评分卡的因素重叠了呢？这两个问题是非常考验产产品经理的抽象能力和大复杂系统架构的驾驭能力。

万变不离其宗，只要我们思路清晰，善于抽象，上述问题可以简化为两个模型“评分是一个一刀切的纯计量行为，也即他是个尺子”、“约束条件是一个定性的方向性条件，相当于变速箱”；基于此我们可以抽象凝练出“额度引擎”的几个关键设计原则，如下：

• 对象：人群定权重；
• 场景：场景定梯度；
• 悲观修正指标：用户命中我们额度引擎中的悲观指标，在上述1、2额度基础上下修；
• 乐观修正指标：用户命中我们额度引擎中的乐观指标，在上述1、2、3额度基础上上修；
• 资产净值安全修正指标：基于用户资产净值（如有）对上述1~4计算额度进行安全修正；
• 月供上限安全修正指标：基于用户月净可支配收入对上述对上述1~5计算额度进行安全修正；
• 机器不是万能：人群万变，数据源不绝对可靠，工程师的算法绝非完美，产品经理永远不要相信XX平台的算法多牛叉；只需相信一点，策略总有遗憾，把主动权交给司机（如果额度不理想，支持用户申请提额进入人工审核流程）。

tips：大家可能注意到这个例子中引用了大量新概念“悲观指标”、“乐观指标”、“安全修正”，产品经理一定要具备“无中生有（把琐碎的事情整合为一个有价值的物件）、造概念（高中数学中的设未知数解函数）”这种能力；关于“造概念的产品能力case”可以看下我的《集合理财计划：资金资产撮合系统、财务分润清结算产品架构设计》这篇文章中有更多关于这方面的case分享。

case4：押品额度引擎-流程解构

case3向大家分享的是信贷场景的信用定价，抵押贷款业务场景中，更多的是参考押品进行资产定价。

这里不再展开说明，方法论相通，核心要点如下：

• 前端路由拦截：无效房源应优先做路由拦截，而非查无结果时再给反馈；
• 成本与场景：弱需场景查自有库；强需场景查专业库（付费）；
• 查不中是高概率事件：汽车不断推出新型号、房产不断推出新楼盘，第三方查不中是大概率事件；

case5：合规计费流程

风险千万条，合规第一条；自主开发大数据项目是个极容易进监狱的行业，购买三方数据也并不是花钱这么简单；故此无论您的大数据平台是对接第三方还是通过爬虫自检，如果产品经理在合规这不下足功夫，将给业务和老板挖巨坑。

下面我们通过层层逆推的方式，来向大家分享合规如何做：

• 监管或用户告我们怎么办？tips：需有用户授权，民事领域，契约做好就是护身符；
• 用户怎么授权的？tips：B端通道还是C端通道？B端高可信商户，走保证金模式；B端低可信商户，走用户授权模式；C端直接走用户授权模式；
• 同一个用户涉及申请、批贷、电核、放款、贷后、循环复借，可能需要多次查，每次都授权太麻烦。tips：通过“法律文本设计”+“查询快照产品封装”+“操作权移交使用着”来解决。

case6：案件回朔流程

磨刀不误砍柴工，通过前述若干场景的case分享，我们废了九牛二虎之力将风控模型设计好了，研发吭哧吭哧开发完了，效果好不好，这个时候需要用数据说话；所以“案件回溯”是一个可自学习的“风控系统”基础环节，案件回溯系统的设计要点如下：

• 哪个模型、哪个案件来的（对象）：caseid、userid、ruleid；
• 采集哪些信息（定量）：还款状态（当前状态）、逾期状态（历史状态）、ROI数据（毛利贡献）；
• 有什么问题（定性）：偏差区间计算；
• 问题定位准不准（分析）：人工标定；
• 模型反验（推演）；模型的哪些参数和规则做调整可以降低此类事件发生的概率；

三、服务抽象、策略设计

哲学上讲“看山是山、看山不是山、看山还是山”，乍一听，讲这话的人脑子有些毛病，哲学家净搞些虚无缥缈的东西。

实则不然，这句话的白话版本是“透过现象看本质”、“表面看着不相同的东西要看他们背后的本质是否相同”、“找出共同点”，也即产品经理的从业方法论中的核心能力素养“抽象能力”——一个有素养的产品经理要习惯将原始的事物抽象化，再将抽象的东西具象化的表现出来——抽象其实是把繁复的事物用尽可能简明的方式进行阐述。

上节通过多个case向大家分享如何“解构我们的研究对象，完成了对现象的认知；但我们的的认知不能停留在这个层面，在不断思考本质的过程中我们逐步对研究对象建立一个更加清晰的模型，形成我们对于事物的抽象。

抽象更多是偏向于逻辑表达，但终须要让团队听得懂、让用户轻松上手用，考验的是产品经理的另一个能力素养“具象(表达)”。

具象是对抽象的表达，我们经常可以看到一些产品宣传“无卡支付”、“会计智能分录”、“智能支付路由”、“智能风控”、“电话AI助理”；但你了解后发现其实就是一个“一个参数”、“一个函数”、“一个规则(集)”、“一个工具”、“一个功能”而已。

智能风控引擎设计中我们用到的抽象这些诸如“角色抽象”、“业务抽象”、“场景抽象”、“概念抽象”、“规则抽象”、“模型抽象”也是其它领域中最主流的、最核心的通识方法；通过这些抽象将上述“上节解构”出来五花八门的术语、概念、场景进行统一考量、整体设计、系统集成，以“最小服务（可以解耦的功能)”的具象形式进行产品落地，进而达到相对的“以不变应万变”的产品设计目标。

case1：规则配置引擎-服务抽象-业务链路图

上一节内容的业务解构中的很多规则都可以抽象为规则，我们只要把规则的核心功能点抽象为具体的字段，各个字段之间以规则的方式进行组合，即可满足业务层面的任意场景的任意诉求。

具体到“规则配置引擎”这个服务中，经过抽象，有如下6个核心概念：

• 变量（谁）：如年龄、如收入、如逾期情况；
• 场景（哪里用）：如消金场景、信贷场景、房抵贷场景、车抵贷场景；
• 条件（如何触发）：策略上需支持条件组合、逻辑运算；
• 动作（触发后果）：需要做哪些动作，如绝对禁止、人工干预、执行评分；
• 收费（商业化考虑）：选配字段；
• API（商业化、可维护考虑）：选配字段；

case2：策略配置引擎-服务抽象-业务链路图

规则服务抽象是最小粒度的抽象，将多种规则进行集成、组合为“一个个策略”，相当于“不同规格的乐高积木”搭建为“不同的空间的玩具”。

规则可以单条执行，多用于低级判断或强路由场景中；单条策略多用于高级判断，多条策略形成的“策略组合”多用与更高级的智能路由判断或面向业务的“完整业务链路”——如前述中的各个层级的业务流程。

具体到“策略配置引擎”这个服务中，经过抽象，有如下5个核心概念：

• 开始：输入指令；
• 对象：选择策略；
• 输出：输出策略运行结果
• 路由判断：根据输出结果，选择下一策略，如此循环；
• 结束：输出最终结果。

规则与策略的3个最核心区别：

• 策略的对象多是规则、规则的对象是字段；
• 策略是多个规则的组合；
• 规则节点线程段，策略节点线程分叉多。

case3：规则/策略状态管理-服务抽象-业务链路图

无论是规则还是策略，其核心在于自学习、随着数据增加、场景的变化、算法都在实施调整；这就要求，“服务抽象”时额外抽象出一个“审计、追朔”的概念，具象到业务中也即“变更需要审批”、“历史快照可回溯”。

不同的抽象表达方式对研发下游的开发理解有着不同的友好度，如何优雅的抽象，是高阶产品与普通产品的核心能力区别，下图与上图相比，哪个更易阅读呢？哪个表达的信息更丰富呢？哪个对具体的产品设计和编码设计更友好呢？

case4：智能风控引擎-服务抽象-整体业务链路图

业务解构上从到小，服务抽象上从小到，最终我们将若干个抽象出来的子服务再次抽象，也即上图的整体技术业务链路图。

前面的“贷前/中/后业务流程图”、“自动批贷授信业务流程图”是一个面向业务的语言；上图是一个面向技术的语言，通过服务抽象我们将业务转换为技术语言。

case5：智能风控引擎向快贷SaaS云平台-整体集成架构图

下图为快贷SaaS云平台的整体价格设计图，在这里，智能风控引擎决策平台只是一个独立的服务，把这个服务close掉，整个平台依托人工审批可以独立运行。

通过抽象服务，我们在产品层面将“智能风控决策引擎”封装为一个服务，即支持内部系统调用，也能对外公开提供接入能力；无他，整个信贷云平台依托人工审批路由依旧可以完美运转。

以上是我们在“智能风控决策引擎中后台”方面的一些设计思想和实践分享，限于篇幅原因，具体的“词典设计”、“表结构设计”、“规则设计”、“策略设计”、“用户画像”、“数据报表”、“贷中动态风控预警设计”、“贷后管理设计”等模块将在《智能风控决策引擎-中后台设计策略2：表结构设计、规则设计、策略设计》、《智能风控决策引擎-中后台设计策略3：贷中动态风控预警设计及任务调度系统》、《智能风控决策引擎-中后台设计策略4：贷后逾期风险处置系统设计》以专题方式向大家展开讲解。

不同的行业、不同的业务场景、不同的岗位角色，会面临不同的产品任务。

但万变不离其宗，方法相通，只要我们有产品盘感、业务敏感、逻辑严谨、灵通好学、干练带风、狠下功夫，放到哪我们都一样熠熠生辉。

产品之路很艰辛，也更能锻炼人，尤其是中后台、尤其是B端复杂业务场景！在此祝广大产品兄弟姐妹们不辱“产品”之title，做出好产品！

作者：九天牧人，个人微信unifarm

本文由 @九天牧人 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议