Family Office Technologische Infrastruktur: Aufbau oder Abdriften

Das Problem ist die Anhäufung, nicht der Ehrgeiz

Wenn ein Family Office eingerichtet wird, fallen die ersten technologischen Entscheidungen unter Zeitdruck: Das Team ist klein, die Vermögenswerte sind in Bewegung, und die Priorität liegt darauf, die Berichterstattung zu erledigen, nicht darauf, zu konzipieren, wie sie erfolgen soll. Ein Portfolio-Buchhaltungssystem wird lizenziert. Ein Verwahrer stellt einen Datenfeed bereit. Jemand erstellt ein Konsolidierungsmodell in einer Tabellenkalkulation, weil das Buchhaltungssystem bestimmte Asset-Klassen noch nicht verarbeiten kann. Innerhalb von zwei Jahren weist diese Tabellenkalkulation Abhängigkeiten auf, besitzt eine Versionshistorie, die niemand mehr versteht, und hat einen festen Verantwortlichen, der als Einziger den Monatsabschluss durchführen kann. Das ist keine Nachlässigkeit. Es ist das vorhersehbare Ergebnis der Lösung unmittelbarer Probleme ohne strukturellen Rahmen.

Die Folge ist das, was Fachleute als «Technologie-Drift» bezeichnen: ein System, das nie als Ganzes konzipiert wurde und daher nur zeitweise als Ganzes funktioniert. Eine Umfrage eines grossen Verwahrungsnetzwerks aus dem Jahr 2023 ergab, dass rund 60 Prozent der Single Family Offices mit einem Vermögen von über $500M angaben, mehr als acht verschiedene Datenquellen für die konsolidierte Berichterstattung zu nutzen. Weniger als die Hälfte dieser Quellen war durch einen formellen Datenvertrag verbunden. Die andere Hälfte wurde manuell, in der Regel monatlich, von einem Mitarbeiter des Finanz- oder Operationsteams abgeglichen. Der Zeitaufwand für diesen Abgleich betrug durchschnittlich 14 Stunden pro Berichtszyklus, was bei vollständiger Kostenanrechnung einen erheblichen und wiederkehrenden Betriebsaufwand darstellt, der selten in einer Budgetlinie ausgewiesen wird.

Vier Ebenen, über die jeder Family-Office-Stack verfügen muss

Eine gut funktionierende Technologieinfrastruktur definiert sich nicht durch ihre ausgefeilteste Komponente. Sie definiert sich vielmehr dadurch, ob sie über vier klar voneinander abgegrenzte Ebenen mit eindeutig festgelegten Zuständigkeiten verfügt: Datenerfassung, einen Golden-Record-Speicher, eine Analyse- und Berichtsebene sowie eine Governance- und Audit-Ebene. Teams, die mit der Zuverlässigkeit ihrer Berichterstattung zu kämpfen haben, vermissen fast immer mindestens eine dieser Ebenen, oder haben zugelassen, dass zwei davon in einem einzigen Tool zusammengefasst wurden, das keinem der beiden Zwecke gerecht wird.

Ebene 1: Datenerfassung

Die Datenerfassung umfasst alle Wege, über die externe Informationen in den Stack gelangen. Dazu gehören Feeds von Verwahrstellen (in der Regel als SWIFT-MT- oder ISO-20022-Nachrichten oder über eine proprietäre API bereitgestellt), NAV-Berichte von Fondsverwaltern, Bewertungen von Direktinvestitionen, Banktransaktionsdateien sowie Feeds mit Steuerunterlagen. Das entscheidende Prinzip auf dieser Ebene ist die Unveränderlichkeit: Von einer Quelle empfangene Rohdaten sollten vor jeglicher Transformation genau so gespeichert werden, wie sie eingegangen sind, mit Zeitstempel und Quellenkennung. Diese einzige Regel beseitigt eine ganze Kategorie von Abstimmungsstreitigkeiten, da sie die Möglichkeit erhält, zwischen einem Datenfehler an der Quelle und einem Transformationsfehler im eigenen Haus zu unterscheiden.

Ebene 2: Der Golden-Record-Speicher

