Question 1

What is the Legal Entity Identifier (LEI) and why was it created?

Accepted Answer

The Legal Entity Identifier is a 20-character alphanumeric code that uniquely identifies a legal entity — a company, fund, trust, or other organization — participating in financial transactions. It was created in direct response to the 2008 financial crisis. When Lehman Brothers collapsed in September 2008, regulators and counterparties discovered they could not quickly determine their actual exposure to Lehman because the firm operated through hundreds of legal entities with inconsistent identifiers across different systems and jurisdictions. There was no globally consistent way to aggregate positions by counterparty. The G20 directed the Financial Stability Board to develop a global solution. The result was the Legal Entity Identifier system, formalized under ISO 17442, with the Global Legal Entity Identifier Foundation (GLEIF) established in 2014 as the central operating unit overseeing a network of Local Operating Units (LOUs) that issue and maintain LEIs. The core value of the LEI is two-sided: it provides a consistent, public identifier that connects an entity's name to its registration data and ownership structure, and it is free for anyone to query. Every LEI record in the GLEIF Global LEI Index is publicly available at no cost — a deliberate design choice to ensure that transparency is a public good, not a proprietary data service.

Question 2

What is the structure of an LEI code?

Accepted Answer

An LEI is a 20-character alphanumeric code structured under ISO 17442. The first four characters identify the LOU (Local Operating Unit) that issued the LEI — for example, '5493' identifies LEIs issued by DTCC. Characters 5 through 18 are the entity-specific identifier assigned by the LOU — a 14-character alphanumeric string unique to the entity within the issuing LOU's namespace. Characters 19 and 20 are check digits calculated using the ISO 7064 algorithm, which allows systems to detect transcription errors before the code is processed. Each LEI record carries two categories of reference data: Level 1 data — the entity's legal name, registered address, country of incorporation, registration authority and number, and legal form — and Level 2 data — the identity of the direct consolidation parent entity and the ultimate consolidation parent entity under applicable accounting standards (IFRS or US GAAP), each identified by their own LEI. The Level 2 relationship data is what allows regulators and risk managers to aggregate exposure across all subsidiaries of a parent — the core use case that motivated the LEI's creation.

Question 3

What do Level 1 and Level 2 LEI data mean for counterparty risk?

Accepted Answer

Level 1 data answers 'who is this entity': legal name, registered address, jurisdiction of incorporation, registration authority, and legal form. This is the basic identity layer — sufficient to identify a counterparty in a single transaction. Level 2 data answers 'who owns them': the Direct Parent LEI (the entity that consolidates the reporting entity under applicable accounting standards — IFRS or US GAAP) and the Ultimate Parent LEI (the entity at the top of the full consolidation chain). Consolidation under GLEIF's Level 2 standard follows accounting definitions of control, not simply majority share ownership — a parent may control a subsidiary through board control, contractual arrangements, or other mechanisms that qualify as consolidation under IFRS 10 or ASC 810, even where direct share ownership is below 50%. Level 2 data is what transforms the LEI from a name identifier into a risk management tool. A broker-dealer that trades with three different entities — each with a different LEI, legal name, and jurisdiction — may not realize they are all part of the same corporate group until Level 2 data reveals the common Ultimate Parent LEI. Without Level 2 LEI data, that aggregation requires manual corporate structure research. GLEIF publishes Level 2 relationships in a standard machine-readable format that can be queried programmatically, making group-level exposure aggregation a data pipeline step rather than an analyst task.

Question 4

What is 'No LEI, No Trade' — which regulations require an LEI?

Accepted Answer

The 'No LEI, No Trade' principle is most precisely associated with MiFID II transaction reporting: under MiFID II Article 26, investment firms cannot report an executed transaction to their national competent authority without valid LEIs for the executing firm, the counterparty, and — where applicable — the client. A missing or lapsed client LEI means the transaction report is rejected, creating a reporting gap and a potential regulatory violation. The principle has been extended colloquially to other frameworks. Under EMIR, both counterparties to a derivatives trade must have valid LEIs to report the trade to a registered trade repository. Under CFTC swap reporting rules, counterparty LEIs are required in Swap Data Repository submissions, though the CFTC framework has historically allowed temporary alternative identifiers in limited circumstances where an LEI is unavailable — unlike MiFID II, which has no such exemption. Under the SEC's Consolidated Audit Trail (CAT), LEI is used as a supplemental identifier for institutional accounts in CAIS submissions; the primary CAT account identifier is the Firm Designated ID (FDID), with LEI as an additional field. The consistent thread across frameworks is that LEI is required for meaningful cross-border regulatory reporting aggregation — its absence does not just create a reporting error for the transaction in question, it breaks regulators' ability to aggregate exposure data across jurisdictions.

