在《从DRP到RCB——风险管控数智化升级的系统平台｜风险管控的数智化升级系列之三》中，我们分析了DRP数据底座与RCB风控大脑的建设路径，并在《风险模型——风险管控数智化的核心引擎｜风险管控的数智化升级系列之四》之中探讨了风险模型的设计方法。

由此，从理念到管理，从数据到模型，一个完整的数智化风险管控体系及系统平台——RCB，已然清晰。

那么，这套体系和系统，可用来干什么呢？当前国资委要求央国企构建的穿透式监管系统平台，与这个RCB又有什么关系吗？

这个问题，与下面这个问题紧密相关。

企业应当如何在满足监管要求的同时，避免“为穿透而穿透”的形式主义，真正让穿透式监管服务于自身的风险管控？

本文从风险管控数智化升级的视角出发，试图回答这些问题。

我们不对穿透式监管进行详细的政策解读，这个工作我们之前以及很多同行都已做了。

我们现在聚焦于一个问题：如何利用RCB平台，将“全级次、全链条、全过程、全要素穿透”的监管要求，转化为可落地、可运行、可持续的技术与管理能力？

这种操作既可满足监管的要求，也成为企业提升自身风险管控水平的契机。这个“一举两得”的满足方式，正是笔者参与多个穿透式监管项目所得到的一手经验。

一、穿透式监管的要义与面临挑战

1、穿透式监管的核心要义

穿透式监管并非新概念，其核心要义，一般用“四个全”来概括：

全级次穿透：监管视野需纵向穿透所有产权层级，从集团总部延伸至最底层的子公司、项目公司乃至境外实体，消除“控股不控权”的监管盲区。

全链条穿透：对投资、采购、资金、合同等关键业务，从发起、审批、执行到完结的全链条进行监控，不留断点。

全过程穿透：对重大事项的决策、执行、监督、评价全过程进行跟踪，实现“事前有预警、事中有控制、事后可追溯”。

全要素穿透：将财务数据、业务数据、风险数据、合规数据、内控数据等全要素纳入监管范围，实现数据融合、信息贯通。

这“四个全”，就是让监管者（无论是国资委还是集团总部）能够看到底层真实情况，而不是经过层层加工、修饰的汇总报表。

2、企业落地穿透式监管的主要挑战

尽管这个监管要求明确，但企业在实际落地过程中，却普遍面临四大挑战。

一是数据获取难。穿透式监管要求从最基层的经营单元直接采集原始数据。对于大型集团企业，这意味着要连接几十个甚至上百个子公司的业务系统，数据接口千差万别，数据标准各自为政。一些子公司甚至还在使用纸质单据或Excel台账，根本没有可对接的系统。数据获取的难度和成本远超预期。

二是规则定义难。穿透式监管要求企业将内控监管要求转化为规则模型。但规则的定义并非易事。哪些指标需要监控？预警阈值设多少？如何平衡“漏报”和“误报”？这些问题没有标准答案，需要结合企业自身的管理成熟度和风险偏好来探索。而且，规则不是一劳永逸的，需要随业务变化和监管更新持续调整，这对企业的规则管理能力提出了很高要求。

三是处置闭环难。规则模型触发了预警，谁来处理？怎么处理？多久处理完？如果企业没有建立明确的预警处置流程和责任体系，预警就会变成“只报不处”，穿透式监管沦为形式。但建立处置闭环，涉及业务部门、风控部门、审计部门的协同，涉及绩效考核和责任追究，这是管理层面的深层变革，这比技术建设还要复杂。

四是投入产出难平衡。穿透式监管体系建设需要大量投入。系统建设、数据治理、规则开发、人员培训，每一项都需要真金白银。短期内，这些投入的效果可能不明显——风险事件没有减少（因为本来就不多），监管检查通过了（但这是及格线），管理层感受不到“价值”。如果投入产出无法被清晰呈现，项目很容易在建设中期因资源不足而夭折。

以上四个挑战，单靠任何一项都无法解决。技术平台（如RCB）可以解决数据采集和规则执行的问题，但不能代替企业建立处置流程和问责机制。反过来，如果企业建立了完善的制度，但没有技术平台支撑，穿透式监管也只能停留在纸面。

