Có một sự thật mà nhiều lãnh đạo công nghệ bảo hiểm nhận ra muộn hơn mong đợi: IFRS 17 không phải là một bài toán kế toán. Đó là bài toán kiến trúc dữ liệu.

Trong hai thập kỷ qua, các hệ thống core bảo hiểm tại Việt Nam được xây dựng với một triết lý nhất quán: phục vụ nghiệp vụ phát hành hợp đồng, thu phí, xử lý bồi thường và báo cáo theo chuẩn kế toán Việt Nam (VAS). Triết lý đó đã làm tốt nhiệm vụ của mình. Nhưng kể từ khi IFRS 17 chính thức có hiệu lực và Luật Kinh doanh bảo hiểm 2022 định hình lộ trình áp dụng trong nước, yêu cầu đặt ra cho core đã thay đổi về bản chất — không phải về quy mô.

Trục xoay căn bản nhất là thế này: thay vì ghi nhận doanh thu phí bảo hiểm theo kiểu “thu được thì hạch toán”, IFRS 17 yêu cầu doanh nghiệp phải mô hình hóa toàn bộ nghĩa vụ tài chính trong suốt vòng đời hợp đồng — bao gồm dòng tiền kỳ vọng trong tương lai, tỷ lệ chiết khấu, mức điều chỉnh rủi ro và biên dịch vụ theo hợp đồng (CSM). [2] Đây không phải là những con số mà hệ thống core truyền thống được thiết kế để lưu trữ và xử lý.

Hình 1 — Năm yêu cầu cốt lõi mà hệ thống core bảo hiểm phải đáp ứng để tuân thủ IFRS 17. Nguồn: IFRS.org, HLB Global, BCG 2023.

Tham khảo thêm các bài viết liên quan đến core bảo hiểm tại đây:

Chuyển Đổi Core Bảo Hiểm: Lộ Trình An Toàn Từ Hệ Thống Lõi Đến Real-Time

IFRS 17 Đang “Đòi Hỏi” Gì Từ Core?

Để hiểu đúng mức độ thay đổi, cần phân biệt rõ hai thế giới. Ở thế giới VAS, một hợp đồng bảo hiểm là một thực thể độc lập — nó có phí, có điều khoản, có trạng thái và được theo dõi cho đến khi đáo hạn hoặc chấm dứt. Ở thế giới IFRS 17, một hợp đồng chỉ có ý nghĩa khi đặt trong bối cảnh của nhóm mà nó thuộc về — một “group of contracts” được phân loại theo danh mục, theo năm phát hành (cohort), và theo mức độ có lãi hay thua lỗ (onerous/non-onerous). [4]

Đây là thay đổi về đơn vị tính toán, và nó kéo theo hàng loạt hệ quả. Khi đơn vị tính toán thay đổi, toàn bộ cách ghi nhận dữ liệu, cách phân bổ chi phí, cách đo lường nghĩa vụ — tất cả đều phải thay đổi theo. Hệ thống core, vốn là nơi dữ liệu hợp đồng “sống”, không thể đứng ngoài cuộc chuyển đổi đó.

Bên cạnh yêu cầu về nhóm hợp đồng, IFRS 17 còn đòi hỏi ba mô hình đo lường riêng biệt tùy theo đặc điểm sản phẩm: mô hình tổng quát (GMM) cho đa số hợp đồng nhân thọ dài hạn, cách tiếp cận phân bổ phí bảo hiểm (PAA) phù hợp cho phi nhân thọ, và mô hình phí biến đổi (VFA) dành cho sản phẩm có tham gia chia lãi. [2] Mỗi mô hình yêu cầu những tập dữ liệu đầu vào khác nhau, và core phải đủ linh hoạt để cung cấp đúng loại dữ liệu cho từng trường hợp.

“Core cũ vốn thiết kế cho nghiệp vụ và báo cáo địa phương, giờ phải trở thành ‘data engine’ cho IFRS 17, chứ không chỉ là hệ thống phát hành hợp đồng và thu phí.”

— PwC Vietnam, IFRS 17 Implementation Insights

Những “Khoảng Trống” Điển Hình của Core Hiện Tại

