人身保险核保系统专业术语与业务逻辑详解手册

我所在的项目组负责人身保险系统中的核保模块（Underwriting Module），并且已经接触到“核保函”“体检函”“健康函”“契调函”“财务函”等关键概念。这些“函件”是核保流程中信息补充、风险评估、决策支持的核心载体。

以下是一份专为 Java 后端开发者 编写的《人身保险核保系统专业术语与业务逻辑详解手册》，内容涵盖：

• 核保整体流程与定位
• 各类核保函件的定义、作用、触发条件与处理逻辑
• 函件生命周期（下发、回销、超时）
• 系统设计中的关键实体与状态机
• 实际开发建议、注意事项与合规要求
• 附：核保术语中英对照表 + 代码建模建议

---

📘 人身保险核保系统专业术语与业务逻辑详解手册

（Java 后端开发者专用）

---

一、核保（Underwriting）是什么？为什么重要？

1.1 定义

核保是保险公司对投保申请进行风险评估与承保决策的过程，目的是：

• 判断是否接受投保
• 确定以何种条件承保（标准体、加费、除外责任、拒保等）

1.2 在系统中的定位

• 上游：接收来自“投保录入”模块的申请（Application）
• 下游：输出核保结论，驱动“保单生成”或“拒保通知”
• 核心逻辑：规则引擎 + 人工干预 + 函件补充调查

💡 开发者认知：核保不是“审批”，而是“风险定价”。你的代码决定了公司是否“接了一单好生意”。

---

二、核保函件体系详解

在人身险核保中，当自动核保无法直接给出结论时，系统会下发函件，要求客户或第三方提供额外信息。这些函件统称为 “核保函”（Underwriting Letter / Request）。

2.1 四大类客户函件（面向投保人/被保险人）

函件类型	全称	触发场景	作用	回销内容
体检函	Medical Examination Letter	年龄偏大、保额高、健康告知异常	要求到指定医院体检	体检报告（含血压、血糖、B超等）
健康函	Health Inquiry Letter	健康告知“是”（如曾住院、有慢性病）	补充疾病详情、治疗情况	病历、诊断证明、复查结果
契调函	Medical & Lifestyle Investigation Letter	高保额、职业风险高、多份投保	调查生活习惯、既往病史、投保动机	调查员报告（含面访记录）
财务函	Financial Verification Letter	投保保额远超年收入、职业收入不明	验证缴费能力与财务真实性	收入证明、银行流水、税单

✅ 关键区别：

• 体检函、健康函：由客户自行提供材料
• 契调函：由保险公司委托第三方调查员执行
• 财务函：验证“是否买得起”，防止道德风险

---

2.2 其他常见核保函件（补充）

类型	说明
补充资料函	通用函件，用于索取任意缺失材料
生存调查函	验证被保险人是否生存（防冒名投保）
同业投保查询函	向其他保险公司查询客户是否重复高额投保

---

三、函件生命周期：下发 → 处理 → 回销 → 核保决策

3.1 函件状态机（核心！）

3.2 关键状态说明

状态	说明	技术处理建议
ISSUED	函件已生成并通知客户	记录下发时间、渠道（短信/邮件/APP）
PENDING_RESPONSE	等待客户/机构回传材料	启动倒计时（通常7–30天）
RESPONDED	材料已上传	触发核保员待办任务
EXPIRED	超时未回	自动流转至“拒保”或“延期”
COMPLETED	核保员已处理，函件闭环	关联核保结论

---

3.3 函件超时处理（重要！）

• 默认时效：体检函（15天）、健康函（10天）、契调函（20天）、财务函（15天）
• 超时后果：
  • 自动标记为 EXPIRED
  • 可配置策略：自动拒保 / 转人工 / 允许延期一次
• 开发注意：需定时任务扫描 issued_date + ttl < now 的函件

// 伪代码：函件超时处理任务
@Scheduled(cron = "0 0 2 * * ?") // 每日凌晨2点
public void processExpiredLetters() {
    List<UnderwritingLetter> expired = letterRepo.findExpired();
    for (UnderwritingLetter letter : expired) {
        letter.setStatus(EXPIRED);
        underwritingService.handleExpiredLetter(letter.getApplicationId());
    }
}

---

四、核保决策与函件的关系

函件不是目的，而是获取信息以支持决策。常见决策路径：

投保申请
   ↓
自动核保引擎判断
   ↓
需要更多信息？ → 是 → 下发函件（体检/健康/契调/财务）
   ↓ 否
直接给出结论（标准/加费/拒保）
   ↓
