CDP-Integration ohne Core-Banking-Migration: Wie API-First-Architekturen den Gordischen Knoten lösen

Die größte Bremse für datengetriebenes Banking in Europa ist nicht der Mangel an Daten. Es ist der Mangel an Integrationsfähigkeit.

Deutsche Banken betreiben im Durchschnitt 40 bis 80 verschiedene IT-Systeme. Core-Banking, Kreditverwaltung, Kreditkartensystem, CRM, Online-Banking-Plattform, Meldewesen, Wertpapierplattform. Diese Systeme wurden über Jahrzehnte aufgebaut, oft als Insellösungen, mit proprietären Datenbankformaten und System-spezifischen Schnittstellen.

Eine Customer-Data-Platform soll alle diese Daten zusammenführen und ein einheitliches Kundenprofil schaffen. Die klassische Antwort auf diese Anforderung war eine vollständige Migration: Neues Core-Banking, neue Architektur, neues Datenbankmodell. Drei bis fünf Jahre Implementierung, acht- bis neunstellige Budgets, erhebliches Ausfallrisiko.

Das muss nicht so sein.

Was eine API-First-CDP-Architektur leistet

Eine API-First-Architektur stellt die Integration nicht vor, sondern hinter die Frage der Datennutzung. Statt "Wie migrieren wir alle Daten in ein neues System?" lautet die Frage: "Wie greifen wir auf bestehende Daten zu, ohne sie zu verschieben?"

Das Ergebnis ist eine Architektur, die:

• Bestehende Quellsysteme unangetastet lässt

• Über standardisierte APIs (REST, event-basiert) Daten in Echtzeit oder nahezu-Echtzeit abruft

• Diese Daten in einem zentralen CDP-Layer zusammenführt und anreichert

• Den nachgelagerten Systemen (Campaign-Engine, Journey-Orchestrierung, NBA-Engine) ein einheitliches, aktuelles Kundenprofil bereitstellt

Das Core-Banking-System bleibt, wo es ist. Es bekommt keine neuen Anforderungen. Es liefert Daten über eine definierte Schnittstelle — wie es das heute für hundert andere Zwecke bereits tut.

Die drei Integrationsebenen in der Praxis

Ebene 1: Batch-Integration für historische Daten

Für historische Transaktionsdaten — die für Modelltraining, Segmentierung und Feature-Engineering benötigt werden — genügt eine initiale Bulk-Extraktion, gefolgt von täglich oder wöchentlich aktualisierten Delta-Loads.

Diese Daten ändern sich nicht mehr. Sie müssen einmalig migriert und danach nur noch inkrementell aktualisiert werden. Das ist technisch straightforward und lässt sich mit jedem Standard-ETL-Tool durchführen.

Ebene 2: Near-Realtime-Integration für aktuelle Kontodaten

Für aktuelle Kontostände, Produktnutzung und Produktbesitz genügt eine near-realtime-Integration mit einem Update-Rhythmus von Stunden. Die Kundensegmentierung und die Next-Best-Action-Bewertung brauchen keine Millisekunden-Aktualität — sie brauchen Datenkonsistenz ohne tagelangen Verzug.

Ebene 3: Echtzeit-Events für Transaktionssignale

Für Transaktionsbasierte Trigger — ein Kunde zahlt erstmals bei einem bestimmten Haendler, ein Gehaltseingang fehlt — wird ein event-basierter Ansatz benötigt: Das Quellsystem sendet bei relevanten Transaktionen ein Event an den CDP-Layer, der dieses Event sofort auswertet und bei Bedarf einen Trigger auslöst.

Dieses Event-Streaming lässt sich in den meisten modernen Core-Banking-Systemen (und auch in Legacy-Systemen über vorgelagerte Event-Broker wie Kafka) realisieren, ohne das Quellsystem selbst zu ändern.

Was in der Praxis den Unterschied macht

Datenqualität vor Vollständigkeit

Eine häufige Falle: Teams warten mit der CDP-Inbetriebnahme, bis alle Datenquellen vollständig integriert sind. Das kann Jahre dauern. Die pragmatische Alternative: Mit den wichtigsten Quellsystemen (Core-Banking, Kreditkarte) starten, erste Use Cases produktiv schalten, weitere Quellen inkrementell integrieren.

Ein CDP mit 70 Prozent Datenvollständigkeit, der produktiv läuft, liefert mehr Wert als ein perfektes System in drei Jahren.

Datenhygiene und Deduplizierung

Wenn Daten aus mehreren Quellsystemen zusammengeführt werden, entstehen zwangsläufig Duplikate und Inkonsistenzen. Ein Kunde ist im Core-Banking als "Johann Mueller" gepflegt, im CRM als "Hans Mueller", in der Kreditkartendatenbank mit einer anderen Adresse. Der CDP-Layer muss diese Identitäten zusammenführen — das ist nicht trivial, aber beherrschbar.

DSGVO-konformes Datenmapping

Jede Datenquelle, jedes übertragene Feld, jede Verarbeitungsgrundlage muss dokumentiert sein. Ein API-First-CDP bietet hier einen strukturellen Vorteil gegenüber Migration-basierten Ansätzen: Datenflüsse sind explizit definiert, nicht implizit in Migrationsskripten versteckt.

Ein realistischer Zeitplan

Auf Basis von Implementierungserfahrungen ergibt sich für eine typische Retail-Bank mit zwei bis drei Kernquellsystemen folgender Zeitrahmen:

• Wochen 1–6: Core-Banking-Integration (Batch + Near-Realtime), erste Kundenprofil-Konsolidierung

• Wochen 7–12: Erste produktive Use Cases (Segmentierung, einfache Trigger-Kampagnen)

• Monate 4–6: Zusätzliche Quellsysteme (Kreditkarte, CRM), Echtzeit-Event-Streaming, erste Propensity-Modelle

• Monate 7–12: Vollständige NBA-Architektur, Journey-Orchestrierung, kontinuierliches Modell-Monitoring

Kein Big-Bang. Kein drei-Jahres-Projekt. Messbare Ergebnisse ab Quartal zwei.

Was das für die Investitionsentscheidung bedeutet

Eine API-First-CDP-Architektur ändert die wirtschaftliche Logik der Integration fundamental: Statt einer Vorab-Investition in eine vollständige Infrastruktur-Migration entsteht ein inkrementeller, nutzungsbasierter Aufbau — bei dem jede Integrationsstufe unmittelbar Wert liefert.

ACCELERAID ist von Anfang an als API-First-System gebaut — mit vorgefertigten Konnektoren für die gängigen Core-Banking-Systeme des deutschen und europäischen Markts und einer Integration-Architektur, die auf bestehende IT aufbaut statt sie zu ersetzen.

Demo anfragen