Ein Kunde, viele Rechtsträger: Eine einheitliche Kundensicht über Geschäftsbereiche und Jurisdiktionen hinweg

Kurzfassung: Eine gruppenweite Kundensicht sollte eine gemeinsame Identitätsreferenz liefern, ohne so zu tun, als wäre die Gruppe ein einziger Rechtsträger. Lösen Sie die Datensätze auf, die die Richtlinien erlauben, behalten Sie Quellenzugehörigkeit und Originalwerte bei und setzen Sie durch, welche Tochtergesellschaft welche Attribute sehen darf. Wo Daten nicht zusammengeführt werden dürfen, betreiben Sie dieselbe Resolution-Engine innerhalb jedes freigegebenen Perimeters und tauschen nur gesteuerte Entitätsreferenzen oder zulässige Ergebnisse aus.

Entwerfen Sie eine gemeinsame Sicht, ohne Ihre Kontrollen einzuebnen. Besprechen Sie Deployment- und Governance-Grenzen mit unserem Team oder testen Sie das Matching-Verhalten lokal. Demo buchen oder Tilores Studio kostenlos testen.

Auf dieser Seite

Warum entstehen in einer Gruppe mehrere Kundensichten?
Funktioniert die Sicht auch ohne zentrale Datenhaltung?
Wo liegt die aufgelöste Sicht?
Wie gehen Sie mit zwei Jurisdiktionen um?
Was ist mit Einwilligung und Aufbewahrung?
Welches Deployment-Modell passt?
Häufige Fragen

Ein Kunde kann für die Gruppe eine Person sein und für die Unternehmen darin fünf separate Datensätze. Die Handelstochter kennt eine E-Mail-Adresse. Das Kreditgeschäft kennt einen Namen laut Ausweis und eine Anschrift. Das Servicecenter kennt eine Telefonnummer. Ein frisch übernommenes Unternehmen betreibt weiterhin sein eigenes CRM. Jeder einzelne Datensatz mag korrekt sein, doch kein System kann die Frage der Gruppe beantworten, ohne eine organisatorische Grenze zu überschreiten.

Diese Grenze ist nicht bloß technisch. Rechtsträger haben eigene Verträge, Zwecke, Aufbewahrungsfristen, Einwilligungsnachweise und Aufsichtsbehörden. Eine Single Customer View gelingt, wenn sie Identität auflöst und diese Kontrollen zugleich bewahrt. Sie scheitert, wenn „einheitlich“ als Erlaubnis verstanden wird, jedes Attribut in einem unbeschränkten Profil zusammenzuführen.

Warum entstehen in einer Gruppe mit mehreren Geschäftsbereichen mehrere Kunden?

Jeder Geschäftsbereich legt einen Kundendatensatz für den Prozess an, den er verantwortet. Das CRM identifiziert eine Vertriebsbeziehung. Die Abrechnung identifiziert den Vertragspartner. Der Support identifiziert den Anrufer. Das Marketing identifiziert ein erreichbares Mitglied der Zielgruppe. Eine regulierte Tochtergesellschaft identifiziert womöglich die Person oder den Rechtsträger, der einem Screening unterliegt. Das sind keine Duplikate aus Nachlässigkeit. Es sind lokale Sichten für unterschiedliche Verantwortlichkeiten.

Auch Identifikatoren verändern sich an den Rändern der Gruppe. Eine Tochtergesellschaft speichert ein nationales Telefonformat, eine andere nimmt die Ländervorwahl mit auf. Eine Person nutzt für ein Produkt eine private E-Mail-Adresse und für ein anderes die berufliche. Eine Muttergesellschaft schließt in einer Jurisdiktion Verträge, während eine Tochter in einer anderen bezahlt. Handelsregistereinträge, Geschäftsbezeichnungen und Adressen unterscheiden sich zwischen Märkten.

