Data & Technology

Customer Data Platform für Finanzdienstleister: Der Leitfaden 2026

Customer Data Platform für Finanzdienstleister: Definition, Architektur, Aufsichtsrecht und Abgrenzung zu DWH und CRM im Überblick.

acceleraid Redaktion

5 Min. Lesezeit

Customer Lifecycle Management

Customer Lifecycle Management

Customer Lifecycle Management

01

Acquire

Signale erkennen

02

Onboard

Aktivierung steuern

03

Grow

Next Best Action

04

Retain

Churn reduzieren

05

Reactivate

Potenziale zurückholen

Daten → KI-Score → Trigger → Kanal → Feedback

Daten → KI-Score → Trigger → Kanal → Feedback

Abstrakte Visualisierung einer Customer Data Platform im Bankenumfeld

Dieser Beitrag eröffnet eine neue Serie zu Customer Data Platforms im Finanzsektor. Teil 2 beschäftigt sich mit Auswahlkriterien und RFP-Fragen, Teil 3 mit Kosten und Business Case. Wer bereits mit Next-Best-Action-Logik arbeitet, findet ergänzend unsere Serie zur Next Best Action im Banking.

Eine Customer Data Platform für Finanzdienstleister ist mehr als ein weiteres Datentool im Marketing-Stack — sie ist die Voraussetzung dafür, dass Banken und Versicherer Kundendaten überhaupt in Echtzeit, konsistent und regelkonform nutzen können. Nach der Definition des CDP Institute ist eine CDP „software that creates and maintains a persistent, unified customer record that is accessible to other systems" und übernimmt die primäre Verantwortung dafür, Kundenidentität und Datenstruktur über die Zeit zu pflegen (CDP Institute). Für Finanzdienstleister kommt eine zusätzliche Anforderungsebene hinzu: Aufsichtsrecht, Datenresidenz und die Integration mit Kernbanksystemen, die in anderen Branchen keine Rolle spielen.

Was eine Customer Data Platform für Finanzdienstleister leisten muss

Das CDP Institute hat für die RealCDP-Zertifizierung sieben nachweisbare Kernfähigkeiten definiert: Daten aus jeder Quelle aufnehmen — strukturiert, semi-strukturiert, unstrukturiert —, die volle Detailtiefe erfassen, Daten persistent speichern, vereinheitlichte Profile identifizierter Personen bilden, Daten mit jedem angebundenen System teilen, in Echtzeit reagieren und Kundendaten im Einklang mit lokalen Datenschutz- und Sicherheitsvorgaben governieren (CDP Institute, RealCDP Certification). Entscheidend ist dabei die Detailtiefe: Eine echte CDP „is able to retain all details of input data indefinitely" — im Unterschied zu Systemen, die Daten aggregieren oder nach Fristen verwerfen (CDP Institute).

Auch der Echtzeit-Anspruch ist konkret messbar: RealCDP verlangt eine Reaktionszeit von „under one second" sowohl für die Aufnahme neuer Daten als auch für die Beantwortung einer Profilanfrage — ein deutlich schärferer Maßstab als der frühere Richtwert von 30 Sekunden (CDP Institute, RealCDP). Gartners Marketing-Glossar definiert eine CDP ähnlich funktional: als Martech, die Kundendaten aus Marketing- und anderen Kanälen vereinheitlicht, um Kundenmodellierung sowie Timing und Targeting von Botschaften und Angeboten zu optimieren (Gartner Marketing Glossary).

Warum eine Customer Data Platform für Finanzdienstleister anders aussieht

Die genannten Kernfähigkeiten gelten branchenübergreifend. Was eine Customer Data Platform für Finanzdienstleister von einer generischen Martech-CDP unterscheidet, ist die regulatorische Hülle, in die sie eingebettet sein muss. Drei Aspekte sind dabei besonders relevant:

Auslagerung und Aufsicht. Die EBA-Leitlinien zu Auslagerungsvereinbarungen gelten seit dem 30. September 2019 (EBA/GL/2019/02). Sie verlangen, dass das Auslagerungsregister den Datenstandort enthält — konkret „the country or countries where the service is to be performed, including the location … of the data" (Rn. 54(f)) sowie bei Cloud-Diensten zusätzlich Service- und Deploymentmodell (Rn. 54(h)) (EBA/GL/2019/02). Eine CDP, die diese Angaben nicht liefern kann, lässt sich in einer Bank schlicht nicht auslagerungsrechtlich einordnen.

