Làm chủ core banking: ngân hàng cần tự xây đến đâu?

1. Ngân hàng cần làm chủ những gì?

Khi một ngân hàng muốn ra sản phẩm mới nhanh hơn, câu hỏi “mua hay tự xây core?” thường xuất hiện sớm. Tuy nhiên, quyết định này chỉ có ý nghĩa khi làm rõ phần nào đang cản trở kinh doanh: quy tắc sản phẩm, chất lượng dữ liệu, tích hợp, quy trình phê duyệt hay năng lực triển khai thay đổi.

Core banking trong bài được hiểu là nền tảng ghi nhận và xử lý tài khoản, tiền gửi, khoản vay và bút toán trong phạm vi được giao. Kênh số, thanh toán, thẻ, dữ liệu và kế toán doanh nghiệp có thể nằm ở các nền tảng khác. Ranh giới cụ thể cần được xác định theo kiến trúc của từng ngân hàng.

Odin đề xuất đánh giá năng lực làm chủ qua năm câu hỏi:

• Kiến trúc: ngân hàng có biết hệ thống nào chịu trách nhiệm cho từng kết quả nghiệp vụ và phụ thuộc vào những thành phần nào?
• Nghiệp vụ và dữ liệu: ai xác nhận số dư, trạng thái giao dịch, lãi, phí và các bút toán điều chỉnh?
• Thay đổi: ngân hàng có thể đánh giá, kiểm thử, triển khai và kiểm soát tác động của một thay đổi?
• Vận hành và phục hồi: khi lỗi xảy ra, đội ngũ có thể xác định giao dịch đang ở đâu và khôi phục dịch vụ đúng nghiệp vụ?
• Quan hệ nhà cung cấp: ngân hàng có quyền tiếp cận tài liệu, hỗ trợ, dữ liệu, bằng chứng và phương án chuyển đổi phù hợp?

Sở hữu mã nguồn hỗ trợ một phần những năng lực này. Để biến mã nguồn thành dịch vụ ngân hàng tin cậy, tổ chức vẫn cần con người, quy trình, kiểm thử, kiến thức tài chính và quyền quyết định rõ ràng.

2. Đọc gì từ NAB, Barclays và tài liệu core thương mại?

NAB: đội ngũ kỹ thuật nội bộ và hợp tác sản phẩm có thể cùng tồn tại

Trang giới thiệu đội ngũ công nghệ của National Australia Bank — NAB, Australia mô tả ngân hàng thiết kế, phát triển và vận hành các nền tảng core, kênh số, thanh toán, dữ liệu và AI. Thông tin này thể hiện vai trò kỹ thuật nội bộ; nó chưa xác định toàn bộ nguồn gốc mã phần mềm của từng nền tảng. [1]

Trong tài liệu Group Strategy and Technology Update ngày 13/3/2013, NAB trình bày Oracle Banking Platform trong chương trình NextGen và quan hệ hợp tác với Oracle. Đây là bằng chứng lịch sử về việc sử dụng sản phẩm thương mại trong quá trình hiện đại hóa; không nên dùng nó để khẳng định cấu hình toàn bộ core NAB ở hiện tại. [2]

Diễn giải của Odin: khi học từ NAB, nên tìm hiểu cách ngân hàng xây dựng năng lực kỹ thuật và điều phối hệ sinh thái công nghệ. Muốn kết luận “core tự phát triển”, cần bằng chứng cụ thể về sản phẩm, phạm vi và thời điểm.

Barclays US Consumer Bank: core thương mại gắn với mục tiêu tăng trưởng tiền gửi

Ngày 14/4/2026, FIS công bố Barclays US Consumer Bank gia hạn nhiều năm thỏa thuận core banking, lựa chọn Profile để hỗ trợ chiến lược tiền gửi và hiện đại hóa năng lực số. Thông báo mô tả kết nối giữa core, dữ liệu và kênh khách hàng. Đây là thông tin về thỏa thuận và định hướng triển khai; chưa chứng minh mọi hạng mục đã hoàn tất hoặc hiệu quả kinh doanh đã được kiểm chứng độc lập. [3]

Diễn giải của Odin: sản phẩm thương mại có thể là một phần của chiến lược ngân hàng số. Cần đánh giá cách ngân hàng cấu hình, tích hợp và khai thác nền tảng để đạt mục tiêu cụ thể.

Khả năng cấu hình và mở rộng cần được kiểm tra ở đúng phiên bản

FIS giới thiệu Profile là core thời gian thực cho tiền gửi và khoản vay, có các chức năng cấu hình. Tài liệu sản phẩm cũng mô tả giao diện tích hợp và khả năng mở rộng. Đây là mô tả của nhà cung cấp, cần được đối chiếu với phiên bản, hợp đồng hỗ trợ và thiết kế thực tế khi lựa chọn. [4] [5]

