风控策略之黑名单

2024-02-02 11:48
文章标签 策略 风控 黑名单

本文主要是介绍风控策略之黑名单,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

我们经常会听到银行的同事说征信报告发生了连三累六就不会下款了,这里大概就是一个黑名单的定义,它属于一个风控规则,命中就会被决策引擎拒绝,那么这个连三累六是怎么定义的呢?随着互联网金融,大数据的崛起,黑名单的数据源和规则定义更加多元广泛,产生了更多的风控黑名单规则因子,如何对黑名单更加深入的了解呢?

(尤其现在市场合规持牌银行机构,持牌消费金融公司,保险公司,头部p2p,小贷公司,大量不知名的游击借贷公司 一同面向借款人,加之借款人信用意思,资金需求,政策导向,就业环境等导致借款人还款具有较大不稳定性:同一个人只还上征信的,不还p2p,小贷的。在p2p还款良好的个人听闻p2p监管退出开始建群集体恶意逃废债,显然这里的一个人是相对的黑名单也是相对的非黑名单)

1、内部黑名单
企业通过客户周期数据表现,建立自身的黑名单数据库,一般不同的产品带来的是不同的风险客群,数据表现也尽不相同,所以如果一个黑名单策略规则就相同的使用在不同的产品是不合理的。本人是一名数据分析师,遵守经验主义更崇尚数据分析量化结果,因为一切的最后结果都在最后的收益量化上呈现。

定义:一般类似于风控建模中目标GB的确认可以利用滚动率、迁徙来定义黑名单。例如,像银行通常为90天,也就是连续3次30天,银行有银监会下发的贷款指导分类原则指导。像本人之前从事的现金贷PDL短周期PD10就很难再有回款了,黑名单的规则定义逾期天数大于10,回款不到1%。更早的PDL一般是到PD7回款率就几乎没有了,这也是很多复借规则有一条策略规则(上一次订单逾期天数)所在的原因,这个规则的阈值没有设置为5,也没有设置为13,而设置为7,从迁徙报表可以一眼看出,这就是量化的魅力。

维护:既然定义好了目标就一直不变了么。不是这样的,像银行体系虽然大周期,最近也看到很多微文说银行部分也开始用M2了,说明整体资产恶化,任何事情都是永恒变化着的,随着经济结构发展的变化,人民信用意识形态迁移,市场金融产品布局渗透,政策监管对资金流向的影响,对产品的风险表现影响很大,所以这个黑名单的定义也要维护,如果我的客户不断下沉,上文说道的7天就要改变5天(举例,需要通过数据分析),因为从数据上逾期6,7天的客户我是损失的,给我不能带来收益。复借我们就没有在必要给他下款,如果我们风控部门还在悠闲的用着之前一套定义准则,那只有等着公司的钱流外人田了,或者更严重的就是风控走人,团队换人,这个我说一点不严重,我之前呆的两个公司都遇到了,一个是整体风控团队走人,一个是负责人走人。

2、外部黑名单

三方黑名单的收集来源;
行业共享:典型的af就是合作了同业的p2p,进行共享,他会给你返回具体逾期天数等级,产品,风险等级等字段;
爬虫收集:例如公检法执行信息,很多公司会爬虫的相关网站抓取数据产生规则;
公共库直连:例如某公司产品宣传的公安库直连,近3个月到20年内的时间切片数据,类别有在逃、涉毒、吸毒、前科;
支付数据:近几年兴期的支付公司为主要数据对外提供风控解决方案,他们自身的黑名单就是通过对支付数据的挖掘进行定义的(怎么挖掘:简单的就是某个客户在三方支付扣款余额不足次数之类的统计)
设备数据:通过设备数据(短信,定位,设备指纹等)来定义好坏客户,其中短信的挖掘厂商产品比较成熟,因为黑名单客户都被短信催收过,而且从短信的内容你大致可以看出这个客户是在入催,中期,处置的大概哪个阶段。
其他:催收公司合作,数据交换(合不合规,反正是有的),这个肯定区分度很强哈,直接就是被催收的客户,这是我两年前接触过得,不知道现在还有没有。
就想到这些了,思路短缺,欢迎补充!

其实内部黑名单没有什么好说的,外部黑名单就很有意思了,在北京工作这3年多,接触了太多的三方数据,几乎每家都有黑名单的输出,短信的,支付的,人法公安的,设备的,银行的等等,很多类别种类,很丰富。
面对这种黑名单,本人的经验建议不要直接急于上规则,拿来就用,前几年很多公司不太注意数据质量,我在的三家公司就是拿来就用,那时候也很少有专业的分析人员。懂数学的不懂业务,懂业务的不懂数学,大部门分析人员还在用excel,很难搞出令人开心的分析。原因主要:首先你不了解这个数据收集来源,底层数据,第二个不知道真实性,第三个也不知道在你的产品上是否有区分度。当然数据方会说的天花乱坠,这时候作为一名策略分析师是我最喜欢的事了,我们回溯下,或者最好我们线上跑一跑,就是那种空跑不决策,数据先调用着,然后等待有表现的时候我们在去分析。说的再天花乱坠,也要等效果出来,我们合同在走起。

