AML 3 — Giám sát giao dịch & phát hiện bất thường

Ở bài Tổng quan AML chúng ta đã thấy phòng chống rửa tiền là một chuỗi các lớp phòng thủ, và ở bài KYC/CDD chúng ta xây dựng hồ sơ khách hàng cùng kỳ vọng về hành vi của họ. Nhưng biết khách hàng là ai mới chỉ là một nửa câu chuyện. Nửa còn lại — thường là phần khó nhất và tốn nguồn lực nhất — là giám sát giao dịch (transaction monitoring): liên tục quan sát dòng tiền thực tế chảy qua tài khoản và tự hỏi câu hỏi cốt lõi: "Hành vi này có phù hợp với những gì ta kỳ vọng ở khách hàng này không?"

Bài viết đi sâu vào cách ngân hàng phát hiện bất thường: các kịch bản rửa tiền điển hình (typology), hai trường phái phát hiện (luật ngưỡng và học máy), vòng đời cảnh báo, bài toán dương tính giả, kèm ví dụ SQL chạy được trên sandbox.

Vì sao phải giám sát giao dịch

KYC cho ta bức chân dung tĩnh: nghề nghiệp, thu nhập, mục đích mở tài khoản, nguồn tiền dự kiến. Từ đó hình thành kỳ vọng hành vi — ví dụ tài khoản lương nhân viên văn phòng nên nhận ~15–25 triệu/tháng, chi cho tiêu dùng, thi thoảng chuyển khoản. Giám sát giao dịch là so hành vi thực tế với kỳ vọng đó và với chính lịch sử tài khoản để phát hiện lệch chuẩn.

Điểm quan trọng: kẻ rửa tiền hầu như không thực hiện giao dịch "trông giống rửa tiền" một cách lộ liễu, mà che giấu nguồn gốc bất hợp pháp bằng cách làm dòng tiền trông giống hoạt động kinh tế bình thường. Vì vậy phát hiện không dựa vào một giao dịch đơn lẻ mà dựa vào mẫu hình (pattern): tần suất, tổng lượng, thời điểm, đối tác, quan hệ với hồ sơ.

Hai chế độ giám sát chính:

• Hậu kiểm (post-transaction / batch): chạy theo lô, thường hằng ngày sau khi giao dịch hoàn tất. Mô hình truyền thống, đủ cho phần lớn nghiệp vụ AML vì mục tiêu là phát hiện mẫu hình theo thời gian. Có đủ dữ liệu trong ngày để phân tích, nhược điểm là độ trễ (tiền đã đi rồi).
• Thời gian thực (real-time): đánh giá giao dịch trước/trong lúc xử lý, có thể chặn/giữ lại. Bắt buộc với sàng lọc trừng phạt (sanctions screening) và ngày càng cần với thanh toán tức thời/QR, nơi tiền đến đích trong vài giây, không thu hồi được. Real-time cần độ trễ thấp nên luật phải gọn.

Hầu hết ngân hàng vận hành cả hai: real-time cho sàng lọc và các luật velocity đơn giản, hậu kiểm cho các kịch bản phức tạp cần nhìn nhiều ngày.

Typologies — các kịch bản rửa tiền

Typology là mẫu hình, kỹ thuật hoặc "chữ ký hành vi" được ghi nhận mà tội phạm dùng để rửa tiền — như những "kịch bản"/"playbook", mỗi cái mô tả phương thức, kênh tài chính và các dấu hiệu đỏ (red flags) đặc trưng. Các cơ quan như FATF và FinCEN thường xuyên công bố typology để ngành tham chiếu. Dưới đây là những kịch bản phổ biến nhất.

Structuring và Smurfing

Đây là typology kinh điển và quan trọng nhất cần hiểu. Structuring là cố ý chia nhỏ một khoản tiền lớn thành nhiều giao dịch để mỗi cái nằm dưới ngưỡng báo cáo hoặc lưu vết bắt buộc. Định nghĩa pháp lý của FinCEN nêu rõ: một người thực hiện structuring khi tiến hành một hoặc nhiều giao dịch tiền mặt, ở một hoặc nhiều tổ chức, trong một hoặc nhiều ngày, dưới bất kỳ hình thức nào, nhằm mục đích né tránh yêu cầu nộp báo cáo.

Ở Mỹ ngưỡng nổi tiếng nhất là 10.000 USD: giao dịch tiền mặt vượt 10.000 USD trong một ngày làm việc buộc phải nộp Currency Transaction Report (CTR), nên kẻ rửa tiền chia thành nhiều lần gửi 9.000–9.900 USD. Đáng chú ý: chia nhỏ qua nhiều chi nhánh, nhiều ngày, hay nhiều ngân hàng vẫn là structuring bất hợp pháp — tổng thể và ý đồ né tránh mới là điều quan trọng, không phải từng giao dịch.

