4. 风险数据治理框架

风险数据Single Source of Truth（SSOT）不是一套工具的上线，而是一套治理框架的落地。很多机构在SSOT建设中把80%的预算投在平台和数据集成上，却只留20%给治理机制，结果往往是"数据接进来了，但没人认账、没人维护、没人对质量负责"。本章聚焦治理框架的五个支柱——组织、制度、流程、标准、考核，说明它们各自解决什么问题、如何协同支撑SSOT，以及缺失时会出现什么典型故障。

一、核心原理：五支柱如何支撑"唯一可信源"

SSOT的本质是"同一风险指标，在全机构范围内只有一个权威定义、一个权威数值、一个权威责任人"。要维持这个"唯一性"，需要五类机制同时作用：

• 组织：解决"谁决策、谁执行、谁使用"的权责归属问题，是SSOT的骨架。
• 制度：解决"凭什么这么定、违反怎么办"的规则依据问题，是SSOT的合法性来源。
• 流程：解决"数据从产生到消费如何流转、变更如何审批"的运转问题，是SSOT的血管。
• 标准：解决"口径、格式、编码、质量阈值如何统一"的一致性问题，是SSOT的度量衡。
• 考核：解决"做得好不好、有没有动力持续做"的驱动力问题，是SSOT的发动机。

五者缺一不可：只有组织没有标准，会出现"多头定义"；只有标准没有考核，标准会逐渐形同虚设；只有流程没有制度，流程遇到争议就会停摆。SSOT的稳定性，来自这五个支柱形成的闭环。

二、方法流程：五支柱的落地动作

把五支柱从概念变成可执行动作，建议按以下顺序推进，每一步都有明确的交付物：

1. 组织先行：设立风险数据治理委员会（决策层）、数据Owner（业务层）、数据Steward（执行层）三级角色。交付物是《风险数据权责矩阵》，明确每个风险域（信用、市场、操作、流动性）的Owner与Steward。
2. 制度配套：发布《风险数据管理办法》《数据标准管理细则》《数据质量问责办法》。制度要写清"谁在什么时限内响应什么请求"，而不是只写原则。
3. 流程固化：定义数据需求提出、标准评审、变更审批、质量事件处置四条核心流程，并嵌入工单系统。交付物是流程图与SLA。
4. 标准落地：建立风险数据标准库，覆盖指标口径、代码集、元数据、质量规则。每个标准都要有版本号和生效日期。
5. 考核闭环：将数据质量指标（完整性、及时性、准确性、一致性）纳入部门KPI，按季度发布数据质量报告并挂钩绩效。

三、案例场景：某银行风险数据口径冲突的治理过程

某银行在建设风险SSOT时，发现"不良贷款率"在信贷部、风险部、财务部三个报表中数值不一致，差异最大达0.8个百分点。排查后发现：

• 组织问题：该指标无明确Owner，三个部门各自定义。
• 标准问题：逾期天数计算口径不同（是否含宽限期、是否含展期）。
• 流程问题：口径变更无审批记录，历史版本无法追溯。
• 考核问题：数据质量未纳入KPI，无人主动纠偏。

治理动作：由风险数据治理委员会指定风险部为Owner，发布统一口径标准（含宽限期、不含展期），在工单系统中固化变更审批流程，并将"口径一致性"纳入三部门季度考核。三个月后，该指标在全行报表中实现100%一致。这个案例说明：SSOT的障碍通常不是技术，而是治理机制的缺位。

四、误区与复盘