什么是智能风控系统（风控系统设计）

什么是智能风控系统（风控系统设计）风控系统实际是包含两部分内容，一是识别风险，二是对识别后的风险或是自动的或是人工的进行处理。后台系统增加了惩罚管理，相对于原先风险处理硬编码在业务逻辑中，惩罚管理可以做到配置化的分级处理，当然响应可能没有以前及时，但也是近实时的。整体流程如下所示。离线计算服务需要对核心指标进行数据建模，借助算法，机器学习，来分析出风险点，将结果反馈上报一般来说业务方在接入风控系统时需要先配置策略规则，然后设定每个规则对应的阈值和分值等级，完了就可以应用上线观测实际预测的效果，实际的预测结果只能依赖离线分析，可能需要对用户历史操作轨迹进行分析，如果预测结果拦截的都是正常操作的用户，这时可能就需要调整阈值。有了这个闭环就知道接下来需要做的事情了，后面所有的架构都是围绕这个闭环来进行。经过重新梳理后架构图如下：实时风控服务是整个风控系统的核心服务，是风控系统对外的门面，被所有业务系统同步调用，返回对风控规则的校

一、背景

当前互联网企业存在很多业务风险，有些风险（比如薅羊毛）虽然没有sql注入漏洞利用来的直接，但是一直被羊毛党、刷单党光顾的企业长期生存下来的几率会很低！

• 账号：垃圾注册、撞库、盗号等
• 交易：盗刷、恶意占用资源、篡改交易金额等
• 活动：薅羊毛
• 短信：短信轰炸

实时业务风控系统是分析风险事件，根据场景动态调整规则，实现自动精准预警风险的系统。

需要解决的问题：

• 哪些是风险事件，注册、登录、交易、活动等事件，需要业务埋点配合提供实时数据接入
• 什么样的事件是有风险的，风险分析需要用到统计学，对异常用户的历史数据做统计分析，找出异于正常用户的特征
• 实时性，风险事件的分析必须毫秒级响应，有些场景下需要尽快拦截，能够给用户止损挽回损失
• 低误报，这需要人工风控经验，对各种场景风险阈值和评分的设置，需要长期不断的调整，所以灵活的规则引擎是很重要的
• 支持对历史数据的回溯，能够发现以前的风险，或许能够找到一些特征供参考

二、架构图

风控系统的核心就是规则引擎，一个好的规则引擎可以方便业务方随时变更验证逻辑而不用重启服务。既要保证服务的稳定又要不失灵活性。规则引擎我们是采用执行Drools脚本，可以灵活变更规则逻辑。这需要对领域模型进行抽象，目前抽象出了策略、规则和指标关系如下图所示：

一般来说业务方在接入风控系统时需要先配置策略规则，然后设定每个规则对应的阈值和分值等级，完了就可以应用上线观测实际预测的效果，实际的预测结果只能依赖离线分析，可能需要对用户历史操作轨迹进行分析，如果预测结果拦截的都是正常操作的用户，这时可能就需要调整阈值。有了这个闭环就知道接下来需要做的事情了，后面所有的架构都是围绕这个闭环来进行。经过重新梳理后架构图如下：

三、风控系统组成实时规则服务

实时风控服务是整个风控系统的核心服务，是风控系统对外的门面，被所有业务系统同步调用，返回对风控规则的校验结果，保证业务流程正常且安全。

准实时规则计算服务

准实时风控业务需要对一些业务场景进行实时计算，需要借助kafka flink等实时计算业务，对核心风控指标进行计算规划

离线计算服务

离线计算服务需要对核心指标进行数据建模，借助算法，机器学习，来分析出风险点，将结果反馈上报

四、风控管理平台

风控系统实际是包含两部分内容，一是识别风险，二是对识别后的风险或是自动的或是人工的进行处理。后台系统增加了惩罚管理，相对于原先风险处理硬编码在业务逻辑中，惩罚管理可以做到配置化的分级处理，当然响应可能没有以前及时，但也是近实时的。整体流程如下所示。

五、实现原理

统计学

• 次数统计，比如1分钟内某账号的登录次数，可以用来分析盗号等
• 频数统计，比如1小时内某ip上出现的账号，可以用来分析黄牛党等
• 最大统计，比如用户交易金额比历史交易都大，可能有风险
• 最近统计，比如最近一次交易才过数秒，可能机器下单
• 行为习惯，比如用户常用登录地址，用户经常登录时间段，可以用来分析盗号等

抽象：某时间段，在条件维度（可以是多个维度复合）下，利用统计方法统计结果维度的值。充分发挥你的想象吧！

Redis

redis中数据结构sortedset，是个有序的集合，集合中只会出现最新的唯一的值。利用sortedset的天然优势，做频数统计非常有利。

比如1小时内某ip上出现的账号数量统计：

保存维度

• ZADD key score member（时间复杂度:O(M*log(N))， N 是有序集的基数， M 为成功添加的新成员的数量），key=ip，score=时间（比如20160807121314），member=账号。存储时略耗性能。 结构如下：

1.1.1.1 |--账号1 20160807121314 |--账号2 20160807121315 |--账号n 20160807121316 2.2.2.2 |--账号3 20160807121314 |--账号4 20160807121315 |--账号m 20160807121316

计算频数

• ZCOUNT key min max（时间复杂度:O(1)），key=ip，min=起始时间，max=截止时间。计算的性能消耗极少，优势明显

Drools

规则配置：rules/*.drl，规则都是用java语言编写。默认配置了登录事件的部分规则

drl文件说明：

package rules; --规则包路径 import com.example.riskcontrol.model.LoginEvent --引入类 import com.example.riskcontrol.service.DimensionService import com.example.riskcontrol.model.EnumTimePeriod global DimensionService dimensionService --引入外部服务 rule "98_login_ip" --规则名称，全局唯一 salience 98 --规则优先级，值越大越先执行 lock-on-active true --事件不重复执行该规则 when --条件判断，是否需要进入action event:LoginEvent() --判断事件对象是否是LoginEvent类 then --action int count = dimensionService.distinctCount(event new String[]{LoginEvent.OPERATEIP} EnumTimePeriod.LASTHOUR LoginEvent.MOBILE); --近1小时内该事件ip上出现的mobile数量统计 if(event.addScore(count 20 10 1)){ --如果统计结果超过20个，则记10分，并且结果每超1个，再多记1分 dimensionService.insertRiskEvent(event "近1小时内同ip出现多个mobile count=" count); --记录风险事件日志 } end --结束规则