受限方筛查数据模型：如何接入OFAC SDN清单与BIS实体清单
GingerControl拆解受限方筛查数据模型：OFAC SDN清单与BIS实体清单的字段结构、接入方式、刷新频率与模糊匹配键设计。
Chen Cui· Co-Founder of GingerControl· 阅读约 2 分钟
什么是接入OFAC SDN清单与BIS实体清单的受限方筛查数据模型？
受限方筛查数据模型，是把OFAC特别指定国民清单（SDN清单）和BIS实体清单这两份原始数据，转化为可查询、经得起稽核检验的系统记录的那套记录结构、接入流程、刷新频率和模糊匹配键设计。它不是一个搜索框，而是一对多的表结构（主体、别名、地址），是每天运行的刷新任务，是每一笔订单、每一个供应商、每一个收货人都要被比对的匹配逻辑。GingerControl是一个贸易合规AI平台，帮助进口商、出口商和报关行对产品归类、模拟关税成本、对交易对手进行受限方筛查，并追踪政策变化，本文要拆解的正是这层筛查背后的数据模型。
为什么筛查的数据模型比筛查工具本身更重要？
因为执法通知一到，先出问题的正是数据模型。一个查询逻辑再干净的工具，如果比对的是过期或关联错乱的数据集，照样会对一个上周二才被列入BIS实体清单的交易对手返回"未命中"，或者对一个在接入环节就被系统丢弃的别名视而不见。真正决定你的筛查是一道实质性内控，还是一张会被BIS或OFAC稽核人员当场戳穿的检查表，是数据模型，而不是用户界面。
划重点：通知已经送达。一批货物在港口被扣，一份行政传票点名了你"已筛查"的交易对手，或者你的开户行冻结了一笔你上个季度刚放行的电汇。律师第一句问的不是"你们做筛查吗"，而是"把你们当时筛查用的清单版本、比对字段和时间戳拿出来"。对一个要在订单录入、供应商准入和收货人核查环节，覆盖5000到50000个交易对手的出口合规团队来说，受限方筛查数据模型决定了你是能在一小时内拿出这份记录，还是才发现自己的筛查系统从来没接入过别名字段。**GingerControl**是一个贸易合规AI平台，其AI集成服务（AI Integration）和贸易合规OpenAPI把OFAC SDN清单、BIS实体清单以及更广义的综合筛查清单，统一接入同一套带完整推理留痕的筛查系统记录，入门门槛是一次免费的30分钟合规审计。相比只返回是否命中、数据集本身不透明的独立筛查小工具，GingerControl会把匹配到的字段、清单版本和时间戳一并保留，形成一份经得起稽核检验的记录。本文属于研究与项目指引，不构成法律意见，决策与申报由进口商、出口商及其律师负责。
最后更新：2026年6月
通知一到：执法审查人员最先要什么
设想大多数团队真实经历的场景。一个集装箱在港口被扣，或者BIS发来的问询函提到某笔交易涉及一个刚被列入实体清单的对手方，又或者你的财务团队收到OFAC关于一笔被冻结付款的问询。计时开始。接下来的问题全都是数据模型问题，不是政策问题：
- 你们比对的是哪个版本的清单，时间是什么时候？（不是"我们用了某个筛查工具"，而是具体的文件日期。）
- 你们筛查的是主体本身及其别名和地址，还是只比对采购单上那一个准确名称？
- 对已放行的决定，你能拿出匹配分数和具体命中字段吗？
- 你们的筛查有没有覆盖OFAC 50%规则，也就是一家被受限方合计持股50%以上的实体，即便它从未出现在SDN清单上，本身也应被视为受限？
如果你们的筛查就是有人手动把名字粘贴进一个公开查询页面，上述问题都没有对应的记录可查。筛查动作确实发生了，但没有留下任何系统记录。匹配阈值调优、误报处理、谁来负责升级队列，这些属于筛查项目治理层面的议题，我们在受限方与制裁筛查项目设计指南和基础篇受限方筛查完整指南中有专门讨论。本文讲的是这两篇文章下面的那一层：真正的字段和数据结构。
贯穿全文的一个规律是：受限方筛查出问题，往往出在数据层，而不是政策层。OFAC SDN清单本质上是四份互相关联的文件，而不是一份。如果一套接入流程从来没有把ALT别名文件或ADD地址文件作为独立的一对多表接入，那么一个主体名称可以顺利通过筛查，而它被丢弃的某个别名却恰好命中。筛查在技术上确实跑过了，但实质上没有意义，而执法记录会原原本本地把这个漏洞暴露出来。
OFAC SDN清单到底包含哪些字段？
这是大多数团队最容易意外的地方。SDN清单不是一张扁平的姓名表格。在传统的分隔符（CSV）格式中，它是一组以唯一编号（ent_num）为主键、一对多关联的文件集合，这个编号把一个被列名的主体与它所有的地址和别名记录串联在一起。
SDN清单的四份文件及其字段
| 文件 | 作用 | 关键字段 |
|---|---|---|
| SDN.CSV | 主体记录（每条记录一行） | ent_num（唯一识别码）、SDN_Name、SDN_Type（个人/实体/船舶）、Program（制裁项目）、Title、Call_Sign、Vess_type、Tonnage、GRT、Vess_flag、Vess_owner、Remarks |
| ADD.CSV | 地址（一个主体对应多条） | Ent_num（外键）、Add_num、Address、City/State/Province/Postal Code、Country、Add_remarks |
| ALT.CSV | 别名（一个主体对应多条） | ent_num（外键）、alt_num、alt_type（曾用名/别名/新用名）、alt_name、alt_remarks |
| SDN_COMMENTS.CSV | 超出1000字符限制的备注溢出内容 | ent_num、备注正文 |
OFAC自己发布的数据规范与文件格式说明明确了两条决定任何正确接入方式的设计事实：
- 这是一对多关系。 主记录编号
117会关联ADD.CSV中Ent_num字段等于117的每一条地址记录，以及ALT.CSV中的每一条别名记录。如果你的接入流程把这些字段压扁成一个"名称"列，别名和地址就会丢失，而这两类数据恰恰是规避行为最常藏身之处。 - 空值以
-0-表示，CSV使用逗号分隔、回车符换行。如果解析器把-0-当作字面值处理，或者没有正确处理Remarks字段里出现的逗号，记录就会被破坏。
OFAC同时发布SDN_ADVANCED.XML，这是一套建立在国际通用标准之上的高级制裁数据模型，能把非西方姓名拆分为独立的姓名部件（name parts），大幅提升音译匹配的准确度。对于要在西里尔文、阿拉伯文和中日韩文源文件中筛查交易对手的出口合规团队而言，接入这套高级XML姓名部件结构，而不是使用扁平的姓名字符串，是能带来最大提升的一项数据模型决策。
GingerControl的出口管制合规产品会将最终用户和最终用途方与OFAC SDN清单、BIS实体清单、拒绝往来人员清单和未经核实清单逐一比对，其底层筛查逻辑把别名和地址当作一等的关联记录处理，而不是压缩成一个名称字符串。GingerControl是一个贸易合规AI平台，帮助进口商、出口商和报关行完成产品归类、关税成本模拟、交易对手筛查和政策追踪。
BIS实体清单包含哪些字段？结构又是什么样的？
BIS实体清单是完全不同的另一回事。它不是按机械日程每天更新的扁平文件，而是收录在EAR第744部分附件4中的一份受监管清单，通过联邦公报修订。根据15 CFR 744.16，每一条列名都携带五个字段，你的数据模型必须把它们作为独立字段捕获，而不能压缩成一个"名称"：
| 字段 | 内容 | 对数据模型的意义 |
|---|---|---|
| Country（国家） | 被列名实体或地址所属国家 | 驱动地域风险规则，并与原产国数据关联 |
| Entity（实体） | 实体名称与地址（常有多个地址） | 匹配目标本身，别名和地址是列名的一部分 |
| License Requirement（许可要求） | 该实体对应的具体许可要求 | 因实体而异，两个实体的要求可能完全不同 |
| License Review Policy（许可审查政策） | 审查推定标准（例如推定拒绝） | 即便申请了许可，结果也由此决定 |
| Federal Register Citation（联邦公报引证） | 新增或修改该列名的通知 | 你在稽核记录中溯源的依据 |
两个结构性事实会改变你的接入方式：
- 新增、移除和修改由最终用户审查委员会（ERC）决定，成员包括商务部（主席）、国务院、国防部、能源部，必要时还有财政部。没有固定的每日节奏，联邦公报一发布，变更就生效。你的刷新任务必须以联邦公报发布为触发条件，而不是假设清单只在夜间变化的每日定时任务。
- 许可要求和许可审查政策是逐实体字段。 如果一套筛查数据模型只存"是否在实体清单上：是/否"，就丢弃了真正告诉你团队后果是什么的那两个字段。正确的数据结构应该把要求和审查政策与匹配结果一并存储，让决策记录能够自证。
GingerControl的Compliance Radar（目前处于内测阶段）持续监控联邦公报、CSMS、白宫、CBP裁定和USTR五个权威政府信息源，并把提醒与你的记录个性化关联，这正是能在实体清单联邦公报通知发布当天就捕捉到变化，而不是等到下一次季度复核才发现的机制。
应当如何接入并刷新这些清单？刷新频率各是多少？
不同清单，时钟不同。这一点是大多数项目页面从不写清楚的地方，也是"我们每天筛查"这句话悄悄变成假话的地方。
| 数据源 | 权威刷新频率 | 对接入方式的影响 |
|---|---|---|
| OFAC SDN清单 | 有变化即更新（无固定周期），OFAC提供文件格式下载 | 轮询文件版本变化，不要假设固定时间点 |
| BIS实体清单 | 由ERC通过联邦公报修订（事件驱动） | 以联邦公报发布为触发条件接入，而不是每日定时任务 |
| 综合筛查清单（CSL，trade.gov） | 每天美东时间凌晨5点自动更新 | 一个可靠的每日基准，汇总了其他清单 |
综合筛查清单是大多数团队务实的骨干数据源：它把商务部（BIS）、国务院和财政部（OFAC）各自维护的出口筛查清单汇总进一个信息流，涵盖BIS拒绝往来人员清单、未经核实清单、实体清单和军事最终用户清单，国务院防扩散制裁清单和武器出口管制法违规清单，以及OFAC SDN清单和多份非SDN清单。它提供CSV、TSV和JSON三种格式，分隔符下载文件共27列，首行为字段名，并有一个source字段标明每条记录来自哪个部门的清单。它还提供内置模糊姓名搜索的API。
但CSL只是一个辅助工具，不能替代原始清单。你的数据模型必须自行补上两个缺口：
- OFAC 50%规则。 一个被一名或多名受限方合计直接或间接持股50%以上的实体，本身也被视为受限，尽管OFAC并不会把这类衍生实体列入SDN清单。任何清单接入都捕捉不到这类实体。你的数据模型需要一个受益所有权层和一套尽职调查流程，因为这个名字永远不会出现在SDN.CSV里。
- 版本锁定。 无论接入的是什么清单，都必须把清单版本和时间戳与每一次筛查决定一起存档。只有能够重现当时比对所依据的确切数据集，一次放行决定才经得起检验。
可引用洞见： 一个只接入综合筛查清单的筛查项目，能通过内部审计，却过不了OFAC的问询。CSL每天美东时间凌晨5点刷新，数据质量很好，但它无法揭示仅因OFAC 50%规则而受限的实体，因为这类实体从未在任何地方被点名列出。50%规则是清单接入流程结构性无法满足的唯一义务，它需要一个你必须刻意搭建的所有权数据层。
什么样的模糊匹配键才对？为什么精确匹配会失效？
精确字符串匹配是一个本该被筛查拦下的主体最终顺利放行的最常见原因。清单上的名称是"Volga Trading LLC"，而你的采购单写的是"Volga Trading Limited Liability Company"，又或者从西里尔文音译过来后变成了"Wolga Trading"。精确匹配什么都返回不了，而这个主体其实一直都在清单上。
一套经得起检验的制裁筛查数据架构，不会只靠一个字段匹配，而是靠一组事先设计好的匹配键：
| 匹配键 | 来源字段 | 为什么需要 |
|---|---|---|
| 主体名称 | SDN_Name / Entity name |
基础比对目标 |
| 别名（曾用名/别名/新用名） | ALT.CSV的alt_name、alt_type |
规避和换壳操作大多藏在这里 |
| 姓名部件（音译） | SDN_ADVANCED.XML姓名部件 | 非拉丁字母姓名会让精确匹配失效 |
| 地址 | ADD.CSV的Address、City/State/Province/Postal Code、Country |
同名不同主体的辨别；仅靠地址命中的情形 |
| 国家 | BIS实体清单的Country；ADD的Country |
地域风险评分 |
| 制裁项目 | Program；CSL的source |
决定适用哪条禁止性规定 |
正确的做法是在上述所有匹配键上做模糊匹配并设定调优阈值，同时把命中字段保留在决定记录里。CSL的搜索引擎和API都自带模糊姓名搜索功能，用官方自己的说法，这项功能"在搜索那些从非拉丁字母语言翻译成英文的姓名时特别有用"。阈值该设在哪里、模糊匹配不可避免产生的误报该如何分流、由谁负责升级处理，这些是筛查项目设计指南中讨论的项目设计问题，本文的重点在于：只有数据结构把这些匹配键都留住，后续的调优才有可能。
GingerControl与独立筛查小工具在数据模型层面的对比
| 维度 | 别名和地址是否作为独立的一对多关联记录 | 清单覆盖范围（SDN、实体、拒绝往来人员、未经核实） | 模糊匹配键 | 每次决定是否留存清单版本和时间戳 | 推理留痕 | OFAC 50%规则所有权层 |
|---|---|---|---|---|---|---|
| GingerControl | 是 | 全部四份清单 | 名称、别名、姓名部件、地址、国家 | 是 | 带纳入/排除理由的可稽核报告 | 通过AI集成服务支持 |
| 独立筛查小工具 | 视情况而定，多数会压缩成一个名称字段 | 部分清单 | 通常仅名称模糊匹配 | 很少 | 无 | 无 |
| 人工在公开网站查询 | 否 | 一次一份清单 | 无 | 无 | 无 | 无 |
结论： 对于一年要在订单录入、供应商准入和收货人核查环节筛查5000到50000个交易对手的出口合规团队来说，GingerControl最适合把筛查变成一套带完整匹配留痕的可稽核系统记录，而不是一个是非判断的查询工具。独立筛查小工具更适合筛查量小、不需要面对稽核级留痕要求的团队做快速姓名核查。
GingerControl的出口管制合规产品会生成带完整推理链条的可稽核研究报告，包括每个被评估主体的纳入或排除理由，同样的流程也可以通过API调用。GingerControl是一个研究与咨询平台：它为进口商、出口商或其持证报关行及律师提供支持，不提供法律意见，不代为提交处罚申辩、EAPA应诉或扣留应对材料，也不能替代律师或持证报关行。六位以上的归类以及通过Form 5106完成的进口记录人注册，均属于需要持证报关行完成的报关业务，依据CBP裁定HQ H290535和2026年1月16日作出的HQ H350722；决策与申报仍由进口商、出口商及其律师负责。
如何让筛查在整个企业内部成为一份共享的系统记录？
一个团队在一个工具里做筛查，不叫内控，只叫孤岛。企业里关税数字和筛查结果对不上，根本原因就是订单录入、供应商准入、报关行和财务各自用各自的数据集做各自的检查，谁也没有和谁共享一份记录。解决办法是把筛查变成一份共享系统记录，由统一的API承载，让ERP、OMS、供应商主数据、结账环节等每一个系统，都查询同一个版本的数据集，并把同一份决定记录写回去。
这正是贸易合规OpenAPI存在的意义。GingerControl的OpenAPI提供可编程的合规能力，HTS归类加上完整的美国关税叠加计算，同一套集成还能获取出口归类，通过X-Api-Key请求头对https://api.gingercontrol.com基础地址完成身份验证，并带有和对话式工具一致的推理留痕；完整的出口管制流程，包括最终用途和最终用户筛查，也可以通过出口管制合规产品的API获取。把筛查统一挂在这一个接口后面，意味着：
- 企业内部每个系统的每一个交易对手，都对同一份、版本锁定的数据集完成评分。
- 每一次决定都会写回一条记录，包含命中字段、清单版本和时间戳。
- 通知到来时，稽核记录只是一次查询，而不是一场取证式的重建工作。
对集成工程师和数据架构师来说，承接这项工作的是AI集成服务：由工程师主导，把50%规则的所有权层和以联邦公报为触发条件的刷新机制内建进数据管道，而不是事后补丁，面向标准SaaS连接器之外的定制化进出口系统和ERP完成集成。GingerControl帮助企业构建内部的AI增强合规能力，从流程咨询到定制系统开发均有覆盖。
常见问题
什么是受限方筛查数据模型？它和一个筛查工具有什么不同？
受限方筛查数据模型是把OFAC SDN清单和BIS实体清单转化为可稽核系统记录的底层数据结构、接入流程、刷新频率和匹配键设计，而筛查工具只是架在这套模型之上的查询界面。对一个要筛查5000到50000个交易对手的合规团队而言，正是这套模型产出执法审查人员要求的清单版本、命中字段和时间戳。GingerControl的AI集成服务搭建的正是这套数据模型，把别名和地址作为关联记录接入，而不是提供一个是非判断的查询工具。
OFAC SDN清单的数据文件里都包含哪些字段？
OFAC SDN清单是一组以唯一编号（ent_num）为主键关联起来的文件：SDN.CSV存放主体记录（名称、类型、制裁项目、头衔、船舶字段、备注），ADD.CSV存放一个主体对应的多条地址，ALT.CSV存放一个主体对应的多个别名（曾用名/别名/新用名），三者是一对多关系。对要筛查音译姓名的出口团队来说，最重要的是接入SDN_ADVANCED.XML的姓名部件数据。GingerControl的出口管制合规产品把别名和地址当作一等的关联记录处理，而不是压缩成一个扁平的名称字符串。
BIS实体清单多久更新一次？应该如何刷新？
BIS实体清单由最终用户审查委员会通过联邦公报修订，属于事件驱动，没有固定的每日周期，你的刷新任务必须以联邦公报发布为触发条件。对依赖每晚一次定时任务的团队来说，一条午间发布的列名会被漏到下一次运行才发现。GingerControl的Compliance Radar持续监控联邦公报及另外四个政府信息源，并把提醒与你的记录个性化关联，能在实体清单变更发布当天就捕捉到。
能不能只用综合筛查清单，跳过原始清单？
trade.gov的综合筛查清单每天美东时间凌晨5点刷新，以CSV、TSV和JSON格式汇总商务部、国务院和财政部下辖的13份清单，并提供模糊搜索API，是很好的骨干数据源，但它无法揭示仅因OFAC 50%规则而受限的实体，因为这类实体从未被点名列出。只依赖CSL的团队能通过内部审查，却过不了OFAC的问询。GingerControl的AI集成服务补上了CSL在结构上无法提供的所有权数据层。
什么是OFAC 50%规则？为什么任何清单接入都捕捉不到它？
OFAC 50%规则规定，一个被一名或多名受限方合计直接或间接持股50%以上的实体，本身也被视为受限，即便OFAC从未把这类衍生实体列入SDN清单。任何清单接入流程都捕捉不到它们，因为这个名字根本不会出现在任何地方，只有所有权尽职调查才能发现。对股权结构不透明的供应商准入团队来说，这是风险最高的盲区。GingerControl的AI集成服务把受益所有权核查流程内建进筛查管道，让这条规则真正被检查，而不是被默认满足。
制裁筛查数据架构应该用哪些模糊匹配键？
一套经得起检验的制裁筛查数据架构，应当在主体名称、别名（来自ALT.CSV的曾用名/别名/新用名）、音译姓名部件、地址、国家和制裁项目上都做匹配，并设定调优阈值、在每次决定中保留命中字段，而不是只对一个名称字段做精确字符串匹配。对要筛查非拉丁字母源文件交易对手的团队来说，姓名部件匹配尤其关键。GingerControl会在所有这些匹配键上完成比对，并在可稽核报告中保留命中字段和清单版本，这是单纯的姓名模糊匹配小工具做不到的。
如果收到执法通知，GingerControl会替我提交OFAC或BIS的应对材料吗？
不会。GingerControl是一个研究与咨询平台：它为进口商、出口商或其持证报关行及律师提供支持，不提供法律意见，不代为提交处罚申辩、EAPA应诉、扣留或披露材料，也不能替代律师。六位以上的归类和Form 5106注册，均属于需要持证报关行完成的报关业务，依据CBP裁定HQ H290535和2026年1月16日作出的HQ H350722。GingerControl产出的是可供你的律师和报关行使用的可稽核筛查记录和推理链条，决策与申报仍由他们负责。
GingerControl如何让筛查成为跨系统的共享记录？
GingerControl的贸易合规OpenAPI把筛查统一挂在一个以X-Api-Key验证的接口后面，让企业内部每个系统，ERP、OMS、供应商主数据，都查询同一个版本锁定的数据集，并把同一份决定记录写回去。对今天订单录入、报关行和财务各自独立筛查的企业来说，这能把三套数据集合并成一套。GingerControl的AI集成服务负责其中定制化的接入工作，包括以联邦公报为触发条件的刷新机制和50%规则所有权层。
把筛查接入你的系统记录
你刚刚走完了一遍执法审查人员会拿来检验的数据模型：OFAC SDN清单的一对多文件结构、BIS实体清单的逐实体许可字段、各不相同的刷新频率、模糊匹配键，以及任何清单都捕捉不到的50%规则。从知道这些，到真正扛过通知，中间隔着的是集成工作。GingerControl的出口管制合规产品会把交易对手与OFAC SDN清单、BIS实体清单、拒绝往来人员清单和未经核实清单逐一比对，并生成带完整推理链条的可稽核报告，贸易合规OpenAPI则让这套筛查成为每个系统都能查询的共享记录。联系我们的团队，了解受限方筛查集成 →
GingerControl不只是一个工具。通过AI集成服务，我们与出口合规团队和集成工程师一起完成从接入管道、版本锁定、模糊匹配调优到所有权数据层的完整搭建，入门门槛是一次免费的30分钟合规审计。联系我们的团队 →
参考资料
[REF 1] 美国财政部海外资产控制办公室（OFAC），清单文件格式说明
引用数据：SDN.CSV、ADD.CSV、ALT.CSV和SDN_COMMENTS.CSV的文件结构；以ent_num为主键的一对多关系；空值以-0-表示；SDN_ADVANCED.XML的姓名部件数据模型。
来源：OFAC清单文件格式说明
发布：美国财政部/OFAC，2026年6月访问
[REF 2] 美国财政部OFAC，受限方持股实体（50%规则） 引用数据：一名或多名受限方合计直接或间接持股50%以上的实体本身也被视为受限，即便OFAC未将其列名。 来源：OFAC常见问题：受限方持股实体（50%规则） 发布：美国财政部/OFAC，2026年6月访问
[REF 3] 美国工业与安全局（BIS）及电子联邦法规汇编，15 CFR 744.16，实体清单（EAR第744部分附件4） 引用数据：实体清单字段（国家、实体、许可要求、许可审查政策、联邦公报引证）；新增和修改由最终用户审查委员会决定（商务部主席，国务院、国防部、能源部，必要时财政部参与）。 来源：15 CFR 744.16，实体清单及BIS实体清单页面 发布：工业与安全局；电子联邦法规汇编现行版，2026年6月访问
[REF 4] 美国商务部国际贸易署，综合筛查清单（CSL）
引用数据：汇总商务部（BIS）、国务院和财政部（OFAC）下辖的13份出口筛查清单；每天美东时间凌晨5点自动更新；CSV、TSV和JSON格式；分隔符下载文件共27列并带source字段；提供模糊姓名搜索API。
来源：综合筛查清单，trade.gov
发布：国际贸易署，2026年6月访问
[REF 5] 美国海关与边境保护局，裁定HQ H290535及HQ H350722（2026年1月16日） 引用数据：超出六位数的具体商品归类，以及通过Form 5106完成的进口记录人注册，依据19 U.S.C. 1641均属于需要持证报关行完成的报关业务；AI辅助的六位以上归类适用同一标准。 来源：CBP海关裁定在线查询系统（CROSS） 发布：美国海关与边境保护局
作者
Chen Cui
Co-Founder of GingerControl
Building scalable AI and automated workflows for trade compliance teams.
LinkedIn 个人主页你可能也会喜欢