1. 课程导入

欢迎进入《资本流动性监管报送完整项目实战》。在正式动手写代码、配规则、跑批之前，我们需要先建立一张“全局地图”：监管报送到底在报什么、为什么报、报给谁、数据从哪里来、系统由哪些模块组成、一个完整报送周期包含哪些关键动作。只有把这张地图装进脑子，后续每一章的字段映射、指标计算、校验规则和调度配置才不会变成零散的知识点。

一、学习目标：从“会填表”到“能交付系统”

本课程的目标不是教你手工填写某一张监管报表，而是让你具备独立设计并落地一套资本流动性监管报送系统的能力。具体来说，完成全部30章后，你应当能够：

• 理解监管逻辑：说清资本充足率、流动性覆盖率（LCR）、净稳定资金比例（NSFR）等核心指标的监管意图与计算口径。
• 掌握数据链路：从源系统取数、贴源存储、指标加工、报表生成到监管报送的全链路设计与实现。
• 编写加工规则：能够将监管公式翻译为可执行的SQL或计算逻辑，并处理币种、机构、期限等维度。
• 构建校验体系：设计表内校验、表间校验、跨期校验，并定位与修复数据质量问题。
• 完成项目交付：独立完成调度编排、日志监控、报送文件生成与版本管理。

二、核心概念：先分清四个容易混淆的词

监管报送领域术语密集，初学者最容易在“资本”与“流动性”、“报表”与“指标”、“报送”与“披露”之间打转。下面用一张对比表厘清最核心的四组概念。

需要特别强调的是：报表是“数据容器”，指标是“计算结论”。同一张报表可能支撑多个指标，同一个指标也可能依赖多张报表。系统设计时，报表层负责数据归集与口径统一，指标层负责公式计算与阈值判断，两者必须解耦。

三、整体框架：报送系统的五层结构

一个可落地的资本流动性监管报送系统，通常可以划分为五个层次。下图展示了从源系统到监管报送的完整数据流与模块关系，请结合后续章节反复回看。

这五层不是简单的线性流水线。实际项目中，指标加工层会反向依赖贴源层的明细数据，校验层会同时读取指标层和报表层，监控层则贯穿所有层。理解这种“分层但交叉”的关系，是后续设计调度依赖和排查数据问题的关键。

四、项目全貌：一个报送周期的典型场景

假设你所在银行需要在每月第5个工作日前完成上月LCR和NSFR报送。一个完整的报送周期通常包含以下动作：

1. 数据准备（T+1至T+2）：从核心、信贷、资金等系统抽取余额、交易、现金流数据，完成币种折算和机构映射。
2. 指标加工（T+2至T+3）：按监管公式计算合格优质流动性资产、未来30天净现金流出、可用稳定资金和所需稳定资金。
3. 校验与调整（T+3至T+4）：执行表内平衡校验、表间勾稽校验、跨期波动校验，对异常数据进行业务确认和调整。
4. 报表生成与复核（T+4）：生成监管报表文件，业务部门复核并签字确认。
5. 报送与归档（T+5）：通过监管接口报送，保存报送版本、日志和回执。

五、常见误区与复盘

在过往项目中，初学者最容易踩以下四个坑：

• 误区一：把报表当指标。 直接拿报表合计数当监管指标，忽略口径差异和抵销规则。复盘：先确认监管公式，再反推需要哪些报表字段。
• 误区二：忽视币种与机构维度。 只算本币或全行汇总，导致报送口径与监管要求不一致。复盘：在贴源层就统一币种折算规则和机构树版本。
• 误区三：校验规则后置。 等报表生成后才做校验，问题定位成本极高。复盘：校验应嵌入加工过程，边算边校验。
• 误区四：没有版本管理。 规则变更后无法复现历史报送结果。复盘：规则、参数、数据快照三者都要版本化。

下面是一段典型的报送任务调度配置示例，后续章节会详细讲解每个参数的含义：

job:
  name: LCR_MONTHLY_REPORT
  schedule: "0 2 3 * *"        # 每月3日凌晨2点触发
  depends_on:
    - SRC_EXTRACT_CORE
    - SRC_EXTRACT_LOAN
    - SRC_EXTRACT_TREASURY
  steps:
    - load_source_data
    - calculate_hqla
    - calculate_net_cash_outflow
    - run_validation
    - generate_report_file
    - submit_to_regulator
  retry: 2
  alert_channel: risk-reporting-group