Übernahmen vervielfachen das Problem. Das übernommene Unternehmen bringt eigene Kundenschlüssel, Matching-Regeln und Aufbewahrungshistorien mit. Eine Migration mag die Systeme irgendwann konsolidieren, aber das Geschäft muss gemeinsame Kunden erkennen, bevor dieses Programm abgeschlossen ist.

Klassisches Master Data Management kann einen Golden Record steuern, und eine Customer Data Platform kann Identität für die Aktivierung auflösen. Beides kann in seiner Domäne die richtige Zuständigkeit sein. Die Lücke zwischen Rechtsträgern zeigt sich, wenn die aufgelöste Identität zusätzlich operative Anwendungen, mehrere Datenplattformen und mehrere rechtliche Perimeter bedienen muss, ohne dass eine Plattform zum Eigentümer sämtlicher Quellen wird.

Eine brauchbare Gruppenentität hat deshalb zwei Ebenen. Die erste ist eine dauerhafte Identitätsreferenz, die angibt, welche zulässigen Datensätze sich auf dieselbe Person oder denselben Rechtsträger beziehen. Die zweite ist eine autorisierte Sicht, die für den anfragenden Geschäftsbereich zusammengestellt wird. Die Referenz darf weiter geteilt werden als die zugrunde liegenden Attribute.

Lässt sich eine Single Customer View aufbauen, wenn Daten nicht zentralisiert werden können?

Ja. Zentralisierte Identität setzt keine zentralisierten Rohdaten voraus.

Das Standarddesign für eine Gruppe, deren Richtlinien eine Zusammenführung erlauben, ist ein Managed-Cloud-Deployment auf AWS, das die freigegebenen Gruppenquellen bedient. Die Engine nimmt die für das Matching nötigen Identitätsfelder auf, behält die Herkunft der Quelldaten bei und stellt die aktuelle Entität über GraphQL bereit. Anwendungen erhalten nur die Attribute, zu deren Nutzung sie berechtigt sind.

Wenn eine Jurisdiktion oder Tochtergesellschaft diese Felder nicht in das Gruppen-Deployment übertragen darf, platzieren Sie die Resolution-Engine innerhalb dieses Perimeters. Tilores unterstützt nach der Managed-AWS-Option auch Ihren eigenen AWS-Account, eine andere Cloud und On-Premise. Derselbe GraphQL-Vertrag und dasselbe Matching-Verhalten funktionieren über alle Modelle hinweg.

Jedes Deployment benötigt lediglich einen Key-Value-Store, eine Queue und Dateispeicher. Auf AWS sind diese Primitive DynamoDB, SQS und S3. Diese geringe Anforderung erlaubt es einer Gruppe, dieselbe Resolution-Funktion nahe an jedem freigegebenen Datenbestand zu betreiben, statt in jeder Region ein anderes Identitätsprodukt einzuführen.

Die Deployments können eine gesteuerte Referenz, eine Match-Aussage oder eine freigegebene Teilmenge austauschen statt roher Quelldatensätze. Was genau ausgetauscht wird, ist eine Richtlinienentscheidung. Manche Gruppen teilen eine pseudonyme Gruppen-Entitäts-ID. Andere erlauben nur eine Ja-oder-Nein-Antwort auf die Frage „Ist das ein bestehender Kunde der Gruppe?“, ohne offenzulegen, welche Tochtergesellschaft den Datensatz hält. Ein regulierter Anwendungsfall kann eine manuelle Prüfung verlangen, bevor eine Verknüpfung über Rechtsträger hinweg sichtbar wird.

Die Architektur darf nie den Eindruck erwecken, dass allein das Deployment eine Rechtsgrundlage für den Datenaustausch schafft. Sie verändert, wo die Funktion läuft und welche Daten bewegt werden müssen. Der Verantwortliche und die betroffenen Gruppengesellschaften entscheiden weiterhin über Zweck, Zugriff, Aufbewahrung und Offenlegung.

