第二章：监管数据模型——EAST、1104与数据字典设计
各位同学好，我是老张。今天咱们聊聊监管数据模型这个硬骨头。
说实话，我刚入行那会儿，看到EAST和1104这两套体系，头都是大的。一个要求明细数据，一个要求汇总报表，数据标准还不一样。后来踩了不少坑，才慢慢摸清楚这里面的门道。
这一章，我就把我在项目中积累的经验，掰开了揉碎了讲给你听。
2.1 EAST数据模型详解
EAST，全称是Examination and Analysis System Technology，翻译过来就是「检查分析系统技术」。说白了，就是监管机构要求银行把业务系统的明细数据，按照固定格式报上去。
为什么要报明细数据？你想想看，汇总报表能看出问题吗？很多时候不能。明细数据才能做穿透式监管。
核心要点：EAST的核心是「明细」二字。每一笔交易、每一个客户、每一张合同，都要报。
EAST数据模型有几个关键特征：
- 表结构固定——监管规定了每张表的字段、类型、长度，你不能自己改
- 关系复杂——表与表之间通过主外键关联，比如客户信息表和账户信息表
- 版本迭代快——从EAST 1.0到现在的EAST 5.0，几乎每年都在变
我记得在做一个城商行的EAST项目时，对方IT负责人跟我说：「老张，我们系统里客户性别字段存的是0和1，但监管要求是M和F，怎么办？」
这就是典型的映射问题。我当时的方案是：在报送层做一层数据转换，不改源系统，只改映射逻辑。
我的经验：EAST报送，最怕的是源系统数据质量差。建议在报送前做一次数据质量检查，把空值、格式错误、逻辑矛盾的数据先筛出来。
2.2 1104报表体系
1104报表体系，是银保监会（现在叫金融监管总局）要求报送的监管报表。跟EAST不同，1104是汇总报表，不是明细数据。
1104体系有多大？我数过，核心报表大概有100多张，涵盖资本充足、流动性风险、信用风险、市场风险等方方面面。
这里我列几张最常用的报表：
| 报表编号 | 报表名称 | 报送频率 |
|---|---|---|
| G01 | 资产负债项目统计表 | 月报 |
| G02 | 衍生金融工具业务情况表 | 季报 |
| G04 | 资本充足率汇总表 | 季报 |
| G11 | 资产质量五级分类情况表 | 季报 |
| G21 | 流动性期限缺口统计表 | 月报 |
1104报表的难点在哪？我总结了两点：
- 口径复杂——同一个指标，在不同报表里口径可能不一样。比如「不良贷款」，G01和G11的定义就有细微差别
- 勾稽关系多——表内、表间都有勾稽关系，一个数错了，可能连累好几张表
避坑指南：我曾经遇到过一个项目，客户把G01和G11的「不良贷款」口径搞混了，导致连续三个月的报表都被退回重报。后来我帮他们建了一个口径映射表，才彻底解决这个问题。
2.3 数据元标准
数据元标准，听起来很抽象。其实说白了，就是给每个数据字段定一个「身份证」。
比如「客户姓名」这个数据元，它的标准定义包括：
- 中文名称：客户姓名
- 英文名称：CustomerName
- 数据类型：字符串
- 最大长度：60
- 定义：客户在金融机构开立账户时使用的法定姓名
为什么要搞数据元标准？我举个例子你就明白了。
有一次，我在做数据治理项目，发现同一个「贷款余额」，在核心系统叫LoanBalance，在信贷系统叫CreditBalance，在报送系统叫LoanAmt。三个系统，三个名字，你说怎么对账？
数据元标准就是解决这个问题的。它要求所有系统都用同一个名字、同一个定义、同一个格式。
核心原则：数据元标准遵循「三统一」原则——统一命名、统一定义、统一格式。
目前金融行业常用的数据元标准有：
- JR/T 0013-2004——金融业数据元标准
- 《银行业监管数据元标准》——银保监会发布的行业标准
- 《金融机构数据元注册规范》——数据元注册和管理的规范
2.4 数据字典设计
数据字典，是数据模型的「说明书」。它记录了每个字段的含义、类型、取值范围、业务规则等。
我见过很多团队，上来就建表，建完表就写代码，从来不写数据字典。结果呢？三个月后，新来的同事看不懂表结构，半年后，连写代码的人自己都忘了某个字段是干嘛的。
数据字典应该包含哪些内容？我一般要求团队至少写清楚这几点：
| 字段名 | 数据类型 | 长度 | 是否必填 | 取值范围 | 业务说明 |
|---|---|---|---|---|---|
| cust_id | VARCHAR | 20 | 是 | 客户编号 | 核心系统生成的唯一客户标识 |
| cust_name | VARCHAR | 60 | 是 | 客户姓名 | 与身份证件一致 |
| cust_type | CHAR | 1 | 是 | 1-个人, 2-对公 | 客户类型分类 |
| id_type | CHAR | 2 | 否 | 01-身份证, 02-护照, 03-军官证 | 证件类型代码 |
| id_no | VARCHAR | 30 | 否 | 证件号码 | 加密存储 |
数据字典设计有几个要点：
- 命名规范——我习惯用snake_case，全小写加下划线，比如cust_name、loan_amt
- 类型选择——能用CHAR就别用VARCHAR，能用INT就别用DECIMAL，性能会好很多
- 注释完整——每个字段都要写注释，别偷懒
- 版本管理——数据字典也要做版本控制，我用Git管理
我的小技巧：数据字典写完后，让业务人员审核一遍。很多时候，技术人员的理解和业务人员的理解是不一样的。早发现早修改，比上线后返工强一百倍。
2.5 知识体系总览
下面这张图，是我自己画的监管数据模型知识体系。你看一眼，就能明白这几个概念之间的关系。
这张图你看懂了吗？核心就是：EAST和1104是「要什么数据」，数据元标准是「数据长什么样」，数据字典是「数据怎么存」。四者缺一不可。
好了，这一章的内容就到这里。记住一句话：监管数据模型不是技术问题，是管理问题。技术再牛，数据质量不行，一切都是白搭。
公众号:蓝海资料掘金营，微信deep3321