None of the addresses match the form exactly. Now what?
This is the part of KYC nobody writes about. Before any screening happens, before anyone looks at risk, somebody has to work out which company this actually is. That question eats hours, and it is the question a Legal Entity Identifier answers.
An LEI code is a 20-character code assigned to one legal entity and no other. Each entity gets one, it never changes, and the record behind it is public. When the counterparty has one, the analyst above stops guessing between four Sterling Capitals and looks up a single record.
What it does not do is equally important, and we will get to that.
If you are new to the identifier itself, start with our guide to what a Legal Entity Identifier is.
Why Identifying the Entity Takes So Long
The problem is not that teams are slow. It is that most firms store the same company under several different references.
GLEIF's research findings, published in May 2018 and undertaken with research agency Loudhouse, surveyed 102 senior salespeople in banking across the UK, US and Germany. It found that financial institutions use an average of four identifiers to identify and cross-check new legal entities, and that onboarding a client, including due diligence, takes six weeks on average. 57% of those surveyed said they spend more than 1.5 days a week on onboarding work - 27% of their working week.
Think about what four identifiers means in practice. The core banking system has one. The trade capture system has another. The screening tool has a third. The credit file has a fourth. Nothing links them, so when someone needs a full picture of that client, they match on the company name - and the name is written slightly differently in each system.
"Acme Holdings Inc." "ACME HOLDINGS, INC." "Acme Hldgs Inc". Three systems, three spellings, one company, and a person paid to work out that they are the same.
A Legal Entity Identifier cuts that work down, provided it is captured consistently across your systems. It is the same 20 characters everywhere, so the match is exact instead of approximate. It does not make screening itself any faster - what it reduces is the entity-resolution work that comes before screening.
What Is an LEI Code Used For During KYC Checks?
It answers one question: which legal entity is this?
The code points to a public record holding the entity's legal name, its registered address, the country it was formed in, its registration status, and when the data was last checked. Before the code is issued, that reference data is validated against authoritative sources available for the entity's jurisdiction - usually the official business registry, though what counts as authoritative varies by country.
So when a counterparty gives you their LEI, you are not taking their word for the legal name. You are reading a record an accredited issuer has already checked.
That is the whole contribution. Useful, but narrow.
Where LEI Code Verification Fits in the Workflow
Two moments.
At onboarding. Ask for the LEI code with the other entity details. Look it up. Check the legal name and address on the record against what the client wrote on the form. Mismatches here are worth a question - sometimes it is a typo, sometimes the client has given you the parent company instead of the entity actually opening the account.
At periodic review. Check the record again. Is it still active? Has the legal name changed? Has the registered address moved? A lapsed record is not a red flag by itself, but it tells you the data has not been revalidated in over a year, so it is worth a fresh look.
Most of the value comes from doing both. Checking once at onboarding and never again gives you a snapshot that quietly goes stale.
What an LEI Code Does Not Do
This is where firms get into trouble, usually by assuming the identifier carries more information than it does.
It is not a sanctions check. An LEI code is not a sanctions list. It carries no risk flag. A company on the OFAC SDN list can hold a perfectly valid, active LEI - the two systems have nothing to do with each other. If an analyst ever treats a valid LEI as a reason to skip screening, that is a serious control failure.
What it does help with is screening quality. Screening "Sterling Capital Partners" as a text string returns matches for every company with a similar name. Screening a specific, identified entity returns fewer false positives, so the review queue is shorter and cleaner.
It does not confirm who owns the company. More on this below, because the confusion here is common.
It does not say the entity is safe. Any entity can get an LEI. There is no vetting of the business, only verification of the identity. A valid code means "this company exists and is who it says it is" - not "this company is low risk."
It does not complete your CIP or CDD file. An LEI does not replace the information and verification steps required under your applicable Customer Identification Program procedures. It sits alongside them as an extra reference point.
Does an LEI Show Who Owns a Company?
Partly, and the limits matter.
LEI data comes in two layers. Level 1 is the entity itself - name, address, status. Level 2 records parent companies.
Here is the catch. Level 2 records the entity's accounting consolidating parents - the companies that consolidate this entity into their financial statements. There are two: the direct one (closest) and the ultimate one (furthest up).
Accounting consolidation is not the same as ownership. A person can own and control a company without consolidating it into any financial statement, in which case Level 2 shows nothing about them. Where no parent is reported, the record gives a documented reason rather than naming an owner.
So Level 2 will tell you that Entity A rolls up into Group B. It will not tell you that an individual sits behind Group B. It is not a beneficial ownership register, and it should never be shown to a reviewer as an ownership map.
Used properly it is a starting point for ownership work, not a substitute for it. The technical detail is published as GLEIF Level 2 relationship data.
One 2026 Change U.S. Teams Should Know About
If you apply the Customer Due Diligence Rule, something shifted this year.
On 13 February 2026, FinCEN issued an exceptive relief order (FIN-2026-R001) removing the requirement for covered financial institutions to identify and verify beneficial owners of legal entity customers at each new account opening. Previously, a customer opening their fifth account triggered the same full beneficial ownership collection as their first.
Under the order, that work is required in three situations:
- when a legal entity customer first opens an account with the institution
- when the institution knows facts that would reasonably call into question the reliability of beneficial ownership information it previously obtained
- where its own risk-based procedures for ongoing customer due diligence determine it is necessary
"Covered financial institution" is defined at 31 CFR 1010.230(f), which takes in banks and credit unions, brokers and dealers in securities, mutual funds, and futures commission merchants and introducing brokers in commodities.
The CDD Rule itself has not gone anywhere. Institutions must continue to comply with all other AML/CFT requirements under the Bank Secrecy Act, including program, recordkeeping and reporting obligations. The order also states plainly that taking up the relief is at each institution's discretion - you can keep your existing practice.
There is a connection to identity work here. If you are relying on beneficial ownership information collected two years ago, you need to be confident you are looking at the same legal entity you collected it from. That is what a persistent identifier is for. The order is published in full as FinCEN Order FIN-2026-R001, and general guidance sits in FinCEN's CDD Rule FAQs.
Where It Actually Helps
| Situation | What the LEI does |
|---|---|
| Four similarly named companies in your search results | Narrows it to one verified record |
| Client's legal name written three ways across your systems | Gives every system the same 20-character key |
| Periodic review of a corporate client | Shows whether the reference data is still current |
| Screening returning too many false positives | Cleaner input, fewer ambiguous matches to clear |
| Building a picture of a group structure | Shows accounting consolidating parents as one input |
You can verify an LEI code free of charge at any point. If your work is bank-focused, our page on LEI in banking goes further into that setting.
What About a Lapsed LEI Code?
A lapsed LEI code still identifies the entity. The 20 characters stay assigned, and the company has not changed. What lapsed means is that nobody has revalidated the reference data within the renewal period, so the name and address on the record might now be out of date.
Whether you accept one is your call - there is no rule either way. A practical approach is to treat lapsed status as a prompt for fresh source verification rather than as an automatic failure.
The useful thing is to decide in advance and write it into procedure, so two reviewers looking at the same lapsed record reach the same conclusion. For when an LEI number is required in the first place, see our U.S. LEI regulatory requirements hub.
A Practical Way to Start
If you want the benefit without a project, do this once.
Take your existing corporate customer file. Match it against published LEI records in bulk - the data is open, so this is a data exercise, not a licensing one. Store the LEI against each entity that has one. From then on, use it as the key whenever you move that customer between systems.
The payoff builds up. Every review, every system migration, every reconciliation with a counterparty from that point runs on a value that does not change, instead of a name that does.
You can verify an LEI code to begin.