Solvency II 软件：第二支柱选型指南

搜索 Solvency II 软件，您会看到三类完全不同的产品都用同一套说法包装自己。一个供应商销售精算资本引擎。另一个销售可为监管机构生成 XBRL 报送文件的报告工具。第三个销售治理与合规平台，用于让您的董事会、策略和关键职能保持有序。这三类产品都可以合理地自称为 Solvency II 软件。但它们彼此并不能替代。如果买错类别，您要么为永远用不到的能力支付过高成本，要么会在监管审查前三周才发现缺口。

本指南面向治理侧真正拥有采购决策权的人：CRO、风险负责人、合规负责人，或 EU 保险公司、再保险公司的关键职能持有人。本文用直白语言解释这些类别，说明在治理层具体应关注什么，并展示如果您已经在运行 DORA、NIS2 或 ISO 27001，合适的工具如何减少重复工作。本文会刻意如实限定范围，因为在监管方那里丧失可信度的最快方式，就是声称某个工具能做它实际上做不到的事。

Solvency II 实际要求的三大支柱

Solvency II 是 EU 面向保险公司和再保险公司的审慎监管制度，基于 Directive 2009/138/EC 和 Delegated Regulation (EU) 2015/35，并叠加了详细的 EIOPA 指引。它分为三大支柱，您所处的支柱决定了您需要哪类软件。如果您刚接触这一制度，请先阅读我们的指南：什么是 Solvency II，以及三大支柱如何相互配合。

• Pillar 1 - 定量要求。 资本测算：Solvency Capital Requirement (SCR)、Minimum Capital Requirement (MCR)、技术准备金，以及生成这些数字的标准公式或内部模型。这是精算和资本建模软件的领域。
• Pillar 2 - 治理体系。 Directive 第 40 至 49 条规定的定性要求：董事会（AMSB）责任、书面策略、风险管理体系、作为流程的 ORSA、四项关键职能、适格性与诚信、薪酬，以及外包。这是治理和 GRC 软件的领域。
• Pillar 3 - 报告与披露。 Quantitative Reporting Templates (QRTs)、Solvency II XBRL 报送文件、SFCR 和 RSR 叙述性报告。这是监管报告软件的领域。

市场上大多数混淆，来自买方输入“Solvency II 软件”时期待一种产品，却发现来自三大支柱的供应商都在争夺同一次点击。本指南后续聚焦 Pillar 2，因为治理买方的需求就在这里，也因为这是最常缺少工具支撑的支柱。机构在资本引擎和 QRT 工具上投入大量预算，却用一个塞满 Word 文档的共享盘和一张关键职能持有人电子表格来运行整个治理体系。

这种不平衡在一定程度上是理性的。Pillar 1 和 Pillar 3 有明确产出和硬性报送日期，因此每年都更容易赢得预算讨论。Pillar 2 没有报送日期，这恰恰是它容易漂移的原因，也解释了为什么Pillar 2 的实际成本很少被作为经常性项目纳入预算。账单会在之后以治理审计发现的形式到来，而治理审计发现关闭起来缓慢且昂贵，因为它们关乎行为，而不是一个可以在周末重新计算的数字。

Solvency II 软件的三类产品

1. 精算和资本建模（Pillar 1）

这些平台用于计算 SCR 和 MCR、评估技术准备金、运行标准公式或完整/部分内部模型，并对资产负债表进行压力测试。它们是这一制度的数学核心。如果您需要产出资本数字，就需要这类工具，而且没有任何治理工具可以替代它。买方评估此类产品时，会关注模型准确性、计算性能、情景灵活性，以及计算本身的审计追踪。

2. QRT 和 XBRL 监管报告（Pillar 3）

这些平台会接收来自精算引擎和账簿的数据，将其格式化为 QRT，根据 EIOPA 的分类标准进行校验，并生成提交给本国监管机构的 XBRL 实例文档。它们也处理 SFCR 和 RSR 的叙述性报告。买方评估此类产品时，会关注分类标准覆盖范围、校验规则完整性、报送工作流，以及供应商交付每次 EIOPA 新分类标准版本的速度。

3. 治理和 GRC（Pillar 2）