Der Golden-Record-Speicher ist die einzige massgebliche Darstellung von Beständen, Bewertungen, Transaktionen und Entitätsbeziehungen zu einem beliebigen Zeitpunkt. Es handelt sich um die Ebene, die die meisten Family Offices nie offiziell definiert haben. Ohne sie trifft jeder nachgelagerte Bericht implizit eigene Entscheidungen darüber, welche Quelle als verbindlich gilt, wenn Quellen voneinander abweichen, und diese Entscheidungen werden selten dokumentiert. Der Golden-Record-Speicher erfordert ein Datenwörterbuch: eine formale Spezifikation jedes Feldes, seiner zulässigen Werte, seiner Quellhierarchie (welche Quelle bei einem Konflikt Vorrang hat) und seiner Aktualisierungshäufigkeit. Die Erstellung dieses Wörterbuchs vor der Auswahl der Tools ist die richtige Reihenfolge, nicht umgekehrt. Die meisten Konsolidierungsprojekte scheitern, weil das Datenwörterbuch nachträglich erstellt wird, indem rückentwickelt wird, was das ausgewählte System unterstützen kann.

Ebene 3: Analyse- und Berichtsebene

Die Analyseebene greift auf den Golden-Record-Speicher zu und erstellt Performance-Attributionen, Risikoaggregationen, Cash-Flow-Prognosen sowie kundenorientierte Berichte. Die oberste Regel lautet: Diese Ebene muss gegenüber dem Golden-Record-Speicher schreibgeschützt sein. Analysten und Investment-Experten sollten zu keinem Zeitpunkt die Möglichkeit haben, aus einem Berichtstool heraus Änderungen an den massgeblichen Daten vorzunehmen. In der Praxis wird diese Regel regelmässig verletzt, und jeder Verstoss ist der Keim eines Schattensystems. Stellt ein Analyst fest, dass das Berichtstool eine bestimmte Berechnung nicht bewältigt, ist die naheliegende Reaktion, die Daten in eine Tabellenkalkulation zu exportieren und die Berechnung dort durchzuführen. Wird das Ergebnis anschliessend als verbindlich präsentiert, existieren im Team nun zwei konkurrierende Versionen der Wahrheit.

Ebene 4: Governance- und Audit-Ebene

Die Governance- und Audit-Ebene erfasst, wer was wann und mit wessen Genehmigung geändert hat. In den meisten Fällen handelt es sich dabei nicht um eine eigenständige Anwendung, sondern um eine Reihe von Vorgaben, die einheitlich auf die anderen drei Ebenen angewendet werden. Zugriffsprotokolle, Änderungsprotokolle, Genehmigungsworkflows für Bewertungsabweichungen sowie eine formelle Aufzeichnung von Datenqualitätsausnahmen gehören alle hierher. Diese Ebene ist für Häuser mit Berichtspflichten gemäss FATCA oder CRS nicht optional, da beide nachweisbare Audit-Trails für Finanzdaten auf Unternehmensebene vorschreiben. BEPS-Säule II fügt eine weitere Dimension hinzu: Das globale Mindeststeuersystem von 15 Prozent erfordert eine Zuordnung der Einkünfte nach Rechtsordnungen in einer Detailtiefe, die tabellenkalkulationsbasierte Systeme strukturell nicht in der von den Aufsichtsbehörden erwarteten Prüfungsqualität unterstützen können.

Eine Struktur ohne explizite Governance-Ebene ist nicht nur in operativer Hinsicht anfällig. Sie stellt auch ein regulatorisches Risiko dar, das mit jeder weiteren Rechtsordnung zunimmt, die die Familie in ihre Struktur aufnimmt.

Warum Schattensysteme entstehen und warum sie fortbestehen

Schattensysteme sind kein technologisches Versagen. Sie sind ein Rückmeldesignal. Sie treten zuverlässig innerhalb von 18 bis 24 Monaten nach der Einführung eines neuen Systems auf, weil das Kernsystem einen bestimmten Nutzerbedarf nicht erfüllt hat und niemand mit der Befugnis, das Kernsystem zu korrigieren, sich darum gekümmert hat. Der Nutzer schliesst diese Lücke mit den verfügbaren Mitteln, was fast immer eine Tabellenkalkulation bedeutet. Die Tabellenkalkulation funktioniert. Man verlässt sich darauf. Sie wird immer komplexer. Die Person, die sie erstellt hat, verlässt das Unternehmen oder wechselt die Position, und die Tabellenkalkulation wird zu dem, was in der Branche als «Key-Person-Dependency mit Dateiendung» bezeichnet wird.

