穿透式监管体系的“三体系一系统”中，智能化监管系统是技术载体，而规则模型是智能化监管系统的“智能中枢”。
国资委15号文明确要求“积极构建重点领域内控监管规则模型”。没有规则模型，系统就只是一个数据汇集平台，无法自动识别风险、无法自动触发预警、无法形成管理闭环。
但实际推进中，企业都面临同样的难题：规则模型到底是什么？它和传统的风险指标、内控检查表有什么区别？应该设计哪些模型、怎么设计、设计出来怎么用？
本文从规则模型的分类、设计理念与方法、具体模型清单、全生命周期管理等方面，系统阐述穿透式监管规则模型应当如何设计和落地。
01 穿透式监管领域规则模型的分类
在展开设计方法讨论之前，先厘清一个基础问题：穿透式监管领域的规则模型，到底有哪些类型？
（一）按技术形态分：结构性规则、行为性规则、关联性规则
从技术实现的角度，规则模型可以分为三类。
1. 结构性规则模型。基于财务报表逻辑和结构化数据，通过设定的阈值和公式进行自动判断。特点是判断逻辑清晰、数据来源明确、可完全自动化运行。
典型场景包括资产负债率超过监管上限、关联交易占比超过阈值、利润总额同比异常波动等。这类模型，往往只是穿透式监管领域的子模型，其开发相对简单，只要有数据即可部署，是建设初期优先部署的类型。
2. 行为性规则模型。基于业务流程异常，通过对业务操作行为的模式识别来判断是否存在违规。其特点是判断逻辑需结合业务流程特点设计，可能需要多条件组合判断。
典型场景包括审批流程绕过规定节点、合同签订时间晚于履约时间、付款审批先于合同签订等。这类模型的开发需要业务部门的深度参与，确保规则逻辑符合业务实际。
3. 关联性规则模型。基于多源数据交叉验证，通过不同数据源之间的比对来发现隐蔽的关联关系和风险传导路径。特点是需要数据贯通作为前提，往往涉及多个业务系统的数据关联分析。
典型场景包括供应商工商信息与内部人员关联关系排查、合同方与收款方不一致检测、招标投标中多次出现相同投标人组合识别等。这类模型的开发难度最大，需要在数据治理基本完成后才能部署。
这三类模型的技术难度逐级递增，企业在建设初期应优先部署结构性规则模型，积累经验后再逐步扩展。
（二）按监管场景分类：合规校验类、风险监测类、关联穿透类、行为分析类
深入分析穿透式监管的十大重点领域，规则模型还可按应用场景进行分类。
1. 合规校验类模型。用于验证业务操作是否符合制度规定和监管要求，回答“程序对不对”的问题，如投资决策程序合规性校验、合同审签倒置检测等。
2. 风险监测类模型。用于持续监控业务数据中的异常波动和风险信号，回答“风险大不大”的问题，如财务数据异常波动监测、大额异常支付监测等。
3. 关联穿透类模型。用于穿透多层级的股权关系、交易关系、资金流向，识别隐蔽的风险传导路径，如股权穿透分析、关联交易识别、围标串标识别等。
4. 行为分析类模型。用于分析业务操作行为的模式，识别异常行为特征，回答“行为正不正常”的问题，如非工作时间支付分析、频繁小额拆分支付识别等。
（三）按运行方式分类：实时拦截类、批量扫描类
从系统的运行方式角度，规则模型还可以分为两类。
1. 实时拦截类模型。嵌入业务流程中，在业务操作发生的瞬间进行校验和判断。一旦触发规则，系统立即执行阻止动作。适用于风险后果严重、判断标准清晰的场景，如大额支付的权限校验、付款与审批的时序校验等。对系统性能要求较高，需在毫秒级内完成判断。
2. 批量扫描类模型。按照预定周期（每日、每周、每月）对全量数据进行扫描分析，发现异常后生成预警信号。适用于不需要实时干预但需要定期监测的场景，如薪酬倒挂分析、投后收益偏离度监控等。
两类模型互补，共同覆盖全场景的风险监控需求。
02 规则模型设计的底层方法
很多人都会问，规则模型的底层原理，到底是什么？为什么它能将业务风险转化为系统可执行的判断？
（一）专家系统：规则模型的学理根基
根据本人研究，规则模型的学术根基可追溯至人工智能领域的专家系统。专家系统的核心思想是将人类专家的知识编码为一系列“条件—动作”规则（即“IF-THEN”规则），由推理引擎在给定事实数据上进行自动推理。
这一技术路径，其实在20世纪80年代就进入商业应用，是知识工程领域最成熟的成果之一。
专家系统的核心在于：它的智能来源不是算法本身，而是嵌入在规则中的人类专家的知识和经验。
这与基于统计学习的机器学习模型有本质区别。机器学习模型从数据中“学习”规律，其推理过程是“黑箱”式的——模型做出了判断，但很难解释“为什么”。
专家系统的推理过程是完全透明、可追溯的——“IF”条件满足，则执行“THEN”动作，每一个判断都可以追溯到具体的规则、具体的条件和具体的输入数据。
在穿透式监管的场景中，可解释性不是锦上添花，而是必要的前提条件。
一条围标串标预警信号，如果系统自己都不能解释“为什么认为这是围标串标”，后续的核查派单和整改跟踪就无从谈起。一个融资性贸易的误报，可能导致对正常业务的错误干预；一个真实风险的漏报，可能意味着国有资产损失。
穿透式监管对可靠性的要求是“确定性地发现问题”，或者至少“发现的问题线索是可追溯、可验证的”。这正是专家系统路径的核心价值所在。
在穿透式监管建设中，一个常见的认知混淆是将规则模型等同于AI大模型。
一些人员认为“规则模型是用AI大模型来生成监管结论，把数据喂进去，让大模型自己判断哪里有风险”。
这完全是两条从底层逻辑到工作机制都存在本质区别的技术路径。
规则模型是基于确定性的“IF-THEN”逻辑。业务人员根据监管政策和风险经验定义明确的规则逻辑，技术人员将其转化为可执行的代码，系统在数据流上持续运行这些规则，满足条件即输出预警。它的输出是稳定的、一贯的。同样的数据输入，无论运行多少次，输出结果完全相同。规则模型不会产生“幻觉”，规则说一不二。
AI大模型则是基于概率预测。它的每一次输出本质上是在计算“下一个词最可能是什么”，而不是在执行确定的逻辑判断。输出带有天然的不确定性，不管怎样优化，都可能产生“幻觉”。生成看似合理但实际上不存在的问题，或者遗漏实际存在的风险。输出的稳定性无法保证，同样的数据输入在不同时间运行可能得到不同的结论。
在穿透式监管的场景中，这个问题不是可以容忍的小瑕疵，而是关系到系统能否被信任的根本问题。规则模型路径是成熟、可靠、可解释的，适合处理违规特征明确、可以被结构化描述的监管场景。
（二）三层原理：从管理意图到系统执行的转化
规则模型，要从管理意图到系统执行再到信号输出，经历三个层次的转化，也存在三层的原理。
1. 业务原理：将控制措施映射为监控方向。规则模型的起点不是技术方案，而是业务风险的识别和管控措施的梳理。企业在长期的经营管理实践中，已经积累了大量的管控措施。穿透式监管所要实现的，就是将这些由人执行的管控措施，转化为由系统自动执行的监控逻辑。
这个转化遵循一条清晰的映射路径。每一项管控措施都针对一个特定的风险场景，这个风险在业务操作层面表现为一种或几种具体的违规形态，每一种违规形态对应一个或多个监控方向。
规则模型不增加新的管控要求，它只是把企业已经在执行的管控措施，从依赖人的自觉升级为依赖系统的刚性约束。
2. 逻辑原理：将监控方向转化为条件表达式。业务原理确立了监控方向，但监控方向仍然是业务语言的描述，系统无法直接理解。逻辑原理要解决“怎么判断”的问题：如何将业务语言描述的违规行为，转化为计算机可以执行的条件表达式。
这个转化的关键，在于对违规行为构成要件的拆解。每一个违规形态都可以拆解为若干构成要件。
如，要认定“程序倒置”，必须同时存在“投资款项已经支付”且“支付日期早于决策审批日期”两个事实。每一个构成要件对应一个数据检查操作，多个条件通过AND、OR等逻辑运算符组合。
刚性触发的规则是单独判定的。只要条件为真，直接输出高风险信号，不参与加权评分；需人工研判的规则是多条组合判定的。单条命中可能只是中风险，多条件叠加且人工确认后才升级为高风险。
3. 技术原理：规则引擎的数据处理与信号生成。条件表达式要真正运行起来，需要一个技术载体——规则引擎。规则引擎的工作原理可以概括为三步：接收数据输入（从各业务系统接口拉取规则所需的数据字段，组装成“事实对象”）、匹配规则条件（将事实对象中的每一个字段值代入条件表达式进行计算，得出命中或未命中的结论）、触发执行动作（如果命中，根据预定义的“控制联动”配置执行控制动作，同时生成预警信号）。
预警信号是一个结构化的数据对象，包含信号ID、规则编号、触发时间、涉及业务对象ID、风险等级、信号描述文本等字段。这个数据对象一旦生成，就进入了预警处置流程的流转。
这三层原理回答了规则模型“为什么能运行”的根本问题。业务原理提供“监控什么”的内容，逻辑原理提供“怎么判断”的推理框架，技术原理提供“如何执行”的运行环境。
（三）六要素方法：从原理到实践的转化工具
三层原理回答了“规则模型为什么能运行”，但具体到设计实践中，还需要一套可操作的方法。这就是本人一直提出的六要素方法论。
一个完整的规则模型，一定包含六个核心要素。六要素之间存在一条不可颠倒的递进关系，前一个要素的产出，是后一个要素的输入。
要素一：风险场景定义，回答“管什么”。将模糊的风险关注转化为边界清晰、可被系统监控的具体业务情景。
风险场景的界定遵循从宏观到微观的路径。首先从业务领域整体出发识别若干大类风险，然后对每一类风险进行细分，直到形成可操作的场景单元。场景划分得越细，后续的规则设计就越有针对性。
界定风险场景需要回答三个问题：这个业务领域的核心流程是什么、关键控制节点在哪里；在这个环节出现过什么问题；监管政策在这个环节有什么特殊要求。
要素二：数据来源梳理，回答“判断依据从哪来”。为每一个监控方向建立运行所需的物质基础。规则模型的准确性从根本上取决于数据来源的完整性、准确性和及时性。没有数据就是无米之炊，数据质量差就是垃圾进垃圾出。确定数据来源需要遵循完整性原则（覆盖规则判断所需的所有数据维度）、准确性原则（数据来源可靠、采集过程规范）、及时性原则（数据能实时或准实时进入规则模型）。
要素三：规则逻辑构建，回答“怎么判断”。将业务专家头脑中的违规判定逻辑转化为计算机可以执行的条件表达式。这是六要素中承前启后的一环。条件表达式的基本形态是“条件组合→结论”，用大于、小于、等于、不等于、属于、不属于、包含、不存在、且、或等符号，将判断逻辑表述为准代码形式。
围绕条件表达式，还需要定义输出信号（规则命中后系统推送的预警描述）、控制联动（规则命中后系统自动执行的操作）等配套属性。
要素四：预警阈值设定，回答“判断之后怎么定级”。在系统做出的所有判断中，区分哪些需要立即干预、哪些需要人工确认。其核心原理是根据规则的可判定性区分两种策略。刚性触发适用于判断边界清晰、不存在灰度空间的规则，一旦命中直接判定为高风险。需人工研判适用于命中后可能存在合理例外情景的规则，命中后标记为中风险，由业务人员结合实际情况做出最终判定。
要素五：响应处置流程，回答“判断结果怎么变成管理行动”。将系统的技术判断转化为可执行、可追问、可闭环的处置动作。处置流程按照风险等级分层展开：高风险触发紧急干预，系统自动执行控制联动，同步生成核查工单；中风险保留业务正常运转，同时生成工单要求限时核实反馈；低风险自动记录至风险台账。处置流程要形成闭环，依赖于责任角色的精确定位、响应时限的明确约束、升级路径的逐级传导。
要素六：模型迭代记录，回答“怎么让模型越用越准”。建立规则模型持续进化的管理机制。业务在变化、制度在更新、政策在演进、数据环境也在变化，模型如果静止不动，从上线那一刻起就在走向失效。迭代触发条件包括制度变更、组织调整、业务新增、监管更新、效能触发、定期评审等。
03 穿透式监管需要设计哪些模型
分类明确了、方法掌握了，接下来要是一个更实际的问题：穿透式监管到底需要设计哪些模型？
（一）政策依据与行业实践
国资委政策文件给出了产权、投资、财务、资金、薪酬分配、金融、采购与供应链、军品业务、合同、境外这十大重点监管领域。
多家央企的实践表明，规则模型的建设应当覆盖十大重点领域，每个领域根据其业务特点和风险特征，可设计若干具体模型。
（二）从风险和问题的监控角度分析模型设计
规则模型的设计，不仅是要符合监管政策要求，更应当从需要“监控什么风险”出发。每一个模型，都对应一个具体的风险场景或突出问题。
1. 产权领域需要重点监控三类风险：产权变动程序合规性（是否履行了规定的审批程序、评估备案程序是否完整）、挂靠经营与虚假控股（工商信息与产权信息是否一致、是否存在无实际经营痕迹的壳公司）、产权交易价格公允性（交易价格是否在合理区间）。
对应的模型，包括产权变动程序合规性校验模型、挂靠经营与虚假控股识别模型、产权交易价格公允性校验模型。
这些模型以合规校验类和关联穿透类为主，涉及产权登记信息、工商数据、交易合同等多源数据的交叉验证。
2. 投资领域需要重点监控四类风险：投资决策程序合规性（审批层级是否与投资金额匹配、决策文件签署日期是否在实施日期之前）、投资概算执行偏差（实际投资额与决策投资额的偏离程度）、投后收益达成率（实际收益与可研预期收益的偏离程度）、控股不控权（名义上控股但实质上失去管理控制）。
对应的模型包括投资决策程序合规性校验模型、投资概算执行偏差监控模型、投后收益偏离度监控模型、控股不控权识别模型。投资是央企资本运作的起点，其模型设计应覆盖从立项到退出的全过程。
3. 财务领域需要重点监控三类风险：财务数据异常波动（关键财务指标同比或环比的异常变动）、关联交易合规性（关联交易金额或占比是否超过监管上限、交易价格是否公允）、合并报表范围合规性（并表范围是否符合规定）。
对应的模型包括财务数据异常波动监测模型、关联交易合规性监测模型、合并报表范围合规性校验模型。财务领域的模型以结构性规则模型为主，基于财务报表数据运行。
4. 资金领域需要重点监控四类风险：大额异常支付（单笔或累计超过设定金额的支付）、非工作时间支付（夜间、节假日的大额支付）、资金归集与账户管理（应纳入未纳入集团资金池的账户、资金归集率不达标）、资金体外循环（资金流向与业务合同不一致）。
对应的模型包括大额异常支付监测模型、非工作时间支付识别模型、资金归集与账户管理监控模型、资金体外循环识别模型。资金领域的模型以实时拦截类和批量扫描类相结合，部分高风险规则需要实时运行。
5. 薪酬分配领域需要重点监控三类风险：工资总额执行（工资总额是否超出核定数）、薪酬与业绩匹配度（薪酬水平与企业经营业绩是否匹配）、同层级薪酬公平性（同层级同类型岗位薪酬差距是否在合理范围）。
对应的模型包括工资总额执行监控模型、薪酬与业绩匹配度校验模型、同层级薪酬公平性分析模型。薪酬领域的模型以批量扫描类为主，按月度或季度周期运行。
6. 金融领域需要重点监控三类风险：融资性贸易（“四流”是否一致）、金融投资风险敞口（投资规模、杠杆率、风险敞口是否超限）、衍生品交易合规性（保证金比例、审批程序是否合规）。
对应的模型包括融资性贸易识别模型、金融投资风险敞口监控模型、衍生品交易合规性校验模型。金融领域的模型以关联穿透类和风险监测类为主，涉及多源数据的交叉验证。
7. 采购与供应链领域需要重点监控四类风险：围标串标（投标人IP地址、MAC地址、投标文件相似度、股权关联关系）、供应商利益冲突（供应商与内部人员是否存在关联关系）、采购价格异常（中标价格是否显著高于市场均价或历史价格）、供应商准入合规性（准入程序是否合规）。
对应的模型包括围标串标识别模型、供应商利益冲突识别模型、采购价格异常监测模型、供应商准入合规性校验模型。采购领域的模型以关联穿透类和行为分析类为主。
8. 合同领域需要重点监控三类风险：合同审签倒置（签订日期晚于生效日期或履约开始日期、审批完成日期晚于签订日期）、合同付款与履约进度不匹配（付款进度与履约进度是否一致）、合同变更频率异常（变更频率是否超过合理范围）。
对应的模型包括合同审签倒置检测模型、合同付款与履约进度匹配校验模型、合同变更频率异常识别模型。合同领域的模型以合规校验类为主，涉及合同信息、审批流程、付款记录等数据的时序比对。
9. 境外领域需要重点监控三类风险：境外投资项目合规性（决策审批程序、风险评估、境外经营负面清单对照）、境外资金异常流动（大额异常跨境资金流动）、跨境数据合规（数据传输是否符合所在国法律法规和国内监管要求）。
对应的模型包括境外投资项目合规性校验模型、境外资金异常流动监测模型、跨境数据合规性校验模型。境外领域的模型需要考虑跨境数据传输的法律合规要求，在确保数据安全的前提下运行。
04 规则模型的全生命周期管理
规则模型不是一次性交付的静态文档，而是需要持续运营的系统组件。从设计到开发到运行到维护，规则模型，要经历多个阶段。
（一）设计阶段：从业务需求到模型文档
设计阶段的任务是将业务风险转化为结构化的模型文档。这一阶段由业务部门主导、内控部门组织、信息化部门参与。
首先由业务部门根据本领域的风险场景和管控需求提出模型建设需求，经内控部门审核、领导小组审批后正式立项。然后由业务专家和规则模型设计师联合开展问题含义理解、合规义务列举、管控规则提炼等工作，逐步形成风险场景定义、规则逻辑构建、预警阈值设定等核心文档。信息化部门同步开展数据来源梳理，确认每个判断变量的数据可获取性。
设计完成后，组织业务部门、内控部门、信息化部门三方联合评审，逐条确认规则逻辑的业务准确性和技术可行性。
（二）开发阶段：从模型文档到可执行代码
开发阶段的任务是将模型文档转化为可执行的技术方案。这一阶段由信息化部门主导，业务部门配合验证。信息化部门依据规则模型设计文档进行规则引擎的配置和开发。
对于结构性规则模型，主要通过配置规则引擎的参数和条件表达式即可完成；对于行为性规则和关联性规则模型，可能需要定制化开发。
开发完成后，在测试环境中进行功能测试、性能测试和安全测试。业务部门参与用户验收测试，验证规则逻辑是否与设计一致。
（三）运行阶段：从模型上线到预警处置
运行阶段的任务是让模型在真实环境中持续运行并产生监管价值。这一阶段由系统自动执行，各责任部门按职责参与预警处置。
模型上线后，按照预定的调度策略自动运行——实时拦截类模型在业务操作发生时即时触发，批量扫描类模型按照每日、每周或每月的周期自动执行。
模型运行的结果——预警信号——自动推送至相关责任岗位。责任人在规定时限内完成核查和处置，在系统中回写核查结论和处置结果。领导小组办公室对预警处置的全过程进行跟踪督办。
（四）维护阶段：从运行数据到模型迭代
维护阶段的任务是根据运行数据持续优化模型。这一阶段由内控部门组织、业务部门和信息化部门协同执行。规则模型的迭代由以下情形触发：监管政策或企业内部制度发生变更、发生新的风险事件或行业内出现新型违规案例、运行数据分析显示命中率或准确率偏离目标区间、按照规定周期进行定期评审。
迭代的流程是：分析运行数据、识别优化方向、修改模型设计、完成历史数据回测、经评审后部署上线。迭代的质量控制是关键环节。规则逻辑修改后，必须用历史数据进行回测，对比修改前后的识别率和误报率。
每一次变更都必须记录版本号、变更内容、变更原因、审批人和生效日期，确保模型的设计意图和演进历史被完整保留。
小结一下：规则模型的设计，根植于人工智能领域专家系统的成熟方法论。它将人类专家的知识编码为“条件—动作”规则，由推理引擎在事实数据上进行自动推理。模型设计好了，穿透式监管才有了真正的“智能”。
