Solvency II Software: Einkaufsleitfaden für Säule 2

Suchen Sie nach Solvency II Software, erhalten Sie drei völlig verschiedene Produktarten, die dieselben Worte tragen. Ein Anbieter verkauft eine aktuarielle Kapital-Engine. Ein zweiter verkauft ein Meldewerkzeug, das XBRL-Meldungen für die Aufsicht ausgibt. Ein dritter verkauft eine Governance- und Compliance-Plattform, die Ihren Vorstand, Ihre schriftlichen Leitlinien und Ihre Schlüsselfunktionen in Ordnung hält. Alle drei nennen sich zu Recht Solvency II Software. Keiner von ihnen erledigt die Aufgaben der beiden anderen. Kaufen Sie die falsche Kategorie, zahlen Sie entweder zu viel für Funktionen, die Sie nie nutzen werden, oder Sie entdecken drei Wochen vor einer aufsichtlichen Prüfung eine Lücke.

Dieser Leitfaden richtet sich an die Person, bei der die Kaufentscheidung auf der Governance-Seite tatsächlich liegt: den CRO, die Leitung Risiko, die Leitung Compliance oder eine Inhaberin beziehungsweise einen Inhaber einer Schlüsselfunktion bei einem EU-Versicherer oder Rückversicherer. Er erklärt die Kategorien in klarer Sprache, benennt, worauf es speziell in der Governance-Schicht ankommt, und zeigt, wie das richtige Werkzeug Doppelarbeit beseitigt, wenn Sie bereits DORA, NIS2 oder ISO 27001 betreiben. Er ist bewusst ehrlich zum Leistungsumfang, denn der schnellste Weg, Glaubwürdigkeit bei einer Aufsichtsbehörde zu verlieren, ist die Behauptung, ein Werkzeug leiste etwas, das es nicht leistet.

Was Solvency II tatsächlich verlangt, in drei Säulen

Solvency II ist das aufsichtsrechtliche Regime der EU für Versicherer und Rückversicherer, aufgebaut auf der Richtlinie 2009/138/EG und der Delegierten Verordnung (EU) 2015/35, ergänzt um detaillierte EIOPA-Leitlinien. Es ist in drei Säulen gegliedert, und die Säule, in der Sie sich bewegen, entscheidet darüber, welche Software Sie brauchen.

• Säule 1 - quantitative Anforderungen. Die Kapitalmathematik: die Solvenzkapitalanforderung (SCR), die Mindestkapitalanforderung (MCR), versicherungstechnische Rückstellungen sowie die Standardformel oder das interne Modell, das diese Zahlen erzeugt. Das ist die Domäne aktuarieller Software und von Kapitalmodellierung.
• Säule 2 - Governance-System. Die qualitativen Anforderungen der Artikel 40 bis 49 der Richtlinie: Verantwortung des Verwaltungs-, Management- oder Aufsichtsorgans (AMSB), schriftliche Leitlinien, das Risikomanagementsystem, die ORSA als Prozess, die vier Schlüsselfunktionen, fachliche Eignung und Zuverlässigkeit, Vergütung und Ausgliederung. Das ist die Domäne von Governance- und GRC-Software.
• Säule 3 - Berichterstattung und Offenlegung. Die quantitativen Meldebögen (QRT), die Solvency-II-XBRL-Meldungen, die Berichte SFCR und RSR. Das ist die Domäne aufsichtsrechtlicher Meldesoftware.

Der Großteil der Verwirrung im Markt entsteht bei Käufern, die "Solvency II Software" eintippen, ein Produkt erwarten und Anbieter aus allen drei Säulen um denselben Klick konkurrieren sehen. Der Rest dieses Leitfadens konzentriert sich auf Säule 2, denn dort lebt der Governance-Käufer und dort ist die Werkzeugausstattung am häufigsten dünn. Unternehmen investieren kräftig in die Kapital-Engine und das QRT-Werkzeug und betreiben dann das gesamte Governance-System auf einem geteilten Laufwerk voller Word-Dokumente plus einer Tabelle mit Inhabern von Schlüsselfunktionen.

Bis zu einem gewissen Punkt ist dieses Ungleichgewicht rational. Säule 1 und Säule 3 haben harte Ergebnisse und harte Einreichungstermine, deshalb gewinnen sie jedes Jahr den Budgetstreit. Säule 2 hat keinen Einreichungstermin, und genau deshalb driftet sie ab. Die Rechnung kommt später als Governance-Feststellung, und Governance-Feststellungen sind langsam und teuer zu schließen, weil es um Verhalten geht statt um eine Zahl, die sich an einem Wochenende neu rechnen lässt.

