AML 7 — Dữ liệu, phân tích mạng & công nghệ AML

Sáu bài trước bàn về cái gì và tại sao. Bài này bàn về cách làm được — hạ tầng dữ liệu và công nghệ bên dưới. Suy cho cùng, AML hiện đại là một bài toán dữ liệu lớn: gộp dữ liệu định danh, giao dịch, sàng lọc và nguồn ngoài lại, làm sạch, kết nối, rồi chạy mô hình phân tích trên đó. Nếu tầng dữ liệu yếu, mọi mô hình tinh vi phía trên đều vô nghĩa — "rác vào, rác ra".

Bài này dành cho người làm data/kỹ thuật trong ngân hàng. Nó nối trực tiếp với các series kỹ thuật khác trong kho tri thức: mô hình hoá dữ liệu, Kafka/streaming, CDC với Oracle, và học máy không giám sát cho phát hiện bất thường.

1. Vì sao AML là một bài toán dữ liệu lớn

Một hệ thống phát hiện rửa tiền tốt không phải là một mô hình thông minh — nó là một quy trình dữ liệu đầu-cuối. Ba đặc điểm khiến AML đặc biệt khó về mặt dữ liệu:

• Đa nguồn và không đồng nhất. Dữ liệu KYC ở hệ thống onboarding; giao dịch ở core banking, thẻ, ví; dữ liệu sàng lọc từ nhà cung cấp danh sách (sanctions, PEP); dữ liệu ngoài gồm sổ đăng ký doanh nghiệp, thông tin thụ hưởng (beneficial ownership), tin xấu (adverse media). Mỗi nguồn có mô hình, chu kỳ và chất lượng khác nhau.
• Tín hiệu phân tán. Một giao dịch lẻ hầu như không đủ để kết luận rửa tiền. Tín hiệu thật nằm ở mối quan hệ và chuỗi thời gian: nhiều giao dịch nhỏ liên tiếp, một mạng tài khoản chuyển vòng vo, một khách đột nhiên đổi hành vi. Muốn thấy tín hiệu, phải nối dữ liệu chứ không nhìn từng dòng.
• Chi phí sai lầm bất đối xứng. Bỏ sót một vụ (false negative) có thể dẫn tới phạt hàng trăm triệu USD; báo động nhầm (false positive) tràn lan làm đội điều tra chết ngạt. Chất lượng dữ liệu quyết định trực tiếp cả hai loại lỗi.

Vì vậy, nền tảng của AML hiện đại là chất lượng và tích hợp dữ liệu, không phải thuật toán. Thứ tự đúng là: hợp nhất dữ liệu → giải quyết thực thể → dựng đồ thị quan hệ → chạy luật + mô hình → sinh cảnh báo → điều tra → báo cáo.

2. Mô hình dữ liệu AML: hướng tới "single view of customer"

Mục tiêu của tầng dữ liệu AML là dựng được một cái nhìn hợp nhất về khách hàng (single view of customer): với bất kỳ khách hàng nào, hệ thống trả lời được ngay — họ là ai, sở hữu những tài khoản/thẻ/ví nào, giao dịch với ai, có quan hệ gì với các khách hàng khác, đã bị cảnh báo/hồ sơ nào chưa, và rủi ro hiện tại ở mức nào.

Các thực thể cốt lõi trong một mô hình dữ liệu AML thường gồm:

Vài nguyên tắc thiết kế quan trọng:

• Bảo toàn lịch sử (temporal). Xếp hạng rủi ro của khách, địa chỉ, tình trạng PEP đều thay đổi theo thời gian. Mô hình dữ liệu AML phải giữ được trạng thái tại thời điểm giao dịch xảy ra, không chỉ trạng thái hiện tại — đây chính là bài toán lịch sử hoá đã bàn trong mô hình hoá dữ liệu (SCD, bảng lịch sử). Khi điều tra viên mở lại một giao dịch năm ngoái, họ cần thấy khách khi đó được đánh giá rủi ro thế nào.
• Tách nguồn khỏi kho phân tích. Không truy vấn trực tiếp vào core banking để chạy AML. Thay vào đó, dữ liệu chảy vào một kho/lakehouse AML riêng qua CDC + streaming: Oracle CDC/GoldenGate/Debezium bắt thay đổi từ core, đẩy qua Kafka tới hệ thống AML. Nhờ vậy giám sát gần thời gian thực mà không đè tải lên hệ thống giao dịch.
• Chuẩn hoá và làm giàu. Trước khi vào mô hình, dữ liệu được chuẩn hoá (định dạng ngày, đơn vị tiền, mã quốc gia ISO), làm giàu (gắn mã ngành, phân loại kênh, thêm toạ độ địa lý) và kiểm chất lượng (thiếu trường bắt buộc, giá trị bất khả thi).

