Giới thiệu dự án

Bối cảnh và thực trạng ngành

Trong kỷ nguyên số hóa tài chính, mức độ kết nối và tự động hóa trong các giao dịch ngân hàng thương mại ngày càng mở rộng, kéo theo sự phức tạp của các rủi ro gian lận và vi phạm quy chế. Theo báo cáo từ Ủy ban Thương mại Quốc tế Hoa Kỳ (USITC) và các tổ chức kiểm toán quốc tế, các định chế tài chính toàn cầu phải chi trả hàng tỷ USD mỗi năm để xử lý các vấn đề liên quan đến tuân thủ pháp lý, phòng chống rửa tiền (AML - Anti-Money Laundering) và bảo mật dữ liệu theo chuẩn GDPR (với mức phạt vi phạm lên tới 4% doanh thu toàn cầu).

Tại Việt Nam, Ngân hàng TMCP Quân đội (MB) là tập đoàn tài chính đa ngành với hơn 296 điểm giao dịch, gần 15.000 cán bộ nhân viên cùng 6 công ty thành viên. Để đảm bảo an toàn vận hành, Khối Kiểm soát nội bộ – đặc biệt là Bộ phận Tuân thủ (BPTT) – đóng vai trò then chốt trong việc giám sát, phát hiện và xử lý các hành vi vi phạm tuân thủ (VPTT).

                      +------------------------------------------+
                      |         Hệ thống Nguồn (Data Sources)    |
                      |   Core Banking T24, HRIS, Active Directory|
                      +--------------------+---------------------+
                                           | (ETL Batch/CDC)
                                           v
+-----------------------------------------------------------------------------------+
|               HỆ THỐNG QUẢN LÝ TUÂN THỦ (COMPLIANCE MANAGEMENT SYSTEM - CMS)       |
|                                                                                   |
|  +-----------------------+   +-----------------------+   +---------------------+  |
|  | Engine Kịch bản       |   | Module Chấm điểm      |   | Workflow Xử lý &    |  |
|  | (Rule-based Scenario) |-->| Cảnh báo Rủi ro       |-->| Giải trình          |  |
|  | Auto / Manual / Alert |   | (F2-Score Calibrated) |   | BPTT <-> Chi nhánh  |  |
|  +-----------------------+   +-----------------------+   +---------------------+  |
+------------------------------------------+----------------------------------------+
                                           | (Direct API / Embedding)
                                           v
                      +------------------------------------------+
                      |     Báo cáo Quản trị & Tích hợp          |
                      |    Tableau Server, ECM, SMTP Server      |
                      +------------------------------------------+

Vấn đề nghiên cứu (Problem Statement)

Quy trình kiểm soát tuân thủ truyền thống tại ngân hàng đang đối mặt với các điểm nghẽn nghiêm trọng:

  • Phương pháp rà soát phân tán, thủ công: BPTT thực hiện kiểm tra theo phương thức thủ công ("đi từng ngõ, gõ từng nhà, rà từng người"), dẫn đến tình trạng quá tải khi số lượng hồ sơ nghi ngờ vi phạm phát sinh hàng trăm ca/ngày.
  • Dữ liệu phân mảnh và thiếu chuẩn hóa: Dữ liệu giao dịch, nhật ký người dùng phân tán trên hệ thống ngân hàng lõi (Core Banking Temenos T24), hệ thống nhân sự (HRIS) và hệ thống quản trị quy trình (BPM), gây khó khăn cho việc đối soát tập trung.
  • Thiếu cơ chế cảnh báo sớm và phân vùng rủi ro: Chưa có công cụ tự động phân loại, chấm điểm ưu tiên các trường hợp vi phạm có mức độ nghiêm trọng cao để tối ưu nguồn lực điều tra.

Mục tiêu dự án

  1. Khảo sát, đánh giá toàn diện các giải pháp quản lý tuân thủ thương mại quốc tế (SAP ETD, MetricStream, ServiceNow GRC) để xác định bài toán phù hợp cho MB.
  2. Phân tích và thiết kế mô hình hệ thống Phần mềm Quản lý tuân thủ (Compliance Management System - CMS) tự động hóa khép kín.
  3. Xây dựng phương pháp luận chấm điểm cảnh báo sớm đa cấu phần tích hợp chỉ số F2-Score.
  4. Phát triển kịch bản mẫu phát hiện tài khoản đăng nhập Temenos T24 đồng thời trên nhiều thiết bị.
  5. Hiện thực hóa phần mềm CMS trên nền tảng web tích hợp hạ tầng công nghệ thông tin ngân hàng.

