关于穿透式监管领域中的“虚假贸易”规则模型设计与开发，我们已完成上篇：《  “虚假贸易”规则模型的设计与开发（上）全层级》和中篇：《  “虚假贸易”规则模型的设计与开发（中）｜资料准备与调研访谈》。 

本篇进入“虚假贸易”规则模型设计与开发的最务实部分——全要素设计、部署与验证。 正是这部分，真正能够将一个“业务管控体系”转化为一个“五自动技术体系”。这也是本人一再提出的“法律+管理+AI”原创方法论的魅力之所在。 

全要素设计环节，是将分散在监控方向、风险场景中的业务判断逻辑，按照规则模型六要素框架进行系统化填充与工程化表达，形成可直接交付开发团队的设计文档包。 

部署环节，说明如何将六要素设计转化为系统内的功能安排。

验证环节，则从完整性、合理性、可行性三个维度对模型上线前的最终检验。

一、六要素概述  

规则模型的六要素，是本人在穿透式监管体系建设方法论中提出的核心设计框架。 在该方法论下，一个完整的规则模型，由六个相互关联的要素构成——风险场景、数据来源、规则逻辑（含规则条目与阈值）、预警等级、处置动作、迭代机制。 

注意，六个要素不是并列的六个模块，而是遵循一条从业务到技术、从静态到动态的逻辑链。理解这个逻辑链，是正确完成全要素设计的前提。 

1. 风险场景是逻辑起点，回答“监控什么”。它将“突出问题”或“典型问题”分解为可操作的具体监控对象。 每一个风险场景都是违规行为在业务实践中的一种可识别表现形态。场景的分解需要达到“可监控”的颗粒度——有明确的数据源、可量化的判断标准和清晰的责任主体。如果某个场景找不到数据支撑或无法量化判断，它在规则模型中的优先级就会降低，甚至暂时搁置。 风险场景的识别成果体现为六要素清单中的“风险场景识别表”。 

2. 数据来源是技术基础，回答“判断依据从哪来”。它为每一条规则条目的每一个判断变量定位数据所在的系统、数据库表和字段名。数据来源的精准度直接决定了规则模型能否真正运行。数据来源匹配到规则条目层级——不是笼统地标注“司库管理系统”，而是精准标注“司库管理系统—资金支付流水表—支付金额字段”。 这种条目级的数据来源定位，将业务需求转化为技术开发人员可直接执行的数据接口需求。 数据来源的成果体现为六要素清单中的“数据来源映射表”。 

3. 规则逻辑是智能核心，回答“怎么判断”。它将风险场景中蕴含的业务判定经验，转化为由若干规则条目通过“与”、“或”、“非”三种逻辑运算符组合而成的完整判定单元。 一条规则逻辑是一个能够独立作出是否触发预警决策的最小运行单元。 规则条目是规则逻辑的最小原子，每个条目只包含一个判断变量、一个判断算子和一个阈值或比对值。条目通过“与”组合表示所有条件必须同时满足，通过“或”组合表示至少一个条件满足即可，通过“非”组合表示排除条件。 规则逻辑中的阈值是判定条件的临界值，是规则条目的有机组成部分。 规则逻辑的成果体现为六要素清单中的“规则逻辑定义表”和“结构化规则库”，必要时可合并为一张“规则逻辑表”。 

4. 预警等级是风险标尺，回答“有多严重”。它为每条规则逻辑设定触发后的风险等级——红色高风险或黄色中风险。 预警等级的设定依据是信号与虚假贸易核心特征的关联强度。直接触及货权缺失、资金闭环等核心特征的信号设定为红色高风险，具有指向性但单独证明力有限的信号设定为黄色中风险。 预警等级的成果体现为六要素清单中的“预警阈值与等级表”。 

5. 处置动作是闭环保障，回答“发现后怎么办”。它定义预警触发后的系统自动动作——是暂停付款流程还是仅推送工单，人工介入方式——推送给哪个岗位、什么时限内完成核查，超期升级路径——超期多长时间升级至哪一级管理层。没有处置动作的规则模型只是一个“数据观察器”，无法产生管理实效。 处置动作的成果体现为六要素清单中的“处置动作定义表”。 

6. 迭代机制回答“如何越用越好”。它设定模型运行后的评估周期——每季度评估准确率、每半年评估覆盖度，优化触发条件——准确率低于百分之五十调优、新违规手法出现补规则、监管政策变化即复核，以及变更管理流程——变更提出、影响评估、审批确认、实施部署、验证验收。 迭代机制的成果体现为六要素清单中的“规则迭代记录表”。 

