CrossLease Blog

Zwischen Anpassung und Vergleichbarkeit: Warum Leasinggesellschaft und Refinanzierungsbank an denselben Daten scheitern

Thu, 16 Apr 2026 00:00:00 GMT

Warum Leasingdaten in der Refinanzierung immer wieder nicht stimmen – obwohl sie korrekt sind

Montagmorgen, 8:15 Uhr. Der regelmäßige Bericht für eine laufende Refinanzierung steht an. Die aktuellen Daten der Leasinggesellschaft sind geliefert, der Bestand wirkt stabil. Und doch beginnt die Abstimmungsschleife:

Beim Abgleich mit dem Vormonat fehlen plötzlich 23 Verträge. Die durchschnittliche Restlaufzeit hat sich merklich verlängert. Bei drei größeren Verträgen stimmen die Restwerte nicht mehr mit dem vorherigen Stand überein. Die Rückfrage geht raus, mit Screenshots aus zwei scheinbar identischen Auswertungen, die unterschiedliche Zahlen zeigen.

Dieses Muster wiederholt sich in nahezu jedem Refinanzierungsprozess und seine Ursache liegt tiefer als fehlerhafte Daten.

Abweichungen entstehen selten durch falsche Daten

Die meisten Abweichungen entstehen nicht, weil Daten falsch sind, sondern weil sie unter unterschiedlichen Anforderungen entstehen und weiterverarbeitet werden.

Im operativen Leasinggeschäft müssen Daten vor allem aktuell und anpassungsfähig sein. Verträge werden verändert, Werte aktualisiert und Entscheidungen kurzfristig umgesetzt. Diese Dynamik ist notwendig, um das Geschäft zu steuern. Gleichzeitig entstehen dadurch kontinuierlich Veränderungen im Bestand.

In der Refinanzierung gelten andere Maßstäbe. Hier müssen Daten über die Zeit vergleichbar bleiben, Entwicklungen müssen erklärbar sein und Veränderungen dürfen nicht isoliert auftreten. Die Bestandsmeldung an den Refinanzierer lebt von dieser Konsistenz. Entscheidend ist nicht nur der aktuelle Stand, sondern die nachvollziehbare Entwicklung dahin.

Beide Perspektiven sind fachlich korrekt. Auf Bankseite bedeutet das jedoch: Treffen unerklärte Abweichungen ein, landet das Thema schnell im Covenant-Monitoring oder muss manuell vor dem nächsten Kreditkomitee nachgehalten werden, mit entsprechendem Aufwand auf beiden Seiten. Der Bruch entsteht dort, wo beide Logiken ohne gemeinsame Datengrundlage aufeinandertreffen.

Zahlen können korrekt sein und trotzdem nicht vergleichbar

Zahlen können den aktuellen Zustand exakt abbilden und damit fachlich richtig sein. Gleichzeitig können sie ihre Nachvollziehbarkeit im Zeitverlauf verlieren. Sie sind dann nicht falsch, aber nicht mehr ohne Weiteres verwendbar.

Genau hier entsteht der Widerspruch.

Eine Anpassung kann im operativen Kontext notwendig und korrekt sein. Ohne sichtbaren Bezug zur vorherigen Situation wird sie in der Weiterverarbeitung jedoch zu einer Abweichung. Der Bruch entsteht nicht in der Zahl selbst, sondern in der fehlenden Verbindung zu ihrer Entwicklung.

Damit verschiebt sich die zentrale Frage: nicht ob eine Zahl stimmt, sondern ob sie in ihrem Zusammenhang verständlich bleibt.

Die Schnittstelle als eigentlicher Problemraum

Der kritische Punkt liegt in der Übergabe zwischen beiden Seiten. Daten werden als fertiger Zustand weitergegeben, während die Entstehung dieses Zustands unsichtbar bleibt.

