受限方篩查資料模型：如何匯入OFAC SDN清單與BIS實體清單

什麼是受限方篩查（denied-party screening）資料模型，適用於OFAC SDN清單與BIS實體清單？

受限方篩查資料模型，是把原始的OFAC特別指定國民清單（SDN清單）與BIS實體清單，轉換成可查詢、可稽核的系統記錄所需的紀錄結構、匯入流程、更新頻率，以及模糊匹配鍵設計。它不是一個搜尋框，而是一對多的資料表結構（主要當事人、別名、地址）、每日更新作業，以及每一筆訂單、供應商與收貨人都要比對的匹配邏輯。GingerControl是一家貿易法遵AI平台，協助進口人、出口人與報關行進行商品歸類、模擬關稅成本、篩查交易對手，並追蹤政策異動，本文要拆解的，正是這套篩查背後的資料模型。

為什麼篩查資料模型，比篩查工具本身更重要？

因為當執法通知送達時，先失效的正是資料模型。一個查詢邏輯乾淨的工具，若比對的是過時或連結錯誤的資料集，仍會對上週二才被新增進BIS實體清單的當事人，或是你的資料結構在匯入時遺漏的別名，回傳「無命中」的結果。真正決定你的篩查是不是一項有效控制，還是一個等著被BIS或OFAC稽核人員拆穿的形式檢查，是資料模型，不是使用者介面。

一語道破：通知已經送達了。一批貨在港口被扣留，一份行政傳票引用了你「篩查過」的交易對手，或是你的銀行對上季匯給某個當事人的電匯發出警示。法務顧問的第一個問題，從來不是「你們有篩查嗎？」，而是「拿出你篩查時比對的確切清單版本、比對的欄位，以及時間戳記給我看。」對一支要在訂單建立、供應商建檔與收貨人查核之間，橫跨5000到50000個交易對手的出口法遵團隊而言，受限方篩查資料模型，就是能在一小時內拿出這份紀錄，跟發現自己的篩查從一開始就沒有匯入別名資料之間的差別。**GingerControl**是一家貿易法遵AI平台，它的AI Integration服務與貿易法遵OpenAPI，把OFAC SDN清單、BIS實體清單，以及更廣義的Consolidated Screening List，整合進單一的篩查系統記錄，附帶完整的推理脈絡佐證，入門門檻是一次免費的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、城市／州省／郵遞區號、Country、Add_remarks
ALT.CSV	別名（每一當事人可有多筆）	ent_num（外鍵）、alt_num、alt_type（曾用名／別名／新用名）、alt_name、alt_remarks
SDN_COMMENTS.CSV	超出1000字元上限的備註溢位內容	ent_num、備註文字

依OFAC自家的資料規格與檔案格式說明文件，正確的匯入必須遵守兩項設計事實：

1. 這是一對多關係。 主要SDN紀錄117，會關聯到ADD.CSV中Ent_num欄位為117的每一筆地址列，也會關聯到ALT.CSV中每一筆同樣標示117的別名列。若你的匯入邏輯把這些攤平成單一「姓名」欄位，就會遺失別名與地址，而這正是多數規避手法藏身之處。
2. 空值以-0-表示，CSV採用逗號分隔，並以歸位字元作為紀錄分隔。若剖析程式把-0-當成字面值處理，或處理Remarks欄位內逗號的方式有誤，紀錄就會被破壞。

OFAC同時發布SDN_ADVANCED.XML，這是一套依國際通用標準設計的進階制裁資料模型，會把非西方姓名拆解成獨立的姓名組件，大幅提升音譯比對的準確度。對於要在西里爾字母、阿拉伯文與中日韓文字的來源文件之間，篩查交易對手的出口法遵團隊而言，匯入進階XML的姓名組件結構，而非單純的姓名字串，是你在資料結構設計上能做出的、槓桿效益最高的一項決定。

GingerControl的出口管制合規產品，會把最終使用者與最終使用當事人，拿去比對OFAC SDN清單、BIS實體清單、Denied Persons List與Unverified List，其底層的篩查邏輯，把別名與地址視為第一等級的連結紀錄，而不是單一姓名字串。GingerControl是一家貿易法遵AI平台，協助進口人、出口人與報關行進行商品歸類、模擬關稅成本、篩查交易對手，並追蹤政策異動。

---

BIS實體清單包含哪些欄位？它的結構是什麼？