Giải pháp đề xuất

Xây dựng hệ thống CMS nội bộ độc lập, kết nối tự động với Kho dữ liệu (Data Warehouse - DWH) thông qua công cụ trích xuất và biến đổi dữ liệu (ETL), tích hợp xác thực tập trung qua Microsoft Active Directory (MS AD), lưu trữ hồ sơ trên hệ thống Quản lý nội dung doanh nghiệp (ECM) và trực quan hóa phân tích qua Tableau Server.

Kết quả đầu ra kỳ vọng

  • Giảm 70% thời gian phát hiện và chuyển giao hồ sơ nghi ngờ vi phạm xuống chi nhánh.
  • Tự động hóa 100% quy trình thu thập dữ liệu và khớp nối logic vi phạm cho các kịch bản chuẩn hóa.
  • Đảm bảo độ chính xác phát hiện qua mô hình chấm điểm định lượng đa tiêu chí.

Phạm vi và giới hạn

  • Phạm vi ứng dụng: Triển khai tại Khối Kiểm soát nội bộ và các chi nhánh, phòng giao dịch thuộc hệ thống MB.
  • Giới hạn kỹ thuật: Dữ liệu kịch bản được đồng bộ định kỳ theo lô (Batch Processing) từ DWH; các tính năng xem tệp tin phân giải cao phụ thuộc vào giao thức kết nối với hệ thống ECM hiện hữu.

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

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

So sánh giải pháp thương mại và giải pháp tự phát triển

Qua khảo sát thực tế từ Gartner Peer Insights và thực trạng hạ tầng của MB, bảng so sánh dưới đây làm rõ tính khả thi của giải pháp CMS tự phát triển:

Tiêu chí SAP Enterprise Threat Development MetricStream Compliance Management ServiceNow GRC Hệ thống CMS đề xuất
Chi phí bản quyền Rất cao (License doanh nghiệp) ~$180.000 / 36 tháng ~$100/user/tháng Tối ưu chi phí bản quyền
Thời gian triển khai 6 – 12 tháng 3 – 6 tháng 6 – 9 tháng 3 – 4 tháng (Prototype/MVP)
Khả năng tùy biến Khó tùy biến kịch bản đặc thù Phụ thuộc nhà cung cấp Cần mua thêm module Làm chủ 100% mã nguồn
Tích hợp Core T24 & HRIS Cần middleware phức tạp Cần cấu hình API tùy chỉnh Phức tạp, chi phí cao Tích hợp trực tiếp qua DWH/ETL
Độ phức tạp vận hành Đòi hỏi chuyên gia SAP Đòi hỏi đào tạo chuyên sâu Giao diện quản trị phức tạp Tối ưu theo quy trình nội bộ MB

Ma trận ưu tiên yêu cầu người dùng (MoSCoW)

  • Must have (Bắt buộc):
    • Đồng bộ tự động dữ liệu nhật ký từ DWH qua IBM InfoSphere DataStage.
    • Phân loại và xử lý 3 loại kịch bản: Tự động, Thủ công, Cảnh báo.
    • Module chấm điểm cảnh báo vi phạm đa cấu phần.
    • Phân quyền kiểm soát truy cập dựa trên vai trò (RBAC) tích hợp MS AD (SSO).
    • Quy trình giải trình hai chiều giữa BPTT và Chi nhánh.
  • Should have (Nên có):
    • Nhúng bảng điều khiển báo cáo trực quan từ Tableau Server.
    • Tự động gửi email cảnh báo thông qua SMTP Server nội bộ.
    • Quản lý mở/đóng kỳ tuân thủ độc lập cho từng kịch bản.
  • Could have (Có thể có):
    • Tải lên danh sách vi phạm bổ sung bằng tệp mẫu Excel định dạng chuẩn.
    • Lưu vết lịch sử thay đổi tham số chấm điểm hệ thống (Audit Log).
  • Won't have (Chưa thực hiện ở giai đoạn này):
    • Xử lý luồng dữ liệu thời gian thực dạng Streaming (Real-time Event Processing).
    • Tự động phân tích ngôn ngữ tự nhiên (NLP) cho nội dung giải trình của chi nhánh.

