Gian lận, sàng lọc AML & cấm vận

Các bài trước của series đã nói về việc tiền đi từ A đến B như thế nào: qua SWIFT cho xuyên biên giới, qua instant payment và QR cho nội địa tức thời, đóng gói trong message chuẩn ISO 20022. Bài này nói về một câu hỏi khác, chạy song song với mọi lệnh chuyển tiền: lệnh này có được phép đi không, và có phải là gian lận không?

Đây là lớp kiểm soát rủi ro. Nó vừa là nghĩa vụ pháp lý (ngân hàng có thể bị phạt hàng tỷ USD nếu để lọt tiền cho bên bị cấm vận), vừa là bảo vệ khách hàng (chặn kẻ gian rút sạch tài khoản). Điểm khó là lớp kiểm soát này phải chen vào giữa luồng thanh toán — mà luồng đó ngày càng nhanh, đặc biệt với instant payment gần như không có cửa sổ hoàn tác.

Bài viết đi qua bốn khối: sàng lọc cấm vận, AML trong thanh toán, chống gian lận (fraud), và bảo mật hạ tầng SWIFT (CSP); kết bằng bài toán đánh đổi false positive/false negative và vai trò của dữ liệu/ML.

1. Sanctions screening — sàng lọc cấm vận

Vấn đề

Nhiều quốc gia và tổ chức duy trì danh sách cấm vận (sanctions lists): cá nhân, tổ chức, tàu biển, quốc gia mà ngân hàng không được phép giao dịch. Những danh sách phổ biến nhất:

• OFAC SDN (Specially Designated Nationals) — do Bộ Tài chính Mỹ (OFAC) công bố. Có ảnh hưởng toàn cầu vì hầu hết giao dịch USD đi qua hệ thống ngân hàng Mỹ.
• 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.
• Danh sách nội địa — mỗi nước có danh sách riêng theo quy định trong nước.

Khi một lệnh thanh toán chạy qua ngân hàng, ngân hàng phải đối chiếu tất cả các bên liên quan với những danh sách này: người trả tiền (payer), người nhận (payee), ngân hàng trung gian, thậm chí địa chỉ, quốc gia, và tên tàu/hàng hóa nếu có trong nội dung.

Fuzzy matching — vì sao không thể so khớp chính xác

Nếu chỉ so khớp tên chính xác, kẻ bị cấm vận chỉ cần viết sai chính tả một chữ là thoát. Vì vậy sàng lọc dùng fuzzy matching (khớp mờ), xử lý các biến thể:

• Transliteration: một tên tiếng Ả Rập, Nga, Trung có thể phiên âm ra Latin theo nhiều cách khác nhau (ví dụ "Mohammed" / "Muhammad" / "Mohamad").
• Alias / bí danh: danh sách thường ghi kèm các tên gọi khác của cùng một đối tượng.
• Thứ tự tên, viết tắt, thiếu chữ đệm, khoảng trắng, dấu.

(minh hoạ) Quy tắc khớp tên trong sanctions screening

Tên trên lệnh:      "IVAN PETROV"
Đối chiếu danh sách: "PETROV, IVAN IVANOVICH"  (SDN, alias: "I. PETROV")

Bước xử lý:
  - Chuẩn hoá: bỏ dấu, viết hoa, tách token -> [IVAN, PETROV]
  - So khớp không phụ thuộc thứ tự -> khớp 2/3 token của mục danh sách
  - Điểm tương đồng (Jaro-Winkler/Levenshtein) trung bình = 0.92
  - Ngưỡng cấu hình = 0.85  ->  HIT (nghi ngờ)

Kết quả: đánh dấu POTENTIAL MATCH -> chuyển hold để điều tra thủ công

Hit thì làm gì

