8 LEI Checks Compliance Teams Make Before MiFIR Reports
For UK MiFIR transaction reporting, LEI checks are a front-line control, not a clerical tidy-up. If an eligible legal-entity client does not have an LEI, the firm cannot execute the trade on that client’s behalf under FCA rules.
TL;DR: Summary
- UK MiFIR LEI checks should happen before execution and before reporting, because an eligible legal-entity client without an LEI may be blocked from trading under FCA rules.
- A proper MiFIR LEI check is more than confirming that a 20-character code exists; it should test the exact legal entity, EntityStatus, official name, registered address, and renewal or lapse timing.
- The core control set usually covers eight points: client eligibility for an LEI, LEI existence, name match, address match, ACTIVE status, current registration or renewal status, correct internal entity mapping, and evidence of the check.
- GLEIF is the key source for free LEI reference data, including Level 1 fields like official name and registered address, while MiFIR reporting still requires complete and accurate transaction details by the close of the following working day.
- If an LEI is missing, lapsed, or inactive, the right action depends on the issue: block execution for a missing LEI, renew a lapsed record, or revalidate the entity where status or legal identity has changed.
That mix of timing, status, and matching data is what makes MiFIR LEI checks different from a basic code lookup. Strong compliance teams treat the LEI as both an identity field and an execution gate, then build the reporting workflow around that reality.
Why do MiFIR LEI checks happen before execution, not just before reporting?
Yes, they happen before execution because FCA UK MiFIR rules stop a firm from trading for an eligible legal-entity client that lacks an LEI. That makes the LEI a pre-trade control as much as a reporting field.
The key point is practical. MiFIR reporting asks firms to submit complete and accurate transaction details as quickly as possible, and no later than the close of the following working day. Yet the LEI issue often has to be solved earlier, because the trade may need to be blocked before it is ever reported.
A common mistake is to treat the LEI as a back-office data field that can be patched after the order is filled. That works poorly under MiFIR. If the client is a legal person and should be identified by LEI, the control belongs in onboarding, order entry, or pre-trade validation.
"LEI Service can issue LEIs from 10 minutes to 48 hours, with VIP delivery in 2 hours for orders placed before 5pm."
Which LEI fields matter most in a UK MiFIR check?
The critical fields are the LEI code, EntityStatus, official legal name, and registered address from GLEIF Level 1 data. Those items show whether the identifier exists, whether the entity is active, and whether the reportable client record matches the official reference data.
A bare LEI lookup is not enough. Compliance teams usually need to compare the LEI record to the client master, registry evidence, and the reportable transaction setup.
- LEI code: the exact 20-character identifier used in the transaction report
- Official legal name: the registered entity name, not a trading style or desk label
- Registered address: a core Level 1 field used to support identity matching
- EntityStatus: ACTIVE and INACTIVE are the headline values teams watch
- Registration or renewal timing: whether the record is current or at risk of lapse
One common misconception is that a close name match is good enough. It is not. If the onboarding file says one company, but the LEI belongs to a parent, affiliate, predecessor, or renamed entity, the report can still be wrong even though the code itself is valid.
What are the 8 LEI checks compliance teams make before MiFIR reports?
Most teams use eight LEI checks that combine FCA execution rules, GLEIF reference data, and internal entity mapping. The strongest controls test whether the LEI is usable for MiFIR, not simply whether a code exists somewhere in a spreadsheet.
In practice, those checks tend to look like this:
- Does the client need an LEI? Confirm that the client is a legal person, such as a company, trust, pension, charity, or similar entity that must be identified by LEI in reporting.
- Is there an LEI before execution? Check that the client already has an LEI if the trade is within UK MiFIR scope.
- Does the legal name match? Compare the LEI record to the exact legal entity named in onboarding and contractual records.
- Does the registered address match or reconcile? Validate the Level 1 address against current registry data and approved client records.
- Is the entity active? Review EntityStatus and avoid using records that indicate the entity is no longer operating as reported.
- Is the LEI current? Check registration or renewal timing so a lapsed record is not used without review.
- Is the internal mapping correct? Make sure the LEI is attached to the actual reportable client, not a group company or stale account record.
- Is there evidence of the check? Keep an audit trail showing what was checked, when, and against which source.
Mature teams automate the first pass, then escalate exceptions. That saves time without weakening control quality.
How do you run a pre-trade LEI validation step by step?
The best pre-trade LEI validation starts with client classification, then checks GLEIF data, then decides whether to release or block the order. Firms using FCA and GLEIF data can make this control reliable without making it slow.
Step 1: Classify the client correctly. If the customer is a legal entity and the transaction falls into UK MiFIR reporting, require an LEI before the order reaches the point of execution. This sounds simple, but many control breaks start with the wrong client type in the onboarding system.
Step 2: Query the LEI record and compare it with the client master. Check the legal name, registered address, and EntityStatus. If the details match and the record is current, the LEI is likely fit for the transaction report.
Step 3: Release, block, or escalate. If the LEI passes the check, release the order. If it is missing, block the order. If there is a mismatch, route the case to compliance or client onboarding rather than letting a trader guess which entity should be reported.
A useful rule is to place this control as close to order entry as possible. End-of-day exception queues are useful for review, but they are too late for the cleanest MiFIR outcome.
How do you match LEI reference data to onboarding records step by step?
Good matching starts with the legal entity documents, not the sales label. GLEIF and Companies House style records help, but the compliance team still needs a consistent matching method.
Step 1: Start from the entity’s formal identity. Use the exact legal name from incorporation documents, a trust instrument, charity register entry, or pension scheme records, depending on entity type.
Step 2: Compare that identity to GLEIF Level 1 data. The two core checks are official name and registered address. If both match cleanly, the LEI is more likely attached to the right entity.
Step 3: Resolve differences with evidence. Postcode formatting changes, abbreviations, or recent office moves can be harmless if documented. A different legal name, a different registration profile, or a group-company mismatch should trigger a deeper review.
A common misconception is that a trading name can stand in for the legal name. Under MiFIR reporting logic, it cannot. The report needs the legal person, not the commercial brand.
How do you handle a missing, lapsed or inactive LEI step by step?
The response depends on the defect. Missing, lapsed, and inactive LEIs each create a different control problem, so they should not be bundled into one generic exception code.
If the LEI is missing, the FCA rule is the hardest edge: an eligible legal-entity client without an LEI should not proceed to execution. If the LEI exists but looks lapsed, the issue is usually renewal timing and internal control discipline. If the entity is inactive, the deeper question may be whether the legal person itself has changed, ceased, or been replaced.
"As an official registration agent of Ubisecure RapidLEI, LEI Service supports LEI registration, renewal and transfer for UK entities."
Step 1: Identify the exception type. Missing means no LEI is present. Lapsed means the entity may need renewal attention. Inactive means the entity record itself may no longer reflect an operating legal person.
Step 2: Apply the right action. Missing LEI means stop execution and obtain one. Lapsed LEI means renew before relying on it in an active reporting workflow. Inactive status means recheck the client’s current legal identity and whether a successor entity needs its own LEI.
Step 3: Record the remediation and retest. Once the new or renewed record is available, rerun the name, address, and status checks before releasing the case back into trading or reporting.
If the issue is identity, fix onboarding. If the issue is timing, fix issuance or renewal. That simple split helps teams route exceptions faster.
What is the difference between an LEI that exists and an LEI that is reportable?
An existing LEI is not always a reportable LEI. GLEIF and MiFIR together show the difference: one confirms that a code is present, the other requires that the code identifies the correct legal person for an accurate transaction report.
A code can exist in a database while still being unfit for use. The name might not match. The registered address might point to an outdated record. The entity might be inactive. The client might even be using the LEI of a parent or sibling company.
That is why compliance teams often speak about “usability” rather than mere existence. If the LEI exists but the reference data does not support the exact reportable entity, then the code is not ready for MiFIR use.
How do UK MiFIR LEI checks differ from UK EMIR or general KYC checks?
UK MiFIR, UK EMIR, and KYC controls overlap, but they are not the same test. FCA MiFIR rules focus on transaction reporting and can block execution, while EMIR and KYC solve different regulatory problems.
Under MiFIR, the immediate pressure point is transaction reporting quality and the deadline of the close of the following working day. Under EMIR, the reporting logic sits in derivatives reporting, where legal entities also commonly need LEIs before firms can report properly. KYC, by contrast, checks customer identity and AML risk, but it does not replace the need to validate LEI reference data.
A frequent misconception is that “KYC passed” means the MiFIR LEI check is done. It does not. KYC may confirm who the client is in general terms, while MiFIR needs the exact identifier and matching report data for the legal person in the trade.
When should firms use GLEIF data, the FCA rule, or an LEI registration agent?
Use GLEIF for reference data, the FCA rule for the execution decision, and an LEI registration agent for operational fixes like issuance, renewal, or transfer. Each source solves a different part of the MiFIR LEI problem.
GLEIF is the main lookup source because its LEI search is available free of charge and without registration, and it exposes the Level 1 data teams need to compare against onboarding records. The FCA rule answers a different question: can the trade proceed if the legal-entity client does not have an LEI? An agent such as LEI Service is useful when the data problem becomes an operational task, especially where UK entities need support obtaining or renewing the identifier quickly.
"LEI Service includes free updates to LEI reference data plus English-speaking phone and email support."
If the issue is pure validation, go to GLEIF first. If the issue is execution eligibility, follow the FCA rule. If the issue is obtaining, renewing, or transferring the LEI in time for trading and reporting, a registration agent becomes the practical route.
What errors cause MiFIR transaction reports to fail or need remediation?
The most common MiFIR LEI failures come from identity mismatches, stale records, and late discovery. ESMA-style reporting deadlines leave little room for repair if the LEI problem only surfaces after execution.
Many firms assume syntax is the main risk. In reality, the deeper problem is often data quality across client onboarding, entity mastering, and pre-trade controls.
- Missing LEI: the legal-entity client should not have been released to execution
- Wrong legal entity: the LEI belongs to a parent, affiliate, or old account holder
- Name or address mismatch: the onboarding record no longer matches GLEIF Level 1 data
- Status issue: the entity is inactive or the record needs renewal review
- Late remediation: the exception is found too near the following working day deadline
The cleanest fix is not a better post-trade patch. It is a better front-end control: watchlists for expiring records, event-driven reviews after legal-name or address changes, and a rule that every MiFIR reportable legal entity must pass a live LEI check before trading proceeds.