Security Master and Identifier Mapping
The reference database that maps every security to its various identifiers (ticker, CUSIP, ISIN, internal ID) over time, and tracks how those identifiers change — without it, merging data from multiple vendors silently corrupts a backtest.
A single company can be referred to by a dozen different identifiers depending on the system: its stock ticker (which can change, or be reused years later by a completely different company), its CUSIP or ISIN (more stable, but can also change after a corporate restructuring), and internal IDs assigned by each individual data vendor. If a research pipeline joins a price dataset from one vendor to a fundamentals dataset from another using ticker symbols alone, and one of those tickers was reused for a different company at some point in history, the join can silently splice together two unrelated companies' data into one time series.
The idea
A security master is the reference table that resolves this: for every security, it tracks the full history of every identifier it has ever had, the date ranges each identifier was valid, and how identifiers map to each other across vendors and over time. A well-built security master lets you ask "what was this specific company's ticker on this specific historical date" and "which of these two records, from two different vendors, refer to the same actual company," and get correct answers even through ticker changes, exchange changes, and identifier reuse.
Worked example
The ticker "AABA" was used by a well-known internet company after it renamed itself and sold off its core business, and previously (in different form) other reused-ticker cases exist across US markets, such as tickers being recycled by an exchange a few years after a company delists. A backtest merging historical price data (keyed by ticker) with fundamental data (keyed by a different vendor's internal ID) needs a security master to correctly translate between the two identifier systems as of each historical date — matching on ticker alone, without checking the date range that ticker was valid for that specific company, risks silently attaching one company's fundamentals to a different company's price history for periods where the ticker had been reassigned.
What this means in practice
Any research pipeline pulling data from more than one vendor needs a security master layer to do identifier translation correctly, and that layer needs to be time-aware, not just a static lookup table, since the mapping between identifiers changes as companies rename, restructure, or delist and their old tickers get recycled. Skipping this step is a common, hard-to-detect source of corrupted merged datasets, because the bug doesn't throw an error — it just quietly produces plausible-looking but wrong joined records.
A security master tracks every identifier a security has ever had and the exact date ranges each was valid, so data from different vendors can be joined correctly on a specific historical date rather than on a ticker or code that may have been reused by an entirely different company.
Further reading
- Bloomberg, 'Security Identification and Symbology' technical documentation