对一个互联网产品来说,典型的风控场景包括:注册风控、登陆风控、交易风控、活动风控等,而风控的最佳效果是防患于未然,所以事前事中和事后三种实现方案中,又以事前预警和事中控制最好。
这要求风控系统一定要有实时性。
本文就介绍一种实时风控解决方案。
1.总体架构风控是业务场景的产物,风控系统直接服务于业务系统,与之相关的还有惩罚系统和分析系统,各系统关系与角色如下:
其中风控系统和分析系统是本文讨论的重点,而为了方便讨论,我们假设业务场景如下:
电商业务;
风控范围包括:
注册,虚假注册;
登陆,盗号登陆;
交易,盗刷客户余额;
活动,优惠活动薅羊毛;
风控实现方案:事中风控,目标为拦截异常事件;
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小时注册账号的数目,比如15;
登陆场景,假如规则为单一账号最近3分钟登陆次数不超过5次,那系统需要根据账号去redis/hbase找到该账号最近3分钟登陆的次数,比如8;
redis/hbase的数据产出我们会在第2.2节准实时数据流中进行介绍。
2.2.3 规则判断在得到事实数据之后,系统会根据规则和阈值进行判断,然后返回结果,整个过程便结束了。
整个过程逻辑上是清晰的,我们常说的规则引擎主要在这部分起作用,一般来说这个过程有两种实现方式:
上一篇:《一个人的电商》读书笔记 下一篇:用金钱换时间,简要分析拼多多的优惠体系
郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。