Quant Memo
Foundational

Ticker Changes, CUSIP/ISIN Mapping and Symbology

Why a company's ticker symbol is not a permanent identifier the way its CUSIP or ISIN is, and why any historical database has to track ticker changes carefully to avoid silently splicing two different companies' histories together.

Prerequisites: ISIN, CUSIP, SEDOL and Tickers

A ticker symbol feels permanent because it's what everyone says out loud — "buy some XYZ" — but it's actually just a convenient, exchange-assigned label that can and does change: after a rebrand, a merger, moving to a different exchange, or simply because another, larger company got there first and claimed the symbol. What actually stays fixed to a specific security through all of that is a different kind of identifier entirely — a CUSIP (North America) or ISIN (international) — issued once and, in the vast majority of cases, never reused or reassigned to a different security afterward.

Why this distinction matters for data

Because tickers get recycled, a historical database that tracks a security purely by ticker symbol risks a serious error: if company A used ticker "XYZ" until it was delisted in 2015, and an unrelated company B was later assigned the same now-free ticker "XYZ" in 2019, naively querying "the price history of XYZ" can silently splice company A's pre-2015 history onto company B's post-2019 history as if they were one continuous security — they are not. CUSIPs and ISINs don't have this problem in the same way: they're built to stay bound to one specific security and are the identifier that corporate-action and reference-data systems key off internally, with the ticker treated as just a display label that can be looked up for a given date.

A concrete example

A company renames itself and changes its ticker from "OLDCO" to "NEWCO" on a specific date, keeping the same CUSIP throughout since it's legally the same entity. A price database correctly built around CUSIP as the primary key handles this cleanly — the same underlying security's history continues uninterrupted, just with a different display ticker before and after the change date. A database keyed naively on ticker symbol alone would instead see "OLDCO" apparently stop trading and "NEWCO" suddenly appear from nowhere, potentially treating what is genuinely one continuous company as two unrelated ones, or worse, later reassigning "OLDCO" to some unrelated future company and quietly merging their histories.

What this means in practice

Any serious historical dataset or backtesting pipeline needs a symbology mapping table that tracks, for every security, which ticker was valid over which date range, keyed to a stable identifier like CUSIP or ISIN underneath — exactly the kind of corporate-action reference data that gets maintained as its own dataset, separate from price history itself. Skipping this and matching purely on today's ticker symbol against historical records is one of the most common, and most quietly damaging, mistakes in building a point-in-time-correct dataset.

A ticker symbol can change or be reassigned to a completely different company over time, while a CUSIP or ISIN stays bound to one specific security permanently. Any historical database needs a symbology mapping table tracking ticker validity by date range, keyed to the stable identifier, to avoid silently splicing unrelated companies' histories together.

Related concepts

Further reading

  • Milne, The Complete Guide to Corporate Actions Processing, ch. 6
ShareTwitterLinkedIn