Khi có hit (nghi trùng), lệnh không đi tiếp tự động. Nó bị hold (giữ lại) và chuyển cho bộ phận điều tra. Nhân viên compliance xem xét: đây có đúng là đối tượng bị cấm vận, hay chỉ là người trùng tên (false positive)? Chỉ khi loại trừ được rủi ro, lệnh mới được release; nếu xác nhận là true match, lệnh bị reject/block và có thể phải báo cáo cho cơ quan quản lý.

Ngân hàng cũng duy trì watchlist nội bộ riêng (khách hàng rủi ro cao, đối tượng đang theo dõi) chồng lên các danh sách chính thức.

Screening cả message — ISO 20022 giúp gì

Chất lượng screening phụ thuộc vào chất lượng dữ liệu trong message. Message thanh toán cũ (như MT của SWIFT) nhồi nhiều thông tin vào các trường văn bản tự do → khó tách "tên người nhận" khỏi "địa chỉ" một cách máy móc → nhiều nhiễu.

ISO 20022 có cấu trúc trường rõ ràng (structured data): tên, địa chỉ, quốc gia, mã định danh của từng bên nằm ở đúng trường riêng. Nhờ đó bộ máy screening biết chính xác nên đối chiếu cái gì với danh sách nào, giảm nhiễu và giảm false positive. Đây là một trong những lợi ích lớn nhất của việc chuyển sang ISO 20022 mà bài chuyên đề về chuẩn message đã nêu.

PEP screening

Song song với cấm vận là PEP screening — sàng lọc Politically Exposed Persons (cá nhân có ảnh hưởng chính trị: quan chức cấp cao, người thân, cộng sự thân cận). PEP không bị cấm giao dịch, nhưng 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) thay vì chặn.

2. AML trong thanh toán

AML (Anti-Money Laundering) hỏi một câu khác với sanctions: không phải "bên này có bị cấm không" mà "dòng tiền này có phải tiền bẩn đang được rửa không". Chi tiết tổng quan về khung AML/KYC nằm ở bài AML & tuân thủ; ở đây ta tập trung vào khía cạnh gắn với luồng thanh toán.

Transaction monitoring

Ngân hàng giám sát giao dịch theo các ngưỡng và kịch bản (scenarios) để phát hiện hành vi bất thường:

• Structuring / smurfing: chia nhỏ một khoản tiền lớn thành nhiều giao dịch dưới ngưỡng báo cáo để né kiểm soát.
• Luồng bất thường: tiền vào rồi ra ngay (pass-through), nhiều tài khoản đổ về một điểm rồi chuyển đi (funnel), giao dịch không phù hợp hồ sơ khách hàng (một tài khoản cá nhân bỗng nhận hàng tỷ đồng).
• Vòng quay nhanh, nhiều nước, nhiều tài khoản trung gian.

(minh hoạ) Kịch bản structuring

Khách hàng A, hồ sơ: cá nhân, thu nhập khai báo ~30 triệu/tháng.
Ngưỡng báo cáo giao dịch tiền mặt lớn = 400 triệu.

Trong 3 ngày:
  Nộp tiền mặt 390 triệu  (dưới ngưỡng)
  Nộp tiền mặt 380 triệu  (dưới ngưỡng)
  Nộp tiền mặt 395 triệu  (dưới ngưỡng)
  Ngay sau đó chuyển toàn bộ ra 1 tài khoản ở nước ngoài.

Cảnh báo:
  - Mỗi lần đều sát-dưới ngưỡng (structuring pattern)
  - Tổng cộng vượt xa hồ sơ thu nhập
  -> sinh alert -> điều tra -> cân nhắc lập STR/SAR

STR / SAR

Khi nghi ngờ, ngân hàng lập STR (Suspicious Transaction Report) hoặc SAR (Suspicious Activity Report) gửi cơ quan phòng chống rửa tiền (ở Việt Nam là Cục Phòng, chống rửa tiền thuộc NHNN). Đây là nghĩa vụ báo cáo, và về nguyên tắc ngân hàng không được "tipping off" — không báo cho khách hàng biết mình đang bị báo cáo.

