风控核心子域——名单服务构建及挑战

咕咕鸡
• 阅读 582

引言

名单服务是风控架构中重要子域,对风险决策的性能、用户体验、成本管控、风险治理沉淀都有重要影响,本文将详细介绍名单服务设计思路和实现。

背景

什么是名单?

名单服务通常有几个部分组成:

风险类型

  • 黑名单:绝对会被拒绝的用户。大部分是历史数据清洗出来作弊或者破坏业务的用户,这部分用户对企业无价值且放之进入会破坏生态平衡
  • 灰名单:灰名单上的客户需要进一步审核。这部分用户可能存在某些风险,但是没有明确的证据表明他们是“黑”的
  • 白名单:这部分客户是正常用户,是企业数分人员基于历史表现清洗出来的合规高价值用户,可以直接放行

名单维度

  • 主键:手机号、用户 ID、身份证号、IP、设备标识、wifi MAC 地址等等
  • 业务域:全域、业务子域、细分领域等等,这边需要字典服务来枚举出需要管控的粒度和场景

时间维度 名单是有一定的生效期的,不同的行为会导致锁定期不一样,生效时间可以灵活设置

为什么需要名单服务?

  • 最易构建的决策能力:风控前期的构建是比较依赖名单决策的,策略数分人员通过历史数据判定哪些是“坏用户”,直接将其存储到名单库中,后续请求直接在第一道名单决策中踢出,而不需要执行后续策略在判定一次。策略相对名单来说是非常“重”的,且名单服务构建简单便捷,省时省力。
  • 性能考虑:名单判定一般是在决策流的第一道,试想,对企业服务来说,大部分用户其实都是正常的,如果每个用户的请求都过一遍策略,对成本是极大的浪费,同时对性能来说也是极大的挑战。此时名单服务通过白黑名单,将大部分用户直接决策出去,只对不明确的客户和有风险的客户来做决策,极大地减少了开销。

设计实现

名单服务的特点如下:

  • 名单数据来源:可以是实时产生、离线跑批生产、运营人员手动批量导入等等,形式多样
  • 性能足够好:属于决策流入口必过服务之一,即最大流量冲击,需要经得起峰值压力,RT 要足够小
  • 稳定性:高性能同时还需要高质量保证,如果名单服务出问题,后果不堪设想,流量全部流放到下游,可能会出现服务雪崩
  • 质量保证:任何名单添加到名单库中都需要重视,随意的添加可能会给企业带来难以想象的损失,所以得有完备的审核记录及添加原因,最重要的是生效时间的设定

整体名单服务的数据流图如下所示,重要节点会作明确说明: 风控核心子域——名单服务构建及挑战

实时链路名单查询设计

考虑到名单有时效性及性能要求,且名单数据结构整体简单(多维度,单个维度存储内容小),选择 Redis 存储名单数据非常适合快速查询,数据结构如下: 风控核心子域——名单服务构建及挑战 说明:

  • 采用 Redis Hash 结构存储数据
  • 为何不用 TTL 来存储过期时间?:一是 expire 最大过期时间不能超过 Integer.MAXVALUE 不能满足长时间的过期诉求;二来 Redis 本身定位是缓存,不是永久存储,即数据是可丢失的,需要自己保证服务的高可用

依赖于 Redis 集群良好的性能,基本能满足线上峰值高 QPS 查询需求,且 RT 能很好的控制在 10 ms 以内。如上所说就是要保障高稳定性需求,如何保障名单数据的高可用是首要问题。

高可用设计

Redis 本身定位是缓存,不能永久保存数据,且集群瘫痪或者数据部分缺失应对业务影响较小(能及时恢复的情况下,运维保障集群的可用性),如下是高可用数据设计架构: 风控核心子域——名单服务构建及挑战 说明:

  • T+1 Job 保证数据稳定:每天离线任务全量覆盖,从关系数据库 PG/MySQL 中抽数 push 到 Redis 中即可
  • Redis 集群出问题:不管是老集群重启还是更换到新集群,先用 RDB 恢复数据,保证线上可用,再立即执行离线任务做精确覆盖(T 日的数据丢失需要立即覆盖),考虑到读写同时进行可能会有问题,需要分集群切流

