What Is a CUSIP? A Plain Guide for Holdings Data
A CUSIP is the 9-character ID that names a specific security in U.S. filings. Here is how it is built and why it matters when you work with holdings data.

The short version
A CUSIP is the 9-character code that uniquely identifies a specific U.S. or Canadian security: 6 characters for the issuer, 2 for the exact issue (a share class, a particular bond), and 1 check digit. CUSIPs come from a commercial registry operating under the American Bankers Association, and they are the identifier SEC ownership filings actually use: every 13F position is keyed by CUSIP, not ticker. Tickers change and get recycled; the CUSIP is the stable key, so holdings work always starts with resolving CUSIP to ticker and company.
The structure
- Characters 1-6 (issuer): which company or entity. Every security from one issuer shares this stem: Alphabet's two listed share classes carry the same six characters and differ only in the issue code.
- Characters 7-8 (issue): which specific security from that issuer. By convention equity issues use digits and fixed-income issues mix in letters, so one stem can fan out across share classes and a long tail of bonds.
- Character 9 (check digit): a deterministic function of the first eight characters, designed for an era of manual entry and still useful in data pipelines today.
The granularity is the point. A CUSIP does not name "Apple"; it names one specific instrument Apple has issued. That matters the moment a filing holds one share class, your user asks about another, and a careless join merges the two.

The check digit, worked through
The ninth character comes from a Luhn-style routine the spec calls "modulus 10 double-add-double". Convert the first eight characters to values (digits stay themselves, letters map to A=10 through Z=35), double the even positions, then add the decimal digits of every resulting value. The check digit is whatever brings the sum to the next multiple of 10.
Take 59491810, the widely published issuer-and-issue stem for Microsoft common stock:
- Values: 5, 9, 4, 9, 1, 8, 1, 0.
- Double the even positions: 5, 18, 4, 18, 1, 16, 1, 0.
- Sum the digits of each value: 5 + 9 + 4 + 9 + 1 + 7 + 1 + 0 = 36.
- Check digit: (10 - 36 mod 10) mod 10 = 4.
So the full identifier ends in 4, matching the published CUSIP. In code:
function cusipCheckDigit(stem: string): number {
let sum = 0
for (let i = 0; i < 8; i++) {
const c = stem[i]
let v = c >= '0' && c <= '9' ? Number(c) : c.charCodeAt(0) - 55 // A=10 ... Z=35
if (i % 2 === 1) v *= 2 // double the 2nd, 4th, 6th, 8th characters
sum += Math.floor(v / 10) + (v % 10)
}
return (10 - (sum % 10)) % 10
}
(The spec also assigns values to a few special characters; the version above handles ordinary equity CUSIPs.)
Why bother? 13F infotables are filer-supplied text, not registry exports. Recomputing check digits is the cheapest data-quality gate a holdings pipeline can run: a few lines that catch truncated identifiers, fat-fingered characters, and spreadsheet damage before they become wrong answers.
CUSIP vs ticker vs ISIN
- Ticker (e.g.,
AAPL) is the friendly exchange symbol, but it can be reused or change. It is scoped to one venue, moves on rebrands, and gets recycled after delistings. - CUSIP is a stable, granular identifier used in filings and settlement. It covers U.S. and Canadian securities only, and bulk redistribution is commercially licensed, which matters if you ship identifier data downstream.
- ISIN is the international 12-character identifier (a country prefix plus, often, the CUSIP). A U.S. ISIN is essentially "US" plus the CUSIP plus its own check digit, so whatever applies to the embedded CUSIP travels with it.
For holdings analysis, the CUSIP is what you'll actually find in the raw data, and the ticker is what humans want to read. The practical rule: store the identifier the source gives you, resolve through a mapping layer you can audit, and render tickers last. For the full comparison, including FIGI, the open standard built for this mapping job, see CUSIP vs ISIN vs FIGI vs ticker.
Why it matters for filings data
13F filings identify every position by CUSIP. The scale makes this concrete: managers above the $100 million threshold file up to 45 days after quarter end, and in Q1 2026 that came to 1,824 filers reporting 1.87 million positions worth $53.7 trillion, all keyed on identifiers most users have never typed. To make that data usable you have to resolve CUSIP → ticker → company, handle issues where a CUSIP doesn't cleanly map, and keep up as identifiers change with corporate actions. This resolution work is unglamorous but essential, and it's a big part of why clean ownership data is valuable. (See how to read a 13F filing.)
Resolution is also time-dependent, the part most ad hoc scripts get wrong. The correct mapping for a Q1 filing is the one that was true at the end of Q1. A merger or ticker change since then does not rewrite history, but a naive "look up the current ticker" join will. Good resolution is as-of resolution: identifier history sits next to the raw filing row, so old quarters keep resolving the way they did when filed.
Where CUSIP shows up in a 13F workflow
| Step | What the raw filing gives you | What a usable data layer adds |
|---|---|---|
| Parse the 13F | CUSIP, issuer name, value, shares | Normalized rows and filing provenance |
| Resolve the security | CUSIP string | Ticker, company, share class, and identifier history |
| Compare quarters | Separate filing snapshots | Added, reduced, exited, and held position changes |
| Answer a user | Raw filing rows | A cited explanation with source links |
This is why the 13F data layer matters. The hard part is not only fetching EDGAR filings. It is turning identifier-heavy filings into something an analyst, API client, or AI agent can ask about in normal market language. Each row above is a place a pipeline can quietly go wrong; the resolve step does the most damage because it is where the data changes vocabulary.
API example: resolve before you answer
If a user asks an agent "which funds own Nvidia?", the agent should not invent a ticker mapping from memory. It should search or resolve first, then fetch holdings from sourced data:
curl -H "Authorization: Bearer YOUR_KEY" \
"https://arkolith.com/api/v1/search?q=nvidia"
The search response returns resolved entities, so the next call is exact rather than guessed. A fund's holdings then come back with each position's raw CUSIP, the resolved ticker where one exists, and the accession number of the source filing:
curl -H "Authorization: Bearer YOUR_KEY" \
"https://arkolith.com/api/v1/funds/<cik>/holdings"
That triple (raw identifier, resolved label, source document) lets an agent cite its answer instead of asserting it. Some rows return a null ticker; that is honest output, since not every filed CUSIP maps to a listed symbol. If you are connecting an assistant directly, use the MCP quickstart so the agent can call the lookup tools itself.
The key rule is simple: when the raw source uses CUSIP and the user uses a ticker, there must be an explicit resolution step in between. Skipping that step is how holdings workflows drift into confident but wrong answers.
The common failure mode
The most common mistake is treating ticker symbols as permanent truth. A company can change tickers, merge, spin off a business, or have multiple share classes. A filing row tied to one CUSIP may not map cleanly to the ticker a user has in mind today. Good holdings infrastructure keeps the raw identifier, the resolved ticker, and the source filing together so the mapping can be checked later.
Beyond the ticker trap, a handful of CUSIP-specific failure modes recur in real filings, and most have a mechanical fix:
| Symptom in the data | Likely cause | What to do |
|---|---|---|
| 8 characters instead of 9 | A spreadsheet stripped a leading zero upstream | Left-pad with zeros to 9, then re-validate the check digit |
| Check digit fails validation | Filer typo or a truncated export | Flag the row and fall back to issuer-name matching; never silently "fix" the identifier |
| One CUSIP appears as both shares and an option | 13F option positions are reported under the underlying security's CUSIP | Split on the put/call flag; never sum option legs into the long book |
| CUSIP resolves to a ticker that no longer trades | Corporate action after the filing date | Resolve as of the filing period and keep the identifier history |
| Two different CUSIPs for one company | Multiple share classes, or a new CUSIP after a reorganization | Group by the 6-character issuer stem, then decide deliberately |
The option row is the quiet one. A put and the common shares it references can carry the same CUSIP in a 13F; the put/call field, not the identifier, tells them apart. Treat the CUSIP as the whole story and a bearish position renders as bullish. See 13F options, puts, and calls explained.
For AI workflows, this is especially important. If an agent jumps straight from a company name to a ticker and then to a holdings claim, it may skip the exact security that appeared in the filing. A better agent asks the data layer to resolve the identifier, then cites the filing-backed result.

