📚 课程目录第2章风险数据基础

2. 风险数据基础

在风险数据治理中，很多团队一上来就谈SLA、谈告警、谈报表延迟，却忽略了一个更前置的问题：我们到底在治理什么数据？它从哪里来、长什么样、被谁使用、为什么必须“及时”？如果对风险数据的定义和边界没有共识，后续的及时性指标就会变成各说各话——业务说“T+1太慢”，数据团队说“已经按批次交付”，最终SLA无法落地。本节先把风险数据的“地基”打牢。

一、核心原理：什么是风险数据

风险数据（Risk Data）是指金融机构在识别、计量、监测、报告和控制各类风险过程中，所依赖的结构化与非结构化数据集合。它不等同于全部业务数据，而是与风险敞口、风险因子、风险缓释、限额、资本计量、合规判断直接相关的数据子集。

判断一份数据是否属于风险数据，可以用三个问题快速筛选：

是否影响风险计量结果？例如敞口金额、违约概率、抵质押品估值。
是否触发风险决策或监管报送？例如大额风险暴露、流动性覆盖率、反洗钱名单命中。
是否被风险报告或SLA明确引用？例如每日风险快报、月度监管报表。

核心原理：风险数据的价值 = 数据准确性 × 数据完整性 × 数据及时性。三者是乘法关系，任何一项趋近于零，整体价值都会崩塌。及时性不是“越快越好”，而是“在风险决策窗口内可用”。

二、风险数据的分类与来源

风险数据可以按风险类型、数据形态和来源系统三个维度分类。理解分类的意义在于：不同类别的数据，其及时性挑战和SLA设计逻辑完全不同。

分类维度	类别	典型数据	主要来源	及时性敏感度
按风险类型	信用风险	敞口、评级、违约概率、抵质押品	信贷系统、评级系统、押品系统	中高（日频/月频）
	市场风险	头寸、估值、曲线、希腊字母	交易系统、估值引擎、行情源	极高（准实时/日频）
	操作风险	损失事件、KRI、控制缺陷	事件管理系统、工单系统	中（事件驱动）
	流动性风险	现金流缺口、HQLA、融资集中度	资金系统、总账、支付系统	极高（日频/日内）
按数据形态	结构化	交易流水、余额、限额	核心系统、数据仓库	取决于业务窗口
	半结构化	日志、报文、JSON接口	网关、消息队列	高（流式场景）
	非结构化	合同、舆情、名单文件	文档系统、外部数据商	低到中（批量解析）
按来源	内部系统	核心、信贷、交易、总账	行内IT系统	可控性较高
	外部数据	行情、评级、工商、司法	数据供应商、监管接口	受外部节奏约束
	人工录入	手工调整、例外审批	Excel、邮件、审批流	最易延迟和出错

从来源看，风险数据的链路通常是：源系统 → 贴源层 → 整合层 → 风险数据集市 → 计量引擎 → 报告层。每一跳都可能引入延迟，而SLA必须覆盖端到端，而不是只盯最后一跳。

三、典型应用场景与及时性挑战

风险数据的及时性挑战，本质上是“风险决策窗口”与“数据生产周期”之间的赛跑。不同场景对及时性的要求差异巨大：

市场风险日内监控：需要准实时头寸和估值，挑战在于行情源延迟、估值引擎排队、多系统头寸汇总口径不一致。
信用风险日终敞口：需要T+1早间可用，挑战在于核心系统批量窗口长、抵质押品估值依赖外部更新、跨系统对账耗时。
流动性风险日间监测：需要日内多次刷新现金流缺口，挑战在于支付系统与资金系统数据不同步、人工调账未及时入账。
反洗钱名单筛查：需要交易发生时或准实时命中，挑战在于名单更新频率、筛查引擎吞吐、误报处理的人工介入。
监管报送：有固定截止时间，挑战在于多源数据口径统一、补录数据回追、版本变更导致的返工。

常见误区：把“数据到达时间”等同于“数据可用时间”。数据到达后还需要校验、清洗、对账、补录、审批，这些环节往往才是延迟的大头。SLA必须定义“可用”的判定标准，而不是“到达”的时间戳。

四、案例复盘：一次日终风险快报延迟的根因分析

某银行每日早8:00需向管理层推送风险快报，但连续一周延迟至10:30以后。团队最初认为是数据仓库调度慢，但复盘后发现根因分布在多个环节：

源系统批量窗口漂移：核心系统因月末结息，批量完成时间从凌晨1:00推迟到3:30，但上游未通知下游调整调度依赖。
外部押品估值文件延迟：供应商文件到达时间从2:00变为4:00，且无到达告警，导致整合层空跑等待。
人工补录未纳入SLA：分行手工调整数据在6:00后才录入，但快报生成逻辑已启动，只能二次重跑。
对账失败重试策略缺失：敞口与总账对账不平，系统默认等待人工处理，无自动降级或标记机制。

改进措施包括：建立端到端数据链路SLA地图，为每个环节定义最晚到达时间和告警阈值；对外部数据源设置到达监控和备用文件机制；将人工补录纳入截止时间管理；对账失败时先出“带标记快报”再追补，而不是阻塞整条链路。

# 示例：风险数据链路SLA监控配置（伪配置）
sla:
  - stage: source_core_batch
    latest_arrival: "03:00"
    alert_if_late: true
    fallback: "use_previous_day_snapshot"
  - stage: external_collateral_file
    latest_arrival: "04:00"
    alert_if_late: true
    fallback: "use_last_known_valuation"
  - stage: manual_adjustment
    latest_arrival: "05:30"
    alert_if_late: true
    fallback: "exclude_and_flag"
  - stage: reconciliation
    latest_arrival: "06:30"
    alert_if_late: true
    fallback: "publish_with_warning"
  - stage: report_publish
    latest_arrival: "08:00"
    alert_if_late: true
    fallback: "none"

复盘要点：及时性治理不是“让某个系统跑得更快”，而是识别链路中最脆弱的依赖，并为每个依赖设计可观测、可告警、可降级的策略。没有降级方案的SLA，只是一句口号。

总结来看，风险数据的定义决定了治理边界，分类和来源决定了链路的复杂度，应用场景决定了及时性的优先级，而及时性挑战则暴露了端到端协作中的断点。只有先把这些基础打牢，后续的SLA指标设计、监控告警和治理机制才有坚实的落脚点。