An dieser Stelle treffen zwei Logiken aufeinander: eine, die von laufender Anpassung geprägt ist, und eine, die auf Stabilität und Vergleichbarkeit angewiesen ist. Ohne eine Verbindung zwischen diesen beiden Ebenen entsteht eine strukturelle Lücke, Veränderungen werden nicht als Entwicklung wahrgenommen, sondern als unerklärliche Unterschiede zwischen zwei Zeitpunkten.

Die Folge ist eine bekannte Dynamik: Abweichungen werden identifiziert, Rückfragen gestellt, Ursachen im Nachhinein rekonstruiert. Dieser Ablauf wiederholt sich, weil die nötige Information von Anfang an fehlt. Mehr Felder im Bericht oder zusätzliche Prüfschritte machen Abweichungen schneller sichtbar, aber nicht verständlicher. Der Abstimmungsaufwand steigt, ohne dass sich die Situation grundlegend verbessert, weil der eigentliche Engpass nicht im Bericht liegt, sondern vor ihm.

Das eigentliche Problem ist kein Datenproblem, es ist ein Zeitstempelproblem

Hier liegt die zweite, häufig übersehene Dimension: Wer wann was verändert hat, ist systemseitig in der Praxis oft nicht rekonstruierbar. Eine Restwertrevision, also die nachträgliche Anpassung des kalkulierten Restwertes eines Leasingobjekts, erscheint im Stichtagsbericht als geänderter Wert, ohne dass Zeitpunkt, Anlass oder Vorwert sichtbar sind. Genauso verhält es sich bei einer Laufzeitverlängerung: Die neue Restlaufzeit ist korrekt abgebildet, aber der Refinanzierer sieht nicht, dass sich die ursprünglich angesetzte Laufzeit verändert hat, mit unmittelbaren Auswirkungen auf die Bewertung im Refinanzierungsrahmen. Bei einer Vertragsübernahme wechselt der Leasingnehmer, die Vertragsdaten bleiben formal identisch und dennoch stellt sich für das Sicherheitenverzeichnis die Frage nach der Bonität des neuen Schuldners. Eine Stundungsvereinbarung verändert vorübergehend den Zahlungsfluss, erscheint aber ohne Kontext wie eine planmäßige Abweichung im Cashflow-Profil.

In allen diesen Fällen ist die Zahl korrekt, aber ohne Zeitstempel, ohne Vorwert, ohne Anlass bleibt sie interpretationsoffen. Das ist kein Qualitätsproblem der Daten. Es ist ein strukturelles Defizit in der Art, wie Veränderungen erfasst und weitergegeben werden.

Was sich ändern muss

Die Lösung liegt nicht in weiteren Auswertungen, sondern in einem anderen Umgang mit Veränderungen.

Ein erster operativer Ansatz ist die strukturierte Trennung von Bestands- und Bewegungsdaten: Der Stichtagsbericht zeigt, was ist, ein ergänzendes Reporting zeigt, was sich seit dem letzten Stichtag verändert hat, welche Verträge hinzugekommen, weggefallen oder modifiziert wurden. Beide Perspektiven zusammen ergeben erst das vollständige Bild, das eine Bestandsmeldung für den Refinanzierer tragfähig macht.

Ein zweiter Ansatz ist der maschinenlesbare Änderungskontext je Vertragsereignis: Jede relevante Vertragsänderung wird mit Zeitstempel, Vorwert und Änderungstyp strukturiert erfasst und als Teil des Datentransfers mitgegeben. Nicht als Freitextkommentar, sondern als auswertbares Attribut. Damit wird aus einer ungeklärten Differenz eine erklärbare Entwicklung, ohne Rückfrage, ohne manuelle Rekonstruktion.

Fazit

Die meisten Diskussionen in der Refinanzierung drehen sich um Zahlen, die nicht zusammenpassen. In der Praxis sind diese Zahlen selten falsch.

Das Problem liegt in den unterschiedlichen Anforderungen, unter denen sie entstehen und genutzt werden und in einer Systemarchitektur, die Veränderungen als Zustände speichert, nicht als Ereignisse mit Zeitbezug. Solange Daten nur als aktueller Zustand übergeben werden, bleibt die Schnittstelle ein Bruch zwischen zwei Logiken.