Die drei Kategorien von Solvency II Software

1. Aktuarielle Rechnung und Kapitalmodellierung (Säule 1)

Diese Plattformen berechnen SCR und MCR, bewerten versicherungstechnische Rückstellungen, führen die Standardformel oder ein volles beziehungsweise partielles internes Modell aus und unterziehen die Bilanz Stresstests. Sie sind das mathematische Herz des Regimes. Wenn Sie die Kapitalzahl erzeugen müssen, brauchen Sie eine davon, und kein Governance-Werkzeug ersetzt sie. Käufer bewerten diese Produkte nach Modellgenauigkeit, Rechenleistung, Szenarioflexibilität und Nachvollziehbarkeit der Berechnung selbst.

2. QRT- und XBRL-Meldewesen (Säule 3)

Diese Plattformen nehmen die Zahlen aus Ihrer aktuariellen Engine und Ihren Büchern, formatieren sie in die QRT, validieren sie gegen die EIOPA-Taxonomie und erzeugen die XBRL-Instanzdokumente, die Sie bei Ihrer nationalen Aufsicht einreichen. Sie decken auch die narrative Berichterstattung in SFCR und RSR ab. Käufer bewerten diese Produkte nach Taxonomieabdeckung, Vollständigkeit der Validierungsregeln, Einreichungs-Workflow und danach, wie schnell der Anbieter jede neue EIOPA-Taxonomieversion ausliefert.

3. Governance und GRC (Säule 2)

Das ist die Schicht, die das Governance-System steuert: die Kontrollen, die schriftlichen Leitlinien, die Aufsicht durch Vorstand und Ausschüsse, die ORSA als gesteuerter Prozess, die vier Schlüsselfunktionen, Beurteilungen zu fachlicher Eignung und Zuverlässigkeit, die Vergütungs-Governance und Ausgliederungsregister. Hier sitzt Solvency-II-Governance-Software wie Venvera. Die SCR-Berechnung bleibt bei Ihrer aktuariellen Engine, die QRT-Einreichung bei Ihrem Meldewerkzeug. Die Governance-Schicht ergänzt beide, indem sie belegt, dass die Organisation, die diese Werkzeuge betreibt, ordentlich gesteuert, kontrolliert und dokumentiert ist.

Diese Grenze offen zu benennen, ist wichtig. Eine Governance-Plattform, die behauptete, Kapitalzahlen zu erzeugen oder XBRL-Meldungen einzureichen, würde sich falsch darstellen, und eine Aufsichtsbehörde würde das schnell bemerken. Die ehrliche Position lautet: Die drei Kategorien ergänzen einander. Sehr wahrscheinlich werden Sie je ein Produkt aus jeder Säule besitzen.

Innerhalb von Säule 2: was Governance-Software abdecken muss

Das Governance-System ist ein dauerhaft geltendes Pflichtenbündel, das eine Aufsichtsbehörde jederzeit prüfen kann. Gute Solvency II Software verwandelt jede dieser Pflichten in etwas Strukturiertes, mit Eigentümer, Nachweis und Prüftermin, statt in ein Dokument, das zuletzt vor elf Monaten angefasst wurde. Die Kernbereiche bilden die Richtlinie direkt ab.

Anforderung	Rechtsgrundlage	Was die Software steuert
Verantwortung des Vorstands (AMSB)	Art. 40	Letztverantwortung, Aufsichtsnachweise, Freigaben
Fachliche Eignung und Zuverlässigkeit	Art. 42	Beurteilungen und Neubeurteilungen von Schlüsselpersonen
Risikomanagementsystem	Art. 44	Risikostrategie, Risikoappetit, Leitlinienwerk, Prüfrhythmus
ORSA (als Prozess)	Art. 45	Vorstands-Workflow, Dokumentation, Leitlinie, Freigabespur
Internes Kontrollsystem und Compliance-Funktion	Art. 46	Kontrollbibliothek, Compliance-Überwachungsplan
Interne Revision	Art. 47	Unabhängigkeit, Prüfungsplan, Verfolgung von Feststellungen
Versicherungsmathematische Funktion	Art. 48	Governance der Funktion, Stellungnahmen, Bericht an den Vorstand
Ausgliederung	Art. 49	Register, Kritikalität, Überschneidung der IKT-Auslagerung mit DORA

