4. The ticker lies: identifiers and recycling

Level 1: Where they come from and what they carry inside

You have spent three modules worrying about the numbers. Now the problem is the label that groups them. Almost everybody joins their sources on the ticker, because that is what comes out of the CSV and what you carry around in your head. It is the worst possible identifier, and it fails silently: it raises no exceptions, it simply hands you back the wrong company.

The ticker is a display label, not an identity

Three properties to burn into your memory:

• It is not stable over time. It changes with the brand. Facebook started trading as META in June 2022; Google reorganized under Alphabet in 2015 and split its shares across two codes with different voting rights.
• It gets recycled. When a company disappears, its code goes back into the exchange's inventory and can be handed to another. Twitter was delisted after being bought in 2022 and freed up its code. General Motors went bankrupt in 2009, its old shares were relegated to the over-the-counter market and the new company relisted in 2010, reclaiming the same three-letter code.
• It is not unique across markets. The same code can belong to different companies in New York, London, Frankfurt or Madrid. Which is why vendors invent their own suffixes, and those are not interchangeable between one another.

The operational conclusion: a ticker only identifies something if it comes with a market and a date range.

Identifiers that do hold up

• CIK. The number the SEC assigns to every entity that files documents. Stable and free. It identifies the company, not the share class.
• CUSIP and ISIN. Codes for the specific security. They are the settlement standards, but they are licensed and they change on certain corporate actions.
• FIGI. An open identifier, with one code per security and venue and another at share-class level.
• LEI. Identifies the legal entity in financial transactions, not the listed security.

None of them is magic: each answers a different question, and the typical mistake is to join an entity identifier to a security identifier and lose the share classes along the way.

What happens to the historical series

When a company changes its code, most vendors rewrite the entire history under the new code. That is convenient and treacherous at the same time: the META series starts in 2012 even though that code did not exist until 2022. If another of your sources keeps the old series under the old code, joining on ticker leaves you with two pieces that do not overlap, and no warning whatsoever.

With mergers it is worse. The acquired company ceases to exist; its series ends. If the vendor "splices" the two histories together, you get a make-believe company, with a jump in price and in fundamentals that corresponds to no real shareholder. The first diagnostic is to count how many stable identifiers each code has carried:

import pandas as pd

fundam = pd.read_csv("fundamentales.csv", parse_dates=["fecha"])  # carries ticker and cik

colisiones = fundam.groupby("ticker")["cik"].nunique().sort_values(ascending=False)
print("Tickers con mas de una entidad detras:", (colisiones > 1).sum())
print(colisiones[colisiones > 1].head(15))

# And the other way round: entities that have used several tickers across the history.
mudanzas = fundam.groupby("cik")["ticker"].nunique()
print("Entidades que han cambiado de ticker:", (mudanzas > 1).sum())

If that first count does not come out at zero, every ticker-based join in your project is mixing companies together. The correct approach is to keep a map of effective date ranges and join on a stable identifier, not on a label:

precios = pd.read_csv("precios.csv", parse_dates=["fecha"])
mapa = pd.read_csv("mapa_tickers.csv", parse_dates=["desde", "hasta"])  # ticker, cik, desde, hasta

precios = precios.merge(mapa, on="ticker", how="left")

# Ranges still open have no end date: they must be closed before comparing.
precios["hasta"] = precios["hasta"].fillna(pd.Timestamp("2099-12-31"))

vigente = (precios["fecha"] >= precios["desde"]) & (precios["fecha"] <= precios["hasta"])
descartadas = (~vigente).sum()
precios = precios[vigente]

print("Filas fuera de la vigencia del ticker:", descartadas)
print("Filas sin identificador estable:", precios["cik"].isna().sum())

panel = precios.merge(fundam, on=["cik", "fecha"], how="inner")
print("Filas del panel final:", len(panel))

The discarded rows are exactly the ones that used to sneak in as another company's data. It is worth printing them and going through them one by one the first time: there is almost always a surprise in there.

Why this always fails silently

A ticker-based merge has no way of knowing that two rows with the same label are talking about different things. To pandas, "ABC" is "ABC". The result is not an exception but a perfectly normal-looking panel in which:

• A company shows up with one firm's prices and another firm's fundamentals over a stretch of the history, and any ratio you compute there is a made-up number.
• A company that changed its code loses half its history, because one source rewrote the past and the other did not.
• The panel's row count drops a little and nobody notices, because you never compared that number against the one you expected.

Hence the only discipline that works: never join two sources on ticker without first printing how many rows go in, how many come out and how many end up unmatched. If those three numbers do not square with what you expected, you have an identity problem, not a data problem.

A real case: buying the wrong Zoom

In early 2020, with lockdown pushing everyone onto video calls, plenty of people wanted to buy shares in Zoom Video Communications, which trades under the code ZM. There was also a different and minuscule company, Zoom Technologies, whose code was ZOOM. The intuitive code belonged to the wrong company.

The result was a preposterous rise in the small company over a few weeks, multiplying several times over with no news to justify it, until the SEC suspended trading in it on March 26, 2020, citing concern about the information circulating in the market and about investors possibly confusing it with a similarly named company.

There you have the whole module in a single case: two unrelated companies, near-identical codes, and a match made on the label instead of on the identity. If it happened to thousands of people staring at a screen, imagine how easy it is for it to happen to a pandas merge that never complains. Education, not financial advice.