穿透式监管体系的建设与运行，其本质上是一个将监管要求、风险特征和管理意图转化为可执行、可监控、可追溯的规则模型，并通过穿透式监管系统平台持续运行、不断优化的过程。

可以说，规则模型是穿透式监管的核心，甚至比穿透式监管系统平台还要核心。

规则模型把抽象的制度条文变成具体的判断逻辑，把人工经验变成系统智慧。

穿透式监管的成效，很大程度上取决于规则模型的质量和运行水平。

但是，规则模型也不是“建好即用”的静态工具，而是有一个动态的生命周期。

一个模型从无到有、从运行到迭代，需要经历多个环节？

至少进一步可问，为什么要建这个模型？模型依据什么规则设计？如何技术实现？如何保证质量？运行中如何管理预警线索？如何评价模型是否有效？

本文站在央企穿透式监管的整体框架视角，将规则模型的全生命周期置于其中，对模型的选择、设计、开发、审核、运行到迭代改进与效能评价等六个环节，逐一展开论述。【分为上、下两篇】

每个环节都会说明：做什么、谁来做、怎么做、做到什么标准。

通过这样的拆解，笔者试图揭示这样一个观点：穿透式监管的建设与运行过程，其实就是规则模型的全生命周期管理过程。

管好了规则模型的生命周期，也就管好了穿透式监管的实质。

01 规则模型的选择：要解决的风险或问题框定

规则模型的全生命周期之起点，不是技术开发，而是“选题”。

选错了题，后面所有投入都可能事倍功半。规则模型的选择，本质上是回答一个问题：我们最需要通过模型来穿透什么风险？

（一）选题的基本原则

本文认为，在央企穿透式监管场景下，规则模型的选题应遵循以下原则：

1. 聚焦重大风险。穿透式监管资源有限，模型建设不能“撒胡椒面”。应当优先选择那些发生频率高、损失金额大、监管关注度高、传统手段难以发现的风险场景。例如，虚假贸易、违规资金占用、违规担保、投资偏离主业、招标采购围串标等，往往属于高优先级选题。

2. 回应监管要求。国务院国资委等监管机构对央企提出了一系列禁止性、限制性要求，如“十不准”中对融资性贸易的禁止、对关联交易的管理要求、对投资负面清单的执行等。这些监管红线都是模型选题的直接来源。最直接的监管要求，当然就是国资委2号文、46号令等提出的要求。

模型的作用，就是将这些监管要求，转化为自动化的监测手段。

3. 问题导向。模型选题应当来自真实的痛点。可从巡视审计发现、内外部检查问题、风险事件复盘、业务部门日常困惑中提炼。如果一个风险场景已经被人工反复检查仍频繁出问题，那它很可能适合用模型来持续监测。

4. 数据可行性。一个理想的模型选题，必须能够在现有数据环境中找到支撑。如果所需数据无法采集、无法贯通、质量极差，那么模型即使设计出来也无法运行。因此，选题阶段最好需要信息化部门参与，评估数据可行性。

5. 模型颗粒度适宜。这是一个容易被忽视但极为重要的原则。一个规则模型往往由多条规则组合而成，但模型本身最好聚焦于识别和解决一个特定问题，而不是试图覆盖多个风险。

颗粒度过大，模型规则之间容易相互干扰，预警逻辑混乱，处置责任也难以明确；颗粒度过小，模型碎片化，管理成本高，也难以形成穿透力。

当前模型颗粒度的确定，最佳的是以国资委2号文、46号令以及其他监管文件所指出的具体监管问题为依据。

例如，针对“虚假贸易”这一监管明令禁止的问题，可单独建立一个模型，其中包含若干条关联规则；而不宜将“虚假贸易”、“资金占用”等多个问题混在一个模型中，或者将虚假贸易拆分为多个单项的模型，如“发票异常”、“异常关联关系”等。

一个模型，对应一个监管问题，既便于设计规则、明确责任，也便于后续效能评价和迭代优化。

（二）选题的工作流程与分工

规则模型的选题，不能由某一个部门拍脑袋决定，而应是一个有组织、有论证的过程。

首先，进行风险扫描与需求收集。业务部门结合业务管控需要，提出希望模型监测的风险场景；内控合规部门结合监管动态、审计发现、风险事件，提出合规性监测需求；内部审计部门也可以根据审计中反复出现的问题提出建议。三方信息汇总后，形成初始选题池。