因此，穿透式监管的成功落地，必须是“管理+技术”的双轮驱动。

二、RCB作为穿透式监管的技术载体

我们前面已介绍了RCB（风控大脑）的架构与功能，从穿透式监管落地的需求来看，RCB恰好可提供解决上述挑战的技术支撑。

1、RCB如何支撑“全级次穿透”

RCB的数据集成层与DRP（数字资源管理平台）无缝对接。DRP负责从各级子公司的业务系统采集原始数据，无论子公司的层级有多深、数量有多少，只要其业务系统能够通过API或数据库接口与DRP连接，数据就能被统一汇聚。

对于那些尚不具备信息系统的基层单位，DRP可以通过标准化的数据填报模板（Excel上传、网页表单）实现数据采集，待其系统建设完成后，再切换为自动采集方式。

在RCB的展示交互层，集团总部用户可以通过高管驾驶舱查看任意子公司的风险态势。驾驶舱支持钻取功能：从集团整体风险热力图，下钻到某个二级板块，再下钻到某个三级子公司，再下钻到该子公司的具体风险预警事件，再下钻到触发预警的原始业务单据。这种层层钻取、直达源头的能力，正是“全级次穿透”的技术实现。

2、RCB如何支撑“全链条穿透”

RCB的风险监测预警模块与规则引擎联动，可以实现对业务流程全链条的实时监控。以采购业务为例：从采购需求提报、供应商寻源、招投标、合同签订、订单下达、收货验收、发票校验到资金支付，RCB可以在每一个节点设置规则模型。当一笔采购订单的供应商触发黑名单规则时，系统在订单环节即预警；当验收单数量与订单数量不符时，系统在验收环节即预警；当付款金额超过合同约定比例时，系统在付款环节即拦截。这种贯穿全链条的监控，确保了风险在任何一个环节都不会被遗漏。

更重要的是，RCB的数据贯通能力使得跨节点的关联分析成为可能。例如，系统可以自动将同一笔采购的订单、合同、验收单、发票、付款单关联起来，形成完整的业务链路视图。如果某个环节缺失（如有订单无验收、有验收无发票、有发票无付款），系统可以自动识别并预警。这是传统依赖人工核对的方式完全无法比拟的。

3、RCB如何支撑“全过程穿透”

RCB的预警闭环处置功能，实现了对风险事件全过程的跟踪。当规则模型触发预警时，RCB自动创建处置工单，记录预警时间、触发规则、风险等级、关联单据、责任人、处置时限。责任人接收工单后，在系统内填写核查报告、上传证明材料；复核人审核后关闭工单；超时未完成的系统自动升级。整个过程的所有操作、文档、沟通记录都保存在系统中，形成不可篡改的审计轨迹。

对于重大风险事件，RCB还支持启动专项调查流程。调查小组可以在系统中创建调查任务、上传证据、记录约谈纪要、起草调查报告、提出问责建议。整个调查过程全程留痕，便于事后审计和责任追溯。这种全过程穿透，使得管理层和监管机构可以随时回溯任何一个风险事件的完整处置历史。

4、RCB如何支撑“全要素穿透”

RCB的数据底座DRP汇聚了财务、采购、合同、供应商、项目、资产等多个业务系统的数据，实现了跨系统的数据融合。在此基础上，RCB的规则与模型层可以综合利用这些数据，进行多维度的风险分析。例如，一个供应商的风险评估，可以同时考虑其财务数据（资产负债率）、履约数据（交付及时率）、司法数据（涉诉情况）、关联交易数据（与集团内部人员的隐性关系）。这种全要素的数据融合，使得风险判断更加全面、精准。

三、在重点领域设计与部署规则模型

国资委明确的十大重点领域，是穿透式监管落地的主战场。每个领域都需要建设相应的规则模型体系。从技术实现的角度，这些规则模型大多属于规则模型（非复杂的机器学习模型），因为监管要求强调的是“确定性的、可验证的、可追溯的”风险判断。

（一）规则模型的种类划分

对于十大重点领域的穿透式监管要求，可归纳为以下几类典型的规则模型：

