Graph 8 — Use case ngân hàng & chọn công cụ

Bảy bài trước dựng năng lực: tổng quan graph, mô hình dữ liệu, Cypher cơ bản và nâng cao, thuật toán GDS, fraud/AML, và tích hợp/vận hành. Bài fraud/AML đã đào rất sâu một use case; bài này mở rộng ra toàn bộ danh mục ứng dụng đồ thị trong ngân hàng và — quan trọng không kém — trả lời câu hỏi thực dụng nhất: khi nào NÊN dùng graph, khi nào không, và chọn công cụ nào? Đây là bài đóng series, viết cho người ra quyết định kiến trúc chứ không chỉ người viết Cypher.

Lưu ý: block cypher trong bài là cú pháp Neo4j — minh hoạ, không chạy trên sandbox. Chỉ block đánh dấu -- ▶ Chạy được (SELECT thuần trên 5 bảng demo Postgres) mới thực thi. Các con số trong ví dụ là minh hoạ để hình dung quy mô.

Bản đồ use case đồ thị trong ngân hàng

Fraud/AML là ứng dụng "đinh" vì ROI rõ và dữ liệu sẵn có, nhưng cùng một hạ tầng đồ thị phục vụ được nhiều bài toán khác. Điểm chung của mọi use case dưới đây: giá trị nằm ở quan hệ nhiều bậc, không phải ở một dòng dữ liệu đơn lẻ. Nếu câu hỏi của bạn cần "đi theo" các mối liên hệ qua nhiều tầng, graph tỏa sáng; nếu chỉ cần lọc/tổng hợp trên bảng phẳng, RDBMS/warehouse làm tốt hơn.

1. KYC & UBO — lần theo chủ sở hữu hưởng lợi cuối cùng

UBO (Ultimate Beneficial Owner) là cá nhân thực sự sở hữu/kiểm soát một pháp nhân, dù được che qua nhiều tầng công ty mẹ - con. Quy định KYC/AML buộc ngân hàng phải xác định UBO nắm trên một ngưỡng (thường 25%) trước khi mở tài khoản doanh nghiệp. Vấn đề: cấu trúc sở hữu có thể sâu 4-6 tầng, sở hữu chéo, vòng lặp, và tỷ lệ nhân qua các tầng.

Với RDBMS, việc này là chuỗi self-join đệ quy dài và khó tính tỷ lệ tích lũy. Với graph, mỗi công ty/cá nhân là node, quan hệ OWNS {pct} là cạnh; UBO là bài toán duyệt đường đi + nhân trọng số:

// Minh hoạ: tìm cá nhân sở hữu gián tiếp >= 25% một công ty
MATCH path = (p:Person)-[r:OWNS*1..6]->(c:Company {id: $companyId})
WITH p, reduce(pct = 1.0, rel IN r | pct * rel.pct) AS effective
WHERE effective >= 0.25
RETURN p.name, round(effective * 100, 1) AS ownership_pct
ORDER BY ownership_pct DESC;

Đồ thị còn phát hiện được cấu trúc đáng ngờ: một cá nhân ẩn dưới 10 công ty vỏ, hay hai khách "độc lập" chia sẻ chung một UBO — tín hiệu rủi ro cho onboarding.

2. Khách hàng 360 & entity resolution

Ngân hàng lưu cùng một người ở nhiều hệ thống: core, thẻ, vay, bảo hiểm, CRM — mỗi nơi một khoá, một cách ghi tên/địa chỉ. Khách hàng 360 cần hợp nhất chúng thành một chân dung. Entity resolution là quá trình quyết định "hai bản ghi này là cùng một người".

Graph mô hình việc này rất tự nhiên: mỗi bản ghi là node, các định danh dùng chung (số điện thoại, CCCD, thiết bị, địa chỉ) là node được nhiều bản ghi cùng trỏ tới. Cụm liên thông (connected component — xem bài GDS) qua các định danh này chính là một thực thể. Sau khi hợp nhất, mọi tài khoản - giao dịch - sản phẩm treo dưới một node khách duy nhất, cho cái nhìn 360 thật sự và làm nền cho fraud (một người giả nhiều danh) lẫn cross-sell.

Để đối chiếu: ngay trên RDBMS phẳng, một "khách 360 tối giản" là gom tài khoản và giao dịch quanh một khách. Đây là ví dụ chạy được, JOIN đủ chuỗi khoá customers → accounts → transactions:

