Regulatorische Anforderungen in Leasinggesellschaften: Warum Compliance an Strukturen scheitert, nicht an Gesetzen

Der Anruf kommt meist vier Wochen vor dem Stichtag. Die Compliance-Abteilung hat festgestellt, dass die neuen EBA-Anforderungen an die Kreditwürdigkeitsprüfung auch für Leasingverträge gelten und fragt jetzt beim IT-Dienstleister an, ob das System das abbilden kann. Der IT-Dienstleister fragt zurück, welche Datenfelder genau befüllt werden müssen. Compliance verweist auf den Gesetzestext. Der Marktbereich hat davon noch nichts gehört und fragt, ob das die Abschlussquote beeinflusst. Drei Abteilungen, eine Anforderung und kein gemeinsames Verständnis davon, was sie eigentlich bedeutet. Das ist kein Einzelfall, der unter Zeitdruck entstand, sondern ein Standardmuster.

Das Problem hat einen Namen, aber keine Adresse

In Projekten zur regulatorischen Umsetzung, ob EBA-Leitlinien zur Kreditvergabe, GwG-Novellen oder BAIT- und MaRisk-Anforderungen, es zeigt sich immer wieder dasselbe Bild: Die Anforderung ist bekannt, dokumentiert, irgendwo abgelegt. Und trotzdem fehlt zum Zeitpunkt der Umsetzung das gemeinsame Verständnis darüber, wen sie eigentlich betrifft und was sie operativ bedeutet.

Das liegt nicht an mangelnder Fachkompetenz. Compliance-Experten in Leasinggesellschaften kennen die einschlägigen Regelwerke. IT-Abteilungen können Systeme anpassen. Marktbereiche können Prozesse ändern. Das Problem liegt dazwischen: Keine dieser Einheiten hat einen vollständigen Blick auf den gesamten Umsetzungspfad. Und keine fühlt sich für den Teil zuständig, der in der Lücke zwischen zwei Abteilungen liegt.

In Projekten zur Umsetzung der EBA-Leitlinien zur Kreditvergabe zeigte sich wiederholt, dass die Anforderungen an die Kreditdokumentation nicht nur als Compliance-Thema verstanden wurden, sondern spät, als Eingriff in die Systemarchitektur der Vertragserfassung. Das Ergebnis war regelmäßig dasselbe: Anpassungen unter Zeitdruck, manuelle Zwischenlösungen mit ungeplantem Bestandscharakter und Prüfungsfeststellungen, die bei früherem Vorlauf vermeidbar gewesen wären.

Für Refinanzierungsbanken mit Leasing-Portfolio kommt eine weitere Dimension hinzu. Unter DORA müssen sie nicht nur eigene IT-Systeme bewerten, sondern auch Drittparteienrisiken aus dem Leasing-Portfolio, inklusive der dort eingesetzten Systemdienstleister, in die eigene Risikoberichterstattung einbeziehen. Gleichzeitig steigen die Anforderungen an die Granularität von Meldedaten auf Vertragsebene. Wer diese Daten nicht sauber im System führt, kann sie weder intern steuern noch gegenüber dem Refinanzierungsgeber fristgerecht bereitstellen. Das ist kein Reporting-Problem, es entsteht im Datenmodell, lange vor dem ersten Meldetermin.

Warum Silos bei DORA- und EBA-Projekten in Leasinggesellschaften besonders teuer werden

In Leasinggesellschaften ist die organisatorische Trennung zwischen Markt, Kredit, Compliance und IT historisch gewachsen und in vielen Bereichen funktional sinnvoll. Bei regulatorischen Projekten wird sie zum strukturellen Risiko.

Der Grund ist die Art, wie Regulatorik formuliert ist. Gesetze und Leitlinien beschreiben Zielzustände, keine Prozesse. Wer die EBA-Leitlinien zur Kreditvergabe liest, erfährt, welche Informationen zur Kreditwürdigkeitsprüfung vorliegen müssen, nicht, in welchem System sie gespeichert werden, wer sie erhebt, wann im Antragsprozess das passiert und wie sie in der Refinanzierungsmeldung auftauchen. Diese Übersetzungsleistung, von der regulatorischen Anforderung in den operativen Prozess, ist die eigentliche Umsetzungsarbeit. Und sie kann nur funktionieren, wenn Compliance, IT und Markt sie gemeinsam erbringen.

Was stattdessen häufig passiert: Compliance übersetzt die Anforderung in eine interne Richtlinie. Die Richtlinie landet beim IT-Projektteam als Anforderungsdokument. Das IT-Team setzt um, was beschrieben ist, ohne zu wissen, was im Marktprozess tatsächlich passiert. Der Marktbereich erfährt von der Änderung beim Go-Live. Dann beginnen die Anpassungsschleifen.

Wenn der Steuerungskreis das Problem verwaltet statt löst

Die übliche Reaktion auf dieses Problem ist ein Steuerungskreis. Monatliche Meetings, in denen Vertreter aller Bereiche zusammenkommen und Statusberichte austauschen. Das löst das Silo-Problem nicht, es moderiert es.