合规性校验类规则。例如，“所有合同必须经过法务审查方可签署”，“单笔付款超过100万元需经财务总监审批”。这类规则适用于合同管理、资金管理、采购管理等领域。规则逻辑简单、边界清晰，适合用规则模型实现实时拦截。

阈值监控类规则。例如，“单一供应商采购占比不得超过30%”，“境外项目投资回报率低于8%需预警”。这类规则适用于采购管理、投资管理、境外业务等领域。规则需要设定合理的阈值，阈值可以根据行业基准、历史数据、预算目标等动态调整。

关联分析类规则。例如，“中标供应商与招标经办人之间存在关联关系”，“投标人之间存在股权交叉”。这类规则需要将内部数据（员工信息、供应商信息）与外部数据（工商信息、股权结构）进行关联分析，发现隐性关系。这可能需要图数据库或知识图谱技术的支撑。

时序校验类规则。例如，“付款日期不得早于验收日期”，“合同签订日期不得晚于项目开工日期”。这类规则适用于资金管理、工程建设等领域，通过时间顺序判断业务逻辑的合理性。

状态一致性类规则。例如，“合同状态为‘已终止’的，不得发起付款”“项目状态为‘已竣工’的，不得再列支资本性支出”。这类规则确保业务状态与后续操作的一致性。

（二）规则模型建设的优先级策略

对于全部的十大重点领域不可能同时推进，企业需要根据风险程度、数据条件、监管关注度等因素，制定优先级策略。建议采用“三批次”推进法：

第一批（优先建设）：资金管理、采购管理、合同管理。这三个领域风险集中、数据条件相对成熟、监管要求明确。资金支付是监管的红线，采购是舞弊的高发区，合同是法律风险的主要载体。优先建设这三个领域的规则模型，可以快速见效，积累经验。

第二批（同步推进）：投资管理、境外业务、工程建设。这三个领域风险高但数据条件相对复杂，投资和境外业务涉及多层级、多地域，工程建设涉及大量的现场数据和过程文档。在第一批试点成功的基础上，用积累的经验和数据治理能力逐步覆盖。

第三批（逐步覆盖）：资产管理、担保管理、科技创新、安全生产。这四个领域要么风险相对较低，要么数据基础薄弱，要么规则定义的难度较大（如科技创新风险的量化评估）。可以在前两批运行成熟后，再逐步纳入覆盖范围。

（三）规则模型的生命周期管理

规则模型不是“一建了之”，而是需要持续管理。一个完整的规则模型生命周期包括以下阶段：

需求提出：业务部门或风控部门根据监管要求、风险事件、管理需要，提出新的规则需求。需求文档应包含风险场景描述、数据来源、规则逻辑、预期效果等。

规则开发：规则管理员在RCB规则配置界面中编写规则表达式，并在测试沙箱中用历史数据验证规则的命中率和误报率。

规则审批：规则开发完成后，提交风险管理委员会或授权部门审批。审批通过后，规则进入待发布状态。

规则发布：支持灰度发布——先覆盖小范围业务，观察一段时间确认无误报异常后，逐步扩大到全流量。

规则运行监控：规则发布后，持续监控规则的命中率、准确率、误报率。建立定期报告机制，每月或每季度生成规则运行分析报告。

规则优化与下线：根据监控数据，对规则进行调优（调整阈值、修改逻辑）或下线（当规则长期无命中或已不适用时）。规则的下线也需要审批流程，并记录下线原因。

四、穿透式监管与内控体系的融合

穿透式监管也不是独立于企业现有管理体系之外的体系，而是内控体系在数智化时代的自然延伸。国资委15号文将穿透式监管体系定位为“内控体系建设与监督工作”的重要内容，这意味着，穿透式监管须与内控体系深度融合。

（一）规则模型与内控流程的嵌入

传统的内部控制，主要依靠制度规定和人工执行。例如，制度规定“采购合同必须经法务审查”，但实际执行中，业务人员可能跳过法务审查直接签署合同。穿透式监管要求将控制点嵌入业务流程，变成系统不可绕过的强制节点。

