An LEI is not KYB: what a company identifier can tell you, and what it cannot

The Legal Entity Identifier is one of the cleanest ideas in financial data: give a legal entity a globally unique identifier and make its reference data easier to connect across systems. That is enormously useful. It is also easy to overstate.

An LEI is not a completed Know Your Business decision. It is not proof that a company is safe to onboard. It is not a guarantee that beneficial-ownership information is complete, current or relevant to the relationship you are considering. And it is not a substitute for sanctions screening, authorised-signatory checks or an analyst’s judgment.

The distinction matters because good KYB is not the act of collecting fields. It is the act of deciding whether the available evidence is sufficient for a particular business relationship.

Short answer

Use an LEI as a high-quality entity identifier and, where available, a route into reference and relationship data. Do not use it as a shortcut for a full KYB conclusion. A defensible KYB process still needs to establish the legal entity, understand the relevant ownership/control information, check the appropriate parties, record source limitations and preserve the decision.

What the LEI is good at

GLEIF describes the LEI as an identifier that connects to key reference information about legal entities. In practice, an LEI can help a system answer basic but important questions:

• Are we referring to the same legal entity across two data sources?
• What is the entity’s registered legal name and jurisdiction?
• Is the record active, lapsed or otherwise subject to a registration status?
• Is there relationship data that can help navigate a corporate structure?

The value is not merely the 20-character code. The value is the reduction of ambiguity. “Acme Holdings Ltd” is a fragile identity in a global dataset. A verified identifier gives the analyst and the API a much firmer point of reference.

Where the shortcut breaks

An identifier does not establish the relationship

Suppose a supplier gives you its LEI. You may now be more confident which company it says it is. You have not yet established that the person signing your contract is authorised to represent it, that the bank account belongs to it, that the commercial purpose makes sense, or that its ownership/control picture is appropriate for your risk policy.

Ownership data may be valuable and still incomplete

Corporate relationship data is useful because it makes ownership analysis more structured. But any dataset can have coverage limitations, reporting exceptions, update delays and jurisdictional differences. A KYB system should show these limitations, not turn a missing parent or child relationship into a confident “no ownership risk” conclusion.

This is particularly important where a company has complex cross-border holdings, nominee arrangements, state connections, funds, trusts or a control relationship that is not obvious from percentage ownership alone.

KYB is a decision, not a database lookup

The right question is not “did the API return a company?” It is “do we have enough reliable, relevant and current evidence to enter this particular relationship?” The answer depends on value, geography, sector, product, customer type, payment flow and regulatory obligations.

A low-risk software subscription and a high-value cross-border distribution agreement should not have identical evidence thresholds.

A better way to use LEI in a KYB workflow

This table makes an important product point: the strongest entity data does not remove the need for analyst judgment. It makes that judgment more grounded and more repeatable.

The evidence standard for a real KYB report

A strong KYB dossier should not imply that every field has the same evidential weight. It should distinguish:

1. Registry-backed fact: a legal name, registration number or official filing retrieved from a named source at a recorded time.
2. Relationship data: parent/child or ownership information, with its source and any exception/coverage note.
3. Customer-provided assertion: information supplied by the prospective customer but not independently confirmed.
4. Analyst conclusion: a risk decision based on the facts above, including known limitations.

That distinction is the difference between a polished PDF and a reviewable decision record. It also prevents a company from accidentally presenting a data provider’s partial record as a verified UBO conclusion.

Where Verifex fits

Verifex can use entity and source-backed context to help teams move from a company name toward a reviewable KYB workflow. The promise should remain precise: the platform can preserve the source, retrieval time, evidence excerpt, analyst review status and limitations for each key claim. Teams should validate the live data availability, jurisdictional scope and current source status for their own workflow before relying on it.

An LEI should make the question “which company?” easier. Verifex’s job is to make the later question “why did we accept this relationship?” answerable.

Sources

• GLEIF: the Legal Entity Identifier
• GLEIF: Level 2 relationship data, “who owns whom”
• FATF: beneficial ownership of legal persons
• Verifex: KYB & UBO