Thiết kế hệ thống

Kiến trúc tổng thể và ngăn xếp công nghệ (Technology Stack)

Hệ thống được thiết kế theo kiến trúc phân tầng (Layered Architecture), đảm bảo tính module hóa, tính sẵn sàng cao và bảo mật ngân hàng:

graph TD
    subgraph Client_Layer ["Tầng Giao diện (Presentation Layer)"]
        UI_BPTT["Giao diện BPTT (React.js 18.2)"]
        UI_Branch["Giao diện Chi nhánh (React.js 18.2)"]
        Tableau_Embed["Dashboard nhúng Tableau Server v2023.2"]
    end

    subgraph App_Layer ["Tầng Dịch vụ Ứng dụng (Application Layer)"]
        Gateway["API Gateway / Reverse Proxy (Nginx)"]
        Auth_Service["Xác thực MS Active Directory (OAuth2/SSO)"]
        Core_App["CMS Core Engine (Java 17 / Spring Boot 3.2)"]
        Rule_Engine["Scenario & Scoring Processor"]
    end

    subgraph Data_Layer ["Tầng Dữ liệu & Tích hợp (Data & Integration Layer)"]
        CMS_DB[("Oracle Database 19c Enterprise")]
        ETL_Tool["IBM InfoSphere DataStage v11.7"]
        DWH[("Enterprise Data Warehouse - DWH")]
        ECM_Sys["Hệ thống Quản lý File (ECM API)"]
        Mail_Sys["Email Server (SMTP)"]
    end

    UI_BPTT --> Gateway
    UI_Branch --> Gateway
    Tableau_Embed --> Gateway
    Gateway --> Auth_Service
    Gateway --> Core_App
    Core_App --> Rule_Engine
    Rule_Engine --> CMS_DB
    DWH --> ETL_Tool
    ETL_Tool --> CMS_DB
    Core_App --> ECM_Sys
    Core_App --> Mail_Sys
  • Frontend: React.js 18.2, Ant Design 5.x, Axios.
  • Backend: Java 17, Spring Boot 3.2 (Spring Data JPA, Spring Security, Hibernate 6).
  • Cơ sở dữ liệu: Oracle Database 19c Enterprise Edition.
  • Tích hợp & ETL: IBM InfoSphere DataStage 11.7, RESTful API, SMTP Protocol.
  • Phân tích dữ liệu: Tableau Server 2023.2 API.

Thiết kế Cơ sở dữ liệu (Database Schema)

Mô hình cơ sở dữ liệu vật lý bao gồm các thực thể cốt lõi phục vụ quá trình bắt lỗi và xử lý vòng đời vi phạm:

+---------------------------------------------------------------------------------+
|                                CMS_SCENARIO                                     |
+---------------------------------------------------------------------------------+
| PK SCENARIO_ID        VARCHAR2(50)  | Mã định danh kịch bản                     |
|    SCENARIO_NAME      VARCHAR2(255) | Tên kịch bản (VD: User login multiple IP) |
|    SCENARIO_TYPE      VARCHAR2(20)  | Loại: AUTO / MANUAL / ALERT               |
|    GROUP_CODE         VARCHAR2(50)  | Nhóm: HE_THONG_THONG_TIN / TIN_DUNG...   |
|    RISK_LEVEL         VARCHAR2(20)  | Mức độ rủi ro: LOW / MEDIUM / HIGH / CRIT |
|    CRON_EXPRESSION    VARCHAR2(50)  | Tần suất chạy batch                       |
|    IS_ACTIVE          NUMBER(1)     | Trạng thái kích hoạt (1/0)                |
+---------------------------------------------------------------------------------+
                                      | 1
                                      |
                                      | N