3. Entity resolution: gộp đúng người, đúng đối tác

Đây là mắt xích thầm lặng nhưng quyết định. Entity resolution (giải quyết thực thể, còn gọi là record linkage) là việc nhận ra rằng nhiều bản ghi rời rạc thực chất trỏ về cùng một thực thể thực — dù dữ liệu lệch nhau về chính tả, định dạng hay nguồn.

Vì sao quan trọng đến vậy? Tội phạm cố tình khai lệch để tránh bị nối. "Nguyen Van A" ở tài khoản này và "Nguyễn Văn A" ở tài khoản kia, cùng ngày sinh, cùng số điện thoại — nếu hệ thống coi là hai người khác nhau, mạng lưới rửa tiền sẽ bị cắt thành các mảnh vô hại. Bỏ sót entity resolution nghĩa là bỏ sót tín hiệu từ gốc.

Kỹ thuật thường dùng:

• Blocking — nhóm sơ bộ các bản ghi có khả năng trùng (ví dụ cùng ngày sinh hoặc cùng 4 số cuối CMND) để không phải so từng cặp trong hàng triệu bản ghi.
• Fuzzy matching — so khớp gần đúng tên, địa chỉ bằng khoảng cách chuỗi (Levenshtein, Jaro-Winkler), chuẩn hoá phiên âm, xử lý dấu tiếng Việt. Đây chính là kỹ thuật đã dùng trong sàng lọc cấm vận; ở đây nó phục vụ nối nội bộ chứ không phải khớp danh sách đen.
• Chấm điểm và ngưỡng — tổng hợp nhiều tín hiệu (tên, ngày sinh, địa chỉ, điện thoại, thiết bị) thành một điểm trùng; trên ngưỡng thì tự động gộp, vùng xám thì đưa người xem xét.
• Dùng quan hệ mạng để tăng độ chính xác. Nghiên cứu và thực tiễn ngành cho thấy: xét quan hệ ở cấp mạng lưới (hai bản ghi cùng chuyển tiền tới đúng một nhóm người) chính xác hơn nhiều so với chỉ so thuộc tính từng bản ghi. Đây là lý do entity resolution và graph analytics thường đi cùng nhau.

Kết quả entity resolution tạo ra một định danh hợp nhất (canonical/golden ID) — nút trung tâm để tất cả tài khoản, giao dịch và cảnh báo quy về đúng một khách hàng.

4. Phân tích mạng / đồ thị: nhìn dòng tiền như một mạng lưới

Nếu chỉ có một ý tưởng để nhớ từ bài này, hãy nhớ điều này: rửa tiền là hiện tượng của mạng lưới, nên công cụ tự nhiên để phát hiện nó là đồ thị.

Ý tưởng: mô hình khách hàng, tài khoản, giao dịch thành một đồ thị — nút (node) là khách/tài khoản, cạnh (edge) là giao dịch hoặc quan hệ. Khi đó những mẫu mà hệ thống dòng-đơn-lẻ (row-based) không thấy được sẽ trở nên rõ ràng:

• Vòng tiền (cycle). Tiền đi A → B → C → ... → A. Không có lý do kinh doanh nào để tiền quay về điểm xuất phát; đây là dấu hiệu kinh điển của tạo lớp (layering) để che nguồn gốc.
• Mạng mule. Nhiều tài khoản nhận tiền từ một nguồn rồi nhanh chóng chuyển đi, hoạt động phối hợp — chính là các mạng mule đã bàn trong Fraud/FRAML. Trên đồ thị, chúng hiện ra như những cụm dày đặc.
• Cấu trúc "quạt vào / quạt ra" (fan-in / fan-out). Rất nhiều nút gửi tiền dồn vào một nút (gom), hoặc một nút bung tiền ra rất nhiều nút (chia nhỏ để tránh ngưỡng báo cáo — smurfing).

Các họ thuật toán đồ thị hay dùng trong AML:

Trong đó, betweenness centrality đặc biệt hữu ích: nó nêu bật những tài khoản bắc cầu giữa các cụm vốn tách biệt — đúng vai trò của tài khoản trung chuyển trong layering. PageRank chấm điểm tầm quan trọng dựa trên luồng tiền chảy vào chứ không chỉ số kết nối, giúp lộ ra nút hút tiền bất thường.