Das Fortbestehen von Schattensystemen folgt einer einheitlichen Logik. Die Stilllegung eines Schattensystems erfordert die Anerkennung, dass es verbindliche Daten enthält, die Migration dieser Daten in den Golden-Record-Speicher, die Umsetzung seiner Logik im Kernsystem sowie die Überzeugung des Teams, dass das Kernsystem nun den Bedarf erfüllt, den das Schattensystem zuvor gedeckt hat. Jeder dieser Schritte ist mit Kosten und Risiken verbunden. Der Betrieb des Schattensystems hingegen verursacht keine zusätzlichen Kosten. Für jedes einzelne Quartal ist es die rationale Entscheidung, es unverändert zu belassen. Über mehrere Jahre hinweg führen diese rationalen Einzelentscheidungen zu einem irrationalen kollektiven Ergebnis: einem Stack mit mehreren konkurrierenden Datenquellen, von denen keine vollständig vertrauenswürdig ist.

Integrationssprödigkeit und die Fehlerangriffsfläche

Punkt-zu-Punkt-Integrationen zwischen Systemen bilden das Bindeglied der meisten Family-Office-Stacks und sind die häufigste Ursache für stille Fehler. Eine Punkt-zu-Punkt-Verbindung besteht in der Regel aus einer Dateiübertragung, einem Skript und einer Formatannahme. Diese Annahme ist, wenn überhaupt, nur im Skript selbst dokumentiert. Ändert das Quellsystem sein Ausgabeformat, was Anbieter regelmässig und mit unterschiedlicher Vorankündigung tun, , schlägt das Skript fehl. Ist der Fehler offensichtlich (eine Fehlermeldung, eine fehlende Datei), wird er schnell erkannt. Ist der Fehler jedoch still, ein Feld verschiebt sich in einer Flatfile, und das Skript läuft weiter, ordnet nun aber den falschen Wert dem falschen Feld zu, , wird er möglicherweise erst bei einem Audit oder einer Kundenprüfung entdeckt.

Jede zusätzliche Punkt-zu-Punkt-Verbindung, die ohne formellen Datenvertrag hinzugefügt wird, verdoppelt in etwa die erwartete Fehleranfälligkeit dieses Knotens. Jede Verbindung hängt von der Stabilität ihrer Quelle und der Stabilität jeder anderen Verbindung ab, die in dasselbe nachgelagerte Ziel mündet. Ein Haus mit zwölf Datenquellen und zwanzig Integrationen verwaltet nicht zwanzig isolierte Integrationsrisiken, sondern ein Netzwerk von Abhängigkeiten, deren Ausfallmodi miteinander interagieren. Die praktische Lösung besteht nicht darin, die Anzahl der Datenquellen zu reduzieren, was oft nicht machbar ist, , sondern darin, Datenverträge einzuführen: formelle, versionierte Vereinbarungen, die das Schema, die Aktualisierungshäufigkeit und das Fehlerbehandlungsprotokoll für jeden Datenfeed festlegen. Datenverträge sorgen dafür, dass Integrationsfehler nicht mehr unbemerkt bleiben, sondern sichtbar werden, und nicht mehr mehrdeutig, sondern eindeutig zuordenbar sind.

Ein Hinweis zu Datenfeeds von Verwahrstellen und Fondsverwaltern

Die Datenfeeds der Verwahrstellen unterscheiden sich erheblich hinsichtlich Qualität und Detailtiefe. Ein Prime-Brokerage-Feed enthält in der Regel Details auf Transaktionsebene, aufgelaufene Erträge und Finanzierungskosten. Ein Feed einer Privatbank liefert möglicherweise lediglich Positionsübersichten zum Tagesende. NAV-Berichte von Fondsverwaltern werden häufig als PDF oder strukturierte Tabellenkalkulation statt als maschinenlesbare Dateien bereitgestellt, was einen manuellen oder halbautomatischen Extraktionsschritt erfordert, mit eigenen Fehlerquellen. Häuser, die erhebliche Allokationen in Private Markets verwalten, sollten die Kosten für die Datenextraktion aus nicht standardisierten Quellen explizit budgetieren und bereits bei der Fondszeichnung den Zugang zu maschinenlesbaren Datenfeeds aushandeln, sofern der Fondsverwalter diese bereitstellen kann.