Phần lớn các hệ thống core đang vận hành tại Việt Nam được xây dựng trong giai đoạn 2005–2015, khi những khái niệm như “cohort phân loại theo năm phát hành” hay “cash flow tương lai chiết khấu” chưa hề xuất hiện trong yêu cầu thiết kế. Kết quả là những khoảng trống về dữ liệu rất cụ thể và khó vá nhanh.

Thứ nhất, data model không được xây dựng cho IFRS 17. Không có khái niệm nhóm hợp đồng, không có cơ chế lưu trữ giả định actuarial theo thời gian, không có trường dữ liệu cho biên dịch vụ hợp đồng (CSM) hay mức điều chỉnh rủi ro (RA). [5] Những thông tin này hiện nằm rải rác trong file Excel của đội actuarial, trong các bảng tính tạm thời của bộ phận tài chính, hoặc đơn giản là không tồn tại dưới dạng dữ liệu có cấu trúc.

Thứ hai, dữ liệu phân tán nghiêm trọng giữa nhiều hệ thống: core xử lý hợp đồng, module riêng cho bồi thường, một hệ thống khác cho tái bảo hiểm, thêm vài bảng Excel cho hoa hồng — và tất cả đều đổ vào hệ thống kế toán mà không có cơ chế đối soát đầu cuối tự động. [6] Khi IFRS 17 yêu cầu data lineage — tức là khả năng truy ngược từ con số trên báo cáo tài chính xuống từng hợp đồng nguồn — kiến trúc phân tán này trở thành điểm nghẽn cực kỳ nguy hiểm.

Hình 2 — Năm khoảng trống điển hình giữa hệ thống core hiện tại và yêu cầu IFRS 17. Nguồn: BCG 2023, EY IFRS 17, PwC Vietnam.

Thứ ba — và đây là vấn đề mà các doanh nghiệp thường nhận ra muộn nhất — là thiếu khả năng audit trail cho thay đổi giả định. IFRS 17 không chỉ yêu cầu tính đúng, mà còn yêu cầu giải thích được: tại sao CSM thay đổi từ kỳ này sang kỳ kia, giả định nào được cập nhật, ai phê duyệt, và ảnh hưởng định lượng là bao nhiêu. [7] Không có audit trail, doanh nghiệp không thể vượt qua được kiểm toán IFRS 17, bất kể con số tính toán có chính xác đến đâu.

Core Cần Thay Đổi Ở Những Lớp Nào?

Nhìn từ góc độ kiến trúc, câu trả lời không phải là “thêm một module IFRS 17 vào core cũ”. Đó là cách tiếp cận từng được thử nghiệm — và thường dẫn đến những hệ thống hỗn độn, vừa không đáp ứng yêu cầu IFRS vừa làm chậm năng lực xử lý nghiệp vụ gốc. Thay vào đó, bốn lớp trong kiến trúc cần được tư duy lại một cách có hệ thống.

Hình 3 — Kiến trúc 4 lớp mục tiêu cho hệ sinh thái công nghệ bảo hiểm IFRS-ready. Nguồn: EY Global DSP, BCG 2023, PwC Vietnam.

Lớp dữ liệu và kiến trúc — Nền móng của mọi thứ

Data model cần được thiết kế lại để mỗi hợp đồng có thể được gán vào danh mục, nhóm và cohort năm phát hành, đồng thời được đánh dấu là “có lãi” hay “thua lỗ” (onerous) theo định nghĩa của IFRS 17. [4] Quan trọng không kém là xây dựng “event model” chuẩn hóa: mọi sự kiện nghiệp vụ — từ chỉnh sửa hợp đồng, lapse, withdrawal một phần, cho đến mở lại hồ sơ bồi thường — đều phải sinh ra bản ghi có thể truy xuất để tính toán IFRS 17. [6]

Lớp tích hợp — Giữ cho hệ sinh thái không bị “đứt gãy”

Thiết kế chuẩn API và batch interface giữa core, IFRS 17 engine và hệ thống kế toán (GL/ERP) là điều kiện tiên quyết để đảm bảo tính nhất quán dữ liệu. Chiều đi từ core ra là dòng tiền chi tiết, biến động hợp đồng, đơn vị phủ bảo hiểm (coverage units). Chiều ngược lại — kết quả đo lường CSM, RA, LRC/LIC phản hồi lại để đối soát — cũng quan trọng không kém, nhưng thường bị bỏ quên. [5]

