FATF Travel Rule 与 AML/KYC

日期: 2026-05-23 方向: 机构DeFi / RWA 阶段: Phase 1 - 监管与合规框架 (Day 15-28) 标签: #监管 #合规 #FATF #AML #KYC #TravelRule #VASP

---

今日目标

---

一、FATF 框架基础

1.1 FATF 简介

• 1989 年 G7 设立的政府间组织（OECD 巴黎总部）
• 制定全球 AML/CFT 标准（软法，但成员国压力极大）
• 41 个成员国 + 9 个区域机构（如 APG、MONEYVAL）
• 输出：40 项 Recommendations + Mutual Evaluation 报告

1.2 40 Recommendations 结构

A. AML/CFT Policies and Coordination (R.1-2)
B. Money Laundering and Confiscation (R.3-4)
C. Terrorist Financing and Proliferation Financing (R.5-7)
D. Preventive Measures (R.9-23)  ← 商业实体核心
E. Transparency and Beneficial Ownership (R.24-25)
F. Powers and Responsibilities of Authorities (R.26-35)
G. International Cooperation (R.36-40)

1.3 关键 Recommendations

---

二、VASP 定义（FATF Recommendation 15）

2.1 VASP 定义（2019-06 修订）

Virtual Asset Service Provider = 任何作为业务为他人或代他人开展以下活动的人或法律实体：

1. 虚拟资产之间兑换
2. 虚拟资产与法币兑换
3. 虚拟资产转账
4. 保管 / 管理虚拟资产或工具
5. 参与发行 / 销售（如承销）

2.2 不属于 VASP

• 个人 P2P（不为业务）
• 纯软件开发者（如开源协议代码）
• 矿工 / 验证者（仅打包交易）
• 完全去中心化的协议（FATF Updated Guidance 2021，但定义模糊）

2.3 DeFi 是否 VASP？

FATF 2021 年指引（Updated Guidance for a Risk-Based Approach to Virtual Assets and VASPs）明确：

• "Creator, owner, and operator" of DeFi 应作为 VASP
• 即使协议"形式上"去中心化，控制力（control / sufficient influence）的实体仍可能是 VASP
• 例：DAO 治理代币持有人（如 Uniswap UNI 持有者）—— 模糊地带

---

三、Travel Rule（Recommendation 16）

3.1 传统电汇 Travel Rule

源自 1996 年 BSA Travel Rule（31 CFR 1010.410(f)）：

• 电汇 ≥ $3,000 时，发起银行必须传送以下信息至接收银行：
  • 发起人姓名、账号、地址（或国民 ID）
  • 接收人姓名、账号
  • 金额、货币、日期

3.2 加密领域适配（FATF 2019）

FATF 修订 R.16 适用于 VASP：

• 阈值：≥ $/€1,000（多国采用，但门槛各异）
• 数据：发起方 + 接收方完整 KYC 信息
• 格式：标准化（推荐 IVMS101）
• 机制：必须在交易"发起前或同时"传送

3.3 各辖区 Travel Rule 阈值

3.4 EU TFR（Transfer of Funds Regulation, 2023/1113）

• 与 MiCA 同包通过（2023-05-31）
• 生效日 2024-12-30
• 零阈值：所有加密转账都需 Travel Rule 信息
• VASP-to-VASP：必须验证（verify）信息
• VASP-to-Self-Custody：仅"收集"信息（如自托管钱包归属确认）
• Self-Hosted 钱包：≥ €1,000 转账需 KYC 关联

---

四、IVMS101 数据标准

4.1 IVMS101 简介

• InterVASP Messaging Standard 101
• 由 InterVASP Joint Working Group 制定（2020）
• IS0 20022 兼容 JSON Schema
• 涵盖法人/自然人 VASP、原发地址（originator）、受益地址（beneficiary）

4.2 IVMS101 关键字段

