From Tickers to FIGI: Building Reliable Instrument Identity

Tickers feel stable until they are not

Most research pipelines begin with tickers because they are easy to obtain and simple to work with. They appear to behave like identifiers, and for small experiments, they are often good enough. The problem is that they are not designed to be stable over time, and research systems eventually inherit that instability.

Symbols change, get reassigned, and mean different things across exchanges and vendors. A company can move from one ticker to another, and the original symbol can later be reused by an entirely different issuer. At the same time, different datasets may encode the same instrument with slightly different conventions, which still join successfully but no longer represent the same underlying asset.

This is what makes ticker-based systems dangerous. They rarely fail loudly. Instead, they continue to produce clean outputs built on incorrect identity assumptions.

OpenFIGI introduces a stable identity layer

OpenFIGI, backed by Bloomberg, provides a way to map commonly used identifiers such as tickers into FIGIs, or Financial Instrument Global Identifiers. Unlike tickers, FIGIs are designed to be globally unique and persistent through time. They represent instruments rather than labels.

The important shift is not the API itself but the abstraction it enables. Instead of treating tickers as keys, they become attributes that map into a canonical identity layer. Once that layer exists, the rest of the research system can be built on something that does not drift with vendor conventions or corporate actions.

To make that mapping reliable, the request should carry more than the ticker alone. Exchange information and security type belong in the JSON payload so the API can resolve the intended instrument instead of returning an ambiguous match.

Mapping a ticker to a FIGI

import requests

url = "https://api.openfigi.com/v3/mapping"

headers = {
    "Content-Type": "application/json"
}

payload = [
    {
        "idType": "TICKER",
        "idValue": "AAPL",
        "marketSecDes": "Equity",
        "micCode": "XNYS",
    }
]

response = requests.post(url, json=payload, headers=headers)
result = response.json()

The API call is straightforward. The structural decision to rely on FIGIs instead of tickers is what changes the system.

The next step is turning the response into usable identity fields

Once the API returns a mapping, the useful work is extracting the identity fields you want to preserve inside the security master. Even for a single instrument, it is helpful to keep more than the headline FIGI. Composite FIGI, share class FIGI, mapped ticker, exchange metadata, and security type all provide context that makes downstream joins easier to audit.

In a production pipeline, this same pattern scales across a universe. The key idea is that the raw API response should be normalized into a clean identity layer before it is joined back into the broader research dataset.

Normalizing the OpenFIGI response into a security master

import pandas as pd

raw_company = pd.DataFrame(
    [
        {
            "ticker": "AAPL",
            "market_sector_description": "Equity",
            "mic_code": "XNYS",
        }
    ]
)

first = response.json()[0]["data"][0]

mapping = {
    "figi": first.get("figi"),
    "composite_figi": first.get("compositeFIGI"),
    "share_class_figi": first.get("shareClassFIGI"),
    "mapped_ticker": first.get("ticker"),
    "name": first.get("name"),
    "exch_code": first.get("exchCode"),
    "security_type": first.get("securityType"),
    "market_sector": first.get("marketSector"),
}

mapping_df = pd.DataFrame([mapping])
security_master = pd.concat([raw_company, mapping_df], axis=1)
security_master

The point is not just to fetch a FIGI. It is to normalize the response into stable identity fields that can live inside the security master.

Ambiguity is part of the data, not an error

One of the more useful properties of OpenFIGI is that it does not always return a single match. A ticker can map to multiple instruments depending on exchange, share class, or listing structure. For example, the ticker LOVE maps to LOVESAC CO/THE in a US listing context, but can map to CANNARA BIOTECH INC. in a Canadian listing context. These are completely different companies, not alternate identifiers for the same issuer. This is often treated as an inconvenience, but it is closer to the truth of the data.

A robust system should not suppress this ambiguity. It should expose it, resolve it explicitly, and record the decision. Once this discipline is introduced, the research process becomes less about convenience and more about controlled assumptions.

One symbol can represent multiple instruments

The ticker LOVE can resolve differently across listing contexts, forcing the system to make an explicit selection instead of relying on an implicit join.

Where FIGI belongs in the research stack

The value of FIGI appears once it becomes the central key in the system. Prices, fundamentals, index holdings, and derived features should all connect through this identity layer rather than through symbols. This allows the research stack to maintain continuity even as external representations change.

In practice, this means introducing a mapping layer early in the pipeline, storing FIGIs alongside source identifiers, and ensuring that all downstream joins reference the canonical key. Over time, this reduces reconciliation work and prevents subtle mismatches from entering the research outputs.

FIGI as a layer inside the data pipeline

Raw identifiers are mapped into FIGIs before entering the security master, allowing downstream systems to operate on stable instrument identity.

Why identity design affects research results

Identity is not just a data engineering concern. It directly influences how portfolios are constructed, how factor exposures are measured, and how backtests behave. If two datasets refer to slightly different instruments under the same ticker, the resulting portfolio may appear more diversified or more stable than it truly is.

This is one of the more subtle failure modes in quantitative research. The system produces reasonable outputs, the numbers look consistent, and nothing crashes. Yet the underlying assumptions are incorrect. By the time the issue is discovered, it is often embedded across multiple layers of analysis.

From convenience to correctness

Moving from tickers to FIGIs is a shift from convenience to correctness. It introduces a small amount of upfront friction, but removes a class of downstream errors that are otherwise difficult to detect.

OpenFIGI is not a complete security master, but it is a critical building block. It allows the system to separate identity from representation, which is a prerequisite for any research process that aims to be both scalable and trustworthy.