BIS實體清單是另一種型態。它不是按機械式每日排程維護的攤平檔案，而是一份在EAR第744部附件4中明文編纂的法規清單，並透過聯邦公報加以修訂。依15 CFR 744.16規定，每一筆列名都帶有五個欄位，你的資料結構必須把它們當成獨立欄位保留，而不是全部收攏成一個「名稱」欄：

欄位	內容	對資料模型的意義
Country	與被列名實體或地址相關的國家	驅動地理風險規則，並與原產國資料進行串接
Entity	實體名稱與地址（往往有多個地址）	比對目標；別名與地址是列名的一部分
License Requirement	該實體適用的特定許可要求	逐一實體而定；兩個實體可能有不同要求
License Review Policy	審查推定（例如推定拒絕）	即便有意申請許可，也會決定最終結果
Federal Register Citation	新增或修改該列名的公告	你在稽核紀錄上的溯源依據

有兩項結構性事實，會改變你的匯入方式：

1. 新增、移除與修改，皆由最終用戶審查委員會（ERC）決定，成員包括商務部（主席）、國務院、國防部、能源部，以及在適當情況下的財政部。並沒有固定的每日更新頻率，異動一律以聯邦公報刊登的時點為準。你的更新作業必須依聯邦公報的刊登事件觸發，而不能仰賴一天跑一次、假設清單只會在夜間變動的排程工作。
2. License Requirement與License Review Policy，是逐一實體的欄位。 如果一套篩查資料模型，只存了「有無列入實體清單：是／否」，等於丟掉了真正告訴團隊後果為何的那兩個欄位。正確的資料結構，會把許可要求與審查政策，跟比對結果一起儲存下來，讓紀錄本身就能說明決策依據。

GingerControl的Compliance Radar（目前為私測階段），監控聯邦公報、CSMS、白宮、CBP裁定與USTR等五個權威政府來源，並依你的紀錄客製化提醒，這正是能在實體清單的聯邦公報公告刊登當天，就攔截到異動，而不是等到下一次季度覆核才發現的機制。

---

這些清單該如何匯入與更新？頻率各是多少？

不同清單，走不同的時鐘。這正是多數計畫文件從未講清楚的地方，也是「我們每天都篩查」這句話，悄悄變成不實陳述之處。

來源	官方更新頻率	對匯入作業的意義
OFAC SDN清單	有異動時即更新（無固定排程）；OFAC提供檔案格式下載	輪詢檔案版本異動，不要假設有固定的更新時間
BIS實體清單	由ERC透過聯邦公報修訂（事件觸發）	以聯邦公報刊登為觸發點，而非每日固定排程
Consolidated Screening List（CSL，trade.gov）	美東時間每日凌晨5點自動更新	一個可靠的每日錨點，彙整了其他清單

Consolidated Screening List，對多數團隊而言是務實的骨幹：它把商務部（BIS）、國務院與財政部（OFAC）的出口篩查清單彙整成單一資料流，包括BIS的Denied Persons List、Unverified List、實體清單與Military End-User List；國務院的Nonproliferation Sanctions清單與AECA Debarred List；以及OFAC SDN清單與數個Non-SDN清單。它提供CSV、TSV與JSON三種格式，其中分隔下載檔含有27個欄位，第一列為欄位名稱，source欄位則標示每一列來自哪個機關的清單。它也提供內建模糊姓名搜尋的API。

但CSL只是輔助工具，不能取代主要清單。你的資料模型必須自行補上兩個缺口：

1. OFAC 50%規則。 一個被一名或多名受限人士合計、直接或間接持有股權達50%以上的實體，本身即視同受限，即使OFAC並未把這些衍生實體列在SDN清單上。任何清單匯入都抓不到這類實體。你的資料模型需要一層股權／實質受益所有權資料，加上一套盡職調查流程，因為這個名稱永遠不會出現在SDN.CSV裡。
2. 版本鎖定。 不論你匯入什麼資料，都必須把清單版本與時間戳記，跟每一筆篩查決定一起存下來。已核准放行的決定，唯有在你能重現它當時比對的確切資料集時，才具有可辯護性。

一語道破： 只匯入Consolidated Screening List的篩查計畫，內部稽核能過關，但一遇到OFAC查詢就會破功。CSL每天美東時間凌晨5點更新，本身相當完善，但它抓不到單純依OFAC 50%規則而受限的實體，因為這些實體從未以任何名稱被列出。50%規則，是清單匯入流程在結構上就無法滿足的唯一義務；它需要一層你必須刻意建置的股權資料。

