ISIN, CUSIP, SEDOL: Instrument Identifiers Compared
A broker message arrives: "bid for 5mm LVMH 2.125s due July 2027." There is no ISIN, no CUSIP, and no SEDOL. Before that quote can become a reliable structured record, a system has to identify the issuer, coupon, maturity date, currency, and likely issue. It then needs to match those attributes against a security master or reference data source, select the correct instrument, and attach a validated identifier to the record.
That workflow is common in fixed-income chat. Traders often use abbreviated descriptions because the participants already understand the context. Data systems do not have that context unless it is captured explicitly. ISIN, CUSIP, and SEDOL can all identify securities, but they come from different numbering systems and serve different regional and operational roles.
What each identifier represents
An ISIN, or International Securities Identification Number, is a 12-character identifier defined under ISO 6166. Its structure combines a two-letter country or jurisdiction prefix, a nine-character national security identifier, and a check digit. The relevant national numbering agency assigns the underlying identifier, with coordination through the Association of National Numbering Agencies, or ANNA.
ISIN is the identifier most often expected when securities data moves across international systems. It can identify bonds, equities, funds, derivatives, and other financial instruments. In a European fixed-income workflow, an ISIN is commonly the primary key used to connect broker messages, order records, allocations, pricing data, and settlement instructions.
A CUSIP is a nine-character alphanumeric identifier associated primarily with securities issued in the United States and Canada. CUSIP follows the ANSI X9.6 standard and is administered by CUSIP Global Services, which has been operated by FactSet since 2022. The first six characters generally identify the issuer, followed by issue-specific characters and a check digit.
CUSIP is deeply embedded in North American reference data, custody, reporting, and post-trade processes. A US corporate bond may therefore be identified internally by CUSIP, while the same instrument is also represented by an ISIN for cross-border exchange. The two identifiers are not interchangeable strings. They are separate identifiers that need an explicit mapping.
A SEDOL, or Stock Exchange Daily Official List number, is a seven-character identifier administered by the London Stock Exchange. It was developed for securities associated with the UK market and is widely used in UK and international market data. SEDOLs can identify equities, bonds, funds, and other instruments, often as part of a broader vendor or exchange reference record.
ISIN, CUSIP, and SEDOL compared
| Identifier | Format | Issuing Authority | Geographic Scope | Primary Use in Fixed Income |
|---|---|---|---|---|
| ISIN | 12 characters: country prefix, nine-character national identifier, check digit | National numbering agencies coordinated through ANNA, under ISO 6166 | International | Cross-border instrument identification, trading records, reporting, settlement, and reference data exchange |
| CUSIP | 9-character alphanumeric code with check digit | CUSIP Global Services, under ANSI X9.6 | Primarily United States and Canada | North American bond reference data, custody, trading, reporting, and post-trade processing |
| SEDOL | 7-character alphanumeric code with check digit | London Stock Exchange | Originated in the UK, used in UK and international market data | UK and global security reference data, instrument linking, and vendor or exchange workflows |
The table describes the identifier systems, not a hierarchy in which one code is always superior. The correct primary identifier depends on the market, the source system, the legal entity involved, and the downstream process. A robust security master may store all three, together with other identifiers such as ticker, exchange code, vendor symbol, and internal instrument ID.
How identifier resolution works in broker chat
Consider the message: "bid for 5mm LVMH 2.125s due July 2027." A parser can extract several fields immediately:
- Side: bid
- Quantity: 5 million, subject to the desk's unit conventions
- Issuer: LVMH
- Coupon: 2.125 percent
- Maturity: July 2027
Those fields may still describe more than one possible instrument. Resolution should therefore use additional context where available, including currency, issuer legal entity, seniority, issue date, market, message thread, and nearby broker messages. If the chat includes "EUR" or a price convention, those details can narrow the candidate set. If the same broker has already discussed one specific issue in the thread, that conversational context can also be useful evidence.
The system can then query an internal security master and reference data sources. Mapping services such as OPENFIGI can help connect known identifiers and instrument attributes, while the relevant national numbering agency or licensed reference data provider remains the authoritative source for issuance and identifier records. The result should include the selected identifier, the fields used for the match, the source, and a confidence or review status.
When no candidate is sufficiently specific, the correct outcome is an unresolved reference, not a guessed ISIN. An operations user can review the proposed candidates, add missing currency or issuer information, and approve the match. Once resolved, the structured quote can be linked to the instrument record used by pricing, order management, compliance, and post-trade systems.
Why mappings are not interchangeable
One security can have an ISIN, CUSIP, and SEDOL at the same time. The identifiers may appear in different feeds, and a system may receive only one of them. A North American bond feed may lead with a CUSIP. A European broker may send an ISIN. A market data file may include a SEDOL alongside exchange and vendor fields.
These mappings need to be stored as relationships, not treated as formatting transformations. A CUSIP cannot be converted into an ISIN by adding a prefix. The ISIN contains a national identifier and a check digit, and the correct mapping depends on the actual security. Likewise, a SEDOL lookup requires a reference record, not a character-level conversion.
Identifier lifecycle also matters. Corporate actions, reopenings, fungible tranches, tap issues, and changes in the legal structure of an issuer can create records that look similar while having different identifiers. A parser should preserve the original broker wording and the resolution evidence, so later users can understand why a particular instrument was selected.
The boundary of identifier enrichment
Identifier enrichment resolves an informal or incomplete security reference to a known instrument record. It does not validate the economic terms of a trade.
If a message says "offer 5mm at 99.42," enrichment may identify the bond associated with "LVMH 2.125s due July 2027." It does not, by itself, confirm that the quantity is in nominal currency, that 99.42 is a clean or dirty price, that the offer is still live, or that settlement terms are correct. Those checks require message interpretation, market conventions, trader workflow rules, and downstream validation.
The distinction is important for system design. An identifier can be correct while the quote is stale, the side is misread, the size is ambiguous, or the settlement date is missing. Instrument resolution should therefore be one stage in a broader pipeline, with separate fields for match status, trade terms, validation status, and human review.
In TwoWay's early-access pilots, this is the practical role of enrichment: preserve the broker's original language, extract the trade signal, and attach a traceable instrument reference when the evidence supports it. If that identifier step fails, the affected downstream records are not only security master links. Quotes may fail to join to prices, orders may remain unmatched, allocations may require manual repair, and reporting or settlement workflows may inherit the ambiguity. Enrichment pipelines should make unresolved instruments visible and actionable rather than silently writing an unverified identifier.