Erst wenn jede relevante Vertragsänderung mit Zeitstempel, Vorwert und Anlass systemseitig vorliegt, entsteht eine gemeinsame Grundlage: eine Bestandsmeldung, die nicht erklärt werden muss, weil sie sich selbst erklärt. Die entscheidende Folgefrage ist dabei weniger technischer als organisatorischer Natur: Welche Vertragsereignisse müssen auf Seite der Leasinggesellschaft überhaupt als strukturierte Ereignisse erfasst sein und nicht nur als geänderter Zustand im Bestandssystem?

Warum Leasing-IT oft unnötig komplex ist

Wed, 25 Mar 2026 00:00:00 GMT

Warum Leasing-IT oft unnötig komplex ist

Leasing ist ein Geschäft, in dem Struktur entscheidend ist.

Vertragslogik, Restwertannahmen, Risiko und Refinanzierung greifen eng ineinander. Schon kleine Änderungen wirken sich oft an mehreren Stellen gleichzeitig aus.

Wer eine Leasinggesellschaft führt, weiß deshalb: Das Geschäft lässt sich nicht in einfache Standardstrukturen pressen.

Umso erstaunlicher ist eine Beobachtung aus vielen Projekten:

In vielen Leasinggesellschaften entsteht die größte Komplexität nicht im Markt, sondern im eigenen System.

Und das liegt selten an der fachlichen Logik, sondern an der Art, wie Systeme über Jahre erweitert wurden.

Komplexität entsteht schleichend

Kaum jemand entscheidet bewusst: „Wir bauen ein überkomplexes System."

Stattdessen kommt ein neues Restwertmodell hinzu, weil eine bestimmte Objektklasse anders bewertet werden muss. Ein großer Händler erhält eine Gebührenlogik, die im Standard nicht vorgesehen war. Eine Refinanzierungsbank fordert zusätzliche Vertragskennzeichen für ihr Pool-Reporting.

Jede dieser Anpassungen ist für sich genommen plausibel. Das Problem entsteht nicht durch die einzelne Entscheidung, sondern durch ihr Nebeneinander.

Nach einigen Jahren existieren mehrere Definitionen dessen, was eigentlich eindeutig sein sollte. Der Vertragsbestand im Managementreport basiert auf einer anderen Logik als der Bestand, der an eine Refinanzierungsbank gemeldet wird, obwohl beide angeblich dieselben Verträge beschreiben.

In vielen Häusern ist die Systemlandschaft kein Ergebnis einer Architektur, sondern der Ausnahmen der letzten zehn Jahre.

Warum Komplexität konserviert wird

Komplexität wird aktiv erhalten, weil sie Interessen schützt. Die Fachabteilung, die vor Jahren eine Sonderlogik für ihre Objektklasse durchgesetzt hat, verteidigt diese Logik, weil sie ihre Berichtswelt strukturiert. Die IT vermeidet Bereinigungen, weil Nebenwirkungen in historischen Produktlogiken schwer abzuschätzen sind. Und niemand übernimmt freiwillig Verantwortung für Entscheidungen, die vor acht Jahren jemand anderes getroffen hat.

Das Ergebnis ist ein stiller Konsens zur Konservierung: Niemand baut ab, weil jeder etwas zu verlieren hat. Dieser organisatorische Anreiz ist mindestens so wirkmächtig wie jede technische Ursache.

Mehr Features schaffen keine bessere Steuerung

In vielen Leasinggesellschaften wird jede neue Anforderung technisch beantwortet. Das Ergebnis wirkt leistungsfähig. Operativ zeigt sich jedoch häufig ein anderes Bild.

Beispielsweise wird vor der Übermittlung eines Reports an eine Refinanzierungsbank ein Export gezogen, in Excel plausibilisiert und an einzelnen Stellen manuell korrigiert. Offiziell ist der Prozess systemgestützt. Faktisch gibt es eine stille Qualitätssicherung außerhalb des Systems.

