Finding the right company across markets — before you pull the wrong filing

OpenFilings·June 26, 2026·10 min read

APIsearchcross-marketISINLEIOpenFIGIGLEIFESMAFIRDSportfolioresearch

You open a holdings file: ISINs, no tickers. A colleague asks for Samsung — Korea listing or US ADR? A news wire names Airbus with a LEI, not a symbol. You type BA and get the wrong company.

These are not edge cases. They are the normal friction of cross-market work. Most filing tools assume you already know which issuer and which listing you mean. When that assumption fails, everything downstream is wrong — filings, revenue, margins, comps — often without an obvious error.

The lookup problem

Financial research starts with identity, not with the 10-K.

In practice you receive:

Tickers that differ by exchange (7203 in Tokyo, not the same workflow as a US ADR)
ISINs from custody or fund admin, with no exchange hint
LEIs from European annual reports and regulatory wires
Names that collide or need a market context (Airbus, Tencent, LVMH)
Local-language names on Asian filings — 腾讯, トヨタ, 삼성전자 — while your screen shows Latin script only

If your stack resolves “ticker → filings” in one market only, you either miss the issuer or attach the wrong one. The filing may download cleanly. The analysis is still off.

Where it shows up in real work

Portfolio and risk. A CSV of ISINs must map to the correct legal entity and home filing source before you can pull financials or news. Guessing the ticker from the ISIN prefix is not reliable for dual-listed names.

Screeners and watchlists. A user adds “Samsung” or “Toyota.” Without a resolution step, you may watch the ADR while they care about the domestic listing — or the reverse.

Cross-border comps. You compare an EU industrial to a US peer. The EU name trades on Euronext; the US name files with the SEC. Same sector, different identifiers, different registries.

Automation and agents. Tools that call filing APIs in a loop multiply every lookup mistake. Fixing identity once at the start is cheaper than debugging wrong KPIs later.

Why one ticker is not enough

Three facts drive most mismatches:

One company, several listings. Samsung, Airbus, Tencent, and many others appear on more than one market with different symbols.
Tickers are not stable keys. They change on relist, merge, or ADR programs; they also collide across venues.
Your source file rarely uses the same ID type as the filing registry. Custodians speak ISIN. EDGAR speaks CIK. ESEF speaks LEI. Japan speaks EDINET codes. Korea speaks DART codes.

Good practice: resolve the issuer first, then choose the listing that matches the question (home market, ADR, local regulatory filing), then fetch filings and numbers.

Local names matter

Many issuers are filed and discussed under a local legal name that never appears on a US terminal.

What you type	Market	Resolves to
Tencent	English query	Tencent Holdings — HK 0700, CN listings
腾讯	Chinese query	Same issuer — local name match
Toyota	English	Toyota Motor — JP 7203
トヨタ自動車	Japanese	Same issuer — local name on EDINET filings
Samsung Electronics	English	KR 005930
三星电子	Chinese (Simplified)	Same group — local catalogue row

OpenFilings keeps Latin and local names on the same entity row. Search accepts either script; the response lists both in display_names, and company profiles expose display_name_local where the registry provides it. That matters when a compliance file, wire, or local-language annual report uses the name your Bloomberg screen does not show.

What search should return

Before you spend allowance on filing history or KPIs, search should answer:

Who is this? Legal name in Latin and local script when available.
Where is it listed? Each market and symbol you can use for filings.
Which stable ID ties it together? LEI when known; otherwise the registry key for that market.

Search accepts name, ticker, ISIN, LEI, and regional listing codes (Hong Kong, mainland China). It runs across the markets on your plan.

Search and profile lookup are authenticated but do not consume credits — useful for screeners, portfolio loaders, and review before you pull filings. History and financials come next; those consume credits on success.

Examples — issuers in the catalogue

Typical search results look like this (abbreviated):

Issuer	Local name	Listings (examples)	Stable ID
Apple Inc.	—	US AAPL	ISIN US0378331005 · CIK (SEC)
Toyota Motor Corporation	トヨタ自動車株式会社	JP 7203	LEI when on file
Samsung Electronics Co., Ltd.	삼성전자주식회사	KR 005930	LEI when on file
Tencent Holdings Ltd.	腾讯控股	HK 0700 · CN listings	LEI when on file
Airbus SE	—	EU AIR · US 20-F (depositary)	LEI on ESEF filings
LVMH	—	EU MC (Euronext Paris)	LEI on ESEF filings

