API-first banking và microservices: từ Thông tư 64 đến quyết định thực tiễn

Ngày 04/11/2026

Kiến trúc API-first kết hợp microservices giúp ngân hàng thay đổi từng phần hệ thống thay vì thay toàn bộ core banking. Tại Việt Nam, Thông tư 64/2024/TT-NHNN về Open API đã biến năng lực này thành yêu cầu tuân thủ. Bài viết đặt lợi ích cạnh cái giá phải trả để lãnh đạo CNTT khối BFSI có căn cứ quyết định lộ trình.

Tham khảo bài viết cùng chủ đề: Hiện đại hóa hệ thống lõi

Hiện đại hóa hệ thống lõi: chọn lift & shift, re-platform hay rebuild, và đi theo thứ tự nào

API-first và microservices là gì, khác nhau ra sao

API-first là cách thiết kế, trong đó giao diện lập trình ứng dụng (API) được xác định trước và trở thành điểm kết nối chung cho ứng dụng nội bộ, kênh số và đối tác. Microservices là cách tổ chức hệ thống. Martin Fowler định nghĩa đây là phương pháp phát triển một ứng dụng duy nhất dưới dạng tập hợp các dịch vụ nhỏ, mỗi dịch vụ chạy trong tiến trình riêng và giao tiếp bằng cơ chế nhẹ, thường là API tài nguyên qua HTTP. Các dịch vụ được xây quanh năng lực nghiệp vụ và triển khai độc lập bằng hệ thống tự động hóa.

Hai khái niệm bổ trợ cho nhau nhưng không đồng nhất. API-first trả lời câu hỏi các bên giao tiếp qua hợp đồng nào, còn microservices trả lời câu hỏi hệ thống được cắt thành những phần nào. Một ngân hàng có thể công bố API ở phía trước trong khi lõi vẫn là một khối nguyên (monolith), và ngược lại.

Khảo sát State of the API 2024 của Postman, công bố ngày 15/10/2024 với hơn 5.600 nhà phát triển và chuyên gia API, cho thấy 74% người trả lời theo hướng API-first trong năm 2024, tăng từ 66% của năm 2023. Đây là số liệu của ngành phần mềm nói chung, không riêng ngân hàng.

Hình 1: Sơ đồ so sánh monolith, microservices và API-first: API-first là cách thiết kế, microservices là cách tổ chức.

Vì sao ngân hàng cần chuyển bây giờ

Chỉ khoảng 30% dự án chuyển đổi core banking hoàn tất việc di chuyển trọn vẹn. Con số này nằm trong phân tích hơn 50 dự án chuyển đổi mà McKinsey công bố ngày 17/02/2022. McKinsey cũng ghi nhận có ngân hàng chi vượt ngân sách 100%, còn tiến độ kéo dài thêm 50% đến 100%. Để tránh phình phạm vi và chi phí, McKinsey đề xuất lên lịch go-live mỗi một đến hai năm.

Tuy nhiên, McKinsey cũng tách riêng phần đóng góp của microservices. Trong phân tích ngày 28/04/2021, McKinsey cho biết các đơn vị áp dụng đầy đủ cách tiếp cận hiện đại hóa có thể rút ngắn một nửa thời gian chuyển đổi và giảm 70% chi phí. Riêng nguyên tắc về core và microservices chỉ mang lại mức giảm điển hình 15% chi phí và 10% thời gian. Các số liệu này thuộc giai đoạn 2021 đến 2022, nên lãnh đạo CNTT chỉ nên dùng làm mốc tham chiếu.

Hình 2: Chuyển đổi core banking tiềm ẩn rủi ro về chi phí và tiến độ, trong khi nguyên tắc về core và microservices có thể giảm khoảng 15% chi phí và 10% thời gian (McKinsey, 2021 và 2022).

Bối cảnh Việt Nam: Thông tư 64/2024/TT-NHNN

