Bên trong core banking hiện đại: Sau nút “Chuyển tiền”: Core banking và AI làm gì?

Một doanh nghiệp nhỏ tại Odin Lab Bank (OLB) duyệt chuyển 20 triệu đồng cho nhà cung cấp. Khi khách hàng rời ứng dụng, ngân hàng vẫn còn nhiều việc: ghi sổ, xác nhận kết quả thanh toán và lưu lại bằng chứng. Nếu các mốc đó được ghi thành dòng sự kiện có thể truy vết, AI còn có thể rà soát giao dịch, phát hiện dấu hiệu bất thường và cập nhật dự báo dòng tiền ngay sau khi dữ liệu cần thiết xuất hiện.

Bài này nối tiếp Core banking 2031: Ngân hàng cần một nền tảng mới như thế nào? bằng cách đi sâu vào một giao dịch. OLB là ngân hàng giả lập; số liệu và mô hình vận hành trong bài là kịch bản nghiên cứu cho năm 2031.

1. Một lệnh chuyển tiền đi qua ngân hàng thế nào?

Trong kịch bản OLB, doanh nghiệp duyệt khoản chi trên ứng dụng. Kênh giao dịch gửi lệnh đã được xác thực và phê duyệt cho bộ điều phối. Core banking ghi bút toán theo quy tắc nghiệp vụ. Hệ thống thanh toán gửi lệnh liên ngân hàng, nhận phản hồi và cập nhật kết quả theo thông tin từ nguồn có thẩm quyền. Trình tự cụ thể có thể khác giữa các hệ thống thanh toán.

Ghi sổ và xác nhận thanh toán là hai mốc khác nhau. Core xác nhận bút toán đã được ghi vào sổ của ngân hàng. Kết quả chuyển tiền phải dựa vào trạng thái mà hệ thống thanh toán có thẩm quyền cung cấp. Nếu hết thời gian chờ mà chưa biết kết quả, OLB giữ trạng thái Đang xác minh, tra soát và đối soát trước khi quyết định gửi lại. Làm vậy tránh tạo giao dịch trùng khi lệnh ban đầu thực ra đã được xử lý.

2. Dữ liệu nào đi vào dòng sự kiện?

Một lệnh yêu cầu hệ thống thực hiện việc gì đó; một sự kiện ghi lại việc đã xảy ra. Với khoản chi trên, các mốc như Lệnh đã duyệt, Bút toán đã ghi nhận và Thanh toán đã được xác nhận có cùng mã tham chiếu giao dịch, nhưng mỗi mốc có mã sự kiện, thời điểm và nguồn xác nhận riêng. Mã tham chiếu giúp đối chiếu hồ sơ; mã sự kiện giúp bên nhận tránh xử lý trùng.

Khi dịch vụ sở hữu cả bút toán và bản ghi chờ phát sự kiện, có thể dùng mẫu hộp thư giao dịch (transactional outbox): lưu cả hai trong cùng một lần ghi dữ liệu, rồi chuyển sự kiện đi sau khi ghi thành công. Vì bộ chuyển tiếp có thể gửi lại, bên nhận cần nhận diện bản trùng. Với core thương mại, ưu tiên API hoặc luồng sự kiện do nhà cung cấp hỗ trợ và đối soát với sổ gốc. Dòng sự kiện phục vụ phân tích; sổ ngân hàng và hệ thống thanh toán vẫn là nguồn xác nhận nghiệp vụ tương ứng.

3. Ba việc AI làm sau giao dịch

Rà soát bằng chứng và lập hồ sơ ngoại lệ

AI có thể đọc hóa đơn, tìm bản phê duyệt, rồi ghép chúng với lệnh và bút toán. Kiểm tra số tiền và các mã định danh bằng quy tắc đối chiếu rõ ràng. Nếu thiếu hóa đơn hoặc dữ liệu không khớp, hệ thống mở hồ sơ ngoại lệ, nêu chỗ lệch và trỏ tới bằng chứng để vận hành xác minh. Khi thiếu nguồn, hồ sơ phải ghi rõ phần chưa kiểm chứng.

