规则模型的设计与开发操作手册-北京一法企业管理有限公司

15010055730

首页

规则模型的设计与开发操作手册

发布时间：2026-05-09

作者：陶光辉

规则模型的设计与开发操作手册

第一部分

总则

1.1 手册目的与适用范围

本手册为中央企业穿透式监管规则模型的设计与开发提供标准化操作指引。

手册以“虚假贸易”规则模型的开发过程为蓝本，提炼出面向十大重点领域各突出问题的通用方法论，供央企内控合规人员、业务部门联络员、信息化部门技术人员及外部咨询顾问使用。

手册中给出的阈值、参数和示例均为参考值，实际操作中应结合企业具体情况设定。

1.2 规则模型的定位

规则模型在穿透式监管体系中处于智能中枢的位置。它是连接制度要求与技术实现的翻译枢纽——将制度中的管控要求和专家经验转化为系统可执行的判定与处置规则。

规则模型与穿透式监管体系的关系是部分与整体的关系，体系是总目标，规则模型是实现这一目标的核心工程。

规则模型与系统平台的关系是灵魂与载体的关系，平台的功能需求由规则模型驱动，平台为规则模型提供运行环境。

规则模型与数据底座的关系是需方与供方的关系，数据治理任务由规则模型的数据需求牵引，规则模型需要什么数据就优先治理什么数据。

1.3 手册结构

本手册按工作推进的逻辑编排，共八个部分。首次使用者建议按顺序通读，有经验的使用者可将第四至第七部分作为独立工作指引对照执行。

第二部分模型层级框架

2.1 规则模型体系的层级概述

规则模型体系遵循“领域—突出问题—规则模型—监控方向—风险场景—规则逻辑—规则条目”的多层递进结构。每一层都有明确的功能定位和颗粒度标准。

最上层是领域层，十大重点领域各自对应一个完整的规则模型体系。一个领域的模型体系包含该领域内全部突出问题所对应的全部规则模型的总和。

领域之下是突出问题层，突出问题来源于国资委典型问题清单，是规则模型的基本组织单元。一个突出问题通常对应一个独立的规则模型，但涉及面广、场景类型多样的突出问题可拆分为多个规则模型。

突出问题之下是监控方向层。监控方向是将突出问题具体化为可操作的切入视角，每个监控方向锚定突出问题的一个核心特征，方向之间边界清晰、不交叉重叠，合起来覆盖突出问题的主要维度。

监控方向之下是风险场景层。风险场景是违规行为在业务实践中的具体表现形态，需要达到可监控的颗粒度——有明确的数据源、可量化的判断标准和清晰的责任主体。如果某个场景无法满足这三项标准，在模型中的优先级就应降低。

风险场景之下是规则逻辑层。一条规则逻辑是由若干规则条目通过“与”“或”“非”三种逻辑运算符组合而成的完整判定单元，能够独立作出是否触发预警的决策，是模型运行的最小独立单元。

规则逻辑之下是规则条目层。规则条目是原子化的单一判断，每个条目只包含一个判断变量、一个判断算子和一个阈值或比对值。数据来源精准匹配到规则条目层级。阈值是规则条目的有机组成部分。

2.2 层级示例

以虚假贸易“货权实控验证”方向下的“货权转移证明缺失”场景为例。凭证核验规则逻辑由三个条目通过与逻辑组合而成：条目一，合同金额大于等于一百万元；条目二，超期天数大于十个工作日；条目三，货权凭证全部缺失。三个条目全部满足时规则逻辑触发预警。

第三部分开发准备

3.1 资料收集

资料收集分为管理侧、业务侧和技术侧三类，分别回答“规则要监控什么、依据是什么”“业务怎么跑、哪个环节容易出问题”“数据能不能拿到、规则能不能实现”三个问题。

三类资料缺一不可。只有管理侧资料，规则就成为脱离业务的空中楼阁。只有技术侧资料，规则就失去了合规性和业务合理性的根基。

管理侧资料包括政策文件与监管要求、内部制度与管控要求、历史问题与典型案例。操作者应逐条拆解政策条款为可监控的具体要求，并将每份资料与监控方向形成映射矩阵。内部制度中的审批限额和授权层级是后续设定阈值的内部依据。历史案例中的违规手法和关键数据特征是规则条目的原型，当初是通过什么数据异常发现问题的，就是规则条目的直接素材。

业务侧资料包括业务流程文档、业务专家经验和业务数据含义与口径。操作者应绘制业务全链条流程图，标注各环节涉及的系统、数据和岗位，形成“流程—系统—数据—岗位”四维对照图。业务专家掌握的隐性知识——那些未被文档化的异常识别经验和判断标准——是规则条目精准表达的关键输入，需要通过深度访谈获取。