Smurfing là biến thể dùng nhiều người ("smurf") làm trung gian: mỗi người gửi khoản nhỏ vào nhiều tài khoản. Mỗi giao dịch trông vô hại nhưng gộp lại rửa cả khoản lớn. Thách thức là phân biệt mạng lưới smurfing có phối hợp với hàng loạt giao dịch nhỏ hợp pháp.

Lưu ý: ở Việt Nam ngưỡng và cơ chế báo cáo do pháp luật quy định (Luật Phòng, chống rửa tiền và các văn bản hướng dẫn); con số cụ thể khác Mỹ. Nhưng nguyên lý của structuring — chia nhỏ để né ngưỡng — là phổ quát.

Các typology khác

• Pass-through / luồng vào-ra nhanh (rapid movement): tiền vào tài khoản rồi gần như lập tức được chuyển đi, để lại số dư gần bằng 0. Tài khoản chỉ đóng vai trò "trạm trung chuyển" chứ không phải tài khoản sử dụng thật. Thường đi kèm giao dịch tròn số (round-number) — 50 triệu, 100 triệu — vì tiền bất hợp pháp ít khi có phần lẻ tự nhiên.
• Không phù hợp thu nhập/hồ sơ: dòng tiền vượt xa mức kỳ vọng theo hồ sơ KYC. Một tài khoản sinh viên nhận vào hàng tỷ đồng mỗi tháng là bất thường rõ ràng.
• Giao dịch với vùng rủi ro cao: chuyển tiền đến/từ các quốc gia hoặc khu vực nằm trong danh sách rủi ro cao, thiên đường thuế, hoặc vùng bị trừng phạt.
• Mule accounts (tài khoản trung gian/lừa): tài khoản của người thật (thường bị lừa hoặc thuê lại) được dùng để nhận và chuyển tiếp tiền bẩn. Dấu hiệu: tài khoản mới mở, ít hoạt động rồi đột nhiên có nhiều giao dịch vào-ra, đối tác lạ.
• Trade-based money laundering (TBML): rửa tiền qua thương mại — khai khống/khai thiếu giá trị hàng hóa, hóa đơn giả, chuyển giá trị qua hoạt động xuất nhập khẩu. Rất khó phát hiện vì lẫn trong hoạt động kinh doanh hợp pháp (xem thêm Trade Finance).
• Tăng đột biến (spike): hoạt động của tài khoản nhảy vọt so với đường cơ sở (baseline) của chính nó — số lượng hoặc giá trị giao dịch tăng bất thường mà không có lý do rõ ràng.

Cách phát hiện: luật ngưỡng vs mô hình

Có hai trường phái lớn, và thực tế tốt nhất là kết hợp cả hai.

Rule / threshold-based (dựa trên luật ngưỡng)

Cách tiếp cận truyền thống và vẫn là xương sống của hầu hết hệ thống. Ta định nghĩa các scenario (kịch bản) dạng luật rõ ràng: ngưỡng số tiền (giao dịch/tổng trong ngày vượt X); tần suất (hơn N giao dịch trong khoảng T); velocity (tổng vào và ra lớn trong thời gian ngắn, số dư dao động mạnh); structuring rule (nhiều giao dịch nằm ngay dưới ngưỡng báo cáo).

Ưu điểm: minh bạch, giải thích được (explainable), dễ kiểm toán, cơ quan quản lý chấp nhận — khi luật kích hoạt ta biết chính xác vì sao. Nhược điểm lớn: rất nhiều dương tính giả — luật cứng không phân biệt ngữ cảnh, nên khách hàng bình thường có tháng lương thưởng cao cũng bị bắt.

ML / anomaly detection (mô hình học máy)

Cách tiếp cận hiện đại dùng mô hình học từ dữ liệu để phát hiện những gì lệch khỏi hành vi bình thường mà luật cứng không mô tả được:

• Mô hình hành vi (behavioral profiling): học "bình thường" của từng khách hàng/phân khúc rồi báo động khi sai lệch — bài toán phát hiện bất thường không giám sát, xem sâu ở ML unsupervised & anomaly detection.
• Network/graph analysis: mô hình hóa quan hệ giữa các tài khoản như đồ thị để phát hiện mạng lưới smurfing, cụm chuyển tiền vòng quanh, mule networks — chi tiết ở Dữ liệu & công nghệ AML.
• ML trên chuỗi giao dịch: học các "chữ ký thời gian" (temporal signature) và nhận diện tài khoản khớp mẫu, giảm cả dương tính giả lẫn âm tính giả.