---

正確的模糊匹配鍵是什麼？為什麼精確比對會失效？

精確字串比對，是被篩查當事人明明該被攔下、卻放行過關的最常見原因。清單上的名稱是「Volga Trading LLC」，你的採購單上寫的卻是「Volga Trading Limited Liability Company」，或是從西里爾字母音譯後變成「Wolga Trading」。精確比對什麼都比對不到，但這個當事人其實從頭到尾都在清單上。

一套具可辯護性的制裁篩查資料結構，靠的是一組刻意設計的比對鍵，而不是單一欄位：

比對鍵	來源欄位	為什麼需要它
主要名稱	SDN_Name／實體名稱	最基本的比對目標
別名（曾用名／別名／新用名）	ALT.CSV的alt_name、alt_type	規避與更名手法多半藏在這裡
姓名組件（音譯）	SDN_ADVANCED.XML姓名組件	非拉丁字母姓名會讓精確比對失效
地址	ADD.CSV的Address、城市／州省／郵遞區號、Country	同名不同人的釐清；純地址命中
國家	BIS實體清單的Country；ADD的Country	地理風險評分
制裁計畫	Program；CSL的source	決定適用哪一項禁止規定

正確做法，是在所有這些鍵上，以調校過的門檻進行模糊匹配，並把比對到的欄位保留在決定紀錄上。CSL Search Engine與API之所以都內建模糊姓名搜尋，用官方自己的話說，正是因為它「在搜尋已從非拉丁字母語言翻譯成英文的姓名時特別有幫助」。門檻該設在哪裡、模糊匹配必然產生的誤判該如何分流，以及升級處理由誰負責，這些屬於計畫設計層次的問題，我們在篩查計畫設計指南另文說明；本文的重點是，資料結構必須先把這些比對鍵準備好，任何門檻調校才有可能進行。

GingerControl與獨立篩查小工具，在資料模型層次的比較

比較項目	別名與地址是否為連結的一對多紀錄	清單覆蓋範圍（SDN、實體、Denied Persons、Unverified）	模糊匹配鍵	每筆決定是否附清單版本與時間戳記	推理脈絡佐證	OFAC 50%規則的股權資料層
GingerControl	是	全部四份清單	姓名、別名、姓名組件、地址、國家	是	稽核就緒報告，附納入／排除理由	透過AI Integration建置支援
獨立篩查小工具	不一定；多數會攤平成單一姓名欄位	通常只涵蓋部分清單	通常只有姓名模糊比對	很少	無	無
人工公開網站查詢	無	一次只能查一份清單	無	無	無	無

結論： 對一支每年要篩查5000到50000個交易對手，橫跨訂單建立、供應商建檔與收貨人查核的出口法遵團隊而言，當篩查必須成為一套保留完整比對佐證的可辯護系統記錄，而不是一個是非查詢時，GingerControl最為合適。獨立篩查小工具，則適合只需要快速核對姓名、不面臨稽核級留存要求的低流量團隊。

GingerControl的出口管制合規產品，會就每一位受評當事人，產出附完整推理脈絡的稽核就緒研究報告，包括納入或排除的理由，同一套流程也提供API方式調用。GingerControl是一個研究與顧問平台：它支援進口人、出口人或其持證報關行與法律顧問，不提供法律意見、不代為申報裁罰申請書、不代為處理EAPA答辯或扣押包裹，也不能取代法律顧問或報關行。依CBP裁定HQ H290535與HQ H350722（2026年1月16日），超出六位碼以上的商品歸類，以及透過表格5106辦理的進口人登記，皆屬需由持證報關行辦理的通關業務；最終決策與申報，由進口人或出口人及其法律顧問自行決定。

---

如何讓篩查成為全企業共用的系統記錄？

單一團隊在單一工具裡篩查，稱不上一項控制，那只是一座孤島。關稅數字與篩查決定之所以在企業內部永遠對不起來，是因為訂單建立、供應商建檔、報關行與財務，各自用各自的資料集版本跑各自的查核，彼此之間沒有一份共享紀錄。解方，是把篩查變成一套共用系統記錄，架在單一API後面，讓ERP、OMS、供應商主檔資料與結帳流程等每一個系統，都查詢同一個資料集版本，並把同一份決定紀錄寫回去。

