LEI Level 2 Data: Parent Relationships and Who Owns Whom

Two layers, two questions

The Legal Entity Identifier (LEI) is a 20-character alphanumeric code defined by ISO 17442. GLEIF, the foundation that administers the system, states that every LEI is unique and can represent only one entity, and that the code connects to reference data answering two questions: "who is who" and "who owns whom" ^[1].

Level 1 data is the business card: official legal name, registered address, country of formation and key dates ^[2]. Level 2 data is relational. Entities with an LEI report their direct and ultimate accounting consolidating parents; where both sides hold LEIs, each record shows the other's LEI ^[3]. The Regulatory Oversight Committee (ROC), a group of public authorities that oversees the system ^[4], set the collection policy in March 2016, and collection began in May 2017 ^[3].

This article treats the second layer as a data source. The general merge-or-relate decision is covered in Merge or Relate? A Framework for Organization Records, and the identifier itself on the LEI standards page.

What "parent" means in Level 2

"Owns" is shorthand. The Level 2 parent is defined by accounting consolidation, not by shareholding percentages or legal control.

The ROC's 2016 policy, as summarized by GLEIF, defines the ultimate accounting consolidating parent as "the highest level legal entity preparing consolidated financial statements", and identifies both parents "based on the accounting definition of consolidation applying to this parent". The ROC chose accounting definitions because they apply to financial and non-financial companies, IFRS and US GAAP had converged on the scope of consolidation, and they are public and audited, while acknowledging they were designed for a different purpose ^[4].

The Relationship Record format makes the definitions operational ^[5]:

• IS_DIRECTLY_CONSOLIDATED_BY: the child's accounts are fully consolidated by the parent, in the sense of the accounting standard named in the record's qualifiers, and the parent is the closest fully consolidating parent in the ownership structure.
• IS_ULTIMATELY_CONSOLIDATED_BY: the same test, but the parent is the most distant fully consolidating parent.

The same format carries other relationship types that are not parent relationships: IS_INTERNATIONAL_BRANCH_OF (a branch to its head office), and, since version 2.0, the fund types IS_FUND-MANAGED_BY, IS_SUBFUND_OF and IS_FEEDER_TO ^[6]. Loading every record into a "parent" column mixes fund managers and head offices into the consolidation hierarchy.

Level 2 is not beneficial ownership

The Financial Action Task Force (FATF) defines a beneficial owner, in the context of legal persons, as "the natural person(s) who ultimately owns or controls a customer", and adds that "only a natural person can be an ultimate beneficial owner" ^[7]. Level 2 cannot satisfy that definition by construction. Its endpoints are legal entities identified by LEIs, and an entity controlled by natural persons without an intermediate consolidating legal entity reports an exception rather than a parent ^[8]. The ROC itself called accounting consolidation a starting point, leaving "many other aspects of ownership, control or other relationships" to later phases ^[4]. Open Ownership, which maps GLEIF data into its Beneficial Ownership Data Standard, states that GLEIF's corporate ownership data "is not beneficial ownership data as it does not identify the natural persons at the end of ownership chains" ^[9].

A Level 2 parent is therefore a lead for group structure. It is not evidence of a beneficial owner under any national regime that implements the FATF standard.

Anatomy of a relationship record

Each relationship record holds exactly one directional relationship between two legal entities: a StartNode (the child) and an EndNode (the parent) ^[6]. The fields that matter downstream, per the RR-CDF 2.1 format page:

Two distinctions are easy to lose. RelationshipStatus and RegistrationStatus are different facts: a LAPSED record was not re-certified by its renewal date; the parent may still consolidate the child. And FULLY_CORROBORATED means the data "has been validated against an explicit relationship statement found in key sources (e.g. consolidated financial statements)", while ENTITY_SUPPLIED_ONLY means the record relies significantly on what the submitter provided "due to the unavailability of corroborating information" (same source). The validation level is provenance and belongs on the edge.

The file header's ContentDate, "the date and time as of which the data contained in the file is valid" (same source), not the download time, is the as-of date of every edge.

Reporting exceptions: when no parent is reported

A relationship record exists only when the parent has an LEI ^[5]. Every other outcome is a reporting exception: a record naming the child's LEI, an ExceptionCategory (DIRECT_ACCOUNTING_CONSOLIDATION_PARENT or ULTIMATE_ACCOUNTING_CONSOLIDATION_PARENT), one or more ExceptionReason codes and an optional ExceptionReference to the legal basis ^[8].

The reason list changed in 2022. In a policy dated 7 January 2022, the ROC consolidated five opt-outs into one NON_PUBLIC reason and discontinued collection of Provisional Node Identifier (PNI) data on parents without LEIs ^[10]. GLEIF's format page lists the current state as of today:

Sources: GLEIF, Reporting Exceptions 2.1; ROC, 2022.