Wo liegt die aufgelöste Sicht, wenn Tochtergesellschaften eigene Systeme betreiben?

Die aufgelöste Sicht liegt als gemeinsamer Identitätsdienst neben den Systemen, nicht als deren Ersatz. Quell-CRMs, Abrechnungssysteme und Data Warehouses besitzen weiterhin ihre Datensätze und Prozesse. Sie hängen eine Gruppen-Entitätsreferenz an oder rufen sie ab, soweit die Richtlinie es erlaubt.

Es gibt drei gängige Muster.

Ein Gruppen-Deployment mit kontrollierten Sichten. Alle freigegebenen Quellen speisen eine Resolution-Engine. GraphQL-Abfragen wenden Berechtigungen für Aufrufer und Quellen an, sodass eine Tochtergesellschaft ihre autorisierte Sicht auf die Entität erhält. Das ist das einfachste Betriebsmodell, wenn Daten in einem Perimeter verarbeitet werden dürfen.

Deployments je Jurisdiktion mit einer Gruppenreferenz. Jeder Perimeter löst seine lokalen Datensätze auf. Ein kontrollierter Dienst bildet zulässige lokale Entitäts-IDs auf eine Gruppenreferenz ab. Rohe Identitätsattribute bleiben lokal. Dieses Modell erfordert mehr Abstimmung, reduziert aber grenzüberschreitende Datenbewegungen.

Auflösung je Rechtsträger mit vermittelten Abfragen. Es wird keine zentrale Zuordnung dauerhaft gespeichert. Ein autorisierter Prozess stellt lokalen Deployments eine eng gefasste Frage und kombiniert die zulässigen Antworten. Das eignet sich für stark eingeschränkte Fälle, erhöht aber die Latenz und erschwert gruppenweite Analysen.

Die folgende Governance-Entscheidungstabelle macht die Abwägungen explizit.

Entscheidung	Ein Gruppen-Deployment	Deployments je Jurisdiktion	Vermittelte lokale Abfragen
Ort der rohen Identitätsdaten	Freigegebener zentraler Perimeter	Verbleiben in jeder Jurisdiktion	Verbleiben bei jedem Rechtsträger
Gruppen-Entitätsreferenz	Nativ in einer Engine	Aus lokalen Entitäts-IDs abgeleitet	Gegebenenfalls nur flüchtig
Operative Einfachheit	Am höchsten	Mittel	Am niedrigsten
Lokale Kontrolle	Über Zugriffsrichtlinien durchgesetzt	Durch getrennte Deployments durchgesetzt	Maximale lokale Entscheidungshoheit
Gruppenweite Analysen	Direkt, sofern autorisiert	Erfordert freigegebenen Austausch von Entitäts-IDs	Auf zulässige Aggregate oder Antworten begrenzt
Passt am besten, wenn	Die Gruppe darf Identitätsfelder zusammenführen	Einzelne Regionen dürfen nicht zusammenführen	Austausch ist die Ausnahme und an eine konkrete Frage gebunden

Welches Muster Sie auch wählen: Speichern Sie zu jedem Datensatz das Quellsystem und die Quell-Datensatz-ID. Bewahren Sie Originalwerte neben normalisierten Werten auf. Ein Gruppenidentifikator ohne Herkunftsnachweis ist ein neues Datensilo, das niemand sicher korrigieren kann.

Nachgelagerte Teams sollten die Entitäts-ID nicht als universelle Berechtigung verstehen. Ein Marketingsystem darf vielleicht wissen, dass eine Person bereits Kunde ist, aber nicht den Saldo der Kredittochter oder das Support-Transkript sehen. Lösen Sie Identität einmal auf, autorisieren Sie die Datennutzung getrennt davon.

Wie gehen Sie mit einem Kunden um, den es in zwei Jurisdiktionen gibt?

Behandeln Sie jurisdiktionsübergreifende Identität als Aussage mit Belegen und Richtlinienbezug, nicht als automatischen Merge.

