Können Sie 2026 eine Matching Engine kaufen und Ihren Golden Record behalten?

Kurzfassung: Ja. Eine Bank kann eine spezialisierte Entity Resolution Engine einsetzen, um Datensätze zu normalisieren, zu erkennen, welche Datensätze zu demselben Kunden gehören, und den Identity Graph zu pflegen. Gleichzeitig wählt ihr eigener Mastering Layer die maßgeblichen Werte aus, steuert Freigaben und veröffentlicht den Golden Record in nachgelagerte Systeme.

Testen Sie diese Architektur mit Ihren eigenen Daten. Demo buchen · Tilores Studio kostenlos testen.

Auf dieser Seite

1. Was bedeutet es, nur die Matching Engine zu kaufen?
2. Wo sollte das Matching enden und das Mastering beginnen?
3. Wie sollten Daten zwischen den beiden Ebenen fließen?
4. Welcher Vertrag verhindert, dass die Ebenen auseinanderdriften?
5. Wann passt diese Architektur?
6. Was verlangt die Compliance einer Bank?
7. Wie sollte eine Bank die Architektur bewerten?
8. Was gehört in die Beschaffungsanforderungen?
9. Häufig gestellte Fragen

Was bedeutet es, nur die Matching Engine zu kaufen?

Der Kauf der Matching Engine bedeutet, zwei Aufgaben zu trennen, die häufig in einem großen Master-Data-Management-Programm zusammengeführt werden. Entity Resolution entscheidet, welche Quelldatensätze dieselbe Person oder Organisation darstellen. Das Mastering entscheidet, welche Werte maßgeblich werden, wer eine Änderung freigeben darf und wohin das fertige Kundenprofil veröffentlicht wird.

Diese Abgrenzung ist wichtig. Eine Bank sollte mehr als eine zustandslose Ähnlichkeitsfunktion spezifizieren: Normalisierung, Kandidatensuche, klar getrennte deterministische, Fuzzy- und probabilistische Ansätze, Nachweise für Identitätsentscheidungen und die Verarbeitung von Identitätsänderungen. Dann kann sie Feld-Survivorship, geschäftliche Freigaben und die Veröffentlichung des Golden Record in Systemen belassen, die sie bereits betreibt.

Diese fokussierte Architektur beschreiben wir in unserem Leitfaden zu Entity Resolution in Verbindung mit Master Data Management. Sie ermöglicht einer Bank, einen spezialisierten Identity Layer hinzuzufügen, ohne ihren Customer Master, ihre Datenplattform oder ihr Betriebsmodell zu ersetzen.

Wo sollte das Matching enden und das Mastering des Golden Record beginnen?

Der Matching Layer sollte die Identitätsnachweise verantworten. Der Mastering Layer sollte die geschäftliche Definition des Kundendatensatzes durch die Bank verantworten. Die Tabelle zeigt die empfohlene Zuständigkeit für diese Architektur.

Verantwortungsbereich	Matching Engine	Bankeigener Mastering Layer
Aufbereitung der Quelldaten	Die Normalisierung von Namen, Adressen, Telefonnummern, E-Mail-Adressen, Datumsangaben und Unternehmensattributen spezifizieren, wobei Originalwerte bei Bedarf aufbewahrt werden	Verantwortung für Quellen, Pflichten zur Datenqualität und zulässige Verwendungszwecke festlegen
Kandidatensuche	Datensätze finden, die plausible Übereinstimmungen sind, ohne jeden Datensatz mit jedem anderen Datensatz zu vergleichen	Zulässige Quellpopulationen und Zugriffskontrollen bereitstellen
Identitätsentscheidung	Die Anforderungen der Bank an getrennte deterministische, Fuzzy- und probabilistische Methoden, Matching Rules und Konsistenzprüfungen auf Entitätsebene erfüllen	Richtlinien, Risikokategorien und Prüfbefugnisse freigeben
Identity Graph	Die Anforderungen der Bank an Datensätze, Verknüpfungen, stabile Entitätskennungen sowie den Verlauf von Zusammenführungen und Aufteilungen erfüllen	Die aufgelöste Entitätskennung in gemasterten Ausgaben referenzieren
Werte des Golden Record	Survivorship und die Ausformung des Golden Record bei Bedarf bereitstellen	Die finalen Feldwerte auswählen, wenn das Mastering intern bleibt
Menschlicher Workflow	Nachweise für unsichere Verknüpfungen bereitstellen und reversible Entscheidungen unterstützen	Queues, Freigaben, Funktionstrennung und Eskalation verantworten
Veröffentlichung	Aktuelle Identitätsdaten und Änderungsereignisse ausgeben	Den gemasterten Datensatz in Kernbankensysteme, CRM, KYC, Analytik- und Servicesysteme veröffentlichen

