Find a Company's Parent From Its LEI: Direct Parents, Ultimate Parents and Subsidiaries

To find a company's parent from its LEI, read the entity's record from the public LEI registers and look at its direct and ultimate parent fields. The same registers also list a parent's subsidiaries, so one 20-character code gives you the group above and below an entity. This guide shows the steps, one real request and response, what it costs and where the data stops. The GLEIF company source page is the reference for exact fields, request shape and prices.

The short version

• —The answer: a LEI record names a direct parent and an ultimate parent by their own LEIs, or gives an exception reason when none is reported. Listing children is a separate lookup on the parent's LEI.
• —Who it is for: teams onboarding vendors and counterparties, screening groups, or running an agent through a due-diligence task, who need to know which group an entity belongs to.
• —What it costs: 5 points for a resolved entity record, 1 point per returned record for searches and for the list of subsidiaries ($1 per 1,000). A lookup that finds nothing is free, as the source pages state.
• —What it does not do: it covers only entities that hold a LEI, so it is not a full ownership tree built from filings.

Finding a company's parent from its LEI

A Legal Entity Identifier (LEI) names one legal entity in a public register, in the same 20-character format everywhere. It is not a tax number or a company number issued by one government. It sits next to those: the record carries the registration authority and the entity's number there, so you can match a LEI to a national register entry.

Know which source to call

The catalog reads two public sources of LEI data and a third that lists children.

• —GLEIF company reads the Global LEI Index record for one LEI: previous names, legal form, registration authority and number, addresses, BIC and ISIN codes, registration and renewal dates, managing issuer, fund and branch relationships, and the direct and ultimate parents and children. 5 points per resolved lookup.
• —LEI Lookup company reads the public register at lei-lookup.com: name, entity and LEI status, dates, managing issuer, legal form, registration authority, addresses, a parents object and subsidiary counts. 5 points per resolved lookup.
• —LEI Lookup company relationships takes a parent LEI and returns its subsidiaries, direct and ultimate, one row per child. 1 point per returned record. The source page has the field list.

How parents and children are recorded

The register records a group in two directions, and they live in different places in the response.

• —Looking up from a child: the record has parent fields. In the GLEIF company record these are direct_parent, ultimate_parent and, next to each, an exception object. In the LEI Lookup company record they sit in a parents object with direct, ultimate, direct_exception and ultimate_exception.
• —Looking down from a parent: the record carries counts (direct_children_total, ultimate_children_total) and, in the GLEIF record, a shortened list of children. The full list is what the relationships source returns.

A direct child is owned one step below the parent. An ultimate child sits under the parent at the top of a chain, and a child can be both: in the sample below, both rows are direct_and_ultimate_child. The flags direct_child and ultimate_child on each row say which applies.

The exception fields matter as much as the parent fields. In the GLEIF company sample, direct_parent and ultimate_parent are both null, each paired with an exception object whose reason is NATURAL_PERSONS. The register gives a reason code where a parent LEI would otherwise appear. Treat a null parent and an exception reason as two different facts, and store the reason.

The steps

1. —Resolve a name to a LEI. If you only have a name, call LEI Lookup search or GLEIF company search with it, plus a country or status filter if you know one. Each match comes back with its LEI, name, country, entity status and LEI status. Read total_found and use max_items to cap the records you pay for.
2. —Read the record. Pass the LEI to GLEIF company or LEI Lookup company. Check that the LEI is still ISSUED rather than lapsed, when next_renewal_date falls, and the registration authority and number.
3. —Read the parent fields. A named parent is a LEI. Run it through step 2 to climb another level. An exception reason goes on the file as it is.
4. —Read the group counts. direct_children_total and ultimate_children_total give a sense of group size before you spend points listing children.
5. —List the children. Pass the parent LEI to the relationships source with a max_items cap, and use start_page for large groups.
6. —Follow each child. Every row carries the child's own LEI and a link. Feed that LEI back into step 2 for the children you care about.

A worked example: tracing a vendor's group

An illustrative case: a finance team at a logistics company is onboarding Acme Oy (Finland) as a new supplier. The contract is with the Finnish entity, but procurement policy asks who the ultimate parent is before a contract above a set value is signed. This is a made-up scenario, and no figures are implied.

1. —Resolve the name. They run a LEI search on "Acme Oy" with a country filter. If a match comes back with lei_status ISSUED and an ACTIVE entity status, they take that LEI; if nothing comes back, they note that no LEI exists in the register and move to the national register.
2. —Read the record. They compare the registration authority and the entity's number there with the number on the contract. A mismatch stops the process.
3. —Read the parent fields. The record either names a direct and an ultimate parent by LEI or gives an exception reason. A named parent goes through step 2 as well; an exception reason is noted on the vendor file.
4. —List the siblings. Running the ultimate parent through the relationships source with a modest max_items shows other entities in the group, which they check against the existing vendor list.
5. —File the evidence. Each result carries the register URL it was read from and a session id, so the vendor file points at the register for every fact.