+---------------------------------------------------------------------------------+
|                                CMS_CASE_VIOLATION                               |
+---------------------------------------------------------------------------------+
| PK CASE_ID            VARCHAR2(50)  | Mã định danh trường hợp nghi ngờ vi phạm   |
| FK SCENARIO_ID        VARCHAR2(50)  | Khóa ngoại tham chiếu kịch bản             |
|    PERIOD_ID          VARCHAR2(50)  | Kỳ tuân thủ                               |
|    BRANCH_CODE        VARCHAR2(20)  | Mã chi nhánh phát sinh                    |
|    USER_ID            VARCHAR2(50)  | Mã nhân viên bị cảnh báo                  |
|    TRANSACTION_VAL    NUMBER(18,2)  | Giá trị giao dịch/khoản vay liên quan      |
|    CALCULATED_SCORE   NUMBER(5,2)   | Điểm rủi ro tổng hợp (0 - 100)            |
|    CASE_STATUS        VARCHAR2(30)  | PENDING_EXPLANATION / CLOSED / RETURNED   |
|    VIOLATION_STATUS   VARCHAR2(30)  | VIOLATED / NON_VIOLATED / WARNING         |
|    CREATED_AT         TIMESTAMP     | Thời gian phát hiện                       |
+---------------------------------------------------------------------------------+
                                      | 1
                                      |
                                      | N
+---------------------------------------------------------------------------------+
|                             CMS_CASE_EXPLANATION                                |
+---------------------------------------------------------------------------------+
| PK EXPLANATION_ID     VARCHAR2(50)  | Mã định danh giải trình                   |
| FK CASE_ID            VARCHAR2(50)  | Khóa ngoại tham chiếu Case                |
|    EXPLAIN_CONTENT    CLOB          | Nội dung giải trình từ chi nhánh          |
|    ATTACHMENT_PATH    VARCHAR2(500) | Đường dẫn tài liệu trên ECM               |
|    BRANCH_APPROVER    VARCHAR2(50)  | Cấp phê duyệt chi nhánh (EU CN Approve)   |
|    BPTT_REVIEWER      VARCHAR2(50)  | Cán bộ thẩm định BPTT                     |
|    BPTT_FEEDBACK      CLOB          | Ý kiến phản hồi của BPTT                  |
|    UPDATED_AT         TIMESTAMP     | Thời điểm cập nhật cuối                   |
+---------------------------------------------------------------------------------+

Thiết kế Giao diện lập trình ứng dụng (API Endpoints)

Endpoint Method Quyền truy cập Chức năng
/api/v1/scenarios/execute POST AD BPTT Kích hoạt thực thi kịch bản theo yêu cầu hoặc tham số tùy chỉnh
/api/v1/cases/pending-explanation GET EU CN Edit, Approve Lấy danh sách các trường hợp chờ chi nhánh giải trình
/api/v1/cases/{caseId}/explain POST EU CN Edit Gửi nội dung và tệp tin giải trình lên hệ thống ECM
/api/v1/cases/{caseId}/review PUT EU BPTT, AD BPTT Duyệt/Trả lại giải trình, chốt trạng thái vi phạm và đóng Case
/api/v1/scoring-params PUT AD BPTT Cập nhật cấu hình trọng số ma trận chấm điểm rủi ro

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

Dự án áp dụng mô hình phát triển Agile Scrum với chu kỳ Sprint 2 tuần/lần, phân bổ trong tổng thời gian 14 tuần:

[Sprint 1-2]: Khảo sát, thu thập yêu cầu và thiết kế Data Model
      │
[Sprint 3-4]: Xây dựng Job ETL DataStage & Logic Kịch bản T24
      │
[Sprint 5-6]: Phát triển Backend Engine & Ma trận chấm điểm F2-Score
      │
[Sprint 7]: Phát triển Giao diện React.js & Tích hợp Tableau, ECM, AD
      │
[Sprint 8]: Kiểm thử tích hợp (UAT), Đánh giá hiệu năng và Đóng gói

Implementation và kết quả

Quá trình phát triển kịch bản và thuật toán cốt lõi

1. Kịch bản "Cảnh báo User đăng nhập hệ thống T24 bằng nhiều thiết bị"

Kịch bản phát hiện hành vi một tài khoản người dùng đăng nhập đồng thời trên nhiều địa chỉ IP/thiết bị khác nhau trong cùng một khoảng thời gian làm việc, vi phạm quy định an toàn thông tin của ngân hàng.

Dữ liệu đầu vào trích xuất từ 3 bảng trung gian sau khi ETL từ DWH:

  • UP_LOG_T24: Lưu vết nhật ký đăng nhập T24 (USER_ID, IP_ADDRESS, LOGIN_TIME, STATUS).
  • UP_BRANCH_T24: Thông tin đơn vị chi nhánh quản lý user.
  • UP_USER_HRIS: Thông tin định danh nhân sự (EMPLOYEE_CODE, FULL_NAME, DEPARTMENT).