这一层管理的是治理体系：控制措施、书面策略、董事会和委员会监督、作为受治理流程的 ORSA、四项关键职能、适任性评估、薪酬治理，以及外包登记册。这正是 Venvera 这类 Solvency II 治理软件发挥作用的地方。它不计算您的 SCR，也不提交您的 QRT。它通过证明运行这些工具的组织受到适当治理、控制和记录，来补充您的精算引擎和 XBRL 报告工具。

明确这一边界很重要。一个声称能够生成资本数字或提交 XBRL 申报的治理平台是在误导市场，监管机构也会很快发现。诚实的立场是，这三类产品相互补充。您很可能会分别拥有每个支柱下的一款产品。

第 2 支柱内部：治理软件必须覆盖的内容

治理体系是一套持续性义务，监管机构可以在任何时候进行检验。优秀的 Solvency II 软件会把每一项义务转化为结构化、有负责人、有证据、可审查的事项，而不是一份 11 个月前最后更新过的文档。核心领域直接映射到该指令。有关逐条条文的说明，请参阅我们的 Solvency II 第 2 支柱要求指南。

要求	法律依据	软件管理的内容
董事会（AMSB）责任	Art 40	最终问责、监督记录、签署批准
适任性	Art 42	关键人员评估与重新评估
风险管理体系	Art 44	风险战略、风险偏好、策略集、审查节奏
ORSA（作为流程）	Art 45	董事会工作流、文档、策略、签署审计追踪
内部控制与合规职能	Art 46	控制措施库、合规监测计划
内部审计职能	Art 47	独立性、审计计划、审计发现跟踪
精算职能	Art 48	职能治理、意见、向董事会报告
外包	Art 49	登记册、关键性、ICT 外包与 DORA 的重叠

Venvera 的 Solvency II 模块使用 45 项控制措施覆盖这一第 2 支柱范围，并将其映射到这些条款、授权法规以及 EIOPA《治理体系指南》。统计控制措施的意义在于，每项义务都有归属、有负责人、有一项证据、有审查日期，而不是存在某个人的记忆里。

要务实地区分其中哪些只是文书工作，哪些不是。适任性属于行政性工作：收集评估，设定重新评估日期，如果 HR 配合，两周内即可完成。外包更重，因为您的登记册质量取决于您对服务提供商分包情况的可见性，而这种可见性需要通过谈判取得，而不是简单查询。真正困难的是证明董事会提出过质询。记录某项决策的会议纪要很容易。记录董事会提出反对意见，且高管因此作出调整的会议纪要，才是监管机构要看的内容，而您无法事后补做。

ORSA 是您运行并记录的流程

自有风险与偿付能力评估（Article 45）是人们选购 Solvency II 软件时最容易误解的一项。ORSA 有一个定量输出，即对总体偿付能力需求的前瞻性评估，而这个数字来自您的精算和资本建模。治理软件不会生成它，任何声称可以生成的工具都越界了。监管机构实际审查的内容，详见我们的 ORSA 审查预期内容指南。

治理软件真正负责的是 ORSA 作为一项流程。这意味着 ORSA 策略、年度和临时触发工作流、谁负责什么的分派、证明董事会确实质询并批准该评估的证据、ORSA 报告的版本历史，以及显示该流程按照策略要求运行的审计追踪。监管机构并不只想看到 ORSA 的数字结果。它们想要证明 ORSA 已嵌入决策，并且真正由董事会负责。该证明是一项治理产物，也正是治理层所捕获的内容。

第 45 条就其目标而言起草得很好，同时也是最常被规避的要求。由风险职能在董事会会议前两周撰写一份 ORSA 报告，提交、记录并归档，从字面上看可以满足要求。但这并未实现其目的，有经验的监管人员很快就能看出差别。如果您希望 ORSA 经得起检验，真正的工作发生在报告形成之前的数月：触发机制必须实际生效，决策也必须清晰地使用了输出结果。

因此，清晰的职责划分是：您的资本引擎计算偿付能力需求，而您的治理平台证明围绕该计算的流程得到了妥善运行、记录、质询和签署批准。两者都需要。谁也不能替代谁。

框架映射：停止为同一项治理重复提供证据