其次，进行筛选与论证。内控合规部门牵头，组织业务、技术、审计等部门对收集到的选题进行初步筛选，评估其重要性、紧迫性、数据可行性和技术可行性。筛选过程中要问几个关键问题：这个风险如果发生，后果有多严重？现在有没有其他手段在监测？数据是否支持自动判断？模型上线后由谁来处理预警？对于颗粒度不清晰的选题，需要在论证阶段予以调整或拆分。

最后，进行优先级排序与立项。经过论证的选题进入模型建设计划，按照风险等级、资源投入和紧急程度排序，报管理层审批后立项。立项文件应当明确模型要解决的具体风险问题、预期效果、责任部门、时间计划。

（三）管理标准

模型选题阶段的管理标准可概括为：风险场景明确、问题定义清晰、颗粒度适宜、数据支撑可行、责任主体落地。

具体而言，建议形成书面的《模型建设需求书》，内容包括风险场景描述、监管依据或制度依据、当前管理现状与痛点、模型监测目标、数据源初步判断、预警处置责任部门建议等。没有清晰需求书的模型，不应进入设计阶段。

举例来说，某企业在穿透式监管系统建设中，最初拟建设“应收账款逾期风险模型”。经过论证后发现，该风险虽重要，但财务系统已有较成熟的账龄分析和催收流程，模型新增价值有限。

而同期审计发现多起贸易业务中“客户与供应商为同一实际控制人”的异常情况，传统手段难以在交易前识别。于是该企业将选题从“应收账款逾期”调整为“关联方隐蔽贸易识别模型”，聚焦于通过股权穿透、工商数据比对识别隐性关联交易，风险针对性大大增强。这个调整正是对颗粒度和问题导向的重新审视。

02 模型的设计：制度理解、数据需求与规则逻辑

选题确定后，便进入模型设计环节。

这是规则模型生命周期中专业含量最高，也最需要多部门协同的环节。

模型设计不是“写几条规则”，而是要把制度语言转化为可计算的逻辑，把数据需求定义清楚，把多个规则组合成能准确预警的模型。

设计阶段不进行实际的数据汇集和治理，但要明确需要什么数据、数据从哪里来、数据应该满足什么条件。

真正的数据汇集与治理，在后续开发环节完成。

（一）制度理解：从条文到逻辑

任何规则模型都有其制度根源。制度理解是将外部监管规定、内部管理制度、业务操作规范转化为规则逻辑的第一步。

这一环节的核心是回答：制度要求什么？违反制度的典型表现（风险体现）是什么？如何用数据特征来识别这些表现（识别逻辑）？

以“融资性贸易禁止”为例。国资委“十不准”明确禁止开展无商业实质的融资性贸易。制度理解需要进一步细化：什么情况下可能构成融资性贸易？

从业务特征看，可能表现为贸易合同约定的货物自始至终未发生实际流转；上游供应商和下游客户为关联方或受同一控制；资金流向与货物流向背离；贸易利润异常固定，与市场波动脱钩；业务周期短、金额大、频次高，呈现出“资金过桥”特征。

这些业务特征，就是后续规则设计的依据。

制度理解的工作应由业务部门和内控合规部门共同完成。

业务部门提供业务场景和操作细节，内控合规部门提供制度依据和合规判断标准。理解不到位，模型就可能“跑偏”，要么漏掉关键风险，要么产生大量误报。

（二）数据需求定义：列出所需数据

制度理解之后，需要回答：哪些数据能够反映上述风险特征？数据从哪来？能否自动获取？质量要求是什么？

在设计阶段，只列出数据需求清单和数据质量要求，不进行实际的数据采集、清洗和关联。这一环节的交付物是一份《数据需求说明书》（该文档属于本人原创的规则模型六要素的一部分）。

数据需求定义包括三个层面。

一，明确需要哪些数据域和数据项。以虚假贸易模型为例，可能需要合同数据（合同签订、标的、金额、期限）、物流数据（发货单、收货单、运输记录）、资金数据（收付款流水、银行回单）、客商数据（工商注册信息、股权结构、实际控制人）、财务数据（收入确认、往来科目、存货变动）等。

