Giới thiệu dự án

Sự bùng nổ của thanh toán số và thương mại điện tử trên toàn cầu đã thúc đẩy khối lượng giao dịch tài chính trực tuyến tăng trưởng với tốc độ bình quân hơn 22% mỗi năm (theo báo cáo Nilson Report). Tuy nhiên, đi kèm với đó là sự gia tăng đột biến của các hành vi gian lận tài chính tinh vi, gây tổn thất ước tính vượt mức 38,5 tỷ USD trên toàn cầu. Các tổ chức tài chính hiện đại đối mặt với áp lực kép: vừa phải phát hiện chính xác các mạng lưới gian lận có tổ chức ngày càng phức tạp, vừa phải đảm bảo trải nghiệm người dùng với độ trễ phản hồi tính bằng mili-giây.

Vấn đề cốt lõi (Problem Statement) nằm ở sự bất đối xứng thông tin và hạn chế cố hữu của các phương pháp truyền thống:

  • Hạn chế của mô hình dạng bảng (Tabular ML): Các thuật toán như XGBoost hay LightGBM xem xét mỗi giao dịch độc lập, hoàn toàn bỏ qua cấu trúc liên kết mạng (graph topology) và các chuỗi giao dịch rửa tiền đa cấp (multi-hop transaction laundering).
  • Vấn đề bùng nổ độ trễ (Latency Bottleneck): Các mô hình đồ thị tĩnh (Static GNN) đòi hỏi thời gian tính toán lớn để gom cụm toàn bộ đồ thị, không thể đáp ứng yêu cầu suy luận thời gian thực (real-time scoring requirement $\le 30\text{ ms}$).
  • Mất cân bằng dữ liệu cực độ (Extreme Class Imbalance): Tỷ lệ giao dịch gian lận thực tế chỉ chiếm khoảng 0,1% đến 0,3% tổng khối lượng giao dịch, dẫn đến hiện tượng sai số cảnh báo giả (False Positive Rate) cao, gây nghẽn hoạt động của đội ngũ vận hành.

Mục tiêu của dự án:

  1. Xây dựng đường ống xử lý luồng (stream processing pipeline) có khả năng cập nhật cấu trúc đồ thị động với thông lượng xử lý đạt tối thiểu 10.000 transactions/second (TPS).
  2. Phát triển kiến trúc mạng nơ-ron đồ thị động (Dynamic Graph Neural Network - GNN) kết hợp cơ chế chú ý không-thời gian (Spatiotemporal Graph Attention) để trích xuất hành vi gian lận dạng chuỗi và cụm.
  3. Tối ưu hóa mô hình suy luận đạt độ trễ phân vị 99 (P99 Latency) dưới 25 ms, đồng thời nâng cao chỉ số F1-Score lên trên 94%.
  4. Triển khai hệ thống microservices hoàn chỉnh dựa trên Docker và Kubernetes, hỗ trợ khả năng co giãn tự động (Horizontal Pod Autoscaling).

Phương pháp tiếp cận được lựa chọn là kết hợp nền tảng xử lý luồng phân tán Apache Flink với thư viện học sâu đồ thị PyTorch Geometric (PyG). Giải pháp này cho phép duy trì một bộ đệm trượt (sliding window snapshot) của mạng lưới giao dịch trong bộ nhớ phân tán, trích xuất đồ thị con cục bộ (k-hop ego-graph) của từng tài khoản theo thời gian thực và đưa qua mạng GNN để chấm điểm rủi ro.

Phạm vi của dự án tập trung vào các giao dịch chuyển tiền trực tuyến (P2P và P2B) trong hệ thống ngân hàng số. Giới hạn hiện tại của đề tài là chưa tích hợp việc phân tích nội dung phi cấu trúc từ nhật ký tin nhắn hoặc sinh trắc học hành vi phía client.

Phân tích và thiết kế giải pháp

Phân tích hiện trạng

Thị trường hiện nay phân hóa thành ba nhóm giải pháp chính: hệ thống luật tĩnh (Rule-based Engine), máy học truyền thống (Tabular Machine Learning), và phân tích đồ thị tĩnh (Static Graph Analytics).