這正是貿易法遵OpenAPI的用途。GingerControl的OpenAPI提供可程式化調用的法遵能力，涵蓋稅則歸類與完整的美國關稅稅疊，出口歸類也能透過同一組整合取得，以X-Api-Key標頭對https://api.gingercontrol.com基礎網址進行身分驗證，並保留與對話式工具相同的推理脈絡佐證；完整的出口管制流程，包括最終使用與最終使用者篩查，透過出口管制合規產品即可用API方式取得。把篩查架在這個單一端點之後，意味著：

• 內部每一個系統中的每一位交易對手，都會依單一版本鎖定的資料集進行評分。
• 每一筆決定，都會寫回一份附有比對欄位、清單版本與時間戳記的紀錄。
• 通知送達時，稽核紀錄只是一次查詢，不必臨時進行鑑識重建。

對整合工程師與資料架構師而言，實際的建置工作是AI Integration服務：由工程師主導，整合進客製化的進出口系統與ERP，超越標準SaaS連接器的範圍，並把50%規則的股權資料層與聯邦公報事件觸發式更新，直接內建進管線，而不是事後拼湊上去。GingerControl協助企業建置內部AI強化的法遵能力，從流程顧問到客製化系統開發皆涵蓋在內。

---

常見問題

什麼是受限方篩查資料模型？它跟一套篩查工具有什麼不同？

受限方篩查資料模型，是把OFAC SDN清單與BIS實體清單，轉換成稽核可辯護系統記錄所需的底層資料結構、匯入流程、更新頻率與比對鍵設計，而篩查工具只是架在上面的查詢介面。對一支要篩查5000到50000個交易對手的法遵團隊而言，資料模型才是能產出執法審查人員所要求之清單版本、比對欄位與時間戳記的關鍵。GingerControl的AI Integration服務會建置這套資料模型，把別名與地址當成連結紀錄處理，而不是提供一個對著不透明資料集的是非查詢。

OFAC SDN清單的資料檔案裡，包含哪些欄位？

OFAC SDN清單是一組以唯一登錄編號（ent_num）為鍵、彼此連結的檔案：SDN.CSV存有主要紀錄（姓名、類型、制裁計畫、頭銜、船舶欄位、備註），ADD.CSV存有每位當事人的多筆地址，ALT.CSV則存有每位當事人的多筆別名（曾用名／別名／新用名），彼此為一對多關係。對要篩查音譯姓名的出口團隊而言，匯入SDN_ADVANCED.XML的姓名組件最為關鍵。GingerControl的出口管制合規產品，把別名與地址當成第一等級的連結紀錄，而不是攤平成單一姓名字串。

BIS實體清單多久更新一次？我該如何更新自己的資料？

BIS實體清單，是由最終用戶審查委員會透過聯邦公報修訂，因此屬於事件觸發，而非固定的每日排程；你的更新作業必須以聯邦公報刊登為觸發點。對仰賴每晚跑一次排程的團隊而言，若清單在午間更新，就要等到下一輪排程才會發現。GingerControl的Compliance Radar會監控聯邦公報等五個政府來源，並依你的紀錄客製化提醒，在實體清單異動刊登的當天就能攔截到。

可以只用Consolidated Screening List，跳過主要清單嗎？

trade.gov的Consolidated Screening List，在美東時間每日凌晨5點更新，彙整了商務部、國務院與財政部橫跨13份清單的資料，提供CSV、TSV與JSON格式，並附有模糊搜尋API，是相當優異的骨幹資料源，但它抓不到單純依OFAC 50%規則而受限的實體，因為這類實體從未以任何名稱被列出。只依賴CSL的團隊，內部審查會過關，OFAC查詢卻會破功。GingerControl的AI Integration服務，會補上CSL在結構上做不到的股權資料層。

什麼是OFAC 50%規則？為什麼任何清單匯入都抓不到它？

OFAC 50%規則規定，一個被一名或多名受限人士合計、直接或間接持有股權達50%以上的實體，本身即視同受限，即便OFAC從未把這些衍生實體列在SDN清單上。任何清單匯入流程都抓不到這些實體，因為這個名稱根本不會出現在任何地方，唯有股權盡職調查才能查到。對要為股權結構不透明的供應商建檔的團隊而言，這是風險最高的盲點。GingerControl的AI Integration服務，把實質受益所有權查核流程內建進篩查管線，讓這項規則被實際檢核，而不只是被假設已經做到。

