第 2 章：常见信用数据源与采集合规要求
做信用评分模型，第一步就是搞清楚数据从哪来。
很多人上来就堆变量，觉得越多越好。我早期也干过这事，结果模型上线一个月就被监管叫停——因为用了没授权的电商数据。嗯，教训深刻。今天咱们就聊聊常见的数据源，以及取数据时必须守的规矩。
2.1 主流信用数据源有哪些？
我把常见的数据源分成四大类。你想想看，用户画像的不同维度，其实就藏在这些数据里。
| 数据类别 | 典型来源 | 覆盖内容 | 获取难度 |
|---|---|---|---|
| 传统金融 | 央行征信、银行流水、信用卡账单 | 贷款记录、逾期、负债、还款习惯 | 高（需用户授权+机构接口） |
| 政务数据 | 社保、公积金、税务、法院执行 | 收入稳定性、就业状态、涉诉风险 | 中（需对接政府部门或第三方） |
| 互联网行为 | 运营商、电商、社交、支付 | 消费能力、社交关系、设备指纹 | 低（但合规风险高） |
| 第三方征信 | 百行征信、朴道征信、同盾 | 多头借贷、欺诈评分、行为标签 | 中（需商务合作+合规审查） |
我个人习惯，先看传统金融数据，这是信用模型的地基。政务数据是支柱，能帮你判断用户有没有稳定收入。互联网行为数据是装饰，用好了能提升区分度，但一旦踩线——整个模型都得推倒重来。
2.2 数据采集合规红线
现在国内最严的就是《个人信息保护法》和《征信业务管理办法》。说白了，不是你能拿到什么数据，而是你能合法拿到什么数据。
2.2.1 用户授权——不能碰的铁律
我见过最惨的案例：某团队爬了公开电商评论，给用户打标签，然后直接用于信用评估。结果被用户投诉，罚了年收入的4%。
正确的做法：
- 每个数据源必须有独立的《授权书》
- 授权内容要明确写清楚「用于信用评估」
- 用户可随时撤回授权
- 数据使用期限不能超过授权有效期
2.2.2 数据最小化原则
不是能拿的都拿。你只需要和还款能力、还款意愿强相关的数据。比如：
- 运营商数据：只取在网时长、通话活跃度，不要取具体通话内容、联系人名称
- 电商数据：只取消费金额分级，不要取具体购买商品名称
- 设备信息：只取设备指纹用于反欺诈，不要取通讯录、相册
这个原则在法律里写得很清楚，但实际执行时容易「顺手」多拿一点。我建议在数据采集层做硬编码过滤——不是通过代码逻辑判断，而是直接在ETL里把无关字段扔掉。
2.2.3 数据安全与保存期限
采集来的数据不能永久存着。通常业务结束后5年，或者用户销户后3年，必须删除或脱敏。而且存储过程必须加密，传输通道必须用HTTPS。
我记得有一次审计，对方要求我们演示「数据删除」过程。我们以为删了数据库就行，结果备份服务器还没来得及清。从那以后，我要求团队做数据生命周期管理——从采集到销毁，每一步都留日志。
2.3 数据源选择与合规要求的整体框架
下图是我在实际项目中总结的数据决策路径。你可以对照自己的项目，看看每一步是否走对了。
核心决策链： 业务需求 → 数据源识别 → 合规审查 → 用户授权 → 最小化采集 → 安全存储 → 模型开发 → 定期复审
2.4 不同数据源的合规要求对比
我整理了最关键的四个维度，方便你在选数据源时对照检查。
| 数据源类型 | 是否需要单独授权 | 数据最小化难点 | 典型保存期限 | 跨境传输限制 |
|---|---|---|---|---|
| 央行征信 | 是（单独征信授权书） | 只能查本人，不能查配偶 | 业务关系存续+5年 | 禁止出境 |
| 政务数据 | 是（政务服务授权） | 只取缴费状态，不取明细 | 业务结束后3年 | 一般禁止 |
| 运营商数据 | 是（运营商侧授权） | 只取在网时长、通话活跃度，不取通讯录 | 授权期内+6个月 | 禁止 |
| 第三方征信 | 是（机构间协议+用户授权） | 关注输出结果，不要回传原始数据 | 按合作协议约定 | 需备案 |
好，关于常见数据源和合规要求就讲到这里。记住一句话：数据质量决定模型上限，合规风控决定模型生命。下一轮我们聊聊怎么把这些原始数据清洗成可以喂给模型的「干净变量」。