在笔者这2年从事穿透式监管的研究与实务以来，一直认为穿透式监管从政策走向实践，遇到的最大难题之一不是数据不通，也不是系统没建，而是多数人对“模型”这个词本身没有很好理解。

很多企业把模型建设当作技术团队的事，交给信息化部门或者外部厂商去“实现”；很多风控内控人员把规则模型的设计往自身职责之外推脱，觉得其是“技术活”。

这种认知的后果就是：模型设计出来了，业务部门不认；或者业务部门认了，但模型上线后与制度对不上；或者制度也对、模型也跑，但出了问题没人说得清“这条规则到底意味着什么”。

为纠正这种偏差且赋能风控内控人员主动构建模型，在《《穿透式监管体系建设指南》系列二十篇 ┃ 从认知变革到价值实现》之后，本团队启动新的系列——《智能化传统式监管模型设计指南》。

本文认为，规则模型的设计，本质上不是技术问题，而是管理问题。

它触及的核心命题是：谁有权定义风险、谁有权设定标准、谁有权决定处置方式？

这个命题不回答清楚，模型设计就会沦为“技术外包”，风险管控的规则制定权也就在不知不觉中旁落。

01 什么是规则模型

规则模型这个概念，在政策文件中有明确的定位。国资委15号文要求“积极构建重点领域内控监管规则模型”，将规则模型作为穿透式监管落地的核心抓手。

在《穿透式监管模型的设计与实施》一文中，本人将穿透式监管模型定义为“将监管要求转化为系统可执行的判定与处置规则的核心载体”。

需要声明一下，这个穿透式监管模型，在本系列中主要就是指规则模型。

这个定义包含三个关键信息。第一，规则模型的来源是“监管要求”，不是技术人员的想象。监管要求来自国资委2号文的典型问题清单、46号令的追责情形、行业监管的红线规定，以及企业内部的规章制度。

第二，规则模型的形态是“系统可执行的判定与处置规则”，不是文字描述，不是流程图，而是可以被规则引擎读取和执行的条件表达式。

第三，规则模型的功能是“判定与处置”，它不仅要判断“有没有违规”，还要定义“违规之后怎么办”。

更具体地说，规则模型的完整内涵是指将十大重点领域中的监管要求和风险管控逻辑，转化为结构化、可计算、可执行的判定与处置规则体系。

这个定义中有几个需要进一步厘清的地方。

规则模型不等于“模型”这个词的通常含义。

在数据科学领域，“模型”通常指机器学习模型，通过训练数据自动学习规律。规则模型不是“学习”出来的，它是“设计”出来的。

规则模型也不等于企业的“风险模型”。风险模型基于历史数据和统计学习方法，对业务行为的风险程度进行概率评估，输出的是一段连续的风险评分或概率值。

规则模型基于预设的规则和阈值做确定性判断，输出的是“命中”或“未命中”的二值结论。

两者的技术路径、判断逻辑、适用场景完全不同，不能混为一谈。前者是确定性的，后者是概率性的。后面，有专门篇章论述。

02 规则模型的本质

理解了规则模型“是什么”之后，需要进一步理解它“做什么”。

规则模型的本质，可概括为一句话：将制度要求转化为系统可执行判定逻辑的“翻译器”。

这个“翻译”过程包含四个转化。

规则模型将制度文本转化为可执行代码，将专家经验转化为标准化算法，将事后检查转化为实时监控，将模糊判断转化为精准量化。

制度中说“重大投资须经董事会审议”，这是自然语言的表述；规则模型将其转化为“如果投资金额大于等于阈值，且系统中不存在董事会决议记录，则触发预警”，这是计算机可以执行的逻辑。

这个翻译过程的困难，不在于技术，而在于“翻译的准确性”。业务人员说的“重大投资”，在制度中可能指“单项投资金额超过2000万元”，但在某些子企业中可能被理解为“超过1000万元”。业务人员说的“董事会决议”，在系统中可能存在多种记录形式。如果翻译不准确，规则模型就会要么漏报、要么误报。

翻译的准确性，取决于翻译者是否同时理解“制度语言”和“系统语言”。

只懂制度的人，翻译出来的是“制度注释”，不是可执行的规则；只懂技术的人，翻译出来的是“技术逻辑”，不是制度的本意。

规则模型的设计，需要的是“双语者”。既能读懂制度的要求，又能写出系统能执行的逻辑。

这个翻译过程还有一个容易被忽视的特点：翻译本身就是一种“解释”。制度条款往往有模糊空间，比如“重大投资”的具体标准是什么，“关联交易”的认定范围包括哪些情形。

翻译者需要对这些模糊空间做出判断，这个判断的过程，就是在制定规则。

03 设计规则模型就是在制定风险管控规则