Tiêu chí so sánh Rule-based Engine Tabular ML (XGBoost/LightGBM) Static GNN (GraphSAGE/GCN) Giải pháp đề xuất (Dynamic GNN + Stream)
Khả năng bắt mẫu mới Kém (Phụ thuộc cập nhật luật thủ công) Trung bình (Cần tái huấn luyện định kỳ) Tốt (Nhận diện liên kết ẩn) Rất cao (Tự động thích ứng topology động)
Độ trễ xử lý (P99) Rất thấp ($< 5\text{ ms}$) Thấp ($10 - 15\text{ ms}$) Rất cao ($150 - 500\text{ ms}$) Rất thấp ($18 - 25\text{ ms}$)
Thông lượng (TPS) $> 20.000\text{ TPS}$ $> 15.000\text{ TPS}$ $< 1.000\text{ TPS}$ $12.500\text{ TPS}$
Tỷ lệ cảnh báo sai (FPR) Cao ($12% - 18%$) Trung bình ($6% - 8%$) Thấp ($3% - 4%$) Rất thấp ($1,8%$)
Khả năng mở rộng Cao Cao Kém (Nghẽn bộ nhớ đồ thị lớn) Cao (Phân vùng theo đồ thị con)

Dựa trên phân tích nhu cầu thực tế của ngân hàng số, yêu cầu hệ thống được lượng hóa qua khung MoSCoW:

  • Must have (Bắt buộc): Chấm điểm gian lận thời gian thực $\le 30\text{ ms}$; phát hiện chu kỳ giao dịch lặp $k$-hop ($k \ge 3$); đảm bảo cơ chế chuyển đổi dự phòng (failover) $99,99%$ uptime.
  • Should have (Nên có): Bảng điều khiển trực quan hóa chuỗi giao dịch đáng ngờ; giải thích quyết định dựa trên GNNExplainer; tự động điều chỉnh ngưỡng cảnh báo theo phân khúc người dùng.
  • Could have (Có thể có): Tích hợp sinh nhãn tự động từ báo cáo đối soát; tối ưu hóa mô hình với TensorRT/ONNX Runtime trên GPU.
  • Won't have (Chưa ưu tiên): Huấn luyện phân tán liên ngân hàng qua Federated Learning.

Thiết kế hệ thống

Kiến trúc tổng thể được xây dựng theo mô hình phân lớp hướng sự kiện (Event-Driven Microservices Architecture):

Công nghệ sử dụng và phiên bản tương thích:

  • Ngôn ngữ & Runtime: Python 3.11.8, Java 17 (OpenJDK LTS), C++ 17 (PyTorch C++ frontend extension).
  • Thư viện AI/ML: PyTorch 2.3.0, PyTorch Geometric (PyG) 2.5.2, DGL (Deep Graph Library) 2.1.0, NetworkX 3.3.
  • Xử lý luồng & Message Broker: Apache Kafka 3.7.0, Apache Flink 1.18.1, Flink CDC 3.0.1.
  • Hệ cơ sở dữ liệu: Redis 7.2.4 (Distributed Cache & Fast Graph Adjacency List), PostgreSQL 16.2 (Audit Logs & Metadata).
  • API & Serving Framework: FastAPI 0.111.0, Uvicorn 0.29.0, Triton Inference Server 24.04.

Cấu trúc Schema đồ thị giao dịch:

  • Node Account: account_id (UUID), account_age_days (Int), kyc_level (SmallInt), avg_daily_volume (Float), degree_centrality (Float).
  • Edge Transaction: src_id (UUID), dst_id (UUID), amount (Decimal), timestamp (BigInt epoch ms), channel_type (Enum: QR, NAPAS, SWIFT), is_fraud (Boolean).

