Thực chiến bảo hiểm: tái tục hợp đồng (renewal), sửa đổi (endorsement) & proration

1. Bối cảnh doanh nghiệp & phạm vi

VietLife quản lý danh mục 1,1 triệu hợp đồng bảo hiểm nhân thọ và phi nhân thọ đang hiệu lực, trong đó khoảng 9% hợp đồng phát sinh yêu cầu sửa đổi (endorsement) giữa kỳ mỗi năm — tăng/giảm hạn mức bảo hiểm, đổi người thụ hưởng, thêm điều khoản bổ sung — và 100% hợp đồng phải qua quy trình tái tục (renewal) vào cuối mỗi kỳ 12 tháng nếu khách hàng không hủy. Module Policy Lifecycle Service (PLS) chịu trách nhiệm tính toán phí theo tỷ lệ thời gian còn lại (proration), phát hành phiên bản hợp đồng mới, và đảm bảo hiệu lực bảo hiểm không bao giờ bị gián đoạn — một ngày gián đoạn hiệu lực có thể khiến công ty từ chối bồi thường sai cho khách hàng vẫn đang đóng phí đều đặn.

Phạm vi kiểm thử bài này tập trung: (1) engine proration tính phí bổ sung/hoàn khi endorsement giữa kỳ, (2) quy trình phát hành phiên bản hợp đồng mới khi tái tục, đảm bảo continuity of coverage (hiệu lực liên tục không gap/overlap), và (3) đối soát cuối kỳ giữa số tiền billing thực thu và số tiền proration tính toán. Ràng buộc nghiệp vụ nghiêm ngặt: mọi thay đổi hợp đồng phải lưu vết dạng version (endorsement history), không cho phép sửa đè bản ghi cũ, phục vụ yêu cầu tra soát khi có khiếu nại hoặc thanh tra.

Phạm vi tự động hoá

• API tính proration cho endorsement giữa kỳ
• API phát hành phiên bản hợp đồng khi tái tục
• Kiểm tra continuity hiệu lực (không gap/overlap)
• Đối soát billing vs proration cuối kỳ
• Luồng E2E: khách yêu cầu tăng hạn mức → nhận hoá đơn bổ sung

2. Kiến trúc & luồng nghiệp vụ

PLS tách biệt 3 service: Endorsement Service xử lý thay đổi giữa kỳ và gọi Proration Engine để tính phí chênh lệch, Renewal Service chạy batch hàng đêm quét các hợp đồng sắp hết hạn trong 30 ngày tới để chuẩn bị báo giá tái tục, và Billing Service ghi nhận giao dịch thu/hoàn tiền thực tế liên kết ngân hàng đối tác. Endorsement và Renewal đều publish sự kiện `PolicyVersionCreated` lên Kafka để Billing Service và Notification Service (gửi email/SMS khách hàng) subscribe xử lý bất đồng bộ, tránh khoá luồng chính khi hệ thống thanh toán bên thứ ba chậm.

Điểm khó khi kiểm thử

• Proration phải tính đúng theo lịch (30/360 hay lịch thực actual/365) — sai quy ước gây lệch phí nhỏ nhưng tích luỹ lớn
• 2 endorsement hiệu lực cùng ngày cần thứ tự xử lý tuần tự rõ ràng
• Batch renewal đêm phải idempotent nếu chạy lại do lỗi giữa chừng

3. Mô hình dữ liệu & bất biến nghiệp vụ (oracle)

Thực thể Policy có nhiều PolicyVersion theo thời gian, mỗi PolicyVersion có effectiveFrom/effectiveTo không được chồng lấn với version khác của cùng Policy. Mỗi Endorsement tạo ra một PolicyVersion mới và một ProrationAdjustment ghi số tiền dương (thu thêm) hoặc âm (hoàn), trong khi Renewal tạo PolicyVersion mới với effectiveFrom bằng đúng effectiveTo + 1 ngày của version trước đó — đây là bất biến continuity quan trọng nhất của toàn hệ thống.

Bất biến nghiệp vụ (oracle) bắt buộc

• Không có gap: version(N).effectiveTo + 1 ngày = version(N+1).effectiveFrom
• Không có overlap: khoảng [effectiveFrom, effectiveTo] của 2 version bất kỳ không giao nhau
• Bảo toàn phí: phí gốc + Σ ProrationAdjustment của mọi endorsement = phí cuối cùng trong billing, sai số < 0,01
• Proration = phí năm ÷ tổng ngày kỳ × số ngày còn lại kể từ ngày hiệu lực thay đổi, làm tròn theo quy ước day-count đã xác nhận
• Endorsement history là append-only: không bao giờ UPDATE/DELETE bản ghi PolicyVersion cũ, chỉ tạo bản ghi mới và đánh dấu supersededBy