Lớp analytics — Từ tuân thủ đến lợi thế cạnh tranh

Doanh nghiệp nào làm tốt IFRS 17 sẽ đồng thời có trong tay một nền tảng dữ liệu rất mạnh cho quản trị rủi ro, định giá sản phẩm và lập kế hoạch vốn. Nhưng điều này chỉ đạt được nếu data lake/warehouse được xây dựng với schema tối ưu cho simulation và what-if, và nếu master data — sản phẩm, kênh phân phối, đối tác — được chuẩn hóa từ gốc. [8]

Chiến Lược Chuyển Đổi: Tránh Cái Bẫy “Big Bang”

Có một cám dỗ thường thấy trong những dự án lớn: thiết kế toàn bộ hệ thống từ đầu, triển khai một lần, cắt sang hệ thống mới trong một đêm cuối tuần. Trong bối cảnh IFRS 17, đây là cách tiếp cận có mức độ rủi ro rất cao — đặc biệt khi doanh nghiệp vừa phải tuân thủ deadline quy định vừa phải duy trì hoạt động kinh doanh liên tục.

Khuyến nghị nhất quán từ các tổ chức tư vấn lớn là dùng IFRS 17 như “chất xúc tác” để tái thiết kế công nghệ và quy trình tài chính – rủi ro, chứ không phải chỉ là một dự án compliance đơn thuần. [8] Điều đó có nghĩa là song song hóa hai quỹ đạo: một quỹ đạo ngắn hạn giải quyết yêu cầu báo cáo khẩn cấp bằng data layer trung gian, và một quỹ đạo dài hơn tái thiết core một cách có chiến lược.

Hình 4 — Mô hình lộ trình 3 wave cho chuyển đổi core bảo hiểm hướng IFRS 17. Thực tế tại Việt Nam cho thấy toàn bộ hành trình thường kéo dài 12–24 tháng. Nguồn: EY, PwC Vietnam, KPMG Vietnam 2025, FPT IS.

Trong mô hình ba làn sóng (three-wave) mà nhiều doanh nghiệp đã áp dụng thành công, làn sóng đầu tập trung hoàn toàn vào chuẩn hóa dữ liệu và interface — định nghĩa target architecture, thực hiện gap assessment chi tiết, và xây dựng IFRS 17 integration layer. Đây là phần công việc ít “sexy” nhất nhưng lại là điều kiện tiên quyết cho mọi thứ tiếp theo.

Làn sóng thứ hai mới bắt đầu chạm vào nghiệp vụ: cấu hình lại quy trình phê duyệt sản phẩm để bao gồm các tham số IFRS 17 (contract boundary, coverage units, phân loại mô hình đo lường), tự động hóa quy trình closing hàng tháng, và tích hợp chính thức với IFRS 17 engine. Làn sóng thứ ba — tối ưu vận hành và khai thác analytics — thực ra là phần đáng mong đợi nhất, khi những đầu tư của hai giai đoạn trước bắt đầu mang lại giá trị kinh doanh thực sự. [9]

Thực tế tại Việt Nam cho thấy phần lớn doanh nghiệp cần từ 12 đến 24 tháng để hoàn thành hành trình này và thường vượt ngân sách ban đầu — không phải vì thiếu quyết tâm, mà vì mức độ phức tạp của data transformation thường bị đánh giá thấp hơn thực tế. [1] Điều này càng nhấn mạnh tầm quan trọng của việc bắt đầu sớm, bắt đầu từ dữ liệu, và không để áp lực deadline quy định dẫn đến các quyết định kiến trúc vội vàng.

“Doanh nghiệp nào đầu tư đúng mức vào nền tảng dữ liệu cho IFRS 17 hôm nay sẽ có lợi thế cạnh tranh rõ rệt trong quản trị rủi ro và định giá sản phẩm trong 5 năm tới.”

— Tổng hợp từ EY, BCG Insurance Technology Review 2023

Kết Luận: Quy Định Như Một Cơ Hội Tái Cấu Trúc