DORA und Datenrückführung. Seit dem 17. Januar 2025 ist die Digital Operational Resilience Act (DORA) anzuwenden, ohne weitere Übergangsfrist (BaFin, DORA-Überblick). Die BaFin erwartet zudem, dass Institute „jederzeit schnell und uneingeschränkt" auf ihre bei einem Cloud-Anbieter gespeicherten Daten zugreifen und diese rücküberführen können — idealerweise über „plattformunabhängige Standarddatenformate" (BaFin, Cloud-Aufsichtsmitteilung). Eine CDP ohne offene Exportformate erzeugt hier ein handfestes Compliance-Risiko.

Datenstandort als geopolitische Frage. Die BaFin verlangt eine „Bewertung des Standorts, an dem Daten gespeichert oder verarbeitet werden, des Standorts des Unternehmenssitzes des Cloud-Anbieters, der geopolitischen Lage … und der anwendbaren Gesetze … in den betreffenden Gerichtsbarkeiten" (BaFin, Cloud-Aufsichtsmitteilung). Die Nennung des Rechenzentrumsstandorts genügt dabei grundsätzlich, auf Anforderung ist jedoch die genaue Anschrift bereitzustellen (BaFin, Cloud-Aufsichtsmitteilung).

Architektur: von der Datenquelle bis zur Aktivierung


Architektur einer Customer Data Platform für Finanzdienstleister

Eine funktionsfähige Architektur folgt vier Schichten: Ingestion aus Kernbanksystem, CRM und Kartenverarbeitung; persistente, identitätsauflösende Speicherung; Governance-Schicht für Consent, Lineage und PII-Schutz; und schließlich die Aktivierungsschicht, die Scores und Segmente in Echtzeit an Online-Banking, App, E-Mail oder Filial-CRM ausspielt. Genau diese Kombination — Echtzeitdaten aus CRM, Kernbanksystem und Kartenverarbeitung mit Consent-Management, Lineage-Dokumentation, PII-Schutz und deutschem Hosting nach GDPR-by-design-Prinzip — bildet nach Anbieterangaben den Kern des CDP-&-Data-Governance-Moduls von Acceleraid (Acceleraid Platform).

Warum diese Architektur mehr ist als graue Theorie, zeigt eine McKinsey-Erhebung: Nur etwa 28 % der Banken können interne strukturierte Kundendaten heute überhaupt rasch in ihre KI-Modelle integrieren (McKinsey, Getting personal). Diese Integrationslücke ist meist keine Frage fehlender Modelle, sondern fehlender Dateninfrastruktur darunter.

Abgrenzung: CDP versus Data Warehouse versus CRM

Die Verwechslung mit Data Warehouse (DWH) und CRM ist der häufigste konzeptionelle Fehler bei der CDP-Einführung. Ein DWH ist primär für analytische Abfragen durch Data-Teams gebaut, nicht für Echtzeit-Aktivierung im operativen Betrieb. Ein CRM verwaltet in erster Linie explizit erfasste Vertriebs- und Servicebeziehungen, nicht das vollständige Verhaltens- und Transaktionsprofil eines Kunden. Eine CDP schließt diese Lücke, indem sie laut CDP Institute als „unified interface" fungiert, „through which customer data services are governed and made operational" (CDP Institute) — und dabei drei Deploymentmodelle kennt: „packaged", „warehouse-native" (composable) und „dual-mode" (CDP Institute).

Merkmal

Data Warehouse

CRM

Customer Data Platform

Primärzweck

Analytisches Reporting

Vertriebs-/Servicebeziehung

Echtzeit-Aktivierung & Governance

Datentiefe

Aggregiert/historisiert

Explizit erfasste Interaktionen

Volle Detailtiefe, alle Quellen

Reaktionszeit

Batch/Stunden

Nutzergetrieben

Unter 1 Sekunde (RealCDP-Maßstab)

Governance-Fokus

Datenqualität

Kontaktdaten-Pflege

Consent, Lineage, PII

Quelle: CDP Institute, RealCDP Certification; Einordnung DWH/CRM redaktionell auf Basis der CDP-Institute-Definition.

Reifegrad: wo der Markt tatsächlich steht