Beginnen Sie mit deterministischen Belegen, wo diese gültig sind. Eine gemeinsame Gruppen-Konto-ID oder eine verifizierte Registernummer kann stark sein. Fuzzy Matching fängt Schreibweisen- und Formatabweichungen ab. Probabilistisches Matching gewichtet mehrere Teilsignale. Halten Sie die drei Verfahren auseinander und machen Sie den Grund für eine Übereinstimmung nachprüfbar.

Derselbe Wert kann grenzüberschreitend unterschiedliche Risiken tragen. Namen werden womöglich in andere Schriftsysteme transliteriert. Adressformate lassen Bestandteile weg oder ordnen sie anders an. Telefonnummern werden neu vergeben. Nationale Identifikatoren dürfen die Quelljurisdiktion unter Umständen nicht verlassen oder nicht für einen neuen Zweck verwendet werden.

Konfigurieren Sie das Matching je Quelle und Jurisdiktion, statt einen globalen Schwellenwert anzuwenden. Ein Wert, der von einer regulierten Tochtergesellschaft verifiziert wurde, kann mehr Gewicht tragen als ein selbst ausgefülltes Marketingformular. Ein häufiger Familienname sollte weniger Gewicht haben als eine seltene Kombination. Reichen die Belege nicht aus, erhalten Sie zwei lokale Entitäten und geben die gruppenübergreifende Aussage zur Prüfung.

Firmenkunden bringen zusätzlich Hierarchien mit. Vertragspartner, zahlender Rechtsträger, Muttergesellschaft und Betriebsstätte können jeweils unterschiedliche Rechtsträger sein. Führen Sie eine Unternehmensgruppe nicht allein deshalb zusammen, weil Datensätze dieselbe Domain oder Adresse teilen. Modellieren Sie den aufgelösten Rechtsträger getrennt von Beziehungen wie „Tochter von“, „zahlt für“ oder „firmiert als“.

Im Finanzdienstleistungsbereich kann Identity Resolution eine vollständigere Grundlage für Sanktions-, PEP- und Adverse-Media-Screenings schaffen. Sie ersetzt diese Prüfungen nicht und entscheidet auch nicht über ihr Ergebnis. Die Gruppe sollte zudem festhalten, welcher Rechtsträger das Screening durchgeführt hat und welche Rechtsträger sich darauf stützen dürfen.

Ändert sich eine grenzüberschreitende Verknüpfung, halten Sie das Ereignis fest. Eine Korrektur kann eine Gruppenentität wieder in zwei lokale Entitäten aufteilen. Nachgelagerte Anwendungen brauchen eine Zuordnung und einen Gültigkeitszeitpunkt, damit sich historische Auswertungen reproduzieren lassen.

Was bedeutet das für Einwilligungen und Aufbewahrung über Rechtsträger hinweg?

Einwilligung und Aufbewahrung bleiben an den Zweck und den Rechtsträger gebunden, der die Daten erhoben hat. Zwei Datensätze aufzulösen, führt nicht ihre Berechtigungen zusammen.

Das entspricht der Zusammenfassung des Europäischen Datenschutzausschusses zu Datenschutz durch Technikgestaltung, die Zweckbindung, Datenminimierung, Richtigkeit, Speicherbegrenzung und Sicherheit als eigenständige Grundsätze behandelt. Auflösung verbessert Richtigkeit und Auffindbarkeit; sie hebt die übrigen Grundsätze nicht auf. Die ICO-Leitlinien zu Vereinbarungen über die gemeinsame Datennutzung verlangen ebenso, dass Organisationen Zweck, Rollen, Datenverarbeitung und Standards dokumentieren, bevor personenbezogene Daten geteilt werden.

Der rechtliche Anker ist Artikel 5 der DSGVO, der Zweckbindung, Datenminimierung, Richtigkeit und Speicherbegrenzung als gleichzeitig geltende Pflichten behandelt. Ein Identitätsdesign auf Gruppenebene muss deshalb beides belegen: warum Datensätze zu einer Person gehören und warum ein bestimmter Verbraucher ein bestimmtes Attribut nutzen darf.