Không doanh nghiệp nào chào đón thêm áp lực từ quy định. Nhưng IFRS 17, nhìn từ một góc độ khác, là cơ hội hiếm có để doanh nghiệp bảo hiểm buộc phải làm điều mà đáng lẽ phải làm từ lâu: xây dựng nền tảng dữ liệu thực sự vững chắc, thiết lập single source of truth, và loại bỏ những mảng “bóng tối” trong dữ liệu nghiệp vụ.

Những doanh nghiệp chọn cách tiếp cận tối thiểu — làm đủ để qua kiểm toán rồi thôi — sẽ thấy mình vẫn phải quay lại bài toán này trong vài năm tới, nhưng với chi phí cao hơn và tính cấp bách lớn hơn. Những doanh nghiệp chọn coi IFRS 17 là điểm khởi đầu cho hiện đại hóa toàn diện sẽ ra khỏi giai đoạn này với năng lực công nghệ vượt trội — và đó mới là lợi thế cạnh tranh bền vững.

Câu hỏi không phải là “có nên chuyển đổi core không”. Câu hỏi là “chuyển đổi như thế nào, với lộ trình nào, và bắt đầu từ đâu”.

Ông Hùng Nguyễn – Trưởng phòng Phát triển Sản phẩm – Khối Chăm sóc Sức khỏe FPT IS 

Chuyên gia có hơn 10 năm kinh nghiệm trong lĩnh vực phát triển phần mềm và chuyển đổi số, với thế mạnh trong việc thiết kế kiến trúc hệ thống, xây dựng sản phẩm số và dẫn dắt đội ngũ kỹ thuật triển khai các dự án quy mô lớn. Định hướng phát triển công nghệ gắn liền với chiến lược kinh doanh, giúp doanh nghiệp tối ưu vận hành và tạo ra lợi thế cạnh tranh bền vững.

Tài Liệu Tham Khảo

[1] KPMG Vietnam (2025). Raising Awareness on IFRS and IFRS 17. kpmg.com/vn — Số liệu 12–24 tháng và rủi ro vượt ngân sách triển khai IFRS 17 tại Việt Nam.

[2] IFRS Foundation (2023). IFRS 17 Insurance Contracts — Issued Standard. ifrs.org — Ba mô hình đo lường (GMM, PAA, VFA) và yêu cầu tách biệt LRC/LIC, theo dõi CSM.

[3] EY (2023). IFRS 17 Global DSP Considerations. ey.com — Khung kiến trúc 4 lớp và khuyến nghị target architecture.

[4] IFRS Vietnam (bản dịch). IFRS 17 — Hợp đồng bảo hiểm. ifrs.vn — Yêu cầu về group of contracts, cohort, portfolio và phân loại onerous.

[5] BCG (2023). IFRS 17 Requires New Data and Technology Strategies. bcg.com — Khoảng trống về data model, granularity dữ liệu và yêu cầu IFRS 17 integration layer.

[6] EY Vietnam (2024). IFRS 17 Implementation — Vietnam Perspective. ey.com/vi_vn — Vấn đề dữ liệu phân tán, event model chuẩn hóa và tự động hóa closing.

[7] EIOPA (2023). Report on Implementation of IFRS 17. eiopa.europa.eu — Yêu cầu audit trail, scenario/rerun và data lineage.

[8] EY (2023). How IFRS 17 Affects Insurers. ey.com — IFRS 17 như chất xúc tác hiện đại hóa, chuẩn hóa master data và simulation.

[9] FPT IS (2024). Góc nhìn số: Chuyển đổi core bảo hiểm. fpt-is.com — Mô hình 3-wave và chiến lược chuyển đổi core trong bối cảnh Việt Nam.

[10] HLB Global (2023). IFRS 17 and Its Impact on the Insurance Sector. hlb.global — Tác động đến tách biệt liability for remaining coverage vs incurred claims.

[11] PwC Vietnam (2021). IFRS 17 Press Release — Vietnam Roadmap. pwc.com/vn — Lộ trình IFRS tại Việt Nam và rủi ro giữ kiến trúc cũ.

[12] Duane Morris Blog / Dr. Oliver Massmann (2024). Vietnam Insurance Regulatory Update. blogs.duanemorris.com — Luật Kinh doanh bảo hiểm 2022 và bối cảnh quy định tại Việt Nam.