Entity-Resolution und Ticker-Mapping warum dieselbe Firma fuenf Namen hat.

Es ist einer der unsichtbarsten und zugleich folgenreichsten Fehler in jeder Trading-Pipeline: Daten werden mit dem falschen Wertpapier verknüpft. Eine Nachricht über Firma A landet beim Kurs von Firma B, weil ein Ticker wiederverwendet wurde. Ein Quartalsergebnis wird der falschen juristischen Einheit zugeordnet, weil ein Konzern umfirmiert hat. Eine ISIN kollidiert, ein CUSIP wurde recycelt, ein Symbol nach einem Delisting an eine neue Firma vergeben. Solche Fehler erzeugen keine Fehlermeldung — sie erzeugen still falsche Features, falsche Labels und am Ende falsche Trades. Entity-Resolution ist die Disziplin, die diese Identitäts-Zuordnung sauber löst: dieselbe reale Firma über alle Datenquellen und über die Zeit hinweg eindeutig zu erkennen, obwohl sie unter fünf verschiedenen Namen und Identifiern auftaucht. Dieser Beitrag erklärt, warum Identifier so unzuverlässig sind, welche Mapping-Strategien funktionieren, wie man historische Gültigkeit korrekt behandelt und warum dieser eher undankbare Pflichtteil über die Belastbarkeit der gesamten Pipeline entscheidet.

Warum dieselbe Firma fünf Identitäten hat.

Ein börsennotiertes Unternehmen wird in unterschiedlichen Datenquellen über unterschiedliche Schlüssel referenziert: ein Börsenticker, eine ISIN, ein CUSIP, ein SEDOL, eine interne Anbieter-ID, dazu der Firmenname in mehreren Schreibweisen. Keiner dieser Schlüssel ist über alle Quellen und über die Zeit hinweg stabil und eindeutig.

Ticker sind börsenspezifisch und werden wiederverwendet. ISINs identifizieren Wertpapiere, nicht Firmen — eine Firma kann mehrere haben, und nach Corporate Actions ändern sie sich. CUSIPs werden nach einer gewissen Zeit recycelt. Firmennamen schließlich sind ein Albtraum: „Apple“, „Apple Inc.“, „Apple Inc“, „APPLE INCORPORATED“ — alles dieselbe Firma, aber als Strings völlig verschieden.

Das Ergebnis: Ohne eine bewusste Auflösungsschicht verknüpft man Datenquellen über naive String- oder Ticker-Gleichheit — und liegt regelmäßig falsch. Die Fehler sind selten, aber wenn sie auftreten, sind sie systematisch und teuer.

Die häufigsten Fallen im Detail.

Vier Kollisionstypen verursachen den Großteil der Probleme:

• Ticker-Recycling: Ein Symbol wird nach einem Delisting frei und Jahre später an eine völlig andere Firma vergeben. Ein naiver Join über den Ticker mischt zwei Firmen in einer Zeitreihe — der gefährlichste Fall, weil er unsichtbar bleibt.
• Ticker-Wechsel: Eine Firma ändert ihr Symbol (Umfirmierung, Börsenwechsel). Wer nur den aktuellen Ticker kennt, verliert die Historie unter dem alten Symbol.
• Mehrfachnotierung: Dieselbe Firma ist an mehreren Börsen mit unterschiedlichen Tickern und ISINs gelistet. Behandelt man sie als getrennte Entitäten, doppelt man Exposure und verzerrt Korrelationen.
• Identifier-Kollision: CUSIP- oder ISIN-Recycling und schlicht fehlerhafte Datenanbieter-Zuordnungen führen dazu, dass ein Schlüssel auf die falsche Firma zeigt.

Allen gemeinsam ist: Sie erzeugen keinen Crash, sondern stille Datenverfälschung. Ein Modell trainiert munter weiter — auf teils falsch verknüpften Daten. Der Schaden zeigt sich erst, wenn live Geld auf Basis dieser Verknüpfungen bewegt wird.

Die zeitliche Dimension ist entscheidend.

Der häufigste konzeptionelle Fehler ist, Mapping als statische Tabelle zu behandeln: ein Ticker, eine Firma, fertig. In Wahrheit ist die Zuordnung zeitabhängig. Welcher Firma ein Ticker gehörte, hängt vom Datum ab. Welche ISIN gültig war, ändert sich nach Splits und Fusionen.

Eine korrekte Mapping-Schicht ist deshalb historisch versioniert: Jede Zuordnung gilt für einen bestimmten Zeitraum. Ein Join muss nicht nur fragen „Welche Firma hat Ticker XYZ?“, sondern „Welche Firma hatte Ticker XYZ am Datum D?“. Das ist eng verwandt mit Point-in-Time-Datenhaltung und bitemporaler Modellierung — und aus demselben Grund unverzichtbar.