-- ▶ Chạy được
SELECT c.id,
       c.full_name,
       c.city,
       COUNT(DISTINCT a.id)          AS so_tai_khoan,
       COALESCE(SUM(a.balance), 0)   AS tong_so_du,
       COUNT(t.id)                   AS so_giao_dich
FROM customers c
LEFT JOIN accounts a     ON a.customer_id = c.id
LEFT JOIN transactions t ON t.account_id = a.id
GROUP BY c.id, c.full_name, c.city
ORDER BY tong_so_du DESC
LIMIT 20;

RDBMS làm tốt việc gom quanh một khoá đã biết. Cái nó vật vã là khi khoá chưa được hợp nhất — phải suy ra "đây là cùng người" qua mạng lưới định danh dùng chung. Đó chính là lúc chuyển qua graph.

3. Recommendation — next-best-product

Đồ thị khách - sản phẩm - hành vi là mảnh đất cổ điển cho gợi ý. Ý tưởng lọc cộng tác (collaborative filtering) diễn đạt thẳng bằng Cypher: "khách giống bạn (cùng nắm nhiều sản phẩm với bạn) còn dùng sản phẩm nào bạn chưa có?"

// Minh hoạ: gợi ý sản phẩm dựa trên khách tương đồng
MATCH (me:Customer {id: $id})-[:HOLDS]->(p:Product)<-[:HOLDS]-(peer:Customer)
MATCH (peer)-[:HOLDS]->(rec:Product)
WHERE NOT (me)-[:HOLDS]->(rec)
RETURN rec.name, count(DISTINCT peer) AS score
ORDER BY score DESC LIMIT 5;

Kết hợp thêm node similarity hoặc embedding đồ thị (Node2Vec/FastRP trong GDS) cho gợi ý tốt hơn. Trong ngân hàng, đầu ra thường là feature đưa vào mô hình propensity, không phải quyết định cuối — nhưng graph cung cấp tín hiệu quan hệ mà bảng phẳng khó có.

4. Knowledge graph & GraphRAG

Knowledge graph kết nối dữ liệu doanh nghiệp phân mảnh — sản phẩm, quy định, hợp đồng, khách, tổ chức — thành một mạng ngữ nghĩa có thể truy vấn. Nó là "bản đồ khái niệm" của ngân hàng, dùng cho tra cứu, kiểm tra tuân thủ, và ngày càng nhiều cho GenAI.

GraphRAG (Graph Retrieval-Augmented Generation) là biến thể RAG dùng knowledge graph làm nguồn truy hồi thay cho (hoặc bổ sung) tìm kiếm vector thuần. Thay vì chỉ lấy các đoạn văn bản "gần nhất" theo embedding, GraphRAG đi theo quan hệ để gom ngữ cảnh liên kết nhiều bước — ví dụ "sản phẩm X thuộc nhóm Y, chịu quy định Z, do phòng W phụ trách" — rồi đưa cả cụm đó cho LLM. Ưu điểm: câu trả lời bám cấu trúc thật, giảm bịa, dễ truy vết nguồn. Đây là hướng còn mới; hãy coi là bổ trợ cho tìm kiếm vector (Elasticsearch/OpenSearch) chứ không thay thế.

5. Rủi ro liên đới & tập trung tín dụng — "nhóm khách hàng liên quan"

Quy định an toàn vốn buộc ngân hàng đo giới hạn cấp tín dụng cho một khách hàng và người có liên quan (related party / connected group). Rủi ro thật không phải từng khách riêng lẻ mà là cả nhóm: nếu công ty mẹ, các công ty con, và người điều hành cùng vay, một cú sập của nhóm kéo theo toàn bộ dư nợ. Định nghĩa "liên quan" bắc qua sở hữu, ban điều hành chung, bảo lãnh chéo, giao dịch nội bộ — đúng dạng mạng lưới.

Graph gom nhóm bằng thuật toán community/connected component trên các cạnh "liên quan", rồi cộng dồn dư nợ toàn nhóm để so với giới hạn. Đây là anh em ruột của entity resolution nhưng ở cấp pháp nhân + tín dụng, và nối thẳng vào chấm điểm tín dụng khi đưa "rủi ro nhóm" thành feature.

Vẫn có thể ước lượng thô mức tập trung trên RDBMS trước khi cần graph — ví dụ tổng dư nợ (số dư âm/tín dụng) và dòng tiền quanh nhóm khách theo thành phố, JOIN đủ 5 bảng demo (đối chiếu cả nhánh nhân sự phụ trách theo phòng ban):