这六个要素环环相扣，构成从识别到处置再到优化的闭环。风险场景牵引出数据需求，数据来源支撑规则逻辑的计算，规则逻辑触发预警等级，预警等级决定处置动作的力度和方式，处置动作的执行效果反馈至迭代机制，迭代机制驱动风险场景的补充和规则逻辑的优化。 

这种递进关系，决定了全要素设计的工作顺序——先确定风险场景，再梳理数据来源，再定义规则逻辑和阈值，再设定预警等级，再设计处置动作，最后建立迭代机制。六个要素的完整填充，意味着规则模型能够从业务构思，转化为可交付的工程化设计文档。

二、“虚假贸易”规则模型的六要素全设计 

以下按前述六要素，展开对“虚假贸易”规则模型的完整设计。

（一）风险场景   

按前文《  “虚假贸易”规则模型的设计与开发（上）全层级》所分析，“虚假贸易”规则模型可识别出十三个“风险场景”，分属四个监控方向。 

1. 贸易背景真实性验证方向，包含三个风险场景。供应商与客户同源，指同一笔交易的供应商和客户存在股权关联或实际控制人相同，上下游形成闭环交易，涉及业务环节为贸易合同签订和交易对手准入审查。贸易规模与经营能力不匹配，指贸易合同金额远超供方或需方的注册资本和经营规模，缺乏合理的商业逻辑，涉及业务环节为合同签订前的尽职调查。交易标的不涉及企业经营范围，指供方或需方的经营资质与交易标的无关，贸易业务游离于企业核心业务之外，涉及业务环节为交易对手准入审查。 

2. 货权实控验证方向，包含四个风险场景。货权转移证明缺失，指仓单、提单、入库单等货权转移凭证在系统中无记录，或仅有复印件无法核实真实性，涉及业务环节为货物交割与验收。仓储记录与交易规模不匹配，指仓储系统记录的货物吞吐量与合同约定货物量严重不一致，涉及业务环节为仓储管理和合同履约监控。货物流转时间异常，指货物从供应商到客户的流转时间在物理上不可能实现，涉及业务环节为物流管理和合同履约监控。货物未实际进入企业仓库，指物流单据显示货物直接从供应商仓库发往客户仓库，企业自身无仓储记录和物流费用发生，涉及业务环节为货物交割与仓储管理。 

3. 资金流向闭环验证方向，包含四个风险场景。资金“即进即出”，指企业向供应商付款与收到客户回款的时间高度接近，资金在企业账户停留时间极短，涉及业务环节为资金支付与收款管理。上下游为同一实际控制人，指穿透股权关系后供应商和客户归属同一主体，涉及业务环节为交易对手准入审查。交易金额高度匹配，指同一笔贸易的买入金额与卖出金额几乎完全一致，企业未产生合理的贸易价差，涉及业务环节为合同定价与资金管理。保证金与贸易规模不匹配，指预收的保证金远不足以覆盖潜在的违约或跌价风险，涉及业务环节为合同签订前的风险评估。 

4. 合同条款商业合理性验证方向，包含两个风险场景。合同权利义务不对等，指采购合同与销售合同的条款内容高度雷同，企业仅承担资金方角色，不承担任何货物质量、交付延迟等贸易业务固有的商业风险，涉及业务环节为合同签订与审批。合同集中签订异常，指多份贸易合同在相同日期集中签订，涉及不同交易对手和不同标的物，不符合正常商业节奏，涉及业务环节为合同管理。 

上述十三个风险场景，建议经过访谈调研的确认和补充。以业务语言向贸易业务专家复述后，认可场景清单覆盖了虚假贸易在企业实际业务中的主要表现形态，与74号文“十不准”禁令的映射关系。各场景均满足可监控性标准——有明确的数据源支撑、有可量化的判断标准、有清晰的责任主体。 该十三个风险场景，构成虚假贸易规则模型中“风险场景识别表”的内容。

（二）数据来源   

数据来源要精准匹配到规则条目层级。每个规则条目的每个判断变量，都应定位到具体系统的具体数据库表的具体字段名。 以下按监控方向，将各风险场景中规则条目的数据来源进行系统化整理。 为便于开发团队使用，每个数据来源均标注“系统名称—数据库表名称—字段名称”的三段式定位，同时标注数据可获取性状态。 

1. 贸易背景真实性验证方向涉及三个业务系统和一个外部数据源。 合同管理系统合同基本信息表提供供应商名称、客户名称、合同金额、标的品类等基础信息字段。供应商名称和客户名称为必填项，填充率接近百分之百，数据可获取性良好。合同金额字段为必填项，填充率接近百分之百。标的品类字段为必填项，填充率接近百分之百。 