同时需要关注多线程问题,同一个维度,在同一时间可能存在批量更新情况,尤其是离线任务恢复时,历史数据会存在对一个维度多次更新问题,不考虑多线程问题可能会导致数据被篡改。

数据安全审计

名单库的风险点在于:随意地添加名单可能导致“坏用户”畅通无阻,“好用户”无法在进入业务流程

名单的生产来源及定性原因不明确,线上在排查问题时也只能干瞪眼,为了能回溯名单操作,需要做到如下几点:

  • 写日志:任何写动作需要追加日志,且需要做持久换存储,方便做名单时序数据分析
  • 黑名单 & 白名单需要审计:尤其是线上单独添加这种,必须指明原因且要对操作负责
  • 跑批任务审计:离线任务或者算法推数等需要控量,否则在迭代更新过程中出现 BUG 问题,导致名单数据猛增,后果不堪设想

异动监控

监控重中之重

能第一时间感知问题,监控的维度如下:

  • 决策层面监控:灰、白、黑名单决策数量监控
  • 元数据产出层面监控:任何名单猛增或猛跌都是需要去定性是否正常
  • 拉黑踢白:没有永久犯错的人,也没有永久的好人,名单之间的流动也需要关注

总结

名单服务在风控域中是最重要的子域之一,是风控流量的“网关”。名单库对整个风控决策的稳定性,性能提升起到决定性影响。

同时名单服务也是“高危”的,如果使用不当,可能会给企业良好用户带来困扰,给那些“黑产”敞开门户,需要做好数据审核及异动监控。

往期精彩

欢迎关注公众号:咕咕鸡技术专栏 个人技术博客:https://jifuwei.github.io/

风控核心子域——名单服务构建及挑战

若有收获,就点个赞吧

点赞
收藏
评论区
推荐文章
咕咕鸡 咕咕鸡
2年前
风控决策引擎——决策流路径规划
引言决策引擎服务是风控系统的大脑,承载着风控策略编排和计算的任务,对决策的时耗和精度有着严格的要求,本文以决策流执行路径实现方案为切入点,一窥风控决策引擎高效的原理。<!more背景在上文
咕咕鸡 咕咕鸡
1年前
风控规则引擎构建及挑战
如果决策引擎是风控的大脑,那么规则引擎则是大脑内的重要构成,其编排了各种对抗黑产的规则,是多年对抗黑产的专家经验的累计,本文将向你介绍规则引擎的构成及实现。
咕咕鸡 咕咕鸡
1年前
减少80%存储-风控名单服务重构剖析
小小的Redis大大的不简单,本文将结合风控名单服务在使用Redis存储数据时的数据结构设计及优化,并详细分析redis底层实现对数据结构选型的重要性。
Wesley13 Wesley13
3年前
MySQL部分从库上面因为大量的临时表tmp_table造成慢查询
背景描述Time:20190124T00:08:14.70572408:00User@Host:@Id:Schema:sentrymetaLast_errno:0Killed:0Query_time:0.315758Lock_
clickhouse在风控-风险洞察领域的探索与实践
一、风险洞察平台介绍以ClickhouseFlink实时计算智能算法为核心架构搭建的风险洞察平台,建立了全面的、多层次的、立体的风险业务监控体系,已支撑欺诈风险、信用风险、企业风险、小微风险、洗钱风险、贷后催收等十余个风控核心场景
「风控算法服务平台」高性能在线推理服务设计与实现
本文作者:郁昌存来自京东科技风险管理中心一、背景/目标1)风控智能化体系建设依赖大量深度学习/机器学习模型进行实时在线的风险识别、智能决策。要求可以将算法模型快速部署为在线服务,供决策引擎调用。2)风控决策引擎涵盖交易、支付、营