Ưu điểm: bắt mẫu tinh vi, thích nghi typology mới, giảm nhiễu. Nhược điểm: khó giải thích ("hộp đen"), cần dữ liệu chất lượng cao và nhãn — mà nhãn thật (SAR đã xác nhận) lại rất hiếm.

Kết hợp và scenario tuning

Thực tế hàng đầu là hybrid: luật ngưỡng làm lớp lọc thô minh bạch, ML xếp hạng/lọc lại alert để nâng độ chính xác. Mấu chốt là scenario tuning — điều chỉnh liên tục ngưỡng và tham số theo hiệu quả thực tế. Ngưỡng quá thấp → ngập alert; quá cao → bỏ lọt. Đây là vòng lặp không bao giờ dừng.

Vòng đời cảnh báo và bài toán dương tính giả

Khi một scenario kích hoạt, nó sinh ra một alert (cảnh báo). Alert không phải là kết luận có tội — nó chỉ là "đáng để xem xét". Vòng đời điển hình:

Các bước:

1. Sinh alert: scenario/ML tạo cảnh báo, kèm dữ liệu ngữ cảnh (giao dịch, hồ sơ, lịch sử).
2. Phân loại & ưu tiên (triage): gộp các alert liên quan, chấm điểm rủi ro để phân tích viên xử lý cái quan trọng trước.
3. Điều tra: phân tích viên xem xét, thu thập thông tin bổ sung, đối chiếu với KYC. Đây là bước đắt nhất vì cần con người.
4. Kết luận:
   • Nếu có cơ sở nghi ngờ → lập Báo cáo giao dịch đáng ngờ (STR/SAR) và/hoặc leo thang. Toàn bộ quy trình này ở bài Báo cáo STR.
   • Nếu không có cơ sở → đóng alert kèm lý do (audit trail).

Dương tính giả — vấn đề trung tâm

Đây là nỗi đau lớn nhất. Hệ thống dựa trên luật cứng có tỷ lệ dương tính giả rất cao — hệ thống cũ có thể lên quanh mức 90–95% alert là "false positive", tức gần như mọi cảnh báo cuối cùng đều vô hại. Hậu quả: lãng phí nguồn lực (đội điều tra ngập alert vô nghĩa, "alert fatigue"); rủi ro bỏ lọt (false negative — nhiễu lớn làm alert thật bị chìm); và phiền khách hàng vô tội bị giữ giao dịch.

Các hướng giảm dương tính giả:

• Tuning ngưỡng dựa trên dữ liệu hiệu quả thực tế.
• Phân khúc khách hàng (segmentation): đặt ngưỡng khác nhau theo nhóm — doanh nghiệp lớn khác cá nhân, tiểu thương khác người làm công. Một ngưỡng chung cho tất cả là nguồn nhiễu chính.
• Giảm nhiễu bằng ML: dùng mô hình xếp hạng lại alert (alert scoring) đẩy alert có khả năng thật lên trên.
• Gộp alert (consolidation): nhiều alert cùng khách hàng nên gộp thành một hồ sơ.

Chỉ số quan trọng nhất là tỷ lệ chuyển đổi alert→SAR: trong 100 alert bao nhiêu dẫn tới báo cáo thật. Tỷ lệ rất thấp là dấu hiệu scenario cần tuning. Nhưng cẩn trọng — tối ưu mù quáng có thể khuyến khích bỏ lọt; mục tiêu là bắt đúng, không phải ít alert.

Dữ liệu cần cho giám sát

Chất lượng giám sát phụ thuộc trực tiếp vào chất lượng và độ đầy đủ của dữ liệu. Các nguồn cốt lõi: dữ liệu giao dịch (số tiền, loại, thời điểm, đối tác, kênh — thường từ core banking); hồ sơ KYC & kỳ vọng hành vi để so thực tế với dự kiến (nối KYC/CDD); điểm rủi ro & dữ liệu bổ trợ như xếp hạng rủi ro, danh sách trừng phạt, dữ liệu graph quan hệ (nối Dữ liệu & công nghệ AML); và hạ tầng real-time cho thanh toán tức thời/QR — luồng dữ liệu độ trễ thấp để đánh giá và có thể chặn kịp thời.

Một thách thức lớn là data silo — dữ liệu giao dịch, KYC, thẻ, ví... rải rác ở nhiều hệ thống, khiến khó có cái nhìn toàn cảnh về một khách hàng.