One search row, multiple listings — you pick the market that matches the filing you need (home annual report vs ADR vs ESEF).

GLEIF — what a LEI query returns

GLEIF (Global Legal Entity Identifier Foundation) is the public registry behind the 20-character LEI. It answers: who is this legal entity?

GLEIF uses JSON:API (application/vnd.api+json). Abbreviated payloads:

LEI → entity — GET …/lei-records/MINO79WLOO247M1IL051

{
  "data": {
    "type": "lei-records",
    "id": "MINO79WLOO247M1IL051",
    "attributes": {
      "lei": "MINO79WLOO247M1IL051",
      "entity": {
        "legalName": { "name": "Airbus SE" },
        "legalAddress": { "country": "FR" },
        "status": "ACTIVE"
      },
      "registration": {
        "status": "ISSUED",
        "initialRegistrationDate": "2012-06-06"
      }
    }
  }
}

ISIN → LEI + name — GET …/lei-records?filter[isin]=FR0000073272

{
  "data": [{
    "type": "lei-records",
    "id": "MINO79WLOO247M1IL051",
    "attributes": {
      "lei": "MINO79WLOO247M1IL051",
      "entity": { "legalName": { "name": "Airbus SE" } }
    }
  }]
}

LEI → ISIN list — GET …/lei-records/MINO79WLOO247M1IL051/isins

{
  "data": [
    { "type": "isins", "attributes": { "isin": "FR0000073272" } },
    { "type": "isins", "attributes": { "isin": "NL0000235190" } }
  ]
}

One LEI, several ISINs — see Why one LEI maps to several ISINs.

How to query GLEIF directly (public, no key):

LEI → entity: GET https://api.gleif.org/api/v1/lei-records/{LEI}
ISIN → LEI + name: GET https://api.gleif.org/api/v1/lei-records?filter[isin]={ISIN}
LEI → ISIN list: GET https://api.gleif.org/api/v1/lei-records/{LEI}/isins

OpenFilings uses GLEIF when enriching the catalogue (name confirmation, LEI backfill, ISIN cross-check). You do not need a GLEIF account for day-to-day research — search and lookup on OpenFilings already merge this into one issuer row.

OpenFIGI — tickers, FIGI, and venue symbols

OpenFIGI (Bloomberg) is an instrument directory, not an entity registry. It answers: what is this symbol on this exchange?

Request — POST https://api.openfigi.com/v3/mapping

[{ "idType": "TICKER", "idValue": "AIR", "exchCode": "FP" }]

Response (one block per request job; no LEI):

[{
  "data": [{
    "figi": "BBG000BB9TF6",
    "name": "AIRBUS SE",
    "ticker": "AIR",
    "exchCode": "FP",
    "compositeFIGI": "BBG000BB9TF6",
    "securityType": "Common Stock",
    "marketSector": "Equity",
    "securityType2": "Common Stock"
  }]
}]

With an ISIN, the same endpoint returns venue-specific lines — often several rows when the security trades on Paris, Amsterdam, and elsewhere:

[{ "idType": "ID_ISIN", "idValue": "FR0000073272" }]

→ [{ "data": [{ "ticker": "AIR", "exchCode": "FP", "name": "AIRBUS SE", … }, …] }]

OpenFIGI does not return a LEI. It is most useful when you have a European symbol (MC.PA, AIR.PA) or an ISIN from a custodian file and need the listing line that matches a price feed or a Yahoo suffix.

An optional API key raises rate limits; without it, responses are throttled.

OpenFilings uses OpenFIGI during catalogue maintenance — especially for EU and cross-listed names where the same company appears under different venue suffixes. Live search reads the merged catalogue; you query OpenFilings, not OpenFIGI directly.

ESMA FIRDS — LEI ↔ ISIN in Europe