Die Aufteilung ist konfigurierbar. Tilores kann einen Golden Record ausformen, aber die Bank muss diese Verantwortung nicht verlagern. Entscheidend ist, wo jede Entscheidung bereits eine zuständige Stelle hat. Eine Bank mit etablierten Survivorship-Regeln und Data Stewardship sollte diese beibehalten. Eine Bank ohne diese Kontrollen muss sie weiterhin konzipieren, auch wenn sie die Matching Engine kauft.

Wie sollten Daten zwischen der Matching Engine und dem Customer Master fließen?

Eine saubere Integration verwendet wenige klar definierte Phasen. Jede Phase hat genau ein Ergebnis und eine verantwortliche Stelle.

1. Quelldatensätze übermitteln. Die Bank übermittelt zulässige Kundendatensätze und Quellkennungen an die Engine. Ihr Beschaffungs- und Datenvertrag sollte das erforderliche Verhalten bei Normalisierung, Persistenz und Aufbewahrung von Originalwerten für die Nachvollziehbarkeit festlegen.
2. Kandidaten finden. Suchregeln identifizieren plausible Datensätze. Die Kandidatensuche bleibt von der Matching-Entscheidung getrennt, sodass ein Suchtreffer keine Identitätsverknüpfung erzeugt.
3. Identität auflösen. Die Bank sollte die Bedingungen der Matching Rules und die Konsistenzprüfungen auf Entitätsebene definieren, die Konflikte wie widersprüchliche Geburtsdaten oder Steuerkennungen zurückweisen.
4. Identitätsänderungen veröffentlichen. Der Entity Stream dokumentiert CREATE-, UPDATE-, MERGE-, SPLIT- und DELETE-Ereignisse mit den betroffenen Entitäts- und Datensatzkennungen. Eine Ereignisbenachrichtigung ist nicht dasselbe wie ein Entscheidungsnachweis: Benötigt ein Team Nachweise zu den angewandten Regeln, ruft es die relevante Entity Edge über GraphQL ab. Unser Leitfaden zu stabilen Kennungen und nachgelagerten Änderungsereignissen beschreibt dieses Betriebsmuster.
5. Mastering-Regeln anwenden. Der Layer der Bank wählt die maßgebliche Adresse, den maßgeblichen Namen, die Kontaktdaten, den Risikostatus und weitere kontrollierte Attribute aus. Er erfasst, wer eine Ausnahme freigegeben hat.
6. Den aktuellen Kunden bereitstellen. Operative Systeme nutzen den gemasterten Datensatz. Anwendungen, die die aktuell aufgelöste Entität benötigen, können Tilores über die GraphQL APIabfragen. Die Runtime API basiert auf GraphQL; der öffentliche MCP-Server unterstützt bei der Konfiguration und der Abfragegenerierung, nicht bei der Live-Auflösung von Kundendaten.

Dieser Ablauf unterstützt historische Massendaten und Echtzeit-Onboarding mit einem einzigen Identitätsmodell. Außerdem schirmt er nachgelagerte Systeme von Änderungen an Verknüpfungen ab: Eine korrigierte Identitätsentscheidung trifft als kontrolliertes Ereignis ein, und der Mastering Layer berechnet den betroffenen Golden Record neu.

Die Integrationsgrenze folgt dem Arbeitsablauf: Zuerst Identität auflösen und Identitätsänderungen veröffentlichen, dann bankeigene Survivorship-Regeln anwenden und den gemasterten Datensatz bereitstellen.

Welcher Vertrag verhindert, dass die beiden Ebenen auseinanderdriften?

Der Integrationsvertrag ist die Architektur. Eine vage Übergabe wie „Kunde 123 wurde geändert“ ist für Mastering, Audit und Wiederherstellung zu schwach. Definieren Sie diese Felder vor der Implementierung:

