一，监管报送项目
1.1“监管报送，1104，一表通”与“银保监会，银行”的关系
1.2监管报送概述
二，监管报送数据流向
2.1流向（ods，dwd，dws，dw）
2.2《S72》报表（具体）
一，监管报送项目
1.1“监管报送，1104，一表通”与“银保监会，银行”的关系
银保监会，现为国家金融监督管理总局，作为中国银行业、保险业的最高监管机构
监管数据：风险监测的基础，政策制定的依据，监管行动的触发器，国际接轨的桥梁
银保监会对银行的监管遵循四大理念：管法人、管风险、管内控、提高透明度
1104报表，名称源自2003年11月4日中国银监会（银保监会前身）启动"银行业金融机构监管信息系统"建设工程
1104报表的本质是一套标准化的监管数据采集工具，要求银行按照统一的定义、口径、格式报送财务和风险数据
与商业银行内部的会计报表不同，1104报表是统计报表而非会计报告，它更关注风险暴露和监管指标，而非单纯的财务业绩（这也是为什么1104报表不能完全由银行系统自动生成，需要专业人员根据监管要求进行加工、转换）
一表通（一表贯通）：整合分散的报送要求，建立统一的监管数据集市，银行按照统一标准准备一次数据，就能满足多种监管报送需求。核心优势在于"全量采集"和"逐层穿透"
一表通与现有系统的关系是渐进替代，过渡期内，银行仍需要并行维护多种报送体系
对于银行，一表通初期投入较大，长期降低合规成本
（1）历史发展维度：1104报表是银保监会早期建立的非现场监管工具，经过近20年的扩充完善，已形成包含数十张报表的庞大体系；一表通是近年来推动的报送方式革新，解决传统报表体系日益复杂、银行负担加重的问题
1104侧重于风险指标的定期汇总，一表通侧重于业务数据的全量采集
（2）数据流向角度：银行作为被监管机构，处于数据生产端；银保监会处于数据接收和分析端
（3）系统兼容性角度：一表通设计时考虑与现有系统的衔接（可以生成1104报表中的大部分统计指标，数据项上有较高匹配度；兼容EAST系统的数据标准），银行可以容易地将一表通数据映射到EAST，减少系统切换产生的转换成本
三类数据源在监管功能上各有侧重、相互印证：
1104报表提供风险全景视图（通过各类监管指标反映银行的整体稳健性）；
EAST系统提供业务明细数据（支持监管机构的深度分析、现场检查）；
客户风险数据聚焦客户维度风险（集团客户和关联交易）
实际应用中，这三种数据源形成监管闭环：银保监会通过1104报表发现异常指标，通过EAST/一表通调取相关明细数据锁定问题领域，结合客户风险数据评估潜在传染效应（指标预警-数据挖掘-风险处置）
1104报表侧重"识别和计量"（标准化指标量化风险水平）；
EAST/一表通侧重"分析和预警"(提供深入挖掘风险根源的数据工具)；
客户风险系统侧重"关联和传染"(防范风险在客户网络间的扩散)
1.2监管报送概述
五个阶段：前期准备、数据治理、系统建设、报送执行、后续管理
1.2.1前期准备
（1）首先明确监管要求（研究相关法规文件、监管指引、报送标准），监管报送的核心目的是让监管机构及时、准确掌握被监管对象的经营状况，风险水平，从而实施有效监管
对于企业，监管报送作为合规要求，也是展示自身管理水平，风控能力的窗口
对于银行，监管报送内容（资本充足率、流动性风险、信贷资产质量等）关键指标，影响监管机构的评级，监管措施
（2）组织架构搭建：企业设立监管报送团队/归口管理部门，（业务专家、技术人员、合规人员）共同负责解读监管要求、设计数据采集方案，确保报送质量
（3）项目计划制定：
时间节点（数据采集、清洗、校验、审核、报送各环节所需时间）
任务分解（大目标拆解为可执行的小任务）
资源分配（确保人力、技术、财务支持到位）
风险预案（预判可能出现问题，准备应对措施）
（4）监管合规意识培养：企业应组织相关人员学习监管政策，报送要求，理解每项数据背后的监管意图和业务含义，"为什么要报这些数据"比"如何填报这些数据"更需要，这种深层次的理解有助于在数据异常时做出正确判断，而非机械完成填报任务
1.2.2数据治理
（1）确定数据来源：不同类型的数据分散于企业各个业务系统（客户信息在CRM系统，交易记录在核心业务系统，风险数据在风控系统），绘制完整的数据地图，明确每个报送指标对应的源数据位置
银行1104监管报表的数据可能涉及七大台账类别（存款台账、贷款台账、同业台账、投资台账、SPV台账、理财台账、其他台账），企业建立统一的监管数据集市，作为"集散中心"，确保数据同源性和一致性
ps：CRM客户关系管理系统（Customer Relationship Management），企业管理与客户关系的工具，收集、存储、管理、分析客户数据
（2）数据提取：关注时效性，完整性，源系统数据结构与监管要求不匹配，需要进行数据转换、映射
（3）数据清洗
（4）数据校验：
表内校验（单张报表内部逻辑关系）
表间校验（不同报表间关联指标的一致性）
总分校验（汇总数据与明细数据互相印证）
跨期校验（数据变化的合理性、连续性）
（5）数据补录：系统无法自动获取某些数据，设计合理的手工补录流程（补录工作由最了解业务实际情况的数据生产部门负责）
（6）据质量监控体系：持续提升报送质量的长效机制，设置数据质量指标（完整性率、准确率、及时率）、定期生成质量报告、分析问题根源推动整改
质量监控不应限于报送前，而应贯穿整个数据生命周期，实现"事前预防"而非"事后纠正"
（7）数据治理文化
1.2.3系统建设
（1）核心架构：前端展示层、业务逻辑层、数据存储层
前端展示层（用户交互，提供数据填报、查询、报表展示界面）
业务逻辑层（业务规则、数据转换逻辑）
数据存储层（数据的持久化存储、管理）
（2）监管数据集市：核心组件，监管报送的专用数据仓库，从各业务系统抽取数据按照监管要求加工
数据集市采用分层设计（隔离业务数据变化、报送逻辑变化），包括标准化层、汇聚层、指标层
标准化层（对源数据清洗、标准化处理）
汇聚层（按照业务主题进行整合）
指标层（生成用于报送的统计指标）
（3）报送流程自动化（4）数据穿透能力
（5）系统集成：监管报送系统不是孤立存在，需要与企业的其它系统进行数据交换、功能协同（打破信息孤岛，实现数据一次采集、多方共享）
集成场景
与核心业务系统的数据对接
与风险管理系统共享风险数据
与合规管理系统联动监控报送合规性
与办公系统集成待办任务和审批流程
（6）技术安全性（7）系统灵活性（8）用户体验
1.2.4报送执行
（1）报送任务管理：明确报送的内容范围、时间要求；分解具体任务并分配责任人；设置各环节的完成时限；监控任务执行进度；处理任务延期、变更情况
（2）数据填报：关注准确性、完整性，由业务部门（最了解业务实质）负责
分为三种
全自动填报（系统直接生成，无需人工干预）
半自动填报（系统生成基础数据，人工进行补充、确认）
全手工填报（无系统支持，完全依赖人工整理）
（3）多级校验机制
分为四种
前端校验（数据录入时检查基本格式、必填项）
业务规则校验（符合业务逻辑、合理性范围）
逻辑关系校验（表内、表间数据的一致性）
专业判断校验（业务专家复核异常数据）
（4）多维度审核流程（5）问题处理机制（6）报送文件生成
（7）报送方式选择
常见四种
在线直联报送（系统对接监管平台自动传输数据）
文件上传（通过监管指定网站上传报送文件）
电子邮件报送（通过加密邮件发送数据）
纸质报送（打印签字后邮寄）
（8）报送确认与回执（9）应急处理预案（10）报送后分析
1.2.5后续管理
（1）报送后续管理（2）监管反馈处理（3）数据质量评估（4）业务制度更新（5）人员培训与能力建设（6）系统功能优化（7）监管趋势预判（8）数据资产应用（9）跨部门协作机制（10）考核激励机制（11）文档与知识管理（12）合规文化培育
二，监管报送数据流向
2.1流向（ods，dwd，dws，dw）
ODS (Operational Data Store操作数据存储/贴源层)
DWD (Data Warehouse Detail明细数据层/数据仓库细节层)
DWS (Data Warehouse Summary汇总数据层/数据服务层)
DW (Data Warehouse数据仓库)
（1）数据源 -> ODS层
数据来源（各类业务源系统）： 银行核心系统、信贷系统、国结系统、理财系统、中间业务平台、反洗钱系统、客户关系管理系统
采集方式
批量抽取：业务低峰期（夜间）通过 ETL 工具（Kettle, Flink, Spark）或数据库同步工具（CDC）进行全量、增量抽取
实时/准实时接入： 要求时效性高的监管报送（反洗钱交易监控、大额交易报告），通过消息队列（Kafka）进行实时流式接入
ODS 层任务
数据缓冲： 接收不同源系统的原始数据
近源存储： 保持源系统表结构、数据内容不变，不做/仅做极少的清洗，是源数据的“快照”
历史数据存储： 保留一定时间的历史数据，用于问题排查、重跑、审计
数据落地： 将流式数据落地成批处理可用的形式
监管报送关联：监管报送所需最原始证据的存储地，报送数据出现质疑、追溯原始记录时，回到ODS层/源系统查询
（2）ODS层 -> DWD层
数据清洗、标准化、整合、建模
数据清洗
处理缺失值，修正错误值，去重，处理异常值
数据标准化
统一编码/代码值，计量单位，日期/时间格式，命名规范
数据整合/集成
关联不同源系统的相关数据，解决数据冲突，构建主数据
维度建模
按照事实表、维度表的方式组织数据
事实表： 存储业务过程的核心度量，包含外键关联到维度表，监管报送的核心原子数据大部分来源于此
维度表： 存储描述性属性，为事实表提供丰富的分析角度
明细粒度： DWD层存储最细粒度的数据
监管报送关联
数据质量保障： 清洗、标准化是保证报送数据准确性的基石
单一事实来源： DWD层为整个数据仓库（包括监管报送）提供统一、可信赖、原子粒度的数据基础，所有后续的汇总、加工都基于此
可追溯性： 保留ODS到DWD的映射、清洗规则，从报送结果追溯到DWD明细，再追溯到ODS原始记录
满足明细报送要求： 部分监管报表需要明细数据，直接从DWD层的事实表（按需关联维度表）获取/轻度加工获得
（3）DWD层 -> DWS层
轻度汇总、预计算公共指标、构建宽表。
按主题/业务域汇总： 基于DWD层的事实表、维度表，按照常用的业务分析维度进行聚合计算
预计算公共指标： 计算常用的、被多个上层应用（监管报送、内部报表、数据分析）共享的指标
构建宽表： 提高查询效率，将多个相关的事实指标、常用的维度属性冗余存储在一张表中，形成“宽表”，减少后续应用层（数据集市）关联查询的开销
数据粒度： 比DWD层粗，通常是按日、机构、产品等维度的汇总值，存储指标结果，而非原始明细
监管报送关联
效率提升：DWS层预先计算大量监管报表所需的共性指标，报送加工过程无需每次都从最细粒度数据开始汇总
一致性保证： 所有使用DWS层指标的应用（不同监管报送任务）都基于同个计算逻辑、口径
支持复杂报表： 监管报表需要多维度交叉统计，DWS层良好的维度建模、预聚合为此提供高效支持
减少对DWD的压力： 常规报送任务只需访问DWS层，避免扫描庞大的DWD明细数据
（4）DWS/DWD层 -> DW (数据集市层/监管报送集市)
面向监管报送的深度加工、指标计算、格式转换、生成报送文件
数据源选择
主要来源DWS： 大部分报送指标直接从DWS层的预汇总宽表/指标表中获取
补充来源DWD： 对于DWS层未覆盖的、需要特殊加工、非常明细的指标，从DWD层抽取加工
监管指标计算
根据具体的监管报表要求（如人行、银保监/金监总局、外管局），进行指标计算、业务逻辑处理
可能需要跨多个DWS表、DWD表关联计算
应用特定的监管规则、校验公式、折算率
数据整合、组装： 将计算出的各项指标，按照监管报表的格式要求进行组装
数据格式转换： 将数据转换成监管机构要求的特定文件格式（XML, CSV, 专线API传输）
数据校验：监管机构要求的特定校验规则（如表内平衡校验、表间勾稽校验、历史波动校验、阈值校验），校验失败的数据记录日志并触发告警，进行人工干预、修正
报送文件生成与加密： 生成最终的报送文件，按要求进行加密
报送记录存储： 存储本次报送的元数据（报送时间、批次、操作人）和报送文件副本（审计、备查）
监管报送关联
最终产出层： 数据流的终点
强业务规则导向：逻辑紧密贴合具体的监管制度文件，是监管要求在技术层面的最终实现
数据质量最后防线： 执行最严格的、针对特定报表的校验规则
审计追踪： 存储报送记录、文件，满足审计要求
2.2《S72》报表（具体，举例）
图片不能大于5mb
举的例子可能太详细了，现已删除
数据流向：银行，1104，一表通
部分手稿
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
