3. 证据留存模板的字段设计

交易监测的价值不仅在于“发现可疑”，更在于“证明可疑”。当一条规则命中、一笔交易被标记，后续的复核、上报、监管问询乃至司法程序，都要求我们能够拿出一份完整、可信、可追溯的证据材料。证据留存模板就是承载这份材料的骨架，而字段设计决定了这副骨架是否经得起推敲。本节聚焦模板中最关键的七类字段：证据类型、来源系统、采集时间、存储位置、哈希值、责任人和关联规则编号，逐一说明它们的标准化定义与填写要求。

为什么字段必须标准化

在实际工作中，证据留存最容易出问题的地方往往不是“没留”，而是“留了但说不清”。例如，同一份交易流水，有人记为“核心系统导出”，有人记为“柜面系统截图”；采集时间有的写交易时间，有的写导出时间；存储位置有的写服务器路径，有的写共享盘目录。字段口径不统一，证据之间就无法建立稳定的关联，复核人员需要反复沟通确认，监管检查时也难以自证链条完整。标准化的本质，是让每一个字段都有唯一、明确、可机器校验的语义，使证据从“个人经验”升级为“组织资产”。

七类核心字段的标准化定义

证据类型用于标识证据的形态与证明目的。建议采用受控词表，而非自由文本，常见取值包括：交易流水记录、账户开户资料、身份核验影像、登录与操作日志、通信记录、规则命中快照、人工复核意见、外部协查回函等。每个取值应对应明确的证明对象，例如“规则命中快照”证明的是规则在特定时点对特定交易作出了判定，而不是证明交易本身真实发生。类型字段还应预留“组合证据”的表达方式，当一份材料同时包含流水与截图时，应拆分为多条记录分别登记，避免一条记录承载多重证明目的。

来源系统标识证据的原始产生或导出系统，需精确到系统名称与模块，例如“核心账务系统—交易流水模块”“反洗钱监测系统—规则引擎”“影像平台—证件影像库”。来源系统字段的意义在于确定证据的原始归属，便于后续向源系统发起一致性核验。填写时应使用组织内已登记的系统清单编码，避免使用“业务系统”“后台”这类模糊表述。

采集时间是最容易被混淆的字段，必须明确其参照约定。建议统一定义为“证据被固化进入留存流程的时刻”，采用带时区的标准格式，如 2024-06-18T14:32:07+08:00。与之相对，证据所反映的业务发生时间应单独设置“业务时间”字段，二者不可混用。例如一笔发生在 6 月 17 日 23:50 的交易，其流水在 6 月 18 日 09:15 被导出固化，则业务时间为 6 月 17 日 23:50，采集时间为 6 月 18 日 09:15。区分这两个时间，才能在时效性审查中准确判断证据是否在规定的 T+1 或 T+3 窗口内完成留存。

存储位置应给出可定位到具体对象的路径或标识，而非笼统的“档案库”。推荐采用“存储介质标识 + 目录层级 + 对象名”的结构，例如“WORM-ARCHIVE-02 / 2024/06/18 / R20240618-0037.zip”。对于写入一次多次读取的归档介质，还应记录卷标或对象存储的版本号。存储位置字段的标准化，直接决定了证据能否被独立、快速地调取。

哈希值是证据完整性的技术锚点。标准做法是在证据固化完成后，对证据文件计算 SHA-256 摘要，并将 64 位十六进制字符串完整登记，同时注明算法名称。哈希值字段应配套“哈希计算时间”和“计算工具版本”，以便在需要复算时保持方法一致。需要强调的是，哈希值证明的是“文件自计算时刻起未被篡改”，它不能替代对来源真实性的审查，因此哈希字段必须与来源系统、采集时间联合使用才有完整意义。

责任人指对本次证据采集、登记与保管负责的具体人员，应记录工号与姓名，而非仅记录部门。责任人字段承担的是可问责性：当证据出现缺失、损坏或口径错误时，能够定位到采集与登记环节的执行者。对于多人协作的场景，可区分“采集人”与“复核人”两个子字段，复核人负责在证据入库前核对类型、来源、时间与哈希值的一致性。

关联规则编号把证据与监测规则连接起来。该字段应填写规则库中规则的唯一编号及版本号，例如“RULE-TR-0142 v3”。规则会迭代，同一编号在不同版本下的判定逻辑可能不同，因此版本号不可省略。当一笔交易同时命中多条规则时，应允许一对多登记，或为每条规则分别建立证据记录，确保“哪条规则、哪个版本、基于哪份证据作出判定”这条链路清晰可查。

字段之间的约束与校验

字段设计不能停留在“列出来”，还要定义它们之间的约束。第一，证据类型与来源系统应存在合理映射：交易流水记录通常来自核心账务系统，身份核验影像通常来自影像平台，若出现“影像证据来自规则引擎”这类组合，应在入库时触发提示。第二，采集时间不得早于业务时间，且应落在规则命中后的规定留存窗口内，超出窗口需记录原因。第三，哈希值必须与存储位置指向的对象一一对应，任何一次存储迁移都应重新计算并登记新哈希，同时保留旧记录形成迁移链。第四，关联规则编号必须存在于规则库且版本有效，规则下线后其历史证据仍应保留原版本号，不得改写为最新版本。

这些约束最好以校验规则的形式固化在留存系统中。例如在入库环节执行如下伪代码逻辑：

校验(记录 r):
  若 r.证据类型 不在 受控词表: 拒绝入库
  若 r.采集时间 < r.业务时间: 拒绝入库
  若 r.采集时间 - r.规则命中时间 > 留存窗口: 标记"超窗"并要求填写原因
  若 SHA256(读取(r.存储位置)) != r.哈希值: 拒绝入库并告警
  若 r.关联规则编号 不在 规则库 或 版本失效: 标记"待确认"
  通过: 写入证据台账，状态置为"已固化"

一份可参考的字段登记示例

下表给出一条规则命中后形成的证据登记示例，参数为教学假设，实际取值应依据机构系统与规则库填写。

落地时的常见偏差

第一类偏差是把采集时间写成业务时间，导致时效性审查失真；第二类偏差是哈希值只登记前若干位或省略算法，复算时无法比对；第三类偏差是存储位置写成部门共享目录，人员变动后路径失效；第四类偏差是关联规则只写编号不写版本，规则迭代后无法还原当时的判定逻辑。避免这些偏差的关键，是把字段定义写进留存系统的元数据规范，并在入库校验中强制执行，而不是依赖填写人的自觉。字段标准化做到位，证据才真正具备可复核、可追溯、可举证的基础。