一、风控功能简介

风控不仅仅是规则引擎，它是一个体系，规则引擎，算是一个决策引擎，不同的公司，对规则引擎定位是不同的；
风控主要功能还是在于数据处理，选取合适且有效的策略规则
风控规则引擎计算能力还是有限的，更多的是在应用内计算风控系数，再交由引擎去决定策略。成熟的产品，比如：blaze，ilog；开源的有drools；
要分清楚指标变量加工和规则引擎的职责，还有一种方式就是用JPMML，直接把规则写成PMML包，然后执行，如果不复杂就可以用一些可热加载的语言来实现。

所有的数据处理的结果都可以抽象为变量； 业务人员基于已经加工好的数据，进行业务策略的配置和基于规则数据再加工。

XX公司的风控技术体系：
基于XX公司的实践，风控技术体系见如下图：
image

注：字段，就是变量，包括很多种来源：接口，数据库，缓存，hadoop等；

风控数据处理技术，主要基于ETL，现在会结合一些AI新技术，离线和实时处理的技术； 变量在不同场景下，种类划分是不一样的。但为了方便规则引擎的处理，其可以大致分为：单值变量，多值变量，待加工变量，已加工变量； 风控种变量很类似于编程语言种变量，也需要分为：String, Integer,double, boolean等类型；

二、风控规则实现

规则可以通俗理解为：变量组合成的表达式，例如：if(a>b) then a=b+c;。多条简单原子规则，可以构成一个规则集；规则集之间调用可以借助流程引擎来实现；将每个规则集当作流程图中的一个节点，通过变量来配置条件分支，完成基于复杂的决策树和评分卡规则的配置； 风控规则一般情况下，是基于场景来配置的。不同场景下的决策规则和变量是不同的； 规则版本控制，非常类似于开发中代码的版本控制，需要保证多版本的支持

三、风控事后分析

这块目前来说，XX公司主要基于AI技术来做，通过AI学习，不定期的调整业务规则： 风控实时拦截是结合缓存+实时数据处理，偶尔会用到离线的处理，通过实时处理引擎；例如：storm,flink,将线上的实时数据不断进行压缩。

四、其他内容

风控最重要的是++建模++，建模的前提是吃透业务，针对具体业务 场景建不同的模型:一般都是先设计维度，再设计变量，最后才是规则，由总体到明细的过程。 决策树，决策表，评分卡只是针对不同数据在相同规则不同表现而定的，模型变量由变量与其权重组成，专家模型定义了强变量，通过机器学习回归其权重，而弱变量及其权重，变量间的相关性等更多的依赖机器学习。 机器学习结果要符合数据的++正态分布++，同时要有贷后表现来验证； 只有回归算法对正态要求高，其他算法并没有那么高，而且金融领域的数据基本还是挺正态的，尤其不同金融产品其实已经筛选过用户了。

Q&A

Q: 你们是每天跑批来计算规则的效果比如精准度覆盖率等，然后来调整规则吗？
A: 我们并不是每天来调整规则的，规则调整纬度很多。
Q: 这里说的依据AI学习调整规则，是分析规则的好坏，还是分析变量的阈值，还是分析变量的好坏，还是根据交易信息来产出变量和规则？
A: 判单规则的好坏，需从2个方面来考虑：1，规则中变量阈值设置地是否合理，阈值设定需结合业务具体业务场景和规则多次试运行后的结果。2，风控事后数据分析和机器学习特征值的抽取，可以发现一些隐含的特征变量。
Q: 评价这个规则好坏的功能是定时跑的还是人工触发的？
A: 评价规则好坏功能，基本都是定时触发的，人工触发场景不多。

Q: 规则引擎，没添加10条规则或者调整规则，对服务的性能影响有多大呢？
A: 规则执行都是在毫秒之内；正常规则引擎不会因为增加10条而影响效率。
Q: 执行用的什么高效的工具呢？
A: 目前是自己开发的规则引擎；

Q: 新的业务对接风控，结合思维导图里的内容，要怎么配置呢？
A: 新业务对接风控：业务人员配规则，通过统一API调用，风控提供规则配置平台，业务人员配置规则，测试，发布，试运行 ；
Q: 但是案件其实不是正太分布的？
A: 正常的如果正态分布了，异常的就好办了，正态分布是客群分布，同时也是个概率分布，模型覆盖正态分布。异常客户在未违约前也是正态正常客户，只不过没有发现特征而已，回归就是发现特征并验证特征。

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