基于Flink和规则引擎的实时风控解决方案_flin.pdfVIP

基于Flink和规则引擎的实时风控解决方案

阿里云云栖社区2019-09-2612:50:09

对一个互联网产品来说，典型的风控场景包括：注册风控、登陆风控、交易风控、活动风控等，而风控的最佳效果是防患于未然，所以事前事中和事后

中，又以事前预警和事中控制最好。

这要求风控系统一定要有实时性。

本文就介绍一种实时风控解决方案。

1.总体架构

风控是业务场景的产物，风控系统直接服务于业务系统，与之相关的还有惩罚系统和分析系统，各系统关系与角色如下：

业务系统，通常是APP+后台或者web，是互联网业务的载体，风险从业务系统触发；

风控系统，为业务系统提供支持，根据业务系统传来的数据或埋点信息来判断当前用户或事件有无风险；

惩罚系统，业务系统根据风控系统的结果来调用，对有风险的用户或事件进行控制或惩罚，比如增加验证码、限制登陆、禁止下单等等；

分析系统，该系统用以支持风控系统，根据数据来衡量风控系统的表现，比如某策略拦截率突然降低，那可能意味着该策略已经失效，又比如活动

的时间突然变短，这表面总体活动策略可能有问题等等，该系统也应支持运营/分析人员发现新策略；

其中风控系统和分析系统是本文讨论的重点，而为了方便讨论，我们假设业务场景如下：

电商业务；

风控范围包括：

注册，虚假注册；

登陆，盗号登陆；

交易，盗刷客户余额；

活动，优惠活动薅羊毛；

风控实现方案：事中风控，目标为拦截异常事件；

2.风控系统

风控系统有规则和模型两种技术路线，规则的优点是简单直观、可解释性强、灵活，所以长期活跃在风控系统之中，但缺点是容易被攻破，一但被黑产

效，于是在实际的风控系统中，往往再结合上基于模型的风控环节来增加健壮性。但限于篇幅，本文中我们只重点讨论一种基于规则的风控系统架构，

风控的诉求，该架构也完全支持。

规则就是针对事物的条件判断，我们针对注册、登陆、交易、活动分别假设几条规则，比如：

用户名与身份证姓名不一致；

某IP最近1小时注册账号数超过10个；

某账号最近3分钟登陆次数大于5次；

某账号群体最近1消失购买优惠商品超过100件；

某账号最近3分钟领券超过3张；

规则可以组合成规则组，为了简单起见，我们这里只讨论规则。

规则其实包括三个部分：

事实，即被判断的主体和属性，如上面规则的账号及登陆次数、IP和注册次数等；

条件，判断的逻辑，如某事实的某属性大于某个指标；

指标阈值，判断的依据，比如登陆次数的临界阈值，注册账号数的临界阈值等；

规则可由运营专家凭经验填写，也可由数据分析师根据历史数据发掘，但因为规则在与黑产的攻防之中会被猜中导致失效，所以无一例外都需要动态调

基于上边的讨论，我们设计一个风控系统方案如下：

该系统有三条数据流向：

实时风控数据流，由红线标识，同步调用，为风控调用的核心链路；

准实时指标数据流，由蓝线标识，异步写入，为实时风控部分准备指标数据；

准实时/离线分析数据流，由绿线标识，异步写入，为风控系统的表现分析提供数据；

本节先介绍前两部分，分析系统在下一节介绍。

2.1实时风控

实时风控是整个系统的核心，被业务系统同步调用，完成对应的风控判断。

前面提到规则往往由人编写并且需要动态调整，所以我们会把风控判断部分与规则管理部分拆开。规则管理后台为运营服务，由运营人员去进行相关操

场景管理，决定某个场景是否实施风控，比如活动场景，在活动结束后可以关闭该场景；

黑白名单，人工/程序找到系统的黑白名单，直接过滤；

规则管理，管理规则，包括增删或修改，比如登陆新增IP地址判断，比如下单新增频率校验等；

阈值管理，管理指标的阈值，比如规则为某IP最近1小时注册账号数不能超过10个，那1和10都属于阈值；

讲完管理后台，那规则判断部分的逻辑也就十分清晰了，分别包括前置过滤、事实数据准备、规则判断三个环节。

2.1.1前置过滤

业务系统在特定事件（如注册、登陆、下单、参加活动等）被触发后同步调用风控系统，附带相关上下文，比如IP地址，事件标识等，规则判断部分会

配置决定是否进行判断，如果是，接着进行黑白名单过滤，都通过后进入下一个环节。

这部分逻辑非常简单。

2.1.2实时数据准备

在进行判断之前，系统必须要准备一些事实数据，比如：

注册场景，假如规则为单一IP最近1小时注册账号数不超过10个，那系统需要根据IP地址去redis/hbase找到该IP最近1小时注册账号的数目，比如1

登陆场景，假如规则为单一账号最近3分钟登陆次数不超过5次，那系统需要根据账号去redis/hba