Vì sao đồ thị mạnh hơn hẳn cho layering? Vì layering chính là việc tạo nhiều bước trung gian để cắt đứt liên kết nguồn–đích. Trong bảng quan hệ (relational), truy "A tới B tới C tới D" đòi hỏi join lồng nhau nhiều tầng, chậm và cồng kềnh. Trong đồ thị, đó chỉ là một phép duyệt nhiều bước (multi-hop traversal) — bản chất của cấu trúc dữ liệu đồ thị. Đó là lý do các nền tảng chuyên dụng (Neo4j, TigerGraph, Amazon Neptune, Oracle Graph) được dùng cho AML: chúng lưu và duyệt quan hệ như công dân hạng nhất. Theo công bố của các nhà cung cấp, mô hình ML dựa trên đồ thị có thể phát hiện thêm nhiều kịch bản so với luật thuần và giảm mạnh dương tính giả — con số cụ thể tuỳ triển khai, cần kiểm chứng nội bộ.

Ví dụ: một luật đồ thị phát hiện vòng tiền (pseudocode)

# (minh hoạ) — Cypher-style pseudocode, KHÔNG chạy trên sandbox

# Tìm chu trình 3–6 bước quay về đúng tài khoản xuất phát,
# trong cửa sổ 14 ngày, mỗi bước >= 50 triệu VND

MATCH path = (a:Account)-[t:TRANSFER*3..6]->(a)
WHERE all(r IN relationships(path) WHERE r.amount >= 50_000_000)
  AND all(r IN relationships(path) WHERE r.ts >= now() - duration('P14D'))
  AND reduce(prev = 0, r IN relationships(path) |   # thời gian tăng dần
        CASE WHEN r.ts >= prev THEN r.ts ELSE -1 END) >= 0
WITH a,
     length(path)                       AS hops,
     reduce(s = 0.0, r IN relationships(path) | s + r.amount) AS total_flow
WHERE total_flow >= 300_000_000          # ngưỡng tổng dòng tiền
RETURN a.golden_id AS entity,
       hops,
       total_flow
ORDER BY total_flow DESC

Luật trên nắm bắt trực giác: tiền quay về nơi xuất phát, số tiền đủ lớn, thời gian đủ gần, không có lý do kinh tế hợp lý → đáng ngờ. Trong thực tế, luật đồ thị thường được kết hợp với điểm số ML (mục 5) để xếp hạng mức nghi ngờ trước khi sinh cảnh báo.

5. Machine learning cho AML: giảm dương tính giả, nhưng phải giải thích được

Vấn đề nhức nhối nhất của giám sát giao dịch dựa trên luật ngưỡng là dương tính giả — thường 90–95% cảnh báo là báo động nhầm, làm đội điều tra kiệt sức. ML vào cuộc chủ yếu để chữa đúng chỗ này, với vài vai trò:

• Xếp hạng cảnh báo (alert scoring). Học từ lịch sử cảnh báo đã xử lý (cái nào thành STR, cái nào đóng vô hại) để chấm điểm cảnh báo mới, đưa cái rủi ro cao lên đầu — điều tra viên xử lý theo thứ tự thông minh thay vì bơi trong đống báo động ngang nhau.
• Phát hiện bất thường (anomaly detection). Học hành vi bình thường của từng khách rồi gắn cờ độ lệch — hữu ích khi kịch bản chưa có mẫu sẵn. Đây là địa hạt của học máy không giám sát: clustering, isolation forest, autoencoder.
• Chấm điểm rủi ro động. Phân khúc khách tinh vi hơn ngưỡng cứng, cho ngưỡng theo ngữ cảnh (một số tiền bất thường với khách A lại bình thường với khách B).
• Graph ML / GNN. Mạng nơ-ron trên đồ thị học trực tiếp từ cấu trúc mạng, kết hợp sức mạnh mục 4 với ML — hướng nghiên cứu nóng cho phát hiện mạng đồng phạm.

Nhưng có một ràng buộc không thể bỏ qua trong AML mà nhiều bài toán ML khác không có: giải thích được (explainability). Cơ quan quản lý sẽ hỏi "vì sao mô hình gắn cờ giao dịch này?" và "vì sao mô hình bỏ qua giao dịch kia?". Một mô hình hộp đen chấm điểm mà không lý giải được là không dùng được cho AML, dù độ chính xác cao đến đâu. Vì thế:

• Ưu tiên mô hình giải thích được, hoặc bọc mô hình phức tạp bằng công cụ giải thích (feature attribution như SHAP) để mỗi cảnh báo kèm lý do "vì sao".
• Không dùng ML để tự động bỏ cảnh báo mà không dấu vết. Thông thường ML dùng để xếp hạng và hỗ trợ con người, không thay thế phán đoán và trách nhiệm pháp lý của con người.

Đây cùng chuỗi tư duy với giám sát và giải thích mô hình trong tín dụng: mô hình phải minh bạch, có tài liệu, và chịu được sự soi xét.

6. Real-time và batch: hai nhịp đập của hệ thống

Không phải mọi thứ AML đều cần thời gian thực, và cũng không thứ gì nên chỉ chạy theo lô. Kiến trúc tốt phối cả hai:

Real-time là bắt buộc cho sàng lọc trước khi tiền rời ngân hàng — bạn không thể để một khoản chuyển tới đối tượng bị cấm vận đi xong rồi mới phát hiện. Luồng điển hình: giao dịch phát sinh → CDC bắt thay đổi → đẩy vào Kafka → bộ xử lý dòng chạy luật + sàng lọc → quyết định trong mili-giây. Ngược lại, batch phù hợp cho phân tích đồ thị nặng, huấn luyện lại mô hình và rà soát hồi tố khi danh sách cấm vận cập nhật (phải quét lại khách hàng cũ).

7. Regtech & vận hành: từ cảnh báo tới hồ sơ

Phần lớn ngân hàng không tự viết hệ thống AML mà mua nền tảng regtech thương mại (các tên quen thuộc: NICE Actimize, SAS, Oracle FCCM, Napier, Hawk...). Giá trị của các nền tảng này nằm ở phần vận hành quanh mô hình:

• Tự động hoá điều tra & workflow. Cảnh báo tự gom thành hồ sơ (case), tự kéo về ngữ cảnh (lịch sử khách, giao dịch liên quan, đồ thị mạng), định tuyến tới đúng điều tra viên, ghi vết mọi thao tác.
• Kết nối tới STR. Khi điều tra kết luận đáng ngờ, hồ sơ chuyển thành báo cáo giao dịch đáng ngờ (STR) với dữ liệu đã sẵn sàng.
• Bảng điều khiển & báo cáo tuân thủ cho quản lý và cơ quan giám sát.

Model governance / validation — không thể xem nhẹ

Điểm mà đội data hay bỏ quên: mô hình AML là một mô hình rủi ro, và do đó chịu kỷ luật quản trị mô hình như mô hình tín dụng. Cơ quan quản lý yêu cầu ngân hàng phải validate, tài liệu hoá và giám sát mô hình AML một cách độc lập, theo cách tiếp cận dựa trên rủi ro và có thể biện hộ được. Cụ thể:

• Validation độc lập — một đội tách biệt với đội xây mô hình kiểm tra tính đúng đắn, độ nhạy ngưỡng, và rủi ro bỏ sót.
• Tài liệu hoá đầy đủ — mục đích mô hình, dữ liệu đầu vào, giả định, giới hạn; đủ để người ngoài tái lập và kiểm tra.
• Backtest & giám sát trôi (drift). Mẫu hành vi hợp pháp lẫn bất hợp pháp đổi theo thời gian; nếu không huấn luyện lại định kỳ, mô hình sẽ trôi và mất hiệu lực. Phải theo dõi hiệu năng liên tục và định lượng suy giảm.
• Challenger model & feature attribution — chạy song song mô hình thách thức để đối chiếu, và giữ khả năng quy trách nhiệm cho từng biến. Đây là thông lệ mà các hướng dẫn giám sát AI ngày càng nhấn mạnh.

Nói ngắn gọn: bạn không chỉ phải làm cho mô hình chạy tốt, mà còn phải chứng minh được nó chạy tốt và giải thích được khi bị hỏi.

8. Riêng tư & tuân thủ dữ liệu

Dữ liệu AML là dữ liệu nhạy cảm nhất trong ngân hàng — nó phơi bày định danh, quan hệ và hành vi tài chính của khách. Vài ràng buộc:

• PII và tối thiểu hoá. Chỉ thu thập và giữ dữ liệu cá nhân cần thiết; mã hoá khi lưu và khi truyền; kiểm soát truy cập chặt và ghi vết ai xem gì. Ở Việt Nam, việc này phải tuân Nghị định 13/2023 về bảo vệ dữ liệu cá nhân.
• Căng thẳng "cần biết" vs "quyền riêng tư". AML cho phép xử lý dữ liệu cho mục đích tuân thủ, nhưng không phải giấy phép vô hạn — phạm vi phải tương xứng.
• Chia sẻ thông tin liên ngân hàng. Mạng mule trải khắp nhiều ngân hàng; hợp tác chia sẻ thông tin (theo cơ chế được pháp luật cho phép và qua đầu mối như cơ quan tình báo tài chính) giúp thấy bức tranh vượt ngoài một tổ chức — nhưng phải cân với luật bảo vệ dữ liệu và bí mật khách hàng.