规则模型的本质是翻译器，但翻译本身不是中立的。

翻译者在“翻译”的过程中，实际上在做三件事：定义什么是风险、判断风险何时触发、决定触发后如何处置。

这三件事合在一起，其实是在说风险管控规则的制定权。

具体来说，规则模型的设计权包含四项具体权力。

第一，风险定义权。什么样的行为算风险、什么样的状态算异常，这个判断标准是由规则模型的设计者来确定的。

同样一笔交易，设定了A规则就会触发预警，不设定A规则就不会触发。设计者说这是风险，它就会成为系统盯住的对象。这个权力决定了企业风险管控的注意力投向哪里。业务部门在讨论中说“这个场景我们经常遇到，确实是问题”，这个场景就可能被写进规则；业务部门说“这个情况我们也有，但属于正常业务波动”，这个场景可能就不会被采纳。风险的定义权，在业务讨论中悄然形成。

第二，阈值设定权。风险严重到什么程度才需要干预，这个临界值是由规则模型的设计者来确定的。

同一类风险，阈值设得高，预警就少，管控相对宽松；阈值设得低，预警就多，管控相对严格。财务部门说“偏差超过5%就应该预警”，这个阈值就定在5%；如果换成“偏差超过10%再预警”，同样的业务行为，一个会被系统盯住，一个不会被系统关注。阈值的微调，可以直接改变一个业务领域的管控松紧程度。

第三，逻辑组合权。多个判断条件之间用“与”还是用“或”来组合，决定了规则模型的灵敏度和覆盖面。

用“与”组合意味着所有条件同时满足才触发，误报少但可能漏报；用“或”组合意味着任一条件满足就触发，覆盖广但误报多。这个组合方式的选择权，掌握在设计者手中。技术团队可能建议用“或”组合以扩大覆盖面，业务部门可能坚持用“与”组合以降低误报，最终的组合方式决定了哪些行为会被系统标记。

第四，处置指向权。规则模型触发预警之后，派单给谁、要求谁在什么时限内完成核查、核查的标准是什么，这些处置流程的设计权同样属于规则模型的设计者。

预警信号派给哪个部门、要求谁牵头核查、整改验收由谁负责，这些流程设计直接关系到风险发生后的责任分配。设计者定义了问题出现之后谁来负责、按什么程序处理。

把这四项权力合在一起，规则模型的设计权实质上是：定义什么是风险、判断风险何时触发、决定触发后如何处置。

谁掌握了规则模型的设计权，就相当于掌握了企业风险管控规则的制定权。

04 规则模型设计权为什么重要

规则模型设计权的重要性，在穿透式监管的语境下被放大了。

过去企业的风险管控，主要靠三种手段：制度约束、人工审核、事后检查。

制度约束告诉人“应该怎么做”，人工审核在关键节点上判断“这件事能不能做”，事后检查发现问题再追责。

在这个人防体系中，管控规则的执行弹性很大。同一个制度条款，不同的执行人可能有不同的理解和尺度。制度说“应当规范决策程序”，有人理解为“走完审批流程就行”，有人理解为“决策依据必须充分、记录必须完整”。

穿透式监管带来的变化是，管控措施正在从人防走向技防。原来由人工判断的事情，逐渐交给系统来执行。

制度中的要求被转化为规则模型中的规则逻辑，审核标准被转化为规则条目中的判断条件，检查重点被转化为规则模型监控的风险场景。

一旦完成这个转化，管控规则的形态就变了。它不再是写在纸面上的制度条文，也不再是靠执行人理解来落地的模糊要求，而是变成了系统里可执行、可自动运行、不可绕过的代码逻辑。

一条规则模型在系统里跑起来之后，它不会被“通融”，不会被“特批”，不会被“下不为例”。触发条件一旦满足，预警必定发出。

这个变化意味着，权力从流程中的某个节点前移到了规则的设计阶段。

传统管理体系中，权力体现在审批环节，谁有签字权，谁就有话语权。但在技防体系下，审批环节的人可能还有签字的形式，但实质上他能做的判断已经被规则模型限定了。

规则说预警必须核查，审批人就不能视而不见。规则说这个条件算违规，审批人就不能说“这次算了”。

规则模型设计权的影响是系统性的、持续性的。一条制度条款可能只影响一个部门、一段时间。一条规则模型一旦部署到平台上，影响的是全集团所有涉及该业务场景的单位，而且只要规则不修改，它的影响就是持续的。

设计者可能只是在某次研讨会上确认了一条规则逻辑，但这条规则会在系统里日复一日地运行，持续地筛查、预警、推动处置。

规则模型设计权还具有隐蔽性。规则模型的设计通常被当作一个技术工作，参与讨论的人往往关注的是逻辑是否自洽、数据是否可得、技术是否可行，很少有人从权力分配的角度去审视它。

