Core banking 2031: Ngân hàng cần một nền tảng mới như thế nào?

1. Khách hàng năm 2031 có thể dùng ngân hàng như thế nào?

Một khách hàng nói: “Tháng này hãy dành đủ tiền cho các khoản phải trả, nhắc tôi phần có thể tiết kiệm và chỉ thực hiện phương án sau khi tôi đồng ý.” Một chủ doanh nghiệp nói: “Lập kế hoạch trả hóa đơn tuần tới từ dữ liệu kế toán, giữ đủ tiền lương và báo tôi nếu thiếu.” Đây là hai tình huống dự báo của Odin. Điểm thay đổi nằm ở việc khách hàng nêu mục tiêu và giao một phần công việc cho hệ thống.

AI agent — tác tử AI có thể lập kế hoạch và gọi công cụ trong phạm vi được giao — có thể làm nhiều hơn trả lời câu hỏi. Nó có thể hiểu yêu cầu, lấy dữ liệu, chuẩn bị phương án, khởi tạo một quy trình và theo dõi kết quả. Tuy nhiên, trả lời đúng, chuẩn bị đúng yêu cầu và hoàn tất đúng giao dịch là các mức năng lực khác nhau.

Khảo sát Banking Consumer Study 2025 của Accenture phân tích 49.300 khách hàng tại 39 quốc gia; 73% người tham gia sử dụng thêm ngân hàng ngoài ngân hàng chính. [16] Đây là bằng chứng về quan hệ nhiều ngân hàng trong mẫu khảo sát, chưa phải số liệu dùng agent. Suy luận của Odin: nếu trợ lý được cấp quyền tiếp cận nhiều nhà cung cấp, việc so sánh và tổ chức tài chính có thể diễn ra trước khi khách hàng mở một ứng dụng ngân hàng cụ thể.

Vì vậy, cần nghiên cứu đồng thời ba thay đổi: khách hàng dùng AI của ngân hàng; khách hàng dùng AI của chính mình hoặc bên thứ ba; và doanh nghiệp để AI trong phần mềm kế toán/ERP kết nối dịch vụ ngân hàng. Các mô hình này có thể cùng tồn tại với ứng dụng, quầy và chuyên viên con người.

Đặt từ phía ngân hàng, câu hỏi là: hệ thống có thể hiểu một yêu cầu đã cấu trúc, trả về điều kiện sản phẩm và trạng thái đúng lúc, rồi hoàn tất công việc qua nhiều bộ phận hay không? Nếu chỉ thêm ô chat trước một quy trình vẫn phải nhập lại và xử lý tay, trải nghiệm chưa thay đổi nhiều.

Việc khách hàng dùng AI không tự tạo ra kết luận phải thay core. Một core hiện hữu có giao diện, dữ liệu và năng lực sản phẩm phù hợp vẫn có thể phục vụ hành trình mới. Quyết định thay nền tảng cần dựa vào khoảng cách năng lực và hiệu quả đầu tư. Bài này dùng hành trình khách hàng để xác định khoảng cách đó, rồi đề xuất một hướng core mới cho OLB.

2. Năm xu hướng công nghệ và giá trị kinh doanh

McKinsey, trong bài ngày 27/8/2026, đặt trọng tâm vào việc chuyển core thành một nền tảng kết nối xử lý giao dịch với năng lực quyết định. Bài nhấn mạnh tính mô-đun, sản phẩm có thể cấu hình, dữ liệu và AI được thiết kế cùng kiến trúc. [1] BCG phân biệt cách giảm chức năng phụ thuộc vào core hiện hữu với cách thay hoặc bổ sung core, đồng thời coi nhân lực và cách làm việc là các điều kiện quan trọng bên cạnh công nghệ. Tài liệu BCG được công bố tháng 8/2024, với bối cảnh chính là Ấn Độ. [2]