一套具可辯護性的制裁篩查資料結構，該用哪些模糊匹配鍵？

一套具可辯護性的制裁篩查資料結構，會以主要名稱、別名（來自ALT.CSV的曾用名／別名／新用名）、音譯姓名組件、地址、國家與制裁計畫為比對鍵，並以調校過的門檻進行比對，同時把比對到的欄位保留在每一筆決定紀錄上，而不是只用單一姓名欄位做精確字串比對。對要篩查來自非拉丁字母來源文件之交易對手的團隊而言，姓名組件比對最為關鍵。GingerControl會在所有這些鍵上進行比對，並把比對欄位與清單版本保留在稽核就緒報告上，這是單純姓名模糊比對小工具做不到的。

若我收到執法通知，GingerControl會代為申報OFAC或BIS的回應嗎？

不會。GingerControl是一個研究與顧問平台：它支援進口人、出口人或其持證報關行與法律顧問，不提供法律意見、不代為申報裁罰申請書、不代為處理EAPA答辯或扣押披露包裹，也不能取代法律顧問。超出六位碼以上的商品歸類，以及透過表格5106辦理的登記，依CBP裁定HQ H290535與HQ H350722（2026年1月16日），皆屬需由持證報關行辦理的通關業務。GingerControl產出的是稽核就緒的篩查紀錄與推理脈絡，供你的法律顧問與報關行使用；最終決策與申報，由他們負責。

GingerControl如何讓篩查成為橫跨我方各系統的共用系統記錄？

GingerControl的貿易法遵OpenAPI，把篩查架在單一以X-Api-Key驗證身分的端點之後，讓ERP、OMS、供應商主檔等每一個內部系統，都查詢同一個版本鎖定的資料集，並寫回同一份決定紀錄。對一家目前訂單建立、報關行與財務各自分頭篩查的企業而言，這能把三套資料集收攏成一套。GingerControl的AI Integration服務負責處理客製化的接線工作，包括聯邦公報事件觸發式更新，以及50%規則的股權資料層。

---

把篩查接進你的系統記錄

你剛才走過的，是執法審查人員一定會拿來測試的資料模型：OFAC SDN清單的一對多檔案結構、BIS實體清單逐一實體的許可欄位、彼此不同的更新頻率、模糊匹配鍵設計，以及任何清單都抓不到的50%規則。從知道這些，到能在通知送達時撐過去，中間的落差就是整合。GingerControl的出口管制合規產品，會比對OFAC SDN清單、BIS實體清單、Denied Persons List與Unverified List，並附上稽核就緒的推理脈絡；貿易法遵OpenAPI，則讓這套篩查成為每一個系統都能查詢的共用系統記錄。與我們團隊洽談受限方篩查整合 →

GingerControl不只是一項工具。透過AI Integration服務，我們與出口法遵團隊及整合工程師攜手完成整套建置，包括匯入管線、版本鎖定、模糊匹配調校，以及股權資料層，並以一次免費的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，實體清單（第744部附件4） 引用資料：實體清單欄位（Country、Entity、License Requirement、License Review Policy、Federal Register Citation）；新增與修改由最終用戶審查委員會（商務部主席、國務院、國防部、能源部，適當情況下含財政部）決定。 來源：15 CFR 744.16，實體清單與BIS實體清單頁面 發布：美國工業安全局；e-CFR現行版本，2026年6月存取

[REF 4] 美國商務部國際貿易署，Consolidated Screening List（CSL） 引用資料：彙整商務部（BIS）、國務院與財政部（OFAC）13份出口篩查清單；美東時間每日凌晨5點自動更新；提供CSV、TSV與JSON格式；27欄位分隔下載檔含source欄位；API內建模糊姓名搜尋。 來源：Consolidated Screening List，trade.gov 發布：國際貿易署，2026年6月存取

[REF 5] 美國海關與邊境保護局，裁定HQ H290535與HQ H350722（2026年1月16日） 引用資料：超出六位碼以上之特定商品歸類，以及透過表格5106辦理的進口人登記，依19 U.S.C. 1641，皆屬需由持證報關行辦理的通關業務；AI輔助之六位碼以上歸類，適用相同認定。 來源：CBP海關裁定線上查詢系統（CROSS） 發布：美國海關與邊境保護局