Fusion: Die Datenmigration entscheidet früher, als alle denken

Die Fusion ist beschlossen. Die Daten sind es nicht.

Juristisch ist eine Fusion in Monaten erledigt. Danach beginnt der Teil, der Kraft kostet. Über das Tempo einer Bankfusion entscheidet die Datenmigration, und zwar früher als im Projektplan vorgesehen: Wer Datenqualität, Dubletten und Zuständigkeiten erst zur technischen Fusion klärt, verliert Monate und trägt die Altlasten beider Institute ins neue Institut.

Der Takt der Konsolidierung bleibt hoch. Nach der Bankstellenstatistik der Deutschen Bundesbank vom Juni 2026 gingen 2025 im Genossenschaftssektor 27 Institute durch Fusionen ab (2024: 25), die Zahl der genossenschaftlichen Institute sank um 3,7 Prozent auf 647. Jede dieser Fusionen führt zwei Datenbestände zusammen, die über Jahrzehnte unterschiedlich gepflegt wurden.

Warum beginnt die Datenmigration früher, als der Projektplan glaubt?

Weil die entscheidenden Weichen fachlich sind und vor der Technik fallen. Im Projektplan steht die technische Fusion am Ende: erst Beschluss, dann Organisation, dann Systeme. Faktisch müssen vorher Fragen beantwortet werden, die kein Rechenzentrum entscheiden kann. Welches Institut führt das Kundenstammdatenmodell? Nach welchen Regeln werden Dubletten zusammengeführt, wenn dieselbe Kundin in beiden Instituten mit unterschiedlichen Adressen geführt wird? Welche Vertragshistorie ist führend, welche Sonderkonditionen gelten weiter?

Wer diese Fragen dem Migrationswochenende überlässt, entscheidet sie unter Zeitdruck und nach Zuruf und korrigiert die Folgen anschließend jahrelang im laufenden Betrieb. Kundenstammdaten sind die Grunddaten einer Kundenbeziehung: Name, Anschrift, Legitimation, Verknüpfungen zu Konten, Verträgen und anderen Personen.

Welche Altlasten wandern ungefiltert mit?

Alles, was vorher niemand bereinigt. Veraltete Adressen, unvollständige Legitimationen, tote Konten, nicht mehr gültige Einwilligungen für die Kundenansprache, historisch gewachsene Sonderfälle in Konditionen und Produkten. Das neue Institut startet dann mit den addierten Altlasten beider Vorgänger. Besonders heikel sind Verknüpfungen: Haushalte, Firmenverbünde und Bevollmächtigte, die in beiden Instituten unterschiedlich abgebildet sind und nach der Zusammenführung nicht mehr zueinander passen.

Die Folgen zeigen sich überall: in Auswertungen, die doppelte Kunden zählen, in Vertriebskampagnen, die dieselbe Person zweimal anschreiben oder gar nicht erreichen, in Meldeprozessen, die auf unvollständigen Daten aufsetzen. Jede spätere Automatisierung und jeder KI-Einsatz arbeitet auf diesem Fundament. Ein Modell, das auf doppelten oder veralteten Daten lernt, liefert verlässlich falsche Ergebnisse.

Wer verantwortet die Datenbereinigung in der Fusion?

Die Fachbereiche, mit klaren Zuständigkeiten je Datendomäne und einer Frist vor der Migration. Die Rechenzentrale liefert für die technische Zusammenführung erprobte Verfahren, wie der Beitrag zur Kernbankmigration beschreibt. Was sie nicht liefern kann, sind die fachlichen Entscheidungen des Instituts: welche Kundendaten aktuell sind, welche Verträge zusammengehören, welche Sonderkonditionen fortgeführt werden.

Bewährt hat sich eine einfache Struktur: je Datendomäne, etwa Kundenstammdaten, Kreditsicherheiten oder Einwilligungen, ein verantwortliches Tandem aus beiden Instituten, ein gemeinsames Regelwerk für Zusammenführung und Bereinigung und ein wöchentlich gemessener Fortschritt mit einer Kennzahl je Domäne, zum Beispiel dem Anteil vollständiger und aktueller Kundenstammdaten. Datenmigration wird beherrschbar, wenn sie als geführtes Arbeitspaket läuft statt als technisches Restrisiko.

Wie lässt sich die Bereinigung beschleunigen?

Mit maschineller Vorarbeit und menschlicher Entscheidung. Dublettenkandidaten über beide Bestände zu finden, fehlende Pflichtfelder zu markieren und Unstimmigkeiten zwischen Stammdaten und Dokumenten aufzuzeigen, ist Massenarbeit, die sich gut automatisieren lässt. Ob zwei Datensätze tatsächlich dieselbe Person beschreiben oder welche Anschrift gilt, entscheidet am Ende der Fachbereich, im Zweifel nach Rückfrage beim Kunden.

