4. AML人工复核体系架构
人工复核不是“把可疑交易丢给分析师”这么简单。一个可运营、可审计、可扩展的HITL（Human-in-the-loop）反洗钱体系，必须由六个相互咬合的组件构成：数据层提供可信事实，规则引擎负责确定性拦截，模型层负责概率性排序，工单系统承载人的判断与协作，审计追踪保证每一步可回溯，权限设计确保“谁在什么条件下能做什么”被严格控制。本章按数据流顺序拆解这套架构，并给出可落地的设计要点。
一、核心原理：分层解耦与责任边界
AML复核体系的第一原则是分层解耦。数据层、规则引擎、模型层各自独立演进，通过标准化接口交换“案件”与“证据”，而不是让规则直接读模型特征、让工单系统直接查原始流水。这样做的好处是：规则变更不需要重新训练模型，模型迭代不需要改动工单流程，审计追踪只需记录接口层的输入输出即可覆盖全链路。
第二原则是责任边界清晰。规则引擎输出的是“命中/未命中”与命中原因，属于确定性判断；模型层输出的是风险分与特征贡献，属于概率性判断；人工复核输出的是“上报/排除/补充调查”的最终处置，属于责任性判断。三者不可互相替代，也不应把模型的概率分直接当作处置结论。
关键设计约束：任何进入人工复核队列的案件，必须同时携带规则命中证据与模型风险分。缺少任一来源的案件应进入“数据补全”子队列，而不是直接分配给分析师。
二、六层架构与数据流
下图展示从交易发生到人工处置完成的完整链路。注意工单系统并不直接访问原始数据层，而是通过案件服务获取已标准化的证据包。
三、方法流程：从案件生成到处置闭环
- 案件生成：规则引擎与模型层并行运行，命中任一来源即生成案件。案件ID全局唯一，携带规则命中码、模型风险分、特征贡献Top5。
- 优先级排序：按“规则严重度 × 模型分 × 客户风险等级”计算优先级，高优先级案件进入快速通道，低优先级进入批量队列。
- 权限过滤与分配：权限网关根据分析师角色、负责区域、可处理金额上限进行过滤，分配时记录分配时间与分配人。
- 人工复核：分析师查看证据包，填写处置结论、理由码、补充说明，必要时发起协查或升级。
- 审计回写：每一步操作写入不可篡改的审计日志，包括查看、修改、提交、撤回等动作。
- 反馈闭环：处置结论作为标签回流至模型层，用于后续再训练与规则阈值调优。
四、关键配置与代码示例
以下是一个简化的案件优先级计算配置，使用YAML描述规则权重与模型分权重，便于运营人员调整而不需要改代码。
case_priority:
rule_weight: 0.4
model_weight: 0.35
customer_risk_weight: 0.25
thresholds:
high: 0.75
medium: 0.45
low: 0.0
rule_severity:
SANCTION_HIT: 1.0
STRUCTURING: 0.8
HIGH_RISK_GEO: 0.7
VELOCITY: 0.5
审计日志的最小字段集必须包含：案件ID、操作人、操作类型、操作时间、操作前状态、操作后状态、IP地址、会话ID。以下是一条典型审计日志的结构：
{
"case_id": "AML-2024-000871",
"operator": "analyst_zhang",
"action": "SUBMIT_DISPOSITION",
"timestamp": "2024-06-12T14:32:07+08:00",
"before_state": "IN_REVIEW",
"after_state": "ESCALATED",
"reason_code": "STRUCTURING_CONFIRMED",
"ip": "10.12.33.41",
"session_id": "sess_9f2a1c"
}
五、权限设计：RBAC与ABAC的混合模型
纯RBAC（基于角色的访问控制）在AML场景下不够用，因为同一角色在不同区域、不同金额、不同时段下的权限可能不同。推荐采用RBAC + ABAC混合模型：角色决定基础能力，属性决定动态边界。
| 控制维度 | 示例属性 | 控制效果 |
|---|---|---|
| 角色 | 分析师、高级分析师、合规官 | 决定可执行的操作类型 |
| 区域 | 华东、华南、海外 | 限制可见案件范围 |
| 金额 | 单笔≤50万、≤500万、无上限 | 限制可处置案件金额 |
| 时段 | 工作时间、非工作时间 | 非工作时间高金额处置需二次授权 |
实践建议：权限变更必须走审批流并写入审计日志。任何“临时提权”都应设置自动过期时间，默认不超过4小时。
六、常见误区与复盘
误区一：规则引擎与模型层直接耦合。有些团队让规则直接调用模型API，导致规则变更时模型服务被频繁触发，稳定性下降。正确做法是两者独立运行，由案件服务合并结果。
误区二：审计追踪只记录“最终结论”。只记录结论无法还原分析师的思考过程，也无法发现“批量误判”。必须记录查看、停留时长、修改理由等中间行为。
误区三：权限设计过粗。所有分析师都能看到全部案件，容易造成敏感数据泄露和“挑案件”行为。应按区域和金额做最小权限切分。
复盘要点：每季度对审计日志做一次“反向抽样”——随机抽取已排除案件，由高级分析师盲审。若盲审推翻率超过5%，说明规则阈值或模型分排序需要调整，而不是简单增加人工复核量。
架构的最终检验标准不是“有多少层”，而是当监管问询“这笔案件为什么被排除”时，能否在30秒内从审计日志中还原完整链路：谁、在什么时间、看到了什么证据、依据什么理由、做出了什么处置。能做到这一点，六层架构才算真正落地。