反欺诈（Anti-Fraud）回答的是”这笔交易是不是坏人发的”；反洗钱（Anti-Money Laundering，AML）回答的是更结构性、更合规化的问题：这个客户是不是坏人？这条资金链路是不是把”黑钱”洗白？这个对手方是不是我国或国际社会正在制裁的实体？ 从工程角度看，前者关心毫秒级决策、F1 分数与体验；后者关心监管可解释性、文档留痕、报表准时、历史可回溯七到十年。做错了反欺诈，公司亏钱；做错了 AML，公司被罚款、管理层被追责、牌照被吊销。2012 年汇丰银行（HSBC）因对墨西哥毒贩资金清洗不力被美国司法部罚没 19.2 亿美元，2020 年 FinCEN 文件（FinCEN Files）揭露全球多家大型银行累计处理可疑交易超过 2 万亿美元——这两个事件重塑了每一家金融机构对 AML 的投入强度。

本篇读者画像：支付公司风控或合规工程师、数字银行 KYC 系统研发、加密资产交易所合规团队、需要理解”监管科技”（RegTech）落地方式的架构师。我们默认读者已阅读上一篇《反欺诈》，理解设备指纹、图谱与行为序列；本文聚焦合规框架下的系统设计：监管怎么说、客户怎么识别、名单怎么筛、交易怎么监测、可疑怎么上报、链上钱怎么追。最后一节讨论 GDPR 与 AML 留存期的张力——这是工程上最微妙的一处。

一、监管框架：工程师的”ABI”

工程师习惯把法律当”外部 API”——不必读全文，但必须知道每个端点返回什么、要求什么字段。AML 的监管栈有三层：国际标准（FATF）、主权国家法律、行业指引。

1.1 FATF 四十项建议

金融行动特别工作组（Financial Action Task Force，FATF）于 1989 年由 G7 发起，2012 年发布当前版本《四十项建议》（The FATF Recommendations），并通过相互评估（Mutual Evaluation）与”灰名单/黑名单”机制对各国施加压力。与工程相关的核心条款：

• R.10 客户尽职调查（Customer Due Diligence，CDD）：建立业务关系、执行超过阈值（通常 15,000 美元或等值）的偶发性交易、怀疑洗钱或恐怖融资、对既有信息真实性存疑时，必须执行 CDD。
• R.11 记录保存：所有交易记录、CDD 材料至少保存 5 年，监管要求时需要”足以重建单笔交易”的详尽度。
• R.12 政治公众人物（Politically Exposed Persons，PEP）：外国 PEP 必须 EDD；国内 PEP 与国际组织 PEP 风险为本。
• R.16 跨境电汇与旅行规则（Travel Rule）：1,000 美元以上跨境电汇必须附带完整的付款人与收款人信息，2019 年扩展到虚拟资产服务提供商（Virtual Asset Service Provider，VASP）。
• R.20 可疑交易报告（Suspicious Transaction Report，STR）：发现或有合理理由怀疑资金涉及犯罪收益，立即报告金融情报机构（Financial Intelligence Unit，FIU）。

1.2 美国：BSA / USA PATRIOT Act / OFAC

• Bank Secrecy Act（BSA，1970）：联邦层面反洗钱基石，要求金融机构保存记录、提交 CTR（Currency Transaction Report，单日现金 > 10,000 美元）与 SAR（Suspicious Activity Report）。
• USA PATRIOT Act（2001）：在 9/11 后引入，Section 326 定义 CIP（Customer Identification Program）最低要求，Section 311/312 给予财政部对高风险司法辖区”特殊措施”权限，Section 314(a)/(b) 建立机构间信息共享通道。
• OFAC（Office of Foreign Assets Control）：美国财政部制裁执行部门。SDN（Specially Designated Nationals）名单是全球筛查的默认”最低标准”；与 SDN 实体直接或间接（50% 规则）交易可能导致民事或刑事责任。2023 年币安（Binance）与 OFAC 和解支付 9.68 亿美元，这是历史上 OFAC 最大民事罚款之一。

SAR 与 CTR 上报给 FinCEN（Financial Crimes Enforcement Network），SAR 规定在发现后 30 天内提交，异常严重可 60 天。

1.3 欧盟：AMLD 5/6 与 MiCA

• AMLD 5（指令 2018/843）：扩大到虚拟货币交易所与托管钱包服务商、预付卡阈值降至 150 欧元、公共受益所有权登记册（Ultimate Beneficial Owner，UBO）。
• AMLD 6（指令 2018/1673）：刑事化洗钱 22 项上游罪名、法人责任、最低监禁刑 4 年。
• AML Package（2024 生效）：设立 AMLA（Anti-Money Laundering Authority，总部法兰克福），首批直接监管 40 家高风险跨境金融集团；同时出台单一规则册（Single Rulebook Regulation）。
• MiCA（Regulation (EU) 2023/1114）：加密资产市场规则，配套《资金转移规定》（Regulation (EU) 2023/1113）把 Travel Rule 应用于加密资产，无金额门槛——这是欧盟对 FATF R.16 的加强实现。

1.4 中国监管框架

• 《中华人民共和国反洗钱法》2025 年修订版（自 2025 年 1 月 1 日起施行）：扩大适用范围至特定非金融机构（房地产中介、贵金属交易商、律师事务所），明确金融机构客户尽调、受益所有人识别、特别预防措施义务，上调罚款上限。
• 人民银行令〔2025〕第 3 号《金融机构反洗钱和反恐怖融资监督管理办法》：取代原 2014 年版本，细化风险为本的分类分级管理。
• 《非银行支付机构条例》（国务院令第 768 号，2024 年 5 月 1 日施行）：把支付机构的备付金、反洗钱纳入行政法规层级，对接人民银行 1 号令、2 号令配套部门规章。
• 《金融机构大额交易和可疑交易报告管理办法》（人民银行令〔2016〕第 3 号）：规定大额交易上报（人民币 5 万元、外币等值 1 万美元以上单日累计等阈值）与可疑交易上报，上报至中国反洗钱监测分析中心（China Anti-Money Laundering Monitoring and Analysis Center，CAMLMAC）。
• 《金融机构客户尽职调查和客户身份资料及交易记录保存管理办法》：留存期限 自业务关系结束当年起不少于 5 年。

1.5 香港、新加坡

• 香港金管局（HKMA） 的《打击洗钱及恐怖分子资金筹集指引》（Guideline on AML/CFT）与《打击洗钱及恐怖分子资金筹集条例》（第 615 章）。虚拟资产服务提供商由证监会（SFC）发放 VASP 牌照，OSL、HashKey 为早期持牌方。
• 新加坡金管局（MAS） 依据 Payment Services Act（PSA） 与 Notice PSN01/PSN02 对 DPT（Digital Payment Token）服务提供商提出 AML/CFT 要求，Notice PSN02 对 Travel Rule 设 1,500 新元门槛并要求 VASP 间信息交换。

工程上我们并不逐条实现法条，而是把所有来源汇集成一张”合规矩阵”：管辖地 × 客户类型 × 交易产品 × 风险等级 → 规则集合。下面的 KYC 生命周期就是矩阵的”横切”。