在RCB中，规则模型可以与业务流程管理系统联动。当业务人员在采购系统中提交合同审批时，RCB的规则引擎自动校验“是否已关联法务审查意见”。如果校验不通过，采购系统收到拦截信号，合同无法进入下一审批环节。这种“流程+规则”的融合，使得内控从“人防”升级为“技防”。

（二）规则模型与内控缺陷的联动

传统内控管理中，内控缺陷的发现往往依赖年度内控评价或审计检查，时效性差。在RCB中，规则模型的运行日志天然就是一个内控缺陷的发现源。当一个规则频繁触发预警，且经复核确认为真实风险时，这本身就说明该环节的内控存在缺陷——可能是制度设计不合理，可能是执行不到位，可能是系统控制缺失。

RCB可以将高频预警自动关联到内控管理模块，生成内控缺陷登记，并启动整改流程。这种“预警→缺陷→整改→验证”的闭环，使得内控管理从“周期性体检”变为“实时监控”。

（三）规则模型与风险评估的循环

一体化风险清单是风险识别阶段的产物，规则模型是风险管控阶段的工具。两者之间应该形成持续的循环：风险清单中的风险，应当尽可能转化为规则模型，实现对风险的持续监控；规则模型在运行中发现的新型风险，应当反馈到风险清单的更新中，纳入下一轮风险评估。

在RCB中，风险清单和规则模型可以通过元数据关联。例如，一条规则可以标注其对应风险清单中的哪一条风险。当风险清单更新时，系统可以自动提示需要检查相关规则是否需要调整。反之，当规则模型发现了新的风险模式时，系统可以建议在风险清单中增加新的风险条目。这种循环确保了风险管理不是一次性的项目，而是持续演进的过程。

五、穿透式监管落地的具体路径

穿透式监管的成功落地，不能仅靠技术平台建设，更不能“为了上系统而上系统”。它需要一套系统化的方法，从现状诊断开始，逐步推进领域规划、数据治理、制度建设，最终实现技术与管理的深度融合。

以下是笔者总结的，从管理体系建设视角出发的穿透式监管建设的落地路径，分为六个步骤。

第一步：穿透式监管现状诊断与评估

任何建设都始于对现状的认识。穿透式监管的诊断，不是泛泛的内控评价，而是要聚焦于“四个全”的差距分析。

诊断内容包括：组织层级覆盖现状、业务流程覆盖现状、数据基础现状、规则模型现状、制度支撑现状等。

诊断方法包括：资料研读（制度文件、系统文档、历史风险报告）、访谈（风控部门、信息化部门、业务部门关键岗位）、系统穿行测试（选取典型业务，模拟从发起到完结的全过程，检查数据链路和系统控制点）、数据质量抽样（选取关键数据字段，抽样核查准确性）。

诊断产出是一份《穿透式监管现状诊断报告》，呈现企业当前在“四个全”维度的差距、数据基础短板、规则模型空白、制度支撑不足等。

第二步：穿透式监管领域与模型清单设计

诊断完成后，需要设计穿透式监管的总体蓝图。这一步不涉及具体的技术开发，而是回答“我们要管哪些领域、用哪些规则、达到什么效果”。

设计内容包括：重点领域选择、规则模型清单设计、数据需求汇总、预警与处置机制设计等。

产出文件包括：《穿透式监管建设总体规划》《重点领域规则模型清单》《数据需求矩阵》《预警处置规程》等。

第三步：数据治理需求的逆向推导与实施

这是承上启下的关键一步。很多企业在这个环节犯错。规则模型清单设计好了，数据需求也列出来了，但发现数据要么不存在，要么质量太差，项目卡在这里无法推进。

正确的做法是：在规则模型设计的同时，就开始反向梳理数据治理需求，将数据治理作为前置条件来推进，而不是“等系统建完了再补数据”。

逆向推导的逻辑：从规则模型清单出发，逐条规则检查所需数据是否可获取、质量是否达标。如果某条规则的数据源缺失，就需要启动数据采集建设（如推动子公司上线业务系统、建立数据填报接口）。如果某条规则的数据质量不达标，就需要启动数据清洗和标准化工作。将所有的数据问题汇总，形成《数据治理专项任务清单》，明确每个问题的解决方案、责任部门、完成时限。