For European instruments, OpenFilings also ingests ESMA FIRDS reference data — the regulatory instrument file published under RTS 23 (FULINS, ISO 20022 auth.017). ESMA documents file naming, download, and field semantics in FIRDS — instructions for download of full and delta reference data files (ESMA65-8-5014).

The published file is XML. One <RefData> block per instrument (abbreviated):

<RefData>
  <FinInstrmGnlAttrbts>
    <Id>FR0000073272</Id>
    <FullNm>AIRBUS SE</FullNm>
    <ClssfctnTp>ESVUFR</ClssfctnTp>
  </FinInstrmGnlAttrbts>
  <Issr>MINO79WLOO247M1IL051</Issr>
  <TradgVnRltdAttrbts><Id>XPAR</Id></TradgVnRltdAttrbts>
</RefData>

OpenFilings parses that into a normalised record when building the catalogue index:

{
  "isin": "FR0000073272",
  "lei": "MINO79WLOO247M1IL051",
  "name": "AIRBUS SE",
  "cfi": "ESVUFR",
  "venue": "XPAR"
}

Field	Source tag	Meaning
isin	`FinInstrmGnlAttrbts/Id`	12-character security id
name	`FullNm`	Instrument name as reported to ESMA
lei	`Issr`	Issuer LEI — the LEI ↔ ISIN bridge
cfi	`ClssfctnTp`	ISO 10962 class (common `EY…`, depositary `ED…`, …)
venue	`TradgVnRltdAttrbts/Id`	MIC-style trading venue (XPAR, XETR, XLON, …)

Where to download — and which FULINS file to pick

Full instrument files are listed on the ESMA Registers — FIRDS files catalogue. ESMA publishes FULINS (full) and DLTINS (daily delta) zips; naming follows FULINS_{letter}_*.zip where {letter} is the first character of the ISO 10962 CFI bucket:

CFI 1st letter	Asset class	Typical contents
C	Collective investment	Funds, REITs, ETFs
E	Equities	Listed shares — use this for ISIN → LEI of issuers
D	Debt	Bonds and other debt instruments
F	Futures / listed derivatives	Futures
H, I, J, O, R, S	Other	Structured products, misc. derivatives

For corporate issuers (Airbus, LVMH, ASML), target FULINS_E_* — not FULINS_C_*. A fund/REIT file (FULINS_C) still has the same XML shape (Issr = LEI, Id = ISIN), but the rows are unit trusts and property funds (e.g. VinaLand, Charter Hall Retail REIT), not ordinary listed operating companies. OpenFilings indexes FULINS_E_*.zip for equity ISIN ↔ LEI backfill; ESMA65-8-5014 §3 describes the naming convention.

The XML layout is the same across buckets — only the instrument population differs:

XML path	Field
`FinInstrmGnlAttrbts/Id`	ISIN
`Issr`	Issuer LEI ← the link you need
`FullNm`	Instrument name
`ClssfctnTp`	CFI code
`TradgVnRltdAttrbts/Id`	Trading venue MIC

We build an offline ISIN ↔ LEI index from ESMA FIRDS full files (FULINS_E_*.zip) and compatible FCA FIRDS drops. That complements GLEIF’s own ISIN–LEI bulk file and is often the fastest path when a holdings file contains only ISINs.

ESEF filings (annual reports on filings.xbrl.org) are keyed by LEI as entity.identifier — the same LEI you see in FIRDS and GLEIF. That is why a wire with LEI, a custodian file with ISIN, and an ESEF annual report can all converge on one issuer once the catalogue links them.

OpenFilings also monitors ESMA ESAP (the ESEF portal) for ingest health — filings flow from ESAP / filings.xbrl.org into our EU pipeline after entity resolution.

Why one LEI maps to several ISINs

This confuses many portfolio and risk workflows until you separate entity from security:

LEI = one legal entity (Airbus SE, LVMH, Samsung Electronics Co., Ltd.)
ISIN = one tradable instrument (one share class, one listing line, one DR program)

So a single LEI routinely maps to many ISINs:

Share classes — common vs preferred (different ISINs, same LEI)
Listings — Paris, Amsterdam, London, Xetra: often one ISIN per venue line
Depositary receipts — US ADR or ESEF-GB line vs home-market ordinary shares
Units and other instruments — some entities also have fund or unit ISINs under the same LEI

