AML 4 — Sàng lọc cấm vận, PEP & watchlist

13 thg 7, 2026 2 lượt xem

#banking

#aml

#pep

#sanctions

#screening

#watchlist

Sàng lọc cấm vận, PEP & watchlist

Bài gian lận & sàng lọc cấm vận trong thanh toán đã giới thiệu ý tưởng: mỗi lệnh chuyển tiền phải chạy qua một lớp kiểm soát hỏi "bên này có được phép giao dịch không?". Bài này phóng to riêng lớp đó — sanctions screening — và mở rộng sang hai họ hàng gần: PEP screening và adverse media screening. Ba thứ này gọi chung là watchlist screening, chạy trên cùng bộ máy khớp tên (name matching engine), nhưng hậu quả và cách xử lý khác nhau:

Cấm vận (sanctions): khớp đúng thì cấm giao dịch — đây là ranh giới đỏ pháp lý, không phải "rủi ro cao" mà là "không được phép".
PEP: khớp đúng thì không cấm, nhưng phải áp dụng thẩm định tăng cường (EDD) — xem KYC/CDD.
Adverse media (tin tiêu cực): không phải danh sách chính thức, mà là tín hiệu rủi ro từ tin tức, đưa vào cân nhắc.

Lớp này khác với giám sát giao dịch (transaction monitoring): monitoring hỏi "hành vi này có bất thường không", còn screening hỏi "bên này là ai — có trong danh sách cấm/theo dõi không". Screening đối chiếu danh tính, monitoring phân tích hành vi.

1. Các danh sách trừng phạt

Sàng lọc cấm vận là việc đối chiếu khách hàng và các bên liên quan với những danh sách trừng phạt (sanctions lists) do chính phủ và tổ chức quốc tế ban hành. Những danh sách quan trọng nhất:

OFAC SDN (Specially Designated Nationals and Blocked Persons List) — do Office of Foreign Assets Control thuộc Bộ Tài chính Mỹ ban hành, ảnh hưởng toàn cầu vì phần lớn giao dịch USD đi qua hệ thống ngân hàng Mỹ (correspondent banking); ngân hàng ở bất kỳ đâu cũng phải sàng lọc theo OFAC nếu muốn giữ quan hệ đại lý USD.
UN Consolidated List — danh sách hợp nhất của Hội đồng Bảo an Liên Hợp Quốc; EU Consolidated List của Liên minh châu Âu; HMT/OFSI (UK) của Anh.
Danh sách nội địa / quốc gia — mỗi nước có danh sách riêng. Tại Việt Nam, Luật Phòng, chống rửa tiền yêu cầu tổ chức tài chính đối chiếu với danh sách theo các nghị quyết của Hội đồng Bảo an và danh sách do cơ quan có thẩm quyền công bố.

Đối tượng trên danh sách không chỉ là cá nhân: còn có tổ chức/pháp nhân, tàu biển, máy bay, quốc gia/vùng lãnh thổ bị cấm vận toàn diện, và các thực thể liên quan (ví dụ công ty do đối tượng SDN sở hữu trên 50% — "50 Percent Rule" của OFAC — cũng bị coi như bị chỉ định dù không có tên riêng trên danh sách).

Hậu quả pháp lý

Vi phạm cấm vận có thể dẫn tới phạt tiền rất nặng (nhiều vụ lên tới hàng trăm triệu đến hàng tỷ USD), truy tố hình sự, mất quyền thanh toán USD, tổn hại uy tín. Trách nhiệm mang tính strict liability ở nhiều khía cạnh — "không cố ý" không phải lý do bào chữa hoàn toàn. Vì vậy đây là lớp mà ngân hàng không thể chấp nhận bỏ lọt (false negative), và điều đó định hình toàn bộ cách vận hành (chấp nhận nhiều báo động giả để không sót).

Sàng lọc khi nào

Khi onboarding: trước khi mở quan hệ, sàng lọc khách hàng mới, chủ sở hữu hưởng lợi (beneficial owner), người đại diện.
Định kỳ / khi danh sách cập nhật: danh sách thay đổi liên tục; mỗi lần cập nhật phải rà lại toàn bộ khách hàng hiện hữu (rescreening).
Trên từng giao dịch: với lệnh thanh toán, đặc biệt xuyên biên giới qua SWIFT, sàng lọc các bên trong lệnh ngay trong luồng, trước khi tiền đi.

