Reader question: A Legal Entity Identifier is only 20 characters long, yet banks and market infrastructures rely on it to identify organizations across transactions and reference data. How can software catch typing errors quickly — and what does a valid LEI checksum actually prove?
The LEI uses a two-layer idea. First, the 20-character identifier has a standard structure under ISO 17442. Second, the last two characters are check digits using the ISO/IEC 7064 MOD 97-10 scheme. Software expands letters into decimal values, computes a modulus-97 remainder and verifies the check condition. This catches many accidental transcription errors without an online lookup.
But checksum validity is only syntactic evidence. A well-formed LEI can be lapsed, retired, annulled, associated with stale reference data, or even fabricated mathematically without ever having been issued. Authoritative semantic validation therefore requires the Global LEI Index or equivalent GLEIF-sourced data.
What this page owns — and what it does not
This page owns:
candidate LEI → structural validation → letter expansion → MOD 97-10 check → checksum result → optional lifecycle/reference-data validation.
It does not replace ISIN check-digit validation, which identifies financial instruments; IBAN validation, which validates bank-account identifiers; or ISO 20022 message validation.
This is identifier and data-quality mathematics, not a legal-entity due-diligence opinion and not financial advice.
The LEI is 20 characters, but the jobs inside it are different
Under the Global LEI System, an LEI is a 20-character alphanumeric code.
A common structural description is:
- characters 1–4: allocation prefix associated historically with the issuing Local Operating Unit;
- characters 5–18: entity-specific alphanumeric portion under the allocation framework;
- characters 19–20: two numeric check digits.
Legacy explanatory material often describes positions 5–6 as reserved zeroes. A robust modern validator should be careful about over-enforcing historical allocation conventions against the full real-world LEI population. The checksum and current authoritative GLEIF record are stronger validation evidence than assumptions about legacy issuance patterns.
Step 1: normalize narrowly
An LEI is an identifier, not prose. A safe input policy should be explicit:
- accept exactly 20 characters after permitted presentation cleanup;
- convert lowercase ASCII letters to uppercase only if the interface contract allows it;
- reject punctuation and Unicode look-alikes rather than guessing;
- preserve every zero and every character position.
Over-normalisation can turn malformed input into a different valid-looking identifier. The system should not silently remove arbitrary characters until a checksum happens to pass.
Step 2: separate structure from checksum
Before arithmetic, test:
- length = 20;
- allowed characters = A–Z and 0–9 under the applicable format rules;
- last two characters are decimal digits;
- no forbidden whitespace or punctuation remains.
If structure fails, do not report “bad checksum.” That diagnostic would be misleading because the arithmetic stage should never have been reached.
Step 3: expand letters into decimal digits
MOD 97-10 calculations operate on decimal digits. Letters are converted using:
A = 10, B = 11, …, Z = 35.
Digits remain unchanged.
For example:
L → 21
E → 14
I → 18
Because letters expand to two decimal digits, the arithmetic sequence is longer than 20 digits.
Step 4: validate with MOD 97-10
The central invariant is:
expanded LEI number mod 97 = 1.
That is the same core modulus family used by IBAN, although the identifier structure and generation rules are different.
A validator does not need arbitrary-precision integer conversion. It can compute the remainder incrementally from left to right.
Streaming remainder algorithm
Let r be the current remainder, initially zero.
For each decimal digit d in the expanded LEI:
r ← (10r + d) mod 97.
After the final digit:
valid if r = 1.
This algorithm is mathematically equivalent to dividing the entire long decimal integer by 97, but it never creates the entire huge number.
Why streaming arithmetic is safer
Programming languages differ in how they handle very large integers. Some silently convert large numbers into floating-point representations that cannot preserve every decimal digit exactly.
The streaming method uses only small integer remainders below 97, making it deterministic and portable.
It also provides an easy invariant for testing: at every step, 0 ≤ r < 97.
Generating the two check digits
For generation, the system starts from the first 18 characters and calculates the two final digits according to the ISO/IEC 7064 MOD 97-10 construction.
A practical implementation can:
- take the 18-character base;
- append temporary zeroes for the check-digit positions under the generation convention;
- expand letters;
- compute the modulus;
- derive the two-digit value needed so the completed LEI produces remainder 1.
Because the check digits range from 00 to 99, a test implementation can also brute-force all 100 candidates and select the unique pair that satisfies the validation invariant. This is slower than the direct formula but trivial at this scale and useful for verifying parity or derivation logic independently.
Checksum validity is not issuance validity
Anyone who knows the public checksum rule can create an 18-character base and calculate mathematically valid check digits.
Therefore a passing MOD 97-10 check does not prove:
- GLEIF or an accredited issuer ever issued the LEI;
- the legal entity still exists;
- the LEI registration is current;
- the associated name and address are current;
- the entity is the intended transaction counterparty;
- parent relationships are complete.
The checksum answers a narrower question: is the string internally consistent with the check-digit rule?
Step 5: look up the authoritative record
GLEIF publishes the Global LEI Index, downloadable concatenated files, Golden Copy files and APIs.
A semantic validation layer can therefore perform:
checksum-valid LEI → GLEIF record → entity status + registration status + reference data + relationships.
The online lookup should be reported separately from checksum validation. A temporary API outage should not cause software to claim that a mathematically valid LEI has an invalid checksum.
Entity status and registration status are different
An LEI record carries lifecycle information beyond the code itself.
An entity can be active or inactive, while the LEI registration can have statuses such as issued/current, lapsed, retired or annulled under the applicable data model.
A valid checksum therefore remains valid even after the registration status changes.
That is another reason the checksum should never be overloaded into a “counterparty is active” decision.
Level 1 data: “who is who”
GLEIF describes Level 1 LEI reference data as the business-card layer answering who is who.
It includes fields such as:
- official legal name;
- registered and headquarters addresses;
- registration authority and entity identifiers;
- entity legal form and jurisdiction-related fields;
- record timestamps and lifecycle information.
A checksum cannot validate any of these facts.
Level 2 data: “who owns whom”
GLEIF’s Level 2 framework captures direct and ultimate accounting-consolidating parent relationships where reported, plus structured exceptions when parent information is not available or is not reportable under the rules.
This creates a separate graph layer:
entity identity ≠ ownership relationship.
One LEI validates one legal-entity identifier. It does not encode the corporate group directly inside the 20 characters.
The prefix does not necessarily identify the current managing LOU
The first four characters reflect allocation history, but an LEI can be transferred between Local Operating Units for maintenance.
Therefore a system should not infer “current managing issuer” solely from the prefix.
The authoritative record contains the current managing LOU information.
Policy Conformity Flag is another separate signal
GLEIF has introduced a Policy Conformity Flag to help data users see whether an LEI record meets specified policy expectations such as timely renewal and Level 2 reporting completeness.
This flag is not the checksum and is not itself identical to GLEIF’s data-quality checks.
A robust data model keeps these dimensions separate:
- syntax;
- checksum;
- record existence;
- registration lifecycle;
- entity lifecycle;
- policy conformity;
- reference-data quality.
LEI, ISIN and IBAN solve different identity problems
LEI: identifies a legal entity.
ISIN: identifies a financial instrument.
IBAN: identifies a bank account under participating national formats.
These identifiers can appear in the same financial workflow but should never be substituted for one another.
GLEIF also publishes mapping datasets that link LEIs with other identifier systems such as ISINs where relationships are available.
Inputs and outputs
An LEI validation engine can require:
- candidate LEI string;
- normalisation policy;
- ISO 17442 structural rules;
- A=10…Z=35 expansion;
- MOD 97-10 implementation;
- optional GLEIF API or Golden Copy data;
- reference-data retrieval timestamp;
- required lifecycle/policy checks for the use case.
Outputs can include:
- normalized LEI;
- structure-valid flag;
- checksum-valid flag;
- remainder value;
- GLEIF record-found flag;
- entity status;
- registration status;
- managing LOU;
- policy-conformity result;
- reference-data freshness timestamp;
- diagnostic failure reason.
Evidence polarity: what supports confidence?
Evidence for confidence includes known GLEIF-issued LEIs passing the checksum, single-character mutations failing, generation/validation round trips, streaming and big-integer implementations agreeing, authoritative GLEIF lookup confirming existence, and lifecycle fields being reported separately from checksum status.
Evidence against confidence includes lowercasing or Unicode substitutions changing results unpredictably, a checksum-valid fabricated identifier being reported as “verified entity,” a lapsed LEI being rejected as a mathematical checksum failure, or a prefix being treated as proof of the current managing LOU.
Counterexample: valid checksum, no authoritative record
A fabricated LEI can satisfy MOD 97-10 if the final digits are calculated correctly.
If the Global LEI Index has no corresponding record, the code is mathematically well-formed but not proven issued.
Counterexample: valid checksum, lapsed registration
An entity can have a real LEI whose registration is no longer current. The 20-character code does not change merely because annual renewal was missed.
The checksum remains valid while the registration-status control raises a separate issue.
Counterexample: valid LEI, wrong counterparty
A user can paste another company’s perfectly valid LEI.
Checksum and authoritative lookup both succeed, but the transaction party is still wrong relative to the business intent.
Semantic identity matching requires comparing entity name, registry data, relationship context or other authoritative evidence.
Counterexample: current managing LOU differs from allocation prefix
If an LEI has been transferred for maintenance, relying only on the first four characters can misidentify the current service provider.
The current GLEIF record is the correct source.
Weak links in implementation
Float conversion. Expanded digits are converted into an imprecise floating-point number.
Letter mapping bug. A=1 is used instead of A=10.
Unicode ambiguity. Look-alike characters enter the string.
Over-normalisation. Punctuation or internal spaces are silently deleted.
Lifecycle collapse. CHECKSUM_VALID is treated as ENTITY_ACTIVE.
Prefix overreach. Allocation prefix is treated as current managing LOU.
Stale GLEIF data. Local reference data are not refreshed after mergers, retirements or updates.
relationship omission. Level 1 identity is mistaken for complete group ownership data.
Diagnostics: how to test the engine
- known-valid test: validate LEIs sampled from GLEIF Golden Copy data.
- single-character mutation: alter one digit or letter and require checksum failure in ordinary cases.
- round-trip generation: generate check digits from an 18-character base and revalidate.
- streaming-versus-bigint test: compare independent implementations.
- fabricated-valid test: generate a mathematically valid code absent from GLEIF and require “checksum valid / record not found.”
- lapsed-status test: use a real lapsed LEI and require checksum success with lifecycle warning.
- transfer test: verify current managing LOU from record data rather than prefix assumptions.
- reference freshness test: compare local cache timestamps with current GLEIF data.
- Unicode test: reject look-alike non-ASCII characters.
- relationship test: keep Level 2 parent data separate from Level 1 identifier validation.
What would falsify confidence?
Confidence should be withdrawn if known GLEIF LEIs fail checksum validation; if streaming and independent implementations disagree; if mathematically fabricated LEIs are reported as issued entities; if lifecycle changes alter the checksum result; or if current managing-LOU information cannot be reconciled to authoritative GLEIF data.
Alternatives and limits
For online workflows, direct GLEIF lookup can validate existence and retrieve lifecycle data without requiring the application to rely on checksum logic alone. Local checksum validation remains useful as an immediate input-quality gate and offline control.
The verifiable LEI (vLEI) solves a different problem by placing organizational identity and authority into cryptographically verifiable credentials. A checksum cannot provide that level of authentication.
How this connects to the surrounding knowledge estate
The ISIN algorithm identifies instruments. The IBAN algorithm identifies accounts and uses the same broad MOD 97-10 family with different structure. ISO 20022 validation can carry identifiers inside structured financial messages. LEI validation adds the party-identity layer without replacing those other identifiers.
Verification and update triggers
Preserve the ISO 17442 version, checksum algorithm, normalisation rules, GLEIF data schema, API/file version, lifecycle mappings and policy-conformity interpretation. Revalidate after ISO 17442 revisions, GLEIF Common Data File changes, new lifecycle states, changes to Policy Conformity rules or incidents involving mismatched counterparties or stale legal-entity reference data.
Primary and high-quality references
- Global Legal Entity Identifier Foundation, Introducing the Legal Entity Identifier.
- GLEIF, LEI Data: Access & Use, describing the Global LEI Index, Level 1/Level 2 data, files and API.
- GLEIF, Data Quality Checks.
- GLEIF, Policy Conformity Flag.
- ISO, ISO 17442-1 — Financial services — Legal entity identifier (LEI), with check digits based on the ISO/IEC 7064 MOD 97-10 framework.
Educational boundary: This article explains LEI syntax, checksum and lifecycle validation. It does not establish legal identity for a transaction, replace due diligence or provide financial advice.