Vertragselement	Was es festlegen muss	Warum der Customer Master es benötigt
Identitätsschlüssel	Eine stabile Entitätskennung und die darin enthaltenen Quelldatensatzkennungen	Verhindert, dass nachgelagerte Referenzen von einem bevorzugten Quelldatensatz abhängen
Ereignistyp	CREATE, UPDATE, MERGE, SPLIT oder DELETE mit den betroffenen Entitäts- und Datensatzkennungen	Bestimmt, welche Golden Records neu berechnet werden müssen
Entscheidungsnachweis	Die relevante Entity Edge über GraphQL abrufen und bankeigene Prüfnachweise separat erfassen	Unterstützt Prüfung, Anfechtung und Erklärung, ohne eine Ereignisbenachrichtigung als Beweis zu behandeln
Übergabeversion	Bankeigene Vertragsversion, Ereigniszeit und Verarbeitungsreihenfolge	Ermöglicht der Bank, die erneute Verarbeitung ihrer eigenen gemasterten Ausgabe zu steuern
Korrekturpfad	Ein von der Bank definierter Prozess zur Korrektur einer Identitätsentscheidung und zur erneuten Verarbeitung nachgelagerter Ausgaben	Macht eine falsche Entscheidung operativ beherrschbar
Sicherheitskontext	Mandant, Zweck, zulässige Felder und Aufbewahrungspflichten	Hält gemasterte Daten innerhalb ihrer zulässigen Verwendung

Datenverträge für vorgelagerte Systeme verdienen dieselbe Aufmerksamkeit. Eine Quelle muss Feldbedeutung, Stabilität von Kennungen, Nullwertbehandlung und Formatänderungen deklarieren, bevor Datensätze das Matching erreichen. Diese sieben Regeln für Datenverträge in Entity Resolution sind ein praktischer Ausgangspunkt.

Wann ist eine Engine mit bankeigenem Mastering Layer die richtige Wahl?

Dieses Modell eignet sich für eine Bank, die bereits über einen Customer Master, einen Stewardship-Prozess oder eine Datenplattform verfügt und darin bessere Identitätsentscheidungen benötigt. Ein umfassenderes MDM-Programm eignet sich, wenn die fehlende Fähigkeit Governance, Workflow, Referenzdaten, Domain-Verantwortung und Verteilung über mehrere gemasterte Domains umfasst.

Entscheidungsfrage	Wählen Sie eine Matching Engine mit Ihrem eigenen Layer, wenn	Ziehen Sie ein umfassenderes MDM-Programm in Betracht, wenn
Was ist bereits vorhanden?	Ein Customer Master und verantwortliche Data Owner sind heute operativ im Einsatz	Es gibt keine gesteuerte Mastering-Funktion
Was funktioniert nicht?	Duplikaterkennung, quellenübergreifende Identität oder Erklärbarkeit sind der Engpass	Governance, Workflow und die Veröffentlichung über mehrere Domains fehlen vollständig
Wer verantwortet Survivorship?	Die Bank hat Regeln zur Auswahl maßgeblicher Werte freigegeben	Die Organisation muss Zuständigkeit und Survivorship von Grund auf konzipieren
Wie viel Kontrolle ist erforderlich?	Die Bank möchte gemasterte Datensätze in ihren Systemen und eine austauschbare Identitätskomponente	Die Bank möchte, dass eine Suite das gesamte Betriebsmodell steuert
Was muss sich zuerst ändern?	Ein fokussierter Identity Layer kann eine bestehende Architektur verbessern	Das Zielbetriebsmodell selbst muss neu konzipiert werden

Nutzen Sie den Entscheidungsrahmen für MDM oder Entity Resolution , um die Wahl des umfassenderen Programms zu prüfen. Die geteilte Architektur ist überlegen, wenn sie den Umfang reduziert, ohne Arbeit in der Integrationsschicht zu verbergen.

Was verlangt die Compliance einer Bank von dieser Architektur?

Identitätsfehler bergen asymmetrische Risiken. Eine übersehene Übereinstimmung kann doppelte Profile bestehen lassen. Eine falsche Übereinstimmung kann Finanzinformationen eines Kunden über den Datensatz eines anderen Kunden offenlegen. Artikel 5 der Datenschutz-Grundverordnung verlangt, dass personenbezogene Daten sachlich richtig, auf dem neuesten Stand und auf das notwendige Maß beschränkt sind. Präzision, Nachvollziehbarkeit und Korrektur sind daher Datenschutzkontrollen.

Die Datenarchitektur einer Bank benötigt außerdem eine verlässliche Aggregation. Die BCBS-239-Grundsätze des Basler Ausschusses behandeln Governance, Datenarchitektur, Genauigkeit, Vollständigkeit, Aktualität und Anpassungsfähigkeit von Risikodaten. Ein Matching Layer sollte diese Eigenschaften stärken, indem er Identitätsnachweise und Änderungshistorien für den der Governance unterliegenden Customer Master der Bank offenlegt.