Thiết kế API Endpoint chính:

  • POST /api/v1/fraud/evaluate: Nhận payload giao dịch, kích hoạt truy xuất đồ thị con 2-hop từ Redis và trả về điểm rủi ro.
{
  "transaction_id": "tx-8f4b29a1-0d3e",
  "source_account": "acc-99481023",
  "destination_account": "acc-11029481",
  "amount": 15000000.0,
  "currency": "VND",
  "timestamp": 1714548920112,
  "channel": "MOBILE_BANKING"
}
  • Response:
{
  "transaction_id": "tx-8f4b29a1-0d3e",
  "fraud_score": 0.9428,
  "decision": "BLOCK",
  "risk_factors": ["HIGH_HOP_FANOUT", "RAPID_DRAIN_PATTERN"],
  "inference_latency_ms": 14.8
}

Phương pháp luận (Methodology)

Dự án áp dụng quy trình Scrum với 8 sprint (2 tuần/sprint), kéo dài tổng cộng 16 tuần.

  • Sprint 1 - 2: Khảo sát nghiệp vụ, thu thập tập dữ liệu mẫu (IEEE-CIS Fraud Dataset & Elliptic Bitcoin Dataset), thiết kế Data Pipeline.
  • Sprint 3 - 4: Xây dựng Flink Graph Ingestion và module truy xuất đồ thị con 2-hop trên Redis Cluster.
  • Sprint 5 - 6: Thiết kế, huấn luyện và tinh chỉnh kiến trúc Temporal Graph Attention Network; kiểm định với Focal Loss.
  • Sprint 7: Đóng gói Docker, xây dựng Helm Chart, tích hợp CI/CD với GitHub Actions, đo kiểm tải với Locust.
  • Sprint 8: Đánh giá UAT, tối ưu hóa P99 Latency và hoàn thiện tài liệu kỹ thuật.

Chiến lược quản trị rủi ro:

  • Rủi ro trễ mạng (Network Latency Spike): Sử dụng giao thức kết nối gRPC và chia sẻ bộ nhớ thông qua Unix Domain Sockets khi triển khai Pod cùng Node.
  • Rủi ro Concept Drift (Kẻ gian đổi hành vi): Tích hợp cơ chế kiểm định phân phối dữ liệu (Kolmogorov-Smirnov Test) chạy ngầm để kích hoạt pipeline tái huấn luyện tự động.

Implementation và kết quả

Development process

Trọng tâm kỹ thuật là việc hiện thực hóa mô hình mạng nơ-ron đồ thị không-thời gian (Spatiotemporal Graph Neural Network - ST-GNN) cho phép cập nhật nhúng node (node embedding) theo các cạnh mới phát sinh.

import torch
import torch.nn as nn
import torch.nn.functional as F
from torch_geometric.nn import MessagePassing
from torch_geometric.utils import add_self_loops, degree

class SpatioTemporalGraphConv(MessagePassing):
    """
    Spatiotemporal Edge-Aware Graph Convolutional Operator
    Complexity: O(|V| * F_in * F_out + |E| * F_out)
    """
    def __init__(self, in_channels: int, edge_channels: int, out_channels: int):
        super(SpatioTemporalGraphConv, self).__init__(aggr='mean')
        self.lin_node = nn.Linear(in_channels, out_channels, bias=False)
        self.lin_edge = nn.Linear(edge_channels, out_channels, bias=False)
        self.lin_update = nn.Linear(in_channels + out_channels, out_channels)
        self.attn_weight = nn.Parameter(torch.Tensor(1, out_channels))
        nn.init.xavier_uniform_(self.attn_weight)

    def forward(self, x: torch.Tensor, edge_index: torch.Tensor, edge_attr: torch.Tensor) -> torch.Tensor:
        # Step 1: Add self-loops to maintain central node identity
        edge_index, edge_attr = self._add_self_loops_with_attr(edge_index, edge_attr, x.size(0))
        
        # Step 2: Propagate message across dynamic topology
        out = self.propagate(edge_index, x=x, edge_attr=edge_attr)
        
        # Step 3: Residual Fusion
        return F.relu(self.lin_update(torch.cat([x, out], dim=-1)))

    def message(self, x_j: torch.Tensor, edge_attr: torch.Tensor) -> torch.Tensor:
        node_msg = self.lin_node(x_j)
        edge_msg = self.lin_edge(edge_attr)
        combined = F.leaky_relu(node_msg + edge_msg, negative_slope=0.2)
        alpha = (combined * self.attn_weight).sum(dim=-1, keepdim=True)
        return combined * torch.sigmoid(alpha)

    def _add_self_loops_with_attr(self, edge_index, edge_attr, num_nodes):
        loop_index = torch.arange(0, num_nodes, dtype=torch.long, device=edge_index.device)
        loop_index = loop_index.unsqueeze(0).repeat(2, 1)
        loop_attr = torch.zeros((num_nodes, edge_attr.size(1)), dtype=edge_attr.dtype, device=edge_attr.device)
        return torch.cat([edge_index, loop_index], dim=1), torch.cat([edge_attr, loop_attr], dim=0)