以下洞察会改变大多数 EU 保险公司对 Pillar 2 的成本认知。如果您是一家中型或更大型保险公司，几乎可以肯定已经受到其他具有较重治理要求的 EU 制度约束。欧盟《数字运营韧性法案》（DORA）自 2025 年 1 月起已适用于金融实体。许多保险公司持有 ISO 27001。不少还落入 NIS2 范围。这些制度都要求与 Solvency II Pillar 2 高度重叠的治理控制措施：组织结构、职责分离、记录管理、ICT 和第三方外包监督、事件治理以及董事会问责。

如果没有框架映射，您会按每个框架分别为这些事项提供证据，在不同工具或文件夹中，以不同节奏进行审核。这会造成重复工作、重复的审核疲劳，以及当一个副本已更新而其他副本未更新时出现偏差的重复风险。框架映射方法会将单一证据映射到其满足的每一个框架。您只需为 DORA 证明一次 ICT 外包治理，重叠的 Solvency II 第 49 条治理控制措施就会由同一证据自动满足。一次取证，处处合规。

在启用其中任何内容之前，请先与您的内部审计职能确认。复用是一种合理的节省，但对未参与映射达成过程的人来说，它看起来与走捷径没有区别。请写明为什么每一项复用的控制措施确实是同一项义务在两个制度下的体现，并将该理由保存在评估人员能够找到的位置。这个沟通只需一个下午，却能让您日后避免一次耗时得多的沟通。

让这种做法保持诚实、而不是沦为合规捷径的纪律在于明确哪些内容绝不能自动满足。重叠的治理控制措施，例如组织结构、职责分离、记录以及 ICT 外包类控制措施，可以合理复用，因为它们确实是同一项控制措施在两个制度下的呈现。但保险特定的控制措施是原生要求，必须直接提供证据：ORSA、包括精算职能在内的四项关键职能，以及适当性与胜任能力。没有任何 DORA 或 ISO 证据可以满足“精算职能已就技术准备金发表意见”。假装可以满足会造成虚假的覆盖范围，而虚假的覆盖范围比没有覆盖范围更糟，因为它会掩盖差距。Venvera 的 Solvency II Pillar 2 模块会明确划定这条界线。

四项关键职能

Solvency II 要求设立四项关键职能，Pillar 2 软件必须将每一项作为独立、人员配置适当、报告机制适当的职能进行跟踪，而不是仅作为组织架构图中的一个名称。

• 风险管理职能（Art 44）。负责风险管理系统、风险偏好框架，以及将风险纳入决策过程。
• 合规职能（Art 46）。就合规事项向董事会提供建议，评估法律变化的影响，并运行合规监测计划。
• 内部审计职能（Art 47）。对整个治理体系提供独立保证，包括其他职能。独立性正是会被测试的控制措施。
• 精算职能（Art 48）。协调技术准备金，就承保策略和再保险充分性发表意见，并向董事会报告。这一职能具有保险行业特性，原生属于治理层，绝不能从其他框架自动满足。

这里的软件任务，是针对每项职能保存其任职人及其适任性状态、证明独立性的汇报线、该职能的活动和产出，以及其按期向董事会报告的证据。当监管机构要求“给我看你们的精算职能在上一个周期向董事会报告过”时，答案应当只需点击两下即可取得。

购买治理软件时应关注什么

一旦您确认自己采购的是 Pillar 2 类别的软件，就可以用这份清单区分严肃的平台和只是贴上 Solvency II 标签的通用 GRC 工具。在演示中最快的测试，是要求供应商把精算职能作为一等对象展示在屏幕上，包括其任职人、汇报线以及最近一次向董事会提交的意见。如果显示出来的只是通用任务上的一个自定义字段，那么您看到的就是一个在营销中使用保险措辞的通用 GRC 产品。

原生 Solvency II 控制措施映射

控制措施应映射到 Directive 2009/138/EC、Delegated Regulation (EU) 2015/35 和 EIOPA guidelines 的具体条款，而不是映射到含糊的“保险”模板。如果供应商无法向您展示条款级映射，那么内容就是通用的。

真正的跨框架映射

询问该工具如何处理与欧盟 NIS2 指令、ISO 27001 和欧盟《数字运营韧性法案》（DORA）的重叠。真正的框架映射会复用共享的治理证据，并明确拒绝自动满足保险特定的控制措施。如果所有内容都被称为“自动满足”，请离开，那是虚假的覆盖范围。

