ISIN vs ticker vs SEDOL vs WKN vs CUSIP: fund identifiers explained

An ISIN identifies one security worldwide; a ticker identifies a listing on one exchange; SEDOL, CUSIP and WKN are national numbering schemes for the UK and Ireland, North America and Germany respectively. For funds and ETFs the ISIN is the only identifier that is both global and unique per share class, which is why it is the key that databases, custodians and fund data APIs use. Everything else is either local, non-unique or embedded inside the ISIN anyway.

Why funds need more than one identifier

A single ETF share class can be listed on five exchanges, held through custodians in a dozen countries, and reported to regulators under several regimes. Each of those systems grew its own naming convention before a global one existed. The ISIN, defined by ISO 6166 and issued by each country's National Numbering Agency, was the attempt to unify them; the older codes did not disappear, they became inputs to it.

The practical problem for developers is that users arrive with whichever code their broker shows them. A German retail investor knows the WKN, a UK adviser quotes the SEDOL, a trader types a ticker, and the fund's own factsheet prints the ISIN. Your product has to accept all of them and resolve to one key. That key should be the ISIN, for reasons the rest of this post makes concrete.

The five identifiers side by side

Two rows deserve a closer look.

Tickers are not unique. The iShares Core MSCI World UCITS ETF (accumulating share class, ISIN IE00B4L5Y983) trades as one ticker on the London Stock Exchange, a different one on Xetra and another on Borsa Italiana. Worse, tickers are reused across exchanges for unrelated securities. A ticker only means something together with an exchange code, and even then it identifies a listing, not the underlying share class. The ticker glossary entry has more on the reuse problem.

WKN is not embedded in the ISIN. German ISINs are DE + 000 + WKN + check digit, so for a German security you can derive one from the other. But an Irish ETF sold in Germany has an Irish ISIN and a separately assigned WKN that has nothing to do with the ISIN's middle characters. Mapping WKN to ISIN for non-German funds needs a lookup table.

How SEDOL and CUSIP nest inside the ISIN

The middle nine characters of an ISIN are the National Securities Identifying Number, padded with leading zeros. For the two most common national schemes the nesting is exact:

• UK and Irish ISINs: GB or IE + 00 + 7-character SEDOL + check digit. Take IE00B4L5Y983: the SEDOL is B4L5Y98.
• US ISINs: US + 9-character CUSIP + check digit. The CUSIP is positions 3–11 with no padding, because a CUSIP is already nine characters.

This means you can extract the SEDOL from any GB or IE ISIN with a slice, and the CUSIP from any US ISIN. The reverse works too: given a SEDOL and the knowledge that the security is Irish, you can reconstruct the ISIN by prepending IE00 and computing the Luhn check digit (the ISIN guide has the algorithm, and the free ISIN validator does it in the browser).

Luxembourg ISINs (LU) and French ISINs (FR) do not embed a SEDOL or CUSIP. Their NSIN is a national number that has no life outside the ISIN, so for the bulk of UCITS funds domiciled in Luxembourg there is nothing to extract.

typescript
export function nationalCode(isin: string): { scheme: "SEDOL" | "CUSIP" | "WKN" | "NSIN"; code: string } {
  const cc = isin.slice(0, 2);
  const nsin = isin.slice(2, 11);
  if (cc === "GB" || cc === "IE") return { scheme: "SEDOL", code: nsin.slice(2) };
  if (cc === "US" || cc === "CA") return { scheme: "CUSIP", code: nsin };
  if (cc === "DE") return { scheme: "WKN", code: nsin.slice(3) };
  return { scheme: "NSIN", code: nsin.replace(/^0+/, "") };
}
​
nationalCode("IE00B4L5Y983"); // { scheme: "SEDOL", code: "B4L5Y98" }
nationalCode("LU1681043599"); // { scheme: "NSIN", code: "1681043599" } — no separate national scheme

Which identifier should be your primary key?

The ISIN, every time. The reasoning:

1. It is unique per share class. Accumulating and distributing classes, hedged and unhedged, retail and institutional each have their own ISIN. That is exactly the granularity fees, NAVs and performance are reported at. See share classes explained for why this matters.
2. It is global. One key works for an Irish ETF, a Luxembourg SICAV, a French FCP and a US mutual fund.
3. It has a check digit. You can reject typos before they cost a lookup. The ISIN glossary entry covers the format.
4. It is what the documents print. Factsheets, KIDs and prospectuses carry the ISIN; many carry no ticker at all.
5. It is what data APIs accept. FundFacts API resolves a fund from its ISIN alone: GET /api/v1/funds/{isin} returns the structured factsheet, and the batch, portfolio and overlap endpoints take lists of ISINs.

The other codes become alias columns. A pragmatic schema is a securities table keyed by ISIN with nullable sedol, cusip and wkn columns, and a separate listings table with (isin, exchange, ticker, currency) rows, because one ISIN has many listings.

Resolving what users type

The input box on a fund search should accept anything and normalise it. A reasonable order of attempts:

1. Strip whitespace, upper-case. If it matches ^[A-Z]{2}[A-Z0-9]{9}\d$ and passes the check digit, it is an ISIN. Done.
2. If it is 7 characters ending in a digit, treat it as a SEDOL candidate; if 9 characters, a CUSIP; if 6, possibly a WKN. Look it up in your alias table.
3. Otherwise treat it as a name or ticker and run a text search. FundFacts exposes GET /api/v1/search?q= for this, which matches ISIN prefixes first, then fund name and issuer, and returns the ISIN for each hit. Search is free on every plan.

bash
curl "https://fundfactsapi.com/api/v1/search?q=core%20msci%20world&limit=5" \
  -H "Authorization: Bearer ffk_live_..."

json
{
  "query": "core msci world",
  "count": 5,
  "results": [
    { "isin": "IE00B4L5Y983", "name": "iShares Core MSCI World UCITS ETF USD (Acc)", "issuer": "iShares", "currency": "USD", "assetClass": "Equity", "shareClass": "USD Acc", "url": null }
  ]
}

Once you have the ISIN, the factsheet lookup is one call, and the response's isin envelope field echoes the canonical upper-case code so you can store it.

Edge cases worth handling

• One ISIN, several currencies. An ETF share class can be listed in USD in London and in EUR in Frankfurt under the same ISIN. The listing currency is a property of the listing, not the security. keyFacts.currency in a fund payload is the share-class base currency, which is fixed.
• Ticker collisions across asset classes. A three-letter ticker on one exchange can be a bank on another. Never key anything on a bare ticker.
• Reissued national codes. SEDOLs and CUSIPs can be reassigned after corporate events; ISINs are not recycled. Another reason to key on ISIN.
• Funds without any listing. Most non-ETF UCITS funds are not exchange traded, so they have an ISIN and possibly a SEDOL or WKN, but no ticker at all. A ticker-first design cannot represent them.
• Fund of funds. A fund's top holdings are reported by name, not by identifier, in most factsheets. If you need identifiers for holdings, you will be doing name matching, which is how the overlap endpoint works.

Where each identifier shows up in FundFacts data

The API is ISIN-native. The envelope of every fund response has isin (canonical) and name; the data object has shareClass when it can be inferred, keyFacts.currency and keyFacts.inception. There is no ticker field, because a ticker without an exchange is ambiguous and the fund's own documents rarely commit to one. If you need tickers for a trading screen, keep them in your listings table alongside the ISIN and join at display time.

For the rest of the identifiers, the glossary has short entries on SEDOL, CUSIP and WKN. If you are designing a fund database from scratch, the fund screener tutorial shows a schema keyed on ISIN in practice.