3. 交易监测体系概览

交易监测体系不是单一系统，而是一条从“数据进入”到“结论输出”的完整流水线。理解这条流水线，是后续做历史回放和效果验证的前提。因为回放验证的对象不是某个孤立规则，而是整条链路：数据是否完整、规则是否命中、场景是否聚合、阈值是否合理、预警是否被正确处置、案件是否被准确认定、报告是否可追溯。任何一个环节断裂，都会让监测效果失真。

一、核心原理：监测体系是一条“漏斗式”链路

交易监测的本质，是在海量交易中逐层收敛风险。第一层是数据层，包括客户身份、账户、交易流水、渠道、对手方等；第二层是规则与模型层，通过规则、模型、名单、场景、阈值把可疑行为筛出来；第三层是预警与案件层，把命中结果转化为可处置的预警，再经人工或系统分析形成案件；第四层是报告与反馈层，把案件结论输出为内部报告或监管报告，并反向优化规则和阈值。

这条链路的核心逻辑是：规则负责“抓得准”，模型负责“抓得全”，名单负责“抓得死”，场景负责“抓得成串”，阈值负责“抓得稳”，预警和案件负责“抓得实”，报告负责“抓得可证”。 任何一层缺失，都会导致漏报或误报。

二、方法流程：七类要素如何协同工作

下面用一张表把监测体系的核心要素、作用、典型输入输出和常见问题列清楚，便于在回放时逐项对照。

在实际系统中，这些要素通常以配置和日志形式存在。例如，一条典型的规则配置可能如下：

rule_id: R001
rule_name: 单日累计现金存入超阈值
condition:
  txn_type: CASH_DEPOSIT
  window: 1D
  sum_amount: >= 50000
  customer_risk: [HIGH, MEDIUM]
action:
  generate_alert: true
  alert_level: HIGH
  scene: SC_CASH_STRUCTURING

当规则命中后，系统会生成预警，并进入案件管理流程。回放验证时，我们需要关注的是：这条规则在历史数据上是否仍然有效？阈值是否应该调整？场景聚合是否合理？

三、案例/场景：一个“现金拆分”场景的全流程

假设某客户在三天内分别在不同网点存入现金 4.8 万、4.9 万、4.7 万，单笔均低于 5 万，但累计超过 14 万。监测体系会这样运转：

1. 规则层：单笔大额现金规则未命中，但“多笔累计现金存入”规则命中。
2. 模型层：该客户行为评分升高，因为其交易模式与历史拆分案例相似。
3. 名单层：客户不在制裁名单，但对手方账户曾出现在内部关注名单中。
4. 场景层：系统将多笔现金存入、分散网点、接近阈值等特征聚合为“现金拆分”场景预警。
5. 阈值层：场景阈值设置为“3日内累计≥10万且单笔均低于5万”，触发预警。
6. 预警与案件：预警生成后，调查人员调取客户身份、资金来源、交易背景，形成案件。
7. 报告：若无法合理解释，则提交可疑交易报告，并记录报告编号、提交时间、结论。

这个案例说明：单看规则可能漏掉，单看模型可能误报，只有把规则、模型、名单、场景、阈值串起来，才能形成完整判断。 回放验证时，我们要检查的正是这条链路在历史数据上是否依然成立。

四、误区与复盘：回放验证中最容易踩的坑

复盘时，建议按以下清单逐项检查：

• 数据是否完整：历史交易、客户信息、名单版本是否齐全？
• 规则是否仍适用：业务模式、监管要求是否已变化？
• 阈值是否合理：是否按客群、地区、渠道分层？
• 场景是否重叠：多个场景是否重复预警同一行为？
• 预警处置是否闭环：是否有调查记录、结论和报告？
• 报告是否可追溯：报告编号、时间、结论是否与预警关联？