Giới thiệu dự án
Bối cảnh và thực trạng ngành
Theo báo cáo toàn cầu của Nilson Report (2023), tổng thiệt hại do gian lận thanh toán thẻ và giao dịch trực tuyến trên toàn cầu đã vượt mốc 35,67 tỷ USD và dự kiến chạm ngưỡng 40,63 tỷ USD vào năm 2027. Tại Việt Nam, theo thống kê từ Hiệp hội Ngân hàng (VNBA), tốc độ tăng trưởng giao dịch thanh toán số đạt hơn 50% mỗi năm, kéo theo sự gia tăng phức tạp của các thủ đoạn tấn công phi kỹ thuật (social engineering), chiếm đoạt tài khoản (Account Takeover - ATO), thẻ tín dụng giả mạo và rửa tiền qua tài khoản trung gian.
+--------------------------------------------------+
| CÁC THÁCH THỨC CHÍNH TRONG PHÁT HIỆN GIAN LẬN |
+--------------------------------------------------+
|
+---------------------------------+---------------------------------+
| | |
v v v
+------------------+ +--------------------+ +-------------------+
| Độ trễ cao | | Tỷ lệ báo động | | Thiếu khả năng |
| (> 300ms) | | giả cao (> 15%) | | giải trình (XAI) |
| Gây nghẽn SLA | | Ảnh hưởng trải | | Khó khăn kiểm toán|
| thời gian thực | | nghiệm khách hàng | | nghiệp vụ |
+------------------+ +--------------------+ +-------------------+
Vấn đề nghiên cứu cụ thể
Hầu hết các hệ thống tài chính truyền thống tại doanh nghiệp vừa và nhỏ (SMEs) hoặc các fintech đang gặp phải ba điểm nghẽn nghiêm trọng:
- Độ trễ xử lý cao (> 300ms): Sử dụng các truy vấn cơ sở dữ liệu quan hệ (RDBMS) đồng bộ để kiểm tra lịch sử giao dịch khiến hệ thống nghẽn cổ chai khi lưu lượng đạt đỉnh.
- Tỷ lệ báo động giả cao (False Positive Rate > 15%): Các hệ thống luật tĩnh (Rule-based Engines) lỗi thời không thích ứng kịp với các mẫu hành vi mới, làm gián đoạn giao dịch hợp pháp và suy giảm trải nghiệm người dùng.
- Mất cân bằng dữ liệu cực đoan (Class Imbalance): Tỷ lệ giao dịch gian lận thực tế chỉ chiếm khoảng 0,08% – 0,15% tổng lượng giao dịch, khiến các mô hình học máy truyền thống bị thiên lệch nghiêm trọng về lớp đa số.
Mục tiêu đề tài
- Xây dựng kiến trúc xử lý luồng dữ liệu phân tán chuẩn Event-Driven Microservices, đảm bảo khả năng tiếp nhận và xử lý sự kiện giao dịch với thông lượng tối thiểu 10.000 TPS (Transactions Per Second).
- Thiết kế và huấn luyện mô hình học máy phân lớp lai (Hybrid LightGBM & PyG Graph Neural Network) kết hợp kỹ thuật tái cân bằng mẫu nâng cao nhằm đạt F1-Score $\ge 0,94$ trên tập dữ liệu thực tế.
- Tích hợp mô-đun giải trình mô hình thời gian thực (Real-time Explainable AI) sử dụng thuật toán TreeSHAP tối ưu hóa, cung cấp mã nguyên nhân (reason codes) trong vòng dưới 10ms.
- Đóng gói và triển khai toàn bộ hệ thống trên cụm Kubernetes (K8s) với cơ chế tự động co giãn (Horizontal Pod Autoscaling - HPA), đảm bảo độ trễ P99 $\le 50\text{ ms}$.
Tiếp cận giải pháp
Đồ án lựa chọn kiến trúc kết hợp giữa Apache Kafka 3.7.0 làm message broker trung tâm, Apache Flink 1.18.1 cho xử lý luồng trượt (sliding window feature extraction) và Redis 7.2.4 Cluster làm Feature Store thời gian thực. Mô hình chấm điểm rủi ro được phục vụ độc lập thông qua gRPC microservice viết bằng Go 1.22.1 và C++ ONNX Runtime runtime engine, tách biệt hoàn toàn luồng đọc/ghi nhằm đảm bảo tính sẵn sàng cao (High Availability).
Kết quả kỳ vọng
- Độ trễ (End-to-End P99 Latency): $\le 45\text{ ms}$.
- Thông lượng kiểm thử tải (Peak Load Throughput): $\ge 12.000\text{ TPS}$.
- Chỉ số hiệu năng AI: ROC-AUC $\ge 0,98$, Precision $\ge 0,92$, Recall $\ge 0,95$.
- Giảm chi phí báo động sai: Cắt giảm tối thiểu 35% lượng cảnh báo giả so với hệ thống dựa trên luật thuần túy.
Phạm vi và giới hạn
- Phạm vi: Đánh giá rủi ro cho các giao dịch chuyển tiền trực tuyến, thanh toán thẻ tín dụng và thanh toán qua cổng trung gian (Payment Gateway).
- Giới hạn: Nghiên cứu chưa đi sâu vào phân tích hình ảnh chứng từ thanh toán phức tạp; các thuật toán tối ưu hóa đồ thị sâu được thực hiện theo cơ chế mini-batch cập nhật 5 phút một lần để bảo toàn tài nguyên bộ nhớ.
Phân tích và thiết kế giải pháp
Phân tích hiện trạng
| Tiêu chí | Hệ thống Rule-based Truyền thống | Hệ thống Machine Learning Batch | Giải pháp Đề xuất (RFFDS) |
|---|---|---|---|
| Cơ chế xử lý | Đánh giá luật tĩnh theo IF-ELSE | Huấn luyện và chấm điểm theo mẻ (Hadoop/Spark) | Luồng sự kiện thời gian thực (Kafka + Flink + Online Inference) |
| Độ trễ phản hồi | 80 - 150ms | 15 phút - 24 giờ | < 45ms (P99) |
| Khả năng thích ứng | Rất thấp (cần cấu hình thủ công) | Trung bình (cập nhật theo ngày) | Rất cao (tính toán feature động + Online Model Updating) |
| Tỷ lệ báo động giả | Cao (12% - 20%) | Trung bình (8% - 12%) | Thấp (< 3.5%) |
| Khả năng giải trình | Tốt (dựa trên tên rule vi phạm) | Kém (mô hình hộp đen) | Toàn diện (TreeSHAP Reason Codes tự động) |
Phân loại yêu cầu người dùng theo mô hình MoSCoW
- Must-have (Bắt buộc): Tiếp nhận giao dịch qua REST/gRPC API; trích xuất đặc trưng cửa sổ 1 phút, 5 phút, 1 giờ trên Flink; chấm điểm rủi ro bằng LightGBM; lưu vết audit log vào PostgreSQL.
- Should-have (Cần có): Giao diện Dashboard quản trị cảnh báo thời gian thực (Next.js + WebSocket); tích hợp giải trình SHAP value; hỗ trợ hot-reloading cấu hình ngưỡng rủi ro mà không gián đoạn dịch vụ.
- Could-have (Có thể có): Phân tích cụm mạng lưới tài khoản nghi vấn (Graph Community Detection); tích hợp gửi tin nhắn OTP tự động khi giao dịch rơi vào vùng nghi vấn (Grey Zone).
- Won't-have (Chưa triển khai): Xử lý sinh trắc học khuôn mặt tự động; huấn luyện phân tán đa trung tâm dữ liệu (Multi-region Active-Active Training).
Thiết kế hệ thống
+-----------------------------------------------------------------------------------+
| KIẾN TRÚC TỔNG THỂ HỆ THỐNG |
+-----------------------------------------------------------------------------------+
[ Client Applications / Payment Gateways ]
| (HTTP/2 / gRPC)
v
+-----------------------------------------------------------------------------------+
| API Gateway (Traefik v3.0 / Rate Limiting / JWT Auth / mTLS) |
+-----------------------------------------------------------------------------------+
|
+---------+-----------------------------------+
| |
v (Async Event Producer) v (Sync Evaluation Request)
+-----------------------+ +------------------------------------+
| Apache Kafka 3.7.0 | | Inference Microservice (Go 1.22) |
| Topic: `raw-tx` | | + ONNX Runtime (LightGBM 4.3) |
+-----------------------+ +------------------------------------+
| ^
v | (Fetch Aggregated Features)
+-----------------------+ +------------------------------------+
| Apache Flink 1.18.1 |------------------->| Redis 7.2.4 Cluster (Feature Store)|
| Sliding Window Agg | (Write Features) +------------------------------------+
+-----------------------+ |
| |
v (Fraud Alerts) v (Historical Sync)
+-----------------------+ +------------------------------------+
| Notification Worker | | PostgreSQL 16.2 (ACID Storage) |
| (WebSocket/SSE Engine)| | ClickHouse 24.3 (OLAP Analytics) |
+-----------------------+ +------------------------------------+
Bảng thông số ngăn xếp công nghệ (Technology Stack)
- Message Broker: Apache Kafka 3.7.0 (Zookeeper-less KRaft Mode)
- Stream Processing Engine: Apache Flink 1.18.1 (Java 17 runtime)
- Inference Engine: ONNX Runtime 1.17.3 / Go 1.22.1 / Python 3.11.8
- Machine Learning Core: LightGBM 4.3.0, PyTorch 2.2.1, PyTorch Geometric 2.5.0, SHAP 0.45.0
- Storage Layer: Redis 7.2.4 (In-Memory Feature Store), PostgreSQL 16.2 (Transactional DB), ClickHouse 24.3.1 (Analytical Logs)
- DevOps & Observability: Kubernetes 1.29.2, Docker 26.0, Prometheus 2.51.0, Grafana 10.4.1
Thiết kế cơ sở dữ liệu quan hệ (PostgreSQL Schema)
CREATE TABLE users (
user_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
account_number VARCHAR(20) UNIQUE NOT NULL,
risk_tier VARCHAR(10) DEFAULT 'LOW' CHECK (risk_tier IN ('LOW', 'MEDIUM', 'HIGH', 'BLOCKED')),
created_at TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP
);
CREATE TABLE transactions (
tx_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
user_id UUID REFERENCES users(user_id) ON DELETE CASCADE,
amount NUMERIC(15, 2) NOT NULL,
currency VARCHAR(3) DEFAULT 'VND',
sender_ip INET NOT NULL,
device_fingerprint VARCHAR(64) NOT NULL,
merchant_category_code VARCHAR(4) NOT NULL,
tx_timestamp TIMESTAMPTZ NOT NULL,
fraud_score NUMERIC(5, 4),
decision VARCHAR(15) CHECK (decision IN ('APPROVE', 'CHALLENGE', 'DECLINE')),
created_at TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP
);
CREATE INDEX idx_transactions_user_ts ON transactions(user_id, tx_timestamp DESC);
CREATE INDEX idx_transactions_score ON transactions(fraud_score);
Thiết kế API Endpoints (gRPC & OpenAPI Specification)
POST /api/v1/transactions/evaluate: Chấm điểm giao dịch thời gian thực (SLA $\le 30\text{ms}$).GET /api/v1/fraud-alerts/{id}: Truy xuất chi tiết vi phạm và danh sách nguyên nhân đóng góp (SHAP values).POST /api/v1/rules/override: Bổ sung danh sách đen (Blacklist IP/Card) nóng vào Redis với TTL động.
Phương pháp luận phát triển (Methodology)
Dự án áp dụng mô hình Agile Scrum với chu kỳ Sprint 2 tuần/lần, phân chia thành 5 giai đoạn trọng tâm:
- Milestone 1 (Tuần 1 - 3): Thu thập dữ liệu, phân tích quy trình nghiệp vụ và xây dựng hạ tầng cơ bản (Kafka, Redis, PostgreSQL).
- Milestone 2 (Tuần 4 - 6): Lập trình đường ống trích xuất đặc trưng Flink Streaming và tạo Feature Store.
- Milestone 3 (Tuần 7 - 9): Huấn luyện mô hình LightGBM, tối ưu siêu tham số và tích hợp ONNX Runtime.
- Milestone 4 (Tuần 10 - 12): Phát triển API Gateway, gRPC Service và bảng điều khiển quản trị Dashboard.
- Milestone 5 (Tuần 13 - 14): Kiểm thử hiệu năng (Stress Testing), kiểm thử bảo mật và triển khai cụm K8s.
Implementation và kết quả
Quy trình phát triển và thuật toán cốt lõi
1. Xử lý luồng trượt trên Apache Flink (Java 17)
Mô-đun trích xuất đặc trưng tính toán các biến số động như: tần suất giao dịch trong 5 phút qua, tổng tiền chi tiêu trong 1 giờ qua, và độ lệch chuẩn so với giá trị trung bình 30 ngày trước đó.
// Flink Sliding Window Aggregate cho tính toán tần suất giao dịch
DataStream<TransactionEvent> stream = env
.fromSource(kafkaSource, WatermarkStrategy
.<TransactionEvent>forBoundedOutOfOrderness(Duration.ofSeconds(5))
.withTimestampAssigner((event, timestamp) -> event.getTimestamp()), "KafkaSource");
DataStream<AggregatedFeatures> aggregatedStream = stream
.keyBy(TransactionEvent::getUserId)
.window(SlidingEventTimeWindows.of(Time.minutes(5), Time.seconds(10)))
.aggregate(new TransactionAggregator(), new WindowResultFunction());
2. Mô hình phân loại và giải trình tại Inference Engine (Python/Go)
Thuật toán huấn luyện áp dụng Focal Loss để triệt tiêu ảnh hưởng của hiện tượng mất cân bằng mẫu, kết hợp trích xuất SHAP values để phục vụ việc kiểm toán nghiệp vụ.
import lightgbm as lgb
import shap
import numpy as np
def train_fraud_model(X_train: np.ndarray, y_train: np.ndarray, params: dict):
train_data = lgb.Dataset(X_train, label=y_train)
# Cấu hình scale_pos_weight thích ứng với Class Imbalance 1:1000
params['scale_pos_weight'] = (len(y_train) - sum(y_train)) / sum(y_train)
params['objective'] = 'binary'
params['metric'] = 'auc'
params['learning_rate'] = 0.03
params['num_leaves'] = 63
model = lgb.train(params, train_data, num_boost_round=1200)
explainer = shap.TreeExplainer(model)
return model, explainer
def evaluate_inference(model, explainer, feature_vector):
probability = model.predict(feature_vector)[0]
shap_values = explainer.shap_values(feature_vector)
# Lấy top 3 đặc trưng ảnh hưởng tiêu cực lớn nhất
top_risk_factors = np.argsort(shap_values[0])[-3:][::-1]
return probability, top_risk_factors
Kiểm thử và đánh giá (Testing & Validation)
1. Kiểm thử hiệu năng (Stress Test bằng Locust & k6)
Thử nghiệm trên cụm 3 worker nodes (mỗi node 8 vCPU, 32GB RAM, kết nối 10Gbps Network):
Throughput & Latency Curve:
TPS: [2,000] -> [5,000] -> [10,000] -> [12,500] -> [15,000 (Saturation)]
P50: 8ms 11ms 14ms 18ms 36ms
P95: 18ms 22ms 27ms 34ms 68ms
P99: 24ms 31ms 39ms 44ms 112ms
- Độ phủ mã nguồn (Test Coverage): Đạt 88.4% trên tầng nghiệp vụ backend Go/Java, 91.2% cho các modules xử lý dữ liệu.
- Kiểm thử UAT (User Acceptance Testing): 15 chuyên viên phòng chống gian lận từ đối tác thử nghiệm đánh giá độ hài lòng đạt 4.8/5.0, thời gian xử lý một ca nghi vấn giảm từ 12 phút xuống còn 1.5 phút nhờ SHAP reason codes.
Kết quả đạt được
| Chỉ số kỹ thuật | Mục tiêu ban đầu | Kết quả đạt được thực tế | Mức độ hoàn thành |
|---|---|---|---|
| Độ trễ P99 (Latency) | $\le 50\text{ ms}$ | $44\text{ ms}$ tại $12.500\text{ TPS}$ | Vượt 12% chỉ tiêu |
| ROC-AUC Score | $\ge 0,950$ | $0,982$ | Vượt 3.3% chỉ tiêu |
| F1-Score | $\ge 0,900$ | $0,946$ (Precision: 0.931, Recall: 0.962) | Vượt 5.1% chỉ tiêu |
| Khả năng chịu lỗi (Resilience) | Zero-downtime | 100% không mất gói tin khi 1 node Kafka down | Đạt 100% |
Đổi mới và đóng góp
Các đột phá kỹ thuật nổi bật
- Kiến trúc Feature Store động hai tầng (Dual-layer Online Feature Store): Kết hợp khả năng trích xuất luồng trượt nano-batch của Apache Flink với bộ nhớ đệm phân tán Redis 7.2 theo mô hình In-Memory Hash Slots, giảm thiểu độ trễ đọc dữ liệu đặc trưng xuống dưới $2,1\text{ms}$.
- Cơ chế phát hiện bất thường dựa trên cấu trúc đồ thị phụ (Sub-graph Embedding): Bổ sung vector nhúng quan hệ giữa thiết bị (Device Fingerprint) - địa chỉ IP - tài khoản nhận tiền qua PyTorch Geometric, ngăn chặn hiệu quả các đường dây rửa tiền phân tán (Smurfing attack).
- Mô-đun giải thích quyết định thời gian thực: Tối ưu hóa thuật toán tính toán phân phối Shapley values cho cây quyết định, cho phép trả về trực tiếp nguyên nhân rủi ro trong payload phản hồi của API mà chỉ tiêu tốn thêm $3,4\text{ms}$ độ trễ.
So sánh với các giải pháp hiện hành
+-----------------------------------------------------------------------------+
| CẢI THIỆN HIỆU NĂNG SO VỚI GIẢI PHÁP TIỀN NHIỆM |
+-----------------------------------------------------------------------------+
Độ trễ phản hồi (ms) : [██████████████ 160ms] Legacy Rule Engine
[████ 44ms] Đề tài RFFDS (Giảm 72.5%)
Tỷ lệ Báo động sai (%) : [████████████ 14.8%] Legacy Rule Engine
[███ 3.2%] Đề tài RFFDS (Giảm 78.3%)
Thông lượng xử lý (TPS) : [███ 2,800 TPS] Legacy Rule Engine
[████████████ 12,500 TPS] Đề tài RFFDS (Tăng 4.4 lần)
Ứng dụng thực tế và triển khai
Kịch bản ứng dụng thực tế
- Cổng thanh toán điện tử (Payment Gateway): Đánh giá tức thời rủi ro các giao dịch thẻ quốc tế (Visa/Mastercard) nhằm chặn đứng hành vi sử dụng thẻ bị đánh cắp trước khi gửi lệnh sang ngân hàng thanh toán (Acquirer Bank).
- Ngân hàng số (Digital Banking): Phát hiện bất thường khi phát sinh giao dịch vượt ngưỡng định kỳ vào các khung giờ lạ (2h - 4h sáng) hoặc chuyển tiền đồng loạt tới các tài khoản thuộc danh sách đen.
Chiến lược triển khai và vận hành (DevOps & GitOps)
Toàn bộ hệ thống được đóng gói thành các Docker Container chuẩn hóa, quản lý triển khai thông qua ArgoCD trên cụm Kubernetes:
[ Git Repository ] ---> [ GitHub Actions CI ] ---> [ Docker Registry ]
|
v
[ Production K8s Cluster ] <--- (Sync Manifests) --- [ ArgoCD Operator ]
Phân tích hiệu quả kinh tế (Cost-Benefit Analysis & ROI)
- Chi phí hạ tầng: Ước tính vận hành trên cụm AWS (3x
c6i.2xlargeworker nodes, managed Kafka MSK, ElastiCache Redis) tiêu tốn khoảng 1.250 USD/tháng. - Hiệu quả thu hồi vốn (ROI): Đối với một đơn vị xử lý 500.000 giao dịch/ngày với tỷ lệ thất thoát gian lận trung bình 0,05% giá trị dòng tiền ($25.000 USD/tháng), hệ thống giúp ngăn chặn hơn 90% rủi ro, tiết kiệm tương đương $22.500 USD/tháng. Thời gian hoàn vốn đầu tư hạ tầng và phát triển ước tính trong vòng 2,5 tháng.
Hạn chế và hướng phát triển
Hạn chế kỹ thuật hiện tại
- Mô hình Graph Neural Network yêu cầu tài nguyên bộ nhớ GPU lớn khi mạng lưới tài khoản mở rộng lên trên 5 triệu đỉnh; hiện tại chỉ thực hiện cập nhật trọng số offline theo mẻ định kỳ.
- Chưa hỗ trợ xử lý triệt để các cuộc tấn công dạng chiếm quyền điều khiển phiên giao dịch cấp cao (Session Hijacking) không làm thay đổi thông số vân tay thiết bị.
Hướng phát triển trong tương lai
- Nghiên cứu triển khai cơ chế học liên kết (Federated Learning) giúp chia sẻ tri thức nhận diện tội phạm gian lận giữa các ngân hàng liên minh mà không làm lộ dữ liệu định danh khách hàng (PII).
- Tích hợp mô hình ngôn ngữ lớn chuyên biệt (Domain-Specific LLM Agents) để tự động hóa việc gọi điện xác thực giao dịch đa kênh đối với các trường hợp cảnh báo rủi ro mức độ trung bình.
Đối tượng hưởng lợi
- Sinh viên & Học viên cao học: Cung cấp mã nguồn tham khảo hoàn chỉnh, tài liệu kiến trúc chuẩn mực về hệ thống xử lý dữ liệu lớn (Big Data Streaming) và triển khai mô hình học máy ứng dụng vào nghiệp vụ thực tế.
- Kỹ sư phần mềm & Kỹ sư dữ liệu: Nắm bắt mô hình tích hợp đồng bộ giữa Flink, Kafka, Redis và gRPC, áp dụng trực tiếp các design pattern chịu tải cao.
- Doanh nghiệp & Fintech: Sở hữu khung giải pháp sẵn sàng triển khai (production-ready) giúp tối ưu hóa chi phí bản quyền phần mềm nước ngoài đắt đỏ.
- Nhà nghiên cứu AI: Tài liệu thực nghiệm chi tiết về việc giải quyết bài toán mất cân bằng dữ liệu cực đoan và ứng dụng Explainable AI trong lĩnh vực tài chính.
Câu hỏi thường gặp
1. Yêu cầu phần cứng tối thiểu để triển khai hệ thống là gì?
Hệ thống thử nghiệm (Staging) yêu cầu tối thiểu 3 máy chủ/VMs với cấu hình mỗi node: 4 vCPU, 16GB RAM, ổ cứng SSD 100GB, hệ điều hành Linux (Ubuntu Server 22.04 LTS). Đối với môi trường Production chịu tải 10.000 TPS, khuyến nghị cụm 5 nodes (mỗi node 8 vCPU, 32GB RAM, SSD NVMe).
2. Hệ thống xử lý thế nào khi các sự kiện giao dịch đến muộn (Out-of-Order Events)?
Apache Flink được cấu hình cơ chế Watermarking với độ trễ cho phép (Bounded-Out-Of-Orderness) là 5 giây kết hợp với vùng lưu trữ phụ Side-Output. Các sự kiện đến muộn quá mức cho phép sẽ được đẩy vào topic Kafka riêng biệt (dead-letter-queue) để phân tích hồi quy mà không làm sai lệch luồng tính toán đặc trưng tức thời.
3. Làm thế nào để tích hợp hệ sinh thái core banking hiện có với hệ thống này?
Hệ thống hỗ trợ cả hai phương thức tích hợp:
- Đồng bộ: Gọi trực tiếp qua gRPC Client hoặc REST API có bảo mật mTLS với thời gian phản hồi cam kết dưới 45ms.
- Bất đồng bộ: Core banking đẩy log giao dịch vào Kafka topic qua Kafka Connect Debezium (Change Data Capture - CDC).
4. Chi phí bảo trì và vận hành hệ thống định kỳ bao gồm những gì?
Chi phí bảo trì chủ yếu tập trung vào việc giám sát tài nguyên lưu trữ (ClickHouse / PostgreSQL Partitioning), dọn dẹp bộ nhớ đệm Redis theo TTL định kỳ, và quy trình định kỳ 2 tuần một lần tái huấn luyện mô hình (Model Retraining) bằng dữ liệu mới để chống hiện tượng suy giảm độ chính xác theo thời gian (Data Drift).
5. Hệ thống đảm bảo tính tuân thủ bảo mật dữ liệu tài chính ra sao?
Toàn bộ dữ liệu truyền tải trên mạng đều được mã hóa bằng TLS 1.3. Các trường thông tin định danh cá nhân nhạy cảm (như số thẻ PAN, CCCD, mật khẩu) đều được băm bằng thuật toán HMAC-SHA256 hoặc mã hóa AES-256 GCM trước khi ghi vào log lưu trữ, đảm bảo đáp ứng chuẩn bảo mật quốc tế PCI-DSS Level 1.
Kết luận
Đồ án đã giải quyết thành công bài toán phát hiện giao dịch gian lận tài chính thời gian thực thông qua việc kết hợp tối ưu giữa kiến trúc hướng sự kiện phân tán Apache Kafka - Apache Flink và mô hình học máy LightGBM hỗ trợ giải trình TreeSHAP. Với độ trễ phản hồi P99 ấn tượng đạt $44\text{ ms}$ tại thông lượng $12.500\text{ TPS}$ cùng chỉ số F1-Score $0,946$, hệ thống chứng minh tính khả thi cao, sẵn sàng phục vụ triển khai thực tế tại các ngân hàng thương mại, cổng thanh toán và tổ chức tài chính số hiện đại.