flowchart LR
  A[获客/开户申请] --> B[CIP 身份识别]
  B --> C{PEP/制裁命中?}
  C -- 是 --> D[EDD 加强尽调]
  C -- 否 --> E[CDD 基础尽调]
  D --> F[风险评级 R1-R4]
  E --> F
  F --> G[关系建立]
  G --> H[持续监测]
  H --> I{触发事件?}
  I -- 信息变更/交易异常/名单更新 --> J[触发式复核]
  I -- 周期到期 --> K[定期复核]
  J --> F
  K --> F
  G --> L[关系终止]
  L --> M[档案封存 5-10 年]

2.1 CIP：客户识别

CIP 是开户的”门槛”。自然人最小字段集：姓名、出生日期、地址、身份证号（或护照号 + 签发国）。企业客户还需工商注册信息、法定代表人、受益所有人（UBO，通常持股 25% 以上）。

CREATE TABLE customer (
  customer_id      BIGINT PRIMARY KEY,
  customer_type    VARCHAR(16) NOT NULL,           -- INDIVIDUAL / CORPORATE
  legal_name       VARCHAR(200) NOT NULL,
  legal_name_en    VARCHAR(200),                   -- 英文/拼音，用于制裁筛查
  date_of_birth    DATE,
  nationality      CHAR(2),                        -- ISO 3166-1 alpha-2
  residence_country CHAR(2),
  id_type          VARCHAR(32),                    -- NATIONAL_ID / PASSPORT / BR_CODE
  id_number_hash   CHAR(64) NOT NULL,              -- SHA-256(id || salt)
  id_number_enc    VARBINARY(256),                 -- AES-GCM 密文
  created_at       TIMESTAMP NOT NULL,
  onboarded_by     VARCHAR(64) NOT NULL,           -- 业务线 / 渠道
  risk_rating      CHAR(2),                        -- R1..R4
  review_due_at    DATE,                           -- 下次定期复核
  status           VARCHAR(16) NOT NULL            -- ACTIVE / SUSPENDED / CLOSED
) PARTITION BY RANGE (YEAR(created_at));

CREATE INDEX idx_customer_name_en ON customer(legal_name_en);
CREATE INDEX idx_customer_review ON customer(review_due_at, status);

CREATE TABLE customer_document (
  doc_id           BIGINT PRIMARY KEY,
  customer_id      BIGINT NOT NULL,
  doc_type         VARCHAR(32) NOT NULL,           -- ID_FRONT / ID_BACK / PASSPORT / SELFIE / LIVENESS_VIDEO / UTILITY_BILL
  storage_uri      VARCHAR(512) NOT NULL,          -- S3 / OSS 加密桶
  ocr_json         JSON,
  verify_status    VARCHAR(16) NOT NULL,           -- PASS / FAIL / MANUAL
  hash_sha256      CHAR(64) NOT NULL,              -- 反篡改
  uploaded_at      TIMESTAMP NOT NULL
);

CREATE TABLE beneficial_owner (
  customer_id      BIGINT NOT NULL,
  ubo_name         VARCHAR(200) NOT NULL,
  ubo_id_hash      CHAR(64) NOT NULL,
  ownership_pct    DECIMAL(5,2) NOT NULL,
  is_pep           BOOLEAN NOT NULL DEFAULT FALSE,
  PRIMARY KEY (customer_id, ubo_id_hash)
);

几个工程细节：

• 证件号加密而非明文：一方面满足《个人信息保护法》、GDPR “最小必要”原则；另一方面避免泄露。查询靠 hash 列，加盐防止彩虹表。
• 文件 SHA-256：监管稽查常要求”这份身份证照片五年前是否被修改过”，哈希写入 WORM（Write-Once-Read-Many）存储或链上锚定。
• 分区按年：档案留存 5–10 年，按年份分区方便到期批量归档/删除。

2.2 CDD 与 EDD

CDD 的输出是客户风险评级（Customer Risk Rating，CRR）。典型权重模型（信息性，非监管规定）：

加权后映射到 R1（低）至 R4（高），R3/R4 进入 EDD：要求资金来源证明（Source of Funds）、财富来源证明（Source of Wealth）、高管审批。EDD 必须由独立于业务线的合规审批，形成”二线”。

2.3 持续监测与定期复核

• 持续监测（Ongoing Monitoring）：对账户交易做实时/日终扫描，与 CRR、客户画像对比。
• 触发式复核（Event-Driven Review）：关键字段变更（地址、职业、实际控制人）、命中制裁或不利媒体（Adverse Media）、大额异常交易、跨境突增。
• 定期复核（Periodic Review）：R1 每 3 年、R2 每 2 年、R3 每年、R4 每半年（或按本地监管）。复核内容：证件有效性、PEP 状态、最近 12 个月交易画像、风险评级是否调整。

三、身份验证工程：eKYC 栈

远程开户（eKYC）是近年快速演化的领域。一条典型 eKYC 链路：

sequenceDiagram
  participant U as 用户
  participant APP as 移动端
  participant KYC as KYC 服务
  participant OCR as OCR/NFC
  participant FR as 人脸/活体
  participant VC as 公安/运营商/银行联核
  participant S as 制裁/PEP
  U->>APP: 开户
  APP->>OCR: 身份证正反面
  OCR-->>APP: 结构化字段
  APP->>OCR: NFC 读取 eMRTD (护照/港澳台居住证)
  OCR-->>APP: DG1/DG2 + BAC/PACE 验签
  APP->>FR: 活体自拍 (动作/静默)
  FR-->>APP: liveness_score
  APP->>KYC: 提交 (字段 + 照片 + video_hash)
  KYC->>VC: 二/三/四要素核验
  VC-->>KYC: 比对结果
  KYC->>FR: 证件照 vs 自拍 (face_match)
  FR-->>KYC: similarity
  KYC->>S: 姓名 + 证件号 + 国籍
  S-->>KYC: 名单命中结果
  KYC-->>APP: 通过/转人工

3.1 OCR 与 NFC

中国二代身份证可通过 NFC 读取芯片信息，但 芯片解密必须由持牌公安数据接入方（例如经”互联网+可信身份认证平台”CTID）完成，普通开发者不能自行解芯片。常见方案：现场拍照 OCR + 后端调用”身份证二要素/三要素”核验 API 确认真伪；或接入 CTID 获得不落地号码的网证。

国际证件（护照、港澳台居住证）遵循 ICAO 9303 eMRTD 规范，芯片包含 DG1（MRZ）、DG2（人脸）、DG3（指纹，一般银行无权限）、SOD（签名）。工程上用 iOS Core NFC / Android NfcA 读取，BAC/PACE 派生会话密钥后读取数据组，并用签发国 CSCA 根证书验证 SOD 链。

3.2 活体检测与人脸比对

活体（Liveness）分两类：

• 动作活体：引导用户转头、眨眼、张嘴，检测动作序列；对抗 3D 打印面具、屏幕翻拍。
• 静默活体：深度学习模型对单张图片或短视频分类；对抗深伪（Deepfake）需要多帧时序模型 + 纹理/频域特征。

人脸比对给出 similarity ∈ [0, 1]，阈值与业务风险挂钩：开户 0.82、登录 0.75、刷脸支付 0.92（示例阈值，实际以算法供应商校准为准）。每次比对必须留存 原图 + 比对图 + 分数 + 模型版本，否则监管审计无法复现。