Phát hiện cụm bất thường ngay khi dữ liệu đến

Một giao dịch 20 triệu đồng có thể hoàn toàn bình thường khi xét riêng lẻ. Nhưng nếu nhiều lệnh mới cùng chuyển tới một người nhận và đi kèm các hóa đơn gần trùng, hệ thống có thể phát cảnh báo để chuyên viên xem xét. Kết quả xác minh có thể dẫn đến kiểm tra bổ sung ở lệnh kế tiếp theo chính sách đã duyệt. Project Hertha của BIS Innovation Hub và Bank of England minh họa tiềm năng của phân tích mạng giao dịch; đây là thử nghiệm trên dữ liệu tổng hợp, chưa phải bằng chứng rằng mô hình OLB đã vận hành hoặc đạt hiệu quả tương tự.

Cập nhật dự báo dòng tiền cho doanh nghiệp

Giả sử doanh nghiệp có 120 triệu đồng khả dụng trước giao dịch và còn 100 triệu sau khi chi, bỏ qua phí, phong tỏa và các biến động khác. Doanh nghiệp dự kiến dành 70 triệu trả lương và 10 triệu dự phòng thuế, nên còn 20 triệu theo kế hoạch. Với một hóa đơn 25 triệu sắp đến hạn, hệ thống có thể cảnh báo thiếu 5 triệu theo kế hoạch và cho thấy những giả định đứng sau dự báo. Khoản thiếu dự kiến này không phải thấu chi hay số dư do core xác nhận.

4. Ai quyết định và ai kiểm chứng?

Core và hệ thống thanh toán giữ quyền xác nhận phần nghiệp vụ mình phụ trách. AI phân tích và đề xuất; mọi can thiệp vào giao dịch phải theo chính sách, quyền hạn và điều kiện đã được phê duyệt. Với mỗi cảnh báo hoặc đề xuất, OLB cần lưu nguồn dữ liệu, phiên bản quy tắc hoặc mô hình, kết quả xác minh và quyết định xử lý để có thể tái dựng diễn biến sau này.

Theo Mô hình Ba tuyến của Viện Kiểm toán Nội bộ (The Institute of Internal Auditors – IIA), việc AI rà soát giao dịch và lập hồ sơ ngoại lệ hỗ trợ kiểm soát vận hành. Kiểm toán nội bộ vẫn có vai trò đánh giá độc lập hiệu quả của các kiểm soát đó.

5. OLB nên thử nghiệm gì trước?

Bắt đầu bằng một luồng chuyển tiền doanh nghiệp và cho AI chạy quan sát trên dữ liệu giả lập, chưa tác động vào lệnh. Kiểm thử tối thiểu bốn tình huống: giao dịch bình thường, sự kiện bị gửi trùng, phản hồi thanh toán đến muộn và giao dịch bị hoàn trả. Nhóm core và thanh toán đối chiếu sổ với kết quả; nhóm dữ liệu đo chất lượng dòng sự kiện; nhóm vận hành xác minh cảnh báo và ghi lại quyết định.

• Rà soát: đo thời gian tập hợp bằng chứng và tỷ lệ hồ sơ đủ căn cứ để xử lý.
• Bất thường: đo cảnh báo sai, tình huống bỏ sót và thời gian từ lúc sự kiện xuất hiện đến lúc cảnh báo.
• Dự báo: đo độ trễ cập nhật, sai số và thời gian báo trước khi doanh nghiệp có thể thiếu tiền theo kế hoạch.

Chỉ mở rộng phạm vi khi nhóm thử nghiệm tái dựng được mỗi giao dịch từ lệnh đã duyệt đến kết quả, xử lý đúng các tình huống ngoại lệ và chứng minh được lợi ích so với quy trình hiện tại. Đây là cách biến dữ liệu giao dịch thành giá trị cho cả ngân hàng và khách hàng mà vẫn giữ rõ trách nhiệm xác nhận và xử lý.

Đọc tiếp: Làm chủ core banking: ngân hàng cần tự xây đến đâu? · Nghiên cứu & Ứng dụng