供应商管理系统供应商信息表提供注册资本字段，填充率约为百分之九十五，部分非企业类供应商可能未填报。 工商信息库为外部数据源，通过API接口调用。股权关系表提供实际控制人名称和统一社会信用代码字段，当前覆盖率为百分之七十，非上市企业或境外企业可能无法完成穿透，此类情形规则条目标记为“无法穿透”，暂不触发预警。企业经营范围表提供经营范围字段，可作为文本匹配的数据来源，覆盖率和更新频率与股权关系表一致。 

2. 货权实控验证方向涉及三个系统。 合同管理系统合同基本信息表提供合同金额、最迟交货日期、交付方式等字段，均为必填项。 

物流管理系统为核心数据源，包含五张核心数据表。仓单信息表、提单信息表、入库单信息表以合同编号为关联键，三种凭证均缺失时判定为货权凭证缺失。出货记录表的出货日期字段记录供应商实际出货日期。收货记录表的收货日期字段和收货地址字段记录客户收货日期和收货地址，收货地址需与企业自有仓库地址清单进行比对。 

仓储管理系统出入库记录表提供货物入库量和出库量字段，可按月度汇总统计。入库记录表的关联合同编号字段用于验证货物是否进入企业仓库。

3. 资金流向闭环验证方向涉及两个系统。 财务核算系统为核心数据源，包含两张核心数据表。资金支付流水表提供支付日期和关联合同编号字段，数据更新延迟在三十分钟以内。资金收款流水表提供到账日期和关联合同编号字段，数据更新延迟同样在三十分钟以内。对于时序比对规则，取关联合同编号下最后一笔付款日期和第一笔回款日期进行计算。 合同管理系统合同基本信息表的合同类型字段用于区分大宗商品预付、能源采购、农产品收购等特殊行业类型。预收账款明细表的保证金金额字段提供保证金数据。 

4. 合同条款商业合理性验证方向的数据来源为合同管理系统合同条款表，需部署文本比对组件以计算采购合同与销售合同的条款相似度。文本比对时应排除价格、数量、交货日期等自然变化的字段。 数据来源的成果体现为六要素清单中的“数据来源映射表”。 该表以规则条目编号为索引，逐条标注系统名称、数据库表名称、字段名称和数据可获取性状态。对于数据获取存在风险点的条目——如依赖外部工商数据源的关联穿透规则——在数据可获取性列标注“启用但需关注”，并记录风险点和缓解措施。 

（三）规则逻辑   

规则逻辑是六要素中的智能核心。它由若干规则条目通过“与”“或”“非”三种逻辑运算符组合而成，是能够独立作出是否触发预警决策的完整判定单元。 

每条规则逻辑包含其所拆解的规则条目、条目之间的逻辑组合方式、核心阈值以及综合评分规则。 

规则条目的组合，遵循以下语法规则：“与”逻辑表示所有关联条目必须同时满足，规则逻辑才触发，适用于多个必要条件缺一不可的场景。“或”逻辑表示关联条目中至少一个满足，规则逻辑就触发，适用于多个可选疑点任一成立即可的场景。“非”逻辑表示排除条件——排除条件满足时，即使其他条目满足，规则逻辑也不触发，适用于将合理业务场景从预警范围中剔除的场景。 

阈值是规则条目的有机组成部分，不是独立于规则条目之外的存在。金额大于等于一百万元中的一百万元就是阈值，间隔天数小于等于三个自然日中的三个自然日就是阈值。 

阈值分为固定阈值和可调阈值两类。固定阈值来源于法律法规的强制性规定，此类阈值不可调整。可调阈值来源于企业制度规定或业务经验判断，可在试运行中根据命中率和准确率数据进行校准。 

以下按监控方向，逐一呈现虚假贸易模型十三条规则逻辑的完整设计。 

贸易背景真实性验证方向   

1. “同源识别”规则逻辑，所在风险场景为“供应商与客户同源”。该规则逻辑由四个条目通过“与”逻辑组合而成。 条目一，取得同一笔贸易业务的供应商企业名称和客户企业名称，数据来源为合同管理系统合同基本信息表的对应字段。条目二，对供应商进行股权穿透获取实际控制人名称及统一社会信用代码，数据来源为工商信息库股权关系表。条目三，对客户进行股权穿透获取实际控制人名称及统一社会信用代码，数据来源同上。条目四，比对供应商与客户的实际控制人统一社会信用代码是否一致。 当这四个条目全部满足时，规则逻辑触发。 该规则逻辑的阈值是“实际控制人统一社会信用代码相同”，属于比对值判定，非数值型阈值。 数据获取风险点为工商信息库覆盖率，对于无法穿透的供应商或客户，该条目标记为“无法穿透”，暂不触发预警。 