Với một yêu cầu mới, ngân hàng nên kiểm tra lần lượt khả năng cấu hình, mở rộng được hỗ trợ và xây dựng dịch vụ riêng. Sửa sâu phần mềm nền cần có lý do đủ mạnh, vì tác động sẽ kéo dài sang kiểm thử, hỗ trợ và nâng cấp.

Các ví dụ trên cung cấp góc nhìn về lựa chọn kiến trúc và cách tổ chức năng lực. Chúng không tạo thành khảo sát đại diện về tỷ lệ thành công hay thất bại của các dự án core banking.

3. Ba cách tiếp cận và những đánh đổi

Bảng dưới là khung phân tích của Odin. Ba cách tiếp cận có thể cùng tồn tại ở các phạm vi khác nhau trong một ngân hàng.

Chi phí cần bao gồm license, triển khai, tích hợp, nhân sự, kiểm thử, vận hành, phục hồi, nâng cấp và chuyển đổi về sau. Với phương án tự xây, cần cộng cả chi phí duy trì kiến thức, xử lý lỗi nghiệp vụ và bảo đảm đội ngũ kế thừa.

Một nhóm nhỏ viết được nguyên mẫu chứng minh khả năng xây chức năng. Quyết định vận hành core lâu dài cần thêm bằng chứng về tính đúng, năng lực chịu tải, khả năng sửa lỗi, quản trị phiên bản và duy trì dịch vụ khi con người hoặc hạ tầng thay đổi.

4. Lựa chọn của Odin Lab Bank

Odin Lab Bank — OLB là ngân hàng giả lập phục vụ nghiên cứu và đào tạo. Định hướng đã thống nhất là sử dụng core thương mại không nêu hãng trong mô hình công khai; OLB làm chủ cấu hình, tích hợp, vận hành và phát triển hệ thống xung quanh. Giao dịch lõi và số dư chính thức đặt trên hạ tầng riêng với phương án DC–DR; hybrid cloud áp dụng ở cấp ngân hàng.

Profile là một nguồn tham khảo công khai về năng lực sản phẩm. Nó không được dùng để suy ra một ngân hàng thực đang triển khai đúng kiến trúc OLB, hoặc để khẳng định OLB đã chọn một tổ hợp runtime, cơ sở dữ liệu và phần cứng cụ thể.

Thiết kế chi tiết đang đề xuất một địa điểm có quyền ghi chính thức tại một thời điểm, kết hợp sẵn sàng cao và phục hồi liên địa điểm. Đây là phương án thiết kế cần kiểm chứng, chưa phải năng lực đã triển khai.

Đặt core ở DC riêng là một quyết định vị trí. Để hình thành hybrid cloud, ngân hàng còn cần các môi trường cloud được quản trị và tích hợp phù hợp; hai địa điểm DC–DR tự nó chưa đủ để kết luận có hybrid cloud. NIST SP 800-145 là nguồn tham chiếu nền tảng về mô hình cloud. [7]

OLB chưa chốt runtime, database, phần cứng, cơ chế sao chép, công suất và mục tiêu phục hồi riêng cho core. Những lựa chọn này cần xuất phát từ yêu cầu dịch vụ và tổ hợp sản phẩm được hỗ trợ.

5. Tác động đến kinh doanh cần đo bằng gì?

Một kiến trúc linh hoạt chỉ tạo giá trị khi ngân hàng khai thác được nó trong quy trình cung cấp dịch vụ. Odin đề xuất gắn khoản đầu tư với chuỗi: thay đổi kỹ thuật → thay đổi cách làm → kết quả dịch vụ → tác động kinh doanh.

Khi đánh giá tác động tới tiền gửi, doanh thu phí hoặc tỷ lệ giữ chân khách hàng, cần xét cả giá, sản phẩm, chiến dịch kinh doanh và hành vi thị trường. Bài này không gán một mức tăng trưởng doanh thu hoặc tiết kiệm chi phí cho riêng lựa chọn core.

6. Hai tình huống kiểm tra năng lực làm chủ

Tình huống 1: core đã ghi tiền, kênh số chưa nhận được phản hồi

Trong kịch bản giả lập, khách hàng OLB chuyển 1.000.000 đồng. Core đã ghi nợ và ghi có, nhưng phản hồi về lớp điều phối bị mất. Nếu kênh chỉ thông báo thất bại rồi cho gửi một lệnh mới, ngân hàng có thể tạo thêm một giao dịch ngoài ý định ban đầu.

Amazon Builders’ Library giải thích cách dùng định danh yêu cầu để hỗ trợ gửi lại an toàn, đồng thời xem xét yêu cầu đến muộn hoặc cùng mã nhưng thay đổi ý định. [6] Áp dụng vào OLB cần xác minh thêm cách core nhận diện, lưu và tra cứu giao dịch; một khóa chống lặp ở kênh chưa đủ bảo đảm toàn bộ chuỗi.