Oder bei der Einführung einer neuen Servicekomponente stellt sich heraus, dass die Abgrenzung zwischen Finanz- und Serviceleistung im System je nach Vertragsgeneration unterschiedlich codiert ist. Das Reporting weist damit systematisch falsche Werte aus, ohne dass dies im Tagesgeschäft auffällt.

Solange diese Routinen funktionieren, gelten sie als normal. Doch sie sind ein Hinweis darauf, dass die Steuerungslogik nicht vollständig konsistent ist. Mehr Funktionen erhöhen nicht automatisch die Qualität der Steuerung. Sie erhöhen oft nur die Komplexität des Systems - nicht die Klarheit der Entscheidungen.

Diagnosefragen für die eigene Organisation

Bevor ein Systemwechsel diskutiert oder eine Neuimplementierung beauftragt wird, lohnen sich fünf konkrete Fragen:

Gibt es in Ihrem Haus mehr als eine operative Definition von „Vertragsbestand"? Wer hat sie autorisiert und wann wurde sie zuletzt überprüft?

Wie viele manuelle Korrekturen finden zwischen Systemexport und externer Meldung statt? Werden diese dokumentiert, oder sind sie stilles Erfahrungswissen einzelner Mitarbeiter?

Wenn ein neuer Refinanzierungspartner morgen einen standardisierten Datensatz anfordert: Könnten Sie diesen aus dem System heraus reproduzierbar liefern, oder würde zuerst eine interne Klärungsrunde stattfinden?

Wie lange würde es dauern, einem neuen Mitarbeiter zu erklären, warum die Ausfalldefinition im Risikocontrolling von der Definition im Kundensystem abweicht?

Wer mehrere dieser Fragen nicht klar beantworten kann, hat ein Strukturproblem – kein Softwareproblem.

Refinanzierung als Belastungstest

Besonders deutlich wird das im Austausch mit Refinanzierungsbanken.

Eine Refinanzierungsbank interessiert sich nicht für interne Historien. Sie interessiert sich für belastbare, reproduzierbare Zahlen. Wenn sich das gemeldete Portfolio-Volumen zwischen zwei Perioden ohne klar dokumentierte Ursache verändert oder wenn Definitionen von Ausfall und Überfälligkeit nicht konsistent hergeleitet werden können, entsteht nicht nur Rückfragebedarf. Es entsteht Zweifel an der Systemstabilität.

Refinanzierung wirkt deshalb wie ein Stresstest. Sie legt offen, ob die interne Komplexität fachlich notwendig ist, oder historisch gewachsen.

Regulatorische Konsequenzen inkonsistenter Definitionen

Was intern als beherrschbare Unschärfe gilt, wird im regulatorischen Kontext zum strukturellen Risiko.

Refinanzierungspartner verlangen reproduzierbare, revisionssichere Datensätze, eine Anforderung, die eine Gesellschaft mit mehreren parallelen Berechnungslogiken strukturell nicht erfüllen kann. BaFin-Anforderungen an das Risikodatenmanagement verlangen eindeutige Datendefinitionen und eine dokumentierbare Herleitung aller risikorelevanten Kennzahlen. Und IFRS 16 setzt eine konsistente Abgrenzung von Leasing- und Servicekomponenten voraus, wer das im System nicht sauber abbildet, schafft Grundlagen für Prüfungsrisiken.

Strukturelle Bereinigungen sind deshalb keine IT-Projekte. Sie sind Governance-Entscheidungen.

Differenzierung rechtfertigt keine Fragmentierung

Leasing lebt von Produktvielfalt: Kilometerverträge, Restwertmodelle, Servicekomponenten, Sale-and-Lease-Back-Strukturen. Diese Vielfalt verlangt Flexibilität im Produktdesign, aber keinen unstrukturierten Datenkern.