Bilden Sie Einwilligung, Sperrvermerke, Aufbewahrung und Rechtsgrundlagen als Metadaten mit Quellen- und Entitätskontext ab. Ein Kunde kann Produktinformationen einer Tochtergesellschaft zustimmen und einer anderen nicht. Eine gruppenweite Sperre kann für einen bestimmten Kanal gelten, während eine gesetzlich vorgeschriebene Servicenachricht weiterhin zulässig ist. Die Resolution-Schicht hilft, dieselbe Person über verschiedene Identifikatoren hinweg zu erkennen; das Richtliniensystem entscheidet, welche Handlung daraus folgt.

Nutzen Sie die aufgelöste Entität, um freigegebene Vorgänge vollständig zu machen. Übt eine Person ein wirksames Löschrecht aus, kann Identity Resolution helfen, die vom Antrag erfassten Datensätze zu finden. Jeder Rechtsträger wendet dabei weiterhin seine eigenen Pflichten und Ausnahmen an. Eine Tochtergesellschaft muss vielleicht ein Marketingprofil löschen, während eine andere Transaktionsdaten gesetzlich aufbewahrt.

Tilores kann Aufbewahrungsregeln je Datenquelle festlegen. Läuft ein Datensatz ab oder wird er gelöscht, wird die Entität neu organisiert und der Vorgang lässt sich auditieren. Eine Regel je Quelle ist in einer Gruppe unverzichtbar, weil eine einzige globale Aufbewahrungsfrist meist schlicht falsch ist.

Das Governance-Modell sollte beantworten:

welcher Rechtsträger einen Antrag entgegennimmt und prüft;
welche anderen Rechtsträger informiert werden;
welche Identifikatoren zum Auffinden verwandter Datensätze verwendet werden dürfen;
welcher Nachweis über die Erledigung zurückgemeldet wird;
welche Ausnahmen gelten und wer sie genehmigt;
ob die gruppenübergreifende Entitätsreferenz selbst aufbewahrt, ersetzt oder gelöscht werden muss.

Auditieren Sie Abfragen ebenso wie Änderungen. Ein gemeinsamer Identitätsdienst kann Beziehungen offenlegen, selbst wenn er Attribute zurückhält. Ungewöhnliche Abfragen über Rechtsträger hinweg gehören überwacht.

Welches Deployment-Modell passt zu einer Gruppe mit mehreren Rechtsträgern?

Wählen Sie das am wenigsten fragmentierte Modell, das den tatsächlichen Perimeter erfüllt.

Managed Cloud auf AWS ist der Ausgangspunkt, wenn die Gruppe freigegebene Identitätsfelder in einer verwalteten Grenze verarbeiten darf. Sie erhalten eine Engine, eine Konfiguration und eine operative Sicht, während Zugriffskontrollen die Berechtigungen der Tochtergesellschaften wahren.

Ihr AWS-Account passt zu einer Gruppe, die dieselbe AWS-Referenzarchitektur in ihrem eigenen kontrollierten Account betreiben will. Das ist sinnvoll, wenn Account-Eigentum, Netzwerk- oder Residency-Vorgaben das Managed-Modell ausschließen.

Eine andere Cloud passt zu einer Gruppe oder Jurisdiktion, deren freigegebener Cloud-Perimeter anderswo liegt. Vermeiden Sie es, Matching-Logik in einem separaten Produkt zu duplizieren, nur weil die umgebende Plattform eine andere ist.

On-Premise passt zu einer isolierten lokalen Umgebung. Es ist eine unterstützte Option für eine spezifische Kontrollanforderung – nicht das Leitdesign und kein Beleg dafür, dass alle anderen Modelle unsicher wären.