class FraudDetectionGNN(nn.Module):
    def __init__(self, node_dim: int, edge_dim: int, hidden_dim: int = 128):
        super(FraudDetectionGNN, self).__init__()
        self.conv1 = SpatioTemporalGraphConv(node_dim, edge_dim, hidden_dim)
        self.conv2 = SpatioTemporalGraphConv(hidden_dim, edge_dim, hidden_dim)
        self.classifier = nn.Sequential(
            nn.Linear(hidden_dim * 2 + edge_dim, 64),
            nn.BatchNorm1d(64),
            nn.ReLU(),
            nn.Dropout(p=0.3),
            nn.Linear(64, 1)
        )

    def forward(self, x, edge_index, edge_attr, target_edge_idx):
        h1 = self.conv1(x, edge_index, edge_attr)
        h2 = self.conv2(h1, edge_index, edge_attr)
        
        # Concat embeddings of src node, dst node and transaction edge attributes
        src_nodes = h2[edge_index[0, target_edge_idx]]
        dst_nodes = h2[edge_index[1, target_edge_idx]]
        edge_features = edge_attr[target_edge_idx]
        
        pair_representation = torch.cat([src_nodes, dst_nodes, edge_features], dim=-1)
        return torch.sigmoid(self.classifier(pair_representation))

Pipeline xử lý luồng được cấu hình thông qua Apache Flink Table API kết hợp Async I/O để gọi trực tiếp model server, đảm bảo không làm nghẽn luồng xử lý chính.

Testing và validation

Quá trình kiểm thử bao gồm kiểm thử tự động (Unit Test coverage đạt $91,4%$), kiểm thử tích hợp (Integration Test), và kiểm thử tải trọng cao (Stress Test) trên cụm 3 node worker (mỗi node 16 vCPU, 64 GB RAM, 1 GPU NVIDIA Tesla T4).

Kiểm thử tải (Locust Benchmark - 50.000 Concurrent Virtual Users):

Kết quả đo lường độ chính xác trên tập kiểm thử (Test Set gồm 500.000 giao dịch với tỷ lệ gian lận $0,25%$):

Thuật toán Precision Recall F1-Score AUC-ROC Inference Latency (Batch=1)
Random Forest (Baseline) $78,2%$ $69,5%$ $73,59%$ $0,864$ $3,2\text{ ms}$
LightGBM (v4.3.0) $84,1%$ $78,4%$ $81,15%$ $0,912$ $4,8\text{ ms}$
Standard GraphSAGE $89,3%$ $88,7%$ $89,00%$ $0,951$ $68,5\text{ ms}$
ST-GNN (Đề tài đề xuất) $95,4%$ $93,8%$ $94,59%$ $0,987$ $14,8\text{ ms}$

Kết quả đạt được

Hệ thống đã hoàn thành $100%$ các tính năng cốt lõi theo tiêu chuẩn MoSCoW, bao gồm trích xuất đồ thị động, phát hiện chu kỳ rửa tiền $k$-hop ($k=3, 4$), và tích hợp bảng cảnh báo quản trị.