2. Hai loại screening: khách hàng vs giao dịch

Cần tách bạch hai nơi screening xảy ra, vì chúng có ràng buộc thời gian và dữ liệu rất khác nhau.

Customer / name screening — sàng lọc danh sách khách hàng của ngân hàng, chạy khi onboarding và theo lô (batch) định kỳ. Ở đây có nhiều dữ liệu để phân định (ngày sinh, quốc tịch, địa chỉ, giấy tờ) và không có áp lực mili-giây: một hit có thể được điều tra trong nhiều giờ.

Transaction screening — sàng lọc các bên trong một lệnh thanh toán cụ thể: người trả (payer), người nhận (payee), ngân hàng trung gian, và cả các trường văn bản tự do (địa chỉ, mục đích, tên tàu/hàng hóa). Điểm khó:

Phải chạy real-time, chặn trước khi gửi lệnh — với instant payment, cửa sổ chỉ vài trăm mili-giây.
Dữ liệu nghèo và nhiễu hơn (chỉ có tên + một dòng địa chỉ, không có ngày sinh). Dữ liệu càng ít càng khó phân định true/false và càng dễ sinh báo động giả — đây là lý do dữ liệu có cấu trúc giúp screening chính xác hơn, như pay-07 đã nêu.

Hai loại dùng chung engine khớp tên và chung danh sách hợp nhất, nhưng ngưỡng và quy trình xử lý hit được cấu hình riêng.

3. Fuzzy name matching — tại sao không thể khớp chính xác

Nếu chỉ so khớp tên chính xác từng ký tự, kẻ bị cấm vận chỉ cần viết sai một chữ, đảo thứ tự, hay phiên âm khác đi là thoát. Cấm vận vì thế bắt buộc dùng fuzzy matching (khớp mờ) — chấp nhận các biến thể phổ biến:

Bí danh (alias / a.k.a.): danh sách thường ghi kèm nhiều tên gọi khác của cùng một đối tượng; phải khớp với cả bí danh, không chỉ tên chính.
Phiên âm (transliteration): một tên gốc chữ Ả Rập, Nga, Trung, Hàn... khi viết sang chữ Latinh có nhiều cách. Ví dụ kinh điển: "Mohammed" / "Muhammad" / "Mohamad" / "Muhammed" đều từ một tên gốc; "Youssef" / "Yusuf" / "Jusuf".
Thứ tự tên: "IVAN PETROV" vs "PETROV, IVAN" (họ trước hay tên trước tùy quy ước).
Viết tắt / thiếu chữ đệm: "I. Petrov", bỏ patronymic (tên đệm theo cha).
Lỗi chính tả, khoảng trắng, dấu, ký tự đặc biệt.

Các họ thuật toán

Không có thuật toán vạn năng; hệ thống thực tế xếp chồng nhiều lớp:

Edit distance (khoảng cách chỉnh sửa): đếm số thao tác (thêm/xóa/thay ký tự) để biến chuỗi này thành chuỗi kia — Levenshtein. Bắt tốt lỗi chính tả, sai một vài ký tự.
String similarity theo vị trí: Jaro-Winkler — cho điểm cao hơn khi phần đầu chuỗi khớp; rất phổ biến trong screening. OFAC nêu công cụ tra cứu của họ dùng Jaro-Winkler cùng thuật toán phiên âm.
Phonetic (theo phát âm): Soundex (từ 1918) mã hóa tên theo âm để "Smith" và "Smyth" trùng mã; Metaphone / Double Metaphone (Lawrence Philips, 2000) chính xác hơn cho tên đa ngôn ngữ, xử lý cụm phụ âm và chữ câm tốt hơn. Phonetic bắt các biến thể phiên âm mà edit distance bỏ sót.
Token-based: tách tên thành token, so khớp không phụ thuộc thứ tự, và hạ trọng số các token phổ biến (kiểu TF-IDF) để "Nguyễn", "Mohammed", "Smith" không tự động kéo điểm lên cao — giảm báo động giả cho tên thông dụng.

Ngưỡng và đánh đổi

Mỗi so khớp cho ra một điểm tương đồng (thường quy về thang 0–1 hoặc 0–100). Hệ thống có ngưỡng (threshold): trên ngưỡng thì coi là hit / potential match phải xem xét. Thực tế các hệ AML thường đặt ngưỡng Jaro-Winkler trong khoảng ~0.80–0.90 và tinh chỉnh (tuning) theo dữ liệu.