Để nối rõ AI với tự động hóa, nghiên cứu BCG và OpenAI ngày 9/3/2026 phân tích cách agent liên kết công việc phía khách hàng với xử lý hồ sơ và quy trình phía sau. Trọng tâm là hoàn tất hành trình, gồm tổng hợp thông tin, khởi tạo công việc và chuyển trường hợp cần chuyên viên, thay vì chỉ trả lời hội thoại. [17] Đây là phân tích định hướng; không phải báo cáo một ngân hàng đã tự động hóa toàn bộ bằng agent.

Tổng hợp của Odin: năm xu hướng dưới đây chỉ có ý nghĩa khi kết nối được với một thay đổi cụ thể trong kinh doanh.

Ba phân biệt giúp tránh hiểu sai xu hướng. Big data không phải cơ sở dữ liệu thay thế trực tiếp cho sổ giao dịch; cloud-native không đồng nghĩa toàn bộ hệ thống phải chạy trên public cloud; microservices không có nghĩa phải bẻ nhỏ mọi thao tác hạch toán thành nhiều giao dịch độc lập. Ngân hàng vẫn cần một ranh giới ghi nhận tiền được thiết kế chặt chẽ.

AI cũng đang tham gia chính quá trình thay core. Thông báo ngày 29/9/2026 của Thought Machine và AWS mô tả việc dùng AI trích xuất quy tắc từ hệ thống cũ, tạo logic sản phẩm và kiểm thử trong môi trường mô phỏng. [3] Đây là tín hiệu về công cụ chuyển đổi mới; các tuyên bố rút ngắn thời gian của nhà cung cấp chưa phải bằng chứng một ngân hàng lớn có thể chuyển toàn bộ core trong vài ngày.

3. Bằng chứng về AI khách hàng và hiện đại hóa core

Cần hai nhóm bằng chứng để nối nghiên cứu với đề xuất: một nhóm cho thấy cách khách hàng giao tiếp và thực hiện công việc đang thay đổi; nhóm còn lại cho thấy ngân hàng đang đổi nền tảng. Một dự án core mới không mặc nhiên chứng minh ngân hàng đó đã có dịch vụ AI tự chủ.

AI đang thay đổi tương tác và thực hiện công việc ở đâu?

Thông báo Visa Agentic Ready ngày 30/4/2026 liệt kê hơn 50 đối tác ở châu Á–Thái Bình Dương, trong đó có ACB, MB, Sacombank, Techcombank và VPBank. [15] Việc có tên trong chương trình cho thấy tham gia chuẩn bị và kiểm thử; không đủ căn cứ nói từng ngân hàng Việt Nam đã cung cấp agent thanh toán đại trà.

Những dự án core nào cho thấy hướng thay nền tảng?

Tổng hợp của Odin: nhóm thứ nhất chứng minh một số năng lực tương tác và hành động đã xuất hiện; nhóm thứ hai cho thấy các cách đầu tư nền tảng. Mô hình ngân hàng 2031 kết hợp hai hướng là một suy luận cần tiếp tục kiểm chứng, không phải kiến trúc đã được xác nhận ở mọi ngân hàng trong bảng. Các trường hợp chọn lọc cũng không phải khảo sát đại diện thị trường.

4. Từ khách hàng dùng ứng dụng đến khách hàng dùng agent

Dự báo cơ sở của Odin cho năm 2031: ứng dụng ngân hàng vẫn tồn tại, nhưng một phần công việc được bắt đầu bằng mục tiêu, hội thoại, ảnh hoặc dữ liệu nghiệp vụ. Mức ủy quyền tăng theo từng loại công việc và nhóm khách hàng; không có một tỷ lệ chung đủ căn cứ cho toàn bộ thị trường.

Cần phân biệt AI của ngân hàng phục vụ trong phạm vi sản phẩm và quan hệ của ngân hàng; AI của khách hàng có thể so sánh nhiều nhà cung cấp theo ưu tiên của họ; và AI trong hệ thống doanh nghiệp phục vụ quy trình tài chính của tổ chức. Không mặc định agent của ngân hàng là cố vấn độc lập tìm phương án tốt nhất trên toàn thị trường.

