Wie Banken den Matching-Anbieter wechseln, ohne die Entscheidungshistorie zu verlieren

Kurzfassung: Bewahren Sie die Matching-Historie als prüfbares Entscheidungsprotokoll, nicht nur als Export alter Entity-IDs. Sichern Sie Quellidentitäten, Regelversionen, Belege, Overrides und Gültigkeitszeiten. Lassen Sie alten und neuen Resolver parallel laufen, prüfen Sie wesentliche Unterschiede und stellen Sie erst mit nachgewiesener Herkunft, Alias-Zuordnung und Rückweg um.

Demo buchen oder Tilores Studio kostenlos testen.

Auf dieser Seite

1. Was müssen Sie beim Wechsel des Matching-Anbieters bewahren?
2. Wie erfassen Sie die Historie vor dem Ende des Altvertrags?
3. Wie ordnen Sie alte und neue Matching-Entscheidungen zu?
4. Wie testen Sie den Ersatz, ohne alte Fehler zu konservieren?
5. Wie sieht eine kontrollierte Umstellung im Jahr 2026 aus?
6. Welche Rolle kann Tilores bei einer Migration mit Historie spielen?
7. Welche Unterlagen benötigen Einkauf, Risiko und Revision?
8. Wann ist die Migration abgeschlossen?
9. Häufige Fragen

Ein Wechsel des Matching-Anbieters ist keine reine Datenübertragung. Die neue Plattform kann dieselben Datensätze anders gruppieren, obwohl beide Systeme für sich genommen korrekt arbeiten. Für die Bank zählt deshalb eine andere Frage: Kann sie später erklären, welche Beziehung zu welchem Zeitpunkt galt, weshalb sie geändert wurde und welche nachgelagerten Anwendungen von der Änderung betroffen waren?

Behandeln Sie die bisherige Entscheidungshistorie als prüfbares Protokoll, nicht als Liste alter Entity-IDs. Frieren Sie die Quellpopulation und den Regelstand ein, vergleichen Sie beide Resolver anhand derselben Eingaben und behalten Sie für jede wesentliche Abweichung eine Begründung. Der Umstieg ist erst abgeschlossen, wenn Fachbereiche, Risiko und Revision die aktuelle und die historische Sicht auch ohne Zugriff auf den alten Dienst rekonstruieren können.

Was müssen Sie beim Wechsel des Matching-Anbieters bewahren?

Trennen Sie zunächst drei Identitäten. Eine stabile Quell-ID bezeichnet einen Datensatz innerhalb eines benannten Quellsystems. Eine bisherige Entity-ID bezeichnet die Gruppierung, die der alte Resolver zu einem bestimmten Zeitpunkt erzeugt hat. Eine fachliche Kennung gehört dagegen beispielsweise zu einem Konto, einem Fall oder einer Zahlung. Diese Kennung darf sich nicht allein deshalb ändern, weil Kundenakten künftig anders gruppiert werden.

Für einen belastbaren Vergleich brauchen Sie eingefrorene, mit Zeitstempel und Hash versehene Datenstände. Dokumentieren Sie nicht nur, welche Datensätze zu einer alten Entity gehörten. Halten Sie auch fest, welche Regelversion, Schwellenwerte, Vergleichsfelder und manuellen Entscheidungen zu dieser Gruppierung geführt haben, soweit der bisherige Anbieter diese Informationen bereitstellt.

Das Mindestprotokoll für eine nachvollziehbare Migration

Eine exportierte Entity-Tabelle ist noch keine Entscheidungshistorie. Sie zeigt einen Zustand. Die Historie erklärt zusätzlich die wirksame Konfiguration, den Zeitpunkt, die Herkunft der Datensätze und spätere Merges, Splits und Overrides.

Wie erfassen Sie die Historie vor dem Ende des Altvertrags?

Beginnen Sie, solange der alte Dienst und die zuständigen Fachleute noch verfügbar sind. Benennen Sie Quellsysteme, Datensatzpopulation, Extraktionszeit und Konfiguration. Exportieren Sie die Originaldatensätze mit ihren Quell-IDs. Signieren oder hashen Sie jeden Export und erfassen Sie die Zeilenzahl. Exportieren Sie danach die Mitgliedschaft jeder alten Entity, auch wenn sie nur einen Datensatz enthält.

