Modellierung komplexer Hypothekenstrukturen
Warum Covered-Bond-Reporting vom zugrunde liegenden Datenmodell abhängt
Covered-Bond-Reporting wird häufig als reines Berechnungsproblem verstanden: Darlehenssaldo nehmen, LTV-Grenze anwenden, den anrechenbaren Deckungswert bestimmen, Überdeckung berechnen und den Bericht erzeugen.
In der Praxis ist die Berechnung jedoch selten der schwierigste Teil. Die wichtigere Frage ist, ob die Software den Deckungspool überhaupt korrekt abbildet.
Das ist entscheidend, weil reale hypothekarische Deckungspools keine flachen Darlehenslisten sind. Sie bestehen aus Netzwerken von Darlehensnehmern, Krediten bzw. Darlehen, Hypotheken, Liegenschaften, Bewertungen, Rangstellen, vorrangigen Belastungen, Allokationsregeln, Anrechnungsgrenzen, Liquiditätsanforderungen und Reporting-Pflichten. Ein großer Teil der Covered-Bond-Logik liegt nicht in den Objekten selbst, sondern in den Beziehungen zwischen ihnen.
Die vier Entitätsklassen
Ein robustes Covered-Bond-Datenmodell muss vier Objekte als eigenständige Entitäten behandeln:
- Darlehensnehmer — die Partei oder Gruppe, deren wirtschaftliche Exponierung beurteilt wird.
- Kredit / Darlehen — die Kreditverpflichtung selbst, einschließlich Saldo, Laufzeit, Tilgungsprofil und anrechnungsrelevanter Attribute.
- Hypothek — das im Grundbuch eingetragene Sicherungsinstrument, mit Rang, eingetragenem Betrag und gesicherten Verpflichtungen; rechtlich getrennt vom Darlehen, das sie besichert.
- Liegenschaft — das Immobilienobjekt, gegen das die Hypothek eingetragen ist, mit Beleihungswert, Marktwert, Bewertungsdatum, Lage, Objekttyp und anrechnungsrelevanten Eigenschaften.
Die häufige Abkürzung besteht darin, die Hypothek direkt im Kredit bzw. Darlehen aufgehen zu lassen. Das funktioniert für den einfachsten Fall mit einem Darlehensnehmer, einem Darlehen und einer Liegenschaft. Es scheitert jedoch, sobald die Struktur realistisch wird: eine Hypothek besichert mehrere Darlehen, ein Darlehen wird durch mehrere Hypotheken besichert, eine Simultanhypothek erstreckt sich über mehrere Liegenschaften oder mehrere Hypotheken mit unterschiedlichen Rängen liegen auf derselben Liegenschaft.
Ab diesem Punkt ist die Unterscheidung zwischen Darlehen, Hypothek und Liegenschaft nicht theoretisch. Sie bestimmt, wie viel Deckungswert verfügbar ist, wo er allokiert werden kann und ob die Zahl gegenüber Deckungsstockprüfer, Auditor, Aufsicht oder Ratingagentur erklärbar ist.
Beziehungsdatensätze: Wo Covered-Bond-Fakten tatsächlich hingehören
In Covered-Bond-Software gehören wichtige Informationen häufig zur Beziehung zwischen Entitäten.
Der Rang einer Hypothek ist nicht einfach eine Eigenschaft der Liegenschaft. Er ist eine Eigenschaft einer konkreten Belastung auf einer konkreten Liegenschaft. Die verbleibende Kapazität für eine nachrangige Hypothek hängt vom aktuellen Saldo vorrangiger Exponierungen ab. Die Allokation des Beleihungswerts bei einer Simultanhypothek gehört zur Verbindung zwischen Hypothek und Liegenschaft, nicht zur Liegenschaft isoliert.
Deshalb benötigt das Modell explizite Beziehungsdatensätze — oder, in der Datenmodellierung, Junction Records. Zum Beispiel:
- Borrowing verknüpft Darlehensnehmer und Kredit / Darlehen.
- Collateralisation verknüpft Kredit / Darlehen und Hypothek.
- Encumbrance verknüpft Hypothek und Liegenschaft.
- Ownership oder wirtschaftliche Zuordnung verknüpft Darlehensnehmer und Liegenschaft, wo dies für Aggregationen erforderlich ist.
In diesen Datensätzen liegen die operativen Fakten: Rang, eingetragener Betrag, allokierter Beleihungswert, Restkapazität, Anrechnungsstatus, Bewertungsdatum, Freigabestatus, Regelversion und Audit Trail. Wenn diese Fakten in Kommentaren, Anhängen oder Tabellen liegen, lassen sie sich nicht zuverlässig berechnen, abfragen, versionieren oder prüfen.
Ein Datensatz, unterschiedliche Reporting-Sichten
Covered-Bond-Emittenten benötigen mehrere Sichten auf dasselbe Portfolio.
Die regulatorische Sicht erfordert Loan-Level-Anrechenbarkeit: LTV-Grenzen je Liegenschaft, anrechenbare Deckungswerte, Überdeckung, Haircuts, Liquiditätsreserve, Laufzeitinkongruenzen und Asset Eligibility. In Österreich ist die Unterscheidung zwischen anrechenbarer Deckung und freiwilliger Überdeckung besonders wichtig. Ein Darlehen kann im Deckungspool verbleiben, während nur ein Teil davon als anrechenbare Deckung zählt. Ein einzelnes Saldo-Feld reicht dafür nicht aus.
Die Sicht der Ratingagentur kann eine Aggregation auf Ebene des Darlehensnehmers erfordern. Ein Darlehen, das isoliert konservativ wirkt, kann anders aussehen, sobald alle Darlehen und alle zugehörigen Liegenschaften des Darlehensnehmers gemeinsam betrachtet werden. Bei gewerblichen Hypothekenpools kann dieser Whole-Loan-LTV auf Darlehensnehmer-Ebene aussagekräftiger sein als einzelne Loan-LTVs.
Beide Sichten sollten aus demselben zugrunde liegenden Datenmodell entstehen. Wenn regulatorisches Reporting, Ratingagentur-Templates und Treasury-Dashboards aus getrennten Extrakten erzeugt werden, sind Abstimmungsprobleme bereits im Prozess angelegt.
Was schiefläuft, wenn das Modell zu einfach ist
Schwache Modelle scheitern selten spektakulär. Sie scheitern durch Workarounds.
Allokationslogik wandert in Tabellen. Restkapazitäten werden aus statischen Annahmen statt aus aktuellen vorrangigen Salden berechnet. LTV-Grenzen je Liegenschaft werden zu früh approximiert. Der Deckungsstockprüfer fragt nach einer Nachvollziehbarkeit vom berichteten LTV bis zu Bewertung, Rang und Allokationsregel, und die Antwort hängt von manueller Rekonstruktion ab.
Das Ergebnis kann trotzdem eine Zahl sein. Aber es ist eine Zahl, die schwerer zu vertrauen und schwerer zu verteidigen ist.
Für Banken wird daraus regulatorisches Risiko, Audit-Aufwand, Abstimmungsarbeit mit Ratingagenturen und operative Abhängigkeit von wenigen Personen, die den Workaround verstehen.
Der praktische Standard für Covered-Bond-Software
Eine geeignete Covered-Bond-Plattform benötigt keine exotische Technologie. Sie benötigt die richtigen Abstraktionen.
Sie sollte Darlehensnehmer, Kredite bzw. Darlehen, Hypotheken, Liegenschaften und ihre Beziehungen als strukturierte, versionierte Datensätze führen. Sie sollte Anrechenbarkeit auf Liegenschafts- und Darlehensebene berechnen, rangabhängige Restkapazitäten verarbeiten, Simultanhypotheken allokieren, anrechenbare und nicht anrechenbare Darlehensanteile unterscheiden und die Lineage jeder berichteten Zahl erhalten.
Der Punkt ist nicht, rechtliche Beurteilung, Treasury-Expertise oder die Prüfung durch den Deckungsstockprüfer zu ersetzen. Der Punkt ist, sicherzustellen, dass diese Beurteilung in Software so abgebildet wird, dass sie konsistent angewendet und später erklärt werden kann.
Covered Bonds sind rechtliche Instrumente und Refinanzierungsprodukte. In Software sind sie auch Datenstrukturen.
Die Qualität dieser Strukturen entscheidet darüber, ob LTV, Anrechenbarkeit, Überdeckung und Reporting-Zahlen vertrauenswürdig sind — und ob der Prozess effizient genug läuft, um über manuelle Rekonstruktion hinaus zu skalieren.