Frequently asked questions
How many characters is a CUSIP?
Nine: six for the issuer, two for the issue, and one check digit computed with the modulus 10 double-add-double routine shown above.
Why do 13F filings use CUSIPs instead of tickers?
CUSIPs are stable and unambiguous at the security level; tickers can change or be reused. Filings need precision: a 13F position names one exact instrument.
Is a CUSIP the same as an ISIN?
No. An ISIN is a 12-character international ID that often embeds the CUSIP with a country code and its own check digit. For a U.S. stock the two name the same security at different scopes.
Can a company's CUSIP change?
Yes. Mergers, reorganizations, and some other corporate actions can retire a CUSIP or introduce a new one while the name and even the ticker carry on. That is why pipelines keep identifier history and resolve filings as of their period, not against today's mapping.
Why do AI agents struggle with CUSIPs?
CUSIPs are not natural-language concepts and many mappings change after corporate actions. An agent should use a resolver or API lookup, not training memory, when it turns a CUSIP into a ticker or company.
What is the best next step after learning CUSIPs?
Read the 13F filing guide, then inspect the 13F data layer. CUSIP resolution is one part of making institutional ownership data queryable.
Arkolith resolves CUSIPs to tickers and serves clean, sourced holdings data. Explore the 13F data layer, connect an agent with the MCP quickstart, or get a key.
Keep reading

Bill Ackman 13F: Pershing Square Q1 2026
Pershing Square reported an 11-position, $13.7B Q1 2026 13F book, with Microsoft new, Amazon added, and Alphabet sharply reduced.

WhaleWisdom API Alternative: 13F Data With MCP
A WhaleWisdom API alternative should preserve SEC 13F source links, accepted dates, comparable filings, and agent-ready retrieval paths.

13F Database: How to Search Institutional Holdings
A 13F database lets you search institutional holdings by manager, issuer, ticker, CUSIP, filing period, and accepted date without treating delayed filings as live trades.