Wer diese zeitliche Gültigkeit ignoriert, baut Look-Ahead-Bias direkt ins Fundament: Man verknüpft heutiges Wissen über Firmenidentitäten mit historischen Daten, in denen diese Zuordnung anders war oder noch gar nicht existierte. Der Backtest profitiert von Information, die live nie verfügbar war.

Strategien zur Auflösung.

Entity-Resolution kombiniert meist mehrere Techniken, in aufsteigender Komplexität:

In der Praxis bildet ein gepflegter Security-Master das Rückgrat — eine zentrale Referenz, die jeder Firma eine stabile interne ID gibt und alle externen Identifier mit ihrer historischen Gültigkeit darauf abbildet. Externe Quellen werden gegen diesen Master aufgelöst, nicht direkt miteinander verknüpft. Der LEI (Legal Entity Identifier) hilft zusätzlich, weil er auf die juristische Einheit zielt — gerade bei Konzernstrukturen wertvoll.

Corporate Actions und Konzernstrukturen.

Besonders heikel wird Entity-Resolution bei Strukturveränderungen. Eine Fusion verschmilzt zwei Identitäten zu einer — die Historie beider Firmen muss korrekt zusammengeführt oder bewusst getrennt gehalten werden, je nach Anwendungsfall. Ein Spin-off spaltet eine Tochter ab, die plötzlich eine eigene Identität braucht, deren „Vorgeschichte“ aber im Mutterkonzern liegt.

Auch die Frage, was die „Entität“ überhaupt ist, hängt vom Zweck ab. Für Fundamentaldaten interessiert die juristische Einheit. Für Konsumdaten interessiert vielleicht die Marke — die zu einer ganz anderen börsennotierten Mutter gehören kann als der Name vermuten lässt. Eine saubere Auflösung muss diese Ebenen (Marke, Tochter, börsennotierte Mutter) explizit unterscheiden.

Hier verzahnt sich Entity-Resolution mit der korrekten Behandlung von Corporate Actions. Wer Splits, Fusionen und Spin-offs in der Identitäts-Zuordnung nicht nachzieht, erzeugt genau die Phantom-Sprünge, die jede Auswertung verfälschen.

Validierung und Monitoring.

Entity-Resolution ist nie „fertig“. Jede neue Datenlieferung kann unbekannte Namen, neue Ticker oder kollidierende IDs enthalten. Deshalb braucht es laufende Kontrolle statt einmaliger Einrichtung.

Praktisch bewährt haben sich automatische Plausibilitätsprüfungen: Wie viel Prozent einer neuen Lieferung lassen sich eindeutig auflösen? Ein plötzlicher Einbruch der Match-Rate ist ein Alarmsignal — meist hat der Anbieter Format oder Namenskonvention geändert. Unaufgelöste Einträge gehören in eine Review-Queue, nicht stillschweigend verworfen oder geraten.

Ebenso wichtig: Stichproben gegen eine unabhängige Quelle. Verknüpft das Mapping wirklich die richtige Firma? Schon wenige manuell geprüfte Fälle pro Lieferung decken systematische Fehler früh auf. Der Grundsatz lautet, lieber kontrolliert eine Verknüpfung verweigern als blind eine falsche herstellen — eine fehlende Zuordnung ist sichtbar und reparierbar, eine falsche bleibt verborgen.

Aufwand, Nutzen und ehrliche Grenzen.

Entity-Resolution ist undankbar: Sie produziert kein sichtbares Feature und keine schöne Backtest-Kurve. Ihr Nutzen ist negativ definiert — sie verhindert Fehler, die sonst niemand bemerkt hätte. Genau deshalb wird sie chronisch unterschätzt und unterbudgetiert.

Der Aufwand ist real. Einen belastbaren Security-Master aufzubauen und zu pflegen, ist laufende Arbeit; kommerzielle Referenzdaten kosten Geld. Für ein kleines Universum weniger liquider Instrumente mag eine schlanke, manuell gepflegte Mapping-Tabelle reichen. Für breite Aktienuniversen mit vielen Datenquellen wird es schnell zu einem eigenen Datenprodukt.

Und auch hier gibt es Grenzen: Manche Identitäts-Fragen sind schlicht mehrdeutig, etwa bei komplexen Holdingstrukturen oder kürzlichen Umstrukturierungen. Eine ehrliche Pipeline markiert solche Fälle als unsicher, statt eine Scheingenauigkeit vorzutäuschen. Das Ziel ist nicht hundertprozentige Auflösung um jeden Preis, sondern korrekte Zuordnung dort, wo sie eindeutig ist — und sichtbare Unsicherheit dort, wo sie es nicht ist.

Sie verknüpfen mehrere Datenquellen und sind nicht sicher, ob Ihr Ticker- und Entity-Mapping wirklich die richtigen Firmen zusammenbringt? Unverbindlich anfragen — wir prüfen Ihre Mapping-Schicht auf historische Gültigkeit, Recycling-Fallen und Konzernstrukturen und legen ein Fundament, auf dem Ihre Features und Labels verlässlich stehen.