Sorgfaltspflichten gegenüber Kunden schaffen eine weitere Abhängigkeit. FATF-Empfehlung 10 und die zugehörige Auslegungsnote behandeln die Sorgfaltspflichten gegenüber Kunden, einschließlich Identifizierung, Verifizierung und laufender Sorgfaltspflichten. Sanktionsprüfungen, Prüfungen politisch exponierter Personen und Adverse-Media-Prüfungen hängen alle davon ab, die richtigen Datensätze dem richtigen Kunden zuzuordnen. Strukturierte Quellen wie OpenSanctions können Informationen zu Sanktionen, PEP und ausgewählte nachteilige Informationen aus nicht sanktionsbezogenen Watchlists liefern, jedoch kein umfassendes Archiv von Nachrichtenberichten, Social-Media-Beiträgen oder Pressemitteilungen. Entity Resolution liefert den Identitätskontext. Die Screening-Entscheidung verbleibt bei der Bank und ihren Screening-Kontrollen.

• Präzision: Legen Sie Bedingungen für automatische Verknüpfungen anhand des Schadens durch falsche Übereinstimmungen fest, nicht anhand eines universellen Scores.
• Erklärbarkeit: Rufen Sie den relevanten Nachweis an der Entity Edge über GraphQL ab und bewahren Sie bankeigene Prüfentscheidungen auf.
• Menschliche Prüfung: Leiten Sie unsichere Fälle mit den erforderlichen Entscheidungsnachweisen an autorisierte Data Stewards weiter.
• Reversibilität: Testen Sie Korrektur und erneute nachgelagerte Verarbeitung als normale Betriebsabläufe.
• Datenminimierung: Übermitteln und veröffentlichen Sie nur die Felder, die für den zulässigen Zweck erforderlich sind.

Wie sollte eine Bank diese Architektur in einem Proof of Concept bewerten?

Ein aussagekräftiger Proof of Concept testet die Engine und die Grenze um sie herum. Ein hoher Matching Score in einer kuratierten Datei beweist nicht, dass das Produktionsdesign funktioniert.

1. Die Entscheidung definieren. Erfassen Sie, welche Quellen, Kundenpopulationen und nachgelagerten Prozesse zum Umfang gehören.
2. Referenzdaten mit Labels erstellen. Erstellen Sie eine geprüfte Menge aus Matches, Non-Matches und ungeklärten Fällen, einschließlich schwieriger Namen, Adressen und historischer Änderungen.
3. Messgrößen festlegen, bevor Ergebnisse vorliegen. Messen Sie Präzision und Recall getrennt. Gewichten Sie falsche Übereinstimmungen stärker, wenn sie Datenschutz- oder finanzielle Schäden verursachen.
4. Alle drei Ansätze testen. Testen Sie deterministisches, Fuzzy- und probabilistisches Matching als getrennte Methoden. Beziehen Sie eine reine Regelkonfiguration ein, wenn jede Verknüpfung mit menschenlesbaren Bedingungen begründet werden muss. Eine zugängliche, maßgebliche Darstellung der statistischen Grundlage für probabilistisches Record Linkage stellt das US Census Bureaubereit. Fuzzy-Ähnlichkeit allein ist eine andere Methode.
5. Die Übergabe testen. Speisen Sie Benachrichtigungen zu CREATE-, UPDATE-, MERGE-, SPLIT- und DELETE-Ereignissen in einen beispielhaften Mastering-Workflow ein. Bestätigen Sie, dass die Bank einen Golden Record neu berechnen und erneut veröffentlichen kann.
6. Korrektur und Exit testen. Führen Sie einen Korrekturfall aus, verarbeiten Sie die betroffene gemasterte Ausgabe erneut und validieren Sie die Datensätze und Nachweise, die die Exit-Anforderungen der Bank verlangen.

Führen Sie die Bewertung innerhalb der vorgesehenen Kontrollgrenze durch. Tilores unterstützt Managed Deployment, das eigene AWS-Konto einer Bank, eine andere Cloud und On-Premises-Umgebungen. Die aktuellen Optionen finden Sie auf der Deployment-Seite.

Was sollte die Beschaffung in die Anforderungen aufnehmen?

Die Beschaffung sollte Ergebnisse und Schnittstellen spezifizieren, nicht eine Einkaufsliste von Matching-Begriffen. Die Anforderung muss die gesamte Betriebsgrenze abdecken:

• Normalisierung von Namen, Adressen, Telefonnummern, E-Mail-Adressen, Datumsangaben und Unternehmensdaten bei Aufbewahrung der Originalwerte.
• Getrennte Unterstützung für deterministisches, Fuzzy- und probabilistisches Matching.
• Suchregeln bleiben von Matching Rules getrennt.
• Konsistenzprüfungen auf Entitätsebene, die eine Verknüpfung blockieren können, wenn kritische Attribute im Konflikt stehen.
• Stabile Entitätskennungen mit Verlauf von Verknüpfungen, Zusammenführungen, Aufteilungen und Löschungen.
• Über GraphQL abrufbare Nachweise an Entity Edges sowie bankeigene Prüfprotokolle.
• Reversible Prüfentscheidungen und ein auditierbarer Steward-Workflow.
• GraphQL-Zugriff auf die aktuelle aufgelöste Entität und dokumentierte Ereignisbenachrichtigungen für nachgelagertes Mastering.
• Deployment innerhalb der von der Bank geforderten Kontrollgrenze.
• Eigentümerschaft an gemasterten Daten und ein getesteter Exit-Pfad.
• Integrationspunkte für Sanktions-, PEP- und Adverse-Media-Prüfungen.

Die endgültige Kaufentscheidung ist klar. Behalten Sie Ihren Mastering Layer, wenn er Governance, Survivorship und Veröffentlichung bereits verantwortet. Kaufen Sie die spezialisierte Engine für Normalisierung, Matching, Identity Graphs, Erklärungen und kontinuierliche Änderungen. Wählen Sie ein umfassenderes MDM-Programm, wenn die fehlende Fähigkeit das Betriebsmodell selbst ist.

Demo buchen, um die Grenze rund um Ihren aktuellen Customer Master festzulegen. Sie können auch Tilores Studio kostenlos testen und den Identity Layer mit Ihren eigenen Datensätzen testen.

Häufig gestellte Fragen

Kann Tilores als Matching Engine arbeiten, während unsere Bank den Golden Record verantwortet?

Ja. Tilores kann einen Golden Record ausformen, wenn diese Verantwortung im Identity Layer liegt. In der hier beschriebenen Architektur wendet der Mastering Layer der Bank Survivorship-, Freigabe- und Veröffentlichungsregeln an, während ihr Beschaffungsvertrag die erforderlichen Entity-Resolution-Fähigkeiten und die Nachweisgrenze definiert.

Ersetzt diese Architektur unsere MDM-Plattform?

Tilores kann neben einer bestehenden MDM-Plattform oder einem Customer Master als Entity Resolution Layer eingesetzt werden. Die bestehende Plattform kann Domain Governance, Workflow, Survivorship und Verteilung beibehalten, während Tilores eine aktuelle und erklärbare Identität bereitstellt.

Wie erreichen Matching-Änderungen den Golden Record?

Tilores dokumentiert Benachrichtigungen zu CREATE-, UPDATE-, MERGE-, SPLIT- und DELETE-Ereignissen mit den betroffenen Entitäts- und Datensatzkennungen. Der Mastering Layer der Bank verarbeitet die relevanten Benachrichtigungen, berechnet betroffene Profile neu und veröffentlicht die geänderten Golden Records erneut. Anwendungen rufen die aktuell aufgelöste Entität und relevante Nachweise an Entity Edges über GraphQL ab.

Kann die Bank erklären, warum zwei Datensätze verknüpft wurden?

Tilores dokumentiert Regelkennungen an Entity Edges. Eine Bank kann die relevante Edge über GraphQL abrufen und ihre eigene Prüfentscheidung sowie unterstützende Nachweise aufbewahren. Ein Schwellenwert allein ist keine Erklärung.

Wie unterstützt das Design Sanktions-, PEP- und Adverse-Media-Prüfungen?

Entity Resolution konsolidiert die Kundenidentität und die zugehörigen Datensätze vor dem Screening. Screening-Werkzeuge und Datenquellen bewerten anschließend diesen aufgelösten Kontext. Die Bank behält die Verantwortung für Screening-Richtlinien, Eskalation und die endgültige Compliance-Entscheidung.

Quellen

1. How to Create a Golden Record?, Tilores-Dokumentation.
2. Tilores API Documentation, Tilores-Dokumentation.
3. Rules Configuration, Tilores-Dokumentation.
4. Tilores MCP Server, Tilores-Dokumentation.
5. Deployment Options, Tilores.
6. Regulation (EU) 2016/679, General Data Protection Regulation, Europäische Union.
7. Risk data aggregation and risk reporting (BCBS 239), Basler Ausschuss für Bankenaufsicht.
8. The FATF Recommendations: Recommendation 10 and Interpretive Note to Recommendation 10, Financial Action Task Force.
9. Specialised coverage, OpenSanctions.
10. Methods for Record Linkage and Bayesian Networks, William E. Winkler, US Census Bureau.