手把手系列|贷后评分(C)卡模型开发实操(全)

序言:
随着风控精细化的管理,番茄风控也就将现有的内容进一步迭代,更新贷后迁徙率模型的内容,同时也综合了星球社区中同学的一些新需求,给大家梳理了贷后迁徙率模型的文章。
希望对所有的风控人员在贷后相关的模型开发的上都有所启发。文章虽然大部分是关于模型开发的细节,但其中也不乏关于贷后迁徙率应用的内容,相信对贷后策略和相关风控领域的同学也会有所启发。
本次整体的内容,我们更会在知识星球上为大家提供本次内容所涉及的实操数据与代码,带领大家领略整个贷后迁徙率模型内容,整体目录如下:

PART 1.迁徙率模型的业务背景
1.1…业务背景
1.2.迁徙率模型的简单介绍
PART 2.迁徙率模型的设计思路

PART 3.迁徙率模型的特征开发

PART 4.迁徙率模型开发应用
PART 5.实操—迁徙率的模型特征开发

Part1.迁徙率模型的业务背景

一.业务背景
风控模型的整个体系主要由反欺诈模型,申请准入模型(A卡),贷中行为模型(B卡),贷后催收模型(C卡),网上对于反欺诈,AB卡的资料较多,但对于C卡的介绍却比较少,原因在于以前很多公司没有专门的催收团队,且人的因素对催收结果影响很大,大部分公司在用户发生M1(逾期30+)后就会进行委外催收处理。
但随着目前信贷行业的发展,委外催收慢慢被淘汰,各家公司开始搭建并重视起自己的催收团队,为了提高催回率,减少坏账损失,催收也朝着精细化的方向发展,催收策略和模型变得越来越重要,基于此背景,本文将介绍贷后模型中的迁徙率模型,介绍其开发的思路,过程和应用方式。

二.迁徙率模型的简单介绍
1、迁徙率:
表示用户从当前的逾期状态过渡到下一个逾期状态的比率
贷后中逾期状态分为这么几类:
M0:表示未处于在逾状态,在逾天数等于0
M1:表示处于在逾状态,在逾天数为1-30天
M2:在逾天数为31-60天
M3:在逾天数为61-90天
M4:在逾天数为91-120天
以此类推…
上述的逾期状态是业界常用的,有些的公司的定义可能会有差别,例如会把M0定义成在逾1-3天(还款的宽限时间),还有考虑到用户可能有多笔在逾订单,一个订单中又有很多期是在逾的,所以这里面的在逾天数通常表示为“最大在逾天数"(算出每期的在逾天数取其中最大值)。另外计算在逾天数时要确定观察点,例如用户在今天算的在逾天数为15,那到了明天如果他还不还,在逾天数就变为了16。下面来拟计算2月-3月的迁徙率:

Step1:在2月28号那天标记样本中每个用户的逾期状态
Step2:因为每个逾期状态之间都间隔了30天,所以迁徙的表现期为30天,观察在3月30号这一天样本中每个用户的逾期状态
Step3:计算各个迁徙率的值
按照上述步骤模拟的结果如下:
在这里插入图片描述

图中可以看出,2月28号处于M0的人,30天后有33%的人迁移到了M1,67%的人仍处在M0阶段,2月28号处于M3的人,只有12%的人还清所有欠款,回到了M0阶段,而有33%的人仍然不还恶化到了M4阶段

2.迁徙率模型的分类
从上述的迁徙率结果可以看出,每个逾期阶段的风险是不一样的,逾期阶段越长,催回的概率越小,在每个阶段的样本都充足的情况下,为了精细化的催收策略,可以分阶段构建迁徙率模型,例如M0-M1,M1-M2,M2-M3模型,来提高各个阶段的催回率。有些公司可能不会分的这么细,会分成短账龄迁徙模型(<=M1阶段的用户迁移到M2+)及长账龄迁徙模型(M3阶段用户迁移到M4+),所以要根据样本量,业务目标具体来定做什么样的迁徙率模型。

Part2.迁徙率模型的设计思路
一.目标定义和预测群体
以M1-M2迁徙模型为例,那预测群体为观察点处在M1阶段的用户,预测这些人30天后迁移到M2的概率。样本定义在用户维度,即计算用户的最大在逾天数作为逾期状态。