2. “规模比对”规则逻辑，所在风险场景为“贸易规模与经营能力不匹配”。该规则逻辑由四个条目通过“与”逻辑组合而成。 条目一，取得单笔贸易合同金额，数据来源为合同管理系统合同基本信息表的合同金额字段。条目二，取得供应商注册资本，数据来源为供应商管理系统供应商信息表的注册资本字段。条目三，计算合同金额除以注册资本的比值，阈值设定为大于等于五倍。条目四，判断供应商是否不在大型知名企业白名单内，白名单由贸易业务部门和内控部门联合审定。 四个条目全部满足时触发预警。阈值“五倍”的设定依据是虚假贸易案例中合同金额与供应商注册资本的倍数关系统计，首次部署时设定为五倍，试运行后根据命中率和准确率校准。 

3. “范围比对”规则逻辑，所在风险场景为“交易标的不涉及企业经营范围”。该规则逻辑由五个条目通过“与”逻辑、“或”逻辑、“非”逻辑组合而成。 条目一，取得交易标的品类，数据来源为合同管理系统合同基本信息表。条目二，判断标的品类是否包含在供应商经营范围内，采用关键词匹配。条目三，判断标的品类是否包含在客户经营范围内。条目二与条目三采用或逻辑——供应商或客户至少一方经营范围不包含标的品类即视为异常。条目四，基于或逻辑的结果进行判断，双方都不包含则异常。条目五，取得合同金额，判断是否超过小额豁免阈值五十万元，采用非逻辑——小额贸易不做强制经营范围审查。 条目四与条目五通过“与”逻辑组合，同时满足时触发预警。经营范围关键词匹配的准确性需要在迭代中持续优化，补充特殊行业经营资质的匹配逻辑。

货权实控验证方向   

4. “凭证核验”规则逻辑，所在风险场景为“货权转移证明缺失”。该规则逻辑由三个条目通过“与”逻辑组合而成。 条目一，单笔贸易合同金额大于等于一百万元，阈值依据为企业内部对重大贸易业务的界定标准，属于可调阈值。条目二，当前日期减去合同约定的最迟交货日期大于十个工作日，宽限期的设定考虑了正常的单据流转和录入延迟，属于可调阈值。条目三，物流管理系统中仓单、提单、入库单均不存在——三种凭证均缺失方触发，存在其中任何一种则视为有货权转移记录。 三个条目全部满足时触发预警。货权凭证类型的清单可在迭代中根据企业实际使用的凭证类型进行更新。 

5. “仓储比对”规则逻辑，所在风险场景为“仓储记录与交易规模不匹配”。该规则逻辑由三个条目通过与逻辑组合而成。 条目一，按月度统计仓储系统记录的货物入库量和出库量之和，数据来源为仓储管理系统出入库记录表。条目二，按月度统计贸易合同约定的货物数量总和，数据来源为合同管理系统合同基本信息表。条目三，计算仓储吞吐量与合同货物总量的比值，阈值设定为低于百分之五十，属于可调阈值。 三个条目全部满足时触发预警。阈值“百分之五十”为初始设定值，试运行后可按不同货物类型——大宗商品、标准工业品、特殊设备——分别设定匹配标准。 

6. 时效比对规则逻辑，所在风险场景为货物流转时间异常。该规则逻辑由四个条目通过与逻辑组合而成。条目一，取得供应商出货日期，数据来源为物流管理系统出货记录表。条目二，取得客户收货日期，数据来源为物流管理系统收货记录表。条目三，计算收货日期减出货日期的间隔天数，与预设的最短物理物流时间比对。最短物流时间按货物类型和运输距离分档设定，例如普通货物省内运输最短为一天、跨省运输最短为两天、特殊设备增加安装调试时间，属于可调阈值。条目四，判断该笔贸易是否属于电子化交付或服务类贸易， 采用“非”逻辑——此类贸易不适用物流时间规则。四个条目全部满足时触发预警。最短物流时间参数表需要每半年按实际物流数据校准。 

7. 入库核验规则逻辑，所在风险场景为货物未实际进入企业仓库。该规则逻辑由三个条目通过与逻辑组合而成。 条目一，该笔贸易合同在财务核算系统中存在付款记录，数据来源为资金支付流水表。条目二，仓储管理系统中该合同编号对应的货物入库记录不存在，数据来源为仓储管理系统入库记录表。条目三，物流管理系统中收货地址为企业自有仓库的记录不存在，数据来源为物流管理系统收货记录表的收货地址字段。 三个条目全部满足时触发预警。对于直发客户、供应商代管仓等正常业务场景，在迭代中根据预警命中率和核查反馈，分析未入库原因中正常场景的比例，将高频正常场景纳入排除条件。

