3、信用数据体系：数据来源（征信、行为、第三方）、数据维度、数据质量与清洗原则

信用评分模型的本质是“用数据还原风险”。无论算法多么先进，模型的上限始终由数据质量决定。在个人信用评分领域，数据体系是模型的“原材料仓库”，其完整性、准确性和一致性直接影响评分结果的可靠性。本章将系统拆解信用数据的三大来源（央行征信、行为数据、第三方数据）、核心数据维度、以及数据质量治理的实操原则，帮助学员建立从“数据采集”到“数据可用”的完整认知框架。

3.1 数据来源：三大支柱的定位与互补逻辑

3.1.1 央行征信数据：信贷决策的“压舱石”

央行征信系统（金融信用信息基础数据库）是个人信用评分最权威的数据来源。它记录了个人与持牌金融机构之间的信贷往来，包括贷款审批、信用卡使用、担保记录、还款行为、逾期情况以及近两年的查询记录。其核心价值在于“强相关性”——信贷历史是预测未来违约行为最直接的信号。例如，一个连续12个月正常还款的借款人，其违约概率显著低于有“连三累六”（连续3个月逾期或累计6次逾期）记录的人群。

但央行征信也有明显局限：覆盖人群有限（约5亿人有信贷记录，大量“信用白户”无数据）、更新滞后（机构按月报送，T+1或T+2更新）、维度单一（缺乏收入、消费、行为等动态信息）。因此，仅靠征信数据构建的模型，对“白户”和“轻信贷人群”的区分能力不足。

3.1.2 行为数据：洞察“近期状态”的显微镜

行为数据来自用户与金融机构或互联网平台的日常交互，包括APP登录频率、转账流水、消费场景、账单还款方式、设备使用习惯等。这类数据的核心价值在于高频、实时、反映近期状态。例如，一个用户近3个月在借贷APP上的登录次数突然增加，可能暗示其资金紧张；而工资卡流水稳定、消费场景多元的用户，通常还款能力更强。

行为数据的挑战在于：数据量大但噪声高，需要经过特征工程才能转化为有效变量；同时涉及用户隐私合规问题，采集和使用必须遵循“最小必要”原则。在评分模型中，行为数据通常作为“调优变量”而非“基础变量”，用于提升模型在特定人群上的区分度。

3.1.3 第三方数据：扩展风险视角的“广角镜”

第三方数据涵盖司法执行记录、税务缴纳、社保公积金、电商消费、社交关系、多头借贷查询、反欺诈黑名单等。其价值在于补充征信盲区，尤其对“征信白户”和“跨平台风险”的识别。例如，某用户征信记录干净，但第三方数据显示其同时在7家网贷平台申请借款（多头借贷），这通常是资金链紧张的信号。

第三方数据需谨慎使用：数据来源合法性、更新频率、覆盖偏差（如部分人群在电商平台无消费记录）都可能引入系统性偏差。实践中，第三方数据通常用于构建“反欺诈规则”或作为模型中的“辅助变量”，权重不宜过高。

3.2 数据维度：从原始字段到模型变量的映射

信用评分模型通常将数据组织为五大维度，每个维度下包含若干具体字段。理解维度划分有助于特征工程和模型解释。

• 身份特征（Identity）：年龄、性别、学历、婚姻状况、职业、居住稳定性（如居住时长、是否自有住房）。这些变量反映“还款意愿”的基础面。例如，年龄在25-45岁之间、学历本科以上、职业为公务员或大型企业员工的群体，违约率通常较低。
• 履约能力（Capacity）：月收入、负债总额、负债收入比（DTI）、资产状况（房产、车辆）、社保公积金缴纳基数。这是评估“还款能力”的核心。例如，DTI超过50%的借款人，其可支配收入对突发支出的缓冲能力较弱。
• 信用历史（History）：信贷账户数、信用额度使用率、最长账龄、逾期次数/金额、查询次数（硬查询）、公共记录（欠税、民事判决）。这是模型中最具预测力的维度。例如，信用额度使用率超过80%的用户，违约风险显著上升。
• 行为偏好（Behavior）：消费金额/频次/场景、转账对象稳定性、APP活跃时段、还款方式（自动扣款 vs 手动还款）。行为数据能捕捉“近期状态变化”。例如，原本每月消费2万、近3个月骤降至5000元，可能反映收入下降。
• 关联风险（Network）：通讯录中黑名单人数、关联设备数量、紧急联系人风险评分、担保关系。这类数据用于识别“团伙欺诈”和“传染性风险”。例如，某用户通讯录中30%的联系人处于逾期状态，其自身违约概率会上升。

3.3 数据质量与清洗原则：从“能用”到“好用”

3.3.1 数据质量四大维度

数据质量直接决定模型效果的上限。评估数据质量需关注四个维度：