效用评估

:三方的黑名单就不需要自己定义了,因为三方已经定义好了,大部分给的是字段,剩下的就是需要我们做的是评估,回溯测试也好,线上测试也罢,后续就是需要我们分析这个因子。那么这个因子命中多少的首逾,表现多少的坏账,有多少的回款(其实这三指标相辅相成的)我们才会觉得合适作为黑名单规则呢。例如坏账;100%没得说必须用哈,60%呢,50%呢,其实我这个也有很多的思考疑虑,高了完美,低了不谨慎,其实还是从盈亏的角度或者风控kpi的角度来定义,我觉得没问题的。假如我风控kpi的PD20 是15%。那么这个时候这个因子PD20的表现是30%,我觉得定义黑名单是没问题的,大于15%也没问题。记得之前接触过r3的规则自定,就是是坏账的2倍作为拒绝阈值。没有作为黑名单定义但是有一定的区分度,也可用在模型中作为变量,就像模型中,我们通过的客户最底分数段中的坏账肯定比整体坏账高很多的,但是我们并没有拒绝这一部分人群。他考虑了通过率,成本,转化,收益很多因素的。

总结我遇到的几个有意思的东西

1:别认为黑名单就把人家黑了:记得第一份工作我们用是br,他们的名单叫特殊名单,然后里面有具体的原因。当时我们做的是医美客户,额度还比较大,也是由于当时技术的原因,这个规则没有生效。然后我很好奇的等待着这几个命中了特殊名单规则的客户,结果他们表现的很好,这是我第一次开始怀疑黑名单,从那时候我经过的黑名单数据必须要在上线之前或者成为策略之前要测试一个周期。这个事件说明了,你的黑名单黑了我的白名单,呵呵呵呵呵。
有的三方做开发者推送服务的,在产品介绍中介绍黑名单的数据来源:基于历史数据,近一年内存在大于90天的记录,拥有千万级黑名单用户,千万级哈哈,一个头部的公司全部用户又有多少哈,通过互金行为分析,关系挖掘,这些介绍都是值得怀疑的。不是借贷公司,千万级黑名单,笼统的说明黑名单数据来源这些都是严重值得怀疑的,所以必须进行评估验证。

2:关于命中率的问题:刨除集中攻击,任何信贷产品的黑名单命中率都是有一定的区间范围,这个范围比规则,模型决绝的低。因为它要求稳准狠,所以一般黑名单的规则命中率在0-10%。在10%上下的,一般也就是客群最差的产品了,稳定的也在3-5之间。所以当你使用一个黑名单数据源规则时,如果命中率是15%了,或者更高,作为一个经验的行家。这个命中率就是值得怀疑的,要不数据有问题。要不这根本就不是一个这正的黑名单规则。这个我遇到的也很多,一般这样的效用也不大。不仅没有效用,而且损失了很多用户。往往被运营市场的同学追着问。如果你简单的说这是我们接的三方,测试返回都没问题。他们命中黑名单了,然后就拒绝了人家。我觉得作为一个风控是不合格的,你必须知道这个是有问题的。

3:关于成本问题:在风控流程中位置
我们看到太多的教学课件,太多的ppt,黑名单规则放哪里了:都在最前面的流程吧,肯定在反欺诈,模型前面。但是我想说。如果一个黑名单1元(几乎都是查得收费),一个模型0.5,为什么不把黑名单放在最后呢。模型会拒绝大部分的人,黑名单会拒绝少部分的人。我们换个思路:通过的人成本都是0.5,因为这两条数据都跑了且没有命中黑名单,模型通过,但是拒绝的人呢,只选择其中一个数据你会选择哪个,我用0.5的成本就可以把一个人拒绝掉,而不需要使用1元的黑名单去拒绝,如果使用黑名单去拒绝则我的拒绝成本增加了3倍。我们之前都是结合通过率,收费方式,结合风控流程,然后设计最低的成本,之后计算下来真的可以节省一大笔哦。

综上简述:黑名单需要从从数据源、评估方法、成本优化、动态管理角度等进行细致的针对性的详细了解和分析,达到最佳使用决策,以上只是本人这几年经历的工作的实战片面经验,希望给读者贡献一点源泉,谢谢。
 

这篇关于风控策略之黑名单的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/670613

相关文章

在JS中的设计模式的单例模式、策略模式、代理模式、原型模式浅讲