KYC/CDD và Travel Rule

Giám sát giao dịch chỉ có ý nghĩa khi ngân hàng biết khách hàng là ai — đó là KYC (Know Your Customer) và CDD (Customer Due Diligence), làm ngay từ khi mở tài khoản và cập nhật định kỳ. Với khách rủi ro cao (gồm PEP) thì áp dụng EDD (Enhanced Due Diligence).

Travel Rule yêu cầu khi chuyển tiền vượt ngưỡng, thông tin định danh của người gửi và người nhận phải "đi cùng" lệnh chuyển từ đầu đến cuối — để mỗi ngân hàng trên đường đều có đủ dữ liệu để screening. Đây chính là lý do vì sao dữ liệu các bên trong message (ISO 20022) phải đầy đủ và chuẩn hóa.

3. Payment fraud — gian lận thanh toán

Fraud khác AML ở chỗ nào

Đây là điểm hay nhầm:

• AML: nguồn tiền là tiền bẩn (tội phạm dùng hệ thống để rửa tiền của chính chúng). Nạn nhân là "xã hội / hệ thống tài chính".
• Fraud: kẻ gian lấy tiền của người khác. Có một nạn nhân cụ thể bị thiệt hại.

Một giao dịch có thể vừa là fraud vừa dính AML, nhưng công cụ và mục tiêu kiểm soát khác nhau: fraud tập trung vào bảo vệ nạn nhân và chặn kịp thời, AML tập trung vào phát hiện và báo cáo dòng tiền bẩn.

Các loại gian lận chính

• Account takeover (ATO): kẻ gian chiếm quyền truy cập tài khoản nạn nhân (đánh cắp mật khẩu, OTP, SIM swap) rồi tự thực hiện giao dịch.
• BEC (Business Email Compromise): giả mạo email lãnh đạo/nhà cung cấp để lừa nhân viên chuyển tiền tới tài khoản kẻ gian, hoặc đổi số tài khoản trên hóa đơn.
• APP fraud (Authorised Push Payment): loại nguy hiểm và đang bùng nổ — chính nạn nhân tự tay bấm chuyển tiền, vì bị lừa (giả danh công an, giả danh ngân hàng, lừa đầu tư, lừa tình). Vì giao dịch được khách hàng ủy quyền hợp lệ, các cơ chế chống gian lận truyền thống (dựa trên "giao dịch có phải do đúng chủ tài khoản thực hiện không") không bắt được.

APP fraud đặc biệt độc hại với instant payment: tiền đi trong vài giây và gần như không có cửa sổ hoàn tác. Khi nạn nhân nhận ra mình bị lừa, tiền đã rời tài khoản và thường đã được kẻ gian rút/chuyển tiếp qua nhiều tài khoản mule. Đây là lý do các cơ quan quản lý ngày càng đẩy trách nhiệm hoàn tiền APP fraud về phía ngân hàng, tạo áp lực phải phát hiện ngay trong luồng.

Real-time fraud scoring

Vì không thể rà soát sau, ngân hàng chấm điểm rủi ro từng giao dịch trong vài trăm mili-giây, dựa trên:

• Device / behaviour: thiết bị lạ, vị trí bất thường, cách gõ/thao tác khác thường (behavioural biometrics), giao dịch lúc 3 giờ sáng.
• Bối cảnh giao dịch: người nhận mới (chưa từng chuyển), số tiền lớn bất thường, ngay sau một cuộc gọi/đăng nhập đáng ngờ.
• Rules + ML: kết hợp luật cứng (dễ hiểu, dễ giải trình, ví dụ "chặn nếu chuyển > X tới người nhận mới trong 5 phút sau khi đổi mật khẩu") với mô hình học máy (bắt các mẫu tinh vi mà luật cứng bỏ sót). Xem thêm góc nhìn thẻ ở Bảo mật & gian lận thẻ.