The first three reasons say no parent exists under the accounting definition; NON_PUBLIC and NO_LEI say a parent may exist but is unpublished. Never collapse them into one "no parent" flag. The ROC also states that "an entity is not required to provide non-public relationship information in order to register or renew an LEI" (same source), so a NON_PUBLIC exception is a permitted answer, not a compliance gap. Loaders should map the five deprecated codes, which older records still carry, to NON_PUBLIC.

The asymmetry is large. The ROC reported, from GLEIF statistics, that an LEI-to-LEI parent relationship existed for 5 to 6 percent of entities with LEIs, that the accounting definition did not apply for roughly 83 percent, that the relationship was non-public for roughly 7 percent and that the parent lacked an LEI for roughly 4 percent ^[10]. These are historical, pre-2022 proportions.

Golden Copy, Concatenated Files and the API

GLEIF publishes Level 1, relationship records and reporting exceptions as parallel datasets through three channels.

• Concatenated Files combine issuers' files once a day, unmodified. During a transfer between issuers an LEI can appear twice for a few business days, and an issuer glitch can leave records missing ^[11]. On 28 October 2026 the concatenated files listed 3,476,604 LEI records, 676,117 relationship records and 6,279,012 reporting exceptions ^[12]. The Golden Copy for the same date reports different totals, so any count should name the file it comes from.
• Golden Copy Files come from a GLEIF database updated up to ten times a day and are published three times daily (02:00, 10:00 and 18:00 UTC) in XML, CSV and JSON, with transfer duplicates resolved and geocoded addresses added. Each publication has four delta files, relative to the copies of 8 hours, 24 hours, 7 days and 31 days earlier ^[11][13].
• The GLEIF API is based on the Golden Copy. It exposes relationship records and reporting exceptions through links on each LEI record, with owns and ownedBy filters for parents and children ^[14].

The Golden Copy with deltas suits a reference-data pipeline; the API suits point lookups at onboarding. Either way, store the ContentDate or retrieval time beside each fact so a past parent assertion can be reproduced.

Worked example: the Halden group

All entities and LEIs in this example are fictional. The codes beginning FICT00 are invented for illustration, are not valid LEIs and fail the ISO 7064 check-digit test.

Halden Therapeutics AG is a fictional Swiss pharmaceutical company. Its group, as GLEIF data might describe it:

The internal vendor master holds five rows: "Halden Therapeutics", "Halden Therapeutics GmbH", "Halden US Holdings LLC", "Halden Biologics" and "Halden Ventures". A procurement analyst wants group-level spend.

Step 1, resolve each row to one legal entity. Each row is matched to a Level 1 record on legal name, registered address and registry identifier. "Halden Therapeutics" without a legal form stays ambiguous between the AG and the GmbH until a registry number settles it. Halden US Holdings LLC has no LEI; it keeps its own canonical identifier rather than a forced match to the nearest Halden record.

Step 2, attach edges, not merges. Each relationship record becomes a typed edge between two canonical entities, carrying its type, status, validation level, accounting period and ContentDate. No entity record absorbs another.

Step 3, keep exceptions as first-class statements. Halden Biologics' direct-parent exception is NO_LEI, so the system knows a direct parent exists and is unpublished. An internally sourced edge to Halden US Holdings LLC can fill the gap, labelled as internal. Halden Ventures' NATURAL_PERSONS exception places it outside the consolidation perimeter despite the shared name: group spend should exclude it, and any founder link belongs in beneficial-ownership evidence, not in Level 2.

Step 4, answer from the edges. Group spend sums entities whose ultimate-parent edge points to Group Holding, plus Group Holding. Merging the GmbH, the AG and Biologics into one "Halden" record might give the same total, but would fuse the contracts and screening results of three legal persons, and would be hard to reverse.

Joining LEI data to internal records

1. Match at Level 1, relate at Level 2. Resolution compares names, addresses and registry identifiers to Level 1 records. Level 2 never decides identity; it connects entities already resolved.
2. Keep the LEI as an attribute of the canonical record, with its own status. A Level 1 LAPSED status means the registration "has not been renewed by the NextRenewalDate and is not known by public sources to have ceased operation" ^[15]. A lapsed LEI still identifies a live entity; dropping it breaks joins to historical filings.
3. Treat a missing edge as unknown. Absence of a relationship record proves nothing; only an exception record says why no parent is published, and only some exception reasons say there is no parent.

Data quality checks before relying on Level 2

GLEIF's data-quality team describes checks that prevent circular direct-parent chains and ensure that all direct parents and their children "converge on the same ultimate parent or the same reporting exception", and 2025 additions that flag parents whose legal form means they are not expected to consolidate other entities ^[16]. Consumers should rerun equivalent checks, because internal edges and stale snapshots add errors GLEIF never sees.

This article is educational and is not legal or regulatory advice; obligations on beneficial ownership and counterparty data depend on the jurisdiction and the regulator.

Reliable Context keeps one canonical record per real thing, with a cited, dated source behind every value, unknowns declared and any past state reproducible, inside the customer's perimeter.