3. 数据基础
准备金评估的质量，几乎在数据准备阶段就已经被决定。IBNR、Case Reserve 与赔付发展诊断看似是模型与判断问题，但真正导致结果失真的，往往是理赔数据分类口径不一致、三角形构建错位、事故期与进展期定义混乱，以及异常值未被识别。本章聚焦数据基础，目标是把“可用的理赔数据”转化为“可诊断的三角形数据”。
一、核心原理：从逐案赔案到发展三角形
准备金评估的底层数据单元是逐案理赔记录，每条记录至少应包含：赔案号、事故日期、报案日期、结案日期、已付赔款、Case Reserve、险种、机构、状态等字段。核心原理是：按事故期归集风险暴露，按进展期观察赔付发展，最终形成“事故期 × 进展期”的累计赔付矩阵。
事故期（Accident Period）通常为事故发生的年度或季度，代表风险归属；进展期（Development Period）是事故期到评估时点的时间间隔，常用 12、24、36 个月或 0、1、2 年表示。累计已付赔款随进展期单调不减，这是三角形数据的基本约束。若出现倒挂，说明数据存在冲销、重复或口径问题。
二、方法流程：分类、构建、清洗三步走
- 理赔数据分类：按险种、机构、渠道、案件类型分层，确认是否满足同质性。分类过粗会掩盖风险差异，过细会导致每格数据稀疏。
- 三角形数据构建：确定事故期与进展期粒度，按评估时点截取数据，计算累计已付与已发生金额，形成上三角矩阵。
- 数据清洗与异常值处理：检查负值、倒挂、缺失、重复、巨灾大案、滞后报案，逐项标记并决定保留、调整或剔除。
构建三角形时，评估时点（Valuation Date）必须统一。例如评估时点为 2024-12-31，则 2024 事故期只观察到第 12 个月进展，不能强行填充后续进展期。常见做法是保留上三角，下三角留空，由后续模型外推。
# 三角形构建伪代码
for accident_year in 2015..2024:
for dev in 0..9:
cutoff = accident_year + dev
if cutoff <= valuation_year:
C[accident_year][dev] = sum(paid + case_reserve)
else:
C[accident_year][dev] = None # 下三角留空三、案例场景：一张三角形背后的数据问题
某财险公司车险业务，2019 事故期在进展期 24 个月的累计已付赔款低于 12 个月，形成明显倒挂。排查后发现三类问题：一是部分案件在 12 个月时点被重复导入，二是跨年冲销未按事故期回冲，三是大案估损在 12 个月时虚高、24 个月时被下调。经过按赔案号去重、按事故期重新归集、对 Case Reserve 变动设置阈值告警后，三角形恢复单调。
| 检查项 | 典型问题 | 处理建议 |
|---|---|---|
| 事故期归属 | 按报案日期而非事故日期归集 | 统一以事故日期为准，缺失时回退报案日期并标记 |
| 进展期口径 | 月度与年度混用 | 固定粒度，评估时点统一 |
| 累计值单调性 | 出现倒挂 | 检查冲销、重复、估损调整 |
| 异常大案 | 单案影响整格 | 单独列示，评估是否剔除或分层 |
| 缺失与滞后 | 报案延迟导致低估 | 设置报案滞后因子或补录机制 |
四、误区与复盘：数据基础中最容易踩的坑
复盘时建议建立数据质量日志，记录每次清洗的规则、影响金额与影响格数。例如：
2024-12-31 数据清洗日志
- 去重赔案：1,204 条，影响已付 86 万
- 倒挂修正：2019 事故期 24 月，回冲 32 万
- 大案标记：单案 > 500 万，共 7 件，单独列示
- 事故期缺失：312 条，按报案期回退并标记数据基础不是简单的搬运工作，而是准备金评估的第一道专业判断。分类决定同质性，三角形决定可观察性，清洗决定可信度。把这三件事做扎实，后续的 IBNR 估计与赔付发展诊断才有稳固的起点。