3. 精算模型审计的法规与标准

精算模型的审计轨迹并非单纯的技术日志，而是监管合规的证据链。不同监管体系对“可追溯”的定义、颗粒度与保存期限差异显著。理解这些差异，是设计模型审计架构的前提。本节将四大主流框架对审计轨迹的要求拆解为可落地的合规要点。

核心原理：四套框架的监管逻辑差异

四套框架虽都要求可追溯，但出发点不同。偿二代（C-ROSS）以风险为导向，强调模型与监管报表的一致性，要求精算模型的关键假设、参数调整、版本变更可回溯至责任人；IFRS 17聚焦保险合同负债计量，要求履约现金流、合同服务边际（CSM）的每一步计算可复现，且假设变更的影响可单独识别；SOX源于财务报告内控，关注模型输出进入财报的完整性与准确性，强调职责分离与变更审批；Solvency II则通过三支柱体系，要求模型治理、验证与文档化达到“可被独立第三方复现”的程度。

方法流程：审计轨迹的合规设计四步法

1. 识别监管映射：将模型中的每个计算节点映射到对应监管条款。例如，偿二代下的“最低资本”计算节点需关联《保险公司偿付能力监管规则》相关条文；IFRS 17下的“CSM滚动”需关联准则第38-52段。
2. 定义轨迹颗粒度：根据监管要求确定记录层级。SOX要求关键控制点记录审批人与时间戳；Solvency II要求记录模型假设的完整推导过程；IFRS 17要求记录假设变更对CSM的单独影响。
3. 建立版本与变更控制：每次模型变更需记录变更原因、影响范围、审批记录与回滚方案。变更日志应包含变更前后参数对比。
4. 设计可复现证据包：将输入数据、参数、代码版本、运行环境、输出结果打包，确保独立第三方可在相同环境下复现结果。

# 审计轨迹元数据示例（YAML格式）
model_run:
  run_id: "ACT-2024-00123"
  regulation_mapping:
    - framework: "C-ROSS II"
      clause: "第12号：保险风险最低资本"
      node: "life_mortality_risk"
    - framework: "IFRS 17"
      clause: "第38段：CSM滚动"
      node: "csm_rollforward"
  change_log:
    - timestamp: "2024-03-15T10:23:00Z"
      user: "actuary_zhang"
      change: "死亡率假设从0.08%调整为0.075%"
      reason: "2023年经验数据更新"
      approval: "chief_actuary_li"
  reproducibility:
    code_version: "git:abc123f"
    environment: "python:3.11, numpy:1.26"
    input_hash: "sha256:9f2a..."

可视化：四框架审计轨迹要求对比

案例场景：IFRS 17下CSM滚动的审计轨迹设计

某寿险公司在IFRS 17过渡期，需向审计师证明CSM滚动的每一步计算。审计轨迹设计如下：

误区与复盘：常见合规陷阱

• 误区一：日志即审计轨迹。系统日志只记录“发生了什么”，审计轨迹还需记录“为什么发生”和“谁批准的”。缺少变更原因与审批链的日志，在SOX审计中不被认可。
• 误区二：一套轨迹满足所有框架。偿二代要求关联监管报表科目，IFRS 17要求关联准则段落，Solvency II要求关联验证报告。需建立多维度映射，而非单一标签。
• 误区三：忽略环境可复现性。Solvency II明确要求独立第三方可在相同环境下复现结果。仅保存代码和输入数据不够，还需记录依赖库版本、随机种子、硬件配置。
• 误区四：变更记录不完整。常见缺失：变更影响未量化、回滚方案未记录、审批人未签字。复盘时应检查变更日志是否包含“变更前值、变更后值、影响金额、审批人、审批时间”五要素。