{
  "originator": {
    "originatorPersons": [
      {
        "naturalPerson": {
          "name": {
            "nameIdentifier": [
              {"primaryIdentifier": "Smith", "secondaryIdentifier": "John", "nameIdentifierType": "LEGL"}
            ]
          },
          "geographicAddress": [...],
          "nationalIdentification": {
            "nationalIdentifier": "P123456",
            "nationalIdentifierType": "PASS",
            "countryOfIssue": "US"
          },
          "dateAndPlaceOfBirth": {...},
          "customerIdentification": "CUST-001"
        }
      }
    ],
    "accountNumber": ["0x742d35Cc..."]
  },
  "beneficiary": {...},
  "originatingVASP": {
    "legalPerson": {
      "name": {...},
      "geographicAddress": [...],
      "customerIdentification": "VASP-001",
      "lei": "529900T8BM49AURSDO55"
    }
  },
  "beneficiaryVASP": {...},
  "transferPath": [...],
  "payload": {
    "transactionAsset": {"assetType": "BTC", "amount": "0.5"}
  }
}

4.3 数据传输协议

IVMS101 是数据格式，不规定传输。主流协议：

• TRP（Travel Rule Protocol）：开源 REST API 标准，由 ING 等推动
• TRISA：基于 mTLS + gRPC，CipherTrace 推动
• OpenVASP：Whisper 协议（已基本退出）
• Sygna Bridge：BitMEX 推动，亚洲常见

4.4 主流 Travel Rule 服务商

---

五、典型链上 Travel Rule 流程

5.1 VASP-to-VASP（A 交易所发送至 B 交易所）

1. 用户在 VASP A 发起转账请求 → BTC 0.5 至地址 X
2. VASP A 检查地址 X 是否归属于已知 VASP B（通过 Notabene Directory）
3. VASP A 调用 VASP B Travel Rule API：
   POST /v1/transfers
   Body: IVMS101 JSON（含发起人 KYC、金额、地址）
4. VASP B 验证：
   - 接收人在 B 是否真实客户？
   - 接收人是否在制裁名单？
5. VASP B 返回 Accept / Reject
6. VASP A 收到 Accept → 链上发起 BTC 转账
7. 链上交易确认 → 双方记录 Travel Rule 数据 + Tx Hash 关联
8. 5 年保留期限内，监管可请求查询

5.2 VASP-to-Self-Custody（A 交易所发送至自托管钱包）

1. 用户提交目的地 0x7a2... → VASP A
2. VASP A 检查：地址未关联任何 VASP（self-hosted）
3. VASP A 询问用户：
   - 该地址归属（自有 / 第三方）？
   - 第三方 → 拒绝（部分辖区如新加坡）
   - 自有 → 要求"地址证明"（Address Proof）
4. 地址证明方法：
   a. Satoshi Test：从该地址签名一条挑战消息
   b. Micro Transaction：先发 0.0001 BTC，从中确认控制权
   c. Wallet API（如 MetaMask Snap）：直接签名验证
5. VASP A 完成 KYC 关联：用户 ↔ 地址
6. 链上发起转账，记录归属信息

5.3 Self-Custody-to-VASP（自托管钱包发送至 B 交易所）

1. 用户从 MetaMask 发送 BTC 0.5 至 VASP B 地址 Y
2. VASP B 链上检测到入金 → 等待确认
3. VASP B 检查发送地址 X：
   a. 是否来自已知 VASP？→ 启动 VASP-to-VASP 流程
   b. 是否来自客户预先声明的自有地址？→ 完成
   c. 都不是 → "未知发送方"
4. 未知发送方处理（视辖区）：
   - 严格：金额 ≥ €1,000 退回
   - 宽松：允许入金，要求客户事后说明
5. 风险评分：
   - 链上分析：来源是否经过 mixer / OFAC 地址？
   - 高风险 → 冻结账户，提交 STR

---

六、AML 合规栈完整架构

6.1 端到端 AML 栈