3.3 二/三/四要素

中国常见的身份联核：

• 二要素：姓名 + 身份证号 → 公安公民身份信息核查（CTID / NCIIC）。
• 三要素：姓名 + 身份证号 + 手机号 → 运营商联核（三大运营商）。
• 四要素：姓名 + 身份证号 + 手机号 + 银行卡号 → 银联或银行柜面代理核验。

“四要素”常被用作支付绑卡的最低标准。核验接口响应通常返回 “一致/不一致/无此记录”，不返回明文，避免”用他人身份证号+随机手机号反查”。

3.4 电子签名、eID、网证

电子签名须符合《电子签名法》与 ETSI EN 319 411（欧盟）、eIDAS 规则。金融开户合同需要可靠电子签名（可靠签名需要具备签名人专有控制、可检测签名后变动），常见方案是接入合规 CA 的远程签章服务（如中国金融认证中心 CFCA），签名数据写入 PDF LTV（Long-Term Validation）结构，证书吊销列表（CRL）或 OCSP 证据一并存档。

3.5 eKYC 风控反制：深伪（Deepfake）对抗

2024 年以来，香港、日本、新加坡多起”AI 换脸视频会议诈骗”案件让远程开户面临新威胁。工程上的常见对抗：

• 被动活体 + 主动活体组合：静默活体识别合成痕迹（GAN 特征、频域异常），再叠加随机动作指令。
• 挑战响应：服务端随机生成数字串/颜色指令，用户按指令语音+动作响应，延迟和动作序列必须在合理区间。
• 光照响应：屏幕发出随机颜色闪烁，摄像头采集人脸反射光变化（Screen Flash Liveness），对预录像视频是强约束。
• 设备证据：读取设备 DRM 级别、摄像头硬件 ID、iOS DeviceCheck / Android Play Integrity 判断真机与否。
• 原始流采集：不允许客户端上传已处理后的视频，改为服务端生成挑战 → SDK 录制 → 分段上传原始帧，减少客户端篡改空间。

3.6 eKYC 流程的幂等与断点续传

移动网络极不稳定，一次开户常横跨 5–15 分钟，用户可能中断。系统必须幂等：

• 每份开户申请分配 application_id（UUID），客户端断网重连后以 application_id 继续上传缺失步骤。
• 各步骤状态机：DRAFT → ID_SUBMITTED → LIVENESS_DONE → VC_VERIFIED → SCREENING_PASS → APPROVED，非法跳转拒绝。
• 文件上传走分片 + 断点续传（S3 Multipart、阿里云 OSS PartUpload），服务端以 application_id + doc_type 做去重。
• 所有外部调用（公安联核、人脸比对、制裁筛查）带 idempotency_key，供应商返回结果缓存 24h。

四、制裁与 PEP 名单筛查

4.1 数据源

工程实现的第一步是把每家源做成标准化中间表：

CREATE TABLE sanction_entity (
  list_code       VARCHAR(16) NOT NULL,       -- OFAC_SDN / UN / EU / HMT / PBOC
  entity_uid      VARCHAR(64) NOT NULL,       -- 源系统内 ID
  entity_type     VARCHAR(16) NOT NULL,       -- INDIVIDUAL / ENTITY / VESSEL / AIRCRAFT / CRYPTO_WALLET
  primary_name    VARCHAR(400) NOT NULL,
  dob             DATE,
  nationality     CHAR(2),
  ids_json        JSON,                       -- 证件号码集合
  program         VARCHAR(64),                -- SDGT / UKRAINE-EO13662 / CYBER2 ...
  updated_at      TIMESTAMP NOT NULL,
  PRIMARY KEY (list_code, entity_uid)
);

CREATE TABLE sanction_alias (
  list_code       VARCHAR(16) NOT NULL,
  entity_uid      VARCHAR(64) NOT NULL,
  alias_name      VARCHAR(400) NOT NULL,
  alias_type      VARCHAR(16),                -- AKA / FKA / NKA
  script          VARCHAR(16),                -- LATIN / CYRILLIC / ARABIC / HAN
  PRIMARY KEY (list_code, entity_uid, alias_name)
);

4.2 模糊匹配算法

制裁筛查的核心是”不能漏”。同一个人在不同名单里可能写作 “Vladimir Putin”、“Владимир Путин”、“普京”、“V. V. Putin”。算法组合：

• 归一化：去除标点、重音折叠（NFKD + ASCII fold）、大小写、常见头衔（Mr、Dr、博士、先生）、转写（ICAO / Pinyin / BGN-PCGN 俄文转英文）。
• 分词 + 集合相似度：token_set_ratio、Jaccard。
• 字符串距离：Levenshtein、Jaro-Winkler（对前缀敏感，适合姓名）、Damerau-Levenshtein。
• 音似：Soundex / Metaphone（英文），Cologne phonetic（德文），双音译（阿拉伯/俄语），中文拼音 + Soundex 组合。
• 机器学习：学习匹配器（Learning to Match），用监管历史反馈与人工标签训练。

import unicodedata
import re
from pypinyin import lazy_pinyin
from rapidfuzz import fuzz
from jellyfish import jaro_winkler_similarity, metaphone

TITLES = {"mr", "mrs", "ms", "dr", "sir", "madam",
          "先生", "女士", "博士", "教授", "同志"}

def normalize(name: str) -> str:
    s = unicodedata.normalize("NFKD", name)
    s = "".join(ch for ch in s if not unicodedata.combining(ch))
    s = s.lower()
    s = re.sub(r"[^\w\u4e00-\u9fff ]+", " ", s)
    tokens = [t for t in s.split() if t not in TITLES]
    return " ".join(tokens).strip()

def to_latin_tokens(name: str) -> list[str]:
    n = normalize(name)
    tokens = []
    for tok in n.split():
        if re.search(r"[\u4e00-\u9fff]", tok):
            tokens.extend(lazy_pinyin(tok))
        else:
            tokens.append(tok)
    return tokens

def name_score(query: str, candidate: str) -> float:
    q = " ".join(to_latin_tokens(query))
    c = " ".join(to_latin_tokens(candidate))
    if not q or not c:
        return 0.0
    jw = jaro_winkler_similarity(q, c)
    tsr = fuzz.token_set_ratio(q, c) / 100
    pho_q = metaphone(q.replace(" ", ""))
    pho_c = metaphone(c.replace(" ", ""))
    pho = 1.0 if pho_q and pho_q == pho_c else 0.0
    return 0.45 * jw + 0.45 * tsr + 0.10 * pho

def screen(query_name: str, aliases: list[str], threshold=0.88):
    hits = []
    for a in aliases:
        s = name_score(query_name, a)
        if s >= threshold:
            hits.append((a, round(s, 3)))
    return sorted(hits, key=lambda x: -x[1])

# 示例
candidates = ["Vladimir Vladimirovich Putin", "V. V. Putin",
              "普京", "Владимир Путин"]
print(screen("vladimir putin", candidates, threshold=0.80))

4.3 二次确认与白名单

高命中率必然带来高误报。工业界典型做法：