Với các dấu hiệu APP fraud, xu hướng mới là can thiệp vào hành vi: hiển thị cảnh báo động ("Bạn có chắc không quen người này? Đây có thể là lừa đảo giả danh công an?"), làm chậm giao dịch rủi ro cao, hoặc yêu cầu xác nhận thêm — vì với APP fraud, không thể chặn bằng xác thực (khách hàng thật đang tự bấm), chỉ có thể cảnh tỉnh khách hàng.

4. SWIFT CSP — bảo mật hạ tầng SWIFT

Sau vụ tấn công Bangladesh Bank (2016) — kẻ tấn công xâm nhập hệ thống nội bộ, gửi lệnh SWIFT giả và rút ~81 triệu USD — SWIFT triển khai CSP (Customer Security Programme).

Điểm cốt lõi: SWIFT mạng lõi thì an toàn, nhưng điểm yếu nằm ở phía người dùng — máy chủ, workstation, quy trình vận hành của chính ngân hàng. CSP đặt ra CSCF (Customer Security Controls Framework): một bộ controls bắt buộc và khuyến nghị, gồm những nguyên tắc như:

• Cô lập môi trường SWIFT khỏi mạng chung, giảm bề mặt tấn công.
• Kiểm soát truy cập chặt (least privilege, multi-factor), quản lý danh tính.
• Phát hiện & ứng phó (logging, giám sát bất thường, xử lý sự cố).

Hằng năm, các thành viên phải tự đánh giá (attestation) mức tuân thủ với bộ controls và có cơ chế kiểm chứng độc lập. Đây là lời nhắc rằng an ninh thanh toán không chỉ là thuật toán screening, mà còn là bảo vệ chính hạ tầng phát lệnh.

5. Sơ đồ: một lệnh đi qua các lớp kiểm soát

Ba lớp — sanctions → AML → fraud — chạy trong cùng luồng, và với instant payment thì gần như phải chạy đồng thời, dưới một giây.

6. Đánh đổi false positive vs false negative

Đây là bài toán trung tâm của cả lĩnh vực:

• False positive (báo động giả): lệnh sạch bị đánh dấu hit. Quá nhiều FP → STP (straight-through processing) tụt, giao dịch bị chậm, đội compliance ngập việc, khách hàng khó chịu. Tỷ lệ FP trong sanctions screening truyền thống thường rất cao (đại đa số hit là trùng tên vô hại).
• False negative (bỏ lọt): một true match lọt qua. Hệ quả có thể là phạt hàng trăm triệu đến hàng tỷ USD, mất giấy phép, tổn hại uy tín — rủi ro không thể chấp nhận.

Không có cấu hình nào tối ưu cả hai cùng lúc: siết ngưỡng để không bỏ lọt thì FP tăng vọt; nới để giảm FP thì rủi ro bỏ lọt tăng. Các kỹ thuật cân bằng:

• Tuning ngưỡng theo dữ liệu thực (điểm tương đồng, cửa sổ thời gian, số tiền).
• Phân tầng (risk-based / segmentation): khách hàng/luồng rủi ro cao thì siết chặt, luồng rủi ro thấp thì cho qua nhanh — dồn nguồn lực điều tra vào nơi rủi ro nhất.
• Danh sách loại trừ (whitelist) cho các cặp đã xác minh là an toàn để không hit lặp lại.

7. Vai trò dữ liệu & ML

Lớp kiểm soát này về bản chất là một bài toán dữ liệu thời gian thực, gắn chặt với các chủ đề AI/streaming của KB:

