3. 费率表构建概述

在车险、健康险、责任险等大多数非寿险产品中，费率表是核保与定价的“中枢文件”。它把精算模型输出的风险成本，翻译成一线可执行的价格参数。理解费率表的定义、构成、监管约束与业务价值，是后续完成Rating Plan落地的前提。

一、核心原理：费率表到底是什么

费率表（Rate Table）是保险公司在特定险种、特定期间内，用于确定每一张保单应收保费的基准价格集合。它通常由基准费率、费率因子和计算规则三部分构成。基准费率回答“一类标准风险值多少钱”，费率因子回答“不同风险特征如何调整”，计算规则回答“这些因子如何组合、取整、上下限约束”。

从精算视角看，费率表是纯保费与附加费用在风险单元上的分摊结果；从系统视角看，它是核保引擎读取的参数配置；从业务视角看，它是报价、出单、续保、批改时价格一致性的唯一来源。三者必须指向同一份数据，否则会出现“精算算得出、系统跑不出、业务说不清”的断裂。

二、构成要素：一张费率表里有什么

一个完整的费率表结构，通常包含以下要素。理解这些要素的层级关系，比记住字段名更重要。

要素类别	典型内容	作用
险种与版本	险种代码、条款版本、费率版本号、生效期间	确定适用范围，避免新旧版本混用
基准费率	基准纯保费、基准附加费用、基准费率	定义标准风险的起始价格
费率因子	从人因子、从车因子、从地域因子、渠道因子、NCD因子	按风险特征调整价格
计算规则	因子相乘/相加、取整规则、最低保费、最高折扣	保证计算逻辑统一
约束条件	费率上下限、监管备案区间、地区差异系数	确保合规与风险可控
元数据	创建人、审批人、生效日期、变更记录	支持审计与版本追溯

其中，费率因子是最容易出问题的部分。因子之间是相乘还是相加，是否有交互项，是否存在“因子爆炸”，都会直接影响最终价格分布。实践中建议把因子分为主因子和修正因子两层，主因子决定价格量级，修正因子做微调，避免一张表里几十个因子平铺导致不可维护。

三、方法流程：从精算结果到可执行费率表

费率表构建不是“把模型结果抄进Excel”，而是一条有明确输入输出的工程链路。典型流程如下：

1. 需求确认：明确险种、地区、渠道、目标赔付率与费用率假设。
2. 模型输出整理：将GLM、GBM或经验费率结果整理为基准费率与因子系数。
3. 因子平滑与约束：对样本量不足的因子层级做合并或平滑，设置上下限。
4. 费率表结构化：按“险种—版本—因子维度—因子值—系数”的宽表或长表结构落库。
5. 系统配置与联调：在核保引擎中配置Rating Plan，验证取数、计算、取整、最低保费逻辑。
6. 回溯测试：用历史保单跑批，对比新旧费率下的保费分布与赔付率变化。
7. 审批与发布：完成精算、合规、业务三方签批，生成版本号并生效。

其中第4步的结构化设计最容易被低估。如果费率表以“一个因子一列”的宽表存储，新增因子就要改表结构；如果以“因子名—因子值—系数”的长表存储，扩展性更好，但查询性能需要索引优化。建议在配置层使用长表，在计算层缓存为宽表。

-- 费率因子长表结构示例
CREATE TABLE rate_factor (
  rate_version   VARCHAR(20)  NOT NULL,  -- 费率版本号
  factor_code    VARCHAR(30)  NOT NULL,  -- 因子代码，如 NCD、AGE_BAND
  factor_value   VARCHAR(50)  NOT NULL,  -- 因子取值，如 "0.7"、"25-30"
  factor_coef    DECIMAL(10,6) NOT NULL, -- 因子系数
  effective_date DATE         NOT NULL,
  expiry_date    DATE,
  PRIMARY KEY (rate_version, factor_code, factor_value, effective_date)
);

四、监管要求与业务价值

费率表不是保险公司可以随意调整的内部文件。在多数市场，车险、健康险等险种的费率表需要向监管机构备案或审批，且调整频率、调整幅度、地区差异系数都受到约束。监管关注的核心是：费率是否充足、是否公平、是否可解释。因此，费率表中每一个因子的设置，都需要有精算依据和业务合理性说明。

从业务价值看，一张好的费率表至少带来四方面收益：

• 价格一致性：同一风险在不同渠道、不同坐席、不同时间报价一致，减少客户投诉。
• 风险细分能力：通过因子组合，把低风险客户的价格降下来，把高风险客户的价格提上去，改善赔付率。
• 响应速度：费率表结构化后，调整因子系数即可快速上线新价格，无需每次改代码。
• 可审计性：每一张保单的保费都能追溯到费率版本和因子取值，满足内审与监管检查。

五、常见误区与复盘

在实际项目中，费率表构建最常见的误区有三个。第一，把费率表当成静态文档，精算出一版就锁死，业务变化后不及时更新，导致价格与风险脱节。第二，因子颗粒度过细，为了追求模型AUC而设置大量小样本因子，上线后价格波动剧烈，反而影响转化率。第三，系统实现与精算逻辑不一致，例如精算按因子相乘，系统却按相加，或者取整规则不同，导致跑批结果对不上。

总结来说，费率表是连接精算定价与业务执行的桥梁。它的定义决定了边界，构成要素决定了能力，监管要求决定了约束，业务价值决定了它必须被持续维护。只有把费率表当作“活的产品资产”而非“一次性交付物”，Rating Plan的落地才有稳定基础。