制裁篩查指南：合規實務究竟如何運作

當主要商業資料庫開始每天多次更新涵蓋數十到數百份官方清單的制裁資料後，制裁篩查便不再只是每日一次的例行檢查。LexisNexis表示其涵蓋範圍包括180份全球制裁清單以及1,700個執法來源與法院文件，更新頻率最高可達來源發布後24小時內每日四次（LexisNexis WorldCompliance Data）。這樣的規模改變了整個工作性質。分析師不再只是對照靜態清單核對姓名，而是持續對客戶、交易對手、付款與所有權變更進行控管，而且速度必須快到足以在結算前攔截可疑交易。

許多團隊常犯的錯誤，是把制裁篩查單純當作比對問題來處理。真正棘手的問題通常更早就已產生，源自於雜亂的資料、不完整的所有權鏈，以及無法順利匯入的清單資料流。若佇列中充滿看似重要卻並非真正風險的警示，或是真正命中的警示遲來而失去意義，這通常代表資料完整性不足，而不只是引擎本身有問題。控管機制的成效取決於輸入資料的品質。實務上，最出色的方案往往是由既懂規則、又懂資料的人所建立的。

目錄

• 制裁篩查究竟是什麼
• 法規環境及其重要性
• 比對引擎的底層運作原理
• • 標準化為第一步
  • 評分機制衡量可能的比對結果
  • 決策取決於門檻值
• 誤報與資料完整性問題
• • 次要識別資訊承擔主要作用
  • 髒資料導致雜訊結果
• 所有權、別名與跨制度複雜性
• • 別名為何與姓名同等重要
  • 僅依單一制度檢查會留下漏洞
• ELECTE在合規體系中的定位
• 重點整理與實用檢核清單
• 關於制裁篩查的常見問題

制裁篩查究竟是什麼

制裁篩查是將客戶、交易對手及交易資料與整合後的制裁及執法名單進行比對，讓機構得以判斷應放行、覆核或阻擋該活動的流程。這些名單通常來自OFAC、歐盟（EU）、英國OFSI及聯合國（UN）等機構，加上各國主管機關與執法紀錄。其重點不僅在於找出完全相符的姓名，而是要及早察覺禁止性風險暴露，以便及時阻止開戶、付款、貿易流程或與所有權相關的風險。

在實務層面，此項控管會檢視諸如姓名、出生日期、國籍、地址、身分證件及最終受益所有人等識別資訊。若結果乾淨，該當事人即可繼續進行；若出現潛在相符項目，則進入覆核程序；若確認相符，則依貴機構的政策觸發升級處理或阻擋。這項輸出邏輯之所以重要，是因為它告訴分析人員應採取何種行動，而不僅僅是引擎偵測到了什麼。

實務原則：若您的篩查結果無法用淺白語言解釋清楚，代表您的流程過於脆弱，禁不起檢查員或稽核人員的檢視。

更深層的問題在於，許多看似比對失敗的案例，其實是資料完整性失敗。同一個姓名可能在某系統中正確無誤，在另一系統中卻有誤；所有權鏈可能不完整；或者資料饋送在引擎讀取時早已過時。一旦理解這一點，控管範圍便會更加清晰，因為您所要管理的不只是軟體調校，而是端到端的資料品質。

法規環境及其重要性

制裁篩查正處於政策轉化為實際操作控管的關鍵點。美國制裁規則可能導致民事罰款、刑事罰金，甚至對故意違規者處以監禁，這也是為何各團隊將篩查視為日常風險作業的一部分，而非可有可無的勾選項目（Tincheck OFAC verification）。公開的執法摘要也顯示，罰款與和解金額可能迅速攀升，因此薄弱的控管措施很快就會付出高昂代價。對初階分析人員而言，教訓很簡單：若控管措施含糊不清，當檔案量或例外案件佇列增加時，就會出現失效。