Phân tích Accenture tháng 5/2026 đặt ra khả năng agent ảnh hưởng cả lựa chọn phương thức thanh toán, bên cạnh việc hoàn tất mua hàng. [18] Dự báo của Odin: nếu điều này mở rộng, ngân hàng có thể phải cạnh tranh để được agent lựa chọn bằng điều kiện sản phẩm rõ ràng, khả năng tích hợp và chất lượng thực hiện, ngoài thương hiệu và giao diện ứng dụng.

Tác động kinh doanh có thể gồm áp lực lên phí, ưu đãi và tiền gửi khi việc so sánh thuận tiện hơn; đồng thời tạo cơ hội thu hút khách hàng qua đối tác và bán dịch vụ quản lý dòng tiền. Mức tác động chưa thể gán một tỷ lệ chung. Quan hệ khách hàng, tín dụng phức tạp, tranh chấp và các quyết định lớn vẫn cần khả năng gặp chuyên viên và tiếp tục hành trình mà không phải kể lại từ đầu.

Trong kịch bản tăng tốc, các giao diện ủy quyền và kết nối agent phát triển đủ tốt để mở rộng tự động hóa. Trong kịch bản chậm, AI chủ yếu giúp hiểu và chuẩn bị công việc, còn khách hàng vẫn phê duyệt từng giao dịch. Hai kịch bản đòi hỏi nền tảng mở và dữ liệu tốt, nhưng khác nhau đáng kể về mức tự chủ và thời điểm phổ cập.

Không đồng nhất các thước đo: lượt trò chuyện với AI, hành trình được AI hỗ trợ, lệnh thanh toán do agent khởi tạo và giao dịch hoàn tất không cần can thiệp là các tập khác nhau. Dự báo thương mại điện tử qua agent cũng không phải dự báo toàn bộ giao dịch ngân hàng. Cần nêu mẫu số và phạm vi trước khi sử dụng các con số như “50% giao dịch”.

5. Kiến trúc đích: giao dịch, dữ liệu và AI cùng làm việc

Từ phía khách hàng, luồng kiến trúc có thể được đọc như sau: mục tiêu → AI hiểu và đề xuất → quyền thực hiện → điều phối công việc → core/thanh toán thực hiện → kết quả quay lại khách hàng. AI hiểu yêu cầu; automation thực hiện và theo dõi các bước đã xác định; core bảo đảm phần ghi nhận giao dịch. Tăng năng lực của một phần chưa chứng minh cả hành trình đã tự động hóa.

Nếu hỗ trợ agent ngoài ngân hàng, lớp API còn cần cung cấp điều kiện sản phẩm, báo giá và trạng thái theo cấu trúc máy có thể đọc; xác định agent đang đại diện ai và được làm gì; cho phép khách hàng thu hồi quyền và nhận xác nhận giao dịch. Đây là đề xuất kiến trúc của Odin. Không mặc định đã có một chuẩn giao tiếp agent duy nhất được mọi ngân hàng áp dụng, hoặc cho phép agent sử dụng mật khẩu/OTP của khách hàng để thao tác tùy ý.

Lõi giao dịch và sản phẩm. Nền tảng mới quản lý tài khoản, hợp đồng, số dư và bút toán thuộc phạm vi của nó. Quy tắc lãi, phí và vòng đời sản phẩm được cấu hình hoặc lập trình trong khuôn khổ được hỗ trợ, có phiên bản và có khả năng kiểm thử. “Mô-đun” không bắt buộc mỗi mô-đun là một sản phẩm của một hãng khác nhau. Cũng không bắt buộc các dịch vụ lõi phải dùng cơ sở dữ liệu phân tán theo cùng một cách.

