Das Look-through-Prinzip hat sich zu einer Kernanforderung für Manager und Investoren im Asset Management entwickelt, insbesondere bei illiquiden Anlageklassen wie Private Equity, Infrastruktur und Immobilien. Regulatorische Rahmenwerke wie Solvency II für Versicherer, Meldepflichten für Pensionskassen (z.B. GroMiKV in Deutschland) und die wachsende Bedeutung von ESG-Reporting (z.B. gemäß ESRS) verlangen zunehmend Transparenz über die einzelnen Vermögenswerte, die sich hinter Fondsinvestments verbergen. Dies geht weit über die bloße Nennung der Fondsposition hinaus. Ein effizientes, revisionssicheres IT-Setup und präzise operative Prozesse sind daher unerlässlich, um diese granularen Datenanforderungen zu erfüllen und gleichzeitig die Kontrolle über Datenqualität und Governance zu gewährleisten.

Disclaimer:

Dieser Artikel dient ausschließlich zu Informationszwecken und stellt keine Rechts-, Steuer- oder Finanzberatung dar. Die hierin enthaltenen Informationen sollten vor einer Entscheidungsfindung unabhängig überprüft werden.

1. Regulatorische Treiber und ihre Datenanforderungen (Kurzüberblick)

Verschiedene regulatorische Vorgaben machen Look-through-Reporting notwendig. Sie unterscheiden sich in ihrer Detailtiefe, Frequenz und dem Fokus der geforderten Daten:

Regelwerk / Standard	Primärer Fokus der Look-through-Anforderung	Beispiel-Daten
Solvency II (für Versicherer)	Risikobasierte Kapitalunterlegung (SCR), detaillierte Risikoklassifizierung der Assets.	Asset-Typ (detailliert), Ländercode, Sektor, Bonitätsrating, Währung auf Einzelpositionsebene (QRT S.06.03).
GroMiKV (für Pensionsfonds etc.)	Transparenz über Großkredite, Beteiligungen, Ratings.	Details zu großen Beteiligungen, Kreditnehmerinformationen, Bonitätsratings auf Einzelpositionsebene.
ESG-Reporting (z.B. SFDR, ESRS, Green Bond Standards)	Nachhaltigkeitsbewertung, Offenlegung von Umwelt- und Sozialauswirkungen.	CO2-Emissionen, Energieverbrauch, Governance-Scores, soziale Kriterien auf Einzelinvestitionsebene.

All diese Anforderungen verlangen eines gemeinsam: Daten, die nicht nur die Fondsposition selbst betreffen, sondern die Vermögenswerte, die sich innerhalb des Fonds befinden – und das mit hoher Granularität (oft bis auf Ebene der Einzelposition) und Aktualität (typischerweise quartalsweise oder häufiger).

2. Datenherkunft und Herausforderungen

Die Daten für das Look-through-Reporting stammen aus vielfältigen Quellen, was die Aggregation komplex macht:

• Interne Systeme: Investment Book of Record (IBOR), Accounting Book of Record (ABOR) – liefern Stammdaten zu den Fondsinvestments, Cashflows, Bewertungen.
• Externe Quellen (Primär):
  • Asset Manager / GPs der Zielfonds: Oft die Hauptquelle für Look-through-Daten, insbesondere bei Dachfonds (Fund-of-Funds). Die Datenqualität, -struktur (oft PDF oder inkonsequente Excels) und Pünktlichkeit dieser Lieferungen variieren erheblich.
  • Verwahrstellen / Custodians: Liefern standardisierte Daten für liquide oder standardisierte illiquide Wertpapiere (ISIN, Bestände, Transaktionen).
• Externe Quellen (Sekundär): Datenanbieter (z.B. Bloomberg, Refinitiv, MSCI, Preqin) liefern ergänzende Daten wie Ratings, Marktdaten, ESG-Scores, Branchenklassifizierungen – oft standardisiert über Feeds.

Die zentrale Herausforderung liegt in der Heterogenität und der variierenden Qualität und Struktur dieser Daten, insbesondere bei indirekten Investments über Dachfonds oder bei illiquiden Assets, wo Daten von GPs in proprietären Formaten geliefert werden.

3. Kern-IT-Architektur für Look-through-Reporting

Eine robuste IT-Architektur ist notwendig, um die Daten zu sammeln, zu verarbeiten und compliant zu berichten. Dabei sind auch breitere Anforderungen an Finanz-IT zu berücksichtigen (z.B. Prinzipien für effektive Risikodatenaggregation wie BCBS 239 oder nationale IT-Aufsicht wie MaRisk AT 7, die Governance, Datenqualität und Systemintegrität fordern):