-- Thuật toán truy vấn phát hiện vi phạm đăng nhập đa thiết bị
WITH UserLoginIntervals AS (
    SELECT 
        l.USER_ID,
        u.FULL_NAME,
        b.BRANCH_CODE,
        l.IP_ADDRESS,
        l.LOGIN_TIME,
        LAG(l.IP_ADDRESS) OVER (PARTITION BY l.USER_ID ORDER BY l.LOGIN_TIME) AS PREV_IP,
        LAG(l.LOGIN_TIME) OVER (PARTITION BY l.USER_ID ORDER BY l.LOGIN_TIME) AS PREV_LOGIN_TIME
    FROM UP_LOG_T24 l
    INNER JOIN UP_USER_HRIS u ON l.USER_ID = u.EMPLOYEE_CODE
    INNER JOIN UP_BRANCH_T24 b ON u.BRANCH_ID = b.BRANCH_ID
    WHERE l.LOGIN_TIME >= TRUNC(SYSDATE) - 1
      AND l.STATUS = 'SUCCESS'
)
SELECT 
    USER_ID,
    FULL_NAME,
    BRANCH_CODE,
    IP_ADDRESS AS CURRENT_IP,
    PREV_IP,
    LOGIN_TIME AS CURRENT_LOGIN_TIME,
    PREV_LOGIN_TIME,
    ROUND((LOGIN_TIME - PREV_LOGIN_TIME) * 24 * 60, 2) AS TIME_DIFF_MINUTES
FROM UserLoginIntervals
WHERE PREV_IP IS NOT NULL 
  AND IP_ADDRESS <> PREV_IP
  AND (LOGIN_TIME - PREV_LOGIN_TIME) * 24 * 60 <= 15 -- Ngưỡng cảnh báo: Dưới 15 phút đổi IP
ORDER BY TIME_DIFF_MINUTES ASC;

2. Phương pháp luận chấm điểm cảnh báo sớm (Early Warning Scoring Model)

Điểm rủi ro tổng hợp ($S_{total}$) của từng trường hợp vi phạm được tính toán dựa trên ma trận trọng số 4 cấu phần:

$$S_{total} = w_1 \cdot S_{risk} + w_2 \cdot S_{F2} + w_3 \cdot S_{branch} + w_4 \cdot S_{val}$$

Trong đó:

  • $S_{risk}$ (Mức độ rủi ro kịch bản): Thấp (25), Trung bình (50), Cao (75), Nghiêm trọng (100).
  • $S_{F2}$ (Điểm hiệu quả hoạt động dựa trên chỉ số $F_2$-Score của mô hình):

$$F_2 = (1 + 2^2) \cdot \frac{\text{Precision} \cdot \text{Recall}}{(2^2 \cdot \text{Precision}) + \text{Recall}} = 5 \cdot \frac{\text{Precision} \cdot \text{Recall}}{4 \cdot \text{Precision} + \text{Recall}}$$

Chỉ số $F_2$-Score đặt trọng số lớn hơn cho Recall (độ phủ vi phạm), hạn chế tối đa việc bỏ lọt sai phạm (False Negatives) trong lĩnh vực kiểm soát ngân hàng.

  • $S_{branch}$ (Lịch sử tuân thủ của Chi nhánh): Tần suất phát sinh vi phạm trong 6 kỳ gần nhất.
  • $S_{val}$ (Quy mô giá trị giao dịch / khoản vay liên quan): Chuẩn hóa theo các thang điểm biên độ giao dịch.
public class ComplianceScoringEngine {

    // Cấu hình tỷ trọng mặc định: w1=0.35, w2=0.25, w3=0.20, w4=0.20
    private static final double WEIGHT_RISK = 0.35;
    private static final double WEIGHT_F2 = 0.25;
    private static final double WEIGHT_BRANCH = 0.20;
    private static final double WEIGHT_VAL = 0.20;

    public static double calculateCaseRiskScore(
            double scenarioRiskScore, 
            double precision, 
            double recall, 
            double branchViolationHistoryScore, 
            double transactionValue) {
        
        // 1. Tính toán F2-Score chuẩn hóa trên thang 100
        double f2Score = 0.0;
        if (precision + recall > 0) {
            f2Score = 5.0 * (precision * recall) / ((4.0 * precision) + recall);
        }
        double sF2 = f2Score * 100.0;

        // 2. Chuẩn hóa giá trị giao dịch sang thang điểm S_val
        double sVal = normalizeTransactionValue(transactionValue);

        // 3. Tổng hợp điểm rủi ro
        double totalScore = (WEIGHT_RISK * scenarioRiskScore) +
                            (WEIGHT_F2 * sF2) +
                            (WEIGHT_BRANCH * branchViolationHistoryScore) +
                            (WEIGHT_VAL * sVal);

        return Math.round(totalScore * 100.0) / 100.0;
    }