二，明确数据来源系统。例如合同数据来自合同管理系统，物流数据来自物流平台或ERP，客商工商数据来自外部数据服务。

三，明确数据质量要求，包括完整性、准确性、及时性、一致性等。例如，客商主数据中统一社会信用代码字段必须完整，缺失率不得高于5%；物流单据必须在发货后48小时内录入系统等。

数据需求定义由业务部门和内控合规部门共同确认，信息化部门参与可行性评估。

业务部门确认数据含义和业务场景，内控合规部门关注数据合规性，信息化部门评估数据获取的技术路径。三方在设计阶段就数据需求达成一致，可避免开发阶段因数据缺失或不达标而返工。

（三）规则逻辑：从单指标到复合规则

数据需求明确之后，需要设计具体的规则逻辑。

规则逻辑是模型设计的核心，它决定了模型“怎么判断”。规则逻辑包括单指标规则、多指标组合规则、阈值设定、条件逻辑等。

单指标规则是最简单的形式，例如“单笔贸易合同金额超过1000万元且无对应物流单据”触发预警。但现实中，单指标往往误报率高。因此，需要将多个指标组合起来。

复合规则的核心思路是：将多个弱信号组合成一个强信号。

以虚假贸易为例，可以设计如下组合规则：规则A，同一批货物在同一时间段内签订多份购销合同，且上下游客户存在关联关系；规则B，贸易合同约定货物直接由上游供应商发往下游客户，本公司不实际控制货权，且资金流向为先收款后付款或存在垫资特征；规则C，贸易业务毛利率异常低（如低于0.5%），且交易对手为贸易类公司而非实体生产企业。当规则A、B、C中任意两条同时满足时，模型判定为“疑似融资性贸易”并触发预警。这样的复合规则比单一规则更精准。

阈值设定需要谨慎。阈值过严，漏报多；阈值过松，误报多，导致业务部门疲于应付。阈值设定应当基于历史数据回测和业务经验，并且在一段时间内允许动态调整。在设计阶段，需要给出阈值的初始建议值，并说明调整机制。

规则逻辑的设计由业务部门主导，因为业务部门最清楚风险特征。但内控合规部门需要审核规则的合规性和完整性，信息化部门需要评估规则的可实现性。三方在设计阶段就应充分沟通，避免规则设计出来无法实现或实现后大量误报。

（四）管理标准

模型设计阶段的交付物应当包括《模型设计说明书》，内容包括制度依据、风险场景描述、数据需求清单、规则指标定义、组合逻辑、阈值设定、预期预警频率等。设计说明书需要业务、合规、技术三方会签确认，作为后续开发和审核的依据。

03 模型的开发与技术实现

模型设计完成并通过评审后，进入技术开发阶段。这一环节由信息化/数字化部门主导，但业务和合规部门不能“甩手”，需要全程参与测试和验收。

开发阶段的核心工作包括数据汇集与治理、模型引擎的配置、系统集成与数据接口实现，以及充分的测试与验收。

（一）数据汇集与治理

开发阶段的第一步，是依据设计阶段输出的数据需求说明书，进行实际的数据汇集和治理。

先治理，再开发，是确保模型运行效果的前提。如果数据质量不过关，模型引擎配置得再精细，预警结果也不可信。

数据汇集包括从各源系统抽取所需数据，建立统一的数据存储和处理环境。技术实现上，需要开发数据接口或数据同步任务，将合同、财务、物流等系统的数据定期抽取到穿透式监管平台的数据层。

抽取过程中要注意不影响源系统正常运行，并保证数据传输的安全性和完整性。

数据治理是数据汇集之后的关键环节。治理的内容包括数据清洗、数据标准化、数据关联和数据质量监控。

数据清洗解决缺失值、异常值、重复记录等问题；数据标准化统一数据格式和编码规则，例如统一日期格式、统一币种、统一客商编码；数据关联建立跨系统数据之间的对应关系，例如将合同编号与物流单号、收付款流水关联起来，形成完整的业务链；数据质量监控则通过规则或报表持续跟踪数据质量，确保后续模型运行的数据基础稳定。

数据汇集与治理由信息化部门主导，但业务部门必须参与数据质量的确认。例如，业务部门需要确认清洗规则是否合理，关联逻辑是否准确，避免因技术处理不当导致数据失真。内控合规部门则关注数据权限和数据安全，确保数据使用符合规定。