Lớp tiếp cận và điều phối. API đưa yêu cầu vào đúng dịch vụ; quy trình điều phối theo dõi một hành trình nhiều bước. Ví dụ, mở tài khoản có thể bao gồm định danh, thiết lập hợp đồng, tạo tài khoản, phát hành thẻ và thông báo. Thanh toán ngoài ngân hàng còn phụ thuộc hệ thống thanh toán và kết quả quyết toán; phản hồi từ core không mặc nhiên là bằng chứng mọi công đoạn đã hoàn tất.

Nền tảng dữ liệu. Sự kiện nghiệp vụ và dữ liệu liên quan được tổ chức thành các sản phẩm dữ liệu dùng lại được. Kho dữ liệu lớn kết hợp lưu trữ và phân tích — thường gọi là lakehouse — hỗ trợ báo cáo, huấn luyện mô hình và phân tích dài hạn. Các quyết định cần phản ứng ngay còn cần dòng xử lý trực tuyến và dữ liệu phù hợp độ mới. Một bản sao phân tích không trở thành nguồn quyết định số dư khả dụng chỉ vì được gọi là “real-time”.

Nền tảng quyết định và AI. Quy tắc xác định trước, mô hình dự báo và agent có thể cùng tham gia. Chúng có thể phân loại dòng tiền, dự báo thiếu hụt, đề xuất ưu đãi hoặc chuẩn bị chỉ thị thanh toán. Khi cần tác động tới tiền, yêu cầu đi qua giao diện và điều kiện nghiệp vụ đã định; core vẫn phải thực hiện ghi nhận tài chính đúng. Nếu AI tạm không hoạt động, các dịch vụ giao dịch thiết yếu cần có hành vi đã thiết kế, thay vì mặc định mọi khoản tiền đều phải chờ một mô hình ngôn ngữ.

Nền tảng vận hành. Tự động hóa kiểm thử, phát hành, cấu hình môi trường, quan sát và xử lý công việc là phần của thiết kế đích. Một nền tảng có thể cung cấp những năng lực này trên hạ tầng riêng, public cloud hoặc dịch vụ SaaS. Tổ hợp thực tế cần được nhà cung cấp hỗ trợ và kiểm chứng. Đa cloud cũng không tự động tạo khả năng chuyển core sang nhà cung cấp khác.

Trong thiết kế này, xử lý giao dịch trong ngày có thể liên tục, nhưng các công việc theo ngày nghiệp vụ, lãi, đối soát và báo cáo vẫn tồn tại ở nơi cần thiết. Mục tiêu là thu hẹp phụ thuộc vào các đợt xử lý lớn và tổ chức chúng tốt hơn; không hứa rằng ngân hàng sẽ hết mọi xử lý định kỳ.

6. Đề xuất OLB: core mới cho tài khoản doanh nghiệp nhỏ

OLB là ngân hàng giả lập. Hồ sơ nền tảng hiện hành dùng core thương mại không nêu hãng, với hệ thống giao dịch lõi trên hạ tầng riêng DC–DR và định hướng hybrid cloud ở cấp ngân hàng. Phần dưới là đề xuất kiến trúc đích mới để nghiên cứu thay thế, chưa phải cập nhật đã được chấp thuận cho hồ sơ OLB. Không có dữ liệu khách hàng, cấu hình hoặc hồ sơ nội bộ của ngân hàng thật được dùng trong tình huống.

Đề xuất: chọn một nền tảng core thế hệ mới có sản phẩm, tài khoản và hạch toán đã được chứng minh; OLB làm chủ thiết kế sản phẩm, tích hợp, dữ liệu và dịch vụ khác biệt. Không mặc định OLB phải tự viết lại toàn bộ bộ máy hạch toán. Nhóm giải pháp mới và nền tảng thương mại đã hiện đại hóa đều có thể tham gia đánh giá nếu đáp ứng cùng bài toán.

Phạm vi mở đầu là “OLB Tài khoản dòng tiền SME”, dành cho doanh nghiệp nhỏ trong mô hình ngân hàng mẹ trong nước, dùng VND. Mục tiêu là giúp khách hàng nhìn và tổ chức tiền bán hàng, lương, nhà cung cấp và dự phòng thuế từ một trải nghiệm thống nhất. Đây là tên sản phẩm giả lập để nghiên cứu, không phải danh mục đã có mã chính thức.