二.观察点,观察期,表现期的定义
我们先看一下申请准入模型(A卡)的观察点,观察期,表现期是怎么定义的,笔者画了下面这张图来表示,设定表现期为90天以上,坏用户定义为最大逾期天数>=30天,好用户定义为最大逾期天数<=3天。观察点即为用户的申请日,每个用户的申请日不同,观察点自然也不一样。我们从建模的时点来观察,要求用户到期日和建模时点的间隔至少在90天以上(表现期),然后在建模时点计算这些人的最大逾期天数,这里的逾期天数包含“逾期还款”和“在逾”两种状态,将最大逾期天数>=30标记为坏用户,<=3天为好用户。观察点之前则为用户的观察期,一观察期设为360天或720天,观察期内采集的数据来构造特征,通过这些特征来预测用户申请之后的逾期表现。
在这里插入图片描述

从A卡的定义中可以看出,每个用户的观察点不一样,且只要满足表现期,用户的标签不会随着建模时点改变而变化,举个例子,如果把今天作为建模时点,用户X只有在逾订单,且最大逾期天数>=30天,那他的标签是个坏用户,那如果把建模时点推到后天,这时候用户X已经把在逾订单都给还了,那他只有逾期还款订单,最大逾期天数还是>=30天,仍然是个坏用户,因为逾期天数包含“逾期还款”和“在逾”两种状态。

那对于迁徙率模型,表现期是很容易定的,模型是预测M1-M2的迁徙情况,那表现期就为30天,观察期的话也跟A卡类似,设为360天或720天,主要研究的是两个问题:
1)怎么确定观察点?
2)在什么时点计算逾期天数?
在这里插入图片描述
先说第一个问题,迁徙率模型不像A卡有明显的触发动作(申请行为)时间作为观察点,贷后用户的逾期还款行为每天都在发生,如果建模时点为2021年12月31日,那么往前推30天(表现期),2021年12月1日之前每天都可以作为观察点来建模,那到底选哪天呢?笔者的想法是观察点越近越好,但也要留出足够多的时间外样本(OOT)来验证模型效果,因为观察点不固定,所以验证模型跨时间稳定性非常重要。我们可以分析近一年的数据做迁徙率分析,计算每天M1-M2的迁徙率变化,选择迁徙率稳定,客群稳定,催收动作无大变动的一段时间作为建模和模型验证的时间窗口,假设2021年9-12月份样本比较稳定,那可以将2021/8/31作为建模的观察点,用建模观察点后每隔1个月作为验证样本的观察点,这样验证样本有三部分,验证的观察点分别为2021/10/1,2021/11/1,2021/12/1。
建模观察点2021/8/31确定好后,第二个问题就容易解决了,先在建模观察点计算用户的最大在逾天数,将处在M1阶段的用户挑选出来,这些用户就是建模样本,然后经过30天表现期,在2021/9/30这个时点再计算这些人的最大在逾天数,将处在<=M1阶段的标记为好用户,迁移到M2的标记为坏用户。

从刚才的建模思路中可以发现申请准入模型和迁徙率模型的不同点:
1)申请准入模型用户观察点不固定,迁徙率模型所有用户用同一个观察点
2)申请准入模型在建模时点计算逾期天数,且包含“逾期还款”和“在逾”,迁徙率模型是在观察点和表现期满的时间点计算逾期天数,且只考虑“在逾”
3)申请准入模型每个用户的表现时间不一样,观察点越靠前,表现时间越长,而迁徙率模型所有用户表现时间都一致
4)迁徙率模型由于观察点固定,所以更看重跨时间的稳定性。

三.如何评估迁徙率模型的效果
1)建模样本中随机划分出验证集计算KS,AUC指标,然后在跨时间样本上验证KS,AUC的稳定性,这是线下评估的方式。
2)模型刚上线时还没积累到期样本,这时候可以通过催收员使用模型的反馈来评估,例如高分段的用户催回率是较高的,用户是比较配合催收的,催收员可通过与用户的接触来判断模型预测的准确性。