Was in diesen Gremien fehlt, ist eine gemeinsame Arbeitsebene. Nicht ein Statusmeeting, in dem Compliance berichtet und IT zuhört, sondern eine gemeinsame Analyse: Welche Datenobjekte sind betroffen? Wo entstehen sie im Prozess? Wer trägt sie fort? Was bedeutet die Anforderung für die Produktgestaltung im Flottenleasing, wo Rahmenverträge und Einzelverträge unterschiedlich behandelt werden müssen?

Ein Muster, das sich in ähnlicher Form wiederholt: Eine Leasinggesellschaft führt im Zuge einer GwG-Novelle neue KYC-Pflichten für gewerbliche Kunden ein. Compliance definiert den Prozess, IT setzt ihn systemseitig um. Beim Go-Live stellt sich heraus, dass der Außendienst seit Jahren eine abweichende Praxis beim Erstkontakt nutzt, die nicht dokumentiert, aber etabliert sind. Die neuen Systemmasken passen nicht zur gelebten Realität. Der Marktbereich war im gesamten Projektverlauf nicht eingebunden.

Was das für die Praxis bedeutet

Der Marktbereich muss früher einbezogen werden, als es intuitiv erscheint, nicht weil er Regulatorik mitentscheiden soll, sondern weil er die einzige Einheit ist, die weiß, wie ein Prozess tatsächlich gelebt wird. Bei AML-Anforderungen im gewerblichen Leasing ist der Unterschied zwischen dokumentiertem Onboarding-Prozess und tatsächlichem Ablauf im Außendienst oft erheblich. Compliance-Anforderungen, die auf den dokumentierten Prozess aufsetzen, lösen das Problem nicht.

Das Format, das in der Praxis funktioniert, ist kein weiterer Steuerungskreis. Es ist ein strukturierter Regulatory-Impact-Workshop: zwei bis drei Tage, Compliance, IT-Architektur und Marktverantwortliche gemeinsam am Tisch. Das Ergebnis ist keine Präsentation, sondern drei konkrete Artefakte:

1. Prozesslandkarte der betroffenen Abläufe, mit expliziter Markierung der Übergabepunkte zwischen Abteilungen

2. Datenfeld-Liste der regulatorisch relevanten Felder, mit Systemverantwortlichkeit und Erhebungszeitpunkt im Antragsdurchlauf

3. Abhängigkeitsübersicht offener Klärungsbedarfe zwischen Abteilungen, priorisiert nach Umsetzungsrisiko

Wer diese drei Dokumente vor dem ersten Projektplan hat, reduziert Nacharbeitsschleifen messbar. Wer sie nicht hat, entdeckt die offenen Fragen spätestens beim Go-Live.

Was Systemarchitektur hier leisten kann und was nicht

Organisatorische Koordination ist die Voraussetzung. Aber das System entscheidet, ob die nächste Anforderung wieder von vorne anfängt.

Ein flexibles Datenmodell, das regulatorische Felder ohne Anpassung am Kernsystem ergänzen kann, ist dabei keine Komfortfunktion, sondern eine Grundvoraussetzung. Wer für jedes neue Pflichtfeld ein Datenbankprojekt benötigt, verliert nicht nur Zeit, er verliert die Fähigkeit, auf veränderte Anforderungen überhaupt noch reaktionsfähig zu bleiben. Gleiches gilt für rollenbasierte Zugriffssteuerung: Wenn Compliance, Markt und IT denselben Datensatz sehen, aber unterschiedliche Bearbeitungsrechte benötigen, muss das System das abbilden können, ohne manuelle Workarounds, die bei der nächsten Prüfung zum Befund werden.

Ein lückenloser Audit-Trail für die Kreditdokumentation ist kein Nice-to-have für den Prüfungsfall. Er ist der Nachweis, dass ein Prozess tatsächlich so abläuft, wie er dokumentiert ist, der Unterschied, der in den meisten GwG- und EBA-Prüfungen zwischen Feststellung und Nichtbeanstandung entscheidet. Konfigurierbare Prozessschritte im Antragsdurchlauf schließlich ermöglichen es, neue regulatorische Prüfpunkte einzubauen, ohne den gesamten Workflow neu zu entwickeln.

Kein externer Berater kann das organisatorische Koordinationsproblem dauerhaft lösen, aber ein technologischer Partner kann sicherstellen, dass das System die nächste regulatorische Anforderung nicht von vorne erzwingt. Der Unterschied liegt darin, ob Architekturentscheidungen in der Vergangenheit Flexibilität eingeplant haben oder nicht.

Ob weitere EBA-Anpassungen, DORA-Implementierungsdetails, neue GwG-Pflichten oder BAIT- und MaRisk-Anforderungen – der Rhythmus regulatorischer Anforderungen hat sich beschleunigt. Die relevante Frage ist nicht, ob man fachlich vorbereitet ist. Sondern ob Compliance, IT und Markt die nächste Anforderung gemeinsam lesen können und ob das System danach folgen kann, ohne wieder von vorne anzufangen.