Thực chiến bảo hiểm: thẩm định (underwriting) & tính phí theo bảng quyết định + hệ số actuarial

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

Công ty bảo hiểm nhân thọ giả định VietLife xử lý trung bình 42.000 hồ sơ yêu cầu bảo hiểm mới mỗi tháng qua kênh online và đại lý, trong đó khoảng 68% được hệ thống thẩm định tự động (straight-through processing) chấp nhận trong dưới 5 phút, phần còn lại chuyển sang chuyên viên thẩm định (underwriter) người. Hệ thống Underwriting & Pricing Engine (UPE) là lõi nghiệp vụ quyết định ai được bảo hiểm, mức phí bao nhiêu, và loại trừ điều khoản nào — sai một quyết định có thể khiến công ty nhận rủi ro dưới giá (rủi ro cao nhưng phí thấp) hoặc mất khách vì phí quá cao so với rủi ro thực.

Phạm vi kiểm thử bài này tập trung vào 3 module: (1) thu thập dữ liệu rủi ro (tuổi, giới tính, BMI, tiền sử hút thuốc, nghề nghiệp, bệnh nền), (2) engine bảng quyết định (decision table) ánh xạ tổ hợp yếu tố sang quyết định chấp nhận/từ chối/refer, và (3) engine tính phí actuarial nhân các hệ số theo thứ tự chuẩn. Ràng buộc tuân thủ quan trọng: mọi quyết định từ chối phải có lý do bằng văn bản lưu vết (theo quy định bảo vệ người tiêu dùng bảo hiểm), và bảng hệ số actuarial phải khớp với bảng đã được bộ phận actuary phê duyệt, không được hard-code rải rác trong code ứng dụng.

Phạm vi tự động hoá kiểm thử

• API thu thập rủi ro & tính điểm sơ bộ (risk scoring)
• API decision-table engine (accept/decline/refer)
• API tính phí actuarial (premium calculation)
• Luồng end-to-end nộp hồ sơ → nhận báo giá
• Báo cáo đối soát phí actuarial hàng tháng

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

UPE được thiết kế dạng microservices: Application Service nhận hồ sơ từ web/app, Risk Data Service tổng hợp dữ liệu từ MIB (Medical Information Bureau), bureau tín dụng và telematics nghề nghiệp qua các API bên thứ ba, Decision Engine áp bảng quyết định dạng cấu hình (không hard-code), và Rating Service tính phí cuối cùng. Giao tiếp giữa Application Service và Decision Engine là đồng bộ (REST, timeout 3 giây) vì khách hàng chờ báo giá ngay trên màn hình, trong khi việc đối soát với MIB chạy bất đồng bộ qua hàng đợi Kafka với SLA phản hồi 24 giờ cho các ca cần tra cứu sâu.

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

• Dữ liệu MIB/bureau tín dụng là bên thứ ba — không thể gọi thật trong môi trường test
• Bảng quyết định có thể thay đổi theo mùa/quý — test phải bám cấu hình động
• Race condition khi 2 hồ sơ cùng khách hàng nộp gần như đồng thời

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

Thực thể trung tâm là Application (hồ sơ) gắn với RiskProfile (điểm rủi ro), DecisionResult (kết quả tra bảng quyết định, gồm ruleId trúng) và Quote (báo giá cuối). Mỗi Application chỉ được có duy nhất một DecisionResult hiệu lực tại một thời điểm; nếu dữ liệu rủi ro thay đổi (ví dụ khách bổ sung hồ sơ khám sức khỏe), hệ thống phải tạo phiên bản DecisionResult mới và đánh dấu phiên bản cũ là superseded chứ không được sửa đè lịch sử — đây là yêu cầu audit bắt buộc của cơ quan quản lý bảo hiểm.

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

• Mỗi tổ hợp input hợp lệ khớp đúng 1 hàng (rule) trong bảng quyết định — không 0, không >1
• Phí cuối = base(tuổi,giới) × Π(hệ số nghề, sức khỏe, bệnh nền) × (1 − chiết khấu), làm tròn 2 chữ số, luôn > 0
• Nhóm nghề rủi ro tuyệt đối (nhóm 4) luôn bị decline bất kể các yếu tố khác — loại trừ cứng, không thể ghi đè bởi override thường
• Mọi quyết định decline/refer phải có reasonCode và diễn giải lưu vết, không được trống
• DecisionResult là bất biến (immutable) một khi đã phát hành báo giá cho khách; thay đổi tạo bản ghi mới, versioned