Ergänzen Sie Regelbelege, Scores, Schwellenwerte, Kandidatenpfade und manuelle Entscheidungen, sofern sie tatsächlich zugänglich sind. Inventarisieren Sie Berichte, Fallakten, Screening-Prozesse und Schnittstellen, die eine alte Entity-ID speichern. Stimmen Sie anschließend jeden Mitgliedsdatensatz gegen den Quellauszug und jede referenzierte Regel gegen die eingefrorene Konfiguration ab. Jede nachgelagerte Kennung braucht einen verantwortlichen Eigentümer.

Manche Altplattformen geben nicht alle Entscheidungsbelege frei. Halten Sie diese Grenze ausdrücklich fest. Leiten Sie aus einem Score keine erfundene Regelbegründung ab und unterstellen Sie aus einer endgültigen Gruppierung keine menschliche Freigabe. Die Lücke ist ein Migrationsrisiko, für das Sie eine Entscheidung benötigen.

Wie ordnen Sie alte und neue Matching-Entscheidungen zu?

Vergleichen Sie Gruppen über die Quell-Datensätze, nicht über den Versuch, die alten Entity-IDs im neuen System zu erzwingen. Die Resolver können sich bei Clustering, Grenzfällen oder Reihenfolge von Änderungen unterscheiden. Die gemeinsame Ebene ist die Zugehörigkeit stabil identifizierter Quelldatensätze.

Ein Zuordnungsprotokoll braucht vier Ergebnistypen: unverändert, Merge, Split und gemischt. Unverändert heißt, dass die Mitglieder gleich bleiben. Bei einem Merge werden mehrere alte Gruppen zu einer neuen. Bei einem Split wird eine alte Gruppe in mehrere neue aufgeteilt. Ein gemischter Fall verbindet beide Muster und verlangt eine Prüfung auf Fallebene.

Bewahren Sie die alte Entity-ID als Alias mit Gültigkeitszeitraum und Auflösungsstatus. Ein Verbraucher, der nur die aktuelle Sicht benötigt, kann diesen Alias auf die heutige Entity auflösen. Revision, Beschwerden, Screening und historische Auswertungen brauchen gegebenenfalls den Zustand, der bei der ursprünglichen Entscheidung wirksam war. Entity-IDs sind keine ewigen fachlichen Schlüssel. Auch eine erneute Aufnahme desselben Datensatzes stellt die frühere Entity-ID nicht automatisch wieder her.

Wie testen Sie den Ersatz, ohne alte Fehler zu konservieren?

Die alte Ausgabe ist eine Vergleichsbasis, keine unfehlbare Wahrheit. Eine neue Lösung, die jede frühere Verknüpfung kopiert, übernimmt womöglich falsche Merges, übersehene Treffer und unklare Overrides. Eine Lösung ohne historische Sicht kann dagegen Kundenvorgänge unterbrechen und bereits geleistete Prüfungen entwerten.

Bilden Sie deshalb einen beschrifteten Testsatz. Er sollte wertvolle Kundenbeziehungen, dicht verknüpfte Entities, frühere manuelle Prüfungen, bekannte falsch-positive und falsch-negative Fälle, neue Quelländerungen sowie Datensätze aus Sanktions-, PEP- und Adverse-Media-Prüfungen enthalten. Ergänzen Sie Zufallsstichproben, damit Ausnahmen nicht das gesamte Urteil bestimmen.

Lassen Sie beide Systeme auf demselben eingefrorenen Datenstand laufen. Vergleichen Sie Paarentscheidungen, Entity-Mitgliedschaft und Folgen für Verbraucher. Ordnen Sie wesentliche Abweichungen einer Ursache zu: Übersetzung der Konfiguration, Datenaufbereitung, Matching-Methode, Reihenfolge der Updates, fehlender Altbeleg oder wahrscheinliche Korrektur. Das Prüfungsteam sollte Ursache und Konsequenz freigeben, nicht nur eine Übereinstimmungsquote.

Der Basler Ausschuss betont die Bedeutung einer durchgängigen Datenherkunft für die Qualität von Risikodaten. Nutzen Sie diese Idee als praktischen Akzeptanztest: Von einer geänderten Entity muss der Weg zurück zu Quellwert, Transformation, Regelbeleg und Freigabe nachvollziehbar sein. Externe Listen ändern sich unabhängig vom Resolver. OpenSanctions führt offizielle Sanktionslisten und PEP-Daten in einem Datenökosystem zusammen. Notieren Sie bei jedem Replay die verwendete Listenversion und verwalten Sie Adverse-Media-Anbieterstände gesondert.