┌─────────────────────────────────────────────────────┐
│  Onboarding 层                                        │
│  ├─ KYC（身份验证）：Sumsub / Onfido / Jumio          │
│  ├─ KYB（企业验证）：Trulioo / Refinitiv              │
│  ├─ PEP/Sanction 筛查：Refinitiv / Dow Jones / Comply │
│  └─ Risk Scoring：自有 + LexisNexis                   │
├─────────────────────────────────────────────────────┤
│  Transaction Monitoring                                │
│  ├─ 链上分析：Chainalysis KYT / TRM Labs / Elliptic   │
│  ├─ Behavioral：Hummingbot / Quantexa                 │
│  ├─ Sanction Screening：Chainalysis Sanctions Oracle  │
│  └─ STR 生成：自有 case management                    │
├─────────────────────────────────────────────────────┤
│  Travel Rule                                           │
│  ├─ Notabene Directory + API                          │
│  ├─ IVMS101 数据交换                                   │
│  └─ Address Attribution                                │
├─────────────────────────────────────────────────────┤
│  Reporting & Records                                   │
│  ├─ FIU 报告（FinCEN、JFIU、AUSTRAC……）               │
│  ├─ 5 年记录保留                                       │
│  └─ Audit Trail                                        │
└─────────────────────────────────────────────────────┘

6.2 推荐合规栈（欧洲交易所案例）

---

七、TradFi 监管 → Web3 映射

7.1 SWIFT GPI vs 链上 Travel Rule

传统：SWIFT GPI（Global Payments Innovation）
  ├── 银行间发 MT103 报文（含 50K 字段：付款人、收款人、目的、用途）
  └── SWIFT 是私有网络，仅银行接入

链上：Travel Rule + IVMS101
  ├── VASP 间传 IVMS101 JSON（同等数据）
  └── 公链 + 私有 API 通道（Notabene Directory）

7.2 关键差异

7.3 链上挑战与创新

• 隐私：IVMS101 数据不能上链（GDPR），但需链下保存
• 互操作：不同协议（TRP/TRISA/Sygna）需要桥接 → Notabene 等扮演路由角色
• DeFi 接入：纯 DeFi 难以集成 Travel Rule → 解决方案 = "合规层"DApp（如 Aave Arc、Maple）

7.4 未来：ZK-KYC + Travel Rule

未来理想架构：
  - 用户在 KYC 提供商 Sumsub 完成身份验证
  - 收到 ZK 证明（VC：Verifiable Credential）
  - 在 VASP A 发起转账时，附 ZK 证明（不暴露身份）
  - VASP B 验证证明真实性，但不获得明文 KYC 数据
  - FIU 在合法授权下可解开

实施挑战：

• 监管认可度低
• ZK 链上验证仍贵
• 各辖区 KYC 标准不一致

---

八、关键速查 Cheat Sheet

---

九、面试题（资深级）

Q1: 为一家全球加密交易所设计 Travel Rule 端到端架构，关键决策点是什么？

STAR-T：

• Situation：CEX 在 EU、UK、SG、JP、HK 都有牌照，需要 2024-12-30 前合规
• Task：设计 Travel Rule 解决方案
• Action：
  1. 核心服务商：选 Notabene（最大网络）+ Sumsub（KYC 整合）双备份
  2. 协议：TRP 主用 + TRISA 备用（亚洲 VASP）
  3. 阈值：按最严辖区（EU 0 元）→ 全部交易触发
  4. Self-Custody 处理：Address Attribution 通过 Wallet Connect 签名 + Notabene SafeTransact
  5. 链上分析：Chainalysis KYT 实时风控
  6. 数据保留：5 年，符合最严辖区
  7. 路由优化：发送时检测对手 VASP 的协议，自动适配（TRP/TRISA/Sygna）
• Result：合规所有辖区，年成本 $2M，集成周期 6 个月
• Trade-off：Self-Custody 流程增加用户摩擦，部分用户流失

Q2: 解释 FATF "Sunrise Issue" 问题，以及它是如何被解决的？

回答：

• Sunrise Issue：FATF Travel Rule 实施进度不一——A 国实施了，B 国未实施。A 国 VASP 向 B 国 VASP 发送时无法获取 KYC 数据 → 合规 dilemma
• 早期解决：
  1. 仅向已实施国 VASP 转账（限制业务）
  2. 自托管钱包"中介"（增加摩擦）
  3. 单方面满足，不强制对方
