Thực chiến ngân hàng: kiểm thử chống gian lận & hạn mức thời gian thực

1. Bối cảnh nghiệp vụ: chống gian lận & hạn mức thời gian thực

Ngân hàng số hiện đại xử lý hàng chục triệu giao dịch mỗi ngày qua thẻ, chuyển khoản nhanh (NAPAS 24/7), ví điện tử và cổng thanh toán thương mại điện tử. Mỗi giao dịch đi qua một hệ thống chấm điểm gian lận thời gian thực trước khi được duyệt, giữ lại (hold) hoặc từ chối. Yêu cầu nghiệp vụ khắt khe: quyết định phải ra trong dưới 150-200 mili-giây để không làm chậm trải nghiệm khách hàng tại POS hay ATM, đồng thời phải đủ chính xác để không bỏ lọt kẻ gian và không làm phiền khách hàng thật. Đây là bài toán kinh điển của ngành ngân hàng, nơi tốc độ và độ chính xác luôn mâu thuẫn nhau và đội QA phải kiểm chứng cả hai.

Hệ thống phải đồng thời quản lý hạn mức (limits) theo nhiều chiều: hạn mức giao dịch đơn, hạn mức theo ngày, theo tháng, theo kênh (ATM, POS, online), theo loại thẻ và theo hồ sơ rủi ro khách hàng. Hạn mức và chống gian lận liên kết chặt chẽ: một giao dịch có thể hợp lệ về hạn mức nhưng bị chặn vì bất thường hành vi (velocity bất thường, đổi vị trí địa lý phi thực tế, thiết bị lạ chưa từng đăng nhập). Ngược lại, một giao dịch trong ngưỡng rủi ro thấp nhưng vượt hạn mức vẫn phải bị từ chối cứng theo quy định NHNN và chính sách nội bộ. QA cần hiểu rõ ranh giới giữa hai luồng kiểm soát này để thiết kế ca kiểm thử đúng.

Về mặt tổ chức, dự án này thường có SLA nghiêm ngặt: p99 độ trễ dưới 200ms, tỷ lệ khả dụng 99.99%, và các chỉ số chất lượng mô hình được báo cáo hàng tuần cho ủy ban rủi ro (Precision, Recall, False Positive Rate). Đội test không chỉ kiểm thử chức năng mà còn phải hợp tác với đội Data Science để xác định oracle đúng — tức là tiêu chuẩn đúng/sai cho từng quyết định — và với đội hạ tầng để đo hiệu năng dưới tải cao điểm (giờ lương, ngày lễ, Black Friday). Bài viết này trình bày toàn bộ vòng đời kiểm thử cho hệ thống chống gian lận và hạn mức thời gian thực, từ kiến trúc, mô hình dữ liệu, chiến lược test, ma trận ca, đến CI/CD đo lường chất lượng mô hình và tải.

2. Kiến trúc hệ thống và luồng quyết định thời gian thực

Kiến trúc điển hình gồm bốn lớp: cổng nhận giao dịch (transaction gateway), kho đặc trưng thời gian thực (feature store) tổng hợp velocity/geo/device, công cụ luật (rule engine) áp hạn mức và luật tĩnh, và mô hình học máy chấm điểm bất thường. Một bộ tổng hợp quyết định (decision aggregator) kết hợp kết quả rule engine và điểm ML để ra quyết định cuối: APPROVE, HOLD (yêu cầu xác thực bổ sung như OTP) hoặc DECLINE. Toàn bộ luồng này phải hoàn tất trong ngân sách thời gian rất hẹp, thường dưới 150ms, nên các thành phần được thiết kế bất đồng bộ, có cache và fallback khi một dịch vụ con chậm hoặc lỗi.

Feature store là trái tim của hệ thống: nó duy trì cửa sổ trượt (sliding window) cho từng khách hàng, ví dụ số giao dịch trong 1 phút/1 giờ/1 ngày gần nhất, tổng số tiền đã chi trong ngày, danh sách thiết bị đã từng dùng, và tọa độ địa lý của giao dịch gần nhất để tính vận tốc di chuyển ảo (velocity geo-jump). Dữ liệu này thường lưu trong bộ nhớ tốc độ cao (Redis hoặc tương đương) để đọc/ghi dưới mili-giây. Một điểm QA cần đặc biệt lưu ý là tính nhất quán cuối cùng (eventual consistency) giữa feature store và cơ sở dữ liệu giao dịch gốc — độ trễ đồng bộ có thể tạo ra khoảng hở (race window) mà kẻ gian lợi dụng để thực hiện nhiều giao dịch đồng thời vượt hạn mức trước khi hệ thống kịp cập nhật.

Ngoài luồng đồng bộ, hệ thống còn có luồng bất đồng bộ (asynchronous) để cập nhật lại nhãn (label) sau khi có xác nhận từ khách hàng hoặc điều tra viên (ví dụ khách hàng báo giao dịch bị mất cắp thẻ), phục vụ việc huấn luyện lại mô hình. Ngoài ra còn có kênh quan sát (observability) ghi log mọi quyết định kèm lý do (rule nào kích hoạt, điểm ML bao nhiêu) để phục vụ điều tra khiếu nại và kiểm toán tuân thủ. Việc thiết kế test không thể tách rời các luồng phụ này vì chúng ảnh hưởng trực tiếp tới khả năng tái tạo (reproducibility) của một quyết định khi cần giải trình với khách hàng hoặc cơ quan quản lý.

3. Mô hình dữ liệu, bất biến nghiệp vụ và Oracle FP/FN

Mô hình dữ liệu cốt lõi xoay quanh thực thể Transaction (mã giao dịch, số tiền, thời gian, kênh, thiết bị, tọa độ), Customer (hồ sơ rủi ro, hạn mức cấu hình), FeatureSnapshot (trạng thái cửa sổ trượt tại thời điểm quyết định) và Decision (kết quả, lý do, điểm số, độ trễ xử lý). Bất biến nghiệp vụ (invariant) quan trọng nhất là: tổng số tiền các giao dịch APPROVE trong một ngày của một khách hàng không bao giờ được vượt quá hạn mức ngày đã cấu hình tại thời điểm giao dịch, kể cả khi có nhiều giao dịch đồng thời cạnh tranh cùng lúc (concurrent). Đây là bất biến bắt buộc phải giữ đúng tuyệt đối, khác với các quyết định gian lận vốn mang tính xác suất.

Bất biến thứ hai liên quan đến tính đơn điệu của rủi ro: nếu một giao dịch bị đánh dấu DECLINE bởi một rule cứng (ví dụ vượt hạn mức, thẻ bị khóa), thì không có điểm ML nào có thể lật ngược quyết định thành APPROVE — rule cứng luôn có quyền phủ quyết cao nhất. Bất biến thứ ba là tính toàn vẹn của feature store: mọi giao dịch APPROVE phải được phản ánh vào cửa sổ trượt trước khi giao dịch tiếp theo của cùng khách hàng được xử lý, nếu không sẽ xảy ra hiện tượng 'double spending' vượt hạn mức do đọc dữ liệu cũ.