Sơ đồ tổng thể

Use case thực tế: dùng đồ thị lần theo một mạng mule / layering

Bối cảnh: đội giám sát nhận một cảnh báo lẻ — tài khoản X nhận một khoản lớn rồi chuyển hết đi trong vòng vài giờ. Theo luật ngưỡng đơn lẻ, đây chỉ là một cảnh báo mờ nhạt, dễ bị đóng là "khách chuyển tiền bình thường".

Đội chuyển sang góc nhìn đồ thị:

1. Mở rộng lân cận. Dựng đồ thị quanh X ra 3–4 bước. Lộ ra: X không đơn độc — nó nằm trong một cụm 40 tài khoản nhận tiền từ cùng vài nguồn rồi đẩy đi rất nhanh (giữ số dư gần 0). Đây là hình dạng kinh điển của mạng mule.
2. Community detection. Chạy Louvain trên đồ thị: 40 tài khoản này tách ra thành một cộng đồng chặt, giao dịch chủ yếu với nhau và với hai "trung tâm gom" — dấu hiệu phối hợp chứ không ngẫu nhiên.
3. Centrality. Betweenness centrality nêu bật hai tài khoản bắc cầu giữa "tầng gom" và "tầng phân tán" — chính là các tài khoản trung chuyển của bước layering. Đây là các nút cần ưu tiên điều tra.
4. Phát hiện chu trình. Luật vòng tiền (như pseudocode ở mục 4) tìm thấy tiền cuối cùng quay về gần một nguồn ban đầu qua 5 bước — không có lý do kinh tế, xác nhận layering.
5. Entity resolution. Ba trong số các tài khoản "khác nhau" thực ra cùng một số điện thoại và thiết bị đăng nhập → entity resolution gộp chúng về một golden ID, làm mạng lưới co lại và rõ ràng hơn.

Kết quả: thay vì một cảnh báo lẻ dễ bị bỏ qua, đội có một hồ sơ mạng lưới hoàn chỉnh — ai gom, ai trung chuyển, tiền đi đâu, các thực thể ẩn danh nào thực ra là một — đủ cơ sở để lập STR. Đây là minh hoạ trực tiếp vì sao góc nhìn mạng biến những mảnh tín hiệu rời rạc thành bằng chứng có cấu trúc.

Ghi nhớ

• AML trước hết là bài toán dữ liệu. Chất lượng và tích hợp dữ liệu (KYC + giao dịch + sàng lọc + nguồn ngoài) là nền móng; mô hình tinh vi trên nền dữ liệu kém sẽ vô dụng.
• Single view of customer cần mô hình dữ liệu hợp nhất, giữ lịch sử (trạng thái tại thời điểm giao dịch), nạp qua CDC + Kafka thay vì đè tải core banking.
• Entity resolution là mắt xích âm thầm quyết định: gộp đúng thực thể (fuzzy match + quan hệ mạng) để không cắt vụn mạng lưới rửa tiền ngay từ gốc.
• Đồ thị là công cụ tự nhiên cho AML vì rửa tiền là hiện tượng mạng lưới: chu trình lộ layering, community detection lộ mule, centrality lộ trung tâm/cầu nối.
• ML giảm dương tính giả qua xếp hạng cảnh báo và phát hiện bất thường — nhưng phải giải thích được; ML hỗ trợ chứ không thay con người ra quyết định pháp lý.
• Real-time cho sàng lọc/chặn, batch cho rà soát & huấn luyện — kiến trúc tốt phối cả hai nhịp.
• Mô hình AML là mô hình rủi ro: phải validate độc lập, tài liệu hoá, backtest và giám sát trôi — vì cơ quan quản lý sẽ soi.
• Dữ liệu AML rất nhạy cảm: tuân thủ bảo vệ dữ liệu cá nhân (Nghị định 13/2023), tối thiểu hoá, kiểm soát truy cập, và chia sẻ liên ngân hàng trong khuôn khổ pháp lý.

Bài tiếp theo của chuỗi sẽ khép lại phần vận hành và quản trị chương trình tuân thủ. Xem lại các mảnh ghép nghiệp vụ ở giám sát giao dịch, sàng lọc cấm vận và Fraud/FRAML.