更大的問題在於範圍。OFAC的百分之五十規則（50 Percent Rule）規定，當受列管人士直接或間接、合計持有某實體百分之五十（50 percent）或以上股權時，該實體即被視為受列管；若在撤資後受列管的持股比例降至該門檻以下，該實體則可脫離此自動列管狀態（OFAC FAQ）。這意味著所有權審查是篩查作業的一部分，而非獨立的法律程序。某實體在姓名檢查上可能顯得乾淨，卻仍可能透過其所有人而帶有禁止性風險暴露。

控制機制還必須符合監理機關對案件處理方式的期待。阿聯酋中央銀行表示，潛在的疑似相符應先予暫停，再透過比對出生日期、地址等次要識別資訊與制裁名單細節來解決，若無其他可疑活動存在，則可解除誤判（阿聯酋中央銀行誤判指引）。這與其他地方查核人員所要求的基本原則相同：比對紀錄、記載理由，並確保決策可追溯。類似的做法也出現在志工犯罪背景查核中，身分比對與有記錄的處置結果，其重要性不亞於最初的警示。

實務上的重點在於，篩查失敗往往是資料完整性的失敗。姓名可能因音譯錯誤而傳入系統，股權結構可能不完整，或匯入資料流可能在引擎評分之前就已過時。發生這種情況時，問題並不只出在比對邏輯本身，而在於你所輸入資料的品質，營運決策應從這一點著手。

比對引擎的運作原理

篩查引擎通常依序執行三項工作。首先，將資料標準化。接著，計算相似度評分。最後，套用決策規則。這聽起來很簡單，但每個步驟的存在都是因為現實世界中的姓名相當雜亂。

標準化是第一步

標準化會去除可避免的差異，讓引擎能夠比對紀錄的實質內容，而非其格式。這包括轉為小寫、去除多餘空格、轉譯不同文字系統、移除停用詞，以及將姓名拆分為名字與姓氏的標記。若沒有這個步驟，「Mohammed Al-Rashid」與「Muhammad al Rashid」看起來的差異，可能會比實際情況更大。

評分用於衡量可能的相符項目

標準化之後，引擎會使用Levenshtein、Jaro-Winkler以及metaphone或double-metaphone等模糊比對方法來給出相似度評分。對於多詞組成的姓名，以詞元（token）為基礎的評分方式通常比整串字比對效果更好，因為它能針對重要的部分給予加權，而非將整個姓名視為單一脆弱的整體。這也是為什麼詞序調換或缺少冠詞的姓名，仍可能被列為需要審查的項目。

決策取決於門檻設定

最後一個步驟是門檻邏輯。可設定的評分門檻，再結合對出生日期、國別和身分證號碼等高價值識別資訊給予較高權重，便能產生「清除」、「審查」或「相符」的決策結果。主要的挑戰在於根據自身的客戶組合來調整這些門檻，因為供應商的預設值在某一族群中適用，換到另一族群卻可能表現不佳。

如需更深入、以商業角度探討自動化模式偵測的內容，請參閱ELECTE su ML per business。

引擎的表現，取決於你所輸入的資料品質。如果上游紀錄不乾淨，即使是全球最頂尖的評分模型，也只能靠猜測。

誤判與資料完整性問題

誤判警示，代表這套程式過度依賴寬鬆比對或上游資料品質不佳。簡報中引用的產業報告指出，制裁篩查警示大約有 95% 到 99% 屬於誤判，也就是說只有大約 1% 到 5% 是需要升級處理的真實命中（Ionova false positives）。這正是為什麼單靠增加審核人力，很少能真正解決問題。如果佇列本身雜訊過多，人員仍會把時間耗費在清查那些從未真正具有風險的紀錄上。

更好的解讀方式，是把警示佇列當作一項資料品質檢查來看待。如果輸入的紀錄不完整、不一致或格式不佳，篩查引擎就無法有效比對身分。實務上，第一個該問的問題往往是：資料進入系統時是否夠乾淨，足以讓比對作業正常運作。若想從更廣泛的資料品質角度來理解，data validation 是一個實用的內部參考資源，有助於思考比對之前的驗證工作。

次要識別資訊才是關鍵

次要識別資訊能區分真實命中與外貌相似的個案。單獨的姓名本身是薄弱的訊號。加入出生日期、國籍或身分證號後，審核結果就更站得住腳，因為分析人員有另一種方式可以驗證身分。