• 当前进展：
  • 2024 年 FATF 评估：75% 国家已立法，但实施差异大
  • Notabene Directory 覆盖 1500+ VASP（2024）
  • EU TFR 2024-12-30 生效后，整个欧盟同步
• 架构启示：仍需基于"对手风险地图"做差异化处理：
  • 已实施国：完整 Travel Rule
  • 未实施国：本地化 KYC + 风险评估 + 监控

Q3: DeFi 协议如何遵守 FATF Travel Rule？

回答：

• 基础冲突：DeFi 无中央实体作为 VASP → 无 KYC、无 IVMS101 接口
• 三种应对方案：
  1. Permissioned DeFi：协议本身仅向 KYC 钱包开放（如 Aave Arc、Maple Finance）。前端运营方作为 VASP 履行 Travel Rule
  2. 链上 DID 方案：用户钱包绑定 DID/VC（Polygon ID、Privado ID），DeFi 协议要求高金额交易时验证 DID。但 IVMS101 兼容仍是挑战
  3. 下游 VASP 转嫁：DEX 不做 KYC，但用户最终入金/出金 CEX 时 CEX 履行义务（"延迟 KYC"）。监管认可度有限
• 实例：Compound III 2023 年探讨 KYC 版本（Compound Treasury），dYdX V4 通过验证者地理屏蔽
• 未来：FATF 可能在 2025-2026 发布 DeFi-specific 指引，引入"控制力测试"判定责任主体

Q4: 比较 Tornado Cash 制裁（OFAC, 2022-08）和 Notabene Travel Rule 的合规思路差异？

回答：

• Tornado Cash 制裁（OFAC, 2022-08-08）：
  • 黑名单层面：将 Tornado Cash 协议地址列入 SDN List
  • 后果：与该协议交互即违反美国制裁
  • 法律性质：协议本身被制裁（争议——代码即财产？）
  • 2024-11 Fifth Circuit 撤销部分（Van Loon v. Treasury）：协议不是"财产"
• Notabene Travel Rule：
  • 流程层面：交易过程中传送 KYC 数据
  • 后果：合规即可继续交易
  • 法律性质：行为合规
• 差异：制裁是红线（不能碰），Travel Rule 是流程（合规即可）
• 架构启示：
  1. 风控顺序：先 OFAC 检查（拒绝） → 再 Travel Rule（合规）
  2. 链上分析需双重：地址黑名单 + 资金来源穿透
  3. 智能合约可嵌入 Sanction Oracle（如 Chainalysis Sanctions Oracle）做实时检查

Q5: 解释 EU TFR 与 MiCA 的关系，以及对加密项目的影响？

回答：

• 关系：MiCA + TFR 是"双子"立法，2023-05-31 同时通过、2024-06-30 与 2024-12-30 分批生效
• TFR 范围：
  • 适用所有加密资产转账（包括稳定币、NFT 排除）
  • 适用 CASP（与 MiCA 定义一致）
  • 零阈值（区别于传统电汇 €1,000）
• 对项目影响：
  1. CASP 必须实施 IVMS101 系统（如 Notabene 集成）
  2. Self-Custody 转账：≥ €1,000 → CASP 必须收集（不验证）发件人/收件人信息
  3. 完整公链分析：CASP 需对入金来源做完整链上追溯
  4. 监管报告：定期向 NCA 报告
• 架构启示：
  • CASP 是 EU 加密合规的"枢纽"，所有合规义务汇集到此
  • DeFi 项目若想服务欧盟用户，必须通过 CASP 接口
  • 推动了 KYC NFT、链上 DID 方案在欧盟的发展

---

十、明日预告

明日（Day 23）我们专攻 OFAC 与制裁合规：研究 Tornado Cash 制裁案（2022-08-08）、SDN List 机制、Specially Designated Nationals 名单管理、链上地址过滤工具（Chainalysis Sanctions Oracle、TRM Sanctions API）、跨辖区制裁合规架构（OFAC vs EU vs UK），以及 Van Loon v. Treasury 判决对 DeFi 的意义。