Vertical CDP für Banken: Warum generische CDPs zu kurz greifen

Vertical CDP für Banken: Warum generische CDPs zu kurz greifen

Customer Data Platforms sind seit Jahren fester Bestandteil der Marketing-Stacks im E-Commerce und Retail. Viele Banken haben in den letzten Jahren versucht, diese generischen CDPs eins zu eins auf das eigene Geschäft zu übertragen – und stoßen dabei auf strukturelle Grenzen, die selten im Pflichtenheft, aber fast immer im Livebetrieb sichtbar werden.

Das Datenmodell ist das eigentliche Problem

Generische CDPs sind für Web- und App-Events optimiert: Seitenaufrufe, Klicks, Warenkorbabbrüche, E-Mail-Öffnungen. Banken arbeiten jedoch mit fundamental anderen Datentypen – Kontosalden, Transaktionsströme, Vertragslaufzeiten, Bonitätsscores, regulatorische Klassifizierungen wie KYC-Status oder Risikoeinstufung. Ein generisches CDP-Schema muss für diese Datentypen künstlich erweitert werden, was in der Praxis zu individuellen Datenmodellen führt, die sich kaum standardisiert pflegen oder migrieren lassen. Projektteams berichten häufig, dass 40 bis 60 Prozent des Implementierungsaufwands allein in dieses Nachrüsten des Datenmodells fließen, statt in tatsächliche Anwendungsfälle.

Ein vertikales CDP für Banking bringt dieses Datenmodell von Anfang an mit: Konten, Produkte, Transaktionskategorien, Vertragsstatus und regulatorische Attribute sind native Objekte, keine nachträglichen Custom-Felder.

Echtzeitfähigkeit bei Transaktionsdaten

Der zweite strukturelle Unterschied liegt in der Verarbeitungsgeschwindigkeit. E-Commerce-CDPs sind meist auf Verarbeitungsfenster von Minuten bis Stunden ausgelegt – für einen Warenkorbabbruch ist das ausreichend. Für eine Betrugsprävention oder eine Reaktion auf eine ungewöhnliche Kontobewegung sind Minuten bereits zu langsam. Ein vertikales CDP für Banken ist auf Latenzen im Sekundenbereich für kritische Trigger ausgelegt und kann Transaktionsströme direkt aus Kernbanksystemen oder Kartennetzwerken verarbeiten, statt auf einen ETL-Batch zu warten.

In der Praxis bedeutet das den Unterschied zwischen einer Betrugswarnung, die den Kunden erreicht, bevor der zweite unautorisierte Vorgang durchgeführt wird, und einer Meldung, die erst am nächsten Morgen im Postfach landet.

Regulatorik als eingebautes Feature, nicht als Add-on

Generische CDPs behandeln Datenschutz meist über generische Consent-Layer, die für Marketing-Zwecke ausreichen, aber die spezifischen Anforderungen von GDPR im Finanzsektor, BaFin-Vorgaben zur Auslagerung und Datenverarbeitung sowie DORA-Resilienzanforderungen nicht abdecken. Banken müssen diese Lücken dann individuell schließen – oft über zusätzliche Compliance-Schichten, die die Systemkomplexität erhöhen und die Time-to-Market deutlich verlangsamen.

Ein für Banking entwickeltes CDP bringt granulare Einwilligungssteuerung pro Zweck, vollständige Nachvollziehbarkeit von Datenflüssen für Aufsichtsbehörden und die Option auf private Cloud- oder On-Premise-Betrieb von Grund auf mit. Das reduziert nicht nur das Compliance-Risiko, sondern verkürzt auch Freigabeprozesse mit internen Datenschutz- und Risikoabteilungen, die bei generischen Lösungen häufig sechs bis zwölf Monate zusätzliche Prüfzeit beanspruchen.

Anwendungsfälle, die generische CDPs kaum abbilden

Drei Beispiele verdeutlichen den Unterschied. Erstens: Next-Best-Action-Empfehlungen, die auf Bonitäts- und Risikoscores basieren – ein generisches CDP kennt diese Scores schlicht nicht als Objekttyp. Zweitens: Trigger-Automatisierung aus Transaktionsmustern, etwa eine Kampagne, die ausgelöst wird, wenn ein Kunde drei Monate in Folge sein Dispolimit überschreitet – das erfordert native Transaktionsverarbeitung, nicht nachträgliche Integration. Drittens: Lifecycle-Kampagnen über Produktgrenzen hinweg, etwa vom Girokonto über die Kreditkarte bis zur Baufinanzierung, die ein konsistentes 360-Grad-Kundenbild über alle Bankprodukte voraussetzen.

Was das für die Anbieterauswahl bedeutet

Für Entscheider in Banken, Versicherungen und bei Kartenemittenten lohnt sich eine klare Kosten-Nutzen-Rechnung: Ein generisches CDP ist in der Lizenz oft günstiger, verursacht aber durch Anpassungsaufwand, verlängerte Compliance-Zyklen und begrenzte Echtzeitfähigkeit versteckte Folgekosten, die sich über 24 bis 36 Monate häufig auf das Zwei- bis Dreifache der ursprünglichen Lizenzkosten summieren. Ein vertikales CDP, das für Finanzdienstleister konzipiert wurde, verursacht höhere initiale Lizenzkosten, verkürzt aber Time-to-Value häufig auf drei bis sechs Monate für die ersten produktiven Anwendungsfälle.

Die Entscheidung zwischen generischem und vertikalem CDP ist damit weniger eine Frage der Funktionsliste, sondern eine Frage, wie viel institutionelles Risiko und Implementierungsaufwand eine Bank bereit ist zu tragen, um eine im Kern branchenfremde Plattform passend zu machen.

Migrationsaufwand als versteckter Kostenfaktor

Ein Aspekt, der in der initialen Business-Case-Rechnung häufig fehlt, ist der Migrationsaufwand, falls sich ein generisches CDP nach zwei oder drei Jahren als unzureichend erweist. Da Kundendaten, Segmentlogiken und Kampagnenhistorie tief in der ursprünglichen Plattform verankert sind, ist ein Wechsel zu einem vertikalen System kein einfacher Datenexport, sondern ein Projekt, das oft ein weiteres Jahr Implementierungszeit und parallele Betriebskosten für beide Systeme erfordert. Institute, die diese Migrationsgefahr von Anfang an einpreisen, entscheiden sich in der Praxis häufiger direkt für eine vertikale Lösung, selbst wenn die initialen Lizenzkosten höher liegen.

Team-Kompetenzen als weiterer Unterschied

Schließlich unterscheiden sich generische und vertikale CDPs auch in den benötigten Team-Kompetenzen. Ein generisches CDP erfordert meist ein internes Team, das branchenspezifische Logik – etwa Bonitätsscoring oder regulatorische Kategorisierung – selbst nachbaut und pflegt. Ein vertikales CDP bringt diese Logik als Teil des Produkts mit, sodass sich interne Teams auf die eigentliche Kampagnensteuerung und Analyse konzentrieren können, statt Grundlagenarbeit an der Dateninfrastruktur zu leisten. Banken berichten in diesem Zusammenhang von einer deutlich geringeren Abhängigkeit von spezialisierten Data-Engineering-Ressourcen, was insbesondere für mittelgroße Institute mit begrenzten internen IT-Kapazitäten ein entscheidender Faktor ist.