Das Solvency-II-Modul von Venvera deckt diese Säule-2-Fläche mit 45 Kontrollen ab, die auf diese Artikel, die Delegierte Verordnung und die EIOPA-Leitlinien zum Governance-System abgebildet sind. Der Sinn des Zählens von Kontrollen liegt darin, dass jede Pflicht einen Ort, einen Eigentümer, einen Nachweis und ein Prüfdatum hat, statt im Gedächtnis einzelner Personen zu leben.

Bleiben Sie realistisch dabei, was davon Papierarbeit ist und was nicht. Fachliche Eignung und Zuverlässigkeit ist administrativ: Beurteilungen einsammeln, ein Datum für die Neubeurteilung setzen, und bei kooperativer Personalabteilung ist die Sache in zwei Wochen erledigt. Ausgliederung wiegt schwerer, denn Ihr Register ist nur so gut wie Ihr Einblick in das, was Ihre Dienstleister weitervergeben, und dieser Einblick muss verhandelt werden statt einfach nachgeschlagen. Wirklich schwierig ist der Nachweis kritischer Auseinandersetzung im Vorstand. Protokolle, die eine Entscheidung festhalten, sind leicht. Protokolle, die festhalten, wie der Vorstand nachgehakt und eine Führungskraft daraufhin etwas geändert hat, sind das, wonach Aufsichtsbehörden suchen, und die lassen sich nachträglich nicht herstellen.

Die ORSA ist ein Prozess, den Sie durchführen und dokumentieren

Die unternehmenseigene Risiko- und Solvabilitätsbeurteilung (Artikel 45) ist der am häufigsten missverstandene Punkt, wenn Menschen Solvency II Software einkaufen. Die ORSA hat ein quantitatives Ergebnis, die vorausschauende Beurteilung des Gesamtsolvabilitätsbedarfs, und diese Zahl stammt aus Ihrer aktuariellen Rechnung und Kapitalmodellierung. Governance-Software erzeugt sie nicht, und jedes Werkzeug, das dies behauptet, greift zu weit.

Was Governance-Software sehr wohl besitzt, ist die ORSA als Prozess. Das umfasst die ORSA-Leitlinie, den Workflow für den jährlichen und den anlassbezogenen Auslöser, die Zuweisung, wer was tut, den Nachweis, dass der Vorstand die Beurteilung tatsächlich hinterfragt und genehmigt hat, die Versionshistorie des ORSA-Berichts und die Prüfspur, die zeigt, dass der Prozess so lief, wie es die Leitlinie vorschreibt. Aufsichtsbehörden wollen mehr als die ORSA-Zahl. Sie wollen den Beleg, dass die ORSA in der Entscheidungsfindung verankert ist und vom Vorstand wirklich verantwortet wird. Dieser Beleg ist ein Governance-Artefakt, und genau ihn erfasst die Governance-Schicht.

Artikel 45 ist für seinen Zweck gut formuliert, und er ist zugleich die Anforderung, die am häufigsten umgangen wird. Ein ORSA-Bericht, den die Risikofunktion in den zwei Wochen vor der Vorstandssitzung schreibt, der vorgestellt, zur Kenntnis genommen und abgelegt wird, erfüllt formal den Wortlaut. Den Zweck erfüllt er nicht, und eine erfahrene Aufsicht erkennt den Unterschied schnell. Damit die ORSA trägt, liegt die Arbeit in den Monaten, bevor der Bericht überhaupt existiert: Auslöser, die tatsächlich greifen, und Entscheidungen, die das Ergebnis sichtbar genutzt haben.

Die saubere Arbeitsteilung lautet also: Ihre Kapital-Engine berechnet den Solvabilitätsbedarf, und Ihre Governance-Plattform belegt, dass der Prozess um diese Berechnung herum ordentlich lief, dokumentiert, hinterfragt und freigegeben wurde. Beides wird gebraucht. Jedes bleibt bei seiner Aufgabe.

Der Crosswalk: dieselbe Governance nur einmal nachweisen