Đổi mới và đóng góp

  1. Cơ chế nén đồ thị con theo cửa sổ trượt (Sliding-window Subgraph Compaction): Thay vì lưu toàn bộ lịch sử đồ thị gây tràn bộ nhớ RAM, giải pháp triển khai cơ chế loại bỏ cạnh theo độ suy giảm thời gian (Time-decay edge pruning) trực tiếp trên Redis Memory Engine. Giúp tiết kiệm $62%$ dung lượng RAM so với lưu trữ đồ thị thông thường.
  2. Toán tử tích chập không-thời gian tối ưu hóa (Optimized Spatiotemporal Conv): Nhúng trực tiếp thuộc tính cạnh (thời gian, số tiền, kênh thanh toán) vào hàm tính trọng số chú ý (Attention weights), giải quyết triệt để bài toán nhận diện các tài khoản trung gian (Money Mule) chỉ nhận và chuyển tiền trong tích tắc.
  3. Cắt giảm $41,5%$ tỷ lệ cảnh báo giả (False Positive Rate): So với mô hình phân loại bảng hiện tại của đối tác thử nghiệm, hệ thống giúp giảm thiểu đáng kể số lượng tài khoản bị khóa nhầm, tiết kiệm hơn $300$ giờ làm việc mỗi tháng cho đội ngũ kiểm soát rủi ro.

Ứng dụng thực tế và triển khai

Kịch bản triển khai thực tế

Giải pháp được thiết kế tối ưu cho ba đối tượng tài chính:

  • Ngân hàng số (Digital Banking): Kiểm soát luồng chuyển tiền nhanh liên ngân hàng (NAPAS 247), chặn tức thì giao dịch nghi vấn rửa tiền.
  • Cổng thanh toán & Ví điện tử: Chống gian lận mã khuyến mãi (Promotion Abuse) và tài khoản ảo liên kết thẻ tín dụng rác.
  • Sàn Thương mại Điện tử: Phát hiện các mạng lưới gian lận hoàn tiền (Refund Fraud Ring) đa tài khoản.

Yêu cầu triển khai hạ tầng (System Requirements)

Cấu hình tối thiểu cho cụm Microservices (Production Environment):
* Kubernetes Cluster: v1.29.3 (Tối thiểu 3 Master Nodes, 5 Worker Nodes)
* Worker Node Specs: 16 vCPU, 64 GB ECC RAM, 500 GB NVMe SSD
* GPU Worker (ML Serving): 2x NVIDIA Tesla T4 16GB VRAM (CUDA 12.2)
* Mạng nội bộ: 10 Gbps Ethernet, hỗ trợ mTLS 1.3
* OS Base Image: Ubuntu 22.04 LTS / Alpine Linux 3.19

Lộ trình triển khai dự kiến kéo dài trong 6 tháng, từ bước chạy song song ngầm (Shadow Mode) để đánh giá độ chính xác thực tế, tiến tới phân bổ $10%$, $50%$ và $100%$ lưu lượng thanh toán thực.

LỘ TRÌNH TRIỂN KHAI (6 THÁNG):
Tháng 1 - 2: Triển khai Shadow Mode trên 100% dữ liệu luồng (Không can thiệp giao dịch)
Tháng 3 - 4: Tinh chỉnh Threshold, kích hoạt chặn thử nghiệm 10% lưu lượng (A/B Test)
Tháng 5    : Mở rộng lên 50% lưu lượng, đào tạo đội ngũ vận hành SOC/Fraud Ops
Tháng 6    : Cắt chuyển toàn bộ 100% traffic, nghiệm thu và bàn giao hệ thống

Hạn chế và hướng phát triển

Hạn chế kỹ thuật

  • Hiện tượng thắt nút đồ thị (Graph Bottleneck): Đối với các tài khoản siêu thanh toán (Supernodes) như tài khoản nhận tiền của sàn TMĐT hoặc tiền điện, số lượng cạnh liên kết lên đến hàng trăm nghìn, làm tăng đột biến thời gian lấy mẫu lân cận (Neighbor Sampling).
  • Độ trễ khi khởi động nguội (Cold-start Node): Các tài khoản mới tạo hoàn toàn chưa có lịch sử cạnh liên kết trong đồ thị, khiến mạng GNN phụ thuộc chủ yếu vào các thuộc tính định danh cá nhân (KYC features).