Ngày 31/12/2024, Thống đốc Ngân hàng Nhà nước (NHNN) ban hành Thông tư 64/2024/TT-NHNN, và văn bản này có hiệu lực từ ngày 01/3/2025. Theo Cổng thông tin NHNN, Open API là kênh kết nối giúp ngân hàng cung cấp giao diện lập trình ứng dụng cho bên thứ ba.

Về kỹ thuật, kết nối Open API phải áp dụng kiến trúc REST, định dạng dữ liệu JSON và cơ chế xác thực OAuth 2.0. Hệ thống triển khai Open API phải đáp ứng tối thiểu cấp độ 3 về an toàn hệ thống. Theo Tạp chí Ngân hàng, ngân hàng còn phải ghi nhật ký toàn bộ việc bên thứ ba sử dụng Open API trong tối thiểu 03 tháng và có giải pháp công nghệ giới hạn số lần truy vấn tự động thông tin của khách hàng.

Về trách nhiệm, ngân hàng là bên kiểm soát dữ liệu và chịu trách nhiệm pháp lý cuối cùng đối với dữ liệu được chia sẻ, còn bên thứ ba chỉ được khai thác thông tin đúng phạm vi đã thỏa thuận. Tạp chí Ngân hàng cảnh báo việc chia sẻ này có thể tiềm ẩn rủi ro lộ, lọt dữ liệu hoặc sử dụng dữ liệu khách hàng sai mục đích.

Mức độ sẵn sàng của ngành không đồng đều. Theo Thời báo Tài chính Việt Nam ngày 14/11/2025, NHNN đánh giá dựa trên báo cáo và kế hoạch của hơn 70 tổ chức tín dụng. Nhóm tích cực gồm các ngân hàng “big 4”, VPBank, Sacombank, MB và TPBank, còn nhóm chậm gồm Maybank, SMBC, BIDC và First Commercial Bank. Thời báo Tài chính Việt Nam nhận định nhóm chậm phải nghiên cứu quy định, tìm giải pháp công nghệ và chờ phê duyệt từ ngân hàng mẹ, trong khi cả ngành cùng đối mặt với việc chuẩn hóa dữ liệu, quản trị rủi ro bên thứ ba và an ninh mạng.

Hình 3: Thông tư 64/2024/TT-NHNN được ban hành ngày 31/12/2024, có hiệu lực từ 01/3/2025 và đặt ra bốn yêu cầu kỹ thuật chính cho Open API.

Ba ngân hàng, ba cách đi: Monzo, ANZ và Techcombank

Monzo là trường hợp chọn nhiều dịch vụ nhỏ ngay từ đầu. Theo The Register ngày 09/03/2020, ngân hàng thành lập năm 2015 này vận hành hệ thống trên 1.600 microservices cho hơn 4 triệu khách hàng. Một kỹ sư của Monzo nói tại QCon London rằng ngân hàng muốn giảm rủi ro khi thay đổi. Vì vậy, đội ngũ ưu tiên nhiều dịch vụ nhỏ, mỗi dịch vụ một mục đích, thay vì ít dịch vụ phức tạp hơn.

ANZ đi theo hướng ngược lại, tức là cải tạo hệ thống đang chạy. iTnews ngày 26/09/2023 cho biết ngân hàng này dành khoảng hai năm để tái kiến trúc các ứng dụng monolith thành các thành phần microservices và dịch vụ dựa trên API. Về vận hành, khi xảy ra sự cố cục bộ, khách hàng vẫn thực hiện được 90% việc họ muốn làm.

Techcombank là minh họa gần với thị trường Việt Nam. The Asian Banker ngày 31/07/2025 mô tả ngân hàng đã áp dụng kiến trúc cloud-native xây trên microservices để mở rộng khối lượng giao dịch, đồng thời dùng open API để tích hợp với đối tác thuộc nhiều ngành, trong đó nền tảng ưu đãi kết nối với hơn 450 thương hiệu đối tác. Đây là mô tả định hướng kiến trúc, chưa phải số đo kết quả.