Đây là đánh đổi trung tâm và không thể tối ưu cả hai chiều cùng lúc:

Ngưỡng chặt (cao): ít báo động giả, nhưng dễ bỏ lọt biến thể phiên âm/viết sai — rủi ro không chấp nhận được với cấm vận.
Ngưỡng lỏng (thấp): không bỏ lọt, nhưng tên phổ biến như "John Smith" sẽ khớp với hàng loạt "Joan Smith", "John Smyth" vô hại → báo động giả (false positive) ngập tràn.

Vì cấm vận không cho phép bỏ lọt, thực tế các ngân hàng buộc phải nghiêng về phía nhạy — và chấp nhận tỷ lệ dương tính giả rất cao (đại đa số hit là trùng tên vô hại). Đó là gánh nặng vận hành lớn nhất của lĩnh vực này, và là lý do mục 6 (tuning) tồn tại.

(minh hoạ) Fuzzy matching một lệnh với danh sách cấm vận

Tên trên lệnh thanh toán:   "MOHAMED AL SAYED"
                            (không có ngày sinh trong message)

Đối chiếu mục SDN:
  Tên chính:  "AL-SAYYID, Muhammad"
  Bí danh:    "Mohammad El Sayed", "M. Al Sayed"
  Ngày sinh:  1975-03-xx   |  Quốc tịch: (nước bị cấm vận)

Bước xử lý của engine:
  1. Chuẩn hoá: bỏ dấu gạch, viết hoa, tách token
       Lệnh -> [MOHAMED, AL, SAYED]
       SDN  -> [AL, SAYYID, MUHAMMAD]  + các bí danh
  2. So khớp token không phụ thuộc thứ tự
       MOHAMED ~ MUHAMMAD  (phonetic Double Metaphone: khớp)
       SAYED   ~ SAYYID    (Jaro-Winkler = 0.94)
       AL      = AL        (token phổ biến -> trọng số thấp)
  3. Điểm tổng hợp (đã hạ trọng số token phổ biến) = 0.91
  4. Ngưỡng cấu hình = 0.85   ->   0.91 > 0.85   ->   HIT

Kết quả:  POTENTIAL MATCH  ->  HOLD lệnh  ->  chuyển điều tra thủ công
Ghi chú:  message thiếu ngày sinh/quốc tịch -> khó tự phân định,
          bắt buộc phải điều tra người thật (mục 5).

4. PEP screening & adverse media

Ngoài cấm vận, cùng engine khớp tên còn phục vụ hai loại sàng lọc khác — nhưng hệ quả nhẹ hơn.

PEP screening. PEP (Politically Exposed Person) là người có ảnh hưởng chính trị: quan chức cấp cao, người thân, và cộng sự thân cận (RCA). PEP không bị cấm giao dịch — điểm này rất hay bị nhầm với cấm vận. Nhưng PEP bị coi là rủi ro cao hơn về tham nhũng/rửa tiền, nên khi khớp PEP, ngân hàng áp dụng thẩm định tăng cường (EDD) — xem KYC/CDD & PEP — chứ không chặn. PEP có tính động cao: một người có thể trở thành PEP sau khi được bổ nhiệm, nên danh sách PEP cần rà lại định kỳ.

Adverse media / negative news screening. Không phải danh sách chính thức, mà là việc quét tin tức tiêu cực về khách hàng: tham nhũng, gian lận, rửa tiền, tài trợ khủng bố, né cấm vận, tội phạm... Adverse media là tín hiệu rủi ro sớm — một đối tượng có thể bị báo chí nêu tên trước khi (hoặc mà không bao giờ) xuất hiện trên danh sách cấm vận. Kết quả thường được đưa vào hồ sơ rủi ro tổng thể để cân nhắc EDD hoặc điều tra, chứ không tự động chặn. Thách thức là nhiễu rất lớn (trùng tên, tin cũ, tin không liên quan) nên cần lọc theo mức độ liên quan và độ tin cậy nguồn.

Ba loại này có thể tóm gọn theo hệ quả: sanctions → chặn; PEP → EDD (theo dõi tăng cường); adverse media → tín hiệu để cân nhắc.