Phần tạo khác biệt ở đây nằm trong chất lượng thiết kế tích hợp, xử lý ngoại lệ và trải nghiệm. Ngân hàng có thể đầu tư trực tiếp vào những năng lực đó khi sử dụng core thương mại.

Tình huống 2: chuyển sang DR nhưng giao dịch vẫn chưa vận hành đúng

Trong kịch bản thứ hai, core ở địa điểm phục hồi đã khởi động. Tuy nhiên, Payment Hub còn giữ lệnh đang xử lý, cơ chế xác thực thiếu phụ thuộc, hoặc dữ liệu phục hồi chưa chứa một số giao dịch từng báo thành công.

OLB cần kiểm tra quyền ghi hợp lệ, điểm dữ liệu, trạng thái giao dịch đang xử lý, ngày nghiệp vụ và các kết nối trước khi mở đầy đủ dịch vụ. Thời gian máy chủ khởi động chỉ là một phần của thời gian phục hồi hành trình khách hàng.

Mục tiêu phục hồi phải phân biệt giao dịch đã xác nhận với giao dịch đang xử lý. Nếu yêu cầu là không mất bút toán đã báo thành công, thiết kế sao chép và cơ chế xác nhận phải chứng minh điều đó trong phạm vi sự cố được giao. Đối soát giúp phát hiện khoảng chênh lệch; nó không tự khôi phục bằng chứng ghi nhận đã mất.

Chủ dịch vụ cần xác nhận mức phục vụ có thể mở lại dựa trên bằng chứng nghiệp vụ. Đội hạ tầng, core, thanh toán và bảo mật cung cấp phần kiểm chứng thuộc trách nhiệm của mình. Đây là năng lực phối hợp ngân hàng phải xây dựng dù lựa chọn mua hay tự phát triển core.

Hai tình huống và số tiền trong bài đều được xây dựng cho OLB. Chưa có hệ thống hoặc kết quả diễn tập thực tế được công bố.

7. Đưa lựa chọn công nghệ vào quyết định có bằng chứng

Trước một yêu cầu tự phát triển mới, OLB nên đi qua ba bước:

1. Xác định khoảng trống kinh doanh. Mô tả hành trình, kết quả mong muốn, hạn chế hiện tại và lý do chức năng có sẵn chưa đáp ứng. Chỉ rõ hệ thống giữ dữ liệu và quyền quyết định nghiệp vụ.
2. So sánh phương án trong suốt vòng đời. Đánh giá cấu hình, mở rộng được hỗ trợ, mua thành phần bổ sung và tự phát triển. So sánh cả nâng cấp, bảo mật, vận hành, phục hồi, nhân sự kế thừa và khả năng chuyển đổi.
3. Kiểm chứng trước khi mở rộng phạm vi. Chọn một luồng nghiệp vụ đủ cụ thể; kiểm tra kết quả tài chính, lỗi tích hợp, phục hồi và chi phí vận hành. Dùng bằng chứng để quyết định triển khai, điều chỉnh hoặc dừng.

Hồ sơ quyết định cần có mục tiêu, phương án, rủi ro, kiểm soát, bằng chứng cần đạt, chủ sở hữu, thẩm quyền chấp nhận và điều kiện xem xét lại. Với core thương mại, bổ sung phạm vi hỗ trợ, phiên bản tương thích, nghĩa vụ nhà cung cấp, quyền truy cập dữ liệu và phương án chuyển đổi.

Với core tự xây, ngân hàng cần xác định ai chịu trách nhiệm như một tổ chức phát triển sản phẩm lâu dài: quản lý yêu cầu, chuẩn tính đúng tài chính, kiến trúc dữ liệu, phát hành, hỗ trợ, xử lý lỗi và duy trì kiến thức. Nguồn lực cần đủ cho cả giai đoạn xây dựng và nhiều năm vận hành tiếp theo.

8. Tự xây đến đâu là đủ?

Với OLB, phạm vi phù hợp hiện nay là tận dụng core thương mại cho xử lý tài chính thuộc sản phẩm; làm chủ cấu hình và ranh giới dữ liệu; phát triển có chọn lọc kênh số, tích hợp, đối soát, giám sát và tự động hóa. Năng lực vận hành và phục hồi phải được xây dựng cùng kiến trúc đó.

Quyết định mở rộng phạm vi tự xây cần trả lời ba điều: phần việc ấy tạo giá trị kinh doanh gì, ngân hàng có thể duy trì nó bao lâu, và bằng chứng nào cho thấy dịch vụ vẫn đúng và an toàn khi xảy ra lỗi.

Mức độ làm chủ nên được đánh giá bằng khả năng thay đổi, kiểm soát và duy trì dịch vụ ngân hàng trong thực tế.