Hành trình bắt đầu bằng một yêu cầu giả lập: “Lập kế hoạch chi tuần tới từ hóa đơn và tiền mới về; giữ đủ 70 triệu cho lương. Hãy trình phương án để tôi duyệt.” Trong bước đầu, OLB cung cấp trợ lý bên trong ứng dụng. Một bước nghiên cứu sau là cho agent trong phần mềm kế toán của doanh nghiệp tiếp cận các API được cấp quyền. Hai cách tiếp cận dùng cùng năng lực ngân hàng nhưng khác nơi khách hàng làm việc và chủ thể vận hành agent.

Tình huống có một khoản thu 120 triệu đồng vừa được ghi nhận. Kế hoạch tiền giả lập gồm 70 triệu cho lương, 20 triệu cho nhà cung cấp, 10 triệu dự phòng thuế và 20 triệu chưa phân bổ. Tổng các phần bằng khoản thu. Các giá trị chỉ minh họa; khoản dự phòng thuế không phải kết quả tính nghĩa vụ thuế và 20 triệu chưa phân bổ không tự đồng nghĩa số dư khả dụng của tài khoản.

Tham chiếu về tổ chức tiền và phân khúc là AMP với “Spaces”, Tangerine với khách hàng doanh nghiệp và Simplii với quản lý tiền theo mục tiêu. [8][5][4] Hành trình AI, quy tắc phân bổ và lộ trình OLB là thiết kế của Odin; bài không khẳng định các ngân hàng đó đang dùng cùng kiến trúc hoặc cùng chức năng tự chủ.

Để nối AI với automation trong thiết kế OLB, bộ thử cần theo dõi: agent có hiểu đúng yêu cầu và lấy đúng hóa đơn không; kế hoạch có đúng tổng tiền và thời hạn không; khách hàng đã đồng ý phạm vi nào; lệnh có được gửi một lần và kết quả có quay lại phần mềm kế toán không. Kịch bản thiếu tiền hoặc hóa đơn thay đổi phải làm phát sinh quyết định mới, không để một đề xuất cũ được thực hiện như thể dữ liệu chưa đổi. Đây là tiêu chí thiết kế chưa được kiểm thử thực tế.

Vị trí triển khai core mới còn là lựa chọn cần đánh giá. Phương án nghiên cứu ưu tiên khả năng vận hành trên cloud với tự động hóa tốt, đồng thời so sánh triển khai hạ tầng riêng được hỗ trợ với SaaS hoặc public cloud phù hợp bối cảnh. Chưa chọn hãng, vị trí dữ liệu hay cam kết công suất. Các ràng buộc pháp lý cụ thể cần được đánh giá trong hồ sơ triển khai, không suy ra từ một trường hợp ở Australia hoặc Canada.

7. Lộ trình thay core theo Phương pháp ODIN

Phương pháp ODIN hiện hành gồm Orient – Diagnose & Design – Implement – Navigate: định hướng; phân tích và lập kế hoạch; tổ chức thực hiện; theo dõi và điều chỉnh. [9] Ở bài này, bốn bước được dùng để tổ chức một chương trình đổi mới nền tảng, với kết quả kinh doanh làm điểm xuất phát.

Các khoảng thời gian và quy mô 1.000 doanh nghiệp là giả định lập kế hoạch nghiên cứu, không phải cam kết giao hàng hay kết quả thử tải. Chúng cần điều chỉnh sau đánh giá sản phẩm, dữ liệu, đội ngũ và năng lực giải pháp.