（二）模型引擎的配置

数据准备就绪后，核心工作是将设计阶段的规则逻辑配置到模型引擎中。

模型引擎是执行规则运算的技术组件，它负责将输入数据与规则进行匹配，产生预警结果。模型引擎的配置质量，直接决定模型是否忠实还原设计意图。

模型引擎的配置通常有两种方式：一种是使用商业或开源的规则引擎，如Drools、EasyRules等，通过配置界面或脚本将规则逻辑写入引擎；另一种是自研规则引擎，根据企业自身技术架构定制开发。无论采用哪种方式，配置过程都需要遵循以下要点：

一是规则的结构化表达。将设计说明书中的自然语言规则转化为引擎可以理解的结构化形式，包括条件、操作符、阈值、逻辑关系等。例如，“贸易合同金额大于1000万元且无对应物流单据”可以表达为两个条件：合同金额 > 1000万元，物流单据数量 = 0，两个条件用逻辑与连接。这部分工作，很多情况下，已在模型设计阶段就予以完成了。

二是规则的分组与优先级管理。一个模型可能包含多条规则，有些规则是强预警信号，有些是辅助判断。在引擎中需要对这些规则进行分组，并设置触发优先级。例如，当规则A和规则B同时满足时，预警等级为高风险；仅规则C满足时，预警等级为中风险。分组和优先级需要在引擎中明确配置，确保预警分级符合设计要求。

三是阈值的动态可调。模型中涉及的阈值（如金额阈值、比例阈值、频率阈值等）应当在引擎中作为可配置参数管理，而非硬编码在代码中。这样便于后续根据运行效果和业务变化进行阈值调整，无需修改代码。配置人员需要为每个阈值设定初始值，并记录调整权限和流程。

四是版本管理。模型引擎中的规则配置应当有严格的版本管理，每次修改都生成新版本，保留修改记录和审批信息。这既便于追溯，也便于在出现问题时回滚到之前的版本。

模型引擎的配置工作虽然由信息化部门的技术人员执行，但业务部门和内控合规部门必须深度参与配置验证。业务人员需要确认规则表达是否准确，阈值是否合理；合规人员需要确认规则配置没有偏离制度要求。配置完成后，应当形成配置文档，作为模型上线审核的依据之一。

（三）系统集成与数据接口

规则模型的运行需要从多个源系统获取数据，系统集成与数据接口的开发是实现自动化运行的基础。

模型需要定期（如每日、每小时或实时）从合同系统、财务系统、物流系统等抽取增量数据，进行清洗转换后，输入模型引擎进行运算。数据接口的稳定性、调度及时性直接影响模型实时性。

集成过程中要特别注意三点：数据抽取不能影响源系统正常运行，应当采用旁路抽取或低峰期调度；数据传输过程要有加密和权限控制，防止数据泄露；数据转换逻辑要经过业务确认，避免因技术转换错误导致模型误判。

（四）测试与验收

开发完成后，必须经过严格的测试才能上线。测试包括功能测试、数据测试、性能测试和用户验收测试。

功能测试验证模型是否按照设计说明书正确执行，规则逻辑是否准确实现。数据测试使用历史数据回测，验证模型能否准确识别已知的风险案例，同时评估误报率。

例如，选择过去一年中已经查实的10起虚假贸易案例，看模型是否能全部或大部分识别出来。性能测试验证模型在大数据量下的运行效率，是否能在可接受时间内完成运算并输出预警。用户验收测试由业务部门和内控合规部门共同参与，从业务视角验证模型的可用性、预警信息可读性、处置流程合理性等。

只有通过测试、得到业务和合规部门签字确认的模型，才能进入生产环境。

（五）管理标准

模型开发阶段的管理标准包括：数据治理到位、引擎配置准确、开发过程留痕、版本可追溯、测试报告完备、UAT签字确认。任何模型不得未经测试直接上线。上线后如发现问题，应通过变更管理流程进行修复，而非直接在生产环境修改。

【未完待续】

作者介绍：陶光辉，律师、高级经济师、法学院客座教授，中国管理科学学会理事、中国人工智能学会会员等。擅长领域：穿透式监管、风险管控数智化升级，治理风险与合规（GRC）、法治央企建设等。