How to look up a company’s LEI with an AI agent

A Legal Entity Identifier (LEI) is the closest thing the world has to a passport number for companies. If an AI agent needs to know exactly which legal entity it is dealing with, the LEI register is usually the first place to ask, and it is open to anyone. This guide covers what the code means, how an agent should query it, and the three mistakes that turn a correct lookup into a wrong answer.

What is an LEI?

An LEI is a 20-character code that identifies one legal entity. GLEIF, the Global Legal Entity Identifier Foundation, describes it as a unique alphanumeric code under ISO 17442, linked to reference information that answers “who is who” and “who owns whom”. The first eighteen characters identify the entity and the last two are check digits, so a mistyped code can be caught before anyone looks it up.

Each record carries the entity’s legal name, its registered and headquarters addresses, its legal form, the jurisdiction it was formed in, and, for almost every entity, information about its direct and ultimate parents. The data is published under the CC0 licence, and GLEIF calls the LEI “a public good, available free of charge to all users”.

How many organisations have one?

More than 3.1 million LEIs were active at the end of the second quarter of 2026, according to GLEIF’s quarterly figures, with 92,000 issued in the quarter and growth of 3.0 per cent. GLEIF also reported that 87.9 per cent of LEIs were fully corroborated, and that 99 per cent of the LEI population reported parent information.

Growth is uneven, and it follows regulation. India grew fastest after its central bank made the LEI compulsory for participants in the markets it regulates, and GLEIF attributes growth in Latvia and Lithuania to the continuing application of the EU’s Digital Operational Resilience Act.

Fastest-growing LEI jurisdictions, second quarter of 2026

Show the data

Item	Value	Note
India	7.1%	After the RBI made the LEI compulsory in its markets
Latvia	5.2%	Attributed to the EU’s DORA
Brazil	5.1%
Lithuania	4.7%	Attributed to the EU’s DORA
United Arab Emirates	4.6%
Global average	3.0%

How should an agent query the register?

By identifier, whenever it has one. A request for a single LEI returns one record, and that record either exists or it does not. GLEIF’s public API returns a record at a predictable address, for example https://api.gleif.org/api/v1/lei-records/HWUPKR0MPOU8FGXBT394 for Apple Inc. In our own work, IKAG’s first capability reads it without an API key.

GLEIF also publishes two MCP servers of its own, in beta: one searches the LEI register and the other answers questions about LEI statistics. GLEIF says they work with assistants such as ChatGPT, Claude and Mistral, and that a call sends only the parameters needed for the lookup. If you want your own assistant to look up LEIs today, that is the most direct route.

By name only when it has to, and then as a search, not an answer. In a test of IKAG’s first capability on captured records, the name “SPDR S&P 500 ETF Trust” matched three entities in the register, one of them inactive. The right response to a name is the list of candidates and a question back to the user, not a guess.

Three habits keep an agent fast and fair to the source:

• Cache by LEI. Records change rarely; the record says when it was last updated, so store that date with the value.
• Pace requests. Public registries limit how quickly any one client may call them. Treat a refusal as a signal to slow down, not as “no record”.
• Keep the record’s own dates. A value fetched today can come from a record last updated months ago. Report the record’s date, not the fetch time.

Registration status is not entity status

An LEI record has two statuses, and agents often confuse them.

Field	What it describes	Common values
Registration status	The LEI registration itself	ISSUED, LAPSED, RETIRED, MERGED
Entity status	Whether the entity is reported as active	ACTIVE, INACTIVE

A registration is lapsed when it has not been renewed and has passed any grace period for renewal. That is a fact about paperwork. GLEIF has been explicit that a lapsed LEI does not mean the associated legal entity is inactive. An agent that reads LAPSED and answers “this company no longer exists” has invented a fact.

No match is not “no company”

A search that finds nothing tells you about the search, not the world. A company may have no LEI because it never needed one, because it is registered under a different name, or because the identifier you searched with belongs to another system.

When IKAG’s first capability asked GLEIF about Apple by its SEC identifier, the register returned no match: Apple’s LEI record does not name that SEC number. The company plainly exists; that record simply was not the place that links those two identifiers. The honest answer is “not established from this source”, with the reason.

Linking an LEI to other identifiers

Agents often hold more than one identifier for the same company. Join them only when a primary record names both. Wikidata stores LEIs under property P1278 and is useful for finding a candidate, but community data can agree with a value without proving it. In our tests, an LEI and an SEC CIK that no primary record linked were kept apart, and the result said why.

What an agent should return

A good LEI lookup returns more than a name. It returns:

1. The value, for example the legal name.
2. The record it came from: the LEI, the source, and a link to the record.
3. The record’s own date, when the source states one.
4. The statuses, registration and entity, reported separately.
5. What was not established, with the reason: no match, not in the record, or several candidates.

That is the difference between an answer and a checkable answer. The second takes a few more fields, and it is the only kind you can rely on.