第三章：数据源识别与分类
做金融监管数据治理，第一步不是写代码，而是搞清楚——你的数据到底从哪来？
我见过太多团队，一上来就急着做清洗脚本，结果做到一半发现数据源搞错了。嗯，那场面挺尴尬的。所以今天咱们聊聊数据源的识别与分类，这是整个治理工作的地基。
3.1 内部系统数据：核心银行、信贷、风控
内部系统数据，说白了就是银行自己产生的数据。我个人的习惯是，先把它分成三大类：
- 核心银行系统：账户、交易、存款、支付结算
- 信贷系统：贷款申请、审批、放款、还款、逾期
- 风控系统：反欺诈规则、黑名单、交易监控日志
这三类数据有个共同特点——它们都是结构化数据，存在关系型数据库里。但问题在于，不同系统的数据标准往往不统一。
举个例子：核心银行系统里客户ID可能是8位数字，信贷系统里却是12位带字母的编码。你想想看，如果直接关联这两个表，不炸才怪。
我在项目中遇到过最头疼的事，就是某家银行的核心系统升级后，字段名全变了。原来的 cust_id 改成了 customer_identifier，但信贷系统还是老字段。那段时间我天天对着数据字典发呆。
3.2 外部数据：征信、工商、舆情
外部数据就更有意思了。它们不是银行自己产的，而是从第三方买来的或者接口调来的。
| 数据类别 | 来源 | 常见问题 |
|---|---|---|
| 征信数据 | 人行征信中心、百行征信 | 更新延迟、字段定义不一致 |
| 工商数据 | 国家企业信用信息公示系统 | 企业名称变更、注销状态滞后 |
| 舆情数据 | 新闻、社交媒体、监管公告 | 非结构化、噪音大、时效性要求高 |
这里我要特别提醒一点：外部数据的质量你控制不了。我曾经遇到过征信接口返回的数据里，身份证号居然有18个X的情况。你说这能怪谁？只能自己在清洗层做校验。
避坑指南：我曾经因为轻信工商数据的“企业状态”字段，结果把一家已注销的企业算成了正常经营户。后来监管检查时被点名批评。从那以后，我对外部数据一律做“二次校验”——至少比对两个独立来源。
3.3 非结构化数据：合同、影像
这部分是最容易被忽视的。很多团队觉得“反正合同是PDF，存起来就行了”。但监管报送要求你提取合同里的关键条款——利率、期限、担保方式。你怎么办？
非结构化数据主要包括：
- 合同文本：贷款合同、担保合同、补充协议
- 影像资料：身份证扫描件、营业执照照片、抵押物照片
- 录音/录像：双录文件、客服通话记录
处理这类数据，我建议走“先识别、后提取、再结构化”的路线。说白了，先用OCR把图片转成文字，再用NLP抽取出关键字段，最后存到库里。
我的经验：OCR识别率不是100%的。合同里的公章、手写签名区域，经常识别出乱码。我的做法是——对这些区域做“人工兜底”，也就是机器识别后，标记出置信度低的字段，让人工复核。
3.4 知识体系总览
下面这张图，是我自己总结的数据源分类框架。每次做新项目，我都会先拿这张图去跟业务部门对一遍，确保没有遗漏。
3.5 分类后的处理策略
数据源分好类了，接下来怎么办？我个人的做法是，针对不同类型制定不同的清洗策略：
- 内部系统数据：重点做字段映射和一致性校验。比如统一客户ID格式、日期格式、金额精度。
- 外部数据：重点做时效性检查和异常值过滤。征信数据一般T+1更新，工商数据可能滞后一周，你得心里有数。
- 非结构化数据：重点做内容提取和结构化转换。合同里的利率、期限、担保方式，必须能自动抽出来。
一个小技巧：对于非结构化数据，我建议先做“样本标注”。随机抽100份合同，人工标注出关键字段的位置和格式。然后用这些标注数据训练一个简单的抽取模型。别一上来就搞深度学习，有时候正则表达式+规则引擎反而更稳。
好了，数据源识别与分类就聊到这儿。记住一句话：数据源搞不清楚，后面全是白干。下一章咱们聊聊具体的数据清洗技术，到时候我会拿几个真实案例出来拆解。
公众号:蓝海资料掘金营，微信deep3321