1. 课程导入
欢迎进入《风险数据Single Source of Truth建设》课程。在金融机构、互联网金融平台以及大型企业的风险管理体系中，数据不一致、口径冲突、指标重复计算、报表对不上账，几乎是所有风险数据团队都会遇到的顽疾。业务部门说不良率是2.1%，风险管理部门算出来是2.4%，监管报送口径又是2.3%——同一笔资产、同一个客户、同一个时间点，却出现多个"真相"。Single Source of Truth（单一事实来源，简称SSOT）正是为了解决这一问题而提出的一套数据治理与系统建设方法论。
一、什么是风险数据Single Source of Truth
风险数据SSOT，是指在风险域内，针对关键风险实体（如客户、授信、合约、担保、抵质押物、风险事件、限额、评级、风险参数等），建立一个被全组织公认、唯一权威、可追溯的数据来源。任何下游应用、报表、模型、监管报送，都必须以该来源为准，不得自行维护一套"影子数据"。
需要强调的是，SSOT并不等于"把所有数据物理集中到一张表"。它更准确的含义是：逻辑上唯一、物理上可分布、语义上统一、责任上明确。一个成熟的风险数据SSOT通常包含四个层次：
- 数据标准层：统一风险实体定义、字段命名、码值、计量单位与业务口径。
- 数据模型层：以风险主题域为核心构建概念模型、逻辑模型与物理模型。
- 数据服务层：通过API、数据视图、指标服务等方式对外提供唯一口径的数据。
- 治理机制层：明确数据Owner、Steward、变更流程、质量规则与审计追踪。
二、建设背景：为什么风险数据必须走向SSOT
过去十年，风险数据建设普遍经历了"部门自建、烟囱林立"的阶段。信贷系统、押品系统、评级系统、反欺诈系统、资金交易系统、监管报送平台各自为政，每个系统都维护自己的客户信息和风险指标。这种模式在业务规模较小时尚可运转，但一旦进入强监管、高频交易、精细化资本计量的阶段，问题就会集中爆发。
推动SSOT建设的背景因素主要有以下几类：
| 驱动因素 | 典型表现 | 对SSOT的需求 |
|---|---|---|
| 监管合规 | EAST、1104、巴塞尔III、IFRS9等报送口径不一致 | 统一监管口径与数据溯源 |
| 资本计量 | PD、LGD、EAD参数在不同系统中不一致 | 风险参数唯一来源 |
| 业务决策 | 同一客户在不同报表中风险等级不同 | 客户风险视图统一 |
| 数据成本 | 重复采集、重复存储、重复对账 | 降低冗余与协调成本 |
| 审计问责 | 无法说明数据来源与加工过程 | 端到端血缘与审计追踪 |
从技术视角看，SSOT建设还面临几个现实约束：历史系统改造成本高、数据责任边界模糊、指标口径由多个部门共同定义、实时性与一致性存在天然张力。因此，SSOT不是一次性的IT项目，而是一项持续演进的治理工程。
三、核心原理：SSOT如何让"唯一真相"成立
SSOT能够成立，依赖三个核心机制：唯一性、可追溯性、受控变更。
唯一性要求每个风险实体在组织范围内有且仅有一个权威记录源。例如"客户风险等级"只能由评级系统作为权威源，其他系统只能引用，不能自行修改。可追溯性要求从原始数据到最终指标的全链路血缘可查，任何一次加工、转换、聚合都能还原。受控变更要求数据标准、模型、接口的修改必须经过评审、版本管理和影响分析，避免"悄悄改口径"。
风险数据SSOT参考架构（逻辑分层）
[源系统层]
信贷系统 | 押品系统 | 评级系统 | 交易系统 | 反欺诈系统
| | | |
v v v v
[数据接入层] 采集 / 清洗 / 标准化 / 质量校验
|
v
[SSOT核心层] 风险主数据 + 风险指标 + 风险参数 + 血缘元数据
|
v
[数据服务层] API / 指标服务 / 数据视图 / 监管报送接口
|
v
[应用消费层] 风险报表 | 资本计量 | 监管报送 | 决策分析 | 模型开发
在这个架构中，SSOT核心层是"唯一真相"的物理与逻辑载体，但它并不排斥源系统继续存在。源系统负责生产，SSOT负责统一语义、统一口径、统一服务。
四、典型场景：SSOT在风险域中的落地形态
以某商业银行的风险数据SSOT建设为例。该行原有12个风险相关系统，客户风险等级在信贷系统、评级系统、报表平台中分别维护，导致同一客户在月度风险报告中出现三种等级。建设SSOT后，该行将评级系统确定为"客户风险等级"的唯一权威源，信贷系统与报表平台改为通过API实时获取；同时建立指标口径委员会，任何等级规则调整必须走变更流程并同步更新血缘文档。改造后，监管报送与内部报表的等级一致率达到100%，对账工时下降约70%。
另一个常见场景是押品估值。押品系统、信贷系统、资本计量系统各自记录押品价值，导致LGD计算偏差。SSOT方案要求押品系统作为估值唯一来源，资本计量系统只做引用与快照，并保留估值时点版本，从而保证同一时点的资本计量结果可复现。
五、常见误区与复盘要点
在SSOT建设初期，团队最容易陷入以下误区：
- 把SSOT当成一个大数据库：试图把所有风险数据物理集中，结果项目周期失控。正确做法是先统一语义与服务，再逐步收敛物理存储。
- 只建技术平台，不建治理机制：没有数据Owner和变更流程，SSOT很快会被新的"影子系统"绕过。
- 追求一次性完美口径：口径统一是渐进过程，应先冻结关键指标，再逐步扩展。
- 忽视历史数据迁移：只治理增量、不治理存量，会导致新旧数据长期并存。
- 缺少血缘与审计：无法回答"这个数字从哪来"，SSOT的权威性就无法建立。
六、学习目标与整体课程框架
通过本课程的学习，您将能够：
- 准确理解风险数据SSOT的定义、边界与核心价值。
- 掌握风险主数据、风险指标、风险参数的统一建模方法。
- 设计符合监管与资本计量要求的SSOT逻辑架构与数据服务接口。
- 建立数据标准、数据质量、血缘追踪与变更管理的治理机制。
- 识别并规避SSOT建设中的典型误区，制定分阶段落地路线图。
本课程共30章，整体框架分为六个模块：概念与背景（第1-4章）、标准与建模（第5-10章）、架构与技术实现（第11-17章）、治理与运营（第18-23章）、场景与案例（第24-27章）、演进与复盘（第28-30章）。后续章节将围绕这条主线，从定义出发，逐步深入到模型设计、平台建设、治理机制和行业实践。
在进入下一部分之前，请先思考一个问题：在您所在的组织中，哪一个风险指标最常出现"多个版本"？它背后的权威源应该由谁承担？带着这个问题，我们将开始SSOT的系统性学习。