    private static double normalizeTransactionValue(double val) {
        if (val >= 5_000_000_000L) return 100.0; // >= 5 tỷ VNĐ
        if (val >= 1_000_000_000L) return 75.0;  // 1 - 5 tỷ VNĐ
        if (val >= 200_000_000L)   return 50.0;  // 200tr - 1 tỷ VNĐ
        return 25.0;                             // < 200tr VNĐ
    }
}

Kiểm thử và Đánh giá hệ thống

Kết quả kiểm thử thực nghiệm

Hệ thống được kiểm thử với tập dữ liệu giả lập từ 500.000 bản ghi nhật ký đăng nhập T24 và dữ liệu danh mục nhân sự, chi nhánh.

Nhóm chức năng / Kịch bản Số test case Tỷ lệ Pass Thời gian xử lý trung bình Ghi chú
ETL DataStage Job 15 100% 42 giây / 500k bản ghi Đạt yêu cầu toàn vẹn dữ liệu
Bắt lỗi Login Multi-IP 25 100% 1.8 giây / truy vấn Bắt chính xác 100% ca thử nghiệm
Engine Chấm điểm rủi ro 30 100% < 50ms / ca Điểm số tính toán chính xác theo công thức
Workflow Giải trình 2 chiều 20 100% Tức thời Đồng bộ trạng thái theo thời gian thực
Bảo mật & Tích hợp MS AD 10 100% < 300ms / xác thực Xác thực SSO thành công 
+-------------------------------------------------------------------------+
|                    KẾT QUẢ PHÂN PHỐI ĐIỂM CẢNH BÁO                      |
|                                                                         |
| Mức Đỏ (Điểm >= 80)     [########] 14.2% -> Yêu cầu giải trình khẩn     |
| Mức Vàng (50 <= Điểm < 80) [####################] 48.5% -> Điều tra BPTT|
| Mức Xanh (Điểm < 50)    [##################] 37.3% -> Gửi mail cảnh báo |
+-------------------------------------------------------------------------+

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

Các cải tiến kỹ thuật nổi bật

  1. Mô hình hóa kịch bản đa thuộc tính: Chuẩn hóa toàn bộ các quy chế kiểm soát phức tạp thành 3 luồng xử lý tự động hóa (Tự động đẩy chi nhánh, BPTT tiền kiểm tra thủ công, Cảnh báo qua Email), giảm tối đa độ trễ trong khâu phân phối công việc.
  2. Thuật toán chấm điểm tích hợp $F_2$-Score: Khắc phục nhược điểm của các hệ thống cảnh báo tĩnh bằng cách kết hợp giữa mức độ nghiêm trọng quy chế, độ tin cậy lịch sử của kịch bản (ưu tiên Recall) và lịch sử vi phạm của đơn vị để đưa ra mức độ ưu tiên xử lý trực quan.
  3. Quy trình xử lý khép kín (Closed-Loop Compliance Workflow): Xây dựng luồng tương tác trực tiếp giữa BPTT và Chi nhánh trên cùng một nền tảng, loại bỏ hoàn toàn việc trao đổi hồ sơ qua email rời rạc hoặc văn bản giấy.

Hiệu quả định lượng đạt được

Chỉ số đánh giá Phương pháp thủ công trước đây Hệ thống CMS mới Mức độ cải thiện
Thời gian quét & tạo ca vi phạm 2 - 3 ngày / kỳ kiểm tra 2 - 5 phút / kỳ chạy batch Nhanh hơn 95%
Tỷ lệ sót lọt vi phạm nghiêm trọng ~15% (Do lấy mẫu ngẫu nhiên) < 1% (Rà soát toàn bộ log) Giảm 93% rủi ro sót lọt
Thời gian tổng hợp báo cáo 4 - 8 giờ làm việc Tức thời (Nhúng Tableau) Tiết kiệm 100% công sức tạo báo cáo
Chi phí đầu tư phần mềm $60.000 - $180.000 (Mua ngoài) Tối ưu chi phí bản quyền Tiết kiệm lớn ngân sách CNTT

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

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

  • Cán bộ BPTT: Đầu kỳ tuân thủ, hệ thống tự động chạy batch kịch bản. Đối với các ca vi phạm mức độ Đỏ ($S_{total} \ge 80$), hệ thống tự động phân loại, tạo case và gửi thông báo yêu cầu giải trình tới Giám đốc Chi nhánh liên quan.
  • Cán bộ Chi nhánh: Nhận thông báo qua Email, đăng nhập CMS bằng tài khoản MS AD, xem chi tiết bằng chứng vi phạm và tải lên văn bản giải trình kèm tài liệu chứng minh qua cổng kết nối ECM.
  • Lãnh đạo Khối Kiểm soát: Theo dõi biến động vi phạm toàn hệ thống qua Dashboard Tableau nhúng trực tiếp, nhận diện nhanh các điểm nóng vi phạm theo khu vực địa lý hoặc theo mảng nghiệp vụ (Tín dụng, Hệ thống thông tin, Bảo lãnh).

Yêu cầu cấu hình và hướng dẫn triển khai

1. Yêu cầu hạ tầng máy chủ

  • Application Server: 02 Node (Redundancy), 8 Core CPU, 16GB RAM, Red Hat Enterprise Linux (RHEL) 8.x.
  • Database Server: Oracle 19c RAC, 16 Core CPU, 64GB RAM, SSD Storage.
  • Network & Security: Tích hợp Firewall nội bộ, cấp chứng chỉ SSL/TLS nội bộ, mở cổng kết nối DWH (Oracle 1521), MS AD (LDAP 389/636), SMTP (Port 25/587).

2. Quy trình đóng gói và triển khai

# 1. Build mã nguồn Backend Spring Boot
mvn clean package -DskipTests

# 2. Đóng gói Container Image
docker build -t mb-compliance-cms-backend:1.0.0 .

# 3. Triển khai cấu hình dịch vụ trên Kubernetes / Docker Swarm
kubectl apply -f k8s/cms-deployment.yaml
kubectl apply -f k8s/cms-service.yaml

# 4. Kiểm tra trạng thái sức khỏe dịch vụ (Health check)
curl -k https://cms.mbbank.com.vn/api/actuator/health

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

Hạn chế kỹ thuật hiện tại

  • Độ trễ dữ liệu (Data Latency): Dữ liệu hiện được đồng bộ định kỳ theo lô (T+1 hoặc theo chu kỳ giờ), chưa hỗ trợ cơ chế lắng nghe sự kiện tức thời (Real-time Change Data Capture).
  • Phân tích nội dung giải trình: Việc đánh giá tính hợp lý của nội dung giải trình vẫn phụ thuộc vào chuyên môn đánh giá thủ công của cán bộ BPTT.

Hướng phát triển trong tương lai

  • Tích hợp Apache Kafka để truyền luồng dữ liệu nhật ký giao dịch thời gian thực từ Core T24, cho phép chặn giao dịch vi phạm tức thì.
  • Ứng dụng các mô hình Học máy (Machine Learning) và Xử lý ngôn ngữ tự nhiên (NLP) nhằm tự động phân loại mức độ tin cậy của tài liệu giải trình từ chi nhánh.
  • Mở rộng kho kịch bản sang các nghiệp vụ phức tạp: Kịch bản phát hiện chia nhỏ khoản vay để lách hạn mức phê duyệt, kịch bản phát hiện giao dịch bất thường ngoài giờ làm việc.

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

1. Sinh viên và Học viên chuyên ngành Hệ thống thông tin / Fintech

  • Tiếp cận đồ án mẫu chuẩn mực kết hợp giữa nghiệp vụ ngân hàng thực tế (Core T24, Basel, AML) và kỹ thuật phân tích thiết kế hệ thống thông tin quy mô lớn.
  • Nắm bắt phương pháp kết hợp toán học ứng dụng ($F_2$-Score) vào bài toán quản trị rủi ro định lượng.

2. Kỹ sư phát triển phần mềm và Chuyên viên Dữ liệu

  • Tham khảo mã nguồn truy vấn đối soát dữ liệu lớn trên hệ cơ sở dữ liệu quan hệ doanh nghiệp.
  • Mô hình kiến trúc tích hợp hệ thống đa dịch vụ (Enterprise Integration Patterns) với DataStage, Oracle, Active Directory và Tableau.

3. Ngân hàng và Doanh nghiệp tài chính

  • Một khung kiến trúc phần mềm hoàn chỉnh có thể chuyển giao và áp dụng trực tiếp để tự động hóa hoạt động kiểm soát nội bộ.
  • Tối ưu hóa chi phí đầu tư công nghệ thông tin so với các gói giải pháp đắt đỏ từ nước ngoài.

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

1. Hệ thống CMS yêu cầu cấu hình hạ tầng tối thiểu như thế nào để vận hành ổn định?

Để xử lý dữ liệu cho ngân hàng quy mô ~300 chi nhánh, hệ thống cần máy chủ ứng dụng tối thiểu 8 Core CPU, 16GB RAM chạy Linux, cơ sở dữ liệu Oracle Database 19c Enterprise với dung lượng lưu trữ khả dụng tối thiểu 500GB SSD để lưu vết nhật ký và lịch sử các ca vi phạm trong 3 năm.

2. Làm thế nào để mở rộng thêm các kịch bản bắt lỗi vi phạm mới mà không cần sửa đổi toàn bộ mã nguồn?

CMS được thiết kế theo kiến trúc Module hóa. Người quản trị (AD BPTT) có thể thiết lập tham số kịch bản, ánh xạ trường dữ liệu và cấu hình ngưỡng điểm rủi ro trực tiếp trên giao diện màn hình quản trị. Các logic phức tạp được nạp động thông qua các Stored Procedure chuẩn hóa trong Oracle DB.

3. Hệ thống tích hợp với Core Banking Temenos T24 và HRIS như thế nào để đảm bảo không ảnh hưởng đến hiệu năng giao dịch?

Hệ thống CMS không truy vấn trực tiếp vào cơ sở dữ liệu Production của Temenos T24. Toàn bộ dữ liệu được trích xuất sang Kho dữ liệu (DWH) vào cuối ngày làm việc thông qua các Job ETL IBM InfoSphere DataStage chuyên dụng, đảm bảo tuyệt đối an toàn và không gây tải lên hệ thống ngân hàng lõi.

4. Chi phí bảo trì và vận hành hệ thống CMS tự phát triển so với giải pháp thương mại chênh lệch ra sao?

Giải pháp CMS tự phát triển giúp tiết kiệm 100% chi phí bản quyền định kỳ hàng năm ($50.000 - $100.000/năm đối với các hãng như ServiceNow hay MetricStream). Đội ngũ CNTT nội bộ có thể chủ động sửa lỗi, cập nhật tính năng mới theo quy định của Ngân hàng Nhà nước mà không phụ thuộc vào tiến độ của nhà cung cấp bên thứ ba.

5. Phương pháp chấm điểm bằng F2-Score mang lại lợi ích gì vượt trội so với F1-Score thông thường?

Trong kiểm soát tuân thủ ngân hàng, chi phí của việc bỏ lọt một vi phạm gian lận (False Negative) lớn hơn rất nhiều so với việc kiểm tra nhầm một trường hợp nghi ngờ nhưng không vi phạm (False Positive). $F_2$-Score đặt trọng số lớn hơn gấp đôi cho độ phủ (Recall), giúp hệ thống tập trung cảnh báo tối đa các mối nguy tiềm ẩn.

Kết luận

Đề tài "Xây dựng phần mềm Quản lý tuân thủ tại Ngân hàng TMCP Quân đội" đã giải quyết thành công bài toán chuyển đổi số nghiệp vụ kiểm soát tuân thủ tại một trong những định chế tài chính hàng đầu Việt Nam. Bằng việc kết hợp hài hòa giữa cơ sở lý thuyết quản trị rủi ro hiện đại, phương pháp luận chấm điểm định lượng $F_2$-Score và kiến trúc phần mềm hướng dịch vụ, dự án không chỉ mang lại giá trị học thuật xuất sắc cho khóa luận tốt nghiệp ngành Hệ thống thông tin quản lý mà còn cung cấp một giải pháp ứng dụng thực tiễn cao, giúp ngân hàng tối ưu hóa chi phí vận hành, ngăn ngừa rủi ro và nâng cao năng lực cạnh tranh trong kỷ nguyên số.