📚 课程目录第2章制裁与合规基础

2. 制裁与合规基础

制裁筛查不是简单的“名单比对”，而是一套由法律授权、监管规则、名单机制和工程实现共同构成的合规控制体系。要做好OFAC、UN与EU的筛查工程，首先必须理解制裁的法律来源、名单的生成逻辑以及不同制裁类型的风险边界。否则，系统很容易陷入“只查名字、不看规则”的误区，导致漏报或误报。

一、制裁类型：从全面制裁到定向制裁

国际制裁通常按对象和范围分为以下几类，不同类别对筛查系统的要求差异很大：

全面制裁（Comprehensive Sanctions）：针对特定国家或地区，限制几乎所有贸易、金融和投资活动，如对伊朗、朝鲜、叙利亚的历史性全面制裁。筛查时不仅看名单，还要看国家/地区字段。
定向制裁（Targeted Sanctions）：针对特定个人、实体、船只、飞机或行业，如资产冻结、旅行禁令、交易禁令。这是OFAC SDN名单、UN综合名单和EU综合名单的主要形式。
行业制裁（Sectoral Sanctions）：针对特定经济部门，如俄罗斯金融、能源、国防行业。OFAC的SSI名单（Sectoral Sanctions Identifications List）是典型代表，限制的是特定交易类型而非全面冻结。
次级制裁（Secondary Sanctions）：对非美国主体与受制裁对象进行重大交易的行为进行处罚，要求筛查系统具备“穿透”和“实际控制”判断能力。
出口管制与贸易限制：如美国EAR、BIS实体清单，虽与制裁名单有交集，但法律依据和筛查逻辑不同，工程上常需并行处理。

筛查系统必须区分“资产冻结”与“交易限制”：前者要求立即冻结并报告，后者要求拒绝特定交易。混淆两者会导致合规动作错误。

二、OFAC、UN与EU制裁体系概述

三大体系在授权来源、名单结构和执行力度上各有特点，工程实现时需分别建模。

体系	法律依据	核心名单	主要特点
OFAC（美国）	IEEPA、TWEA、CISADA等联邦法律及总统行政令	SDN、SSI、NS-CMIC、CAPTA等	域外管辖强，50%规则，次级制裁风险高
UN（联合国）	联合国宪章第七章，安理会决议	UN Consolidated List	全球通用，成员国须转化为国内法执行
EU（欧盟）	欧盟共同外交与安全政策（CFSP）及理事会条例	EU Consolidated List、FSF名单	与UN联动，但保留独立添加权，强调基本权利保障

OFAC的50%规则是工程实现中的关键：被制裁实体直接或间接持股50%及以上的子公司，即使未单独列名，也视为受制裁对象。这意味着筛查系统不能只做“名单精确匹配”，还要结合股权穿透数据。

UN名单由安理会制裁委员会维护，更新频率较低但权威性最高。EU名单则通过理事会条例直接生效，成员国监管机构负责执行，且近年来对俄罗斯的制裁更新频繁，对系统的实时同步能力提出更高要求。

三、法律依据与监管要求：从条文到系统参数

制裁合规的法律依据决定了筛查的“强制动作”和“报告义务”。以OFAC为例，美国主体（包括美国公民、永久居民、美国境内实体及美国母公司控制的海外子公司）必须遵守OFAC规定。违反者可能面临民事罚款甚至刑事责任。

监管要求通常包括：

资产冻结与拒绝交易：发现匹配后立即冻结相关资产，并拒绝执行交易。
报告义务：在规定时限内向OFAC或成员国主管机构提交冻结报告和年度报告。
记录保存：保留筛查日志、匹配结果、处置动作至少5年（OFAC要求）。
持续监控：名单更新后需在合理时间内重新筛查存量客户和交易。

许多团队只关注“名单下载”，却忽略了“名单版本管理”。如果无法证明某笔交易发生时使用的是当时有效的名单版本，审计时会被视为控制失效。

在工程实现中，法律要求应转化为可配置参数。例如，匹配阈值、复核时限、报告模板和留存周期都应在系统中显式定义，而不是硬编码在业务逻辑里。

# 示例：制裁筛查配置片段（YAML）
sanctions:
  lists:
    - name: OFAC_SDN
      source: https://www.treasury.gov/ofac/downloads/sdn.csv
      refresh_interval: 24h
      version_retention: 5y
    - name: UN_CONSOLIDATED
      source: https://scsanctions.un.org/resources/xml/en/consolidated.xml
      refresh_interval: 48h
  matching:
    threshold: 0.85
    algorithm: jaro_winkler
    fields: [name, alias, address, country, id_number]
  actions:
    freeze: true
    report_within_hours: 24
    retain_logs_years: 5

四、案例与误区复盘：一个典型的漏报场景

某跨境支付公司在处理一笔欧元汇款时，收款人名称与EU综合名单中的某个实体高度相似，但系统仅做了精确匹配，未触发告警。事后监管检查发现，该实体使用了变体拼写，且系统未启用别名和模糊匹配。更严重的是，系统日志中缺少名单版本信息，无法证明当时使用的是最新名单。

这个案例暴露了三个常见误区：

误区一：只做精确匹配。制裁名单中大量存在别名、音译和拼写变体，必须结合模糊匹配和别名库。
误区二：忽略名单版本。没有版本管理的筛查日志在审计中几乎无效。
误区三：不区分制裁类型。将SSI名单与SDN名单同等处理，可能导致过度冻结或漏报。

正确的做法是：建立“名单—版本—匹配—处置—报告”的完整链路，每一步都留下可审计的证据。筛查系统不是“查一下”，而是“可证明查过、查得对、处置合规”。

理解制裁类型、三大体系的法律依据和监管要求，是后续工程实战的基础。只有把法律规则转化为系统参数和流程控制，筛查才能真正成为有效的合规防线。