-- ▶ Chạy được
SELECT c.city,
       d.name                       AS phong_phu_trach,
       COUNT(DISTINCT c.id)         AS so_khach,
       COUNT(DISTINCT a.id)         AS so_tai_khoan,
       COALESCE(SUM(t.amount), 0)   AS tong_dong_tien
FROM customers c
JOIN accounts a      ON a.customer_id = c.id
JOIN transactions t  ON t.account_id = a.id
JOIN employees e     ON e.id = (c.id % 50) + 1
JOIN departments d   ON d.id = e.department_id
GROUP BY c.city, d.name
HAVING COUNT(DISTINCT c.id) > 1
ORDER BY tong_dong_tien DESC
LIMIT 20;

Truy vấn này minh hoạ cách gom "cụm khách theo thành phố" trên bảng phẳng. Nhưng nó không biết công ty A và công ty B liên quan qua sở hữu chéo — đó là ranh giới nơi graph tiếp quản.

6. Tối ưu mạng lưới ATM / chi nhánh

Ít gợi cảm hơn nhưng rất thực: mô hình vị trí ATM/chi nhánh, đường di chuyển khách, luồng tiền mặt như một mạng không gian. Bài toán như đặt ATM ở đâu để tối đa vùng phủ, chi nhánh nào là điểm nút quan trọng của luồng khách, dùng centrality và thuật toán đường đi ngắn nhất (bài GDS). Đây là graph "địa lý/hạ tầng" hơn là "tài chính", thường kết hợp dữ liệu không gian.

Kiến trúc tham chiếu

Mọi use case trên chia chung một khung: core là nguồn sự thật, Neo4j là lớp phái sinh, GDS sinh insight, ứng dụng/ML tiêu thụ. Đây là nhắc lại nguyên tắc từ bài tích hợp nhưng nhìn từ phía tiêu thụ.

Feature đồ thị cho mô hình. Điểm gặp nhau của graph và ML: GDS tính các đặc trưng chỉ tồn tại ở tầng mạng lưới rồi ghi ngược về warehouse để mô hình dùng. Ví dụ:

Đây là "cầu nối" biến insight đồ thị thành giá trị cho pipeline ML hiện có, thay vì bắt mô hình học lại quan hệ từ bảng phẳng.

Chọn công cụ: graph vs RDBMS vs ClickHouse vs search

Câu hỏi đắt giá nhất. Đừng để "graph là hot" dẫn dắt — hãy để hình dạng câu hỏi quyết định.

Vài dấu hiệu nên chuyển sang graph: câu SQL của bạn có 5+ self-join hay JOIN đệ quy; câu hỏi chứa cụm từ "qua bao nhiêu bước", "liên quan tới nhau thế nào", "vòng", "cụm", "đường tiền"; độ sâu truy vết không biết trước. Dấu hiệu không nên: chỉ lọc + group by trên một-hai bảng, cần quét toàn bộ dữ liệu (graph kém ở scan lớn), hoặc dữ liệu vốn phẳng và ít quan hệ.

Quan trọng: các công cụ bổ sung, không loại trừ. Kiến trúc ngân hàng thật dùng cả bốn — RDBMS giữ tiền, warehouse chạy report, search phục vụ tra cứu, graph trả lời câu hỏi mạng lưới — cùng một dữ liệu, khác góc nhìn.

Neo4j vs Neptune vs TigerGraph

Trong nội bộ họ graph, ba lựa chọn phổ biến (nhắc kỹ hơn ở bài 7):

Với đa số ngân hàng bắt đầu, Neo4j là mặc định hợp lý nhờ GDS trưởng thành và tài liệu tốt. Neptune hấp dẫn nếu hạ tầng đã đứng trên AWS. TigerGraph cân nhắc khi đồ thị đạt quy mô rất lớn và cần deep-link analytics làm lõi.

Hạn chế & lưu ý triển khai ngân hàng