资金流向闭环验证方向   

8. 时序比对规则逻辑，所在风险场景为资金即进即出。该规则逻辑由四个条目通过与逻辑组合而成。条目一，从资金支付流水中提取该笔贸易业务对应的最后一笔供应商付款日期，数据来源为财务核算系统资金支付流水表。条目二，从资金收款流水中提取该笔贸易业务对应的第一笔客户回款到账日期，数据来源为财务核算系统资金收款流水表。条目三，以条目二减条目一，计算间隔天数，阈值设定为小于等于三个自然日，属于可调阈值。条目四，判断该笔贸易是否属于特殊行业类型——合同类型不等于大宗商品预付且不等于能源采购且不等于农产品收购，采用非逻辑排除。 

四个条目全部满足时触发预警。间隔天数的阈值设定依据是正常贸易业务的平均资金周转周期，首次设定为三个自然日，后续每季度根据运行数据进行校准。特殊行业类型白名单由贸易业务部门和财务部门联合审定，按半年度更新。 

9. 关联穿透规则逻辑，所在风险场景为上下游为同一实际控制人。该规则逻辑由四个条目通过与逻辑组合而成。条目一至条目三与同源识别规则逻辑的条目一至条目三完全相同，在系统实现中通过配置复用。条目四，比对供应商实际控制人与客户实际控制人统一社会信用代码是否一致。 四个条目全部满足时触发预警。本条规则逻辑的数据来源、数据风险点和处理方式与同源识别规则逻辑一致，不再重复。 

10. 价差比对规则逻辑，所在风险场景为交易金额高度匹配。该规则逻辑由四个条目通过与逻辑组合而成。条目一，取得该笔贸易业务的买入金额，数据来源为合同管理系统采购合同表的金额字段或财务核算系统供应商付款记录的金额字段，两者可交叉校验。条目二，取得卖出金额，数据来源为合同管理系统销售合同表的金额字段或财务核算系统客户收款记录的金额字段。条目三，计算卖出金额减买入金额的差额绝对值除以买入金额，阈值设定为小于百分之一，属于可调阈值。条目四，排除小额贸易，买入金额大于等于五十万元，采用非逻辑排除。 四个条目全部满足时触发预警。阈值“百分之一”为初始设定值，试运行后按不同贸易类型——代理贸易、经销贸易、自营贸易——分别设定合理的价差区间。 

11. 比例比对规则逻辑，所在风险场景为保证金与贸易规模不匹配。该规则逻辑由四个条目通过与逻辑组合而成。条目一，取得贸易合同预收保证金金额，数据来源为财务核算系统预收账款明细表。条目二，取得贸易合同总金额，数据来源为合同管理系统合同基本信息表。条目三，计算保证金与合同总金额的比值，阈值设定为低于百分之十，属于可调阈值。条目四，判断交易对手是否不在白名单内，白名单包含长期合作客户和信用评级优良客户，采用非逻辑排除。 四个条目全部满足时触发预警。白名单由贸易业务部门和信用管理部门联合审定，按半年度更新准入标准。

合同条款商业合理性验证方向   

12. 条款比对规则逻辑，所在风险场景为合同权利义务不对等。该规则逻辑由三个条目通过与逻辑组合而成。条目一，计算采购合同与销售合同条款的文本相似度，排除价格、数量、交货日期等自然变化的字段，数据来源为合同管理系统合同条款表，阈值设定为大于等于百分之八十五，属于可调阈值。条目二，检索销售合同中质量保证条款，判定内容中是否包含“不承担”或相关豁免表述。条目三，检索销售合同中交付责任条款，判定内容中是否包含“不承担”或相关豁免表述。 三个条目全部满足时触发预警。对于特定行业惯例导致的条款雷同——如大宗商品贸易中上下游合同条款高度标准化——可纳入白名单排除处理，白名单准入需经法务部门和内控部门联合审批。 

13. 集中度统计规则逻辑，所在风险场景为合同集中签订异常。该规则逻辑由三个条目通过与逻辑组合而成。条目一，同一天同一业务部门签订的贸易合同份数大于等于五份，数据来源为合同管理系统合同基本信息表。条目二，同一天同一业务部门签订的贸易合同总金额大于等于一千万元。条目三，涉及至少两家以上不同交易对手，数据来源为同表交易对手名称字段。 三个条目全部满足时触发预警。份数和金额阈值可按业务部门实际签订节奏分部门设定，首次部署按统一标准执行，运行一季度后按各部门历史数据校准个性化阈值。