客户回销函件材料
   ↓
人工核保员复核
   ↓
生成最终核保结论

⚠️ 注意：一张投保单可能同时下发多类函件（如高保额+健康异常 → 体检函 + 财务函）

---

五、系统关键实体与数据模型（Java 开发视角）

5.1 核心实体关系

Application (投保申请)
  └── UnderwritingTask (核保任务)
        └── UnderwritingLetter (核保函件) [1:N]
              ├── letterType: ENUM (MEDICAL, HEALTH, INVESTIGATION, FINANCIAL)
              ├── status: ENUM (ISSUED, RESPONDED, EXPIRED...)
              ├── issuedAt: LocalDateTime
              ├── dueDate: LocalDate
              ├── response: Blob (或关联文件ID)
              └── operator: String (处理人)

5.2 推荐代码结构

// 枚举：函件类型
public enum LetterType {
    MEDICAL_EXAM("体检函"),
    HEALTH_INQUIRY("健康函"),
    INVESTIGATION("契调函"),
    FINANCIAL_VERIFICATION("财务函");
}

// 函件实体
@Entity
public class UnderwritingLetter {
    @Id
    private String letterId;
    private String applicationId;
    private LetterType type;
    private LetterStatus status;
    private LocalDateTime issuedAt;
    private LocalDate dueDate;      // 到期日 = issuedAt + TTL
    private String responseFileId;  // 回销材料文件ID
    private String handler;         // 核保员工号
}

// 服务层
@Service
public class UnderwritingLetterService {
    public void issueLetter(String applicationId, LetterType type) { ... }
    public void respondLetter(String letterId, String fileId) { ... }
    public void handleExpiredLetters() { ... }
}

---

六、实际开发中的推荐做法与高危注意事项

✅ 推荐做法

场景	建议
函件下发	记录下发渠道（APP推送、短信、邮件），便于追踪
材料上传	文件存储使用对象存储（如 OSS/S3），数据库只存 ID
状态变更	所有状态变更写入审计日志（含操作人、时间、原因）
超时处理	支持配置化 TTL（不同产品/渠道可不同）
人工干预	提供“延期”功能，但需记录理由（合规要求）

⚠️ 高危注意事项（务必警惕！）

1. 不要允许客户无限期拖延

   • 必须设置硬性超时，否则核保流程卡死，影响承保时效

2. 函件与投保单强绑定

   • 函件必须关联 application_id，禁止跨单使用

3. 回销材料需校验完整性

   • 例如体检函必须包含指定项目（血常规、尿常规等），系统可做基础校验

4. 契调函涉及隐私，需授权

   • 下发契调函前，需客户签署《生存调查授权书》（系统需记录授权状态）

5. 所有函件操作需留痕

   • 监管检查时，需能还原“何时下发、谁处理、材料内容”

---

七、合规与监管要求

• 《保险法》第十七条：保险公司有权要求投保人如实告知，必要时可调查
• 银保监会《人身保险核保指引》：
  • 函件内容不得诱导、恐吓客户
  • 超时未回不得默认承保
  • 客户补充材料后，应在5个工作日内完成复核
• 个人信息保护：
  • 体检报告、病历等属于敏感个人信息，需加密存储
  • 第三方调查机构需签订数据处理协议（DPA）

---

八、附录：核保术语中英对照速查表

中文	英文	说明
核保	Underwriting	UW
核保函	Underwriting Letter / Request	UW Letter
体检函	Medical Examination Request	MedEx Letter
健康函	Health Inquiry Letter	HI Letter
契调函	Investigation Request	Inv Letter
财务函	Financial Verification Letter	FinVer Letter
下发	Issue	函件发出
回销	Response / Return	客户返回材料
超时	Expired / Overdue	未在期限内回销
核保结论	Underwriting Decision	UW Decision
自动核保	Automated Underwriting	Auto UW
人工核保	Manual Underwriting	Manual UW

---

九、结语

在核保模块开发中，函件是风险控制的“眼睛”。你设计的每一个状态、每一条超时规则、每一次材料校验，都在守护公司的承保质量与合规底线。

请始终牢记：

• 函件不是流程负担，而是风险屏障
• 代码中的“dueDate”背后，是监管的“5个工作日”要求
• 一个未加密的体检报告，可能引发 GDPR 罚单

建议你：

1. 与核保业务专家结对，走查一个完整函件流程
2. 在代码注释中明确标注监管依据（如“依据银保监办发〔2021〕XX号文”）
3. 将本手册作为团队核保模块开发规范附件