Question 5

What happens when an LEI lapses and how does it affect settlement and reporting?

Accepted Answer

An LEI lapses when the entity fails to complete the annual renewal and data verification required by GLEIF. The renewal involves confirming that the entity's Level 1 reference data (name, address, registration) is current and, where applicable, verifying or updating the Level 2 parent relationships. A lapsed LEI retains its code in the GLEIF database but its status changes from ISSUED (active) to LAPSED — visible to anyone querying the GLEIF Global LEI Index. The operational consequences of a lapsed LEI are significant across settlement and reporting pipelines. In ISO 20022 sese.023 settlement instructions, a lapsed LEI in the SettlementParties block creates compliance risk and — depending on the CSD's participant validation rules — may cause instruction rejection or downstream compliance flags. The risk varies by CSD: some European CSDs operating under CSDR settlement discipline apply LEI presence and status checks as part of instruction intake; others validate LEI format but not lifecycle status at the instruction level, leaving the status check to the participant's own pre-submission processes. Regardless of where the CSD validation falls, a lapsed LEI on a sese.023 submitted at 9:00 PM on trade date creates a compliance gap under CSDR — the sese.023 instruction may settle mechanically but the party identification is non-compliant, generating penalties or regulatory flags under CSDR's settlement discipline framework. In MiFID II transaction reporting, a lapsed LEI is unambiguous: the transaction report is rejected by the national competent authority's validation engine. The remediation time — contacting the LOU, completing renewal, waiting for the GLEIF index to update — typically takes 24-48 hours. Under T+1, that window does not exist. The annual renewal cost for most entities is modest — typically under $200 — but the operational cost of a lapsed LEI can include settlement fails, regulatory reporting gaps, and the manual remediation required to restore active status, which typically takes 24-48 hours through a LOU.

Question 6

How does the LEI function in ISO 20022 sese.023 settlement instructions?

Accepted Answer

In ISO 20022 sese.023 settlement instructions, the LEI is the primary structured identifier for each party in the SettlementParties block. The sese.023 message carries separate party identification elements for the delivering settlement party, the receiving settlement party, the delivering agent, the receiving agent, and — in more complex structures — the investor and place of safekeeping. Each party element has an Identification sub-element that can carry a BIC (SWIFT Bank Identifier Code), an LEI, or a proprietary code. For transactions where LEI is required — most cross-border and institutional settlement — the LEI is the identifier that European CSDs validate to confirm the party is a known, active market participant. This is why the connection between the FIX execution layer and the sese.023 instruction layer matters: the LEI for each party must be resolved from the firm's reference data and SSI records at enrichment time, before the sese.023 is generated. If the enrichment layer cannot resolve a valid LEI for the clearing broker or custodian, the sese.023 will either carry a blank LEI element — causing CSD rejection — or a stale, lapsed LEI — also causing rejection. The presence of structured LEI data in the sese.023 also supports the compliance and audit trail requirements of the settlement instruction: regulators and CSDs can trace the instruction to a uniquely identified legal entity rather than relying on a name string that may be abbreviated, truncated, or inconsistently formatted — which was precisely the failure mode that legacy MT54x free-text party fields introduced.

Question 7

How is the LEI used in CAT (Consolidated Audit Trail) reporting?

Accepted Answer

The Consolidated Audit Trail (CAT) — mandated under SEC Rule 613 and operated by FINRA — requires broker-dealers to report detailed order and execution data to the CAT repository. The CAT Customer and Account Information System (CAIS) uses the Firm Designated ID (FDID) as the primary account identifier for customer accounts; LEI is a supplemental identifier field in CAIS submissions for institutional accounts, not a mandatory primary key. Where a broker-dealer maintains LEI records for institutional customers and includes them in CAIS submissions, the LEI provides regulators with a cross-referenceable identity that connects the CAT record to the firm's MiFID II transaction reports, EMIR submissions, and GLEIF data — enabling cross-jurisdictional regulatory analysis. The FIX protocol connection is relevant: Tag 52 (SendingTime) provides the microsecond timestamp required by CAT for order event sequencing, and the parties in Tag 453 — including the institutional customer — should be associated with LEIs in the firm's reference data for complete regulatory cross-referencing, even where the CAT submission itself uses an FDID as the primary key. A firm that maintains LEI records for institutional counterparties in its reference data is better positioned for multi-jurisdiction regulatory inquiries, even in frameworks where LEI is supplemental rather than the sole required identifier.