综合评分规则   

虚假贸易模型各场景的规则逻辑系独立运行，各自输出预警信号。综合评分规则是将多条规则逻辑的预警信号，整合为统一的风险等级判定。评分采用加权计分制，各监控方向的权重分配依据是信号与虚假贸易“三无”核心特征的关联强度。 

货权实控验证方向权重，建议设定为百分之三十五，原因是货权缺失是虚假贸易最直接的证据，一旦触发置信度极高。资金流向闭环验证方向权重，建议设定为百分之三十，原因是资金闭环是融资性贸易的核心特征。贸易背景真实性验证方向权重，建议设定为百分之二十。合同条款商业合理性验证方向权重，建议设定为百分之十五，原因是该方向的信号具有参考价值但单独证明力有限。 

同一方向内多条规则同时触发时，权重不重复累加，取其方向权重本身，避免单一方向的多条规则过度推高综合评分。 

综合评分达到高风险阈值的情形为：任意一条红色高风险规则触发预警，或综合加权得分超过百分之五十。综合评分达到中风险阈值的情形为：黄色中风险规则触发预警，且综合加权得分在百分之二十五至百分之五十之间。综合加权得分低于百分之二十五时，系统记录观察，供季度贸易风险分析参考，不触发工单推送。 

综合评分规则不是独立于规则逻辑之外的一个单独要素，而是规则逻辑层的有机组成部分。它定义了多条规则逻辑之间的协同关系和聚合方式，使模型从“单规则预警”升级为“多维度综合研判”。这是必要的。 

（四）预警等级   

预警等级分为红色高风险和黄色中风险两级。分级的依据是信号与虚假贸易“三无”核心特征的关联强度——直接触及核心特征的信号设定为红色高风险，具有指向性但单独证明力有限的信号设定为黄色中风险。 

红色高风险适用于以下规则逻辑。货权实控验证方向中，凭证核验规则逻辑触发意味着货权凭证缺失，入库核验规则逻辑触发意味着货物未进入企业仓库，均直接印证了“无货权实控”这一核心特征。资金流向闭环验证方向中，时序比对规则逻辑触发意味着资金在企业账户停留时间极短，关联穿透规则逻辑触发意味着上下游为同一主体，均直接印证了“无独立商业利益”这一核心特征。这些规则触发时，虚假贸易的可能性极高，需要立即暂停付款流程并迅速启动核查。 

黄色中风险适用于以下规则逻辑。贸易背景真实性验证方向全部三条规则逻辑——同源识别、规模比对、范围比对——触发时表明交易背景存在疑点，但需要结合其他信号综合判断。

货权实控验证方向中，仓储比对和时效比对两条规则逻辑触发时表明货物流转存在异常，但存在正常的业务解释空间。资金流向闭环验证方向中，价差比对和比例比对两条规则逻辑触发时表明交易条件偏离市场惯例，但单独不足以定论虚假贸易。

合同条款商业合理性验证方向全部两条规则逻辑——条款比对和集中度统计——触发时表明合同安排偏离正常商业逻辑，但部分情形可能是行业惯例。 

预警等级的设定与处置动作直接挂钩。红色高风险触发后，系统自动冻结付款和推送工单并行。黄色中风险触发后，系统仅推送工单，不自动冻结付款，为人工核查留出判断空间。

（五）处置动作   

处置动作是规则模型的闭环保障。没有处置动作的规则模型，只是一个数据观察器，预警信号发出后如果无人跟进，模型的投入就失去了意义。处置动作的设计遵循“分层处置、闭环管理”原则——按预警等级分层设定处置力度，通过派单、核查、整改、验收、销号五个环节形成完整闭环。 

1. 高风险处置流程适用于触发红色预警的场景。系统自动动作包含两项并行操作。 

第一，暂停相关付款流程——系统通过接口调用冻结该笔贸易合同对应的付款指令，防止风险资金继续流出。 

第二，生成核查工单——工单内容包括触发规则名称、风险场景描述、异常数据摘要、关联合同编号和要求完成时限。工单推送至贸易业务部门负责人和集团内控合规部门，同步抄送财务部门负责人。核查时限要求二十四小时内启动核查，三个工作日内完成核查报告并上传系统。 

核查报告应包含以下内容：核查过程和核实的信息来源，异常原因的详细分析，是否确认构成虚假贸易或融资性贸易的初步判断，建议的后续处置措施。 

超期处置规则为，超期一个工作日系统自动升级至贸易业务分管副总经理督办，超期三个工作日系统自动升级至集团总经理。 

