金融风控建模开发SOP(标准操作流程)-适用于银行投行消费金融公司（收藏）

平衡各方利益的模型才是最好模型

—Toby！2022 07 07

各位朋友大家好，我是Toby老师。之前有很多风控朋友咨询如何搭建风控模型。今天我抛砖引玉为大家讲述金融风控模型开发SOP(标准操作流程)，供大家参考。

一.SOP标准操作流程

SOP，是 Standard Operating Procedure三个单词中首字母的大写 ，即标准作业程序，指将某一事件的标准操作步骤和要求以统一的格式描述出来，用于指导和规范日常的工作。SOP的精髓是将细节进行量化，通俗来讲，SOP就是对某一程序中的关键控制点进行细化和量化。实际执行过程中sop核心是符合本企业并可执行，不流于形式。

模型开发SOP

模型开发sop即指“模型开发标准操作程序”，将开发过程统一为标准操作步骤和要求，用来指引模型开发日常的工作。

模型开发并非易事，需要平衡业务方，模型开发方，验证方，领导层等多方面需求。不同部门需求有可能发生冲突，因此模型开发需要照顾各方利益，平衡取舍。模型开发并非完全尊从教科书理论，真实大数据是不干净的，无法完美满足教科书上各条理论。
模型开发尽可能做到模型较高准确性，较高区分能力，分数稳定，合理、维度合适。

模型开发SOP重要性

（1）标准化，流程化重复工作，提高建模效率和质量

（2）便于模型验证和维护

二.模型开发立项需求

业务方或策略方（政策部）发起需求，确定模型开发方原因，使用场景，模型性能要求。

比如，A卡贷前审批模型主要是为了评估贷前用户的违约概率；B卡用于预测用户贷后违约概率；C卡用于催收。反欺诈模型预测黑产，灰产用户骗贷、薅羊毛行为；资本计量模型主要适用于 Basel 体系确定最低资本要求和进行压力测试。

模型立项可以通过邮件和会议形式确立，必要时做好会议纪要。

三.模型开发具体环节

是建模工作的主要过程，包括SQL取数、数据清洗、数据探索，变量筛选、模型建立、模型选择，模型验证，模型部署，线上验证，模型监控和模型迭代。

1.SQL取数：

SQL取数是根据业务方需求，关联若干表单，提取模型需要数据。公司数据量越大，基层表单越混乱，此步骤会越耗时，SQL语句可能从几十行到几千行不等，需要熟悉公司数据库和表单逻辑。新手写的SQL语句还容易产生跑数据耗时，卡死服务器等问题。大多数金融公司数据分析师和模型开发人员职责是重合的，这样建模效率并不高。模型质量难以提升。理想状态是一个模型开发人员搭配一个数据分析师。数据分析师负责取数和提供描述性统计。模型开发人员精力集中在提升模型性能和控制模型维度。

2.数据清洗：

数据清洗主要是对不能直接入模的数据做清洗处理，比如类型不对数据，不合理异常值，缺失值，怪异字符串等等。入模数据必须是结构化数据，否则训练模型时会报错。对于类别变量，可以用one-hot编码。但one-hot编码消耗内存，产生高维度变量。逻辑回归建模时推荐WOE编码方法。对于新一代集成树算法catboost，可以直接申明类别变量，然后自动处理。

3.数据探索

EDA探索性数据分析和描述性统计，包括统计总体数据量大小，好坏客户占比，数据类型有哪些，变量缺失率，变量频率分析直方图可视化，箱形图可视化，变量相关性可视化等。

4.变量筛选：

从原始数据中筛选出重要变量，踢除噪音变量，相关性高变量。

常见的特征选择方法：

• IV information value（信息价值），常用于逻辑回归模型
• Information gain（信息增益），常用于决策树模型
• Correlation coefficient scores（相关系数），通用所有模型
• missing value （缺失率），删除缺失率接近1的变量
• unique value（唯一值），删除唯一值占比接近1的变量
• shap value，删除shap值接近0的变量

5.模型建立：

模型建立就是用清洗后数据,通过机器学习算法建立模型。给模型喂养数据，训练数据，最终让模型生成预测能力，批量预测客户违约率。

6.模型选择：

根据业务方需求，通过多算法比较，择优选择综合性能最佳模型。

一般而言,金融风控领域模型看重AUC，ks，accuracy，psi等指标，混淆矩阵等其他指标也要附带参考。不同模型指标代表不同意义。

7.模型验证：

模型开发过程不可或缺的一部分。它有助于发现表达数据的最佳模型和所选模型将来工作的性能如何。

模型验证分为三个环节,模型开发部门首先内部评估模型质量是否合格，如果没问题会发生第三方模型验证团队。第三方模型验证团队必须保证独立性，验证过程不受模型开发团队干扰，避免既当裁判又当球员的作弊行为。第三方模型验证团队可以是外包公司，也可以是公司内部团队。如果担心数据泄露，优先推荐公司内部团队独立验证。最后模型验证报告会提交给各个团队领导审批。如果领导认为模型质量有问题，会邮件批注或驳回模型。

模型评估的常见的五个⽅法：

• 混淆矩阵
• lift提升图&洛伦兹图
• 基尼系数
• ks曲线
• roc曲线
• psi模型稳定性

由于人员编制不稳定，部分项目相关同事会离职。因此模型验证完后需要存档，包括模型资料保存。存档中要完整记录验证人员，开发人员，业务方人员，开发时间，模型性能，模型缺陷等内容，以便后续人员查阅和维护。

8.模型部署

通过模型验证后，配置好模型的包，文档说明，变量表，准备线上部署。

9、线上线下验证

完成模型线上部署后，进行模型的线上线下部署验证。主要测试线上模型分和线下模型分是否一致。如果线上线下模型分不一致需要找出原因。一般情况下维度高的模型容易发生线上线下分数不一致，因此保留合适模型维度有利于模型上线后维护。常见引起线上线下分数不一致原因有模型包材料有问题，变量漏写，变量多写，硬盘传输速度慢造成丢包等等。

10、模型监控

完成模型的部署和线上验证后，对模型进行各维度的监控，确定是否迭代，形成模型工作闭环。

模型监控需要每日生成报表，邮件发送相关同事查阅。对于数据量大的金融公司，需要整合大量表，模型监控并不是容易的事。

11.模型迭代

如果监控模型ks，AUC，psi等指标变化太大，需要重新迭代模型

备注：上述模型开发sop只是为大家提供一个参考模板，由于各条业务方差异，不能满足所有场景。希望大家因地制宜，建好最适合自己公司的模型开发sop。

如果大家对金融风控建模感兴趣，可了解《python金融风控评分卡模型和数据分析(加强版)》

如果有论文作业一对一辅导的，还可以与作者联系。

版权声明：文章来自公众号(python风控模型),未经许可，不得抄袭。遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。