制裁名单数据怎么做成筛查工作流：从姓名命中到可审计处置

下载一份制裁名单，再做姓名相似度搜索，并不等于拥有一套合规筛查产品。真实业务会马上遇到同名、别名、音译、公司层级、证件字段缺失、名单更新和误报积压；系统故障时，还要决定哪些流程暂停、哪些可以进入人工复核，以及恢复后如何补筛。

r/ComplianceOps 的一则筛查服务中断讨论描述了供应商不可用后，交易被集中挂起、团队临时下载官方名单、人工处置规则却没有预先写清的情景。帖子及回复未经独立核实，不能代表金融机构普遍做法；它给产品设计提出了一个好问题：筛查产品交付的是搜索结果，还是在正常与降级状态下都能追溯的决定流程？

官方名单是来源，不是最终判断

OFAC Sanctions List Service提供 SDN、Non-SDN consolidated、定制数据集和历史 delta 文件等入口，并将名单数据开放为可下载格式。采集层应保存来源列表、记录标识、发布时间、下载时间、文件摘要和解析版本。只有这样，日后才能回答某次筛查使用的是哪一版名单。

同一个对象可能有主名称、弱别名、地址、国籍、出生日期、证件号码、船舶或航空器标识。产品不能把这些字段压成一个长字符串再给出神秘分数。标准化层应保留字段类型和来源原值，同时生成用于检索的规范化表示；任何转写、去标点或音译都要能解释。

名单条目还不是全部合规范围。OFAC 关于 50 Percent Rule 的说明指出，某些未被直接列名的实体也可能因一个或多个被制裁主体合计持有 50% 或以上而被视为 blocked。仅对交易对手名称查名单，无法代替所有权调查。产品必须把“名单直接命中”和“所有权链待核对”分成不同任务，不能用没有股权数据的姓名搜索给后者下结论。

相似度分数只能召回候选

OFAC FAQ 246说明，Sanctions List Search 只对 name 字段使用 fuzzy logic，其他字段采用字符匹配。也就是说，姓名分数只是候选召回信号，不是一个跨字段的风险概率。

产品可以用姓名、别名和音译扩大召回，再用出生日期、地址、国籍、注册地、证件或实体类型帮助分析人员区分。但字段不一致的意义取决于数据质量：出生年份缺失不等于不匹配；地址不同也可能只是历史地址；个人与公司类型冲突则通常是更强的排除信号。界面应展示字段逐项对照，而不是只给“87 分”。

建议至少保留四种结果：

• 待复核：名称或别名达到召回条件，但辅助字段不足。
• 可排除候选：分析人员依据明确字段差异排除，并记录理由与有效期。
• 需升级：关键字段一致或所有权关系需要合规人员判断。
• 无可用结果：本次查询未完成、名单过期或输入不足，不能显示成“通过”。

自动关闭误报尤其要谨慎。以前排除过一个同名对象，不代表新名单版本、新地址或新证件下仍然可排除。所谓 good match exception 应绑定对象标识、依据字段、适用名单与失效条件。

输入质量决定筛查质量

如果上游只传一个截断的收款人名称，后端再复杂也无法恢复缺失身份。筛查 API 应返回输入质量提示：缺少国家、实体类型未知、姓名疑似被字段长度截断、公司后缀被移除，或证件格式无法识别。业务可以据此补资料，而不是不断调低阈值。

个人、公司、船舶和航空器使用不同字段模型。把所有对象都塞进 name + country 会让公司注册号、个人出生日期和船舶 IMO 号失去语义。统一接口可以有共同外壳，但每种对象都应保留自己的强识别字段。

隐私范围同样要控制。筛查需要的身份字段不意味着可以无限保存客户材料。原始证件图、提取字段、筛查请求和分析结论应分层授权，并分别定义保留期。站内的统一数据 API 设计指南可以用于设计来源证据与业务动作的边界，但不能替代法域和用途评估。

持续监控不是每天重复一条提醒

名单更新后，需要找出新增、修改和删除记录，再只重筛可能受影响的对象。若没有稳定的来源记录 ID 和版本差异，系统容易把名称格式调整误认为新命中，也可能漏掉别名或证件字段的新增。

持续监控事件至少包含名单版本、变化字段、受影响对象数、重筛批次和处理状态。同一客户在多个业务关系中出现时，实体解析应避免创建重复案件，但各业务关系的动作仍要独立：开户、付款、供应商准入可能有不同控制人和时限。

不要把“名单删除”自动解释为可以恢复所有业务。此前冻结、拒绝或升级的处置可能需要合规人员按适用规则复核。数据变化只触发任务，系统不越权给出法律结论。

故障降级必须在事故之前设计

名单下载失败、解析错误、筛查服务超时和案件系统不可用是四种不同故障。产品需要显示当前名单版本及新鲜度，拒绝用过期缓存冒充刚完成核对；同时为可恢复的请求保留幂等键，避免服务恢复后重复创建案件。

降级规则应由业务与合规负责人预先批准，例如哪些流程一律挂起、哪些只允许保存草稿、何时转人工、积压按什么顺序补筛。技术团队不能在事故中临时决定真实资金或客户准入是否放行。OFAC Compliance Commitments Framework将风险评估、内部控制、测试与审计、培训等列为合规项目的重要组成；一套筛查产品也应为这些组织控制提供证据，而不是自称替代它们。

恢复后要生成补筛清单：中断窗口内有哪些对象和交易、当时使用的名单版本、现在的重筛结果是否变化、谁复核了差异。站内的API 错误与自愈指南可帮助设计重试、降级和异常队列，但真实放行规则仍应由有权限的人制定。

MVP 验证分析闭环，不追求零误报

第一版可以只覆盖一种对象、一个业务入口和明确的一组官方名单。用经过授权的历史样本建立测试集，分别记录真命中召回、无关候选数量、每案复核时间、输入缺失和名单更新延迟。不要用一个总体“准确率”掩盖漏报与误报的不同代价。

验收时随机抽取已关闭案件，确认另一名分析人员能根据同一输入、名单版本和记录理由重建决定。还应演练一次名单更新和一次服务中断，验证旧结果不会被静默复用、积压不会丢失、恢复后可以补筛。

本文讨论的是制裁名单数据产品化与工程控制，不构成法律或合规意见，也不代表 EveryInfra 已发布制裁筛查服务。名单系统最重要的输出不是“通过”两个字，而是一个边界清楚、允许不确定、能由有权限人员复核并在多年后重建的决定过程。