数据治理的实施包括：数据标准化，制定集团统一的主数据标准（供应商、客户、物料、科目等编码规则），推动各业务系统按标准改造；数据接口建设，对于已有系统的数据，开发API接口或配置数据同步任务，将数据接入DRP，以及数据质量清洗、数据质量监控等。

产出文件包括：《数据治理专项任务清单》《主数据标准规范》《数据接口开发规范》《数据质量度量规则》等。

第四步：穿透式监管相关制度的制定

穿透式监管不仅需要技术支撑，还需要制度保障。在规则模型和数据治理推进的同时，应同步制定或修订穿透式监管相关的管理制度，使技术运行有章可循、责任有据可依。

需要制定的制度包括：《穿透式监管体系管理办法》、《规则模型管理细则》、《预警处置管理办法》、《数据质量管理办法》等。

这些制度的制定，需要与现有的内控体系、合规体系、风险管理体系衔接，避免成为“孤岛制度”。例如，预警处置流程应当与企业已有的风险事件报告制度、内控缺陷整改制度对接，避免重复流程或标准冲突。

第五步：业务管理制度的修改与完善，以匹配穿透式监管需求

穿透式监管对业务管理提出了更高的要求。一些原有的业务管理制度可能无法支撑穿透式监管的运行，需要进行配套修改。

需要审视和修改的业务制度包括：《采购管理办法》、《合同管理办法》、《资金管理办法》、《境外业务管理办法》等。

业务管理制度的修改，应当与规则模型的建设同步进行。每建设一个领域的规则模型，就同步审视和修订该领域的业务管理制度，确保制度规定与系统规则保持一致，避免“制度说一套、系统做一套”。

修改的原则是：制度条款要尽可能“可数据化”，即将模糊的要求（如“应当充分评估供应商资质”）转化为可量化的、可被系统校验的要求（如“供应商必须通过资质预审，预审材料包括营业执照、ISO证书、近三年审计报告，缺少任何一项系统自动拦截”）。

这既是穿透式监管落地的需要，也是提升业务管理精细度的契机。

第六步：RCB平台部署、规则模型上线与持续运营

在完成上述五步之后，技术平台的部署和规则模型的上线，就变得水到渠成。这一步的核心不是“从零开始建系统”，而是将前五步的成果在RCB平台上一一实现。

平台部署包括：安装和配置RCB系统（或基于已有DRP和规则引擎进行集成），配置数据集成接口，建立与DRP的数据同步链路，配置用户权限和角色。

规则模型上线包括：将规则模型清单中的规则逐一在RCB规则引擎中配置、测试、审批、发布。优先上线第一批重点领域的规则模型，运行稳定后再逐步扩展到第二批、第三批。

人员培训包括：对风控专员进行规则配置和管理培训，对业务部门责任人进行预警接收和处置操作培训，对管理层进行驾驶舱使用培训。

持续运营机制包括：建立规则模型运行监控的月度报告制度，建立数据质量问题的定期通报和整改机制，建立预警处置及时率和准确率的考核机制，建立规则模型年度复审和迭代优化机制。

融入数智化升级进程：穿透式监管的落地，最佳策略不是把它当作一个外部强加的任务来应付，而是将其融入企业的数智化升级进程，与RCB建设、风险模型建设、DRP建设统筹规划、同步推进。

这就是说，企业在推进DRP数据底座建设时，就应当考虑穿透式监管的数据需求；在设计RCB的规则引擎时，就应当考虑规则模型的配置和管理需求；在开发风险分析模型时，就应当考虑与穿透式监管规则的联动。

这也是很多企业领导提出的，既满足监管要求，又提升了自身的风险管控能力。监管检查通过是及格线，而真正的价值——风险的有效防控、损失的成功避免——是远超及格线的回报。

小结一下：透式监管的落地，是监管的刚性要求，也是企业数智化升级的天然应用场景。从RCB平台到规则模型，从DRP数据底座到预警处置闭环，我们所构建的数智化风控平台，恰好为穿透式监管提供了坚实的技术支撑。