Question 8

What is the vLEI (Verifiable LEI) and why does it matter in 2026?

Accepted Answer

The Verifiable LEI (vLEI) is a cryptographically secured digital version of the LEI, standardized under ISO 17442-2. Where the traditional LEI is a 20-character code stored in a central database and verified by querying the GLEIF index, the vLEI is a W3C Verifiable Credential — a digitally signed attestation that an entity holds a valid LEI, issued through GLEIF-accredited Qualified vLEI Issuers (QVIs) with GLEIF as the cryptographic Root of Trust. The vLEI can be embedded in digital documents, API payloads, and digital infrastructure as a machine-readable, self-verifying identity proof — the receiving party verifies the cryptographic signature without querying the GLEIF database at the moment of verification. In 2025-2026, GLEIF is piloting vLEI adoption in regulatory filing authentication and digital identity frameworks for financial institutions; early-stage use cases in digital bond documentation and institutional onboarding workflows are in development or limited deployment. The vLEI is not yet mainstream in settlement instruction workflows, but its architecture positions it as the identity layer for contexts where database-query identity verification is insufficient — where identity must be proven by the credential holder rather than looked up in a third-party index. For broker-dealers tracking the trajectory of digital asset settlement infrastructure, the vLEI's progression from pilot to production is worth monitoring: it represents the convergence of the LEI's regulatory identity function with cryptographic verification standards that on-chain settlement environments require.

Question 9

How do firms obtain and renew an LEI?

Accepted Answer

LEIs are issued by GLEIF-accredited Local Operating Units (LOUs) — organizations authorized to register and maintain LEI records within the global system. In the United States, DTCC is an accredited LOU through its GMEI (Global Markets Entity Identifier) service. In Europe, accredited LOUs include WM Datenservice, the London Stock Exchange, and others — the LOU landscape has evolved as providers have consolidated and new entrants have been accredited; the full current list is maintained on the GLEIF website. A firm obtains an LEI by submitting an application to any accredited LOU — the firm does not need to use the LOU in its home jurisdiction, as the global system accepts cross-border registrations. The application requires the firm's legal name, registered address, jurisdiction of incorporation, registration authority and number, and — for entities with a parent — the parent's LEI for Level 2 relationship data. Initial registration typically costs between $65 and $200 depending on the LOU and entity type. Annual renewal is required — the LOU re-verifies the entity's Level 1 reference data and updates Level 2 relationships if the ownership structure has changed. Failure to renew causes the LEI to lapse; reinstatement requires paying the renewal fee and completing the verification process, which typically takes 24-48 hours. For broker-dealers managing large counterparty books — prime brokerage clients, institutional counterparties, swap counterparties — maintaining current LEI records for all entities is an ongoing data management function, not a one-time registration exercise. Many firms run scheduled GLEIF API queries against their counterparty LEI database to detect lapsed or pending-validation status before it causes a settlement or reporting failure.

Regulation	Jurisdiction	LEI Requirement	Consequence of Lapsed / Missing LEI
MiFID II Article 26	EU / EEA	Executing firm + counterparty + client	Transaction report rejected by NCA
EMIR	EU	Both counterparties to derivative	Trade repository submission fails
CFTC Swap Reporting	US	Both counterparties	SDR submission invalid
CAT CAIS (Rule 613)	US	Supplemental institutional account identifier	Cross-jurisdiction regulatory tracing impaired
CSDR Settlement Discipline	EU	Party in sese.023 SettlementParties	Compliance gap; settlement discipline penalties may apply
FATF Recommendation 16	Global	Legal entity counterparty in wire transfers	AML/KYC due diligence incomplete

Legal Entity Identifier (LEI)

Definition

LEI regulatory mandates — key frameworks requiring valid LEIs

How it works

In Devancore™

Related terms