Hier liegt die Einsicht, die die Wirtschaftlichkeit von Säule 2 für die meisten EU-Versicherer verändert. Sind Sie ein mittelgroßer oder größerer Versicherer, unterliegen Sie mit hoher Wahrscheinlichkeit bereits weiteren EU-Regimen mit umfangreichen Governance-Anforderungen. Der Digital Operational Resilience Act (DORA) gilt für Finanzunternehmen seit Januar 2025. Viele Versicherer halten ISO 27001. Etliche fallen unter NIS2. Jedes dieser Regime verlangt Governance-Kontrollen, die sich stark mit Solvency II Säule 2 überschneiden: Aufbauorganisation, Funktionstrennung, Aktenführung, Aufsicht über IKT- und Drittdienstleisterauslagerungen, Vorfalls-Governance und Vorstandsverantwortung.

Ohne Crosswalk weisen Sie jede dieser Anforderungen einzeln nach, einmal je Rahmenwerk, in einem anderen Werkzeug oder Ordner, geprüft in einem anderen Rhythmus. Das bedeutet doppelte Arbeit, doppelte Prüfermüdung und ein doppeltes Risiko des Auseinanderdriftens, wenn eine Kopie aktualisiert wird und die anderen nicht. Der Crosswalk-Ansatz bildet einen einzelnen Nachweis auf jedes Rahmenwerk ab, das er erfüllt. Belegen Sie Ihre IKT-Auslagerungs-Governance einmal für DORA, und die überschneidende Solvency-II-Kontrolle zu Artikel 49 wird aus demselben Nachweis automatisch erfüllt. Einmal nachweisen, überall konform.

Klären Sie das mit Ihrer internen Revision, bevor Sie irgendetwas davon aktivieren. Wiederverwendung ist eine berechtigte Ersparnis, und für jeden, der beim Vereinbaren der Zuordnung nicht im Raum saß, sieht sie aus wie eine Abkürzung. Schreiben Sie auf, warum jede wiederverwendete Kontrolle wirklich dieselbe Pflicht ist, betrachtet durch zwei Regime, und halten Sie diese Begründung dort bereit, wo eine prüfende Person sie findet. Das Gespräch kostet einen Nachmittag und erspart Ihnen später ein sehr viel längeres.

Die Disziplin, die daraus eine ehrliche Praxis statt einer Compliance-Abkürzung macht, besteht darin, zu wissen, was niemals automatisch erfüllt werden darf. Überschneidende Governance-Kontrollen der Art Aufbauorganisation, Funktionstrennung, Aktenführung und IKT-Auslagerung dürfen legitim wiederverwendet werden, weil sie tatsächlich dieselbe Kontrolle sind, betrachtet durch zwei Regime. Die versicherungsspezifischen Kontrollen dagegen sind nativ und müssen unmittelbar nachgewiesen werden: die ORSA, die vier Schlüsselfunktionen einschließlich der versicherungsmathematischen Funktion sowie fachliche Eignung und Zuverlässigkeit. Es gibt keinen DORA- oder ISO-Nachweis, der die Aussage "die versicherungsmathematische Funktion hat ihre Stellungnahme zu den versicherungstechnischen Rückstellungen abgegeben" erfüllt. Etwas anderes zu behaupten, würde Scheinabdeckung erzeugen, und Scheinabdeckung ist schlimmer als fehlende Abdeckung, weil sie die Lücke verdeckt. Venveras Solvency-II-Modul für Säule 2 zieht diese Linie ausdrücklich.

Die vier Schlüsselfunktionen

Solvency II schreibt vier Schlüsselfunktionen vor, und Software für Säule 2 muss jede davon als eigenständige, angemessen besetzte und ordentlich berichtende Funktion führen, über einen Namen im Organigramm hinaus.

• Risikomanagementfunktion (Art. 44). Verantwortet das Risikomanagementsystem, das Rahmenwerk für den Risikoappetit und die Einbindung von Risiko in die Entscheidungsfindung.
• Compliance-Funktion (Art. 46). Berät den Vorstand zu Compliance, beurteilt die Auswirkung rechtlicher Änderungen und führt den Compliance-Überwachungsplan aus.
• Interne Revision (Art. 47). Liefert unabhängige Prüfsicherheit über das gesamte Governance-System, einschließlich der übrigen Funktionen. Die Unabhängigkeit ist die Kontrolle, die geprüft wird.
• Versicherungsmathematische Funktion (Art. 48). Koordiniert die versicherungstechnischen Rückstellungen, nimmt Stellung zur Zeichnungspolitik und zur Angemessenheit der Rückversicherung und berichtet an den Vorstand. Diese Funktion ist versicherungsspezifisch und nativ in der Governance-Schicht, sie wird niemals automatisch aus einem anderen Rahmenwerk erfüllt.