1. 单例模式(Singleton Pattern) 确保一个类只有一个实例,并提供一个全局访问点。 示例代码: class Singleton {constructor() {if (Singleton.instance) {return Singleton.instance;}Singleton.instance = this;this.data = [];}addData(value)

缓存策略使用总结

缓存是提高系统性能的最简单方法之一。相对而言,数据库(or NoSQL数据库)的速度比较慢,而速度却又是致胜的关键。 如果使用得当,缓存可以减少相应时间、减少数据库负载以及节省成本。本文罗列了几种缓存策略,选择正确的一种会有很大的不同。缓存策略取决于数据和数据访问模式。换句话说,数据是如何写和读的。例如: 系统是写多读少的吗?(例如基于时间的日志)数据是否是只写入一次并被读取多次?(例如用户配

Flink任务重启策略

概述 Flink支持不同的重启策略,以在故障发生时控制作业如何重启集群在启动时会伴随一个默认的重启策略,在没有定义具体重启策略时会使用该默认策略。如果在工作提交时指定了一个重启策略,该策略会覆盖集群的默认策略默认的重启策略可以通过 Flink 的配置文件 flink-conf.yaml 指定。配置参数 restart-strategy 定义了哪个策略被使用。常用的重启策略: 固定间隔 (Fixe

Java后端微服务架构下的API限流策略:Guava RateLimiter

Java后端微服务架构下的API限流策略:Guava RateLimiter 大家好,我是微赚淘客返利系统3.0的小编,是个冬天不穿秋裤,天冷也要风度的程序猿! 在微服务架构中,API限流是保护服务不受过度使用和拒绝服务攻击的重要手段。Guava RateLimiter是Google开源的Java库中的一个组件,提供了简单易用的限流功能。 API限流概述 API限流通过控制请求的速率来防止

未雨绸缪:环保专包二级资质续期工程师招聘时间策略

对于环保企业而言,在二级资质续期前启动工程师招聘的时间规划至关重要。考虑到招聘流程的复杂性、企业内部需求的变化以及政策标准的更新,建议环保企业在二级资质续期前至少提前6至12个月启动工程师招聘工作。这个时间规划可以细化为以下几个阶段: 一、前期准备阶段(提前6-12个月) 政策与标准研究: 深入研究国家和地方关于环保二级资质续期的最新政策、法规和标准,了解对工程师的具体要求。评估政策变化可

面对Redis数据量庞大时的应对策略

面对Redis数据量庞大时的应对策略,我们可以从多个维度出发,包括数据分片、内存优化、持久化策略、使用集群、硬件升级、数据淘汰策略、以及数据结构选择等。以下是对这些策略的详细探讨: 一、数据分片(Sharding) 当Redis数据量持续增长,单个实例的处理能力可能达到瓶颈。此时,可以通过数据分片将数据分散存储到多个Redis实例中,以实现水平扩展。分片的主要策略包括: 一致性哈希:使用一

集群环境下为雪花算法生成全局唯一机器ID策略

雪花算法是生成数据id非常好的一种方式,机器id是雪花算法不可分割的一部分。但是对于集群应用,让不同的机器自动产生不同的机器id传统做法就是针对每一个机器进行单独配置,但这样做不利于集群水平扩展,且操作过程非常复杂,所以每一个机器在集群环境下是一个头疼的问题。现在借助spring+redis,给出一种策略,支持随意水平扩展,肥肠好用。 大致策略分为4步: 1.对机器ip进行hash,对某一个(大于

数据库归档策略

数据库迁移策略 为备战双11,需要将数据库中的相关表(历史订单)进行归档,以便腾出更多的空间迎接订单的暴增。作者经过尝试,得出自认为最优的解决方案。下面给出数据库归档策略及示例代码。 现有条件: 1.现有两个数据库:db-A 以及 db-B; 2.两个库中有字段相同的表:tba(表中只有字段订单id–rx_id(long型) 有索引); 3.归档库的tba中还有17年整年的归档数据。 4.由于单

2024 年高教社杯全国大学生数学建模竞赛 C 题 农作物的种植策略 参考论文 无水印

持续更新中,2024年数学建模比赛思路代码论文都会发布到专栏内,只需订阅一次!  完整论文+代码+数据结果链接在文末!  订阅后可查看参考论文文件 第一问 1.1 问题重述 这个问题围绕的是华北山区的某乡村,在有限的耕地条件下,如何制定最优的农作物种植策略。乡村有 34 块露天耕地和 20 个大棚,种植条件包括粮食作物、蔬菜、水稻和食用菌。除了要考虑地块的面积、种植季节等,还要确保

【数据库实战】1_Oracle_命中关联人或黑名单或反洗钱客户

一、字段名称 1、CST_ID :客户编号 2、IDV_LGL_NM :客户姓名 3、关联方标志 RELPARTY_IND,0-否 未命中,1-是 命中 4、TBPC1010表,RSRV_FLD1_INF(备用字段)中的 第6位:黑名单标志,0无,1是。 第10位:反洗钱风险等级1-5。 反洗钱风险等级5级: 1级-低风险客户 2级-较低风险客户 3级-中风险客户 4级-较高风险客户 5级-高风