技术侧资料包括系统架构文档与数据字典、数据质量现状评估、系统集成与外部数据接入情况。操作者应优先获取核心数据表的字段名、字段类型和是否必填信息，逐字段确认填充率和数据同步时效。如果企业尚未完成穿透测试，建议在资料收集阶段同步开展专项数据质量摸底。

3.2 访谈调研

资料准备建议先行，访谈调研在后。带着初步假设进行访谈，效率远高于完全开放式访谈。

规则模型的访谈与风险评估的访谈存在本质区别。风险评估访谈是“开放式探索”，在风险尚未清晰识别的前提下从零开始发现风险。规则模型访谈是“聚焦式深入”，在突出问题已经确定的前提下，深入细化监管逻辑。

访谈目标分为四个层次。第一层，确认风险场景的表现形态——哪些场景发生过、哪些虽未发生但存在潜在风险。第二层，明确异常信号和数据特征——业务人员通常看哪些指标、关注哪些信号。第三层，了解判断标准和经验阈值——多大金额觉得不对、多长时间觉得异常。第四层，确认处置流程和责任机制——发现后怎么处理、向谁报告、多久能完成。

访谈方式以场景引导式为主。访谈者将预定义的监控方向和风险场景以业务语言向被访者呈现，引导被访者用自己的经验填充场景中的具体细节。辅以案例复盘式，选取一至两个历史案例请被访者复盘当初的发现过程和判断依据。

访谈对象分为业务组和管理组。业务组包括业务部门负责人和资深人员，重点访谈识别异常信号的业务经验和判断标准。管理组包括风控合规、财务和法务部门，重点访谈合规依据、处置责任分工和追责衔接机制。

访谈提纲按六要素结构组织，分四组问题。第一组围绕风险场景的表现形态与判定标准，第二组围绕处置闭环，第三组围绕判断依据与合规标准，第四组围绕历史案例与趋势变化。

访谈记录按七个模块整理：风险场景确认清单、判定逻辑与阈值建议、处置流程与岗位分工、判断依据、历史案例与趋势信息、数据源与系统信息、其他补充信息。不同被访者之间的观点差异应标注，信息缺口应识别并安排补充调研。

3.3 资料与访谈的交叉验证

资料提供制度规定和管控标准，访谈提供实际操作和业务经验，两者可能存在差异。一致性验证将制度条款与管理层访谈中的实际操作描述进行比对，关注制度规定和实际操作是否一致。矛盾点处理关注业务人员描述的违规手法与制度规定是否一致、业务人员给出的经验阈值与制度规定的审批限额是否有显著差异。

交叉验证完成后，将确认的风险场景、判定逻辑、阈值建议整理为设计输入文档，逐场景、逐规则条目标注信息来源。

第四部分模型层级展开

4.1 监控方向的确定

监控方向的确定方法是从突出问题的核心特征出发。如“虚假贸易”的核心特征呈现为“三无”——无真实商业实质、无货权实控、无独立商业利益，据此分解出贸易背景真实性验证、货权实控验证、资金流向闭环验证、合同条款商业合理性验证四个监控方向。

通用方法是提炼政策文件中对突出问题核心特征的界定，将其转化为结构化的监控维度，同时参考行业实践和历史案例中的违规类型划分。

监控方向确定后，逐方向与政策条款进行映射核对，确认每条禁令都有对应的监控方向覆盖。如果存在禁令找不到对应方向，说明监控方向可能存在遗漏。方向之间应边界清晰、不重叠，大面积交叉说明划分不够精准。

4.2 风险场景的分解

风险场景的分解沿着“业务环节—异常表现—可监控信号”的逻辑链进行。先确定监控方向覆盖的业务链条，再识别每个关键节点的异常表现形态。

每个场景必须满足可监控性标准：有明确的数据源支撑、有可量化的判断标准、有清晰的责任主体。虚假贸易模型在四个监控方向下共分解出十三个风险场景。

4.3 规则逻辑的定义

规则逻辑的定义使用“若……则……”结构清晰表达触发条件和输出结果。编写完成后逐条进行可执行性自检：触发条件是否足够具体以至于可以编写代码实现，判定所需数据字段是否已经定位，输出结果是否明确。

4.4 规则条目的拆解

规则条目的拆解标准是原子化——一个条目只做一个判断，一个条目只有一个判断变量，一个条目只有一个阈值或比对值。条目之间通过“与”、“或”、“非”三种逻辑运算符组合为规则逻辑。 “与”逻辑适用于多个必要条件缺一不可的场景，“或”逻辑适用于任一疑点成立即可的场景，“非”逻辑适用于将合理业务场景从预警范围中剔除。

