Echtzeit-Identity-Resolution unter der DSGVO: Wie regulierte Institute es umsetzen (2026)
Kurzfassung: Echtzeit-Identity-Resolution unter der DSGVO bedeutet, Datensätze bei der Ingestion aufzulösen, Herkunft und Richtliniennachweise vorzuhalten und den aktuellen aufgelösten Kontext abzurufen, sobald ein regulierter Prozess ihn anfragt. Die Compliance-Arbeit besteht nicht nur aus dem Abgleich: Legen Sie die Rechtsgrundlage fest, minimieren Sie die Attribute, steuern Sie Residenz und Übermittlungen, halten Sie Löschregeln ein und führen Sie einen klaren Audit-Trail.
Wie gehen regulierte Institute mit Echtzeit-Identity-Resolution unter der DSGVO um?
Sie behandeln Echtzeit-Identity-Resolution als kontrollierte Verarbeitung personenbezogener Daten und nicht als Abkürzung an der DSGVO vorbei. Das praktische Muster ist einfach: die Entität auflösen, sobald Datensätze eingelesen werden, die Herkunft der Quelldatensätze und die Belege für die Übereinstimmung erhalten und operative Systeme zur Abfragezeit den aktuellen aufgelösten Kontext abrufen lassen.
Das ist wichtig, weil regulierte Prozesse selten auf eine nächtliche Bereinigung warten können. Eine Sanktionsprüfung, eine Aktualisierung des Kundenrisikos, eine Abfrage im Callcenter oder eine Kreditentscheidung braucht möglicherweise sofort die aktuellste bekannte Sicht auf die Entität. Tilores beschreibt dieses Muster so: Kundendaten aus mehreren Quellen einlesen, Duplikate in Echtzeit auflösen und einheitliche Entitätsprofile über Abfrageschnittstellen wie GraphQL zurückgeben. Die Tilores-Dokumentation zum Matcher unterstützt außerdem deterministisches Matching, Fuzzy Matching und probabilistisches Matching, sodass die Regeln exakte Kennungen nutzen können, wo es sie gibt, und Ähnlichkeitsbewertung dort, wo unsaubere Realdaten es erfordern.
Die DSGVO verändert, wie diese Architektur gesteuert wird. Sie verbietet Identity Resolution nicht. Sie verlangt eine Rechtsgrundlage, Zweckklarheit, Datenminimierung, Sicherheitsmaßnahmen, Aufbewahrungsdisziplin und Rechenschaftspflicht. Tilores sollte deshalb innerhalb einer kontrollierten Datenlandschaft stehen, verbunden mit KYC-, AML-, Kundenservice-, MDM-, CDP- und Warehouse-Systemen, wobei jede nachgelagerte Nutzung einem Zweck und einem Satz an Kontrollen zugeordnet ist.
Welche DSGVO-Anforderungen sollte die Architektur zuerst erfüllen?
Die erste Entwurfsaufgabe besteht darin, DSGVO-Grundsätze in Systemverantwortlichkeiten zu übersetzen. Die folgende Tabelle ist keine Rechtsberatung, aber sie ist die Checkliste, die ein Umsetzungsteam durchgehen sollte, bevor es Echtzeit-Auflösung in einen regulierten Prozess bringt.
| Kontrollbereich | DSGVO-Bezug | Was die Auflösungsschicht nachweisen muss |
|---|---|---|
| Rechtsgrundlage und Zweck | Artikel 6 | Verarbeitungszweck, Rechtsgrundlage, Quellsysteme und nachgelagerte Nutzer sind dokumentiert, bevor Daten abgeglichen werden. |
| Minimierung und Speicherbegrenzung | Artikel 5 | Das Modell nutzt nur die für den Anwendungsfall nötigen Attribute und wendet Aufbewahrungsregeln auf Datensätze, Belege und abgeleiteten Entitätskontext an. |
| Datenschutz durch Technikgestaltung und Voreinstellung | Artikel 25 | Zugriff, Herkunft, Löschung und eine standardmäßig minimale Datenfreigabe sind entworfen, bevor der Prozess live geht. |
| Steuerung des Auftragsverarbeiters | Artikel 28 | Die Rollen von Verantwortlichem und Auftragsverarbeiter sind klar, einschließlich Hosting-Modell, Zugriffsrechten und operativen Zuständigkeiten. |
| Residenz und Übermittlungen | Artikel 44 und Artikel 45 | Das Team weiß, wo personenbezogene Daten gespeichert sind und ob eine Übermittlung außerhalb der zulässigen Umgebung stattfindet. |
| Rechenschaftspflicht und Sicherheit | Artikel 30 und Artikel 32 | Verarbeitungsverzeichnis, Abfrageprotokolle, Zugriffskontrollen und Löschvorgänge lassen sich bei einer Prüfung oder Vorfallanalyse rekonstruieren. |
Wie sollte die Datenresidenz gehandhabt werden?
Die DSGVO ist nicht nur eine Standortregel, doch Residenz wird trotzdem zu einer praktischen Kontrolle, weil Kapitel V die Übermittlung personenbezogener Daten an Drittländer oder internationale Organisationen regelt. Wenn eine Bank, ein Versicherer, ein Fintech oder eine Auskunftei vorgibt, dass personenbezogene Daten in einem definierten Cloud-Konto, einer definierten Region oder einer definierten VPC bleiben müssen, muss die Identity-Resolution-Schicht diese Grenze respektieren.
Tilores ist hier hilfreich, weil es entweder in einer von Tilores verwalteten Infrastruktur oder innerhalb eines Kunden-AWS-Kontos betrieben werden kann. Die Tilores-Seite zur Datenschutz-Compliance beschreibt, dass im Kundenkonto-Modell die Daten innerhalb der Kunden-VPC bleiben können, ohne dass Tilores Zugriff hat, und dass Audit-Trails, Zugriffskontrollen und Werkzeuge zur automatisierten Löschung dennoch unterstützt werden. Das ist die richtige Form für Institute, die die Auflösungs-Engine nah an ihren operativen Systemen betreiben wollen, ohne personenbezogene Daten in eine unkontrollierte gemeinsame Umgebung zu verschieben.
Die Entscheidung über die Residenz sollte fallen, bevor Matching-Regeln justiert werden. Sobald Datensätze in eine Auflösungsschicht fließen, muss das Team wissen, ob Quellattribute, Match-Kanten, Entitätskennungen, Abfrageprotokolle und Löschnachweise sämtlich innerhalb derselben kontrollierten Grenze bleiben.
Wie wirken sich Rechtsgrundlage und Verarbeitungszweck auf das Matching aus?
Entity Resolution kann keine Rechtsgrundlage für eine Verarbeitung schaffen. Artikel 6 verlangt, dass die Organisation die Grundlage für die Verarbeitung überhaupt erst benennt. Eine KYC-Aktualisierung, eine Betrugsuntersuchung, eine Abfrage im Kundenservice und eine Zusammenführung für Marketingzwecke sind unterschiedliche Zwecke, und sie sollten Kontrollen nicht versehentlich voneinander erben.
Das sicherste Betriebsmodell besteht darin, zuerst den Zweck festzulegen und dann zu entscheiden, welche Attribute für den Abgleich nötig sind. In regulierten Anwendungsfällen der Finanzdienstleistung können exakte Kennungen angemessen sein, sofern sie vorliegen, doch echte Daten enthalten auch Tippfehler, Namensvarianten, Adressänderungen und unvollständige Datumsangaben. Deshalb braucht eine Auflösungsschicht deterministisches Matching für harte Kennungen und probabilistisches oder unscharfes Matching für Datensätze, bei denen Konfidenz bewertet und nicht unterstellt werden muss.
Tilores beschreibt sowohl deterministisches, regelbasiertes Matching als auch probabilistisches Matching bereits in seiner öffentlichen Produkt- und Matcher-Dokumentation. In einem DSGVO-konform gesteuerten Prozess müssen diese Fähigkeiten mit dokumentierten Verarbeitungszwecken, Match-Schwellen, Zugriffsregeln und Aufbewahrungsrichtlinien zusammenspielen.
Wie funktionieren Minimierung, Aufbewahrung und Löschung bei aufgelösten Entitäten?
Echtzeit-Auflösung heißt nicht, jedes Attribut für immer zu behalten. Artikel 5 umfasst Datenminimierung und Speicherbegrenzung, deshalb sollte das System die aktuelle Sicht auf die Entität von den Quellbelegen und von allen alten Attributen trennen, die dem Zweck nicht mehr dienen.
Ein praxistauglicher Entwurf hält die Entität nützlich, ohne sie in ein ungepflegtes Archiv zu verwandeln. Speichern Sie die Verknüpfungen zu den Quelldatensätzen, die nötig sind, um zu erklären, warum Datensätze zusammengeführt wurden. Behalten Sie die Match-Bewertungen, Regeln oder Kanten, die Prüfung und Korrektur ermöglichen. Kopieren Sie keine zusätzlichen Felder in die aufgelöste Sicht, nur weil sie in der Quelle vorhanden sind. Wo Aufbewahrungsregeln eine Löschung verlangen, müssen sowohl die aus der Quelle abgeleiteten Attribute als auch jeder darauf aufbauende aufgelöste Kontext verfallen.
Artikel 17 ist ebenfalls relevant, weil ein berechtigtes Löschverlangen erfordern kann, dass sich die Löschung über verknüpfte Datensätze und abgeleitete Sichten fortpflanzt. Unsere Compliance-Kontrollen umfassen Datenherkunft, kaskadierende Löschungen und Werkzeuge zur automatisierten Löschung. Die Tilores-API-Dokumentation stellt zudem Abfragen für Entitäten und für die Entität zu einem Datensatz bereit, was operativ wichtig ist: Ein Team muss die betroffene aufgelöste Entität zu einem bestimmten Quelldatensatz finden können, bevor es die richtigen Informationen korrigieren oder löschen kann.
Was sollte der Audit-Trail belegen?
Der Audit-Trail sollte belegen, wie die Entität zusammengesetzt wurde, wer sie genutzt hat und was sich im Zeitverlauf geändert hat. Artikel 30 verweist auf das Verzeichnis von Verarbeitungstätigkeiten, Artikel 32 auf die Sicherheit der Verarbeitung. In der Echtzeit-Identity-Resolution werden daraus konkrete Nachweise.
Für jeden regulierten Prozess sollte die Organisation die Quellsysteme, die für den Abgleich genutzten Schlüsselfelder, die Match-Richtlinie, die Konfidenzbelege, die anfragende Stelle, das Exportziel, die Entscheidung der Zugriffskontrolle und die Lösch- oder Korrekturmaßnahme zeigen können. Unsere Kontrollen zur Datenschutz-Compliance protokollieren Abfragen, Exporte und Löschungen, und unsere Produktseite beschreibt einen vollständigen Audit-Trail für abgerufene Entitätsgraphen. Diese Nachweise erlauben es einem Compliance- oder Betriebsteam, den Prozess später zu erklären, ohne ihn aus Warehouse-Tabellen rekonstruieren zu müssen.
Entscheidend ist nicht, dass jeder Nutzer jeden Nachweis sehen sollte. Entscheidend ist, dass die Nachweise existieren, rollenbasiert eingeschränkt sind und sich bei einer Prüfung, einer Auskunftsanfrage, einer Modellüberprüfung oder einer Vorfalluntersuchung rekonstruieren lassen.
Wo fügt sich das Screening auf Sanktionen, PEPs und negative Medienberichte ein?
Lösen Sie zuerst die Entität sauber auf und gleichen Sie dann den aktuellen Kontext gegen die passenden Daten zu Sanktionen, PEPs und negativer Medienberichterstattung ab. Erscheint dieselbe Person in Onboarding, Transaktionen und Betreuung unter drei Schreibweisen, erhöht ein isoliertes Screening jeder einzelnen Schreibweise sowohl das Risiko übersehener Treffer als auch das vermeidbarer Fehlalarme.
OpenSanctions ist ein Beispiel für eine öffentliche Quelle für Risikodaten zu Sanktionen, PEPs und negativer Medienberichterstattung. Die Identity-Resolution-Schicht sollte weder als Screening-Engine noch als Ersatz für ein Fallmanagement betrachtet werden. Sie sollte den Personen- oder Organisationskontext zusammenstellen, den der Screening-Prozess braucht, die Belege für diese Zusammenstellung erhalten und sie dem AML- oder KYC-Prozess im Moment der Prüfung zur Verfügung stellen.
Es ist dieselbe Architektur, die Tilores im Artikel zu AML und KYC in Echtzeit und in den Inhalten zu Perpetual KYC beschreibt: Der Kundenkontext muss aktuell genug bleiben für die laufende Überwachung und nicht nur für die Momentaufnahme beim Onboarding.
Wo sollte Tilores neben MDM-, CDP-, KYC- und Warehouse-Systemen stehen?
Tilores sollte neben MDM-, CDP-, KYC-, AML- und Warehouse-Systemen stehen. Es sollte nicht als Ersatz für diese Systeme positioniert werden. Das MDM kann der Governance-Bestand für die gepflegten Domänen bleiben. Eine CDP kann die Aktivierungsschicht für freigegebene Kundenansprache bleiben. Eine KYC- oder AML-Plattform kann die Prozess- und Fallmanagementschicht bleiben. Das Warehouse kann der analytische Speicher bleiben.
Die Rolle von Tilores ist enger und operativer: Entitätskontext auflösen und zusammensetzen, sobald Datensätze eintreffen, und autorisierte Systeme die aktuelle aufgelöste Sicht abfragen lassen, wenn sie sie brauchen. Genau deshalb verweisen der Entity-Resolution-Leitfaden für KYC und Customer 360, der Artikel über Auskunfteien und der AML-Artikel auf dasselbe Betriebsprinzip. Je schneller ein Institut die richtige Person oder Organisation auflösen kann, desto schneller kann der nachgelagerte Prozess auf Basis korrekten Kontexts handeln.
Deshalb kommt es auch auf ehrliche Produktaussagen an. Matching ist nicht nur deterministisch. Es ist deterministisch, wo Kennungen belastbar sind, probabilistisch oder unscharf, wo Daten unsauber sind, und durch Richtlinien gesteuert, wo ein reguliertes Institut erklären können muss, was geschehen ist.
FAQ
Verhindert die DSGVO Echtzeit-Identity-Resolution?
Nein. Die DSGVO verbietet Echtzeit-Identity-Resolution nicht. Sie verlangt für die damit verbundene Verarbeitung personenbezogener Daten eine Rechtsgrundlage, Zweckklarheit, Minimierung, Sicherheit, Aufbewahrungsdisziplin und Rechenschaftspflicht.
Wann sollte die Entität aufgelöst werden?
Für operative Prozesse: die Entität bei der Ingestion auflösen und zusammensetzen und dann zur Abfragezeit den aktuellen aufgelösten Kontext abrufen. So muss niemand auf eine Batch-Bereinigung warten, wenn Sanktionsscreening, KYC-Aktualisierungen oder Serviceentscheidungen aktuellen Kontext brauchen.
Ersetzt Tilores MDM-, CDP- oder KYC-Systeme?
Nein. Tilores sollte neben MDM-, CDP-, KYC-, AML- und Warehouse-Systemen stehen. Es liefert eine Auflösungsschicht in Echtzeit, damit diese Systeme mit aktuellem Entitätskontext arbeiten können.
Wie funktionieren Löschverlangen, wenn Datensätze aufgelöst sind?
Ein berechtigtes Löschverlangen sollte vom Quelldatensatz bis zur betroffenen aufgelösten Entität und zu jedem abgeleiteten Kontext nachverfolgt werden. Die Auflösungsschicht braucht Herkunftsnachweise, eine Fortpflanzung der Löschung und einen Prüfeintrag darüber, was entfernt wurde.
Wo fügt sich das Screening auf Sanktionen und PEPs ein?
Das Screening sollte laufen, nachdem die Person oder Organisation für den Prozess sauber genug aufgelöst wurde. Die Auflösungsschicht stellt Kontext und Belege zusammen; die Screening- und Fallmanagementsysteme treffen und verwalten die Risikoentscheidung.
Sehen Sie, was aufgelöste Entitätsdaten für Ihr Unternehmen — und Ihre KI — leisten.