对于经核查确认构成虚假贸易或融资性贸易的，移交审计部门或纪检监察机构，按46号令关于购销管理追责情形的相关规定启动追责程序。核查确认不构成违规的，由内控合规部门进行验收销号，系统恢复付款流程。 

2. 中风险处置流程适用于触发黄色预警的场景。系统自动动作为推送核查工单至贸易业务部门。 

根据风险场景类型，视需要抄送法务部门——涉及合同条款合理性的场景，或财务部门——涉及价差和保证金异常的场景。 

核查时限要求三至五个工作日内完成核查和情况说明。情况说明应包含异常原因分析和交易合理性说明。 超期处置规则为，超期三个工作日系统自动升级至贸易业务分管副总经理督办。核查确认异常属实的，按高风险处置流程启动核查和追责衔接。核查确认属于正常业务或行业惯例的，由内控合规部门进行验收销号。 

各风险场景的处置责任主体分工如下。货权实控验证方向各场景的核查责任主体为贸易业务部门和仓储管理部门，验收销号责任主体为内控合规部门。

资金流向闭环验证方向各场景的核查责任主体为贸易业务部门和财务部门，验收销号责任主体为内控合规部门。贸易背景真实性验证方向和合同条款商业合理性验证方向各场景的核查责任主体为贸易业务部门，其中合同条款类场景法务部门参与审核，验收销号责任主体为内控合规部门。处置责任主体的设定，需要与企业的岗位职责体系和授权审批矩阵相匹配，在访谈调研中已就当前处置路径进行摸底，与理想闭环机制存在差异的环节已标注，作为后续制度修订和流程优化的输入。 

处置动作的设计成果，体现为六要素清单中的“处置动作定义表”。该表以规则逻辑编号为索引，逐条标注预警等级、系统自动动作、派单对象、核查时限、超期处置规则和升级路径。 

（六）迭代机制   

迭代机制是规则模型持续优化的制度保障。规则模型不是一次性设计完成就固化的静态文档，而是需要在运行中根据数据反馈持续调优的动态体系。 

1. 定期迭代按以下周期执行。每季度评估各条规则的命中率和准确率。 命中率评估是统计各规则触发预警的频次占业务总量的比例，判断是否在合理区间。命中率过低可能意味着阈值偏严或场景已不再适用，命中率过高可能意味着阈值偏宽。 准确率评估是统计预警信号经人工核查确认为真实问题的比例。准确率低于百分之五十的规则需要重点调优，调优方向包括收紧或放宽阈值、增加或调整排除条件、补充辅助判断条目。 每半年评估模型的规则覆盖度，对照最新审计发现、行业案例和国资委监管要求，判断是否需要补充新规则。 

2. 触发式迭代在以下情形发生时启动。监管政策发生重大变化时——如74号文的修订或46号令追责范围调整——立即对相关规则进行合规性复核和修订。新违规手法被行业通报或本企业出现新型虚假贸易案例时，评估是否需要新增监控方向或风险场景，是否需要调整现有规则的判定逻辑或阈值。 

迭代流程分为五个环节。变更提出，由内控部门或业务部门根据运行数据或外部变化提出变更需求。影响评估，由内控部门会同信息化部门分析变更对模型覆盖度和准确率的影响，对关联规则的连锁影响。审批确认，由内控部门审核批准，重大变更需报领导小组审议。实施部署，由信息化部门完成参数调整或代码修改，在测试环境验证通过后部署至生产环境。验证验收，通过测试数据验证变更效果，确认准确率和命中率是否向预期方向改善。 

3. 每次迭代形成新的版本记录，包含版本号、变更类型（新增、修改、停用）、变更内容简述、变更原因、修订人、审批人和生效日期。版本编号规则为V主版本号.次版本号，规则逻辑发生根本性调整时升级主版本号，阈值微调或排除条件优化时升级次版本号。停用的规则在原版本记录中标注停用日期和停用原因，不删除历史记录。所有历史版本的设计文档和运行数据均应归档保存，确保任何时点都能回溯模型的完整演进过程。 迭代机制的成果体现为六要素清单中的“规则迭代记录表”，同时迭代管理流程和版本编号规则作为配套管理制度的组成部分。 

三、部署与验证 

从六要素设计到系统功能的部署安排   

六要素设计完成后，进入实际的部署。部署工作是将设计文档转化为系统内的功能安排。部署由信息化部门牵头执行，内控部门负责业务验收。 