Hilfreich ist eine Testmigration auf einer Stichprobe, lange vor dem Stichtag. Sie zeigt, welche Regeln greifen, welche Fälle durchrutschen und wo das Regelwerk nachgeschärft werden muss. Wo KI in der Fusion sonst noch Zeit spart, beschreibt der Beitrag zu KI im Fusionsprojekt.

Welche Kennzahlen zeigen den Stand der Datenqualität?

Wenige, einfache Quoten je Datendomäne, die jede Woche gleich gemessen werden. Bewährt haben sich fünf Größen, die sich aus den Beständen beider Institute direkt auswerten lassen:

• Dublettenquote: Anteil der Kundinnen und Kunden, die in beiden Instituten oder mehrfach im selben Bestand geführt werden.

• Legitimationsquote: Anteil der Kundendatensätze mit vollständiger und aktueller Legitimation.

• Anschriftenqualität: Anteil der Datensätze mit geprüfter, zustellfähiger Anschrift.

• Ruhende Konten: Zahl der Konten ohne Bewegung über einen festgelegten Zeitraum, die vor der Migration geklärt werden.

• Offene Klärungsfälle: Zahl der Fälle, in denen der Fachbereich noch entscheiden muss, mit Alter und Verantwortlichem.

Diese Quoten gehören in denselben Bericht wie der Migrationstermin. Steigt die Zahl offener Klärungsfälle kurz vor dem Stichtag, ist das ein Frühwarnsignal, das sich noch beheben lässt; nach der Migration wäre es ein Betriebsproblem.

Warum ist die Migration der günstigste Moment für Datenqualität?

Weil eine Fusion zu einer Datenprüfung zwingt, die sich sonst niemand vornimmt. Das fusionierte Institut kann mit einem Kundenbestand starten, der sauberer ist als der jedes Vorgängerinstituts. Saubere Stammdaten, geklärte Familien- und Firmenverbünde und vollständige Legitimationen sind die Grundlage für alles, was nach der Fusion Wachstum bringen soll, vom Vertrieb bis zur Kundenbindung in den Monaten nach der Umstellung, wie der Beitrag zur Kundenbindung nach der Fusion zeigt.

Umgekehrt holt eine verschleppte Bereinigung das Institut wieder ein, mit Mehraufwand in jedem Folgeprojekt. Was nach dem Zusammenschluss auf einer sauberen Grundlage möglich wird, beschreibt der Beitrag Genossenschaftsbanken-Fusionen: Wer nur addiert, verliert; dieselbe Reihenfolge gilt für Sparkassen, die erst Prozesse harmonisieren und dann migrieren.

Was das Management vor der Migration klären sollte

1. Datendomänen benennen und je Domäne ein verantwortliches Tandem aus beiden Instituten einsetzen.

2. Ein gemeinsames Regelwerk beschließen: führendes Datenmodell, Dublettenregeln, fortgeführte Sonderkonditionen.

3. Datenqualität messen, nicht schätzen, mit einer Kennzahl je Domäne und wöchentlichem Bericht an die Projektlenkung.

4. Eine Testmigration auf einer Stichprobe rechtzeitig vor dem Stichtag einplanen.

5. Eine Frist setzen, zu der die fachliche Bereinigung abgeschlossen ist, deutlich vor der technischen Migration.

Häufige Fragen

Wer ist bei einer Bankfusion für die Datenqualität verantwortlich?
Die Fachbereiche beider Institute. Das Rechenzentrum führt die technische Migration durch, die fachlichen Entscheidungen über Dubletten, führende Daten und Sonderkonditionen trifft das Institut.

Wann sollte die Datenbereinigung beginnen?
Mit der Fusionsplanung, nicht mit dem Migrationstermin. Je früher die Regeln stehen, desto weniger wird am Stichtag improvisiert.

Lohnt sich die Bereinigung, wenn ohnehin migriert wird?
Gerade dann. Die Migration ist der Moment, in dem alle Daten ohnehin angefasst werden. Jede spätere Bereinigung kostet zusätzlichen Aufwand im laufenden Betrieb.

Weitere Beiträge zu Fusionen, Migration und Integration bündelt das Dossier Fusion & Integration.

Wie viele Dubletten und unvollständige Legitimationen im eigenen Bestand stecken, weiß vor einer Fusion selten jemand genau, und genau diese Zahl bestimmt den Aufwand der Migration. Ein erstes Gespräch dazu ist ein guter Anfang, wir freuen uns darauf.