Cái giá phải trả

Trường hợp Monzo cũng cho thấy hướng đi này có cái giá riêng. The Register ghi nhận chạy 1.600 microservices không thể thực hiện trên một chiếc laptop, và Monzo từng gặp một sự cố lớn năm 2017 liên quan đến Kubernetes, etcd và linkerd. Martin Fowler nhận định microservices, như mọi kiểu kiến trúc, mang theo cả chi phí lẫn lợi ích.

Chi phí đầu tiên là độ phức tạp vận hành. Fowler chỉ ra rằng cuộc gọi từ xa tốn kém hơn cuộc gọi trong cùng tiến trình, nên ứng dụng phải chịu được lỗi của từng dịch vụ. Triển khai nhiều dịch vụ cũng khó hơn triển khai một monolith, nên giám sát là yếu tố thiết yếu.

Chi phí thứ hai nằm ở dữ liệu. Giao dịch phân tán rất khó triển khai, và Fowler cho rằng hệ thống phải chấp nhận nhất quán cuối cùng (eventual consistency, tức dữ liệu giữa các dịch vụ khớp nhau sau một khoảng trễ), đồng thời xử lý sai lệch bằng các thao tác bù.

Chi phí thứ ba là an ninh API. Theo khảo sát năm 2023 của Salt Security cho ngành tài chính và bảo hiểm, 92% tổ chức gặp sự cố an ninh trong API đang chạy thực tế trong năm trước đó. Gần 70% doanh nghiệp bị trì hoãn triển khai vì vấn đề an ninh API, 84% cuộc tấn công đến từ người dùng đã được xác thực nên trông hợp lệ, và 28% tổ chức chưa có chiến lược API. Infosecurity Magazine, nơi đăng tải kết quả này, không nêu cỡ mẫu khảo sát.

Vì vậy hội đồng kiến trúc cần trả lời ba câu hỏi trước khi tách dịch vụ: hệ thống giám sát đã đủ để phát hiện lỗi giữa các dịch vụ hay chưa, nghiệp vụ nào chấp nhận được nhất quán cuối cùng, và ngân hàng có chiến lược API chung hay mỗi nhóm tự công bố API riêng.

Hình 4: Bảng cân nhắc lợi ích và rủi ro của API-first và microservices, kèm số liệu và nguồn.

Kết luận: lộ trình cho ngân hàng Việt Nam

Câu trả lời ngắn cho lãnh đạo CNTT là ngân hàng nên áp dụng API-first và microservices theo từng miền nghiệp vụ, không thay toàn bộ core cùng lúc, vì Thông tư 64/2024/TT-NHNN yêu cầu chuẩn kỹ thuật và an toàn rõ ràng cho Open API, còn các dự án chuyển đổi trọn gói có nguy cơ vượt chi phí và tiến độ.

Lộ trình gồm bốn bước. Bước đầu tiên là kiểm kê API hiện có và xác định API thuộc phạm vi Open API. Bước thứ hai là chọn một miền nghiệp vụ để tách trước, với các mốc go-live ngắn, tương tự khuyến nghị một đến hai năm mà McKinsey đưa ra cho chuyển đổi core. Bước thứ ba là thiết lập quản trị API và giám sát theo các yêu cầu của thông tư về xác thực, nhật ký tối thiểu 03 tháng, giới hạn truy vấn tự động và cấp độ 3 về an toàn hệ thống. Bước thứ tư là đo kết quả bằng chỉ số cụ thể, chẳng hạn thời gian tạo một API mới (Postman ghi nhận 63% nhà phát triển làm được trong một tuần), tỷ lệ tác vụ khách hàng còn thực hiện được khi sự cố cục bộ (ANZ nêu mức 90%) và số sự cố an ninh trong API đang vận hành.

Tác giả: Lê Thanh Hải – Chuyên gia công nghệ ngân hàng – FPT IS – Tập đoàn FPT