Ein professionelles Leasing-System zeichnet sich nicht durch die Anzahl seiner Sonderlogiken aus, sondern durch die Stabilität seines Datenkerns. Produktvarianten dürfen diese Struktur nutzen, aber nicht unterlaufen. Wenn jede Abteilung ihre eigene Sicht auf denselben Vertrag entwickelt, entsteht keine höhere Professionalität, sondern Fragmentierung, die sich im Exposure-Reporting systematisch niederschlägt.

Wachstum verstärkt Schwächen

In kleineren Beständen lassen sich Unschärfen kaschieren. Mit wachsendem Vertragsvolumen, zusätzlichen Objektklassen und mehreren Refinanzierungspartnern funktioniert das nicht mehr.

Was früher eine erklärbare Ausnahme war, wird bei 50.000 oder 100.000 Verträgen zum strukturellen Muster. Unterschiedliche Definitionen skalieren mit. Manuelle Plausibilisierungen skalieren mit. Wachstum legt oft nicht neue Chancen frei, sondern alte Systemprobleme.

Spätestens wenn neue Refinanzierungslinien angebunden oder regulatorische Anforderungen verschärft werden, zeigt sich, ob die Systemarchitektur tragfähig ist. Wenn jede Erweiterung zunächst analysiert werden muss, weil niemand sicher sagen kann, welche Nebenwirkungen sie in historischen Produktlogiken auslöst, ist nicht das Geschäft zu komplex, sondern die Struktur.

Die IT bildet ab, sie entscheidet nicht

In solchen Situationen wird schnell die Software infrage gestellt. Doch selten liegt die Ursache im System selbst.

Die IT bildet Entscheidungen ab. Wenn über Jahre hinweg Ausnahmen zugelassen, Definitionen nicht vereinheitlicht und parallel weitergeführt wurden, entsteht zwangsläufig eine fragmentierte Landschaft.

Die entscheidende Frage lautet daher nicht, ob die Leasing-Software leistungsfähig genug ist. Sondern ob die Organisation bereit ist, strukturelle Entscheidungen zu treffen und historische Sonderlogiken zu hinterfragen.

Reduktion bedeutet Führung

Weniger Komplexität bedeutet nicht weniger Marktkompetenz. Eine Leasinggesellschaft kann hoch differenzierte Produkte anbieten und dennoch einen stabilen, konsistenten Datenkern haben.

Entscheidend ist, dass zentrale Begriffe eindeutig definiert und systemweit identisch interpretiert werden. Das ist keine Detailfrage der IT. Es ist eine Entscheidung der Führung. Sie bedeutet, Ausnahmen bewusst zu begrenzen, historische Konstrukte zu bereinigen und neue Produkte nicht nur vertrieblich, sondern auch architektonisch zu denken.

Fazit

Leasing wird immer komplex bleiben.

Die strategische Frage lautet jedoch:

Ist Ihre Komplexität eine notwendige Folge Ihres Geschäftsmodells, oder das Ergebnis historisch gewachsener und nicht harmonisierter Systementscheidungen?

Wenn Sie morgen eine weitere Refinanzierungsbank anbinden oder ein zusätzliches Portfolio strukturieren müssten, würde Ihr System diese Erweiterung tragen?

Oder würde vor allem Ihr interner Abstimmungs- und Erklärungsaufwand wachsen?

DORA-Compliance für Leasinggesellschaften: Was Sie jetzt wissen müssen

Mon, 02 Mar 2026 23:00:00 GMT

DORA in Leasinggesellschaften: Was Compliance wirklich bedeutet

Viele Leasinggesellschaften haben DORA inzwischen umgesetzt. Richtlinien wurden ergänzt, Asset-Listen erstellt und Dienstleisterverträge überprüft. In vielen Häusern wurde dafür ein eigenes Projekt aufgesetzt, häufig begleitet von Beratern, Prüfern oder Kanzleien. Damit ist ein großer Teil der formalen Anforderungen erfüllt.