1. 算法命中 → 合规人工复核：SLA 通常是 4 小时以内。
2. 白名单（Good-Guy List）：被确认为同名非本人的客户，写入白名单并记录复核人、证据、有效期（通常 1 年）。名单每日刷新时，如果源记录发生任何变化，白名单自动失效要求再审。
3. 50% 规则（OFAC）：被制裁实体直接或间接持有 ≥ 50% 的公司，自动也被视为受制裁，这部分必须通过 UBO 图谱展开筛查。

4.4 实时筛查 vs 事后扫描

不同业务场景对延迟与完整性的要求不同：

工程上把筛查能力沉淀为两套服务：同步 API（毫秒级，索引驻留内存，规则简化）与批量引擎（Spark 作业，全算法全阈值）。两者共用规则定义，但性能与召回率有意不同。同步 API 的漏报由批量引擎在 T+0/T+1 兜底，兜底命中即升级为案件，客户账户冻结。

4.5 SSN/ID 国别的坑

跨境合规系统里证件号校验常栽跟头：

• 美国 SSN 去除连字符为 9 位数字，禁用 000-xx-xxxx、666-xx-xxxx、9xx-xx-xxxx 等段。
• 中国大陆身份证 18 位，末位含校验码（GB 11643），需要做校验。
• 印度 Aadhaar 12 位，Verhoeff 校验，法律限制仅授权实体存储。
• 欧盟税号（TIN）格式因国而异，德国 11 位、法国 13 位，不可混。
• 护照号有长度限制（多数 ≤ 9 位）但含字母，不同签发国规则不同。

筛查引擎做精确匹配前必须按 (国家, 证件类型) 规范化，否则”中国身份证 vs 俄罗斯内护” 的字符串撞车会制造大量误报。

五、交易监测系统（TMS）

TMS 的目标不是阻断交易（那是反欺诈干的事），而是发现异常模式、支持 STR 上报。上游是账务与支付事件流，下游是案件管理。

flowchart LR
  subgraph 源
    P1[支付系统]
    P2[核心账务]
    P3[跨境汇款]
    P4[证券清算]
    P5[链上交易]
  end
  P1 & P2 & P3 & P4 & P5 --> KAFKA((事件总线))
  KAFKA --> N[标准化 + 丰富<br/>客户画像/对手方/图谱]
  N --> RULE[规则引擎<br/>Drools/自研]
  N --> ML[异常检测模型]
  RULE --> ALERT[预警池]
  ML --> ALERT
  ALERT --> CASE[案件管理]
  CASE --> STR[STR/SAR 上报]
  CASE --> FB[标注反馈]
  FB --> ML

5.1 大额交易与可疑交易

在中国场景（人民银行令〔2016〕第 3 号）常见阈值（简化，实际以最新规定为准）：

• 大额（Large-Value Transaction，LVT）：单日累计现金收支本币 ≥ 5 万 / 外币 ≥ 1 万美元；单笔或当日累计境内非现金收支本币 ≥ 200 万（法人）/ 50 万（自然人），跨境汇款自然人 ≥ 20 万人民币或 1 万美元等值等。大额为事后 T+5 日上报。
• 可疑：无固定阈值，由规则或模型触发，自发现之日起 5 个工作日提交（复杂案件 10 日）。

美国 FinCEN：CTR 单日现金 > 10,000 美元事后 15 天；SAR 发现后 30 天。

5.2 典型可疑场景

一段简化规则引擎的 Python 原型：

from dataclasses import dataclass
from datetime import datetime, timedelta
from collections import defaultdict, deque

@dataclass
class Txn:
    id: str
    customer_id: str
    amount_usd: float
    direction: str          # IN / OUT
    ts: datetime
    counterparty: str
    country: str
    channel: str            # CASH / WIRE / CARD / CRYPTO

class StructuringRule:
    """近 N 天内小于阈值的现金存款次数达标 → 报警"""
    def __init__(self, window_days=7, threshold_low=8_000,
                 threshold_high=9_999, count=5):
        self.window = timedelta(days=window_days)
        self.low, self.high, self.count = threshold_low, threshold_high, count
        self.buf: dict[str, deque[Txn]] = defaultdict(deque)

    def feed(self, t: Txn):
        if not (t.channel == "CASH" and t.direction == "IN"
                and self.low <= t.amount_usd <= self.high):
            return None
        q = self.buf[t.customer_id]
        q.append(t)
        while q and q[0].ts < t.ts - self.window:
            q.popleft()
        if len(q) >= self.count:
            return {"rule": "STRUCTURING",
                    "customer": t.customer_id,
                    "txn_ids": [x.id for x in q],
                    "score": min(1.0, len(q) / 10)}
        return None

class PassThroughRule:
    """大额入账 24h 内 >= 90% 出账"""
    def __init__(self, min_in=100_000, out_ratio=0.9,
                 window_hours=24):
        self.min_in, self.ratio = min_in, out_ratio
        self.window = timedelta(hours=window_hours)
        self.in_events: dict[str, list[Txn]] = defaultdict(list)
        self.out_sum: dict[str, float] = defaultdict(float)

    def feed(self, t: Txn):
        key = t.customer_id
        if t.direction == "IN" and t.amount_usd >= self.min_in:
            self.in_events[key].append(t)
        elif t.direction == "OUT":
            self.out_sum[key] += t.amount_usd
        # 清理过期入账并评估
        alerts = []
        kept = []
        for ev in self.in_events[key]:
            if t.ts - ev.ts > self.window:
                continue
            kept.append(ev)
        self.in_events[key] = kept
        for ev in kept:
            if self.out_sum[key] / ev.amount_usd >= self.ratio:
                alerts.append({"rule": "PASS_THROUGH",
                               "customer": key,
                               "in_txn": ev.id,
                               "out_sum": self.out_sum[key]})
        return alerts or None

真实 TMS 通常跑在 Flink/Spark Streaming 上，状态后端 RocksDB，规则热更新；异常检测走 Isolation Forest、HMM、GraphSAGE 等。模型与规则不相互替代：规则用于监管可解释场景（大额、特定国别），模型用于”未见过的模式”。

5.3 模型的可解释性

合规报告的 可疑原因 字段必须是自然语言，“模型分数 0.97”不够。工程上常用 SHAP 或规则回译（Rule Distillation）把模型输出翻译成”近 30 天与高风险地区交易占比升至 68%，显著高于同业中位数 5%“。

5.4 特征工程与模型

机器学习模型在 TMS 中的角色不是”替代规则”，而是覆盖规则看不见的长尾。特征大致分四层：

模型组合常见做法：

1. 无监督异常（Isolation Forest、AutoEncoder）先筛出 1% 的异常样本。
2. 监督模型（XGBoost、LightGBM）用历史 STR 真阳性做目标，输出可疑概率。
3. 图神经网络（GraphSAGE、GAT）刻画共享特征的团伙。
4. 规则回译（Rule Distillation）将重要特征贡献翻译为自然语言理由。

离线训练与在线推理分离，特征存储使用 Feast / HBase / Redis，确保离线/在线一致性。模型上线前必须通过合规模型风险管理（Model Risk Management，MRM）评审：数据血缘、偏差测试、对保护群体的公平性（Disparate Impact）、降级方案。

5.5 阈值治理

任何阈值都是可审计对象。建立阈值注册表：