Die Aufgabe der Software besteht darin, je Funktion Folgendes vorzuhalten: die Inhaberin oder den Inhaber samt Status zu Eignung und Zuverlässigkeit, die Berichtswege, die die Unabhängigkeit belegen, die Tätigkeiten und Ergebnisse der Funktion sowie den Nachweis, dass sie planmäßig an den Vorstand berichtet hat. Fragt eine Aufsichtsbehörde "zeigen Sie mir, dass Ihre versicherungsmathematische Funktion im letzten Zyklus an den Vorstand berichtet hat", sollte die Antwort zwei Klicks entfernt liegen.

Worauf Sie beim Kauf von Governance-Software achten sollten

Sobald feststeht, dass Sie in der Kategorie Säule 2 einkaufen, nutzen Sie diese Prüfliste, um ernsthafte Plattformen von generischen GRC-Werkzeugen mit aufgeschraubtem Solvency-II-Etikett zu unterscheiden. Der schnellste Test in einer Demo besteht darin, den Anbieter zu bitten, die versicherungsmathematische Funktion als vollwertiges Objekt auf den Bildschirm zu bringen, mit Inhaberin oder Inhaber, Berichtsweg und der letzten Stellungnahme an den Vorstand. Erscheint dabei ein benutzerdefiniertes Feld an einer generischen Aufgabe, sehen Sie ein allgemeines GRC-Produkt mit Versicherungsvokabular im Marketing.

Native Abbildung der Solvency-II-Kontrollen

Kontrollen sollten konkrete Artikel der Richtlinie 2009/138/EG, der Delegierten Verordnung (EU) 2015/35 und der EIOPA-Leitlinien treffen statt einer vagen Vorlage "Versicherung". Kann der Anbieter Ihnen die Zuordnung auf Artikelebene nicht zeigen, sind die Inhalte generisch.

Ein echter rahmenwerkübergreifender Crosswalk

Fragen Sie, wie das Werkzeug die Überschneidung mit NIS2, ISO 27001 und DORA behandelt. Ein echter Crosswalk verwendet gemeinsame Governance-Nachweise wieder und verweigert klar die automatische Erfüllung versicherungsspezifischer Kontrollen. Ist alles "automatisch erfüllt", gehen Sie weiter, denn das ist Scheinabdeckung.

ORSA- und Schlüsselfunktions-Workflows ab Werk

Der ORSA-Prozess, Beurteilungen zu Eignung und Zuverlässigkeit sowie die vier Schlüsselfunktionen sollten als vollwertige Funktionen bereitstehen und sofort nutzbar sein. Das unterscheidet versicherungsnative Software von einer umetikettierten allgemeinen GRC-Plattform.

Nachweise aus Vorstand und Ausschüssen, mit Prüfspur

Freigaben, Prüftermine, Versionshistorie und unveränderliche Nachweise, dass Aufsicht tatsächlich stattgefunden hat. Aufsichtsbehörden prüfen die gelebte Verankerung.

EU-Datenhaltung und ehrlicher Leistungsumfang

Ihre Governance-Daten sollten in der EU bleiben. Und der Anbieter sollte Ihnen klar sagen, wo die Grenze des Produkts verläuft, nämlich dass es Ihre aktuarielle Engine und Ihr QRT-Meldewerkzeug ergänzt und deren Aufgaben bei ihnen belässt. Ein Anbieter, der den Leistungsumfang überzeichnet, kostet Sie Glaubwürdigkeit vor Ihrer Aufsicht.

So bauen Sie Ihren Solvency-II-Software-Stack

Für die meisten Versicherer lautet die Antwort: ein Stack mit sauberen Grenzen. Eine typische, ehrliche Architektur sieht so aus:

• Aktuarielle Rechnung und Kapital-Engine (Säule 1) erzeugt SCR, MCR und versicherungstechnische Rückstellungen.
• QRT- und XBRL-Meldewerkzeug (Säule 3) validiert und reicht die Meldungen ein und erstellt SFCR und RSR.
• Governance- und GRC-Plattform (Säule 2) steuert das Governance-System, den ORSA-Prozess, die Schlüsselfunktionen, Eignung und Zuverlässigkeit sowie Ausgliederung und verwendet überschneidende Governance-Nachweise aus DORA und ISO über den Crosswalk erneut.