Das eigentliche Thema beginnt danach. Denn DORA deckt keine neuen Risiken auf, die Verordnung macht bestehende Abhängigkeiten erstmals sichtbar. Viele davon sind nicht gefährlicher als bisher angenommen. Sie sind nur schwerer zu beschreiben und zu überwachen, als lange gedacht. Und genau das ist für viele Leasinggesellschaften die eigentliche Herausforderung.

Die tatsächliche IT-Landschaft ist größer als die offizielle

Eine zentrale Anforderung von DORA ist die vollständige Erfassung aller IT-Systeme und digitalen Prozesse. Die wichtigsten Systeme sind bekannt, Infrastruktur und Anwendungen sind dokumentiert – und viele Unternehmen gehen davon aus, ihre IT-Landschaft grundsätzlich zu überblicken.

Ein erheblicher Teil der operativen Prozesse findet jedoch außerhalb dieser klassischen Systemlandschaft statt.

In vielen Leasinggesellschaften entstehen beispielsweise Restwertkalkulationen oder Refinanzierungsreportings nicht direkt im Kernsystem, sondern in Excel-Modellen oder individuellen Auswertungstools. Daten werden exportiert, weiterverarbeitet und anschließend wieder in andere Systeme zurückgeführt. Solche Lösungen sind über Jahre entstanden und funktionieren im Alltag meist zuverlässig. Gerade deshalb werden sie intern selten als Teil der kritischen IT wahrgenommen.

Unter DORA verändert sich diese Perspektive. Die Verordnung verpflichtet Finanzunternehmen, alle Systeme und Prozesse zu erfassen, die für den laufenden Betrieb wichtig sind, unabhängig davon, ob sie im zentralen System oder in einer Excel-Datei laufen. Sobald ein Prozess geschäftskritische Daten verarbeitet oder operative Entscheidungen beeinflusst, gehört er zur digitalen Infrastruktur eines Unternehmens. Viele Organisationen stellen deshalb im Rahmen der Umsetzung fest, dass ihre tatsächliche IT-Landschaft deutlich größer ist als die offiziell dokumentierte.

Nicht alle Leasinggesellschaften stehen dabei vor demselben Ausgangspunkt. Bankabhängige Gesellschaften können häufig auf bestehende Strukturen der Mutterbank zurückgreifen, stehen jedoch vor der Aufgabe, diese auf die eigenen Anforderungen herunterzubrechen. Bankunabhängige Gesellschaften tragen die Verantwortung vollständig selbst, haben aber oft kleinere Teams und weniger vorgefertigte Strukturen. Die Anforderungen sind dieselben, der Aufwand, sie zu erfüllen, unterscheidet sich erheblich.

Abhängigkeiten von Mutterbanken und Refinanzierungspartnern

Viele Leasinggesellschaften betreiben IT-Systeme, Infrastruktur oder zentrale Plattformen gemeinsam mit der Mutterbank oder sind eng mit Refinanzierungspartnern verbunden. Diese Struktur ist historisch gewachsen und funktioniert im Alltag meist reibungslos.

Regulatorisch stellt sie jedoch konkrete Anforderungen. Art. 28 DORA verlangt, dass Unternehmen für alle externen Anbieter, die wichtige Funktionen übernehmen, klare vertragliche Regelungen vorhalten, darunter Vereinbarungen zu Verfügbarkeit, Wiederherstellung im Störungsfall, Prüfrechten und Ausstiegsstrategien. Dazu gehört auch die Pflicht, ein IKT-Dienstleisterregister zu führen, das alle relevanten Abhängigkeiten vollständig abbildet. Das gilt auch dann, wenn der Anbieter die eigene Mutterbank ist.

Für viele Leasinggesellschaften führt diese Analyse zu einer Erkenntnis, die vorher selten explizit formuliert wurde: Ein Teil der operativen Handlungsfähigkeit hängt von Systemen ab, die außerhalb der eigenen Organisation betrieben werden und für die bislang keine entsprechenden Absicherungen existieren. Solange diese Systeme stabil laufen, bleibt diese Abhängigkeit unsichtbar. Erst die Pflicht zur systematischen Bewertung macht ihre tatsächliche Bedeutung sichtbar.