Architekturkomponente	Funktion im Look-through-Prozess	Relevanz für Compliance (z.B. BCBS 239, MaRisk)
ABOR/IBOR Layer (Source Systems)	Liefern Basisdaten zu Fondspositionen, Cashflows, Bewertungen.	Grundlage der Daten (Ursprung), Relevanz für Nachvollziehbarkeit (Audit Trail).
Datenintegrationsschicht (ETL, APIs, Feeds)	Sammeln von Daten aus internen/externen Quellen (GPs, Custodians, Datenanbieter).	Gewährleistung der Datenverfügbarkeit (MaRisk), Schnittstellenmanagement.
Data Warehouse / Data Lake (Zentrale Plattform)	Zentrale Speicherung aller Look-through-Daten, Harmonisierung, Golden Record, Historie.	Kern für Datenaggregation (BCBS 239 Principle 2), Historienarchiv (Audit Trail), Datenqualität (BCBS 239 Principle 3).
Validierungs- & Mapping-Engine (Teil der Plattform oder separat)	Automatisierte Prüfungen (Vollständigkeit, Plausibilität), Abbildung auf Zieltaxonomien (z.B. Solvency II Asset-Typen, ESG-Kategorien).	Sicherstellung der Datenqualität (BCBS 239 Principle 3), Konsistenz.
Regulatory Reporting Engine (Reporting Layer)	Generierung der finalen Berichte (z.B. QRTs, ESG-Disclosures) basierend auf den aufbereiteten Daten.	Effiziente und korrekte Berichterstattung (BCBS 239 Principle 4), Formatkonvertierung (z.B. nach XBRL).
Governance Framework & Tools (Übergreifend)	Data Ownership, Metadaten-Management, Prozessdokumentation, Zugriffssteuerung (IAM), IT-Security.	Grundlage für gesamte Daten-Governance (BCBS 239 Principle 1), IT-Sicherheit (MaRisk AT 7).

4. Abbildungstiefe und Herausforderungen bei komplexen Strukturen

Look-through bedeutet, die Kette der Beteiligungen bis zu einer bestimmten Ebene zu „durchleuchten“. Die erforderliche Tiefe geht oft bis zur juristischen Einheit, nicht nur bis zum Zielfonds:

• Direkte Fondsinvestments (AIF): Hier müssen die zugrundeliegenden Positionen (Aktien, Anleihen, Kredite, Immobilien etc.) erfasst werden, idealerweise mit eindeutigen Identifikatoren (ISIN, WKN, LEI, Grundbuchblatt etc.).
• Indirekte Investments (Dachfonds / Fund-of-Funds): Die Kette erstreckt sich über mehrere Ebenen: Ihr Fonds → Zielfonds (GGP) → zugrundeliegende Positionen im Zielfonds → ggf. weitere Beteiligungsschichten. Hier muss die Transparenz über alle Schichten hinweg hergestellt werden.
• Erforderliche Abbildungstiefe: In der Praxis geht Look-through oft bis zur Ebene der juristischen Einheit im Portfolio (z.B. die operierende GmbH, das Projekt-SPV), nicht notwendigerweise bis zu sehr kleinteiligen Vermögenswerten oder individuellen Personen, es sei denn, dies ist spezifisch gefordert (z.B. für bestimmte ESG-Daten). Eindeutige Entity-IDs (LEI, nationale Unternehmensnummern) sind hier entscheidend.

4.1 Herausforderungen bei Konzernverbund und Mehrfachbeteiligung

Besondere Komplexität entsteht, wenn ein einzelner Vermögenswert (z.B. ein Portfoliounternehmen) indirekt über mehrere Kanäle (z.B. verschiedene Zielfonds, parallele Vehikel, Co-Investments) gehalten wird oder Teil eines Konzerns ist, in den ebenfalls investiert wird:

• Kreuz- und Quer-Beteiligungen: Ein Unternehmen kann gleichzeitig über Fonds A und Fonds B gehalten werden, in die Sie investiert sind.
• Intercompany-Beziehungen: Transaktionen (Kredite, Gebühren, Dividenden) innerhalb eines Konzerns im Portfolio müssen ggf. eliminiert oder konsolidiert dargestellt werden, um Doppelzählungen oder eine falsche Risikobewertung zu vermeiden.
• Aggregation und Gewichtung: Die Gesamtbeteiligung an einem Unternehmen über alle Investitionskanäle hinweg muss korrekt berechnet werden, oft gewichtet mit Ihrem jeweiligen Anteil an jedem Kanal.

Fonds	Eigener Anteil in Fonds	Fonds Anteil	Effektiver Anteil
A	20%	5%	1,0%
B	10%	3%	0,3%
Total			1,3%

5. Operative Prozesse und Systemfunktionen zur Bewältigung der Komplexität

Die IT-Architektur muss spezifische operative Prozesse zur Bewältigung der beschriebenen Herausforderungen unterstützen:

5.1 Datenaggregation und Harmonisierung

Der Prozess beginnt mit dem Sammeln der Daten. Hier sind spezifische Systemfunktionen zur Bewältigung heterogener Formate und komplexer Strukturen nötig:

• Automatisierte Datenextraktion: Einsatz von Technologien wie OCR (Optical Character Recognition) und NLP (Natural Language Processing) mit Machine Learning zur automatisierten Extraktion von Daten aus unstrukturierten (PDFs) oder teilstrukturierten Dokumenten (Excel), die von GPs geliefert werden.
• Datenmapping: Systemfunktionen zur Abbildung der verschiedenen externen Datenformate und Klassifizierungen auf ein internes, standardisiertes Datenmodell im Data Warehouse.
• Entity Resolution: Funktionen, die dasselbe Unternehmen oder denselben Asset über verschiedene Quellen hinweg mit unterschiedlichen Identifikatoren (Name, LEI, Registernummer etc.) erkennen und einem eindeutigen internen Master-Datensatz zuordnen.
• Hierarchie-Management: Systemfähigkeit zur Abbildung und Verwaltung komplexer Beteiligungshierarchien (Fonds -> Zielfonds -> Portfolio-Unternehmen -> Asset).

5.2 Validierung und Konsolidierung

Nach der Aggregation und Harmonisierung sind Validierung und Konsolidierung kritisch:

• Automatisierte Plausibilitäts-Checks: Systemroutinen, die auf Inkonsistenzen, fehlende Daten, Formatfehler oder unerwartete Werte prüfen (z.B. Summe der Teile passt nicht zum Ganzen, unerklärliche NAV-Schwankungen auf Look-through-Ebene).
• Konsolidierungslogik: Implementierung von Regeln im Data Warehouse oder der Reporting Engine zur:
  • Eliminierung von Intercompany-Transaktionen: Erkennen und Neutralisieren von Cashflows oder Werten zwischen Einheiten im selben Portfolio-Konzern.
  • Berechnung der effektiven Beteiligung: Genaue Ermittlung des Anteils an einem Portfolio-Unternehmen, auch wenn dieses über mehrere Fondsschichten oder parallele Vehikel gehalten wird, unter Berücksichtigung der Beteiligungsquoten auf jeder Ebene.
  • Single Count Aggregation: Sicherstellen, dass ein Unternehmen, in das mehrfach investiert wurde, in Summe nur einmal mit dem korrekten Gesamt-Exposure gezählt wird (Vermeidung von Doppelzählungen).
• Fehlermanagement: Workflows zur Nachverfolgung, Klärung und Behebung von Datenfehlern, oft unter Einbindung von Data Stewards.

5.3 Reporting und Archivierung

Die finale Generierung der Look-through-Reports und deren Archivierung:

• Berichtsgenerierung: Die Regulatory Reporting Engine nutzt die validierten und konsolidierten Daten, um die benötigten Berichte (z.B. Solvency II QRTs, ESG-Disclosure-Tabellen) im geforderten Format (XBRL, XML, CSV) zu erstellen.
• Audit Trail & Archivierung: Lückenlose Protokollierung jeder Änderung an Daten und jeder Prozessschritt. Revisionssichere Archivierung der gelieferten Berichte und der zugrundeliegenden Daten über die gesetzlichen Fristen hinaus.

6. Governance und Qualitätssicherung

Robuste Prozesse und klare Verantwortlichkeiten sind für das Look-through-Reporting unerlässlich:

• Data Stewardship: Etablierung von Rollen, die für die Definition, Qualität und Pflege spezifischer Datenbereiche verantwortlich sind (z.B. Asset-Klassifizierungen, Entity Master Data, Ownership-Strukturen).
• Regelmäßige Daten-Audits: Durchführung von Stichproben oder automatisierten Audits, um die Qualität und Konsistenz der Look-through-Daten zu prüfen.
• Prozessdokumentation: Klare Beschreibung aller Schritte von der Datenerfassung bis zur Berichtsgenerierung.
• Change Management: Kontrollierter Prozess zur Handhabung von Änderungen an Reporting-Templates, Datenanforderungen oder internen Systemen.

7. Fazit und Ausblick

Das Look-through-Reporting ist eine operationelle und technische Kernherausforderung im Asset Management, getrieben durch wachsende regulatorische Anforderungen. Die Komplexität ergibt sich aus der Notwendigkeit, Daten granular, über mehrere Investitions-Ebenen hinweg und in komplexen Strukturen (Konzernverbund, Mehrfachbeteiligung) abzubilden und zu konsolidieren.

Die Bewältigung erfordert eine robuste IT-Architektur mit einer zentralen Datenplattform (Data Warehouse/Lake), leistungsfähigen Integrations-, Validierungs- und Konsolidierungsfunktionen sowie spezialisierte Systemfunktionen zur Abbildung von Hierarchien und effektiven Beteiligungen. Genauso entscheidend sind präzise operative Prozesse, klare Governance-Strukturen und eine Kultur der Datenqualität.

Für die Zukunft bieten Technologien wie KI (z.B. für Datenextraktion und Klassifizierung) und weiterentwickelte Datenplattformen Potenzial zur weiteren Automatisierung und Effizienzsteigerung. Die Notwendigkeit, Look-through-Daten für verschiedene Zwecke (Risiko, ESG, Regulatorik) zu nutzen, spricht für eine einheitliche Datenarchitektur als strategische Grundlage.

Ein robustes Look-through-Reporting ist nicht nur eine regulatorische Pflicht, sondern ein Zeichen operativer Exzellenz und die Basis für fundierte Analysen und Entscheidungen in komplexen Portfolios.