第五部分六要素全维度设计

5.1 六要素概述及其内在逻辑规则模型的六要素是风险场景、数据来源、规则逻辑、预警等级、处置动作、迭代机制。六个要素不是并列的模块，而是遵循一条从业务到技术、从静态到动态的递进逻辑链。

风险场景是逻辑起点，牵引出数据需求。数据来源是技术基础，支撑规则逻辑的计算。规则逻辑是智能核心，触发预警等级。预警等级决定处置动作的力度。处置动作的执行效果反馈至迭代机制。迭代机制驱动风险场景的补充和规则逻辑的优化。六者构成从识别到处置再到优化的完整闭环。

5.2 风险场景要素的设计方法

风险场景要素在层级展开阶段已完成主体工作，此处完成规范化和格式化表达。场景编号采用“方向简称—顺序号”格式，逐场景填写场景名称、违规表现描述和涉及业务环节。

5.3 数据来源要素的设计方法

数据来源精准匹配到规则条目层级，采用“系统名称—数据库表名称—字段名称”的三段式定位。数据可获取性状态分为四级：A级可直接获取，B级需治理后获取，C级依赖外部数据源需标注覆盖率和更新延迟，D级当前不可获取需纳入数据治理任务书。

5.4 规则逻辑要素的设计方法

规则逻辑要素的完整表达结构包括规则逻辑名称、所属风险场景、触发条件和输出结果。规则逻辑内部包含规则条目及其组合方式、核心阈值和综合评分规则。综合评分采用加权计分制，各监控方向的权重依据信号与核心特征的关联强度分配。直接触及核心特征的规则权重要高，具有指向性但单独证明力有限的规则权重相对较低。同一方向内多条规则同时触发时不重复累加权重，避免单一方向的信号过度推高综合评分。

5.5 预警等级要素的设计方法

预警等级分为红色高风险和黄色中风险两级。直接触及核心特征的信号设定为红色高风险，具有指向性但单独证明力有限的信号设定为黄色中风险。

红色高风险意味着违规可能性极高，处置力度为自动阻断业务和立即核查。黄色中风险表明存在异常但需人工判断，处置力度为推送工单、限期核查。

5.6 处置动作要素的设计方法

处置动作按预警等级分层设计。高风险处置包含三项要素：系统自动动作（暂停相关业务流程、生成核查工单）、核查要求（二十四小时启动核查、三个工作日完成核查报告）、超期升级路径（逐级升级至高级管理层）。中风险处置仅推送工单，不自动阻断业务，为人工核查留出判断空间。处置责任主体按“业务部门核查、内控部门验收”的原则分工。

5.7 迭代机制要素的设计方法

迭代机制分为定期迭代和触发式迭代。定期迭代每季度评估命中率和准确率，准确率低于百分之五十的规则重点调优。每半年评估覆盖度，判断是否需要补充新规则。触发式迭代在监管政策重大变化或新违规手法出现时立即启动。

迭代流程经过变更提出、影响评估、审批确认、实施部署、验证验收五个环节。版本编号规则为V主版本号.次版本号，规则逻辑根本性调整升级主版本号，阈值微调升级次版本号。停用的规则标注停用日期和原因，不删除历史记录。

5.8 六要素的关联一致性自检

六要素全部设计完成后，进行关联一致性自检。五条检查链路包括：风险场景与数据来源的对应关系、风险场景与规则逻辑的对应关系、规则逻辑与处置动作的对应关系、数据来源与规则条目的对应关系、阈值与预警等级的匹配关系。逐链路检查确认六要素之间逻辑一致、相互匹配，不存在断裂或矛盾。发现的不一致项逐项记录并修正。

第六部分模型部署

部署工作将六要素设计文档转化为系统功能安排，遵循“规则条目配置—规则逻辑编排—预警等级绑定—处置流程配置—综合评分部署—迭代管理配置”六步顺序。

规则条目配置将每条条目逐一配置到规则引擎的决策表中，每个条目包含判断变量、数据来源定位、算子类型和阈值参数。规则逻辑编排通过“与”“或”“非”运算符将条目编排为完整判定流程，设置运算优先级。

预警等级绑定到引擎输出配置，红色高风险触发时并行调用业务阻断和工单生成接口，黄色中风险仅调用工单生成接口。处置流程配置到工作流引擎，包括派单对象、核查时限和超期升级规则。综合评分部署到聚合计算模块。迭代管理配置建立版本控制机制和监控仪表盘。

