2. AML 推理链路全景：从交易监控、名单筛查到可疑报告的全流程架构图
反洗钱（AML）推理链路并非单一模块的独立工作，而是由交易监控、名单筛查、客户风险画像、案例管理与可疑报告（STR）等多个环节串联而成的闭环体系。本章从 API 架构视角，拆解全流程的节点、数据流向与关键决策点。
2.1 全流程核心阶段
一条完整的 AML 推理链路通常包含以下 6 个阶段，每个阶段都依赖上游输出并向下游提供结构化数据：
| 阶段 | 核心功能 | 典型输入 | 典型输出 |
|---|---|---|---|
| 1. 数据接入 | 多源交易数据清洗、标准化 | 核心银行、支付、跨境报文 | 统一交易事件流 |
| 2. 交易监控 | 规则引擎 + 行为评分模型 | 交易事件、客户画像 | 预警（Alert） |
| 3. 名单筛查 | 制裁名单、PEP、负面媒体比对 | 交易参与方、受益所有人 | 命中/未命中 + 匹配分数 |
| 4. 客户风险画像 | 动态风险评级（低/中/高） | 交易行为、名单结果、KYC 数据 | 风险评分 + 画像标签 |
| 5. 案例管理 | 调查员人工研判、关联分析 | 预警、名单命中、画像 | 调查结论（可疑/正常） |
| 6. 可疑报告 | 自动生成 STR 并提交监管 | 案例结论、交易明细、证据链 | STR 报文（XML/JSON） |
架构提示： 在 API 设计时，每个阶段应暴露独立的异步接口（如 Kafka Topic 或 REST Callback），避免同步阻塞导致全链路超时。交易监控与名单筛查建议并行执行，再合并结果进入案例管理。
2.2 全流程架构图（SVG）
下图展示了 AML 推理链路的核心节点与数据流向。箭头代表事件驱动或 API 调用关系，颜色区分不同职责域。
2.3 关键 API 交互点
在全流程中，API 设计需要重点关注以下 4 个交互点，它们直接影响推理链路的吞吐与准确性：
- 交易事件发布 API（数据接入 → 下游）：采用批量 + 实时双通道，支持重试与幂等。
- 预警回调 API（交易监控 → 案例管理）：携带规则 ID、命中字段、风险分数，触发案例创建。
- 名单比对结果 API（名单筛查 → 案例管理）：返回匹配实体、匹配类型（精确/模糊）、分数阈值。
- 案例结论提交 API（案例管理 → STR 生成）：包含调查员结论、证据附件、监管机构代码。
实战要点： 名单筛查接口通常要求 < 200ms 响应时间，否则会影响交易监控的实时性。建议对制裁名单做本地缓存 + 增量同步，对 PEP 名单使用异步查询。
2.4 推理链路数据流（第二张 SVG）
为了更清晰地展示数据在推理链路中的流转形态，下图以“一笔跨境汇款”为例，展示从交易发生到 STR 提交的完整数据流与状态变化。
2.5 架构设计原则
- 事件驱动 + 异步解耦： 交易监控、名单筛查、客户画像之间通过消息队列（如 Kafka/RabbitMQ）异步通信，避免单点故障扩散。
- 可观测性： 每个 API 接口必须输出 traceId、处理耗时、决策原因码，便于调查员回溯推理链路。
- 阈值可配置： 规则阈值、名单匹配分数、风险评级权重均通过配置中心动态下发，无需重启服务。
- 幂等设计： 案例创建、STR 提交等关键写接口支持幂等，防止重复提交导致监管数据混乱。
常见陷阱： 交易监控与名单筛查如果使用同步 RPC 调用，当名单服务超时时会导致交易监控阻塞，进而引发全链路雪崩。务必在架构层面将这两个环节设计为并行异步调用，并设置合理的超时与降级策略。