不乾淨的輸入資料，造就雜訊滿滿的輸出結果

多餘的空格、變音符號、被截斷的付款欄位，以及音譯變體，都是製造雜訊的來源。再完美的引擎，也無法還原從未送達的資訊；再固定的門檻，也無法修正各系統間擷取資料不一致的問題。這正是為什麼在有標記樣本群上進行測試，遠比相信一場光鮮亮麗的展示來得重要。

一個實用的習慣是：不只用完全相符的姓名比對，而是在多種資料狀況下測試同一個佇列。

• 檢查資料輸入時的欄位品質：確認姓名、地址與身分證號等資訊是完整送達，而不是因來源系統的限制而被截斷。
• 與已知變體進行比對：在測試資料集中納入音譯與空格差異等情況。
• 檢視門檻的行為表現：觀察每次調整單一欄位時，警示數量如何變化。
• 記錄結案邏輯：不只記錄案件被結案的事實，更要記錄結案的原因。

所有權、別名與跨制裁體系的複雜性

當團隊把制裁篩查僅僅當作一項姓名比對工作時，現代化的篩查機制就會失效。即使被列管人並非直接交易對手，所有權關係仍可能帶來曝險。OFAC 的「50% 規則」在其關於間接持股與封鎖曝險的指引中，清楚說明了這一點。一筆乾淨的客戶紀錄，仍有可能落在受封鎖的所有權鏈之中，因此分析人員需要審視的是誰在控制這個實體，而不只是這個實體叫什麼名字（OFAC FAQ）。

為什麼別名和姓名一樣重要

別名覆蓋範圍是狹隘計畫與經得起審查的計畫之間的分水嶺。人們會更改法定姓名、跨語系書寫、使用音譯拼法,或透過以別名出現的實體進行交易。如果篩查檔案排除這些變體,該控管措施可能看似完整,實際上卻可能遺漏最容易被誤判的記錄。

單一制度檢查存在漏洞

該產業指南摘錄指出,受訪者將資料品質(26.85%)的排名列於受益所有權複雜性(16.11%)與跨制度合規性(14.77%)之前(AML Watcher 制裁指南)。這顯示問題不僅在於政策,更在於資料本身。以單一名單體系為核心建立的計畫執行起來較為簡單,但當同一客戶、付款或交易對手涉及不止一個制裁範疇時,便可能遺漏曝險。

營運上的決策其實很清楚。如果您的業務跨越國界、採用多層股權架構，或是需要對股權結構複雜的實體進行盡職調查，那麼股權關係圖譜篩查就應該是必要項目，而非可有可無的選項。如果您的業務範圍屬於本地且結構簡單，檔案仍需記載一份以風險為基礎的說明，解釋為何選擇不進行篩查。

ELECTE 在合規體系中的定位

篩選引擎判斷的是某筆紀錄是否命中。而資料分析層則協助你證明這項控制措施能長期有效運作。這個區別很重要，因為稽核人員不只想知道警示存在，他們要的是證據，證明這個計畫是有效、一致且受到治理的。

分析工具可以彙整警示處置結果、依業務線衡量誤報模式，並顯示名單更新是否被乾淨地採用。它也能協助你找出交易監控資料與篩選結果不一致的情況，而這往往正是漏判藏身之處。以這種方式運用，分析便成為連結營運、測試與稽核之間的紐帶。

最佳實務：將篩選警示視為證據，而不僅僅是工作流程項目。一旦這些警示被一致地記錄下來，就能支援趨勢分析、抽樣與控制測試。

對於正在建構這層治理機制的團隊來說，ELECTE 資料治理是最貼近這種運作模式的解決方案，因為它專注於讓證據保持結構化、可審查，並隨時可供分析。

真正的成效在於可衡量性。當你能夠追蹤各團隊的命中率、處置時間與涵蓋缺口時，制裁篩選就不再是一個黑箱，而會成為一項可以持續改善的控制措施。這不僅讓稽核更容易進行，也讓管理層更清楚看見計畫哪裡強健、哪裡正在流失風險。

