4. 规则与证据的映射关系建立

监测规则解决的是“什么情况需要报警”，证据留存解决的是“报警之后凭什么证明判断成立”。两者之间如果没有稳定的映射关系，规则触发后往往会出现三种尴尬：证据不足，无法复核；证据散落，追溯成本高；证据与规则口径不一致，复核结论无法验证。因此，本节的核心任务是：为每一条监测规则建立一份“必须留存证据清单”，并让这份清单成为规则上线的前置条件，而不是事后补录的附属品。

一、映射关系的本质：从规则逻辑拆出证据需求

一条监测规则通常由三部分构成：监测对象（账户、客户、交易、设备、商户等）、判断条件（阈值、频次、时间窗、关联关系、名单命中）、触发结论（可疑、异常、需人工复核）。证据清单不是凭经验罗列，而是从这三部分逐项反推：要证明“对象确实是这个对象”“条件确实被满足”“结论确实由该条件推出”，分别需要哪些原始记录。

以一条典型规则为例：“同一客户名下多个账户在10分钟内发生≥5笔跨行转出，单笔金额均≥5万元，触发可疑监测”。拆解后，证据需求自然浮现：客户与账户的归属关系证明、每笔交易的流水明细（时间、金额、收付方、渠道）、时间窗内的交易计数依据、跨行标识的判定来源。这些证据不是“越多越好”，而是缺一不可、多则冗余——缺一项则规则无法验证，多一项则增加留存成本与隐私暴露面。

二、证据清单的字段结构

为了让清单可执行、可检查，建议每条规则对应一张证据映射表，至少包含以下字段：证据项名称、证据类型（交易流水、开户资料、日志、影像、外部名单等）、来源系统、采集时点（实时/准实时/T+1）、留存粒度（单笔/账户级/客户级）、留存期限、责任岗位、校验方式。其中“采集时点”和“留存粒度”最容易被忽视，却直接决定证据能否支撑规则的时间窗判断。

例如时间窗类规则，若交易流水按T+1批量落库，而规则要求10分钟窗口内计数，则必须额外留存实时流水的中间计数快照或规则引擎的判定日志，否则事后无法还原“当时窗口内到底有几笔”。这就是证据清单必须与规则实现方式对齐的原因。

三、映射建立的操作路径

实际操作中，可按“规则拆解—证据识别—来源确认—缺口补齐—清单固化”五步推进，但重点不在步骤本身，而在于每一步的产出要可核查。规则拆解产出判断条件清单；证据识别产出候选证据项；来源确认要落到具体系统、表、字段甚至接口；缺口补齐针对“规则需要但系统没有”的证据，决定是新增埋点、调整日志级别，还是修改规则口径；最后将清单固化为规则配置的一部分，随规则版本一同管理。

下面这张图展示了一条规则从判断条件到证据清单、再到触发后可追溯验证的映射结构，重点体现“条件—证据—校验”的对应关系，而非线性流程。

四、清单固化为可执行模板

映射关系建立后，应形成可直接填写的证据清单模板，并作为规则配置的附件随版本发布。下面给出一份示例模板，字段按本节规则场景设计，实际使用时可按机构系统情况调整。

五、常见缺口与处理原则

实践中，证据缺口最常出现在三类情形。第一类是规则依赖实时计算，但证据只留了结果，例如只存了“命中”标记，没存窗口内逐笔明细，导致无法复算。处理原则是：凡涉及计数、求和、去重的规则，必须留存参与计算的明细或可复算的中间快照。第二类是口径不一致，规则按折人民币金额判断，证据却只留原币金额，复核时无法直接验证。处理原则是：证据中的金额、时间、方向字段必须与规则判断口径同源同义。第三类是证据分散且无关联键，交易流水、日志、关系表各自独立，无法串成一条链。处理原则是：为每次触发生成统一的触发流水号，并让各证据项都携带该流水号，形成可串联的证据链。

最后需要强调，映射关系的价值在于把“可追溯、可验证”从口号变成可检查的动作：每条规则有清单，每项证据有来源，每个来源有校验方式，每次触发有统一关联键。做到这四点，规则触发后的复核就不再依赖个人记忆和临时找数，而是沿着既定映射关系稳定复现判断过程。