Regulierung trifft auf die Realität kleiner Organisationen

Große Banken verfügen über spezialisierte Abteilungen für IT-Steuerung, Informationssicherheit und die Überwachung externer Dienstleister. Leasinggesellschaften arbeiten typischerweise mit deutlich kleineren Teams, die gleichzeitig Systeme betreiben, Fachbereiche unterstützen, Projekte begleiten und den operativen Betrieb sichern.

Mit DORA kommen zusätzliche Dauerpflichten hinzu. Risikoeinschätzungen müssen regelmäßig aktualisiert werden, Abläufe für den Störungsfall müssen dokumentiert und regelmäßig erprobt werden, externe Dienstleister müssen laufend beobachtet werden. Die Logik dahinter ist nachvollziehbar.

Wer diese Anforderungen nicht in den normalen Betrieb integriert, führt DORA als dauerhaftes Parallelprojekt. In vielen Organisationen entsteht dadurch eine Situation, in der die Strukturen formal existieren, ihre dauerhafte Umsetzung im Alltag jedoch erheblich anspruchsvoller ist als in der Projektphase angenommen.

Was DORA tatsächlich sichtbar macht

Viele Unternehmen betrachten DORA zunächst als weiteres regulatorisches IT-Projekt. Tatsächlich wirkt die Verordnung anders.

Sie zwingt Organisationen dazu, Fragen zu beantworten, die lange nicht gestellt werden mussten. Welche Systeme sind wirklich geschäftskritisch? Welche Prozesse hängen voneinander ab? Welche externen Partner sind für den laufenden Betrieb unverzichtbar? Gerade in Leasinggesellschaften zeigt sich dabei häufig, wie viele Abläufe auf gewachsenen Strukturen, pragmatischen Lösungen und implizitem Wissen beruhen.

Wie aufwändig die Beantwortung dieser Fragen ist, hängt wesentlich davon ab, wie das zentrale System aufgestellt ist. Kernsysteme, die Datenflüsse nachvollziehbar abbilden und Auswertungen direkt bereitstellen, erleichtern die Dokumentation erheblich. Systemlandschaften mit vielen manuellen Zwischenschritten und externen Verarbeitungsschleifen erzeugen genau jene Abhängigkeiten, die unter DORA den größten Aufwand nach sich ziehen, nicht weil sie gefährlicher wären, sondern weil sie schwerer zu beschreiben und zu überwachen sind. Gesellschaften, die ihr Kernsystem vollständig nutzen, haben bei DORA strukturell weniger Aufwand.

Was das jetzt bedeutet

Für Leasinggesellschaften, die die formale Umsetzungsphase abgeschlossen haben, lassen sich drei konkrete Handlungsfelder benennen:

Asset-Register als Dauerprozess. Die einmalige Erfassung aller Systeme und Prozesse reicht nicht. Entscheidend ist, dass das Register aktuell bleibt, auch wenn neue Tools eingeführt, Schnittstellen verändert oder externe Dienstleister gewechselt werden. Das erfordert einen festen Prozess, keinen einmaligen Projektabschluss.

Drittparteien-Monitoring für kritische Anbieter. Wer wichtige Aufgaben an externe Anbieter oder die Mutterbank ausgelagert hat, braucht eine laufende Überwachung dieser Abhängigkeiten. Das schließt die Frage ein, was im Störungsfall gilt und wie eine geordnete Beendigung der Zusammenarbeit aussehen würde.

IT-Kapazität realistisch einplanen. Die Dauerpflichten aus DORA lassen sich nicht nebenbei erledigen. Wer sie dauerhaft denselben Personen überträgt, die gleichzeitig den laufenden Betrieb verantworten, schafft eine strukturelle Überlastung. Die Frage, wer diese Aufgaben trägt, gehört zur DORA-Umsetzung dazu.