The outcome is not a risk score; it is a documented answer to who this entity is and who sits above it.

One real request and response

Here is a request to LEI Lookup company relationships for a parent LEI, capped at two returned records. It is taken straight from the source page.

curl -X POST https://api.neuralverge.ai/functions/v1/run_lei_lookup_company_relationships \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"company":"7LTWFZYICNSX8D621K86","max_items":2}'

And the response. This is a real captured response from the source page, not a mock-up. The session id in it is a placeholder value, as on the source page.

{
  "session_id": "11111111-1111-1111-1111-111111111111",
  "kind": "lei_lookup_company_relationships",
  "company": "7LTWFZYICNSX8D621K86",
  "company_id": "7LTWFZYICNSX8D621K86",
  "max_items": 2,
  "start_page": 1,
  "partial": false,
  "human": "# LEI Lookup (lei-lookup.com) — company relationships\n\n- **Company:** 7LTWFZYICNSX8D621K86\n- **Results:** 2 of 479 found\n- **Proxy traffic:** 191.0 KB",
  "machine": {
    "total_items": 2,
    "first_item": {
      "id": "7LTWFZYICNSX8D621K86-2138003FL72FCO53LM68",
      "registration_number": "2138003FL72FCO53LM68",
      "lei": "2138003FL72FCO53LM68",
      "name": "HISTRIA INVERSIONES DESIGNATED ACTIVITY COMPANY",
      "relation": "direct_and_ultimate_child",
      "direct_child": true,
      "ultimate_child": true,
      "parent_lei": "7LTWFZYICNSX8D621K86",
      "url": "https://www.lei-lookup.com/record/2138003FL72FCO53LM68/"
    },
    "items": [
      {
        "id": "7LTWFZYICNSX8D621K86-2138003FL72FCO53LM68",
        "registration_number": "2138003FL72FCO53LM68",
        "lei": "2138003FL72FCO53LM68",
        "name": "HISTRIA INVERSIONES DESIGNATED ACTIVITY COMPANY",
        "relation": "direct_and_ultimate_child",
        "direct_child": true,
        "ultimate_child": true,
        "parent_lei": "7LTWFZYICNSX8D621K86",
        "url": "https://www.lei-lookup.com/record/2138003FL72FCO53LM68/"
      },
      {
        "id": "7LTWFZYICNSX8D621K86-213800D3OXAL3N7T1S19",
        "registration_number": "213800D3OXAL3N7T1S19",
        "lei": "213800D3OXAL3N7T1S19",
        "name": "Tagus - Sociedade de Titularização de Créditos, S.A.",
        "relation": "direct_and_ultimate_child",
        "direct_child": true,
        "ultimate_child": true,
        "parent_lei": "7LTWFZYICNSX8D621K86",
        "url": "https://www.lei-lookup.com/record/213800D3OXAL3N7T1S19/"
      }
    ],
    "total_found": 479,
    "page_count": 1,
    "blocked": false,
    "proxy_traffic_bytes": 195573
  },
  "total_points": 2
}

Reading the response

• —total_found is 479, the register's count of children. total_items is 2, because max_items was 2.
• —Each row has the child's lei, name, relation, the booleans direct_child and ultimate_child, the parent_lei you asked about and a url to the child's record. first_item repeats the first row.
• —Both rows are direct_and_ultimate_child. The sample does not name the parent entity, and this guide does not guess at it.
• —total_points is 2: two returned records at 1 point each.
• —blocked is false on a normal run. If it is true, the register could not be read, so do not treat an empty list as an answer.

A row carries only LEI, name and relationship. For a child's address, status or dates, run its LEI through LEI Lookup company or GLEIF company.

Reading a parent in the other direction

For the climb up the chain, the GLEIF company response is the one to read. Here is an excerpt of its real sample response, shortened by removing every other field and the children arrays, with ... marking the cuts. The full sample is on the source page.

{
  "kind": "gleif_company",
  "company": "HWUPKR0MPOU8FGXBT394",
  "machine": {
    "company": {
      "name": "Apple Inc.",
      "status": "ISSUED",
      "entity_status": "ACTIVE",
      "next_renewal_date": "2027-03-08",
      "managing_lou": { "name": "Bloomberg Finance L.P." },
      "direct_parent": null,
      "direct_parent_exception": {
        "category": "DIRECT_ACCOUNTING_CONSOLIDATION_PARENT",
        "reason": "NATURAL_PERSONS"
      },
      "ultimate_parent": null,
      "ultimate_parent_exception": {
        "category": "ULTIMATE_ACCOUNTING_CONSOLIDATION_PARENT",
        "reason": "NATURAL_PERSONS"
      },
      "direct_children_total": 8,
      "ultimate_children_total": 20,
      ...
    }
  },
  "total_points": 5
}