5. Sơ đồ: một lệnh/khách hàng đi qua screening

Với transaction screening, toàn bộ nhánh "no hit → PASS" phải xong trong mili-giây; chỉ các lệnh dính hit mới rơi vào nhánh HOLD chậm. Với customer screening batch, không có áp lực thời gian thực nhưng khối lượng hit cần điều tra rất lớn.

6. Real-time vs batch

Real-time (đồng bộ, chặn/hold). Dùng cho giao dịch — lệnh phải được sàng lọc và cho quyết định trước khi tiền đi. Nếu hit, lệnh bị hold ngay, không đi tiếp tự động. Ràng buộc: độ trễ thấp (mili-giây), không được làm nghẽn luồng thanh toán.

Batch (theo lô, định kỳ). Dùng cho rà soát danh mục khách hàng hiện hữu, hai tình huống: chạy lại toàn bộ theo lịch (hằng đêm/hằng tuần); và quan trọng nhất — khi danh sách cập nhật (list updated → rescreen): mỗi lần OFAC/UN/EU hoặc watchlist nội bộ đổi, ngân hàng phải rà lại toàn bộ khách hàng hiện hữu với danh sách mới, vì một khách hàng "sạch" hôm qua có thể bị chỉ định hôm nay. Đây là lý do screening không phải việc một lần khi onboarding mà là quá trình liên tục (ongoing monitoring).

Thực tế cả hai chạy song song: real-time bảo vệ từng lệnh, batch bảo đảm không khách hàng nào "trôi" qua khe hở khi danh sách thay đổi.

7. Xử lý hit & false positive

Khi có hit, không bao giờ tự động cho qua và cũng không tự động chặn — mà đi vào quy trình xử lý có kiểm soát:

Hold — giữ lệnh/đánh dấu khách hàng, dừng luồng tự động.
Điều tra (disposition): nhân viên compliance trả lời câu hỏi cốt lõi — đây có đúng là đối tượng trên danh sách, hay chỉ trùng tên? Công cụ phân định là dữ liệu bổ sung: ngày sinh, quốc tịch, địa chỉ, số giấy tờ, mã số doanh nghiệp. Càng nhiều dữ liệu phân biệt, càng dễ loại trừ false positive — đây là lý do transaction screening (dữ liệu nghèo) khó hơn customer screening.
Kết luận:
- False positive → giải phóng (release) lệnh; ghi hồ sơ; cân nhắc thêm vào whitelist để lần sau không hit lặp lại.
- Cần thêm thẩm định (ví dụ khớp PEP) → leo thang / EDD.
- True match cấm vận → block/reject, không release, và báo cáo cho cơ quan có thẩm quyền theo quy định (đồng thời cân nhắc báo cáo giao dịch đáng ngờ - STR).

Whitelist / good-guy list. Với các cặp (khách hàng ↔ mục danh sách) đã được điều tra và xác minh là an toàn, ngân hàng lưu vào whitelist để không sinh lại cùng một alert mỗi lần khách hàng đó giao dịch. Đây là công cụ giảm tải chính, nhưng phải quản lý cẩn thận: whitelist cũng cần rà lại khi danh sách hoặc thông tin thay đổi (một mục whitelist cũ có thể trở nên sai nếu bản chất rủi ro đổi).

Gánh nặng dương tính giả. Trong sanctions screening, tỷ lệ false positive thường rất cao — đại đa số hit là trùng tên vô hại. Hệ quả: đội compliance ngập việc, chi phí lớn; giao dịch bị chậm, STP (straight-through processing) tụt; và tinh vi hơn — quá nhiều báo động giả gây mệt mỏi cảnh báo (alert fatigue), tăng rủi ro bỏ sót một hit thật giữa đống nhiễu.

Tuning. Vì thế phải liên tục tinh chỉnh: điều chỉnh ngưỡng theo phân tầng rủi ro (rủi ro cao siết chặt, rủi ro thấp cho qua nhanh), thêm quy tắc phân định bằng ngày sinh/quốc tịch, hạ trọng số token phổ biến, và dùng feedback từ kết quả điều tra (nhãn true/false) — kể cả bằng mô hình học máy. Mục tiêu: giữ độ nhạy đủ để không bỏ lọt, đồng thời cắt bớt false positive.

8. Vận hành

Vài yêu cầu vận hành xuyên suốt, gắn chặt với dữ liệu & công nghệ AML:

Danh sách hợp nhất & cập nhật: gom OFAC/UN/EU/HMT + nội địa + watchlist nội bộ thành một nguồn thống nhất, cập nhật tự động và kịp thời (danh sách trễ = rủi ro bỏ lọt), biết chính xác đang dùng phiên bản nào tại thời điểm nào.
Audit trail: mọi quyết định (hit, kết luận false positive, release, block, thêm whitelist) phải được ghi lại — ai làm, khi nào, dựa trên bằng chứng gì. Cơ quan quản lý kiểm tra không chỉ "có chặn đúng không" mà cả "quy trình ra quyết định có chặt chẽ và tái lập được không".
Chất lượng dữ liệu: cả dữ liệu khách hàng (ngày sinh/quốc tịch để phân định) lẫn dữ liệu danh sách (alias/định danh đầy đủ) quyết định trực tiếp chất lượng screening.
Công cụ: thường mua từ nhà cung cấp chuyên dụng; ngân hàng chịu trách nhiệm cấu hình ngưỡng, tuning và quy trình xử lý hit — công cụ chỉ là một phần.

Use case thực tế

Một lệnh bị hit do trùng tên PEP. Một doanh nghiệp trong nước chuyển tiền cho đối tác nước ngoài; người nhận có tên gần giống một PEP trong danh sách theo dõi. Transaction screening khớp mờ (điểm 0.89 > ngưỡng 0.85) và message thiếu ngày sinh → HIT → HOLD. Lệnh dừng, sinh alert cho đội compliance.

Điều tra: đối chiếu dữ liệu bổ sung — người nhận là chủ doanh nghiệp ở nước A, có mã số doanh nghiệp và địa chỉ rõ; PEP trong danh sách là quan chức ở nước B, khác quốc tịch và lĩnh vực.
Kết luận false positive — chỉ trùng tên. Lưu ý: nếu đúng là PEP thật thì cũng không chặn (chuyển sang EDD/CDD); chỉ khi là đối tượng cấm vận mới block.
Giải phóng (release) lệnh; ghi đầy đủ audit trail (bằng chứng, người quyết định, thời điểm).
Thêm cặp này vào whitelist để lần sau không hit lặp lại — giảm tải cho đội điều tra.
Nếu bước 2 xác nhận true match cấm vận → block/reject, báo cáo cơ quan có thẩm quyền và cân nhắc STR.

Điểm rút ra: vì message thiếu ngày sinh, engine buộc phải nghiêng về nhạy và sinh hit; phần "cứu" nằm ở điều tra bằng dữ liệu bổ sung và whitelist.

Ghi nhớ

Sanctions ≠ PEP ≠ adverse media. Cấm vận khớp đúng → chặn (ranh giới đỏ pháp lý). PEP khớp đúng → không chặn, áp dụng EDD. Adverse media → tín hiệu rủi ro để cân nhắc.
Screening đối chiếu danh tính; transaction monitoring phân tích hành vi — hai lớp khác nhau, bổ sung nhau.
Các danh sách: OFAC SDN (ảnh hưởng toàn cầu qua USD), UN, EU, HMT/UK, nội địa; cả tổ chức/tàu/thực thể liên quan (50% rule). Vi phạm bị phạt rất nặng → không được bỏ lọt.
Fuzzy matching là bắt buộc: bí danh, phiên âm (transliteration), đảo thứ tự, viết tắt, lỗi chính tả. Kết hợp edit distance (Levenshtein), string similarity (Jaro-Winkler), phonetic (Soundex/Metaphone), token-based + ngưỡng.
Đánh đổi độ nhạy vs false positive không thể tối ưu cả hai; cấm vận nghiêng về nhạy → dương tính giả rất cao là gánh nặng vận hành → phải tuning.
Real-time cho giao dịch (chặn/hold trước khi gửi); batch cho rà soát định kỳ và đặc biệt khi danh sách cập nhật → rescreen toàn bộ.
Hit → hold → điều tra (đúng người hay trùng tên, dùng ngày sinh/quốc tịch/địa chỉ) → release / leo thang-EDD / block+báo cáo; whitelist để không hit lặp lại.
Vận hành: danh sách hợp nhất & cập nhật kịp thời, audit trail mọi quyết định, chất lượng dữ liệu quyết định chất lượng screening.