Der CDP-Markt ist 2026 kein Nischenphänomen mehr: Der Branchenumsatz liegt bei 2,9 Mrd. USD, verteilt auf 217 Anbieter mit 19.813 Beschäftigten und kumuliert 10,5 Mrd. USD Funding (CDP Institute / Customer Data Alliance). Gleichzeitig zeigt die Mitgliederbefragung von Januar 2025 einen Reifesprung: 57 % der Befragten berichteten erstmals von einer einheitlichen Kundendatenbank, 68 % von einer bereits produktiv eingesetzten CDP (CDP Institute News). Der Report „Unified Data, Uneven Outcomes" relativiert diesen Fortschritt jedoch: Trotz breiter CDP- und KI-Adoption und wachsender Nutzung von warehouse-first- und composable-Architekturen bleiben die Ergebnisse uneinheitlich — Governance, Integration, Skills und Value Realization werden als zentrale Barrieren genannt (CDP Institute, 2025 Member Survey).

Für Finanzdienstleister heißt das: Eine CDP zu implementieren löst das Datenproblem nicht automatisch. Sie schafft lediglich die technische Voraussetzung — den eigentlichen Wert entfaltet sie erst, wenn Governance-Prozesse, Modelltraining und Aktivierungslogik konsequent daran anschließen.

Praktische Einordnung für Marketing- und Datenverantwortliche

Aus den genannten Fakten lässt sich ein einfacher Prüfrahmen ableiten, bevor eine Bank oder ein Finanzdienstleister eine CDP-Initiative startet:

  1. Datenquellen-Inventur: Welche Systeme — Kernbanksystem, Kartenverarbeitung, CRM, Webtracking — müssen in Echtzeit angebunden werden, und wo liegen die größten Integrationslücken?

  2. Regulatorischer Rahmen zuerst: Auslagerungsregister, DORA-Konformität und Datenresidenz sind keine Nachgedanken, sondern Auswahlkriterien von Tag eins.

  3. Governance vor Modellen: Ohne Consent-Management, Lineage und PII-Schutz bleibt jedes nachgelagerte KI-Modell auf wackligem Fundament.

  4. Aktivierungspfad definieren: Eine CDP ohne angebundene Kanäle für Online-Banking, App, E-Mail und Filiale bleibt ein teures Datenlager.

Diese vier Punkte sind auch die Grundlage für die konkrete Anbieterauswahl, der sich der zweite Teil dieser Serie widmet — inklusive RFP-Checkliste und roten Flaggen bei der Bewertung von Angeboten.

Ein Aspekt wird in der Praxis regelmäßig unterschätzt: Die Frage, ob eine Customer Data Platform für Finanzdienstleister als "packaged"-Lösung, als "warehouse-native" (composable) Ansatz auf Basis des bestehenden Data Warehouse oder als "dual-mode"-Kombination beider Modelle eingeführt wird, entscheidet maßgeblich über Integrationsaufwand und spätere Betriebskosten (CDP Institute). Banken mit einem bereits stark ausgebauten Snowflake- oder Cloud-Data-Warehouse tendieren zunehmend zu warehouse-nativen Architekturen, weil sie doppelte Datenhaltung vermeiden — ein Thema, das wir in unserer Serie Data is the Key for AI vertiefen.

Auch die Frage der Erklärbarkeit gehört in diese frühe Weichenstellung: Werden auf Basis der CDP-Daten Scores oder automatisierte Next-Best-Action-Entscheidungen erzeugt, muss die Architektur von Anfang an auditierbare, nachvollziehbare Modelllogik unterstützen — nicht erst nachträglich ergänzt werden. Wie eine solche Entscheidungslogik konkret aufgebaut ist, zeigt unser Beitrag dazu, wie eine Next-Best-Action-Engine entscheidet.

Für Institute, die heute noch am Anfang stehen, lohnt sich ein nüchterner Blick auf den eigenen Status quo: Wie viele der sieben RealCDP-Kernfähigkeiten sind bereits — auch ohne CDP-Label — im bestehenden Datenstack abgedeckt, und wo klaffen die größten Lücken zwischen Anspruch und tatsächlicher Echtzeitfähigkeit? Diese Bestandsaufnahme ist der eigentliche Startpunkt jeder erfolgreichen CDP-Initiative im Finanzsektor — noch vor der ersten Anbieterdemo.

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.

We use Cookies 🍪

Strictly necessary cookies (e.g. Pipedrive forms) remain active. With your consent we also use Google Analytics (analytics) and Leadfeeder (visitor identification). More in our Privacy Policy.

Decline

Decline

Accept all

Accept all