• Neo4j là lớp phân tích, KHÔNG thay core. Đừng bao giờ để tiền hay bút toán "chỉ tồn tại trong graph". Chiều ghi luôn là core → graph; insight graph ghi ngược về warehouse như dữ liệu phái sinh.
• Tuân thủ & bảo mật là ràng buộc cứng. Đồ thị gom dữ liệu định danh khách qua nhiều hệ thống — chính vì thế nó là "kho vàng" nhạy cảm. Cần kiểm soát truy cập chặt, mã hoá, che dữ liệu, và ghi log; dữ liệu UBO/related-party đặc biệt nhạy cảm.
• Chất lượng dữ liệu quyết định giá trị. Entity resolution và UBO chỉ đúng khi định danh sạch. Rác vào thì cụm sai — gắn với data quality và lineage.
• Đừng ép mọi thứ thành graph. Nếu câu hỏi giải được bằng một JOIN trên warehouse, làm thế; graph chỉ trả giá cho những câu hỏi quan hệ nhiều bậc.
• Insight cần con người diễn giải. Graph gợi ra "nhóm/vòng/đường tiền đáng ngờ"; quyết định (chặn tài khoản, báo cáo giao dịch đáng ngờ) vẫn theo quy trình nghiệp vụ và pháp lý.

Use case thực tế

Bài toán: Khối Tuân thủ NCB cần rà "nhóm khách hàng liên quan" cho danh mục tín dụng doanh nghiệp — trước đây làm thủ công trên Excel, bỏ sót sở hữu chéo sâu quá 2 tầng.

Cách làm với kiến trúc trên:

1. Nạp dữ liệu: CDC từ core + hồ sơ doanh nghiệp đẩy vào Neo4j — node Company, Person, cạnh OWNS{pct}, MANAGES, GUARANTEES, HOLDS(khoản vay).
2. Gom nhóm: chạy connected component trên các cạnh "liên quan"; mỗi cụm là một nhóm khách liên quan. Ví dụ minh hoạ: hệ thống phát hiện 1.240 nhóm, trong đó 38 nhóm có tổng dư nợ vượt 80% giới hạn cho phép.
3. UBO: với mỗi nhóm, chạy truy vấn nhân tỷ lệ sở hữu tìm cá nhân ≥ 25% — lộ ra 5 nhóm "độc lập trên giấy" thực chất chung một UBO, trước đây không phát hiện.
4. Feature cho mô hình: ghi group_id, group_exposure, pagerank ngược về warehouse; mô hình chấm điểm tín dụng thêm biến "rủi ro nhóm".
5. Kết quả (minh hoạ): rà nhóm từ vài ngày thủ công còn dưới một giờ; nâng giới hạn được kiểm soát theo nhóm thay vì từng khách; hồ sơ AML onboarding có thêm cảnh báo UBO trùng.

Điểm mấu chốt: không use case nào ở trên thay thế core hay warehouse — chúng bổ sung một góc nhìn (mạng lưới) mà các hệ thống phẳng không có, và trả insight ngược về đúng nơi nghiệp vụ đang dùng.

Ghi nhớ

• Ngoài fraud/AML, đồ thị phục vụ 6 nhóm use case ngân hàng: KYC/UBO, khách 360 & entity resolution, recommendation, knowledge graph/GraphRAG, rủi ro liên đới/tập trung tín dụng, tối ưu mạng lưới ATM/chi nhánh.
• Điểm chung: giá trị nằm ở quan hệ nhiều bậc, không ở dòng dữ liệu đơn lẻ. Nếu SQL của bạn cần 5+ self-join hay JOIN đệ quy độ sâu không biết trước → cân nhắc graph.
• Kiến trúc tham chiếu: core (system of record) → CDC → Neo4j → GDS (insight) → warehouse/ứng dụng/ML. Graph feature (PageRank, community, embedding, khoảng cách tới node xấu) là cầu nối graph ↔ ML.
• Chọn công cụ theo hình dạng câu hỏi, không theo trend: RDBMS cho tiền/ACID, ClickHouse/warehouse cho OLAP, search cho tìm kiếm/vector, graph cho traversal nhiều bậc. Chúng bổ sung nhau, không loại trừ.
• Trong họ graph: Neo4j là mặc định an toàn (GDS + tài liệu); Neptune nếu đã ở AWS; TigerGraph khi đồ thị cực lớn.
• Lưu ý ngân hàng: Neo4j là lớp phân tích, không thay core; tuân thủ/bảo mật là ràng buộc cứng vì đồ thị gom định danh nhạy cảm; chất lượng dữ liệu quyết định giá trị; đừng ép mọi thứ thành graph; insight cần con người diễn giải.
• Kết series: bạn đã đi từ khái niệm → mô hình → Cypher → thuật toán → fraud/AML → vận hành → danh mục use case & chọn công cụ. Đủ để đánh giá và triển khai một sáng kiến đồ thị thực trong ngân hàng.