Situation der Gruppe	Empfohlener Ausgangspunkt	Zusätzlich nötige Kontrolle
Ein freigegebener Perimeter für die Identitätsverarbeitung	Managed Cloud auf AWS	Quellen- und Attributberechtigungen je Rechtsträger
Gruppe verlangt Infrastruktur im eigenen AWS-Account	Ihr AWS-Account	Betrieb, Netzwerk und Wiederherstellung auf Account-Ebene
Eine Jurisdiktion verlangt ihre freigegebene Cloud	Eine andere Cloud	Lokales Deployment plus gesteuerter Austausch von Entitäts-IDs
Ein Perimeter darf keine Cloud-Infrastruktur nutzen	On-Premise	Lokaler Betrieb plus eng freigegebener Föderationsweg
Austausch nur für konkrete Fragen erlaubt	Getrennte Deployments	Vermittelte GraphQL-Abfrage mit Zweck- und Audit-Kontrollen

Ziehen Sie die aktuellen Deployment-Optionen als Teil der Datenschutz-Folgenabschätzung heran. Das architektonische Ziel ist nicht Zentralisierung um ihrer selbst willen. Es ist eine verlässliche Identitätsfunktion, die dort läuft, wo die Richtlinien der jeweiligen Gruppe es zulassen.

Der Begriff „Single Customer View“ kann eine gefährliche Annahme verdecken: dass eine Sicht alles für alle enthalten sollte. Das bessere Design ist eine aufgelöste Identität mit mehreren rechtmäßigen, zweckgebundenen Sichten. Die Gruppe erkennt den Kunden. Jeder Rechtsträger weiß weiterhin, was er tun darf.

Häufige Fragen

Kann eine Gruppe eine gemeinsame Kundensicht aufbauen, ohne alle personenbezogenen Daten zusammenzuführen?

Eine Gruppe kann eine gemeinsame Kundensicht aufbauen, ohne jedes Attribut zusammenzuführen, indem sie innerhalb freigegebener Perimeter auflöst und gesteuerte Entitätsreferenzen oder zulässige Ergebnisse austauscht. Das Design hängt von der Rechtsgrundlage und den Datenaustauschregeln der Gruppe ab.

Schafft Entity Resolution eine Erlaubnis, Kundendaten zwischen Tochtergesellschaften zu teilen?

Entity Resolution schafft keine Erlaubnis zum Datenaustausch. Sie erkennt zusammengehörige Datensätze; jeder Rechtsträger braucht weiterhin einen gültigen Zweck, eine Rechtsgrundlage, eine Zugriffsregel und eine Aufbewahrungsrichtlinie für die Attribute, die er nutzt.

Wie sollte Einwilligung in einer gruppenweiten Kundensicht abgebildet werden?

Eine Einwilligung sollte an den Rechtsträger, den Zweck, den Kanal und den Erhebungskontext gebunden bleiben, die sie hervorgebracht haben. Eine Gruppenentität kann den geltenden Einwilligungsstatus ausweisen, ohne mehrere lokale Berechtigungen in eine universelle Berechtigung zu verwandeln.

Was passiert, wenn derselbe Kunde in zwei Jurisdiktionen auftaucht?

Wenn derselbe Kunde in zwei Jurisdiktionen auftaucht, bewahren Sie beide Quelldatensätze und die lokalen Kontrollen und bilden sie nur dort auf eine gesteuerte Gruppenreferenz ab, wo die Richtlinien es erlauben. Kopieren Sie das vollständige Profil nicht stillschweigend über Grenzen hinweg.

Welches Tilores-Deployment passt zu einer Gruppe mit mehreren Rechtsträgern?

Managed Cloud auf AWS ist die Standardwahl, wenn die Gruppe einen freigegebenen Perimeter nutzen darf. Setzen Sie auf den AWS-Account des Kunden, eine andere freigegebene Cloud, On-Premise oder getrennte Deployments, wenn Residency- und Betriebsvorgaben das erfordern.