Wenn das neue Leasingprodukt drei Wochen vor Rollout doch noch zurück ins Fachkonzept muss

Der Pricing-Workshop ist gelaufen, die Vertriebspartner sind informiert, der Marketingtext liegt fertig in der Freigabeschleife. Dann meldet sich die Compliance-Abteilung mit einer Frage, die eigentlich schon vor acht Wochen hätte gestellt werden müssen: Wie genau wird das Restwertrisiko bei der neuen Sale-and-Lease-Back-Variante gegenüber dem Refinanzierungspartner ausgewiesen? Die Antwort gibt es nicht, weil im Fachkonzept nur die Kundensicht durchgerechnet wurde, nicht die Meldeanforderung, die der refinanzierende Bankpartner an granulare Objektdaten stellt. IT muss ein Feld nachziehen, das im Kernsystem so nicht vorgesehen war. Der Go-live verschiebt sich um vier Wochen. Niemand hat etwas falsch gemacht, und trotzdem ist genau das passiert, was in Leasinghäusern regelmäßig passiert.

Das Muster: Drei Sprachen, ein Produkt, kein gemeinsamer Startpunkt

Was in Projekten immer wieder zu beobachten ist: Der Fachbereich entwickelt ein Produkt entlang von Marktchancen und Vertragskonditionen. IT bekommt das fertige Konzept als Ticket oder Change Request und baut es in das bestehende System, ob TDS, SAP-Leasing-Module oder ein individuelles Kernbanksystem spielt dabei keine Rolle, das Muster ist dasselbe. Compliance taucht erst auf, wenn ein Freigabeprozess das verlangt, meist kurz vor dem Rollout. Zu diesem Zeitpunkt sind Preismodell, Vertragslogik und Systemarchitektur bereits festgezurrt. Jede Änderung, die jetzt noch kommt, ist kein Feintuning mehr, sondern ein Rückbau.

Konkret wird das bei einem Ratenmodell mit flexibler Anschlussoption: Der Kunde kann am Vertragsende zwischen Rückgabe, Kauf oder Anschlussleasing wählen, ohne sich vorab festzulegen. Aus Vertriebssicht ist das ein Verkaufsargument. Für den Refinanzierungspartner verändert dieselbe Flexibilität das Rating der Forderung, weil der Cashflow am Vertragsende nicht mehr eindeutig prognostizierbar ist, die Bank kann die Forderung nicht mehr wie eine feste Zahlungsreihe bewerten, sondern muss mit einem Szenariokorridor rechnen. Das schlägt sich in höheren Eigenkapitalanforderungen nach CRR nieder, und genau dafür fehlen in vielen Kernsystemen die passenden Datenfelder: eine differenzierte Objektklassifizierung nach Werthaltigkeit und Marktgängigkeit, eine historisierte Restwertprognose über die Laufzeit statt eines einzelnen Werts zum Vertragsstart, sowie ein Feld für die tatsächlich gewählte Ausübung der Option nach Vertragsende. Ohne diese Historie kann der Refinanzierer die Portfolioqualität nicht nachvollziehen und fragt genau danach, wenn das Produkt längst im Preisblatt steht.

Wie stark ein Haus diese fehlende Datentiefe zu spüren bekommt, hängt direkt von seiner Verhandlungsposition gegenüber dem Refinanzierer ab und die wiederum davon, wer überhaupt am Tisch sitzt. Eine Captive-Leasinggesellschaft, die primär die eigene Konzernmutter refinanziert, hat andere Spielräume als ein unabhängiger Leasinggeber, der im Wettbewerb um Refinanzierungslinien bei mehreren Banken steht. Der Captive kann eine fehlende Datenanforderung intern eher nachverhandeln, weil die Refinanzierungsbeziehung nicht im selben Maß austauschbar ist. Der unabhängige Leasinggeber dagegen trägt das Risiko, dass die refinanzierende Bank bei wiederholten Nachforderungen die Konditionen neu bewertet oder die Linie kürzt, hier wiegt dasselbe Strukturproblem ungleich schwerer, weil die Verhandlungsposition von vornherein asymmetrischer ist.

Warum das passiert: Getrennte Budgets, getrennte Kalender, getrennte Erfolgsmaße

