3. 风险数据治理基础
在BCBS 239落地实践中，最常见的失败原因不是技术能力不足，而是概念混淆：把“数据治理”当成“数据管理”，把“数据质量”当成“数据治理”的全部，把“数据架构”当成IT部门的绘图工作。概念一旦错位，责任、流程、工具和度量就会全部走偏。本节先把四个核心概念放在同一张“责任—活动—对象—度量”坐标系中辨析清楚，再给出可落地的判断方法。
一、核心原理：四个概念不是并列关系，而是“决策—执行—对象—评价”的层次关系
数据治理（Data Governance）回答的是“谁在什么权限下对什么数据做出什么决策”。它是一套决策权与问责机制，关注政策、标准、所有权、委员会、升级路径和合规审计。数据管理（Data Management）回答的是“日常用什么流程和工具把数据管起来”，是治理决策的执行落地，包括元数据管理、主数据管理、数据生命周期管理、数据安全操作等。数据质量（Data Quality）回答的是“数据在多大程度上满足使用要求”，是治理与管理共同作用后的结果表现，通常用准确性、完整性、一致性、及时性、唯一性、有效性六个维度度量。数据架构（Data Architecture）回答的是“数据在哪里、长什么样、如何流动”，是治理与管理赖以运行的静态结构与动态路径，包括概念模型、逻辑模型、物理模型、数据分布、血缘和接口规范。
四者关系可以概括为：治理定方向与责任，管理做执行与运营，架构提供结构与通道，质量给出反馈与评价。缺少治理，管理就没有授权和优先级；缺少管理，治理就是空文；缺少架构，质量问题的根因无法定位；缺少质量度量，治理效果无法证明。
二、方法流程：用“四问法”快速定位概念归属
面对一个具体工作项，不要先争论它属于哪个概念，而是按以下四问顺序判断，通常30秒内即可归类：
- 问决策：这件事是否需要确定“谁有权批准、谁承担后果”？如果是，归入数据治理。例如：确定客户主数据的唯一权威来源、审批数据标准变更。
- 问执行：这件事是否已有明确授权，需要日常重复操作？如果是，归入数据管理。例如：每日跑元数据采集、维护数据字典、执行数据脱敏。
- 问结构：这件事是否在描述数据的位置、形态或流动路径？如果是，归入数据架构。例如：绘制风险数据从核心系统到风险数据集市的血缘。
- 问评价：这件事是否在判断数据是否“够用、可信、及时”？如果是，归入数据质量。例如：设定交易对手信用评级缺失率阈值并监控。
三、案例/场景：某银行风险数据平台“同一问题、四种视角”
场景：风险部门发现“交易对手风险暴露报表”中，同一交易对手在不同报表中名称不一致，导致汇总敞口偏差。四个概念视角分别给出不同动作：
| 概念 | 该场景中的具体动作 | 产出物 | 责任角色 |
|---|---|---|---|
| 数据治理 | 裁定交易对手主数据的权威来源，明确数据所有者与数据管家，批准名称标准 | 数据标准决议、问责矩阵 | 数据治理委员会、数据所有者 |
| 数据管理 | 在MDM系统中执行去重、合并、分发，维护元数据与变更记录 | 主数据记录、变更日志 | 数据管理专员、IT运营 |
| 数据架构 | 梳理交易对手数据从核心系统到风险集市再到报表的血缘，定位不一致发生的节点 | 血缘图、接口规范 | 数据架构师 |
| 数据质量 | 设定名称一致性规则，监控各报表匹配率，触发整改工单并跟踪闭环 | 质量规则、监控看板、整改单 | 数据质量分析师 |
若只做质量监控而不做治理裁定，规则会反复告警却无人有权修改源头；若只做治理裁定而不做架构血缘，就找不到不一致发生在哪个系统。四者必须联动。
四、误区/复盘：三个高频混淆及其代价
误区一：把数据治理等同于数据管理。表现：成立“数据治理部”后，日常工作全是跑脚本、补数据、修报表。代价：治理决策无人拍板，标准无法落地，BCBS 239要求的“治理框架”审计不通过。
误区二：把数据质量当成治理的全部。表现：只建质量规则和看板，不建所有权和升级路径。代价：质量问题反复出现，整改无法追责，度量指标好看但业务不信任。
误区三：把数据架构当成IT绘图任务。表现：架构图由IT单独完成，业务不参与，模型与风险口径脱节。代价：血缘断点、口径冲突，风险加总与并表能力无法满足BCBS 239原则3和原则4。
复盘方法：每季度做一次“概念归位检查”，抽取10个已关闭的数据问题，逐一核对是否同时具备治理决策记录、管理执行记录、架构变更记录和质量验证记录。四类记录齐全的问题，复发率通常低于10%；缺失任意两类以上，复发率显著上升。
概念归位检查清单（示例）
[ ] 治理：是否有明确的数据所有者签字？
[ ] 治理：是否形成可审计的决策记录？
[ ] 管理：是否有日常执行流程与工具记录？
[ ] 架构：是否更新了血缘或模型？
[ ] 质量：是否有规则、监控与整改闭环？
[ ] 度量：是否纳入BCBS 239 KPI看板？