CLM-Software für Banken: kaufen, bauen oder erweitern?

CLM-Software für Banken lässt sich kaufen, bauen oder erweitern — und die Entscheidung wird in vielen Häusern falsch getroffen, weil sie als reine Kostenfrage statt als Risikofrage behandelt wird. Dieser Beitrag ist Teil 2 unserer Mini-Serie zu Customer Lifecycle Management für Banken und liefert den Entscheidungsrahmen: welche Option in welcher Situation trägt, was Eigenentwicklungen historisch tatsächlich kosten, und welche regulatorischen Vorgaben eine Kaufentscheidung ohnehin einrahmen.

Customer Lifecycle Management für Banken: Build, Buy oder Extend im Überblick

Bei Customer Lifecycle Management-Software für Banken stehen grundsätzlich drei Wege offen: vollständige Eigenentwicklung (Build), der Kauf einer marktfertigen Plattform (Buy) oder eine hybride Lösung, bei der Commodity-Funktionen gekauft und Differenzierungsschichten selbst gebaut werden (Extend). Deloitte fasst die Trade-offs so zusammen: „Buy" liefert die Mehrzahl der benötigten Fähigkeiten schneller und mit Vendor-Expertise, bringt aber Vendor-Lock-in, begrenzte Kontrolle und Innovationsrestriktionen mit sich; „Build" gibt volle Kontrolle, erzeugt aber Zusatzkomplexität, höhere Kosten und ein höheres Design-, Build- und Maintain-Risiko. Keine Option allein liefert alle gewünschten Ergebnisse — ein balancierter Hybrid wird empfohlen (Deloitte UK, „The new blueprint for digital banking").

Der von FIS beschriebene „Sweet Spot" konkretisiert diesen Hybrid: 70–80 % der benötigten Funktionen kaufen — Commodity-Funktionen, Compliance-Bausteine — und nur die Differenzierungsschichten wie Scoring- oder Pricing-Logik selbst bauen (FIS, „Modernizing asset finance: The build vs. buy decision", 2025). Für CLM-Plattformen im Banking bedeutet das konkret: Data Governance, Consent-Management, Kernbanksystem-Konnektoren und regulatorisches Reporting sind Commodity — hier lohnt sich Eigenentwicklung fast nie. Die eigentliche Orchestrierungslogik und die Feinjustierung der Scoring-Modelle können dagegen differenzierend sein.

Was Eigenentwicklungen historisch tatsächlich kosten

Die Datenlage zu Build-Risiken ist deutlich robuster, als viele Entscheider annehmen. Eine Analyse von über 5.400 IT-Projekten mit Budgets über 15 Mio. US-Dollar zeigt: Projekte lagen im Schnitt 45 % über Budget, 7 % über Zeitplan und lieferten 56 % weniger Wert als geplant (McKinsey mit dem BT Centre for Major Programme Management der University of Oxford, Oktober 2012). 17 % der untersuchten Großprojekte gelten sogar als „Black Swans" mit 200–400 % Budgetüberschreitung, die die Existenz des Unternehmens bedrohen können — Softwareprojekte tragen dabei das höchste Risiko (McKinsey 2012). Besonders relevant für mehrjährige CLM-Eigenentwicklungen: Jedes zusätzliche Projektjahr erhöht die Kostenüberschreitung um 15 % (McKinsey 2012).