When OpenFilings resolves a LEI, it returns the issuer and its listings (markets + tickers). When you start from an ISIN, we pick the LEI behind that line and attach sibling listings where the catalogue knows them. For a primary ISIN among several, we prefer ordinary / common CFI classes (ESMA EY…) over depositary or preferred lines when the feed allows it.

What the OpenFilings API returns

You do not need to call GLEIF, OpenFIGI, or FIRDS yourself. OpenFilings merges those sources (plus EDGAR, EDINET, OpenDART, CNINFO, …) into one issuer row per company.

Search — `GET /api/v1/entities/search` (MCP `search_ticker`)

Accepts query, ticker, isin, or lei. Example: ?query=Airbus

{
  "entity": {
    "lei": "MINO79WLOO247M1IL051",
    "canonical_key": "lei:MINO79WLOO247M1IL051",
    "display_names": ["Airbus SE"],
    "listings": [
      {
        "market_id": "eu",
        "ticker": "AIR",
        "registry": "eu_esef",
        "company_name": "Airbus SE",
        "lei": "MINO79WLOO247M1IL051",
        "source": "registry",
        "score": 0.97
      }
    ]
  },
  "markets_skipped": [],
  "resolve_timing_ms": { "total": 42 }
}

Dual-listed issuers return several listings[] entries (e.g. EU home listing + US 20-F depositary) under the same lei and canonical_key.

Lookup — `GET /api/v1/entities/lookup?lei=…` (or `isin`, `ticker` + optional `market_id`)

Deterministic profile from the catalogue — no live GLEIF/OpenFIGI call:

{
  "canonical_key": "lei:MINO79WLOO247M1IL051",
  "display_name": "Airbus SE",
  "display_name_local": null,
  "identifiers": {
    "lei": "MINO79WLOO247M1IL051",
    "isin": "FR0000073272",
    "isins": ["FR0000073272", "NL0000235190"],
    "sec_cik": null,
    "org_id": null,
    "yahoo_symbol": "AIR.PA"
  },
  "aliases": [
    { "type": "ticker", "value": "AIR" },
    { "type": "isin", "value": "FR0000073272" },
    { "type": "search_name", "value": "Airbus" }
  ],
  "listings": [
    {
      "market_id": "eu",
      "ticker": "AIR",
      "registry": "eu_esef",
      "company_name": "Airbus SE",
      "lei": "MINO79WLOO247M1IL051",
      "primary": true
    }
  ],
  "industry": {
    "group": "Industrials",
    "sic": null,
    "damodaran": null,
    "industry_local": null
  },
  "links": {
    "filings_discover": "/api/v1/filings/discover?ticker=AIR",
    "company_page": "/companies/eu/AIR/"
  },
  "provenance": {
    "resolution_status": "resolved",
    "updated_at": "2026-06-15T10:00:00+00:00",
    "registry": "eu_esef",
    "market": "eu"
  }
}

Compared to upstream providers	OpenFilings adds
GLEIF → entity + ISIN list	`listings[]` with market, ticker, filing registry
OpenFIGI → symbol + FIGI	`canonical_key`, cross-market aliases, filing links
FIRDS → ISIN ↔ LEI + CFI	Merged `isins[]`, primary ISIN pick, company profile

Search and lookup are authenticated but not metered — suitable for screeners and portfolio loaders before you spend allowance on filing history or KPIs.

For identifier semantics (CIK vs ISIN vs LEI), see CIK, ISIN, LEI — entity identifiers. For API details, see the REST API docs.

What OpenFilings offers

One unified API for regulatory filings across 20 markets — US, Japan, Korea, Hong Kong, Taiwan, Israel, UAE, Saudi Arabia, China, Europe (ESEF), UK, and others on your plan.

One search — Latin or local name, ticker, ISIN, or LEI → the issuer, its local name, and its listings
One filing history — per market, from the same account
One KPI vocabulary — revenue, margins, cash flow normalized for comparison (cross-GAAP guide)

Same data via REST, MCP for research agents, or the web directory. Identity first; filings and numbers second.