Ví dụ SQL trên sandbox

Các ví dụ chạy trên PostgreSQL với schema mẫu, mỗi ví dụ là một câu SELECT/WITH. Quan hệ khóa: transactions.account_id → accounts.id, accounts.customer_id → customers.id. Đây là logic MINH HOẠ rất đơn giản — hệ thống thật phức tạp hơn nhiều (nhiều ngày, nhiều chiều, phân khúc, ngữ cảnh KYC, chấm điểm...).

1. Velocity — tài khoản nhiều giao dịch / tổng lớn trong ngày

Ý tưởng: gom giao dịch theo tài khoản và theo ngày; báo động những tài khoản-ngày có quá nhiều giao dịch hoặc tổng giá trị quá lớn. Đây là luật velocity cơ bản.

▶ Chạy được trong SQL Builder

SELECT
    account_id,
    to_char(created_at, 'YYYY-MM-DD') AS ngay,
    COUNT(*)                          AS so_giao_dich,
    SUM(amount)                       AS tong_gia_tri
FROM transactions
GROUP BY account_id, to_char(created_at, 'YYYY-MM-DD')
HAVING COUNT(*) >= 3 OR SUM(amount) >= 100000000
ORDER BY tong_gia_tri DESC;

Điều kiện HAVING COUNT(*) >= 3 OR SUM(amount) >= 100000000 là hai ngưỡng minh hoạ (nhiều giao dịch hoặc tổng lớn). Thực tế các ngưỡng này phải được tuning theo phân khúc khách hàng và so với đường cơ sở của chính tài khoản.

2. Structuring — nhiều giao dịch giá trị gần ngưỡng

Ý tưởng: giả sử ngưỡng báo cáo là 10.000.000. Structuring là hành vi chia nhỏ để mỗi giao dịch nằm ngay dưới ngưỡng. Ta tìm các tài khoản có nhiều giao dịch rơi vào "vùng nghi ngờ" — ví dụ từ 90% đến dưới 100% ngưỡng (9.000.000 đến < 10.000.000).

▶ Chạy được trong SQL Builder

SELECT
    account_id,
    COUNT(*)     AS so_gd_gan_nguong,
    MIN(amount)  AS gd_nho_nhat,
    MAX(amount)  AS gd_lon_nhat,
    SUM(amount)  AS tong_gia_tri
FROM transactions
WHERE amount >= 9000000
  AND amount <  10000000
GROUP BY account_id
HAVING COUNT(*) >= 2
ORDER BY so_gd_gan_nguong DESC;

Nhiều giao dịch cùng nằm ngay dưới ngưỡng là dấu hiệu đỏ điển hình. Trong thực tế còn phải xét: các giao dịch có gần nhau về thời gian không, có phối hợp qua nhiều tài khoản (smurfing) không, và tổng có vượt ngưỡng nếu gộp lại không.

3. Top tài khoản theo dòng tiền, kèm tên khách hàng

Ý tưởng: xếp hạng tài khoản theo tổng dòng tiền và số giao dịch, join lên accounts rồi customers để lấy full_name phục vụ điều tra. Lưu ý bảng customers có cột full_name (không có cột customer_name).

▶ Chạy được trong SQL Builder

SELECT
    c.full_name,
    a.account_no,
    COUNT(t.id)   AS so_giao_dich,
    SUM(t.amount) AS tong_dong_tien
FROM transactions t
JOIN accounts  a ON t.account_id  = a.id
JOIN customers c ON a.customer_id = c.id
GROUP BY c.full_name, a.account_no
ORDER BY tong_dong_tien DESC
LIMIT 10;

4. Pass-through — vào-ra gần cân bằng

Ý tưởng: tài khoản trung chuyển có tổng tiền vào và tổng tiền ra gần bằng nhau, để lại rất ít số dư ròng. Giả sử kind phân biệt chiều tiền (ví dụ 'credit' là tiền vào, 'debit' là tiền ra). Ta so tổng vào và tổng ra; báo động khi cả hai đều lớn nhưng chênh lệch nhỏ.

▶ Chạy được trong SQL Builder

SELECT
    account_id,
    SUM(CASE WHEN kind = 'credit' THEN amount ELSE 0 END) AS tong_vao,
    SUM(CASE WHEN kind = 'debit'  THEN amount ELSE 0 END) AS tong_ra,
    ABS(
        SUM(CASE WHEN kind = 'credit' THEN amount ELSE 0 END)
      - SUM(CASE WHEN kind = 'debit'  THEN amount ELSE 0 END)
    ) AS chenh_lech