Zwei konkrete Bankenbeispiele aus derselben Studie illustrieren das Risiko: Ein Data-Warehouse-Projekt einer Bank wurde nach 18 Monaten und rund 10 Mio. US-Dollar abgebrochen; in einem anderen Fall verzögerte die zu späte Einbindung der Finance-Abteilung den Go-live um über drei Monate und kostete mehr als 8 Mio. US-Dollar (McKinsey 2012). Der Standish Group CHAOS Report bestätigt das Muster größenabhängig: Große Projekte erreichen nur 11 % Erfolgsquote (59 % „challenged", 30 % gescheitert), kleine Projekte dagegen 61 % Erfolg — Basis sind über 25.000 Projekte aus den Jahren 2011–2015 (CHAOS Report 2015). Agiles Vorgehen verbessert die Quote deutlich, hebt sie aber nicht auf: Agile Projekte erreichen 39 % Erfolg gegenüber 11 % bei Wasserfall, bei Großprojekten 18 % gegenüber 3 % — Wasserfall-Großprojekte scheitern zu 42 % vollständig (CHAOS Report 2015). FIS bringt es unter Berufung auf McKinsey auf den Punkt: „Zwei von drei großen Technologieprogrammen überschreiten regelmäßig ihr ursprüngliches Budget, verfehlen Zeitpläne und liefern die erwarteten Geschäftsziele nicht vollständig" (FIS 2025).

Time-to-Value: der oft unterschätzte Faktor

Neben dem Ausfallrisiko spricht auch die Geschwindigkeit klar für gekaufte oder hybride Lösungen. Unternehmen, die Time-to-Market über perfekte Individualisierung stellen, erzielen über Vendor-Partnerschaften einen 2,3-mal schnelleren ROI, zitiert nach Deloitte (FIS 2025). Vorgefertigte SaaS-Plattformen erreichen laut demselben Papier ROI innerhalb von 3–6 Monaten (FIS 2025). Auch die Integrationsgeschwindigkeit hat sich strukturell verändert: Mit modernen gekauften Kernplattformen und offenen APIs sank die Partner-Onboarding-Zeit von 9 Monaten auf 6 Wochen (FIS 2025).

Für Banken kommt eine strukturelle Budgetrestriktion hinzu: Bis zu 70 % der Technologiebudgets entfallen auf Pflicht-Wartung und Compliance („Run the bank") — Kapazität für mehrjährige Eigenentwicklung ist damit faktisch begrenzt, während die globalen Technologieausgaben im Banking um durchschnittlich 9 % p. a. auf 650 Mrd. US-Dollar im Jahr 2023 stiegen (FIS 2025). Wer trotzdem baut, konkurriert also um ein schrumpfendes Restbudget.

Das oft unterschätzte Buy-Risiko: Kopplung statt Modularität

Kaufentscheidungen sind aber kein Selbstläufer. Deloitte benennt ein Risiko, das in Vendor-Auswahlprozessen häufig übersehen wird: Plattformanbieter designen ihre Systeme oft für maximale Feature-Nutzung, was zu unbeabsichtigter Kopplung und reduzierter Modularität führt (Deloitte UK). Wer eine CLM-Plattform kauft, sollte deshalb explizit prüfen, wie leicht sich einzelne Module — etwa das Prediction-Modell oder der Orchestrierungslayer — austauschen lassen, ohne das Gesamtsystem zu gefährden. Wie sich Systeme ohne Migrationsrisiko integrieren lassen, vertieft unser Beitrag zur nahtlosen Integration ohne Rip-and-Replace.

Die regulatorische Nebenbedingung, die die Entscheidung einrahmt

In der EU ist die Buy-Entscheidung ohnehin nicht frei — sie ist an Prüfpflichten gebunden. Vor Vertragsabschluss müssen Institute bewerten, ob eine kritische oder wichtige Funktion betroffen ist, die aufsichtsrechtlichen Voraussetzungen prüfen, alle Risiken identifizieren, eine Due Diligence des Dienstleisters durchführen und Interessenkonflikte bewerten (Rn. 61 der EBA-Leitlinien, anwendbar seit 30. September 2019) (EBA Guidelines on outsourcing arrangements, EBA/GL/2019/02). Für kritische oder wichtige Funktionen verlangen die Leitlinien zusätzlich eine dokumentierte Exit-Strategie (Rn. 106), uneingeschränkte Prüf- und Audit-Rechte für Institut und Aufsicht (Rn. 87) sowie eine Substituierbarkeits-Bewertung mit Angabe alternativer Dienstleister und geschätzter jährlicher Budgetkosten im Auslagerungsregister (Rn. 55) (EBA/GL/2019/02). Diese Anforderungen sprechen im Kern für Anbieter, die Datenhoheit, Auditierbarkeit und Wechselbarkeit von Haus aus mitdenken, statt sie nachträglich aufzusetzen.

Wie Acceleraid den Extend-Ansatz konkret umsetzt

Acceleraid positioniert sich explizit im Extend-Segment: Die Plattform liefert CDP & Data Governance, Prediction Engine, CLM/CVM-Orchestrierung, Experience Optimisation und Regulatory Reporting als gekaufte Basis — inklusive deutschem Hosting und GDPR-by-design — während das KI-Modell selbst jederzeit wechselbar bleibt und Wissen, Kontexte und Konfigurationen dabei erhalten bleiben (Acceleraid Platform). Für Banken ist das GenAI & LLM Enablement-Modul mit PII-Filterung live in 8 Wochen einsetzbar — ein konkreter Time-to-Value-Beleg für den Buy/Extend-Ansatz im eigenen Produkt (Acceleraid Banking). Über 250 Enterprise-Deployments und ROI in typischerweise 6–9 Monaten stützen die These, dass der Sweet-Spot-Ansatz aus Kauf plus gezielter Erweiterung in der Praxis funktioniert (Acceleraid Platform).

Fazit: Customer Lifecycle Management für Banken braucht keine Build-or-Buy-Ideologie

Die Datenlage ist eindeutig: Eigenentwicklung von CLM-Software trägt ein empirisch hohes Scheiterrisiko, während gekaufte oder hybride Lösungen schneller Wert liefern und regulatorische Anforderungen leichter erfüllen. Die eigentliche Entscheidung liegt nicht zwischen Build und Buy, sondern darin, wo genau die Grenze zwischen Commodity-Funktion und Differenzierungsschicht gezogen wird. Wie sich diese Entscheidung anschließend organisatorisch in Teams, Prozessen und Governance verankert, behandelt der letzte Teil dieser Mini-Serie zum Operating Model.

Illustration: KI-generiert. KI-gestützte Inhalte: Bei der Erstellung unserer Beiträge setzen wir KI-Technologien und automatisierte Agenten ein, unter anderem von Microsoft, Google, OpenAI, Anthropic und weiteren Anbietern. Themen, fachliche Ausrichtung und finale Freigabe liegen bei unserem Team.