部署完成后进行单元测试和集成测试。单元测试逐条规则验证触发逻辑和处置流程是否与设计一致。集成测试使用历史真实数据和模拟异常数据，检验模型在多规则并发时的综合表现。测试通过后签署业务技术映射确认单，由业务方逐条确认技术实现忠实于设计文档中的业务要求。

第七部分模型验证

7.1 验证概述

模型验证从完整性、合理性和可行性三个维度进行，分别回答“覆盖得全不全”“判断得对不对”“能不能跑得通”的问题。验证工作由内控部门牵头，业务部门和信息化部门共同参与。

7.2 完整性验证

完整性验证确认监控方向是否全面覆盖突出问题的各项核心特征，风险场景是否穷尽该突出问题在业务实践中的主要表现形态。验证方法是将场景清单与四个信息源交叉比对：政策文件的禁令条款逐条比对，近三年审计发现案例逐案比对，行业监管通报和同类央企典型案例逐类比对，业务专家经验判断比对。比对中发现的覆盖缺口，记录并制定补充方案。

7.3 合理性验证

合理性验证确认规则逻辑的业务准确性和阈值的场景适配性。验证方法包括三项：业务专家逐条确认规则逻辑和阈值与违规判定标准一致；历史案例回测验证规则逻辑能命中全部已知案例；正常案例排除统计误报率并优化排除条件或调整阈值。

7.4 可行性验证

可行性验证确认数据来源的可获取性和系统实现的技术可行性。验证方法是通过穿透测试逐条确认每个规则条目所需数据字段的真实状态：逐系统确认正常运行，逐表确认存在且可访问，逐字段确认存在且类型匹配、填充率达标，逐条目确认数据采集频率满足时效要求。数据风险按四级标准分级处理：可直接获取的规则正常启用，需治理后获取的同步纳入数据治理任务书，依赖外部数据源的标注风险持续关注，当前不可获取的标记为待启用。

7.5 验证通过标准

模型同时满足完整性验证确认覆盖全面、合理性验证确认判断准确、可行性验证确认数据具备可获取性，方可通过验证，按版本V1.0正式部署上线，进入试运行期。

第八部分模型运维与持续迭代

8.1 日常运维

模型上线后，内控部门指定专人负责日常运维。工作内容包括每日查看模型运行状态，确认规则引擎正常运行、预警信号正常推送。每日查看工单处置情况，关注超期未处理工单并按升级规则督办。每周汇总运行数据，统计分析各场景预警触发数量、预警等级分布、工单处置完成率。

8.2 定期迭代

定期迭代每季度评估各条规则的命中率和准确率。准确率低于百分之五十的规则需要重点调优，分析原因并制定优化方案。每半年评估模型的规则覆盖度，结合新的审计发现、行业案例和国资委监管要求，判断是否需要补充新规则。

8.3 触发式迭代

触发式迭代在监管政策发生重大变化时立即对相关规则进行合规性复核和修订。新违规手法被行业通报或本企业出现新型案例时，评估是否需要新增监控方向或风险场景。

8.4 版本管理

版本编号规则为V主版本号.次版本号。规则逻辑发生根本性调整时升级主版本号，阈值微调或排除条件优化时升级次版本号。停用的规则标注停用日期和停用原因，不删除历史记录。所有历史版本的设计文档和运行数据归档保存，确保任何时点都能回溯模型的完整演进过程。每次迭代形成新版本记录，包含版本号、变更内容、变更原因、审批人和生效日期。

附录一：关键模板汇总含监控方向分解表、风险场景清单、规则逻辑定义表、规则条目明细表、数据来源映射表、预警阈值与等级表、处置动作定义表、迭代记录表、综合评分规则说明表、业务技术映射确认单、模型验证报告、访谈提纲模板、资料收集检查清单等模板

附录二：核心术语释义含规则模型体系、突出问题、监控方向、风险场景、规则逻辑、规则条目、阈值、预警等级、处置动作、迭代机制、与逻辑、或逻辑、非逻辑、综合评分规则等核心术语释义注：本文为《规则模型的设计与开发操作手册》简版。

如需详尽版，可见作者主讲的《穿透式监管：从体系设计到平台落地全流程》线上课程资料包。

附：《规则模型的设计与开发操作手册》

（详尽版目录）

第一部分总则

1.1 手册目的与适用范围

1.2 规则模型在穿透式监管体系中的定位

1.3 手册结构导航与使用方法第二部分模型层级框架

2.1 规则模型体系的层级概述

2.2 各层级的功能定位与颗粒度标准

2.3 层级示例第三部分开发准备