2. 反洗钱核心业务场景：客户尽职调查(CDD)、可疑交易监控(STR)、大额交易上报、制裁名单筛查
反洗钱(AML)合规体系围绕四个核心业务场景构建，它们构成了金融机构反洗钱系统的数据流与决策闭环。本章逐一拆解每个场景的业务定义、API 交互模式以及在线推理的关键特征，为后续的 API 发布与推理引擎设计奠定业务基础。
2.1 客户尽职调查 (CDD)
客户尽职调查是反洗钱的第一道防线，要求金融机构在建立业务关系前、业务关系存续期间以及特定事件触发时，识别并核实客户身份、了解其交易目的与资金来源。CDD 分为三个层级：
| 层级 | 适用对象 | 核心动作 | API 典型接口 |
|---|---|---|---|
| 简化尽职调查 (SDD) | 低风险客户（如政府机构、上市公司） | 基础身份验证、无额外尽调 | POST /api/v1/cdd/simplified |
| 标准尽职调查 (CDD) | 普通个人/企业客户 | 身份证件核验、受益所有人识别、职业/经营背景采集 | POST /api/v1/cdd/standard |
| 强化尽职调查 (EDD) | 高风险客户（如 PEP、制裁关联方） | 财富来源证明、交易目的说明、持续监控频率提升 | POST /api/v1/cdd/enhanced |
在线推理要点： CDD 在线推理通常需要实时调用外部数据源（如工商信息、公安身份核查、全球 PEP 名单），API 响应时间应控制在 2 秒以内，且需支持异步回调模式以应对第三方接口延迟。
2.2 可疑交易监控 (STR)
可疑交易监控是反洗钱的核心侦测环节。系统通过规则引擎、统计模型或机器学习模型，对客户交易行为进行实时或准实时分析，识别出与客户身份、财务状况、交易习惯不符的异常模式。一旦触发预警，需生成可疑交易报告(STR)并上报金融情报机构。
- 规则型监控： 基于阈值与逻辑组合（如：单笔现金交易 > 5 万元且交易频率异常）。
- 行为型监控： 基于客户历史画像的偏差检测（如：账户突然大额快进快出）。
- 网络型监控： 基于资金链路与关联账户的图分析（如：多账户资金归集至同一最终受益人）。
API 设计提示： 可疑交易监控在线推理通常采用“流式+批式”混合架构。实时交易通过流处理引擎（如 Kafka + Flink）调用推理 API，而日终批量扫描则通过离线推理 API 完成。API 需支持
transaction_id 幂等去重与结果缓存。
2.3 大额交易上报
根据监管要求，金融机构对超过特定金额（如人民币 5 万元以上的现金交易、20 万元以上的转账交易）必须在大额交易发生后的规定时限内（通常为 5 个工作日）向反洗钱监测中心上报。大额交易上报的核心在于“及时、准确、完整”。
| 交易类型 | 上报阈值（人民币） | 上报时限 | API 上报模式 |
|---|---|---|---|
| 现金交易 | ≥ 5 万元 | 5 个工作日 | 实时推送 + 批量补报 |
| 法人/其他组织转账 | ≥ 200 万元 | 5 个工作日 | 批量上报 |
| 自然人转账 | ≥ 20 万元（跨境） | 5 个工作日 | 实时推送 |
常见陷阱： 大额交易上报 API 必须处理“拆分交易”场景——客户故意将一笔大额交易拆分为多笔低于阈值的交易。在线推理引擎应具备“同一客户+同一对手+同一日”的聚合检测能力，并在上报前进行合并判断。
2.4 制裁名单筛查
制裁名单筛查是反洗钱合规的刚性约束。金融机构必须在交易处理前、客户准入时以及名单更新后，将客户名称、国籍、证件号、交易对手等信息与国内外制裁名单（如联合国安理会制裁名单、OFAC 特别指定国民名单、中国公安部涉恐名单）进行精确匹配与模糊匹配。
2.5 四大场景的 API 共性特征
尽管四个场景的业务目标不同，但从 API 架构与在线推理视角看，它们共享以下关键特征：
- 低延迟要求： 交易拦截类场景（制裁筛查、大额上报）要求 API 响应时间 < 500ms，否则影响业务连续性。
- 数据一致性： 所有场景均需保证同一客户/交易的多次查询结果一致，避免因缓存或异步导致重复上报或漏报。
- 可审计性： 每次 API 调用必须记录完整的请求/响应日志，包括推理时间、模型版本、匹配规则 ID，以备监管检查。
- 名单与规则热更新： 制裁名单、大额阈值、可疑规则需支持在线热加载，API 网关应具备版本路由能力。