Part3.迁徙率模型的特征开发
做特征开发之前,我们可以思考下哪些行为或数据对用户还款有影响:
1)催收行为:根据历史上对用户的催收手段,催收强度,催收频率等可以反应用户的还款意愿和好催程度,如果一个用户电催经常打不通,失联天数长,动用过催收函,冻结账户等手段,那有理由相信这个人有大概率从M1迁移到M2
2)历史逾期还款行为:包括本平台和其他平台上的贷后行为,如果用户提前还款次数多,说明手上资金比较充足,且重视诚信记录,如果习惯性的逾期,逾期天数又长,说明还款意愿比较低,不重视诚信记录。
3)负债情况:用户若在其他平台上有多头共债现象,说明负债压力比较大,很可能出现拆东墙补西墙,哪家催的急就先还哪家,这种人不还的风险比较高。
4)收入能力:直接反映用户的还款能力,收入包括工资,公积金,固定资产等。

根据以上的这些维度,结合可用的数据,我们可以开发四类特征
1)催收行为特征,包含电催,短信,催收函记录等。
2)逾期还款特征,在本平台的还款记录,逾期记录等
3)内部负债特征,在本平台的在贷,在逾笔数,金额等
4)外部三方特征,包含风险名单,多头共债,逾期行为等

在风控中,我们常从时间维度提取用户在不同时间点的行为特征,所以时间窗口类特征占到了绝大部分,在特征衍生时,我们可根据时间窗口+行为维度+统计对象+统计函数 这个定式来衍生出大量的时间窗口特征。例如对电话催收数据:

时间窗口维度可分为近7天,近15天,近30天,近90天,近180天…

行为维度包括催收员呼叫,用户回电,呼叫中又可分为未接通和已接通
统计对象包含通话次数,通话时间
统计函数就是对通话时间进行加总,取平均等

另外除了统计类特征,还可生成趋势类,占比类,稳定性类的时间窗口特征,基于以上的特征开发思路,笔者整理了一些特征明细供读者参考:
1.催收行为特征
在这里插入图片描述

2.逾期还款特征
在这里插入图片描述

3.内部负债特征
在这里插入图片描述

4.第三方数据
在这里插入图片描述

Part4.迁徙率模型开发应用
这里以开发逻辑回归评分卡为例进行介绍1.数据集的划分在模型设计的介绍中,我们划分出了三部分时间外验证样本,那在建模样本中,还需要划分出训练集和验证集,一般是8:2的比例,训练集用来做模型训练,验证集用来评估模型效果,时间外验证样本用来评估模型在时间上的稳定性。这里要注意,特征筛选和分箱计算IV都只能在训练集中处理,验证集和时间外样本只用来评估效果。2.特征筛选和woe编码
由于我们用的算法是逻辑回归,所以特征筛选的步骤较多,且最后入模的特征要尽量效果好且数量少,筛选的大致步骤为:1)缺失率筛选,将缺失率很高的特征剔除,一般阈值定在50%-70%之间2)方差筛选,将方差等于0或接近于0的特征剔除,这是为了筛掉携带的信息很少的特征。3)常值占比筛选,如果特征中某个值占比过大,那特征携带的信息也比较少,这个跟方差的逻辑类似,筛选的阈值一般定在85-95%之间。4)IV筛选,定筛选的阈值时,要根据总体特征IV值的情况来定,例如IV值都在0.2以下,那阈值要设的松一点,可以保留IV>0.05的特征,如果IV值都比较高,那阈值可以设的紧一点,例如可以保留IV>0.1的特征。5)共线性筛选,将两两相关性在0.7以上或者VIF值大于10的特征做筛除。在共线性筛选前要先做woe编码。6)显著性筛选,利用逻辑回归自带的显著性校验,将P值小于0.05的特征筛除。7)系数符号一致性筛选,逻辑回归评分卡要求每个特征系数符号一致来保证可解释性。3.模型训练将训练集带到逻辑回归中进行训练,逻辑回归一般不调参,要调参的话调整正则化强度(C)和正则化选项(penalty)即可。4.模型评估先在验证集上用KS或AUC评估效果,迁徙率模型用到的特征跟标签都是强相关关系,所以AUC一般能达到0.75以上,KS在0.35以上,然后在三个时间外样本计算KS或AUC,一是看时间外样本的KS和验证集差的多不多来评估模型的泛化能力,二是看时间外样本三个KS的变化趋势,来衡量模型在时间上的稳定性。5.模型应用模型效果达到预期后,可以将模型分分成几个等级,每个等级代表用户不同的还款意愿,催收员通过等级将用户分类做差异化的催收策略,另外为了验证模型的线上效果,可通过设置对照组来评估。例如将用户分成了高风险,低风险,中风险三个等级,对应的催收策略如下:
在这里插入图片描述