CREATE TABLE rule_config (
  rule_code      VARCHAR(64) PRIMARY KEY,
  version        INT NOT NULL,
  params_json    JSON NOT NULL,
  effective_from TIMESTAMP NOT NULL,
  effective_to   TIMESTAMP,
  approved_by    VARCHAR(64) NOT NULL,
  change_reason  TEXT NOT NULL,
  jira_ref       VARCHAR(32)
);

每次阈值调整必须有合规官签字与工单号，生产系统只读取”当前生效”版本。审计时回放：用历史版本对历史数据重放，证明过去的决策基于当时有效的规则。

六、案件管理

stateDiagram-v2
  [*] --> New: 规则/模型命中
  New --> Triage: 分派
  Triage --> Investigating: 一线分析
  Investigating --> EscalatedL2: 升级二线
  Investigating --> ClosedFalse: 排除误报
  EscalatedL2 --> Filing: 决定上报
  EscalatedL2 --> ClosedFalse: 排除
  Filing --> Filed: 已提交 FIU
  Filed --> [*]
  ClosedFalse --> [*]

案件数据模型示例：

CREATE TABLE case_ (
  case_id         BIGINT PRIMARY KEY,
  customer_id     BIGINT NOT NULL,
  opened_at       TIMESTAMP NOT NULL,
  trigger         VARCHAR(64) NOT NULL,      -- RULE:STRUCTURING / MODEL:IF-0.91 / LIST:OFAC_SDN
  status          VARCHAR(16) NOT NULL,
  assignee        VARCHAR(64),
  severity        CHAR(2),                   -- S1..S4
  sla_due_at      TIMESTAMP NOT NULL,
  narrative       TEXT,                      -- 最终叙事
  decision        VARCHAR(16),               -- FILE / NO_FILE / SAR / CTR
  filed_at        TIMESTAMP
);

CREATE TABLE case_evidence (
  case_id    BIGINT,
  kind       VARCHAR(32),   -- TXN / KYC_DOC / NETWORK_GRAPH / CHAIN_TRACE
  ref        VARCHAR(256),
  added_by   VARCHAR(64),
  added_at   TIMESTAMP,
  PRIMARY KEY (case_id, kind, ref)
);

CREATE TABLE str_report (
  report_id     BIGINT PRIMARY KEY,
  case_id       BIGINT NOT NULL,
  authority     VARCHAR(32) NOT NULL,        -- FINCEN / CAMLMAC / FIU_NL ...
  format        VARCHAR(16) NOT NULL,        -- GOAML / FINCEN_SAR_XML / PBOC_CSV
  payload_uri   VARCHAR(512) NOT NULL,
  submitted_at  TIMESTAMP NOT NULL,
  ack_id        VARCHAR(128)
);

上报格式：

• FinCEN SAR：通过 BSA E-Filing 系统提交 XML。
• 中国人民银行大额/可疑报告：通过”中国反洗钱监测分析中心”直报系统按照格式规范生成报表，敏感数据走专线。
• UN goAML：许多国家 FIU 采用 goAML，XML schema 以《FATF SAR Template》为基础。

工程上必须保证幂等上报：提交失败重试时不重复，靠 report_id 唯一约束与回执 ack_id 追踪。

6.3 STR 报文样例与字段口径

不同 FIU 的报文格式各异。以 UN goAML 为例（许多司法辖区采用），一个简化的 <report> 片段：

<report>
  <rentity_id>BANK_ABC_0001</rentity_id>
  <submission_code>STR</submission_code>
  <report_code>STR</report_code>
  <submission_date>2026-04-15T09:12:44+08:00</submission_date>
  <currency_code_local>CNY</currency_code_local>
  <reason>疑似分拆现金存款，短期快进快出，疑涉非法集资</reason>
  <action>账户限制交易</action>
  <transaction>
    <transactionnumber>T-2026041500931</transactionnumber>
    <date_transaction>2026-04-12T10:22:00+08:00</date_transaction>
    <transmode_code>CASH_DEPOSIT</transmode_code>
    <amount_local>98500.00</amount_local>
    <t_from>
      <from_account>
        <institution_code>BANK_ABC</institution_code>
        <branch>SH001</branch>
        <account>6222****1234</account>
        <signatory>
          <t_person>
            <first_name>San</first_name>
            <last_name>Zhang</last_name>
            <birthdate>1985-07-02</birthdate>
            <ssn>3101XXXXXXXXXXXXXX</ssn>
            <nationality1>CN</nationality1>
          </t_person>
        </signatory>
      </from_account>
    </t_from>
    <t_to>
      <to_account>
        <institution_code>BANK_ABC</institution_code>
        <account>6222****9988</account>
      </to_account>
    </t_to>
  </transaction>
</report>

几个常见字段口径问题：

• 本币金额：跨币种交易必须折算到本币，使用交易当日中间价；不同系统时间戳口径（UTC/本地）必须统一，否则对账时出现”金额差一个日汇率”的噩梦。
• 对手方缺失：ATM 现金存款无”来源对手方”，goAML 允许 <from_funds_source>CASH</from_funds_source> 代替，绝不可伪造。
• 多客户同一报告：关联账户（例如家族团伙）可以 <involved_parties> 群体上报，节省调查员反复提交。
• 叙事（Narrative）必须在系统外不可编辑地与报告绑定，常用 PDF/A-3 + 数字签名。

6.4 案件调查的数据编排

合规分析师的日常是”从告警出发，在数小时内还原资金图景”。一个高效的调查工作台应一键展开：

flowchart TB
  ALERT[告警事件] --> VW1[客户 360 视图]
  ALERT --> VW2[交易瀑布图]
  ALERT --> VW3[关系网络图]
  ALERT --> VW4[链上资金追踪]
  VW1 --> D1[KYC 档案/EDD 附件]
  VW1 --> D2[历史案件]
  VW2 --> D3[30/90/365 日对比]
  VW3 --> D4[2-hop 图谱/共享设备/共享 IP/UBO]
  VW4 --> D5[链上分析平台调用]
  VW1 & VW2 & VW3 & VW4 --> NAR[叙事生成草稿]
  NAR --> REVIEW[二线合规复核]

工具链的关键：

• 交易瀑布（Transaction Waterfall）：按日聚合，分出入方向，展示余额变化与阈值线。
• Sankey 图：资金在对手方间流向，快速识别”过桥账户”。
• 时间线：把 KYC 变更、登录、设备切换、交易合一条时间轴。
• 链上追踪：输入存款地址自动调用 Chainalysis Reactor / TRM Forensics，拉取风险标签与归属实体，图形化展示混币路径。
• LLM 辅助叙事：读取结构化证据生成初稿，由分析师审稿提交，不得让 LLM 直接调用上报接口。

七、加密货币 AML

7.1 链上分析

链上地址天然伪匿名。商业链上分析平台（Chainalysis、TRM Labs、Elliptic、MistTrack、Arkham）做两件事：

1. 实体归属：把地址聚类成实体（交易所、矿池、混币器、勒索团伙）。核心启发式：Common-Input Ownership（一次交易的多个输入同属一个实体）、找零检测、行为指纹。
2. 风险评分：给地址打分，并追踪资金流向——例如一笔比特币经过 Tornado Cash 混币后进入某交易所存款地址，交易所 KYT（Know-Your-Transaction）系统会自动升级该笔入金的风险。

7.2 Tornado Cash 制裁案