• Feature real-time: đặc trưng được tính ngay trong luồng (tần suất giao dịch tới người nhận này trong 1 giờ qua, độ lệch so với hành vi thường ngày, số thiết bị mới trong 24h).
• Feedback loop: kết quả điều tra (đây là fraud thật / là FP) được đưa ngược lại để huấn luyện lại mô hình — chất lượng nhãn quyết định chất lượng mô hình.
• Giám sát drift: hành vi kẻ gian và hành vi khách hàng đều thay đổi; mô hình phải được giám sát drift và tái huấn luyện, nếu không hiệu năng sẽ suy giảm âm thầm.
• Explainability: vì quyết định chặn/hold có hệ quả pháp lý và ảnh hưởng khách hàng, mô hình phải giải trình được — đây là lý do rules cứng vẫn tồn tại song song với ML.

Use case thực tế

Tình huống 1 — hit sanctions do trùng tên. Một doanh nghiệp Việt Nam chuyển USD trả nhà cung cấp, người nhận tên "Ali Hassan". Bộ máy screening khớp mờ với một mục trong OFAC SDN cũng tên "Ali Hassan" (điểm tương đồng 0.90 > ngưỡng 0.85) → HIT → HOLD. Lệnh dừng, chuyển đội compliance.

Quy trình xử lý:

1. Đối chiếu thông tin bổ sung: quốc gia (nhà cung cấp ở Singapore, đối tượng SDN ở Trung Đông), ngày sinh, mã số doanh nghiệp, địa chỉ.
2. Kết luận false positive — chỉ trùng tên, không cùng đối tượng.
3. Release lệnh, lưu hồ sơ điều tra (audit trail), và thêm cặp này vào whitelist để lần sau không hit lặp lại (rút ngắn thời gian xử lý).
4. Nếu ngược lại xác nhận đúng đối tượng SDN → reject/block, không release, báo cáo theo quy định.

Tình huống 2 — chặn APP fraud tức thời. Một khách hàng cá nhân, ngay sau một cuộc gọi lạ, đăng nhập từ thiết bị quen nhưng lập tức chuyển một khoản lớn tới người nhận mới qua kênh tức thời. Real-time fraud scoring bắt cụm dấu hiệu: người nhận mới + số tiền lệch mạnh so với thói quen + thời điểm bất thường. Vì đây là APP fraud (khách hàng tự bấm, xác thực hợp lệ), hệ thống không chặn thẳng mà step-up: hiện cảnh báo lừa đảo giả danh, làm chậm giao dịch, yêu cầu xác nhận lại. Khách hàng dừng lại, nhận ra bị lừa, hủy giao dịch — chặn được thiệt hại trước khi tiền rời tài khoản (điều gần như không cứu vãn được nếu tiền đã đi).

Ghi nhớ

• Sanctions ≠ AML ≠ fraud. Sanctions: có được phép giao dịch với bên này không. AML: đây có phải tiền bẩn không. Fraud: có nạn nhân bị kẻ gian lấy tiền không.
• Fuzzy matching là bắt buộc trong sanctions screening (transliteration, alias) — nhưng đổi lại sinh nhiều false positive; hit thì hold & điều tra, không tự động cho qua.
• ISO 20022 dữ liệu có cấu trúc giúp screening chính xác hơn và giảm nhiễu; Travel Rule bắt thông tin các bên phải đi kèm lệnh.
• APP fraud là mối nguy lớn nhất với instant payment vì khách hàng tự ủy quyền và không có cửa sổ hoàn tác — chống bằng cảnh báo/làm chậm, không phải bằng xác thực.
• SWIFT CSP ra đời sau vụ Bangladesh Bank: điểm yếu ở phía người dùng, cần controls + attestation hằng năm.
• Không tồn tại cấu hình hoàn hảo: siết thì FP tăng (chậm STP, tốn người), nới thì bỏ lọt (rủi ro phạt) — cân bằng bằng tuning ngưỡng và phân tầng rủi ro.
• Đây là bài toán dữ liệu real-time: feature trực tuyến, feedback loop, giám sát drift và explainability quyết định hiệu quả thực tế.

Đọc thêm: SWIFT & thanh toán xuyên biên giới · Thanh toán tức thời & QR · ISO 20022 · Bảo mật & gian lận thẻ · AML & tuân thủ