The record has no parent LEI, and instead tells you why it has none. Its direct_children_total of 8 and ultimate_children_total of 20 are the counts you would use to size the group before listing children with the relationships source.

REST and MCP

The platform is the product: a catalog of sources that return typed records in one envelope (a session id, a readable summary, the structured result and the points charged). REST and MCP are two ways to reach it, and the request body is identical in both. REST fits a pipeline step or a schedule. MCP lets an agent call the same source mid-task and decide whether it needs the parent record or the children list.

The lookup above as a tool call on the hosted MCP server uses the same arguments. The tool name is the endpoint name with underscores.

{ "tool": "run_lei_lookup_company_relationships", "arguments": {"company":"7LTWFZYICNSX8D621K86","max_items":2} }

The other tools follow the same pattern, for example run_lei_lookup_companies and run_gleif_companies. The setup for Claude and other clients is in the MCP server guide.

Cost and limits

Points come out of your monthly plan allowance, and the pricing page lists the plans. The source pages state that a lookup that finds nothing is free: a LEI that does not resolve, a search with no hits, and an entity with no children all cost nothing.

Mapping a group has a cost shape worth planning for. Listing all 479 children of the parent in the sample would be 479 returned records at 1 point each, paged with start_page. That is arithmetic on the stated rate, not a benchmark. If you only need to know whether a group is large, read the counts from the 5-point record and skip the list. Each child you then follow costs a further 5-point lookup.

Pitfalls to plan around

• —Only entities that hold a LEI are in the register. A company without one will not resolve, and a search that returns nothing does not prove the company does not exist.
• —Only subsidiaries that hold a LEI and are reported to the register appear. The children list is the register's view of a group, not an ownership tree built from filings.
• —Relationship rows are thin. LEI, name and relationship type only; detail needs a second lookup per child.
• —Large groups can have hundreds of children. Set max_items and page with start_page.
• —A lapsed LEI is still a record. The search sample includes an entity whose LEI status is LAPSED, so read lei_status and next_renewal_date.
• —Names can be ambiguous. The Apple search on the LEI Lookup source found 535 matches, so confirm country and registration authority before following a relationship.
• —A null parent is not a missing parent. Keep the exception reason instead of discarding it.

How to decide

The register is public, so reading it by hand is reasonable for one or two entities. The case for a request is repetition: the same lookup on a hundred counterparties, or an agent climbing a parent chain with no person in the loop, is easier with one response shape than with a parser per page. National registers answer who is registered and who the officers are; the LEI registers answer which entity this is globally and what group it belongs to, and the registration number in a LEI record connects the two. Work through these questions:

• —Does your population hold LEIs? Test a sample of real counterparties first; only entities that hold one are covered.
• —How will you handle exception reasons? Decide what your system does when a parent is null with a reason code.
• —Do you read status and dates? Check lei_status, entity status and next_renewal_date before treating a record as current.
• —Do you cap large groups? Set max_items and a page strategy before running relationships against a parent with hundreds of children.
• —Is it counterparty or vendor onboarding? Confirm which legal entity is on the contract, whether its LEI is current and who sits above it.
• —Is it group-level screening or exposure review? Expand one LEI into its related entities so a check on a parent covers its subsidiaries, and related counterparties are not treated as unrelated.

Frequently asked questions

How do I find a company's parent from its LEI?

Read the entity's record from GLEIF company or LEI Lookup company and check the direct and ultimate parent fields. If a parent is reported, it comes back as a LEI you can look up in turn. If the field is null, check the exception reason next to it, which says why no parent LEI is given.

What is a LEI and why use it as an entity key?

A Legal Entity Identifier is a 20-character code that identifies one legal entity in the public LEI registers. Because the same code means the same entity in every country, it works as a join key when company names, spellings and national registration numbers do not line up across your systems.

Do all companies have a LEI?

No. Only entities that hold a LEI appear in the register, and the subsidiary list only contains children that hold a LEI and are reported to the register. An empty result means the entity is not in the register, not that the company does not exist.

What is the difference between GLEIF company and LEI Lookup company relationships?

GLEIF company returns the full Global LEI Index record for one LEI, including the direct and ultimate parent fields and a list of children. LEI Lookup company relationships reads the public register at lei-lookup.com and returns the subsidiaries of a parent LEI as rows, with a relationship type and a link, which you can page through when a group is large.

What does it cost to list subsidiaries?

LEI Lookup company relationships costs 1 point per returned record, which is $1 per 1,000, and max_items caps the spend. An entity with no children costs nothing. A full GLEIF company or LEI Lookup company record costs 5 points, charged only when the record resolves.

Is MCP available for these sources?

Yes. The sources are available over REST and as MCP tools on the hosted MCP server, with an identical request body. The tool names are the endpoint names with underscores, for example run_lei_lookup_companies.

How current is the data?

The register is read at request time, so the answer reflects the register as it stands when you ask. A record is only as current as what the entity and its issuer have reported, which is why the renewal and last-update dates are part of the response.