2022 年 8 月，OFAC 把 Tornado Cash 及其智能合约地址列入 SDN 名单，这是 OFAC 第一次把智能合约地址本身列入制裁名单，引发激烈争议。2023 年 8 月美国司法部起诉其开发者。2024 年 11 月，美国第五巡回上诉法院在 Van Loon v. Department of the Treasury 案中裁定 OFAC 对 Tornado Cash 不可变智能合约的制裁超越授权（因其不属于 IEEPA 下的”财产”），相关地址随后被移除。但开发者刑事案件独立进行——代码即言论的讨论进入了金融合规领域。对工程师的启示：合约地址级制裁技术上可以被执行（交易所拒绝相关地址），但法律上仍在演化，筛查规则的”白/黑”有时需要日级刷新。

7.3 旅行规则与 IVMS101

FATF R.16 在 2019 年的 Interpretive Note 明确要求 VASP 间传递发起人与受益人信息。国际证券化数据模型 IVMS101（InterVASP Messaging Standard 101）提供统一字段：

{
  "originator": {
    "originatorPersons": [{
      "naturalPerson": {
        "name": {"nameIdentifier": [{
          "primaryIdentifier": "Zhang",
          "secondaryIdentifier": "San",
          "nameIdentifierType": "LEGL"
        }]},
        "geographicAddress": [{
          "addressType": "HOME",
          "country": "CN",
          "townName": "Shanghai",
          "streetName": "Nanjing Road",
          "buildingNumber": "100"
        }],
        "nationalIdentification": {
          "nationalIdentifier": "3101...X",
          "nationalIdentifierType": "CCPT",
          "countryOfIssue": "CN"
        }
      }
    }],
    "accountNumber": ["0xabc...def"]
  },
  "beneficiary": { "...": "..." }
}

7.4 Travel Rule 协议族

行业没有统一协议，多家互操作：

一个合规工程要点：VASP 间对手方发现（Counterparty Discovery，CD）是先决问题——“你知道这个收款地址属于哪家 VASP 吗？”常见做法组合：地址归属库查询（链上分析平台）+ 用户自报 + 交易所联合白名单。发现失败时按 FATF 指南，对于自托管（Self-Hosted）钱包应取得附加信息（发起人声明、地址所有权证明）。

7.5 T+0 穿透式监管（中国）

中国对金融基础设施要求”穿透式监管”——支付机构、交易所、清算机构需要按日甚至实时向监管直报底层明细。人民银行”反洗钱现场非现场监管一体化平台”、证监会”全市场交易监测系统”、外汇局”跨境资金流动监测分析系统”都是这一思路。工程影响：机构要具备按明细维度（客户、账户、商户、对手方）生成 T+0 直报包的能力，数据口径一致性比速度更关键。

直报接入的工程清单：

• 数据血缘：每个报送字段能追溯到核心系统哪张表哪个字段、清洗逻辑版本。
• 口径对齐：同一”客户” 在开户系统、支付系统、账务系统可能有不同主键，统一 CIF（Customer Information File）主数据。
• 断点重传：监管接口不稳定时按日重传，幂等键为 (报送类型, 业务日期, 机构代码, 序列号)。
• 差错回补：发现前日报文错误时提交”冲正+重报”，不得直接覆盖。
• 反向校验：监管回执与本地报送总数/总金额比对，出现差异立即告警。

7.8 UBO 图谱与 50% 规则

OFAC 的 “50% 规则” 是最容易被低估的工程难点：被制裁方直接或间接合计持有 ≥ 50% 的任何实体自动受制裁，即使该实体本身不在 SDN 列表上。合规筛查必须下钻到股权穿透。

一个最小图模型：

CREATE TABLE entity (
  entity_id    BIGINT PRIMARY KEY,
  name         VARCHAR(400) NOT NULL,
  name_en      VARCHAR(400),
  country      CHAR(2),
  type         VARCHAR(16) NOT NULL          -- NP / LP / TRUST
);

CREATE TABLE ownership (
  parent_id    BIGINT NOT NULL,              -- 持股方
  child_id     BIGINT NOT NULL,              -- 被持股方
  pct          DECIMAL(6,3) NOT NULL,
  as_of        DATE NOT NULL,
  source       VARCHAR(64) NOT NULL,         -- 工商/OpenCorporates/客户申报
  PRIMARY KEY (parent_id, child_id, as_of)
);

50% 规则的实现是一个带权图可达性算法。给定制裁种子 S，对每个其他节点 n 计算 S 对 n 的合并持股：沿多条路径求和，但环与相互持股必须处理。

def aggregated_ownership(edges, seeds, target, depth=8):
    """
    edges: list[(parent, child, pct)]  pct in [0,1]
    seeds: set[节点ID]  被视为"受制裁"的起点
    返回 seeds 对 target 的聚合持股比例 (0..1)。
    用 DFS + memo，允许多路径相加，避免简单回环。
    """
    adj = {}
    for p, c, v in edges:
        adj.setdefault(p, []).append((c, v))

    memo = {}
    def dfs(node, visited):
        if node == target:
            return 1.0
        if depth_exceeded := len(visited) > depth:
            return 0.0
        key = (node, frozenset(visited))
        if key in memo:
            return memo[key]
        total = 0.0
        for child, pct in adj.get(node, []):
            if child in visited:
                continue
            total += pct * dfs(child, visited | {child})
        memo[key] = total
        return total

    return sum(dfs(s, {s}) for s in seeds)

edges = [(1, 2, 0.60), (1, 3, 0.30), (2, 4, 0.80),
         (3, 4, 0.40), (4, 5, 0.70)]
print(aggregated_ownership(edges, seeds={1}, target=5))
# 1→2→4→5: 0.6*0.8*0.7=0.336
# 1→3→4→5: 0.3*0.4*0.7=0.084
# 合计对 4 的持股 = 0.48+0.12=0.60 ≥ 50%，4 自动被制裁
# 但若按"先对 4 聚合再向下"的口径，5 持股仅 0.60*0.70=0.42 < 50%

实际合规实现会分层判定：先判定实体 4 是否被穿透制裁（≥50%），是则把 4 加入种子集，再向 5 穿透；而不是简单把所有路径乘法加到终端。这与 OFAC 官方 FAQ 401/402 的”一旦某实体被穿透，即整体视为 blocked”相符。工程师容易写错的正是这一步。

7.9 不利媒体筛查（Adverse Media）

除名单与 PEP 外，不利媒体（Adverse Media / Negative News）是 EDD 必查项。工程流程：

1. 多源新闻抓取（路透、彭博、新华、当地主流媒体），RSS + 商业数据源（Dow Jones Factiva、LexisNexis NewsDesk）。
2. 命名实体识别（NER）抽取人名/机构名，与客户库匹配。
3. 分类器识别涉及话题：Fraud、Corruption、Sanctions、Money Laundering、Terrorism、Tax Evasion、Organized Crime 等 FATF 上游罪 22 类。
4. 多语种处理：同名歧义 + 翻译偏差。
5. 人工复核，入客户档案。

陷阱：LLM 做 NER 容易”编造人物”；生产环境仍以 CRF/BERT-NER 结合规则为主，LLM 只做摘要与话题归类，保留原文引用。

7.10 持续客户尽调的信号源

持续监测不仅看交易，还看”客户画像 drift”：