FROM transactions
GROUP BY account_id
HAVING SUM(CASE WHEN kind = 'credit' THEN amount ELSE 0 END) >= 50000000
   AND ABS(
        SUM(CASE WHEN kind = 'credit' THEN amount ELSE 0 END)
      - SUM(CASE WHEN kind = 'debit'  THEN amount ELSE 0 END)
   ) < 5000000
ORDER BY tong_vao DESC;

Tổng vào lớn nhưng chênh lệch nhỏ = tiền "chảy qua" chứ không "ở lại". Đây chính là chữ ký của tài khoản trung chuyển (nếu giá trị kind trong sandbox khác, hãy đổi 'credit'/'debit' cho khớp).

Use case thực tế: phát hiện structuring

Hãy hình dung một tình huống điển hình. Ông A mở tài khoản với hồ sơ KYC ghi nghề "kinh doanh nhỏ, thu nhập ~20 triệu/tháng". Trong hai tuần, tài khoản nhận nhiều lần gửi tiền mặt, mỗi lần 9,2–9,8 triệu, ở các chi nhánh khác nhau, vào các ngày khác nhau. Không lần nào chạm ngưỡng báo cáo. Nhìn riêng lẻ, mỗi giao dịch hoàn toàn bình thường.

Giám sát hậu kiểm bắt điều này thế nào? Một scenario structuring như ví dụ SQL #2 gom giao dịch "gần ngưỡng" theo tài khoản và đếm — thấy 8 lần trong 14 ngày, tổng gần 75 triệu. Kết hợp luật velocity (#1) cho thấy tổng dòng tiền vượt xa kỳ vọng 20 triệu/tháng theo KYC. Hệ thống sinh alert.

Phân tích viên điều tra: đối chiếu KYC (kinh doanh nhỏ không giải thích được lượng tiền mặt), xem địa điểm gửi (nhiều chi nhánh khác vùng cư trú), xem mẫu phối hợp với tài khoản khác (dấu hiệu smurfing). Kết luận có cơ sở nghi ngờ → lập STR và có thể leo thang; toàn bộ được ghi lại làm bằng chứng và dữ liệu phản hồi cho vòng tuning.

Mấu chốt: không giao dịch đơn lẻ nào bất hợp pháp trên bề mặt — chỉ mẫu hình tổng thể mới lộ ra ý đồ né tránh. Đó là lý do phải nhìn theo chiều thời gian và theo cụm, không phải từng dòng.

Ghi nhớ

• Giám sát giao dịch = so hành vi thực tế với kỳ vọng KYC. Nó là nửa "động" bổ sung cho nửa "tĩnh" là KYC/CDD.
• Chạy cả hậu kiểm và real-time: hậu kiểm bắt mẫu hình theo thời gian; real-time bắt buộc cho sàng lọc trừng phạt và thanh toán tức thời.
• Typology là các kịch bản rửa tiền: structuring/smurfing (chia nhỏ để né ngưỡng) là quan trọng nhất, cùng pass-through, không phù hợp thu nhập, mule accounts, TBML, spike.
• Structuring: chia nhỏ dưới ngưỡng báo cáo — bất hợp pháp dù chia qua nhiều ngày/chi nhánh/ngân hàng; tổng thể và mục đích né tránh mới là điều quan trọng.
• Hai trường phái, một câu trả lời là kết hợp: luật ngưỡng minh bạch nhưng nhiều dương tính giả; ML/anomaly + graph bắt mẫu tinh vi nhưng khó giải thích. Hybrid + scenario tuning là chuẩn thực tế.
• Dương tính giả là vấn đề trung tâm: có thể tới 90–95% ở hệ thống cũ. Giảm bằng tuning ngưỡng, phân khúc khách hàng, gộp alert, ML xếp hạng. Theo dõi tỷ lệ alert→SAR nhưng đừng tối ưu mù quáng.
• Alert không phải kết luận: nó khởi động một quy trình sinh → triage → điều tra → STR/đóng, và mọi kết quả quay lại nuôi vòng tuning.
• Dữ liệu là nền tảng: cần giao dịch + KYC + điểm rủi ro; data silo là kẻ thù của một cái nhìn toàn cảnh.

Bài tiếp theo trong chuỗi đi sâu vào Báo cáo giao dịch đáng ngờ (STR) — điều gì xảy ra sau khi một cuộc điều tra kết luận "có cơ sở". Xem thêm Tổng quan AML, KYC/CDD, và Dữ liệu & công nghệ AML.