Cách chuyển đề xuất là mở mới một danh mục trên core mới, sau đó di chuyển từng nhóm tài khoản cũ. Mỗi tài khoản, hợp đồng hoặc danh mục phải có nơi ghi nhận có thẩm quyền tại từng thời điểm. Dữ liệu có thể được sao chép để kiểm tra và chạy tính toán đối chiếu; điều đó không có nghĩa hai core cùng được tự do ghi tiền cho một tài khoản. Khi giao dịch đi qua hai core, thiết kế thanh toán nội bộ và đối soát giữa chúng là một phần của chuyển đổi.

Trước khi chuyển một nhóm tài khoản, OLB cần kiểm chứng số dư, lãi tích lũy, điều kiện hợp đồng, lệnh chờ, hạn chế giao dịch và phụ thuộc báo cáo. Nếu sau chuyển đổi đã phát sinh giao dịch mới, quay về hệ thống cũ không đơn giản là đổi đường định tuyến: cần kế hoạch xử lý các ghi nhận mới. Đây là yêu cầu kỹ thuật của việc thay hệ thống ghi tiền, không phải một chương trình quản lý rủi ro tách rời.

OLB cũng cần thay cách tổ chức công việc: một nhóm sản phẩm chịu trách nhiệm hành trình SME; nhóm nền tảng core cung cấp năng lực giao dịch và sản phẩm; nhóm dữ liệu–AI cung cấp dữ liệu và quyết định dùng lại; nhóm nền tảng kỹ thuật bảo đảm các nhóm có thể kiểm thử và phát hành. Chỉ mua phần mềm mới sẽ không tự tạo ra nhịp phát triển mới.

8. Đánh giá thành công bằng kết quả kinh doanh

Trong năm đầu nghiên cứu, OLB nên chọn vài thước đo gắn trực tiếp với sản phẩm. Không lấy số lượng microservices, dung lượng data lake hoặc số agent làm kết quả cuối cùng.

Riêng kênh agent, cần đo tỷ lệ khách hàng hoàn tất mục tiêu, mức nhập lại thông tin, số lần xác nhận thực sự cần thiết và mức can thiệp sau khi agent bắt đầu. Nếu tính “tỷ lệ thanh toán do agent khởi tạo”, mẫu số phải là số lệnh thanh toán trong đúng phạm vi và kỳ đo; các câu hỏi tra cứu không được cộng vào đó. Ngân hàng cũng cần theo dõi chuyển đổi từ đề xuất sang sử dụng sản phẩm, chi phí mỗi hành trình và biến động quan hệ tiền gửi theo nhóm khách hàng.

Mô hình tài chính cho một giai đoạn có thể bắt đầu bằng: lợi ích tăng thêm từ khách hàng và tiền gửi + phần chi phí cũ thực sự bỏ được − toàn bộ chi phí mới và chuyển đổi. Sau đó cần xét thời điểm dòng tiền, chi phí vốn và các kịch bản tăng trưởng. Chi phí chạy cũ chỉ giảm khi hợp đồng, hạ tầng hoặc công việc tương ứng được cắt giảm thực tế; việc đưa một phần tải sang cloud chưa đủ.

Với 90 ngày đầu, đầu ra đề xuất là bản mô tả sản phẩm SME, đường cơ sở đo lường, bộ kịch bản nghiệp vụ dùng để đánh giá giải pháp, mô hình tổng chi phí và kiến trúc thử nghiệm có dữ liệu giả lập. Đây là bước đủ cụ thể để bắt đầu nghiên cứu một core mới, trước khi mua sắm hoặc thay đổi hồ sơ kiến trúc chính thức.

Định hướng dành cho OLB: nghiên cứu thay core thương mại hiện hữu bằng một nền tảng thương mại thế hệ mới phù hợp bài toán; bắt đầu từ sản phẩm dòng tiền SME, đồng thiết kế dữ liệu–AI và vận hành tự động, rồi chuyển dần các danh mục đủ điều kiện. Thành công được thể hiện bằng sản phẩm tốt hơn, chi phí phục vụ và thời gian thay đổi tốt hơn, cùng phần hệ thống cũ thực sự được loại bỏ.