1. 完整性（Completeness）：字段缺失率。例如，某第三方数据源中“月收入”字段缺失率达40%，则该变量无法直接入模，需通过插补或构造替代变量。
2. 准确性（Accuracy）：数据值与真实情况的一致程度。例如，用户填写的职业与社保缴纳单位不一致，需通过交叉验证识别。
3. 一致性（Consistency）：同一实体在不同数据源中的记录是否统一。例如，央行征信中婚姻状态为“已婚”，但第三方数据中显示“未婚”，需设定冲突解决规则。
4. 时效性（Timeliness）：数据反映当前状态的程度。例如，使用6个月前的收入数据评估当前还款能力，可能因失业或换工作而产生偏差。

3.3.2 清洗原则与操作流程

数据清洗不是简单的“删空值”，而是基于业务逻辑和统计方法的系统性工程。推荐遵循以下流程：

• 去重（Deduplication）：同一用户在不同时间或渠道可能产生多条记录，需按唯一标识（如身份证号+姓名）合并，保留最新或最完整记录。
• 缺失值处理：区分“随机缺失”和“系统性缺失”。随机缺失可用均值/中位数/众数插补；系统性缺失（如某渠道用户普遍缺少收入字段）需考虑构造“缺失指示变量”或单独建模。
• 异常值检测：使用IQR（四分位距）或Z-Score方法识别极端值。例如，月收入字段出现“999999”或“0”，需判断是录入错误还是真实值。对于明显错误的数据，可设为缺失或截尾处理。
• 逻辑校验：检查字段间的逻辑关系。例如，年龄为25岁但工作年限为20年，明显矛盾；负债金额大于授信总额，可能存在数据错误。
• 标准化与编码：将分类变量（如职业、学历）统一编码，连续变量进行归一化或标准化，便于模型处理。

3.4 案例拆解：某消费金融公司“白户”评分模型的数据治理实战

背景与约束：某持牌消费金融公司计划面向“征信白户”（无任何信贷记录）群体推出小额现金贷产品，目标是将审批通过率从35%提升至50%，同时将逾期率控制在3%以内。约束条件包括：数据合规要求严格、模型开发周期仅6周、初始样本仅2万条（其中逾期样本1200条）。

初始现象与目标：使用传统评分卡模型时，白户人群因缺乏征信数据，模型区分度（KS值）仅为0.18，远低于有征信记录人群的0.35。模型对白户的拒绝率过高，导致优质客户流失。

关键输入数据：

• 央行征信：仅能获取查询记录（无信贷账户），覆盖率100%但信息量低。
• 行为数据：APP注册信息、登录频次、申请时填写时长、设备型号、运营商在网时长（通过第三方接口获取）。
• 第三方数据：多头借贷查询次数（近7天/30天）、电商消费月均金额、社保缴纳状态、司法黑名单命中。

分析判断过程：

1. 初步探索发现：多头借贷查询次数（近7天≥3次）与逾期率呈强正相关（逾期率高达8.2%）；运营商在网时长≥12个月的用户逾期率仅为1.8%；电商消费月均金额≥2000元的用户逾期率低于2.5%。
2. 数据质量评估：多头借贷数据缺失率15%（部分用户无查询记录），电商消费数据缺失率30%（非电商活跃用户）。若直接删除缺失样本，将损失大量有效信息。
3. 清洗策略：对“多头借贷查询次数”缺失值，构造“是否查询过”指示变量（0/1），并将缺失值填充为0（视为无查询）；对“电商消费金额”缺失值，使用运营商在网时长和APP活跃度进行回归插补。

实际操作步骤：

-- 数据清洗伪代码示例
-- 1. 去重：按身份证号+手机号去重，保留最新记录
CREATE TABLE clean_user AS
SELECT *, ROW_NUMBER() OVER (PARTITION BY id_card, phone ORDER BY create_time DESC) AS rn
FROM raw_user WHERE rn = 1;

-- 2. 多头借贷缺失值处理
UPDATE clean_user SET multi_loan_cnt = 0 WHERE multi_loan_cnt IS NULL;
ALTER TABLE clean_user ADD COLUMN has_multi_loan_flag INT DEFAULT 0;
UPDATE clean_user SET has_multi_loan_flag = 1 WHERE multi_loan_cnt > 0;

-- 3. 电商消费金额插补（使用运营商在网时长和APP活跃度）
UPDATE clean_user SET ecommerce_amt = 
  CASE WHEN ecommerce_amt IS NULL 
       THEN 500 + 50 * carrier_tenure_months + 20 * app_active_days_30
       ELSE ecommerce_amt END;

结果对比：清洗后模型KS值从0.18提升至0.29，审批通过率从35%提升至48%，逾期率控制在2.9%。其中，“多头借贷查询次数”和“运营商在网时长”成为贡献度最高的两个变量。

风险与代价：插补后的电商消费金额存在一定偏差，对非电商活跃用户可能高估其消费能力。为此，模型中对插补样本设置了“插补标记”变量，并在贷后监控中重点关注该群体的表现。

复盘经验：数据清洗不是“一次性工作”，而是需要与模型迭代同步进行。建议建立“数据质量监控看板”，每日跟踪关键字段的缺失率、异常值比例和分布漂移，确保模型上线后的稳定性。