2. 交易监测规则的基本要素拆解

一条可执行、可审计、可复用的交易监测规则，本质上是一份结构化的“判断契约”：它必须回答六个问题——叫什么、管什么、在什么条件下触发、阈值是多少、在多长时间内计算、触发后由谁做什么。把这些答案固化为字段，就是规则的基本要素。字段定义不清，规则就会在实现阶段被反复解释，在调优阶段无法归因，在检查阶段无法举证。本节按“字段定义—填写规范—填写示例”的顺序逐项拆解，并给出可直接套用的规则登记模板。

一、标识类字段：规则名称与规则编号

规则名称面向人，要求“一眼看懂监测什么行为”。推荐采用“业务场景 + 异常行为 + 判定口径”的三段式命名，例如“个人账户—夜间高频转账—单日累计笔数超限”。避免使用“规则1”“可疑交易规则A”这类无信息量名称，也不要在一个名称里塞入多个独立判断逻辑。

规则编号面向系统与档案，是规则全生命周期的唯一主键。建议采用“业务域代码 + 规则类型 + 四位流水号”的结构，如 AML-TR-0037（反洗钱-转账类-第37号）。编号一经发布不得复用：规则停用后编号保留并标记状态，修订时通过版本号区分，例如 AML-TR-0037 V2.1。编号与名称必须成对登记，禁止只改名称不改编号，否则历史预警与规则版本将无法对应。

二、范围类字段：监测对象

监测对象定义规则作用于“谁”和“哪些交易”，通常包含三个层次：主体范围（个人客户、对公客户、特约商户、内部员工账户等）、账户范围（本行账户、代理开户、睡眠户是否纳入）、交易范围（渠道、币种、借贷方向、业务品种）。填写时必须写清排除项，例如“不含信用卡还款、不含同名账户互转、不含司法冻结扣划”。

实践中常见的缺陷是监测对象写得过宽，导致预警量虚高。例如把“所有对公账户”作为对象，却未排除社保代发、税费批量扣款等低风险场景，规则上线首月预警量可能达到可处置量的数倍。规范做法是在对象字段中显式列出白名单场景及其依据，并注明白名单的维护责任人。

三、逻辑类字段：触发条件、阈值与时间窗口

这三个字段共同构成规则的“判断内核”，必须作为一个整体填写，任何一项单独存在都没有意义。

触发条件描述行为模式，用可计算的逻辑表达式表达，而不是自然语言描述。例如“同一付款账户在窗口期内向不同收款账户转账，且收款账户数 ≥ 阈值”，其中“不同收款账户数”是聚合口径，必须写明去重规则（按账号去重还是按户名去重）。

阈值是触发条件的临界值，需同时给出数值、单位和比较符。金额类阈值应注明币种及折算规则（如“外币按交易发生日中间价折人民币”）；比例类阈值应注明分母口径。阈值不宜设为整数“拍脑袋”值，应结合历史数据分布确定，例如取近12个月该指标第99百分位作为初值，再根据预警处置能力回调。

时间窗口定义统计的时间跨度与滚动方式，必须写明三点：窗口长度（如24小时、7个自然日）、滚动方式（滑动窗口还是自然日切分）、边界处理（是否含首尾、跨节假日如何计算）。滑动窗口与自然日窗口在同一阈值下结果差异显著：某客户在23:50与次日00:10各转账一次，自然日窗口下计为两日各一笔，24小时滑动窗口下则计为窗口内两笔，可能直接触发规则。

四、处置类字段：优先级与处置动作

优先级决定预警进入人工队列后的排序与时限。建议采用“高/中/低”三级，并绑定明确的响应时限与升级路径：高优先级（如涉恐、涉制裁名单命中）要求当日核查并双人复核；中优先级要求3个工作日内完成初核；低优先级可进入批量抽检。优先级不应由规则名称主观决定，而应结合“命中后确认可疑的历史比率”和“潜在损失敞口”两个维度评定，并在规则上线后按季度复核。

处置动作是规则触发后的标准响应，需写清动作类型、执行主体和留痕要求。常见动作包括：生成预警工单并指派至指定岗位、要求客户补充交易背景资料、限制非柜面渠道交易、上报可疑交易报告、转人工尽调。填写时应避免“视情况处理”这类模糊表述，改为条件分支，例如“命中且客户风险等级为高 → 限制非柜面转出并当日电话核实；命中且风险等级为中低 → 生成工单，3个工作日内完成资料补充”。

五、要素之间的联动关系

八个字段并非并列清单，而是存在明确的依赖与约束关系：监测对象决定触发条件可用的数据范围；触发条件决定阈值和时间窗口的计量口径；阈值与窗口共同决定预警量级，进而影响优先级的评定基础；优先级又约束处置动作的时限。任一字段变更都可能引发连锁调整，因此规则修订必须整条重新评审，不能只改阈值了事。

六、可直接套用的规则登记模板

下表以“个人账户夜间高频转账”为例，给出完整填写样例。示例中的阈值与时限均为教学假设值，实际取值应结合本机构历史数据分布与处置能力确定。

七、填写中的常见错误与判断依据

第一类错误是“条件与阈值脱节”，例如条件写“频繁转账”，阈值却只给了金额，导致程序无法判断“频繁”如何计量。判断依据很简单：把字段内容交给一位未参与设计的开发人员，若其能直接写出伪代码而无需追问，则填写合格。

第二类错误是“窗口口径缺失”，只写“7天内”而未说明是滚动7×24小时还是7个自然日。这类歧义在月末、季末和节假日前后会集中暴露，造成同一客户在不同日期被重复预警或漏警。规范做法是在规则文档中附一个边界算例，用具体时间点验证窗口计算逻辑。

第三类错误是“处置动作无主体”，写了“核实交易背景”却未指明由网点、集中作业中心还是反洗钱岗执行，导致工单在队列中滞留。处置动作字段必须能回答“谁在什么时限内做什么、留下什么记录”。

第四类错误是“编号与版本混用”，修订规则时直接覆盖原记录，造成历史预警无法回溯到当时的判断口径。正确做法是保留旧版本记录并标记失效日期，新版本继承编号、递增版本号，预警工单中同时记录命中的规则版本。

把上述八个字段固化为登记模板并纳入规则上线前的评审清单，可以让规则从“个人经验”转变为“组织资产”：名称与编号保证可追溯，监测对象保证范围可控，触发条件、阈值与时间窗口保证判断可复现，优先级与处置动作保证响应可考核。后续的规则调优、预警质量分析与检查举证，都建立在这份结构化登记之上。