Wie sieht eine kontrollierte Umstellung im Jahr 2026 aus?

Stellen Sie in Etappen um und halten Sie den bisherigen Dienst zunächst als Referenz verfügbar. Die neue Strecke, die Zuordnung nachgelagerter Kennungen und der Rückweg müssen geübt sein, bevor Sie die alte Verbindung aufgeben.

1. Basis einfrieren: Hashes für Quellauszug, alte Mitgliedschaft, Konfiguration, Overrides und Verbraucherreferenzen sichern und den Umfang freigeben.
2. Ersatz konfigurieren: Die Absicht einer Regel übertragen, nicht blind ihre Syntax. Nicht exakt abbildbare Regeln und die genehmigte Alternative dokumentieren.
3. Historie erneut verarbeiten: Den eingefrorenen Bestand mit stabilen Quell-IDs laden und neue Mitgliedschaften samt Entscheidungsbelegen behalten.
4. Parallel laufen: Gleichwertige Änderungen an beide Systeme geben und wesentliche Merges, Splits und Nicht-Treffer abgleichen.
5. Verbraucher prüfen: Aliase, aktuelle Abfrage, historische Sicht, Löschung, Berichtigung, Screening, Fälle und Reporting testen.
6. Begrenzte Gruppe umstellen: Mit einer Quelle, Region oder Arbeitslast beginnen und Abweichungen gegen ausdrückliche Stop-Bedingungen beobachten.
7. Abschließen: Erst nach geübtem Rollback, freigegebenen Belegen und geklärter Aufbewahrung auf den neuen Resolver wechseln und den Altvertrag beenden.

Rollback betrifft mehr als das Umschalten einer Anwendung. Definieren Sie den wiederherzustellenden Konfigurationsstand, Entity-Zustand, Aliasbestand, ausstehende Änderungen und Verbraucher-Checkpoints. Legen Sie auch fest, wie Änderungen während des Rückwegs ohne Verdopplung oder Verlust nachverarbeitet werden.

Welche Rolle kann Tilores bei einer Migration mit Historie spielen?

Tilores setzt deterministisches, Fuzzy- und probabilistisches Matching als getrennte Methoden ein. So kann ein Migrationsteam prüfen, ob eine veränderte Entscheidung auf einer exakten Regel, einem Ähnlichkeitsvergleich oder einer probabilistischen Bewertung beruht. Jede Methode muss gegen beschriftete Fälle getestet werden.

Tilores normalisiert und persistiert Daten, behält aber die Originale. Übernehmen Sie beim Laden Quell-ID und Quell-Namespace und vergleichen Sie die neue Mitgliedschaft mit der signierten Altbasis. Produktive Verbraucher fragen Tilores über GraphQL ab, nicht über REST. Regeln und historisches Replay sind getrennte Vorgänge: Werden neue Matching-Regeln ergänzt, aktualisieren sich vorhandene Daten nicht automatisch. Für einen neuen Regelstand ist deshalb eine kontrollierte erneute Aufnahme derselben Datensätze mit den ursprünglichen IDs, definiertem Umfang und eigener Abstimmung erforderlich.

Nutzen Sie den Entity Event Stream für das Übergangsprotokoll. Tilores veröffentlicht jede einzelne Datenänderung über diesen Stream. Verarbeiten Sie Events idempotent, behalten Sie Gültigkeitszeiten und ordnen Sie veränderte oder nicht mehr aktuelle Entities zu, bevor Verbraucher neue Kennungen übernehmen. Die Tilores-Anleitungen zur Einführung von Entity Resolution und zum Umgang mit Merges, Splits und stabilen IDs erläutern die angrenzenden Schritte.

Welche Unterlagen benötigen Einkauf, Risiko und Revision?

Ein Migrationspaket sollte den freigegebenen Umfang, vertragliche Ausstiegsvoraussetzungen, signierte Exporte, Konfigurationsversionen, Abweichungsanalysen, Prüferentscheidungen, Umstellungsplan, Rollback-Nachweis, Zugriffsänderungen, Aufbewahrung und Schlussabgleich enthalten. Vergeben Sie für jeden Bestandteil einen Eigentümer und eine unveränderliche Kennung.

