Watching brief — not a build task. OpenCheck is LEI-anchored, which caps every lookup at the ~3.3M entities that hold an LEI. OpenCorporates' proto-LEI (pLEI) is an attempt to break that ceiling: a free, ISO 17442-shaped identifier for all legal entities, published in GLEIF's LEI-CDF format, launching with US entities and expanding through 2026 across the 200M+ entities / 140+ jurisdictions OpenCorporates already aggregates.
If it matures, it is directly relevant to us — but the alpha is not yet usable, and this issue records why, so we monitor rather than build.
What I examined (2026-07-14)
Downloaded the full alpha sample: https://p-lei.com/samples/plei.xml.gz (118 MB gz → 3.0 GB XML), plus the sample README. Scope per README: v0.2 alpha, California + Florida, entities beginning with "A". Header declares 1,550,046 records (the README says "approximately 1.2 million" — first minor discrepancy).
Does it follow the CDF format as advertised?
Structurally yes; validly no — it would fail XSD validation.
Correct: GLEIF's real namespaces (leidata/2016 + golden-copy extensions), the LEIHeader / LEIRecords / LEIRecord skeleton, GLEIF RA codes (e.g. RA000603), ISO 20275 ELF codes (e.g. TRI2), and GLEIF's controlled vocabularies (RegistrationStatus: ISSUED, ValidationSources: FULLY_CORROBORATED, EntityCategory: GENERAL). A GLEIF ingest pipeline would recognise it immediately.
Three conformance failures:
1. 87.4% of identifiers are malformed (the big one). ISO 17442 mandates exactly 20 characters; CDF enforces [0-9A-Z]{18}[0-9]{2}.
| identifier shape |
count |
ISO 7064 MOD 97-10 |
OC00… 21 chars |
1,355,327 |
✗ all fail |
OC00… 20 chars |
193,116 |
✓ all pass |
| real GLEIF LEIs |
1,603 |
✓ all pass |
The 21-char ones carry a 13-character Crockford Base32 body where their own README specifies 12 (OC00 + 00 + 12 + 2 check digits = 20). It's an off-by-one in the generator, not a design choice. Verified my checksum implementation against known-good LEIs first (Shell 21380068P1DRHMJ8KU70, BP, Rosneft, and OpenCorporates' own 254900QNTKOM4TQJUM96) — all pass, so the failure is in the data, not the test.
2. 89% of country fields are empty. <lei:Country/> appears 2,770,320 times vs 329,772 populated (2 per record: LegalAddress + HeadquartersAddress). CDF requires ISO 3166-1 alpha-2. Odd, because the jurisdiction is present via LegalJurisdiction (US-FL, US-CA) and Region — Country: US simply isn't backfilled. Most LegalAddress blocks are entirely empty.
3. LastUpdateDate is not a valid xs:dateTime — 2026-03-02 00:00:00 (space instead of T, no timezone). Other date fields are correct (2007-04-17T00:00:00Z), so this is an isolated serialisation bug.
Are pLEIs in the sample, and what fields come with them?
Yes — and notably, real GLEIF LEIs are mixed into the same file (1,603 of them), which is the "bridge" proposition made concrete: a pLEI and an LEI coexist in one namespace.
Per entity: LegalName, HeadquartersAddress (often partial), RegistrationAuthorityID + RegistrationAuthorityEntityID (the native register ID — this is the bridge key we'd actually use), LegalJurisdiction, EntityCategory, ISO 20275 EntityLegalFormCode, EntityStatus, EntityCreationDate, and a Registration block (InitialRegistrationDate, LastUpdateDate, RegistrationStatus, NextRenewalDate, ManagingLOU, ValidationSources). One custom element: <oc:PLEI> in the Extension, which merely duplicates <lei:LEI>.
Caveat: 67% of the sample is INACTIVE (1,032,417 of 1,550,046) — dissolved entities included.
Level 1 only — no relationships (confirmed empirically)
Grepped for every L2 construct — RelationshipRecord, RelationshipData, Relationship, RelationshipType, ReportingException — zero occurrences. This is Level 1 identity/address data; there is no RR-CDF file.
This matters for us specifically. GLEIF's value to OpenCheck isn't only the LEI — it's the Level 2 relationship graph that seeds the ownership network (map_gleif_subsidiaries, the direct-children fan-out). A pLEI would give reach (more entities identifiable) but not structure. And since OpenCheck already consumes OpenCorporates for relationships, today's marginal gain is the identifier alone, not new edges.
Why it's still strategically interesting
The national-ID search (Phase 46) exists precisely because users arrive with a company number, not an LEI — and today we can only proceed if GLEIF happens to know that company. A conformant pLEI would let any company number become a valid entry point. And because it's CDF-shaped, map_gleif() and the GLEIF→BODS mapping would largely work as-is.
What to watch for (revisit triggers)
Actions
Background: OpenCorporates' 10-part series, Fundamentals of legal entity identity data.
Watching brief — not a build task. OpenCheck is LEI-anchored, which caps every lookup at the ~3.3M entities that hold an LEI. OpenCorporates' proto-LEI (pLEI) is an attempt to break that ceiling: a free, ISO 17442-shaped identifier for all legal entities, published in GLEIF's LEI-CDF format, launching with US entities and expanding through 2026 across the 200M+ entities / 140+ jurisdictions OpenCorporates already aggregates.
If it matures, it is directly relevant to us — but the alpha is not yet usable, and this issue records why, so we monitor rather than build.
What I examined (2026-07-14)
Downloaded the full alpha sample:
https://p-lei.com/samples/plei.xml.gz(118 MB gz → 3.0 GB XML), plus the sample README. Scope per README: v0.2 alpha, California + Florida, entities beginning with "A". Header declares 1,550,046 records (the README says "approximately 1.2 million" — first minor discrepancy).Does it follow the CDF format as advertised?
Structurally yes; validly no — it would fail XSD validation.
Correct: GLEIF's real namespaces (
leidata/2016+ golden-copy extensions), theLEIHeader/LEIRecords/LEIRecordskeleton, GLEIF RA codes (e.g.RA000603), ISO 20275 ELF codes (e.g.TRI2), and GLEIF's controlled vocabularies (RegistrationStatus: ISSUED,ValidationSources: FULLY_CORROBORATED,EntityCategory: GENERAL). A GLEIF ingest pipeline would recognise it immediately.Three conformance failures:
1. 87.4% of identifiers are malformed (the big one). ISO 17442 mandates exactly 20 characters; CDF enforces
[0-9A-Z]{18}[0-9]{2}.OC00…21 charsOC00…20 charsThe 21-char ones carry a 13-character Crockford Base32 body where their own README specifies 12 (
OC00+00+ 12 + 2 check digits = 20). It's an off-by-one in the generator, not a design choice. Verified my checksum implementation against known-good LEIs first (Shell21380068P1DRHMJ8KU70, BP, Rosneft, and OpenCorporates' own254900QNTKOM4TQJUM96) — all pass, so the failure is in the data, not the test.2. 89% of country fields are empty.
<lei:Country/>appears 2,770,320 times vs 329,772 populated (2 per record: LegalAddress + HeadquartersAddress). CDF requires ISO 3166-1 alpha-2. Odd, because the jurisdiction is present viaLegalJurisdiction(US-FL,US-CA) andRegion—Country: USsimply isn't backfilled. MostLegalAddressblocks are entirely empty.3.
LastUpdateDateis not a validxs:dateTime—2026-03-02 00:00:00(space instead ofT, no timezone). Other date fields are correct (2007-04-17T00:00:00Z), so this is an isolated serialisation bug.Are pLEIs in the sample, and what fields come with them?
Yes — and notably, real GLEIF LEIs are mixed into the same file (1,603 of them), which is the "bridge" proposition made concrete: a pLEI and an LEI coexist in one namespace.
Per entity:
LegalName,HeadquartersAddress(often partial),RegistrationAuthorityID+RegistrationAuthorityEntityID(the native register ID — this is the bridge key we'd actually use),LegalJurisdiction,EntityCategory, ISO 20275EntityLegalFormCode,EntityStatus,EntityCreationDate, and aRegistrationblock (InitialRegistrationDate,LastUpdateDate,RegistrationStatus,NextRenewalDate,ManagingLOU,ValidationSources). One custom element:<oc:PLEI>in the Extension, which merely duplicates<lei:LEI>.Caveat: 67% of the sample is
INACTIVE(1,032,417 of 1,550,046) — dissolved entities included.Level 1 only — no relationships (confirmed empirically)
Grepped for every L2 construct —
RelationshipRecord,RelationshipData,Relationship,RelationshipType,ReportingException— zero occurrences. This is Level 1 identity/address data; there is no RR-CDF file.This matters for us specifically. GLEIF's value to OpenCheck isn't only the LEI — it's the Level 2 relationship graph that seeds the ownership network (
map_gleif_subsidiaries, the direct-children fan-out). A pLEI would give reach (more entities identifiable) but not structure. And since OpenCheck already consumes OpenCorporates for relationships, today's marginal gain is the identifier alone, not new edges.Why it's still strategically interesting
The national-ID search (Phase 46) exists precisely because users arrive with a company number, not an LEI — and today we can only proceed if GLEIF happens to know that company. A conformant pLEI would let any company number become a valid entry point. And because it's CDF-shaped,
map_gleif()and the GLEIF→BODS mapping would largely work as-is.What to watch for (revisit triggers)
Countrypopulated;LastUpdateDatea validxs:dateTime.ManagingLOUasserts OpenCorporates (254900QNTKOM4TQJUM96) as issuing authority — a claim, not GLEIF accreditation (their README explicitly disclaims affiliation with GLEIF). For a CDD tool, "who vouches for this identifier" matters as much as the identifier itself.Actions
marketing@opencorporates.com; they explicitly ask for alpha feedback). Cheap, and exactly what an alpha is for.Background: OpenCorporates' 10-part series, Fundamentals of legal entity identity data.