开箱即用的 ORSA 和关键职能工作流

ORSA 流程、适任性评估以及四项关键职能应当是一等功能，而不是由您用通用任务拼装出来的东西。这正是保险原生软件与换标通用 GRC 平台的区别。

董事会和委员会证据，并带有审计追踪

签署、审核日期、版本历史，以及证明监督确实发生的不可篡改证据。监管机构测试的是嵌入程度，而不是意图。

EU 数据驻留和诚实的范围说明

您的治理数据应留在 EU 境内。同时，供应商应当清楚说明产品不做什么，即它是补充而不是替代您的精算引擎和 QRT 报告工具。对范围过度承诺的供应商，会让您在监管机构面前损害可信度。

构建您的 Solvency II 软件栈

对大多数保险公司而言，答案是边界清晰的软件栈。一个典型且诚实的架构如下：

• 精算和资本引擎（Pillar 1）生成 SCR、MCR 和技术准备金。
• QRT 和 XBRL 报告工具（Pillar 3）校验并提交报表，并生成 SFCR 和 RSR。
• 治理和 GRC 平台（Pillar 2）管理治理体系、ORSA 流程、关键职能、适任性以及外包，并通过框架映射复用来自 DORA 和 ISO 的重叠治理证据。

各层相互供给。资本引擎为 ORSA 流程提供数字。治理层证明围绕资本工作和报告工作的流程均得到了妥善运行。报告工具提交输出。没有人假装在做相邻支柱的工作，而这种诚实才能经得起监管审查。

如果您已经承担 NIS2、DORA 或 ISO 27001 义务，治理层就是最大效率提升所在。您已经为这些制度提供证据的重叠控制措施可以横向复用，因此建立 Pillar 2 的增量工作会集中在真正具有保险特性的部分：ORSA 流程、四项关键职能以及适任性。这就是一个耗时数月的 Solvency II 治理方案，与一个能够复用现有成果的方案之间的差别。

结论

Solvency II 软件其实是三个市场共用一个名称。您需要清楚自己在为哪一个支柱采购。如果您已经拥有精算引擎和 QRT 工具，缺口几乎总是在 Pillar 2，也就是治理体系，而这个缺口通常由共享网盘和电子表格填补，但它们经不起监管审查。专为治理而构建的平台可以弥补这一缺口，而真正的跨框架框架映射可以在不要求您把同一套治理证据重复提交三次的情况下完成这件事。请务必确认供应商对边界足够坦诚：它是对您的资本和报告工具的补充，而不是替代。

主要来源

上述支柱结构和治理义务可追溯至以下主要来源。条款编号均指 Directive 2009/138/EC。

• Solvency II Directive 2009/138/EC - 治理体系对应第 40 至 49 条：Art 40（AMSB 责任）、Art 41（一般治理要求）、Art 42（适格性与适当性）、Art 44（风险管理）、Art 45（ORSA）、Art 46（内部控制与合规）、Art 47（内部审计）、Art 48（精算职能）、Art 49（外包）。Art 45(1)：“As part of its risk-management system every insurance undertaking and reinsurance undertaking shall conduct its own risk and solvency assessment.” EUR-Lex。
• Commission Delegated Regulation (EU) 2015/35 - 关于治理体系和四项关键职能的详细实施规则。EUR-Lex。
• EIOPA Guidelines on the System of Governance（EIOPA-BoS-14/253）。eiopa.europa.eu。
• DORA - Regulation (EU) 2022/2554 - ICT 与第三方治理的重叠部分；自 2025 年 1 月 17 日起已适用于金融实体（Art 64）。EUR-Lex。

范围说明。Venvera 的 Solvency II 模块覆盖 Pillar 2（治理体系），包含映射至第 40 至 49 条、Delegated Regulation 和 EIOPA Guidelines 的 45 项控制措施。它不覆盖 Pillar 1 资本充足性（SCR/MCR）或 Pillar 3 定量报告（QRTs）；ORSA 作为治理流程受到支持，而不是作为资本计算来支持。该边界在产品内以范围横幅显示。