Ob ein bestimmter Matching-Dienst eine kritische oder wichtige Funktion unterstützt, ist eine Rechts- und Risikobewertung der jeweiligen Bank. Die Nachweise sollten für diese Bewertung und gegebenenfalls für eine Ausstiegsplanung nutzbar sein. Die US-amerikanische Interagency Guidance fordert bei Drittparteibeziehungen eine Planung, wie Tätigkeiten zu einem anderen Anbieter oder zurück ins eigene Haus übergehen können; sie behandelt auch die Beendigung innerhalb des Risikomanagement-Lebenszyklus. Eine Bank muss die Hinweise entsprechend ihrem Rechtsraum und Aufsichtsrahmen einordnen. Keine dieser Quellen schreibt eine konkrete Entity-Resolution-Architektur vor.

Wann ist die Migration abgeschlossen?

Der Wechsel ist abgeschlossen, wenn die Bank aktuelle und historische Identitätsentscheidungen ohne Abfrage des stillgelegten Dienstes erklären kann. Jede alte Entity-Referenz muss auf eine aktuelle Entity, einen zeitgebundenen historischen Zustand oder eine dokumentierte Ausnahme führen.

Die nachgelagerten Eigentümer müssen ihre Zuordnungen akzeptieren. Geprüfte Overrides werden bewusst übernommen oder beendet. Screening-Abläufe sind abgeglichen, Zugänge entfernt und Aufbewahrungspflichten zugewiesen. Auch das Ende der Rollback-Bereitschaft braucht eine ausdrückliche Entscheidung. Eine niedrigere Rechnung oder ein erfolgreicher Massenimport allein ist kein Abschlusskriterium. Entscheidend ist, ob Betrieb, Risiko und Revision den Übergang auch nach Wegfall der Altplattform sicher nachvollziehen können.

Häufige Fragen

Sollten wir alte Entity-IDs in den neuen Matcher kopieren?

Nein. Bewahren Sie sie als Alias und historischen Verweis. Vergleichen Sie Mitgliedschaften über stabile Quell-IDs und eingefrorene Datenstände. Ordnen Sie dann jede alte Entity einer aktuellen Entity oder einer dokumentierten Ausnahme zu.

Kann der neue Resolver alte Matches als beschriftete Wahrheit verwenden?

Erst nach Prüfung. Alte Entscheidungen sind wertvolle Belege, können aber veraltete Regeln, falsche Links oder unklare manuelle Overrides enthalten. Stichproben und Kennzeichnung müssen vor der Nutzung als Akzeptanzmaßstab erfolgen.

Wie lange sollten beide Systeme parallel laufen?

Bis die vereinbarten Risikofälle und Betriebszyklen beobachtet wurden. Die Dauer hängt von der Häufigkeit der Quelländerungen, Kundenauswirkungen, Screening-Nutzung und Rollback-Anforderungen ab, nicht von einer universellen Tageszahl.

Bleiben Entity-IDs bei stabilen Quell-IDs unverändert?

Nein. Stabile Quell-IDs schaffen Nachvollziehbarkeit. Entity-Mitgliedschaft und Entity-ID können sich nach Merge, Split, Löschung oder Regeländerung ändern. Verbraucher brauchen Aliase und Regeln für den Lebenszyklus.

Was geschieht mit der Historie zu Sanktionen, PEP und Adverse Media?

Sie bleibt mit dem Identitätszustand und der Listenversion der ursprünglichen Entscheidung verbunden. Beim Replay müssen Änderungen der externen Liste von Änderungen des Matchings getrennt und wesentliche Unterschiede durch den bestehenden Prüfprozess geleitet werden.

Quellen

1. US Federal Reserve: Interagency Guidance on Third-Party Relationships
2. Basler Ausschuss: BCBS 239 und durchgängige Datenherkunft
3. OpenSanctions: Datenökosystem für Sanktionen und PEP
4. Tilores FAQ: Regeln, Replay und Entity Event Stream
5. Tilores API-Dokumentation
6. Tilores: Wie ein Entity-Resolution-Rollout 2026 wirklich abläuft
7. Tilores: Merges, Splits und stabile IDs für Verbraucher