风控系统场景分析

发布时间:2026-10-07 内容来源:网络

  风控是一个非常大的概念,不同的领域对风控有不同的需求,像跟钱打交道的一些行业,比如 电商、银行、金融机构对风控的要求也就更多。

  这篇文章就来简单介绍一下,风控包括什么,以及设计一个风控系统过程中,需要考虑什么?

  电商风控:风控在电商行业代表是 “反撸羊毛”、“刷单”、“爆单”,“被盗号” 等

  银行放贷风控:贷前调查来判断 还款能力以及还款意愿,贷中审查来判断 逾期风险,贷后管理来判断 催收反应等

  一般来说,风控的非实时数据采集,不能直接从线上的数据库中读取,这会把数据库打死。主要的数据采集方式有从库采集,日志采集和pingback三种方式。

  主流数据库,如Hbase,Mysql都提供同步数据进从库的功能,几个数据库数据完全相同,主库可以读写,从库只读,读取从库不会影响主库操作。

  上游异步把数据送给风控系统,一种方式是通过上游系统主动送,比如说RocketMQ,上游完成数据采集后,把数据异步送给下游。

  另外一种方式是通过日志采集,将风控需要的数据输出到日志中,风控数据对对接日志异步进行采集。

  Pingback指在页面上埋入脚本来监测用户的操作,特别是点击操作和键盘操作,将检测到的用户行为异步发送到服务器端。这可以侦测到用户在页面停留时间,鼠标点击的区域等信息,由此可以推断用户偏好,情绪等信息。 pingback的挑战在于如何在服务器端应对流量洪峰。pingback数据一般不直接入库,可以先写入Kafka,风控系统对接Kafka来分析pingback数据。

  规则是用来判断一笔交易、一笔订单是不是违反了系统中的已有规则,规则我认为可以分为两大类,一类是名单类的规则,一个是规则引擎类的规则。

  名单类来说相对比较简单,一个名单通常情况下包括 “名单类型 + 名单类别 + 名单唯一键 + 生效/失效时间”。

  业务方首先需要确定规则的实时性需求,实时处理当然是最好的,但是实时处理就对于系统的性能要求极高。大多数风控系统也不会采取大量的实时处理,就算实时处理,也通常采用比较简单的规则,也有用准实时处理 或者 非实时处理的,准实时时效性没有那么强,可能几分钟或者几小时再进行处理。

  实时性的系统:联机交易系统,比如用户A在凌晨给海外汇款,1个亿的交易涉及到了反洗钱,要是不实时拒绝的话,这一个亿可能就没了。

  准实时处理:银行贷款系统,因为银行贷款系统并不需要说,立即给客户反馈放不放款,但也不能太慢,就可以用准实时处理。

  规则需要对于全网都生效吗?还是只针对某些商户类型、某些银行卡、某个地区生效就行。

  例子1:发生一笔消费,商户类型为 大型超市 并且 (交易时间在 00:00 - 02:00 或者 22:00 - 23:59)

  例子2:发生一笔交易,交易金额 10w元 并且 交易类型 != 消费

  这种规则就需要把报文中的某几个字段取出来,再判断是不是满足规则条件。常见的操作符包括 等于=,不等于!=,大于 ,小于 ,在某几个值中 in,不在某几个值中 out。

  上面的几个例子,都是静态的数据,但系统中可能还存在动态的数据,某用户当月的消费额,就要累计计算。

  例子3:在银行系的风控中,统计一开云电竞,Kaiyun电竞,开云集团官网,开云电竞股份有限公司张卡在同一个终端下,连续交易的天数,要是超过20天,就认为是刷单。

  例子4:在电商系统中,同一个账号在同一个商户下,过去30分钟内,有超过5次购买记录,就认为是刷单。

  例子5:电商系统中,某用户当月的无门槛优惠券超过10张,就认为是系统bug。

  以例3为例,这种规则的需要分为两步:1. 把累计值算出来,先统计连续交易的天数 2. 规则里面再配置,连续交易的天数是不是大于20,要是大于20,才算命中规则

  在更复杂的一些风控系统中,还会支持这样的规则。涉及到了数学中的一些计算。

  例子6:同一张卡在同一个商户下当月的消费金额 占这张卡当月所有消费金额的 95%以上 并且 此张卡当月消费金额 10笔

  例子7:统计某店铺当月的消费笔数 和 它上个月的消费笔数,要是当月的消费笔数 上月消费笔数的10倍,就算命中规则

  要是确认该用户有违法操作,就需要把该用户加入黑名单,或者进行限流等操作,要是该规则配置要问题,就需要对规则进行及时下线的操作。

  对于运维人员就需要有一个风控监控大屏,来及时显示什么规则被命中,统计某规则过去多长时间内的命中次数。

  业界常见采用的方法是通过,开发代码中命中规则以后,打印日志,监控平台再通过异步分析日志把数据以图表的方式显示出来。

  C卡 催收评分卡(Collection scorecard):当借款人当前还款状态为逾期的情况下,预测未来这笔贷款变成坏账的概率,由此衍生出 滚动率、还款率、失联率等细分的模型。

风控系统场景分析(图1)

  WOE(Weight of Evidence)叫做证据权重,IV(Information Value)叫做信息价值,是一组评估变量的预测能力的指标。也就是说,当我们想要拿出证据证明“年龄”这个变量对于违约概率是否有影响的时候,可以使用这个指标评估年龄到底对违约概率的影响有多大。

  下面表格展示的就是年龄、性别及婚姻状况三个变量相关的好坏样本数据以及计算出的对应的WOE及IV值。WOE的计算公式是:ln[(违约/总违约)/(正常/总正常)]。比如对于年龄18~25的组别,WOE=In[(131/总违约样本数)/(1016/总正常样本数)]。根据WOE值,可以进一步计算出IV值。