制裁筛查是跨境支付系统中最重要的合规环节之一。在全球经济制裁体系日益复杂的背景下，支付服务商必须在交易处理过程中对涉及的各方实体进行实时筛查，确保不与受制裁个人、组织或国家发生交易。一次失败的筛查可能导致数千万美元的罚款、业务牌照吊销，甚至刑事指控。
根据联合国安理会、美国财政部海外资产控制办公室（OFAC）、欧盟理事会、英国财政部（HMT）等机构的数据，全球受制裁实体数量已超过 200 万个条目，并以每月约 5% 的速度增长。跨境支付平台如果未能有效筛查，合规风险极高。
制裁名单是制裁筛查的数据基础。全球主流制裁名单体系包括：
| 制裁名单 | 管理机构 | 条目数量（2025年） | 法律效力范围 | 更新频率 |
|---|---|---|---|---|
| OFAC SDN List | 美国财政部 | ~15,000 | 全球（美元清算） | 每日 |
| OFAC Non-SDN Lists | 美国财政部 | ~50,000 | 全球 | 每日 |
| EU Consolidated List | 欧盟理事会 | ~2,000 | 欧盟成员国 | 不定期 |
| UN Sanctions List | 联合国安理会 | ~700 | 全球（联合国成员国） | 不定期 |
| UK HMT Sanctions List | 英国财政部 | ~5,000 | 英国管辖 | 每日 |
| OFAC CAATSA List | 美国财政部 | ~300 | 全球（针对特定行业） | 不定期 |
| World Bank Debarment List | 世界银行 | ~1,000 | 世界银行项目 | 每月 |
| Interpol Wanted List | 国际刑警组织 | ~10,000 | 全球 | 实时 |
OFAC 的 SDN（Specially Designated Nationals）名单是制裁筛查中最常用、也是风险最高的名单。SDN 名单不仅包括个人，还包括：
不同国家的制裁体系和执法力度存在显著差异。以最具影响力的 OFAC 为例：
制裁严格程度（2025年评估）：
OFAC（美） ████████████████ 最严格，域外效力最强
HMT（英） ██████████████ 严格，域外效力有限
EU（欧盟） ██████████ 严格但政治妥协多
UN（联合国） ██████ 条数少但具有最广泛的国际合法性
举例说明：某中国跨境支付平台处理的美元交易中涉及一家伊朗物流公司。即使该公司的注册地和业务操作都在欧洲，只要清算路径经过美国的代理行（Correspondent Bank），OFAC 即可行使管辖权。
制裁筛查不是简单的名单匹配，而是多维度的实体特征比对。系统需要对交易中的多个字段进行多维度的校验：
| 维度 | 示例数据 | 重要性 | 匹配难度 |
|---|---|---|---|
| 姓名/名称 | "Ali Mohammed Hassan" | 最高 | 高（多语言变体） |
| 地址 | "Tehran, IR" | 高 | 中 |
| 出生日期 | 1980-03-15 | 中 | 低（标准化格式） |
| 证件号码 | 护照号、身份证号 | 中 | 低 |
| 国籍/注册地 | Iran | 高 | 低 |
| 银行账号 | IBAN、SWIFT BIC | 中 | 中 |
| 交易附言 | "Payment for goods" | 中 | 高（非结构化文本） |
| IP地址 | 192.0.2.100 | 低 | 中（VPN混淆） |
| 关联交易对手 | 最终受益人（UBO） | 高 | 高（多层穿透） |
姓名筛查是制裁筛查中最具挑战性的维度，原因如下：
具体案例：某支付系统在筛查 "王伟" 时使用了默认的 Levenshtein 距离算法，阈值设为 0.8，但当遇到 SDN 名单中的 "Wang Wei" 时，由于拼音和王字（Wang vs Wang 完全相同），系统产生了误中（False Positive）。与此同时，系统却漏掉了真正的受制裁实体——因为该实体的英文名 "Wei Wang" 被客户以 "Wang Wei" 提交，系统未能正确识别名字顺序互换。
制裁筛查系统将匹配算法分为两大类：精确匹配（Exact Match）用于快速过滤，模糊匹配（Fuzzy Match）用于减少漏报（False Negative）。
精确匹配包括完全一致和变形匹配：
# 精确匹配示例：身份证件号匹配
def exact_match(pan_input, pan_list):
"""
对证件号进行标准化后精确匹配
返回: (matched: bool, matched_item: dict)
"""
# 步骤1：去除分隔符（空格、横线）
cleaned_input = ''.join(pan_input.split())
# 步骤2：转换为大写
cleaned_input = cleaned_input.upper()
for item in pan_list:
cleaned_list = ''.join(item['pan'].split()).upper()
if cleaned_input == cleaned_list:
return True, item
return False, None
精确匹配的正面案例：
模糊匹配是制裁筛查的核心技术，主流的算法包括：
| 算法 | 原理 | 适用场景 | 准确率 | 速度 |
|---|---|---|---|---|
| Levenshtein Distance | 编辑距离（插入/删除/替换） | 英文姓名字符串 | 中 | 快 |
| Jaro-Winkler | 前缀加权编辑距离 | 短字符串（姓名） | 高 | 快 |
| Soundex | 发音编码 | 英文姓氏发音匹配 | 中 | 极快 |
| Metaphone/Double Metaphone | 改进版发音编码 | 多语言姓名 | 高 | 快 |
| N-gram Cosine Similarity | 字符级子串重叠 | 长文本、地址 | 高 | 中 |
| 拼音转写匹配 | 中文拼音/中文名匹配 | 中文名跨境支付 | 高 | 中 |
Levenshtein 距离计算示例：
比较 "MOHAMMED" 与 "MOHAMMAD"：
位置：M O H A M M E D
| |
M O H A M M A D
差异点：位置 7 → E 与 A 不同
编辑操作：替换 E → A
Levenshtein 距离 = 1
标准化相似度 = 1 - (1 / max(len1, len2))
= 1 - (1 / 8) = 0.875
如果阈值设为 ≥ 0.85，则判定为匹配 ✅
中文姓名的跨境支付筛查需要特殊的处理方案：
def chinese_name_match(chinese_name, list_entry):
"""
中文名与SDN名单的匹配逻辑
支持：全名、拼音、英文名、别名
"""
# 步骤1：中文转拼音（支持多音字）
pinyin = hanzi2pinyin(chinese_name) # "张伟" → "zhang wei"
# 步骤2：拼音分拆为姓和名
surname, given_name = split_surname_given(pinyin)
# surname = "zhang", given_name = "wei"
# 步骤3：组合多种可能的匹配方式
candidates = [
f"{surname} {given_name}", # "zhang wei"
f"{given_name} {surname}", # "wei zhang" (英文顺序)
f"{surname}{given_name}", # "zhangwei"
f"{given_name}{surname}", # "weizhang"
capitalize(surname + given_name), # "Zhangwei"
capitalize(given_name + surname), # "Weizhang"
]
# 步骤4：对每个候选进行模糊匹配
for candidate in candidates:
score = jaro_winkler_similarity(candidate, list_entry['name'].lower())
if score >= 0.85:
return True, list_entry, score
return False, None, 0
真实案例：支付平台排查 "赵宇" 时，SDN 名单中的实体为 "Yu Zhao"。系统先生成拼音 "zhao yu"，然后生成候选顺序 "zhao yu" 和 "yu zhao"，发现 "yu zhao" 与 "Yu Zhao" 匹配。如果不处理姓名顺序翻转，将产生漏报（False Negative）。
误报率是制裁筛查系统最重要的性能指标之一。根据行业经验数据：
| 行业 | 平均误报率 | 筛选比例（每百万交易） | 人工处理成本 |
|---|---|---|---|
| 大型银行 | 1-3% | 10,000-30,000 | $5-15/笔 |
| 中小银行 | 3-8% | 30,000-80,000 | $10-25/笔 |
| 跨境支付平台 | 2-5% | 20,000-50,000 | $3-10/笔 |
| 电商平台 | 5-10% | 50,000-100,000 | $1-5/笔 |
以日处理 100 万笔交易的跨境支付平台为例：
这就是为什么误报率降低 1% 对支付平台意味着数千万美元的节约。
| 原因 | 占比 | 典型场景 |
|---|---|---|
| 姓名重名 | 45% | "李强"与SDN中同名者匹配 |
| 名称相似 | 25% | "Mohammed Ali"与"Mohammad Ali" |
| 地址片段模糊 | 12% | "宁波"与"伊朗"(名字近音) |
| 历史遗留数据 | 10% | 已移除名单但系统缓存未更新 |
| 非实体匹配 | 8% | "Free Palestine"匹配制裁关键词 |
交易发起
↓
实时筛查 ←── 制裁名单数据库（每日更新）
↓
┌──────────────────────────────┐
│ 匹配判断 │
│ ├─ 精确命中 → 自动拒绝(Reject) │
│ ├─ 高分模糊匹配 → 人工审核 │
│ └─ 低分/无匹配 → 自动放行 │
└──────────────────────────────┘
↓
┌──── 自动拒绝 ────→ 拒绝通知
│
人工审核队列
│
┌───┴───┐
│ │
放行 拒绝
(False (True
Positive) Positive)
制裁筛查按执行时机分为两大类：实时筛查（Real-time Screening）和批量回溯筛查（Batch/Retrospective Screening）。
实时筛查嵌入交易处理流程中的关键节点，在交易完成前完成筛查。根据支付系统的架构，筛查节点包括：
| 节点 | 位置 | 延迟要求 | 放行策略 |
|---|---|---|---|
| 交易创建 | 用户提交时 | < 100ms | 异步放行/同步拒绝 |
| 路由决策 | 确定通道前 | < 50ms | 同步阻断 |
| 清算前 | 发送清算文件前 | < 1s | 同步阻断 |
| 出金前 | 资金出款前 | < 200ms | 同步阻断 |
实时筛查的性能要求：在毫秒级完成数十万条制裁名单的模糊匹配。
# 实时筛查架构（使用倒排索引加速）
class RealtimeSanctionsScreener:
def __init__(self, sanctions_list):
# 构建倒排索引以加速匹配
self.inverted_index = self._build_inverted_index(sanctions_list)
self.cache = LRUCache(maxsize=100000, ttl=300) # 5分钟缓存
def _build_inverted_index(self, sanctions_list):
"""构建 2-gram 倒排索引"""
index = defaultdict(list)
for idx, entry in enumerate(sanctions_list):
name = entry['name'].upper()
# 提取所有 2-gram 子串
for i in range(len(name) - 1):
bigram = name[i:i+2]
index[bigram].append(idx)
return index
def screen(self, transaction):
"""实时筛查单笔交易"""
# 检查缓存
cache_key = f"{transaction.sender_name}:{transaction.receiver_name}"
if cache_key in self.cache:
return self.cache[cache_key]
# 步骤1：通过倒排索引快速找出候选名单条目
name_bigrams = self._extract_bigrams(transaction.receiver_name.upper())
candidate_indices = set()
for bigram in name_bigrams:
if bigram in self.inverted_index:
candidate_indices.update(self.inverted_index[bigram])
# 步骤2：对候选条目进行精细匹配
results = []
for idx in candidate_indices:
entry = sanctions_list[idx]
score = self._fuzzy_match(transaction.receiver_name, entry['name'])
if score >= THRESHOLD:
results.append((entry, score))
# 排序，取最高分
results.sort(key=lambda x: x[1], reverse=True)
# 缓存结果
self.cache[cache_key] = results
return results
def _extract_bigrams(self, text):
return {text[i:i+2] for i in range(len(text) - 1)}
性能对比：对一个包含 200 万条记录且每条记录平均 30 字符的制裁数据库：
| 方法 | 单次匹配时间 | 百万交易耗时 | 服务器需求 |
|---|---|---|---|
| 全量 Levenshtein | ~15ms | ~4.2 小时 | 50 核 |
| N-gram 倒排索引过滤 | ~0.3ms | ~5 分钟 | 8 核 |
| 缓存命中（常见名） | ~0.01ms | ~30 秒 | 4 核 |
批量回溯筛查适用于以下场景：
回溯筛查示例流程：
Day 1: OFAC 更新制裁名单，新增 50 个实体
↓
Day 1 23:00: 触发器启动批量回溯作业
↓
查询过去 90 天所有交易
↓
对每笔交易执行全量模糊匹配
↓
识别 127 笔潜在命中的交易
↓
生成回溯报告 → 提交合规团队审核
↓
合规团队确认：3 笔确为制裁实体交易
↓
冻结资金 → 报告监管 → 申请资产冻结令
回溯筛查的性能要求：通常允许在 2-4 小时内完成全部历史交易的回溯。
| 历史交易量 | 回溯窗口 | 完成时间 | 每日增量更新 |
|---|---|---|---|
| 1 亿笔 | 90 天 | ~2 小时 | ~15 分钟 |
| 10 亿笔 | 90 天 | ~20 小时 | ~2 小时 |
| 50 亿笔 | 90 天 | ~4 天 | ~10 小时 |
制裁筛查需要在百万级名单中实现毫秒级匹配，这对系统架构提出了极高的要求。
| 策略 | 效果 | 实现难度 |
|---|---|---|
| 内存数据库（Redis/Memcached） | 匹配速度提升 100x | 低 |
| 倒排索引（Inverted Index） | 候选集缩小 1000x | 中 |
| Bloom Filter | 快速过滤 99% 不相关实体 | 低 |
| 名单分区（按地域/行业） | 缩小搜索范围 10x | 中 |
| 预计算相似度矩阵 | 避免重复计算 | 高 |
交易数据 → [L1: 交易级缓存] (LRU, TTL=5min)
↓ 未命中
[L2: 名单级缓存] (Redis, TTL=1hour)
↓ 未命中
[数据库: 全量名单] (MySQL/ES)
缓存命中率对性能的影响：
| 场景 | L1 命中率 | L2 命中率 | 平均延迟 | 数据库 QPS |
|---|---|---|---|---|
| 热门名称频繁匹配 | 40% | 45% | 2ms | 15,000 |
| 中等频率 | 20% | 50% | 5ms | 30,000 |
| 冷启动（新系统） | 0% | 10% | 50ms | 90,000 |
N-gram 倒排索引可以将需要比较的名单条目从 200 万条缩减到数十条，再将精细匹配应用于这些候选条目。
实际效果：
输入姓名：Mohammed Ali Al-Ahmad
↓
2-gram 提取：MO, OH, HA, AM, MM, ME, ED, D , A, AL, LI, I , A, AL, L -, -A, AH, HM, MA, AD
↓
倒排索引匹配 → 候选条目从 200 万 → 387 条
↓
Jaro-Winkler 精细匹配 → 最终得分排序
↓
前 5 条候选结果输出
制裁名单更新是筛查系统维护中最关键的部分。名单过期或未及时更新是合规审计中最常见的发现。
| 机构 | 数据格式 | 更新方式 | 数据源地址 |
|---|---|---|---|
| OFAC | XML, CSV, TXT | RSS Feed, 邮件通知 | https://www.treasury.gov/resource-center/sanctions/SDN-List |
| EU | PDF, XML | 官方公报（Official Journal） | https://data.europa.eu |
| UN | XML, JSON | 官方网页 | https://www.un.org/securitycouncil/sanctions |
| UK HMT | CSV, XML | API | https://www.gov.uk/government/publications/financial-sanctions-consolidated-list |
┌─────────────────────────────────────┐
│ OFAC 发布新名单 (SDN_20250530.xml) │
└─────────────┬───────────────────────┘
↓
自动爬虫检查 (每5分钟)
↓
检测到新版本 → 下载
↓
┌─────────┴──────────┐
│ 解析/转换/标准化 │
│ → XML → 内部数据格式 │
└─────────┬──────────┘
↓
┌─────────┴──────────┐
│ 差异分析 │
│ → 新增: 47条 │
│ → 移除: 12条 │
│ → 修改: 23条 │
└─────────┬──────────┘
↓
┌─────────┴──────────┐
│ 增量更新数据库 │
│ → 主库: MySQL │
│ → 缓存: Redis │
│ → 搜索引擎: Elasticsearch │
└─────────┬──────────┘
↓
┌─────────┴──────────┐
│ 触发批量回溯筛查 │
│ → 对新增条目的历史交易 │
│ → 生成回溯报告 │
└─────────────────────┘
不同监管机构对名单更新时效的要求：
| 监管要求 | 更新频率 | 最大延迟 | 适用场景 |
|---|---|---|---|
| OFAC 建议 | 每日 | 24 小时 | 美元清算 |
| 欧盟 4AMLD | 实时 | 无 | 所有欧元交易 |
| 香港金管局 | 每日 | 24 小时 | HKD 交易 |
| 新加坡 MAS | 每日 | 24 小时 | SGD 交易 |
| 人民银行 | 实时 | 无 | CNY 跨境交易 |
class SanctionsUpdateManager:
def __init__(self):
self.update_history = []
self.fallback_data_sources = [
'https://primary.treasury.gov/sdn.xml',
'https://mirror.sanctions.org/sdn.xml',
'https://cdn.wikileaks.org/sanctions/sdn.xml'
]
def update_sanctions_list(self):
for attempt, source in enumerate(self.fallback_data_sources, 1):
try:
data = self.download(source)
parsed = self.parse_and_validate(data)
if self.verify_integrity(parsed):
self.apply_update(parsed)
self.record_success(source, len(parsed))
return True
except Exception as e:
self.log_error(f"Attempt {attempt} failed: {e}")
continue
# 所有源都失败时
self.trigger_manual_review()
return False
def verify_integrity(self, data):
"""验证更新数据完整性"""
checksum = hashlib.sha256(json.dumps(data, sort_keys=True).encode()).hexdigest()
# 与官方 checksum 对比
return checksum == self.get_official_checksum()
合规审计要求对所有筛查操作进行完整记录，通常保留 5-7 年。
| 字段 | 说明 | 示例 |
|---|---|---|
| 交易ID | 内部唯一标识 | TX20250530000001 |
| 筛查时间 | 精确到毫秒 | 2025-05-30 14:23:45.123 UTC |
| 名单版本 | 筛查所用名单的快照版本 | OFAC-SDN-20250530-v3 |
| 匹配结果 | 精确/模糊/无匹配 | FUZZY_MATCH |
| 评分 | 各算法的综合评分 | 0.92 |
| 命中条目 | 命中的制裁名单条目ID | SDN-0042157 |
| 处理动作 | 放行/拒绝/人工审核 | REJECT |
| 审核人 | 人工审核的操作员ID | operator_zhang |
| 审核备注 | 操作员备注 | "同名，但其他信息不符" |
| 复核时间 | 上级复核时间 | 2025-05-30 15:00:00 |
{
"audit_period": "2025-Q1",
"total_transactions": 87654321,
"screening_summary": {
"auto_pass": 87000000,
"auto_reject": 4500,
"manual_review": 49821,
"false_positives": 46500,
"true_positives": 3321
},
"list_updates": {
"total_updates": 247,
"new_entries": 3893,
"removed_entries": 2156,
"modified_entries": 1247
},
"retrospective_screening": {
"batch_count": 12,
"total_screened": 25000000,
"hits_found": 892,
"confirmed_positives": 45,
"funds_frozen": 1250000,
"report_to_regulator": true
},
"errors": {
"update_failures": 2,
"recovery_time_avg": "15 minutes",
"false_negatives": 1,
"impact": "1 transaction with $50,000 to sanctioned entity"
}
}
支付平台的制裁筛查系统每年需要接受外部审计，以下是核心检查项：
□ 1. 是否覆盖所有必要的制裁名单
□ 2. 名单更新是否及时（<24h）
□ 3. 筛查算法是否有效（误报率、漏报率）
□ 4. 人工审核流程是否完善
□ 5. 审核记录是否完整保存（≥5年）
□ 6. 回溯筛查是否按期执行
□ 7. 误报优化措施是否持续进行
□ 8. 员工合规培训是否定期进行
□ 9. 系统性能是否满足SLA
□ 10. 灾备恢复能力是否经过测试
跨境支付比境内支付面临更复杂的筛查场景，主要体现在以下几个方面：
交易：中国跨境电商 → 迪拜客户
涉及法域：
├─ 中国法：可能不制裁该迪拜客户
├─ 美国法（USD清算）：OFAC 可能制裁
├─ 阿联酋法：迪拜本地法
└─ 欧盟法（EUR结算通道）：欧盟制裁清单
在法域冲突时，支付平台通常采用 最严格原则（Most Restrictive Principle）：遵循所有涉及法域中制裁最严格的标准。
企业支付案例：
付款方：香港 A 公司（表面看起来没问题）
↓
穿透受益人（UBO）：
└─ 最终股东 → 伊朗国民（持股100%）
↓
筛查结果：SDN 名单中的受制裁实体
↓
处理：拒绝交易，报告监管
跨境支付不仅涉及金融制裁，还涉及贸易制裁（出口管制）：
| 类型 | 内容 | 监管机构 | 影响 |
|---|---|---|---|
| 金融制裁 | 禁止资金往来 | OFAC | 冻结资产、拒绝交易 |
| 贸易制裁 | 禁止特定商品/技术出口 | BIS（商务部） | 拒绝相关贸易支付 |
| 行业制裁 | 限制特定行业（能源、军工等） | OFAC、BIS | 部分限制 |
| 二级制裁 | 制裁与受制裁实体交易的外国实体 | OFAC | 切断美元清算 |
随着加密货币在跨境支付中的应用增加，制裁筛查面临新的挑战：
| 加密货币制裁措施 | 机构 | 覆盖范围 |
|---|---|---|
| OFAC 加密地址制裁列表 | OFAC | 约 1,000+ 地址 |
| Chainalysis 制裁标记 | 私营 | 数百万标记地址 |
| 交易所 KYC 筛查 | 各交易所 | 所有链上地址关联 |
结合以上所有需求，一个完整的制裁筛查系统的参考架构如下：
┌─────────────────┐ ┌─────────────────────┐ ┌─────────────────┐
│ 支付交易输入 │───▶│ 制裁筛查核心引擎 │───▶│ 决策输出 │
│ - API 请求 │ │ │ │ - 自动放行 │
│ - 批量文件 │ │ ┌─────────────────┐ │ │ - 自动拒绝 │
│ - Webhook │ │ │ 精确匹配引擎 │ │ │ - 人工审核队列 │
└─────────────────┘ │ │ - 证件号匹配 │ │ └─────────────────┘
│ │ - 精确姓名匹配 │ │
│ └─────────────────┘ │
│ ┌─────────────────┐ │
│ │ 模糊匹配引擎 │ │
│ │ - Levenshtein │ │
│ │ - Jaro-Winkler │ │
│ │ - Soundex │ │
│ └─────────────────┘ │
│ ┌─────────────────┐ │
│ │ ML 评分引擎 │ │
│ │ - 特征工程 │ │
│ │ - 风险评分模型 │ │
│ └─────────────────┘ │
└─────────────────────┘
│
▼
┌─────────────────┐ ┌─────────────────────┐ ┌─────────────────┐
│ 名单管理 │ │ 数据存储 │ │ 审计与报告 │
│ - OFAC 自动更新 │ │ - Redis (实时) │ │ - 操作日志 │
│ - EU/UN 更新 │ │ - MySQL (持久化) │ │ - 审计报告 │
│ - 手动添加入口 │ │ - ES (检索) │ │ - 合规监控 │
│ - 差异对比工具 │ │ - HDFS (历史归档) │ │ - 监管报送 │
└─────────────────┘ └─────────────────────┘ └─────────────────┘
制裁筛查是跨境支付系统必不可少的关键合规能力。一个高效的制裁筛查系统需要在以下方面取得平衡：
根据行业最佳实践，一个成熟的制裁筛查系统应达到以下 KPI：
| 指标 | 目标值 |
|---|---|
| 误报率（False Positive Rate） | < 2% |
| 漏报率（False Negative Rate） | < 0.01% |
| 实时筛查 P99 延迟 | < 50ms |
| 名单更新延迟 | < 1 小时 |
| 人工审核处理时效 | < 30 分钟 |
| 审计通过率 | 100% |
更新日期：2026-05-30