规则的设计者可能自己也没有意识到，他在定义规则逻辑的同时，也在定义企业风险管控的边界和尺度。

05 规则模型由谁来设计和确认

理解了规则模型设计权的管理属性之后，一个实践中的问题就浮出水面：规则模型应该由谁来设计、由谁来确认？

一，业务部门是规则模型设计的第一责任主体

规则模型的核心内容，是对业务风险的判定逻辑。判断“什么行为算违规”“什么标准算异常”，需要的是对业务场景的深入理解。

财务人员最清楚大额异常支付的特征，采购人员最了解围标串标的常见手法，投资人员最明白投后收益偏离的合理区间。这些判断，技术团队做不了，内控部门也做不了。

业务部门在设计规则模型时，需要完成两项核心工作。第一是风险场景的识别和描述。将本领域的业务风险，从“投资管理不规范”这样的抽象表述，细化为“付款日期早于审批日期”“投后收益低于可研预期50%”这样的具体场景。

第二是判定逻辑的定义。将“什么算违规”的业务判断，转化为可以量化的判定条件，比如“同层级薪酬差距超过3倍且无绩效支撑”就是一个可量化的判定条件。

业务部门在设计规则模型时，可以借助外部咨询机构提供的方法论和模板，但不能把“定义风险”这件事交给外部机构来做。

外部机构可以教业务部门“怎么把业务判断转化为条件表达式”，但不能替业务部门决定“什么算违规”。

二，内控合规部门是规则模型的评审组织和质量把关者

业务部门定义的规则模型，需要有人来把关：这个规则是否与上位制度一致，是否与集团管控要求一致，是否与其他领域的规则存在冲突或重叠。这个把关的职能，应该由内控合规部门承担。

内控合规部门在规则模型设计中的角色，不是“替业务部门设计规则”，而是“确保业务部门设计的规则合规、合理、可执行”。

具体来说，内控合规部门需要审查三个方面：规则的定义是否与制度依据一致，规则的阈值设定是否合理，规则的处置动作是否符合管理要求。

内控合规部门还需要组织跨部门的规则评审。一条规则模型可能涉及多个业务领域的交叉，比如“虚假贸易”的规则模型既涉及采购，也涉及资金，还涉及合同。这种情况下，需要内控合规部门组织联合评审，确保各方的意见都被纳入。

三，信息化部门是规则模型的技术确认者和实现者

业务部门定义了“要判断什么”，内控合规部门确认了“判断是否合规”，接下来需要回答“能不能判断”。判断所需的数据是否可得，判断逻辑能否被系统实现。这是信息化部门的职责。

信息化部门需要确认两件事。一是数据可得性。业务部门定义的规则逻辑，所需的每一个数据字段是否存在于某个业务系统中，能否被采集到数据平台，质量是否满足判断要求。

如果数据不可得，信息化部门需要提出解决方案——是开发新接口，还是推动业务系统改造，还是先用离线填报过渡。

二是技术可行性。规则逻辑的条件表达式能否被规则引擎支持，是否需要定制开发，性能是否满足实时或准实时的要求。

信息化部门在规则模型设计中的角色，不是“替业务部门做判断”，而是“告诉业务部门哪些判断可以做、哪些暂时做不了、做不了的需要什么条件”。这个反馈是双向的：业务部门可能需要调整规则逻辑以适应数据条件，信息化部门也需要推动数据治理以满足业务需求。

四，三方联合评审是规则模型设计的质量保障机制

规则模型在正式开发上线之前，需要经过业务部门、内控合规部门、信息化部门的三方联合评审。

业务部门确认“判定逻辑是否符合业务实际”，内控合规部门确认“合规依据是否充分、处置动作是否适当”，信息化部门确认“数据来源是否可获取、技术实现是否可行”。

三方联合评审的价值，不在于“形式上的签字确认”，而在于“在不同视角的碰撞中发现盲点”。业务部门可能只关注“能不能发现问题”，内控合规部门可能更关注“判断标准是否符合制度”，信息化部门可能更关注“数据能不能支撑判断”。

三方坐在一起，才能确保规则模型既准确、又合规、又可执行。

评审通过后，三方签署《业务技术映射确认单》。

这份确认单的意义，不在于“备案”，而在于明确责任——规则模型一旦上线运行，如果出现问题，可以追溯到是哪一方在哪个环节的判断出了偏差。

小结一下：规则模型的设计，表面上是技术工作，实质上是管理权力的配置。意识到规则模型设计权的管理属性，才能让规则设计的过程更加审慎和透明。因为设计规则的人，在某种意义上，就是在制定企业风险管控的基本法。