Governance als Vorsorgemaßnahme: der Technologieausschuss

Der kostengünstigste Mechanismus zur Verhinderung künftigen Technologie-Drifts ist ein Technology-Governance-Ausschuss, der vierteljährlich zusammentritt und neben dem Chief Operating Officer und dem Finanzverantwortlichen mindestens einen Investment Principal umfasst. Das Mandat des Ausschusses ist eng gefasst: Überprüfung von Datenqualitätsausnahmen aus dem vorangegangenen Quartal, Genehmigung neuer Datenquellen oder Integrationen vor deren Aufnahme in die Systemlandschaft sowie Bewertung von Schattensystemen, die vom Team identifiziert wurden. Die Anwesenheit des Investment Principal ist nicht symbolisch. Investitionsentscheidungen hängen von der Datenqualität ab, und seine Einbindung schafft Verantwortlichkeit zwischen der Technologieebene und den darauf basierenden Entscheidungen.

Der Ausschuss sollte ein Technologieregister führen: ein einziges Dokument, in dem jedes System, jede Integration, jede Datenquelle sowie der Name der jeweils zuständigen Person aufgeführt sind. Das Register ist weder ein Projektplan noch eine Roadmap. Es ist eine Bestandsaufnahme des aktuellen Zustands. Teams, die noch nie ein solches Register erstellt haben, sind in der Regel überrascht, wie viele Verbindungen bestehen, und wie wenige davon einen namentlich benannten Verantwortlichen haben. Die Erstellung des Registers legt die dringendsten Sanierungsprioritäten offen, ohne dass eine externe Bewertung erforderlich ist.

Das Technologieregister ist das Äquivalent einer physischen Inventur im Family Office: Seine Pflege ist mit sehr geringen Kosten verbunden und ist die Voraussetzung für jede sinnvolle Verbesserung des Stacks.

Die richtige Abfolge bei einem Konsolidierungsprojekt

Für Häuser, die zu dem Schluss gekommen sind, dass der kumulierte Drift nicht mehr beherrschbar ist, ist ein Konsolidierungsprojekt die geeignete Massnahme. Die korrekte Vorgehensweise umfasst drei Phasen. Die erste Phase ist definitorischer Natur: Das Datenwörterbuch wird erstellt, alle vorhandenen Quellen und Integrationen werden kartiert, alle Schattensysteme identifiziert und eine Quellhierarchie für jeden konfliktbehafteten Datentyp vereinbart. Diese Phase sollte vier bis acht Wochen dauern und in einer schriftlichen Spezifikation resultieren, nicht in einer Präsentation. Die zweite Phase ist architektonischer Natur: Es werden Tools ausgewählt oder konfiguriert, mit denen der in der Spezifikation definierte Golden-Record-Speicher implementiert werden kann. Die Spezifikation schränkt die Auswahl ein; die Auswahl verändert die Spezifikation nicht. Die dritte Phase ist die Migration: Daten werden übertragen, Logik aus Schattensystemen repliziert, mit dem Altzustand abgeglichen und jede Legacy-Komponente formell ausser Betrieb genommen.

Die häufigste Fehlerquelle bei Konsolidierungsprojekten besteht darin, die erste Phase zu verkürzen oder ganz zu überspringen, weil das Team das neue System so schnell wie möglich in Betrieb nehmen möchte. Ein System, das konfiguriert wird, bevor das Datenwörterbuch vollständig ist, wird so eingerichtet, dass es den Einschränkungen des Ist-Zustands entspricht, anstatt den Soll-Zustand zu unterstützen. Das Ergebnis ist ein neues System, das die strukturellen Probleme des alten reproduziert, verbunden mit erheblichen Kosten und einem Team, das für mehrere Jahre Widerstand gegen weitere Konsolidierungsbemühungen leistet. Die erste Phase ist kein Mehraufwand. Sie ist die eigentliche Arbeit.