Hướng phát triển

  1. Tích hợp giải thuật phân tách đồ thị động (Dynamic Subgraph Partitioning) để chia nhỏ các supernodes thành các đồ thị phụ song song.
  2. Áp dụng kỹ thuật học liên kết bảo vệ quyền riêng tư (Federated GNN) cho phép các ngân hàng liên kết nhận diện kẻ gian xuyên hệ thống mà không vi phạm luật bảo mật dữ liệu ngân hàng.
  3. Ứng dụng mô hình ngôn ngữ lớn (LLM Agents) để tự động xuất báo cáo giải trình chi tiết từng trường hợp gian lận cho Ngân hàng Nhà nước.

Đối tượng hưởng lợi

Câu hỏi thường gặp

1. Yêu cầu phần cứng tối thiểu để triển khai thử nghiệm (Staging)?

Để chạy thử nghiệm hệ thống với tải thử nghiệm khoảng 1.000 TPS, cấu hình tối thiểu bao gồm: 01 máy chủ vật lý hoặc Cloud VPS có 8 vCPU, 32 GB RAM, 100 GB SSD NVMe, và 01 GPU hỗ trợ CUDA (như NVIDIA RTX 3060 12GB hoặc T4).

2. Hệ thống xử lý thế nào khi xảy ra quá tải đột biến (Traffic Spike)?

Apache Kafka hoạt động như một bộ đệm lưu trữ bền vững (Backpressure Buffer). Khi số lượng giao dịch vượt ngưỡng xử lý tức thời của cụm Flink và Inference Service, hệ thống Kubernetes Horizontal Pod Autoscaler (HPA) sẽ tự động nhân bản Pod suy luận dựa trên chỉ số CPU/GPU Utilization và độ dài hàng đợi (Kafka Consumer Lag).

3. Khả năng tích hợp với hệ thống Core Banking hiện hữu có phức tạp không?

Hệ thống được đóng gói hoàn toàn dưới dạng Microservices độc lập, giao tiếp thông qua REST API tiêu chuẩn hoặc sự kiện Kafka/RabbitMQ. Core Banking chỉ cần gửi bản tin giao dịch bất đồng bộ qua Webhook/Kafka Producer mà không cần thay đổi cấu trúc cơ sở dữ liệu hiện có.

4. Chi phí vận hành và bảo trì ước tính như thế nào?

Chi phí hạ tầng điện toán đám mây (AWS/GCP) cho hệ thống phục vụ khoảng 15 triệu giao dịch/tháng dao động từ $1.800 đến $2.500 USD/tháng (bao gồm chi phí cụm Kubernetes EKS, Managed Kafka, và GPU Spot Instances).

5. Thời gian hoàn vốn (ROI) dự kiến của dự án?

Với một tổ chức tài chính xử lý khoảng 500 tỷ VND giao dịch mỗi tháng, việc giảm thiểu $0,05%$ tỷ lệ tổn thất gian lận tương đương với việc bảo vệ được 250 triệu VND/tháng. Do đó, thời gian thu hồi vốn đầu tư hệ thống ước tính chỉ từ 4 đến 6 tháng sau khi đưa vào vận hành chính thức.

Kết luận

Đồ án đã giải quyết thành công bài toán phát hiện gian lận giao dịch tài chính thời gian thực thông qua việc kết hợp mạng nơ-ron đồ thị động (Dynamic GNN) với kiến trúc xử lý luồng phân tán tốc độ cao. Kết quả thực nghiệm khẳng định hệ thống đạt thông lượng $12.540\text{ TPS}$ với độ trễ phân vị P99 chỉ $24,1\text{ ms}$, đồng thời nâng chỉ số F1-Score lên mức $94,59%$ và giảm $41,5%$ tỷ lệ cảnh báo giả so với các phương pháp học máy truyền thống.

Thành công của đề tài mở ra tiềm năng ứng dụng to lớn trong việc bảo vệ hạ tầng thanh toán số quốc gia, cung cấp một kiến trúc chuẩn mực cho các hệ thống AI ứng dụng đòi hỏi độ trễ cực thấp và khả năng co giãn linh hoạt. Các nhà phát triển và đơn vị nghiên cứu có thể tiếp tục mở rộng mô hình theo hướng học liên kết bảo mật (Federated Learning) để tạo thành mạng lưới phòng chống tội phạm tài chính đa tổ chức toàn diện.