關鍵要點與實務檢查清單

最重要的教訓是，制裁篩選首先是一個資料完整性問題，其次才是比對問題。如果輸入資料雜亂、名單來源過時，或所有權鏈不完整，即使是強大的引擎也會力不從心。門檻設定、識別資訊與治理機制，遠比原始警示數量更為重要。

請將這份檢查清單當作一組實際行動，而非政策備忘錄來使用：

1. 將資料導入視為一項控管措施。驗證姓名、地址、身分證號碼與所有權資料是否從各來源系統完整送達。
2. 依你的客戶組合調整閾值。在客群變動後重新測試,而非依賴供應商預設值。
3. 以次要識別資訊強化比對。將出生日期、國籍與身分證號碼納入審查邏輯。
4. 在開戶與付款時都要進行篩查。不要假設一次檢查就能涵蓋整個生命週期。
5. 涵蓋間接持股。記錄你如何套用50%規則及相關持股邏輯。
6. 及時更新名單。讓名單採用頻率與你的營運風險及更新週期相符。
7. 追蹤誤報處理時間。審查週期緩慢不只是營運問題,更是控管問題。
8. 保存稽核證據。為每個案件保存判斷邏輯、資料點與最終處置結果。
9. 測試音譯路徑。在驗證樣本中納入阿拉伯文-拉丁文及其他姓名變體。
10. 檢視名單涵蓋範圍的缺口。檢查是否有單一制裁體系或單一資料來源家族造成盲點。
11. 指派控管負責人。指定業務負責人,而不只是技術負責人。
12. 變動後重新測試。任何新名單、新欄位或客群變動都應觸發控管審查。

制裁篩查常見問題

觀察名單應多久更新一次?依你的營運風險需求而定,但簡報中經過驗證的資料顯示,主要商業資料庫現在每天更新多次,LexisNexis 表示來源發布後 24 小時內每天最多更新四次(LexisNexis WorldCompliance Data)。如果資料饋送更新失敗,應暫停受影響的篩查相依項目、記錄事件,並套用你已記載的備援機制,以證明沒有盲目使用過時的資料饋送。

如何在不過度配適的情況下驗證模糊比對閾值?使用一組已標記的驗證資料集,其中應包含完全相符項目、音譯變體、間距變體以及真陰性案例,並在名單或客戶群變動後重新測試。不要只針對舊有的審查佇列進行調校,因為這可能讓模型在歷史案件上看起來表現良好,卻遺漏了新的模式。

所有權篩查如何處理 50% 以上的合計閾值?在 OFAC 模型中,關鍵測試在於是否有一個或多個受列管人士合計直接或間接持有50% 以上的股權(OFAC FAQ)。這意味著你需要的是所有權資料,而不只是姓名資料,而且你需要一種方法來追蹤透過子公司與關聯實體所產生的間接風險暴露。

交易篩查與客戶篩查有什麼不同？客戶篩查是在建立關係時以及生命週期變動期間，檢查該關係本身。交易篩查則是檢查付款、電匯或交易事件本身，因此能夠捕捉到帳戶開立之後才出現的風險。

監管機構期望看到哪些稽核證據？他們通常會要求規則集、資料輸入、處置紀錄、門檻設定的依據，以及證明你已依風險排程對控管措施進行過測試。如果你無法說明某項警示是如何被處理的，這項控管措施就很難站得住腳。

名稱比對結果應在什麼情況下升級處理，什麼情況下可以自動清除？只有在次要識別資訊與你所記載的政策都支持該結論時，才可以自動清除。如果識別資訊不完整、互相矛盾或品質不佳，就應將該案件升級處理，並保留決策紀錄。

制裁篩查若被當作一項持續運作的控管機制，而非靜態的過濾器，效果最好。ELECTE 協助團隊將警示資料、所有權證據與審查結果，轉化為清楚的分析結果，以支援測試與治理工作。如果你想以更可衡量的方式管理合規作業，歡迎造訪 ELECTE，了解這個平台如何協助你將雜亂的控管資料，轉化為經得起檢驗的決策。