这些信号统一进入”客户信号总线”，任何一条都能触发 review_due_at = today。

7.6 链上 → 链下的风险穿透

一笔链上资金最终要经交易所上岸才能产生”洗白”效果。VASP 的 KYT（Know-Your-Transaction）默认要做：

1. 入金地址扫描：对每笔充值调用链上分析 API，返回标签（交易所、混币器、制裁地址、勒索、诈骗、Darknet Market）。
2. 资金溯源深度：追溯前 N 跳，若 N 跳内出现高危标签按规则冻结或要求说明。N 通常 3–5 跳。
3. 出金地址审核：对用户自填的外部地址同样扫描，拒绝制裁地址。
4. 实时 Mempool 拦截（进阶）：在用户下单提款但 TX 尚未广播前，将地址与最新黑名单比对。
5. 链上与链下对齐：把 KYC 身份与充/提地址以”账户-地址”表绑定，并周期性判断同一地址是否被多客户复用（互斥/团伙）。

7.7 VASP 间互操作的实操问题

Travel Rule 协议百花齐放，实际运营中头疼点：

• 对手方未启用 Travel Rule：FATF “Sunrise Issue”——自身辖区已要求、对手方辖区未要求。应急策略：小额放行留痕、大额退回或要求客户自报。
• 收款地址归属错误：链上分析标签偶有滞后或错误，可能将某 VASP 的冷钱包误判为混币器。必须建立申诉与复核通道。
• 自托管钱包（Self-Hosted）：按 FATF 指南需采集地址所有权证明（Satoshi Test：用客户自证私钥在链上签一段消息），或由 VASP 自行做”合理保证”。
• 用户体验：Travel Rule 问询把原本 30 秒的提现变成数分钟到数小时的审核，产品与合规要权衡。

7.11 旅行规则数据模型

为保证多协议互通，内部抽象出独立于协议的领域模型：

CREATE TABLE tr_message (
  tr_id          CHAR(36) PRIMARY KEY,        -- 内部 UUID
  direction      VARCHAR(8) NOT NULL,         -- OUT / IN
  originator_vasp VARCHAR(64),
  beneficiary_vasp VARCHAR(64),
  asset          VARCHAR(32) NOT NULL,        -- BTC / ETH / USDT-ERC20
  amount         DECIMAL(38,18) NOT NULL,
  tx_hash        VARCHAR(128),
  protocol       VARCHAR(16) NOT NULL,        -- TRP / TRISA / SYGNA / NOTABENE
  payload_enc    VARBINARY(8000) NOT NULL,    -- IVMS101 加密
  status         VARCHAR(16) NOT NULL,        -- PENDING / ACK / REJECTED / EXPIRED
  created_at     TIMESTAMP NOT NULL,
  acked_at       TIMESTAMP
);

设计上要点：payload 以 IVMS101 结构加密存储，对端公钥来自对手方 VASP Directory；所有协议适配器解码后落同一张表，便于稽查与跨协议迁移。

八、数据隐私与 AML 的张力

AML 要求”知道你的客户并留存 5–10 年”，隐私法要求”最小必要、到期删除”。典型冲突与工程处置：

中国《个人信息保护法》第 13 条赋予”履行法定义务”作为合法性基础；欧盟 GDPR Art.6(1)(c)/(e) 同理。关键是把法律依据写进数据生命周期策略，而不是拍脑袋。

8.1 隐私增强技术在 AML 的落地

近年一批隐私增强技术（Privacy Enhancing Technologies，PET）开始在 AML 领域探索：

• 安全多方计算（MPC）：银行间共享”同一客户是否在我行也触发过告警”而不暴露客户明细。英国 FCA 沙盒与新加坡 MAS Project COSMIC 是相关尝试。
• 同态加密（HE）：对加密后的交易特征做聚合统计，监管机构可在不看明文前提下检查异常。
• 零知识证明（ZKP）：用户向 VASP 证明”我不是被制裁对象”而不披露身份明细。ZK-KYC 在 DeFi 合规中被讨论。
• 可信执行环境（TEE）：名单筛查在 Intel SGX / AMD SEV 内执行，供应商不能拿到客户姓名。

这些技术尚未普及，但在跨机构情报共享（例如 Project COSMIC 允许新加坡七家银行在高置信度阈值下共享可疑客户）中已有生产级试点。工程师应关注，但不应在主链路上引入未经监管认可的密码学方案。

8.2 数据本地化

多个司法辖区要求金融数据本地化：中国、俄罗斯、印度、印尼、越南、沙特。对跨国集团来说 AML 数据（尤其原始交易与 KYC 文档）必须留在本地；跨境共享需去标识化或走监管备案通道。工程上的落地：每个辖区一套独立数据底座，合规分析在本地完成，仅派生指标（红绿灯级别）回到集团总部。

九、工程坑点

1. 名单刷新的”半小时盲区”：OFAC 更新在美国东部时间下午，亚洲机构次日早上才刷新，窗口内可能放行被新制裁实体。方案：订阅 OFAC RSS、接入商业 feed（Dow Jones/Refinitiv）实现准实时刷新；关键产品（跨境汇款）采用”交易时二次筛查”而不是”开户时一次筛查”。
2. 字符编码陷阱：SDN 名单 XML 含有俄文、阿拉伯文、希伯来文、中日韩字形，没有统一归一化会漏命中。务必跑 NFKD → ASCII fold → 再做转写。
3. UBO 深度限制：一些合规团队只查 2 层股权，实际离岸结构常达 5 层以上。设置层数与持股比例（≥ 25%）的组合截止条件，并保留”发现新层”的再查机制。
4. 去重与上报二义性：同一笔交易可能同时符合大额与可疑，必须决定”一份报告”还是”两份报告”。按当地监管口径在策略表里配置。
5. 历史数据回放：新规则上线要评估误报率，必须支持在离线数据湖上回放近 90 天交易。因此 TMS 的规则描述最好是数据+时间的纯函数，不带副作用。
6. 生物样本跨模型兼容：更换人脸模型后旧嵌入不可比对。策略是双跑过渡期 + 新注册用新模型 + 旧用户按需重采。
7. STR 上报的”tipping-off”风险：上报后不得告知客户（tipping-off 属刑事风险），工单系统的通知模板、催办邮件必须排除被上报客户。
8. PEP 库误报率极高：共名情况严重（例：某国部长与众多同名普通公民），阈值一味拉高会漏；一味拉低会淹没合规人员。建议按国家/职位拆分阈值，并引入”生日差 ≤ 3 年 + 国籍相同”等上下文条件。
9. 链上地址的可组合性：用户自托管多链钱包，同一实体多地址。Travel Rule 只覆盖 VASP 间，VASP-to-Self-Hosted 需要附加”地址归属证明”流程（Satoshi Test、签名验证）。
10. 留存与审计对象存储成本：10 年交易 + KYC 档案 + 人脸视频 PB 级，必须分层（热/温/冷/归档）并有密钥轮转；合规稽查时从 Glacier 调回需要预案。

十、选型与落地清单

供应商层：

