Nachdem Teil 1 die Grundlagen von Solvency II und die Mechanismen der indirekten Betroffenheit für Manager Alternativer Investments (AIFMs) dargelegt hat, konzentriert sich dieser Teil auf die konkreten Anforderungen an Daten und die daraus resultierenden Reporting-Prozesse. Im Mittelpunkt stehen das Tripartite Template (TPT), die Erwartungen an Datenqualität und die notwendigen Schritte zur Datenbereitstellung durch den AIFM.

Disclaimer:

Dieser Artikel dient ausschließlich Informationszwecken und stellt keine Rechts-, Steuer- oder Finanzberatung dar. Die Informationen sollten vor Entscheidungen individuell geprüft werden.

1. Das Tripartite Template (TPT) – Standardisierungsversuch im Datenaustausch

Um den umfangreichen Datenbedarf der Versicherer für ihre Solvency-II-Meldungen zu decken und den Austausch zu vereinfachen, wurde das Tripartite Template (TPT) als standardisiertes Datenformat entwickelt. Es soll den Informationsfluss zwischen AIFM, Fondsadministrator und Versicherer strukturieren.

• Zweck: Bereitstellung einheitlicher, maschinenlesbarer Daten auf Ebene der Einzelpositionen des Fonds, insbesondere für die SCR-Berechnung.
• Kerninhalte: Das TPT umfasst eine Vielzahl von Datenfeldern, darunter Instrumentenstammdaten, Bewertungsdaten, Risikokennzahlen und spezifische Solvency-II-Klassifizierungen (z.B. CIC-Codes, Risikokategorien, Look-through-Level).
• Herausforderung Illiquide Assets: Die korrekte und vollständige Befüllung aller relevanten TPT-Felder ist insbesondere für illiquide Private Markets Assets komplex, da Standard-Identifikatoren oft fehlen und Daten auf Ebene der Portfolio-Unternehmen erhoben und klassifiziert werden müssen.

2. Konkrete Datenanforderungen an AIFMs

Versicherer benötigen für ihre Solvency-II-Prozesse typischerweise folgende Informationen vom AIFM, oft in der Struktur des TPT oder einem äquivalenten Format:

• Valuation-Details: Aktueller NAV, Fair Value Bewertungen der Einzelpositionen, Cashflow-Historie, Unfunded Commitments.
• Look-through-Daten: Detaillierte Informationen über die zugrundeliegenden Assets des Fonds (Sektor, Region, Währung, Bewertungsmethodik etc.).
• Solvency-II-Klassifikation: Unterstützung bei der Zuordnung der Investments zu den relevanten Solvency-II-Anlageklassen gemäß den Vorgaben des Versicherers.
• Risikodaten: Informationen zum Risikoprofil, ggf. Ergebnisse interner Modelle oder Stresstests.

Herausforderung Datenformat: Unstrukturierte Formate wie PDF-Berichte sind für die automatisierte Weiterverarbeitung durch Versicherer meist ungeeignet. Der Trend geht klar zu strukturierten, maschinenlesbaren Datenlieferungen.

3. Datenqualität als entscheidender Faktor

Die Qualität der vom AIFM gelieferten Daten ist für den Versicherer kritisch, da Fehler zu falschen SCR-Berechnungen und potenziellen aufsichtsrechtlichen Problemen führen können. Daher wird verstärkt auf folgende Kriterien geachtet:

Kriterium	Anforderung an AIFM-Datenlieferung
Granularität	Lieferung auf der erforderlichen Detailebene (oft Einzelposition).
Vollständigkeit	Befüllung aller benötigten Felder, inkl. spezifischer Codes/Klassifizierungen.
Aktualität	Einhaltung der (oft engen) Lieferfristen.
Konsistenz	Abstimmbarkeit zwischen Positionsdaten und aggregierten Fondswerten.

4. Notwendige IT-Prozesse zur Datenbereitstellung beim AIFM

Um die geforderten Daten in der benötigten Qualität und Struktur zu liefern, müssen AIFMs entsprechende IT-gestützte Prozesse etablieren:

1. Datenaggregation & -sammlung: Systematisches Sammeln relevanter Daten aus verschiedenen internen Quellen (IBOR/PMS, ABOR/Buchhaltung) und Anreicherung mit externen oder manuell gepflegten Informationen (Ratings, Klassifizierungen, ESG-Daten). Bei Dachfonds: Einholung und Verarbeitung von Look-through-Daten der Zielfonds.
2. Datenvalidierung & -qualitätssicherung: Implementierung automatisierter und ggf. manueller Prüfroutinen zur Sicherstellung von Vollständigkeit, Plausibilität und Konsistenz der Daten vor der Auslieferung.
3. Daten-Mapping & Konvertierung: Abbildung interner Datenstrukturen auf die Zieldatenstruktur (z.B. TPT-Layout) und Konvertierung in das geforderte technische Format (CSV, XML etc.).
4. Datenbereitstellung & Lieferung: Sicherer und nachvollziehbarer Transfer der aufbereiteten Daten an den Empfänger (Versicherer oder dessen Dienstleister).
5. Archivierung & Audit Trail: Revisionssichere Speicherung der gelieferten Datenpakete und der zugrundeliegenden Rohdaten sowie Protokollierung der Prozessschritte.

Diese Prozesse erfordern oft eine enge Zusammenarbeit zwischen Operations, IT, Risikomanagement und ggf. externen Dienstleistern wie Fondsadministratoren.

Im nächsten Teil werden die notwendigen Anpassungen in der Organisation, den Verträgen und der IT-Architektur diskutiert, um diese Datenlieferprozesse nachhaltig zu unterstützen.