How do you find the CIK, CUSIP, or ISIN for a US stock ticker like AAPL? The question shows up the moment a project touches official data: you need the CIK to pull SEC filings from EDGAR, a CUSIP or ISIN to reconcile positions across two data vendors, a FIGI to build a dataset you're allowed to publish. Five identifier systems cover most of this ground, and they differ in who issues them, what exactly they identify, and what they cost. Mixing them up wastes money at best. At worst it silently mislabels securities in a database. This post compares the five, gives a plain rule for which one each job needs, and shows how to resolve a ticker to its CIK and related reference data with one API call.
The five identifiers at a glance#
| Identifier | Issued by | What it identifies | Licensing |
|---|---|---|---|
| CIK | US Securities and Exchange Commission | A filer (company, fund, or person) rather than a single security | Free and public |
| CUSIP | CUSIP Global Services | A specific North American security (each share class, each bond) | Commercial license; redistribution restricted |
| ISIN | National numbering agencies (ISO 6166) | A security, globally | Varies; US ISINs embed the CUSIP, so its terms tend to follow |
| SEDOL | Assigned in London | A security at the listing level, UK and European coverage | Commercial license |
| FIGI | OpenFIGI, an open standard | Instruments at share-class, country, and venue granularity | Free and openly redistributable |
The most common confusion is that a CIK names an entity while the other four name securities. Apple Inc. has exactly one CIK, 0000320193, and it covers every document the company files: 10-Ks, 8-Ks, proxy statements, and the Form 4s its officers file. The same company has many CUSIPs, one for its common stock and one for each bond it has issued. If your key is "the company", CIK is the right shape. If your key is "this exact instrument", it isn't.
ISIN deserves one structural note. A US ISIN is the country code US, followed by the security's nine-character CUSIP, followed by a check digit. The consequence is that generating or storing ISINs for US securities means handling CUSIP data, and the commercial terms attached to CUSIP tend to follow. If licensing details matter for your use case, confirm them with the issuing bodies directly; the terms are contractual and they change.
FIGI was designed as the open alternative. The standard is maintained by the Object Management Group, lookups are free through the OpenFIGI API, and the identifiers themselves can be stored and redistributed without a fee. FIGIs also come at several granularities: a share-class FIGI for the instrument worldwide, a composite FIGI per country, and a venue-level FIGI per listing. That layering suits the cross-referencing work that the licensed identifiers make awkward.
CIK vs CUSIP vs ISIN vs SEDOL vs FIGI: which one do you need#
A short decision rule covers most cases. Pulling SEC filings, XBRL financials, or insider transactions: use the CIK, since EDGAR is organized around it. US clearing, settlement, and broker paperwork: CUSIP, because US back-office systems key on it. Cross-border operations and European regulatory reporting, where MiFID II transaction reports require ISINs: ISIN. SEDOL is the odd one out for US-centric work; you'll only need it when a workflow touches London or certain European venues. For an open dataset, a public API, or an internal security master shared across teams without a licensing review: FIGI.
Two of the five, CIK and FIGI, are free to obtain and free to pass on. That's worth designing around. A pipeline that keys internally on CIK plus FIGI, and attaches CUSIP, ISIN, or SEDOL only at the edges where a counterparty requires them, keeps the licensed identifiers out of your redistribution path.
Resolving a ticker to its CIK with one API call#
Ticker to CIK is a single request against SiftingIO's company profile endpoint, documented at /docs/discovery/company:
curl -H "X-API-Key: $SIFTING_KEY" \
"https://api.sifting.io/v1/fnd/stocks/AAPL/profile"
The ticker is case-insensitive, so aapl works too. The response carries the identifier plus the entity metadata around it:
{
"ticker": "AAPL",
"name": "Apple Inc.",
"cik": "0000320193",
"sic_code": "3571",
"entity_type": "operating"
}
The full response also includes the fiscal year end and the exchanges list, trimmed here. You can eyeball the same mapping without an API key: the AAPL symbol page shows the SEC CIK inline and lists ISIN, CUSIP, and FIGI among the reference data available for the symbol. The stocks product page covers the company-profile side, the issuer metadata behind the CIK. SEDOL isn't part of either set; SiftingIO doesn't return SEDOLs, so source those from the assigning body if a London-side workflow needs them.
Common pitfalls#
Leading zeros disappear. CIKs are zero-padded 10-digit strings, and Apple's is "0000320193", yet EDGAR also accepts the unpadded 320193, so both forms circulate in the wild. Open a CSV of CIKs in a spreadsheet and the padding is gone; join that column against a padded source and every row misses. Store CIKs as strings, never integers, and normalize to 10 digits at ingestion.
The mapping is many-to-one and it moves. One issuer maps to many CUSIPs and ISINs across share classes and bond issues, so "the CUSIP for Apple" is underspecified: you mean the CUSIP for a particular security Apple issued. Tickers are worse. A delisted company's ticker can be reassigned to an unrelated issuer later, so a historical dataset joined on bare ticker will happily attach the new company's identifiers to the old company's rows. Store identifier mappings with an as-of date, and treat resolution as a job that re-runs on a schedule rather than a constant someone hardcoded in 2019.
Caching licensed identifiers can breach a contract. Writing CUSIPs or SEDOLs received from one vendor into a customer-facing response, a public dataset, or a long-lived internal cache may exceed what the agreement allows. This failure is silent until an audit. If an identifier will leave your system, prefer CIK or FIGI, and check the terms before persisting the others.
From CIK to filings and fundamentals#
The CIK is usually the identifier you wanted anyway, because it's the key to everything the issuer files. With the ticker resolved, the same /v1/fnd namespace covers the filings themselves:
curl -H "X-API-Key: $SIFTING_KEY" \
"https://api.sifting.io/v1/fnd/stocks/AAPL/filings?form=10-K"
From there you can pull filing sections as text, XBRL financials, and insider activity. Two worked examples on this blog pick up where this post ends: joining OHLCV bars with XBRL fundamentals walks the ticker-to-CIK-to-financials chain into a priced dataset, and building a Form 4 insider watchlist uses the same filing feed for officer transactions.
Resolve the identifier once, store it with a date, and the rest of the SEC's paper trail is one namespace away. Start building free.