• 身份：Jumio、Onfido、Socure、旷视 / 商汤、腾讯云慧眼、阿里云实人认证。
• 名单与 PEP：Dow Jones Risk & Compliance、Refinitiv World-Check、LexisNexis Bridger、ComplyAdvantage。
• TMS：NICE Actimize、Oracle Financial Services AML、SAS AML、FICO TONBELLER、国内同盾 / 顶象 / 邦盛。
• 链上：Chainalysis、TRM Labs、Elliptic、MistTrack、Merkle Science。
• Travel Rule：Notabene、Sumsub Travel Rule、21 Analytics、Veriscope、TRISA 网络。

自建 vs 外采：

• 持牌银行 / 大型支付：核心规则与 TMS 自建，名单与链上外采，形成”数据联邦”。
• 中小机构 / 加密交易所：整体外采 SaaS + 本地合规决策；关键在于留痕接口、数据隔离、合规角色权限。

上线清单（Go-Live Checklist）：

1. 合规矩阵完成，产品 × 管辖 × 客户类型 × 风险级 全覆盖。
2. KYC 数据模型与档案留存策略通过法务与 DPO 评审。
3. 制裁名单源每日自动拉取 + 校验 + 回退机制。
4. 模糊匹配阈值经回溯测试（F1、误报率、漏报率）。
5. TMS 规则在生产镜像上回放近 90 天通过率。
6. 案件管理 SLA 与岗位权限（一线/二线/三线）定义并纳入监控。
7. STR / CTR 报文生成工具支持至少两个司法辖区，E2E 拨测通过。
8. 审计日志与 WORM 存储接通，密钥分管与到期策略。
9. 事故演练：误报大面积来袭 / 名单源故障 / FIU 对接中断 / 监管现场检查。
10. 员工培训（尤其一线客服避免 tipping-off）。

十一、公开案例

• 汇丰银行（HSBC）2012 年：因未能阻止墨西哥锡那罗亚贩毒集团通过其美国子公司进行约 8.81 亿美元的资金清洗等问题，与美国司法部达成 19.2 亿美元 DPA（Deferred Prosecution Agreement），成为当时纪录罚款之一。
• 丹斯克银行（Danske Bank）爱沙尼亚分行案 2018 年：2007–2015 年间非居民账户流经约 2000 亿欧元疑似可疑资金，2022 年丹斯克银行与美国司法部达成约 20 亿美元和解，管理层面临欧洲多国刑事追诉。
• FinCEN Files 2020：国际调查记者同盟（ICIJ）披露 2,100 余份 FinCEN 收到的 SAR 涉及 2 万亿美元可疑资金，揭示银行上报之后资金流转仍在继续的结构性问题。
• Binance 2023 年：与美国司法部、财政部（FinCEN、OFAC）、CFTC 达成总计约 43 亿美元和解，CEO 辞职；OFAC 指控其违反 Syria、Iran 等制裁计划。
• 火币 / OKX 等国内交易所 2021 年清退：响应人民银行等十部委《关于进一步防范和处置虚拟货币交易炒作风险的通知》清退中国大陆用户，此后行业合规化进入牌照化阶段。
• 中国 2023–2025 年地下钱庄专案：公安部、人民银行多次联合侦办，涉及数百亿元跨境非法结算，手法以”对敲”“过桥”为主，为 TMS 的”对敲”规则提供真实模式样本。
• Tornado Cash 2022–2024：OFAC 制裁 → 第五巡回上诉法院部分推翻 → 开发者刑事案件继续，合约级制裁的合规与宪法讨论持续。

十二、与本系列其他文章的关系

• 账户与金额建模：《钱的建模》、《账务数据库设计》 决定了 TMS 可以从何处取数。
• 幂等与事务：《幂等、事务与一致性》 保障上报不重复。
• 支付链路：《支付网关》、《跨境支付工程》 是可疑资金出入境的主战场。
• 数字货币：《数字人民币与稳定币》 的双层运营模式决定 AML 责任分配。
• 风控与反欺诈：《实时风控引擎》、《反欺诈》 与本篇共用特征平台与案件管理底座。
• 后续：《信用风险》 解决”会不会还”问题，与本篇”会不会洗”互补。

十三、参考资料

• FATF, “The FATF Recommendations (2012, 2023 updated)”. https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Fatf-recommendations.html
• FATF, “Updated Guidance for a Risk-Based Approach to Virtual Assets and VASPs (2021)”. https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Updated-guidance-rba-virtual-assets.html
• U.S. Department of the Treasury, OFAC SDN List. https://ofac.treasury.gov/specially-designated-nationals-and-blocked-persons-list-sdn-human-readable-lists
• FinCEN, BSA E-Filing System & SAR Instructions. https://www.fincen.gov/resources/filing-information
• European Union, Regulation (EU) 2023/1113 on information accompanying transfers of funds and certain crypto-assets. https://eur-lex.europa.eu/eli/reg/2023/1113/oj
• European Union, Markets in Crypto-Assets Regulation (MiCA), Regulation (EU) 2023/1114. https://eur-lex.europa.eu/eli/reg/2023/1114/oj
• 中国人民银行，《金融机构大额交易和可疑交易报告管理办法》（人民银行令〔2016〕第 3 号）。 http://www.pbc.gov.cn/
• 全国人民代表大会常务委员会，《中华人民共和国反洗钱法》（2024 修订，2025 年 1 月 1 日起施行）。 http://www.npc.gov.cn/
• 中国人民银行令〔2025〕第 3 号《金融机构反洗钱和反恐怖融资监督管理办法》。 http://www.pbc.gov.cn/
• 国务院，《非银行支付机构监督管理条例》（国务院令第 768 号）。 https://www.gov.cn/
• HKMA, “Guideline on Anti-Money Laundering and Counter-Financing of Terrorism (For Authorized Institutions)”. https://www.hkma.gov.hk/
• MAS, Notice PSN01 & PSN02, Payment Services Act AML/CFT. https://www.mas.gov.sg/
• InterVASP, “IVMS 101 data model”. https://www.intervasp.org/
• Chainalysis, “The Crypto Crime Report (annual)”. https://www.chainalysis.com/
• TRM Labs, “TRM Talks / Illicit Crypto Report”. https://www.trmlabs.com/
• Van Loon v. Department of the Treasury, No. 23-50669 (5th Cir. 2024)（Tornado Cash 案第五巡回意见书）。

十四、小结

AML 工程与反欺诈最大的差异是可解释性与可稽查性优先于准确率：一套”召回高但无法向监管解释”的模型在 AML 场景是不可部署的。把监管要求翻译为”标准化合规矩阵 + 可回放的规则 + 可审计的模型”，把客户信息、交易流水、链上证据、名单命中、案件叙事沉淀为”一键重现十年前”的档案结构，这些都是反洗钱系统长期演进的主线。名单刷新更快、模糊匹配更准、链上穿透更深、跨境协作更紧密——每一项都直接牵动成本、用户体验与合规风险的平衡。

对中国市场的从业者，2025 年修订的《反洗钱法》与人民银行 3 号令将会把”受益所有人识别”“特定非金融机构接入”“分级分类管理”推得更深；对出海企业，MiCA、AMLR 与各辖区 Travel Rule 协议的互操作是未来两年的核心工程议题。把合规当工程问题做，而不是当文书工作做——这是本篇希望传递的底层态度。

上一篇：《反欺诈：设备指纹、关系图谱、行为序列、黑产对抗》

下一篇：《信用风险：评分卡、违约预测、巴塞尔 III》