测试组根据风险等级采取不同的催收策略,而对照组都用最常用的手工外呼,通过后面测试组和对照组的催回率对比来验证模型效果。

Part5.实操—催收行为特征开发
1…导入样本文件sample_call_collection.csv,
里面包含50个用户的样本,每个样本的观察点都为2022-03-11,导入样本历史回溯的电催记录call_collection_detail_data.csv,字段含义如下:
user_id – 用户id
call_time – 催收员呼叫时间
ringoff_time – 催收员挂断时间
is_connected – 电话是否接通,n–未接通,y–接通
relationship – 呼叫人与用户的关系,oneself–本人,relatives–亲属,coll_fri–同事朋友,other–其他

需要衍生的特征如下:
近N天本人/亲属/同事朋友的呼叫次数
近N天本人/亲属/同事朋友的接通次数
近N天本人/亲属/同事朋友的接通率
近N天本人/亲属/同事朋友的通话总时长
近N天本人/亲属/同事朋友的通话平均时长

时间窗口:近7天/近15天/近30天/近90天/近180天
在这里插入图片描述
2.定义电催特征衍生的函数,当我们拿到一个用户的id和观察点时,要取除这个用户在观察点之前的历史电催数据,然后进行特征计算,特征衍生函数的变量为user_id和observe_date,函数计算结果为每个特征结果组成的字典。
在这里插入图片描述
3.用for循环的方式跑出每个用户的fea_dict,并生成一张特征的dataframe
在这里插入图片描述

详情可以请到知识星球参考完整详版内容~
在这里插入图片描述

另外,关于本次文章中所提及的代码+数据内容,更可以移步至知识星球后台,查看完整版本数据集+代码内容,供星球同学学习完整内容:
在这里插入图片描述
关于催收模型催收策略等体系化的内容,有兴趣的童鞋们可关注-
第五期的番茄风控《全线条训练营》:
在这里插入图片描述

~原创文章

end

  • 0
    点赞
  • 15
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
手把手进行Django Vue前后端分离开发的入门,可以通过以下步骤实现: 1. 首先,确保已经安装了Python和Node.js,以及相应的开发环境。 2. 创建一个Django项目,可以使用命令`django-admin startproject project_name`来创建项目。 3. 进入项目目录,创建一个Django应用,可以使用命令`python manage.py startapp app_name`来创建应用。 4. 在Django中配置应用,包括数据库连接、URL路由等,可在`settings.py`中进行配置。 5. 创建数据库模型,可以在应用目录下的`models.py`中定义模型类,表示数据表结构。 6. 执行迁移命令,将模型映射到数据库中,可使用命令`python manage.py makemigrations`和`python manage.py migrate`执行。 7. 在应用目录下创建视图函数,用于处理客户端的请求,其中可以包括接收和发送JSON数据。 8. 在`urls.py`中配置URL路由,将请求的URL与对应的视图函数进行关联。 9. 使用Vue CLI创建Vue项目,可以使用命令`vue create frontend`来创建项目。 10. 在Vue项目中安装axios,用于发送HTTP请求,可以使用命令`npm install axios`进行安装。 11. 按照需求,在Vue组件中编写前端代码,可以使用axios与后端进行数据交互,获取数据并展示。 12. 运行Django项目,可以使用命令`python manage.py runserver`来启动Django服务器。 13. 运行Vue项目,可以使用命令`npm run serve`来启动Vue开发服务器。 通过以上步骤,即可实现Django Vue前后端分离开发入门。在实践中,可以进一步学习和了解Django和Vue的相关文档和教程,通过不断实践和探索,提升开发技能。相关的示例代码和项目实例可以参考知乎上的文章。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值