Der Grund liegt selten an mangelndem Willen. Er liegt an der Art, wie Verantwortung organisiert ist. Der Fachbereich wird an Time-to-Market gemessen, IT an Release-Stabilität, Compliance an Prüffestigkeit. Diese drei Maßstäbe erzeugen unterschiedliche Zeitlogiken: Der Fachbereich will schnell ins Pricing, IT plant in Sprints und Freigabefenstern, Compliance denkt in Prüfzyklen, die oft quartalsweise getaktet sind. Wenn keine Instanz existiert, die diese drei Kalender synchronisiert, entsteht automatisch die Reihenfolge „erst Konzept, dann Bau, dann Prüfung", obwohl gerade bei refinanzierungsrelevanten Produkten alle drei Sichten von Anfang an denselben Sachverhalt beschreiben müssten: dasselbe Objekt, dieselbe Forderung, denselben Vertrag.

Dasselbe Muster zeigt sich, wenn man den Blick vom Mobilienleasing auf die Konsumentenfinanzierung richtet. Ein Anbieter führt eine flexible Ratenpause ein, die Kunden bei finanziellen Engpässen einmal pro Vertragsjahr ziehen können. Der Fachbereich kalkuliert das als Kundenbindungsinstrument. Erst spät stellt sich heraus, dass jede gezogene Ratenpause nach den Meldevorgaben der refinanzierenden Bank als Stundung erfasst und einzeln nachgewiesen werden muss, eine Anforderung, die in der ursprünglichen Produktkalkulation nicht vorkam. Das Produkt ist ein anderes, das Strukturproblem ist identisch: Eine vertriebsgetriebene Flexibilität trifft auf eine Meldeanforderung, die niemand vorab mitgedacht hat.

Hinzu kommt ein Vokabularproblem, das in Leasinghäusern besonders ausgeprägt ist. Der Fachbereich spricht über „Restwertkorridore" und „Anschlussoptionen". IT übersetzt das in Datenfelder und Schnittstellen zum Refinanzierer, Compliance übersetzt dieselbe Anschlussoption in ein Bonitäts- und Meldewesenrisiko. Damit entstehen drei Beschreibungen desselben Produkts. Sie laufen nie in einem gemeinsamen Dokument zusammen, sondern erst im Kopf einer einzelnen Person, meist kurz vor der Deadline, wenn es zu spät ist, um noch etwas zu ändern, ohne den Termin zu gefährden.

Der blinde Fleck: Mehr Meetings lösen das Problem nicht

Die naheliegende Reaktion auf dieses Muster ist der Ruf nach „besserer Abstimmung" oder einem zusätzlichen Jour Fixe. Das greift zu kurz. Ein weiterer wöchentlicher Termin ändert nichts daran, dass die drei Bereiche mit unterschiedlichen Artefakten arbeiten - Fachkonzept, Datenmodell, Prüfkatalog - die inhaltlich nie deckungsgleich sind. Man kann sich stundenlang in einem Meeting abstimmen und trotzdem aneinander vorbeireden, weil jeder aus seinem Dokument berichtet, nicht aus einem gemeinsamen.

Das eigentliche Defizit ist nicht Kommunikationsfrequenz, sondern das Fehlen gemeinsamer Entscheidungspunkte, an denen alle drei Sichten zwingend zusammenlaufen müssen, bevor eine Festlegung getroffen wird, die später teuer zu ändern ist. Bei einem neuen Leasingprodukt mit Refinanzierungsbezug ist das konkret: bevor das Pricing final steht, bevor die Systemparametrierung beginnt, bevor der Refinanzierungsvertrag mit der Bank unterschrieben wird.

Die These: Compliance und IT sind Mitgestalter der Produktlogik, nicht Abnahmeinstanzen am Ende

Ein Leasingprodukt mit Refinanzierungsbezug ist von der ersten Kalkulation an ein Datenobjekt, ein Risikoobjekt und ein Meldeobjekt gleichzeitig. Wer Compliance und IT erst einbindet, wenn das Konzept steht, behandelt sie wie eine Prüfstelle, dabei sind sie an dieser Stelle Mitautoren der Produktlogik. Diese Verschiebung ist keine Frage von Soft Skills oder Unternehmenskultur, sondern eine Frage der Projektarchitektur: Wer entscheidet wann, mit wem, auf Basis welcher gemeinsamen Faktenlage?

Konsequenz für die Praxis: Ein gemeinsamer Entscheidungspunkt vor dem Freeze

Praktisch bedeutet das: Vor der Preisfreigabe eines neuen Produkts braucht es einen fixen, verpflichtenden Termin, an dem Fachbereich, IT und Compliance gemeinsam auf dieselbe Frage schauen, nicht auf drei getrennte Fragen. Dieser Termin ist kein Ersatz für die üblichen Freigabeschritte, sondern eine vorgelagerte Prüfung, die mindestens drei Punkte verbindlich klären muss, bevor der Pricing-Freeze gesetzt wird:

Erstens, ist die Meldeanforderung des Refinanzierungspartners für dieses konkrete Produkt bekannt und schriftlich dokumentiert, nicht als allgemeine Regulatorik, sondern als konkrete Feldliste, die die Bank für dieses Vertragsmodell verlangt. Zweitens, kann das Kernsystem die geforderte Objektgranularität tatsächlich abbilden, oder erfordert das Produkt eine Erweiterung, die vor dem Rollout eingeplant werden muss, statt danach als Notfall-Change zu laufen. Drittens, ist ein Verantwortlicher benannt, der die Übergabe zwischen Fachkonzept, Systemumsetzung und Compliance-Prüfung aktiv steuert, nicht nur informiert wird, wenn eine der drei Seiten fertig ist. Fehlt auch nur einer dieser drei Punkte, ist der Freeze verfrüht, selbst wenn Vertrieb und Pricing längst startklar sind.

Dieses Übersetzungsproblem zwischen Fachkonzept, Datenmodell und Prüfkatalog ist am Ende kein reines Abstimmungsthema, sondern auch ein Architekturthema. Ein zuverlässiges Erkennungsmerkmal für diesen Silo-Zustand: Wenn eine Restwertanpassung heute manuell in zwei oder drei Systemen nachgezogen werden muss, einmal im Vertragssystem, einmal in der Meldeplattform für den Refinanzierer, gegebenenfalls noch in einem separaten Risiko-Tool, arbeitet die Organisation faktisch mit Silos, unabhängig davon, was auf dem Organigramm steht. Wenn ein Kernsystem Objektdaten, Restwertprognosen und Meldefelder in getrennten Modulen oder gar getrennten Systemen führt, die nur über nächtliche Batch-Läufe oder manuelle Exporte synchronisiert werden, wird jede Änderung an der Produktlogik automatisch zu einem mehrstufigen technischen Eingriff. Das kostet nicht nur Zeit, sondern erzeugt genau die Verzögerungen kurz vor Rollout, die als Compliance-Problem wahrgenommen werden, obwohl ihr Ursprung in der Systemarchitektur liegt. Systeme, die Objekt-, Vertrags- und Meldedaten in einem gemeinsamen, konsistenten Datenmodell abbilden, verkürzen diesen Weg nicht, weil sie „moderner" sind, sondern weil eine Änderung an einer Stelle automatisch sichtbar wird, wo sie auch systemseitig etwas kostet. Das ist kein Plädoyer für ein bestimmtes Produkt, sondern eine Beobachtung: Je stärker Fachlogik und Systemarchitektur in getrennten Silos leben, desto später merkt eine Organisation, dass eine fachliche Entscheidung eine technische Konsequenz hat.

Wer trägt die Verantwortung für die Übergänge?

Die meisten Häuser haben einen klaren Produktverantwortlichen im Fachbereich, einen klaren Systemverantwortlichen in der IT und einen klaren Freigabeverantwortlichen in der Compliance. Was in den seltensten Fällen klar geregelt ist: Wer verantwortet die Übergänge zwischen diesen drei Rollen? Genau an diesen Übergängen entstehen die Verzögerungen, die am Ende alle drei Seiten als „die Schuld der anderen Abteilung" verbuchen.

Die konsequente Antwort darauf ist keine weitere Prozessvorschrift, sondern eine eigene Rolle: ein Produkt-Owner Refinanzierungsschnittstelle, der weder dem Fachbereich noch der IT noch der Compliance allein zugeordnet ist, sondern explizit für die drei genannten Mindestkriterien vor jedem Pricing-Freeze geradesteht. Diese Person muss keine zusätzliche Hierarchieebene sein, sie kann aus einem der drei Bereiche kommen, solange ihr Mandat über den eigenen Bereich hinausreicht. Entscheidend ist, dass dieses Mandat mit einer echten Eskalationsbefugnis hinterlegt ist: Wenn einer der drei Mindestpunkte kurz vor dem geplanten Freeze nicht geklärt ist, muss diese Person den Freeze verschieben können, ohne dafür erst eine Instanz oberhalb von Fachbereich, IT und Compliance einschalten zu müssen. Ohne diese explizite Zuständigkeit und die Befugnis, sie auch durchzusetzen, bleibt die Frage, wer für die Übergänge sorgt, im Zweifel unbeantwortet und die nächste Compliance-Überraschung drei Wochen vor Rollout ist keine Frage des Ob, sondern des Wann.