1. 第一步，规则条目配置。将规则条目明细表中的每一条规则条目逐一配置到规则引擎的决策表或决策树中。每个条目的配置包含五个参数：规则条目编号、判断变量名称、数据来源定位（系统—数据库表—字段名）、算子类型（大于、小于、等于、包含、不包含等）、阈值或比对值。 规则条目的数据来源定位需与数据接口开发同步进行，确保规则引擎能够准确获取所需数据字段。 对于依赖外部数据源的条目，需配置数据超时或不可用时的降级策略——标记为“无法判断”而非“触发预警”。 

2. 第二步，规则逻辑编排。将规则逻辑定义表中的逻辑组合方式转化为规则引擎的计算流程。通过“与”“或”“非”三种运算符，将规则条目编排为完整的判定逻辑，设置运算优先级。 对于使用“与”组合的规则，所有条目计算结果均为真时触发。对于使用“或”组合的规则，任一计算结果为真时触发。对于使用“非”组合的排除条件，配置排除逻辑的执行顺序——先计算正向判断条目，再计算排除条件，正向全部通过且排除条件不满足时触发。 

3. 第三步，预警等级绑定。将各规则逻辑对应的预警等级，绑定到规则引擎的输出配置中。红色高风险规则触发时，系统自动调用付款冻结接口和工单生成接口，两条调用并行执行。黄色中风险规则触发时，系统仅调用工单生成接口。

4. 第四步，处置流程配置。将处置动作定义表中的派单对象、核查时限和超期升级规则，配置到工作流引擎中。工单模板包含触发规则名称、风险场景描述、异常数据摘要、关联合同编号和要求完成时限。工单生成后自动推送至对应岗位的系统待办事项中。超期自动触发升级催办，升级路径按设计文档中的升级层级执行。 

5. 第五步，综合评分部署。将综合评分规则的权重分配和计算公式，配置到规则引擎的聚合计算模块。多规则逻辑同时触发时，系统按预设权重自动计算综合得分并判定综合风险等级，输出结果至驾驶舱和工单模块。 

6. 第六步，迭代管理配置。建立规则模型的版本管理机制，每次迭代形成新版本号，保留历史版本的完整配置记录，支持版本回滚。配置规则监控仪表盘，实时展示各规则逻辑的命中率、处置时效和综合评分分布。 

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

规则模型的验证   

对于规则模型的验证，可从完整性、合理性和可行性三个维度进行。三个维度分别回答“覆盖得全不全”“判断得对不对”“能不能跑得通”的问题。 

1. 完整性验证是确认风险场景是否全面覆盖了虚假贸易的各项表现形态。 验证方法是将十三个风险场景与多个信息源进行交叉比对。与74号文“十不准”禁令逐条比对，确认每一条禁令在模型中都有对应的风险场景覆盖。与近三年审计发现和巡视反馈中虚假贸易的实际案例逐案比对，确认所有已知案例的违规特征在场景清单中均有对应。与行业监管通报和同类央企典型案例逐类比对，识别是否有新型违规手法未被模型覆盖。 经交叉比对，十三个风险场景覆盖了“十不准”中与虚假贸易直接相关的全部禁令，覆盖了已知案例的主要违规特征，覆盖了“三无”特征的全部维度，完整性验证才算通过。 

2. 合理性验证是确认规则逻辑的业务准确性和阈值的场景适配性。 验证方法包含三项。一是业务专家确认，将每条规则逻辑和阈值用业务语言向贸易业务专家逐条复述，确认逻辑描述与违规判定标准一致。二是历史案例回测，将已确认为虚假贸易的案例数据代入规则逻辑进行离线回测，验证规则逻辑能否命中已知案例。经测试全部已知案例被命中。三是正常案例排除，选取已确认为正常贸易的业务数据代入规则逻辑，统计误报率。 结果显示特殊行业类型通过排除条件得到有效区分，误报率在可接受范围。合理性验证方可通过。 

3. 可行性验证的核心是确认数据来源的可获取性和系统实现的技术可行性。 验证方法是通过穿透测试逐条确认每个规则条目所需数据字段的真实状态。逐系统确认核心业务系统正常运行。逐表确认所需数据库表存在且可访问。逐字段确认所需字段存在、字段类型匹配、填充率达标——绝大多数关键字段填充率在百分之九十以上。逐条目确认数据采集频率满足时效要求——资金数据更新延迟在三十分钟以内，仓单数据更新延迟在两小时左右。

外部工商数据依赖项标注为“启用但需关注”，纳入持续优化范围。这时可行性验证方可通过。 在验证完成后，本“虚假贸易”规则模型V1.0版本正式部署上线，进入试运行期。“虚假贸易”规则模型的设计与开发工作才算基本告一段落。 

（完）