Jede Schicht speist die anderen. Die Kapital-Engine liefert dem ORSA-Prozess seine Zahl. Die Governance-Schicht belegt, dass der Prozess rund um die Kapitalarbeit und die Berichterstattung ordentlich lief. Das Meldewerkzeug reicht das Ergebnis ein. Jede Schicht bleibt bei ihrer eigenen Säule, und diese Ehrlichkeit ist es, was einer aufsichtlichen Prüfung standhält.

Tragen Sie bereits Pflichten aus NIS2, DORA oder ISO 27001, verbirgt sich der größte Effizienzgewinn in der Governance-Schicht. Die überschneidenden Kontrollen, die Sie für diese Regime schon nachgewiesen haben, lassen sich übertragen, sodass sich die zusätzliche Arbeit für den Aufbau von Säule 2 auf die wirklich versicherungsspezifischen Teile konzentriert: den ORSA-Prozess, die vier Schlüsselfunktionen sowie Eignung und Zuverlässigkeit. Das ist der Unterschied zwischen einem Solvency-II-Governance-Programm, das Monate dauert, und einem, das nutzt, was Sie bereits haben.

Das Fazit

Solvency II Software sind drei Märkte, die einen Namen tragen. Wissen Sie, für welche Säule Sie einkaufen. Besitzen Sie bereits eine aktuarielle Engine und ein QRT-Werkzeug, liegt die Lücke fast immer bei Säule 2, dem Governance-System, und diese Lücke wird meist mit geteilten Laufwerken und Tabellen gefüllt, die eine aufsichtliche Prüfung nicht überstehen. Eine speziell dafür gebaute Governance-Plattform schließt diese Lücke, und ein echter rahmenwerkübergreifender Crosswalk schließt sie, ohne dass Sie dieselbe Governance dreifach nachweisen müssen. Achten Sie nur darauf, dass der Anbieter die Grenze offen benennt: Die Plattform ergänzt Ihre Kapital- und Meldewerkzeuge und belässt deren Aufgaben bei ihnen.

Primärquellen

Die Säulenstruktur und die oben zitierten Governance-Pflichten lassen sich auf die folgenden Primärquellen zurückführen. Die Artikelnummern beziehen sich auf die Richtlinie 2009/138/EG.

• Solvency-II-Richtlinie 2009/138/EG - das Governance-System steht in den Artikeln 40 bis 49: Art. 40 (Verantwortung des AMSB), Art. 41 (allgemeine Governance-Anforderungen), Art. 42 (fachliche Eignung und Zuverlässigkeit), Art. 44 (Risikomanagement), Art. 45 (ORSA), Art. 46 (internes Kontrollsystem und Compliance), Art. 47 (interne Revision), Art. 48 (versicherungsmathematische Funktion), Art. 49 (Ausgliederung). Art. 45 Abs. 1: "Jedes Versicherungs- und Rückversicherungsunternehmen nimmt im Rahmen seines Risikomanagementsystems eine unternehmenseigene Risiko- und Solvabilitätsbeurteilung vor." EUR-Lex.
• Delegierte Verordnung (EU) 2015/35 der Kommission - die detaillierten Durchführungsbestimmungen zum Governance-System und zu den vier Schlüsselfunktionen. EUR-Lex.
• EIOPA-Leitlinien zum Governance-System (EIOPA-BoS-14/253). eiopa.europa.eu.
• DORA - Verordnung (EU) 2022/2554 - die Überschneidung bei IKT- und Drittdienstleister-Governance; sie gilt für Finanzunternehmen seit dem 17. Januar 2025 (Art. 64). EUR-Lex.

Hinweis zum Leistungsumfang. Das Solvency-II-Modul von Venvera deckt Säule 2 (das Governance-System) mit 45 Kontrollen ab, die auf die Artikel 40 bis 49, die Delegierte Verordnung und die EIOPA-Leitlinien abgebildet sind. Säule 1 (Kapitalausstattung, SCR/MCR) und die quantitative Berichterstattung der Säule 3 (QRT) bleiben außerhalb des Moduls; die ORSA wird als Governance-Prozess unterstützt, die Kapitalberechnung bleibt bei Ihrer aktuariellen Engine. Diese Grenze wird im Produkt als Scope-Banner angezeigt.