LEI Reference Data & KYB

What LEI data-quality grading is, and isn't, for KYB onboarding

For KYB analysts, onboarding-ops teams, and compliance engineers who pull a counterparty's Legal Entity Identifier record and need to know how sound that record actually is, and where a data-quality grade stops and a real onboarding decision starts.

🔒 All inputs are processed locally in your browser. No data is transmitted. Do not enter real personal data — use synthetic or anonymised inputs only.
Scope. This workflow covers four LEI tools: two existing verify/decode tools, a paste-mode data-quality grading worksheet, and a worker MCP tool that fetches the live GLEIF record. None of them is a KYB clearance system, a sanctions screen, or a substitute for an analyst's own onboarding decision.

LEI Lifecycle & GLEIF Validation Tool · T317

Validates an LEI against the ISO 17442 check digit and reports ISSUED / LAPSED / RETIRED / FORMAT ERROR, batch up to 100.

Open tool →

LEI / BIC / IBAN Anatomy Decoder · T363

Decodes and validates an LEI, BIC/SWIFT code, or IBAN's structural anatomy and check digits.

Open tool →

LEI Data-Quality Grading Worksheet · T551

Grades a pasted GLEIF record against GLEIF's published data-quality dimensions and produces a disposed, tamper-evident KYB worksheet receipt.

Open tool →

lei_kyb_check · MCP Tool

Worker-side MCP tool: fetches the live GLEIF record for an LEI and returns the same grading plus an asserted-fetch receipt with source provenance.

MCP endpoint →

The problem this solves

An LEI record can be structurally valid, ISSUED status, correct check digit, well-formed, and still be a poor data-quality record: a renewal date years stale, no Level-2 parent disclosure where one should exist, an address field left incomplete, a reporting exception typed but uncorroborated. GLEIF publishes data-quality dimensions precisely because "the identifier is valid" and "the record behind it is trustworthy" are different questions. A KYB analyst pulling a counterparty's LEI needs an answer to the second question, not just the first, and needs it in a form that survives an audit: who reviewed which finding, what they decided, and when.

House tools 317 and 363 already answer the first question well, lifecycle status and structural anatomy. Neither one grades the record's data quality or produces a disposition trail. That gap is what the worksheet and the MCP tool below fill.

How the four tools fit together

  1. Validate the LEI itself with the LEI Lifecycle & GLEIF Validation Tool (T317): confirm the check digit, current status, and format before grading anything built on top of it.
  2. Decode counterparty identifiers with the LEI / BIC / IBAN Anatomy Decoder (T363) when the same onboarding record also carries a BIC or IBAN that needs its own structural check.
  3. Grade the record's data quality with the Data-Quality Grading Worksheet (T551): paste the GLEIF JSON:API record, get per-dimension grades and a composite, and disposition each finding accept / flag / escalate to produce a KYB worksheet receipt.
  4. Or fetch live and grade in one call with the lei_kyb_check MCP tool: an agent supplies an LEI, the worker fetches the current GLEIF record and returns the same grading with a source-provenance receipt, no manual paste step. The paste-mode worksheet and the live MCP tool produce identical grades on the same underlying record.
What this grades, and what it doesn't. The worksheet and the MCP tool grade the data quality of the LEI record, registration status, renewal timeliness, corroboration level, entity status, parent-link disclosure, address completeness, against GLEIF's own published dimensions. They say nothing about the counterparty's creditworthiness, sanctions exposure, or whether the entity is legitimate to do business with. A clean data-quality grade means the record is well-maintained, not that the entity has been cleared. Treat a high grade as "this record is fit to build a KYB decision on," never as the decision itself.

Why a live fetch and a pasted record can disagree

The MCP tool's fetch is asserted, not cryptographically proven: the worker states what it retrieved and when, with a response digest, but that is a provenance claim rather than a zkTLS-style proof. GLEIF records also change, a renewal posts, a status lapses, so a live grade and a grade run against a record pasted an hour earlier can legitimately diverge. Neither the worksheet nor the MCP tool is deterministic across time in the way a pure computation is; both are honest about that in their receipts rather than labeling a live-fetch result bit-exact.

Zero egress on the browser side. The paste-mode worksheet (T551) makes no network call, per this site's zero-egress policy; the caller supplies the GLEIF record. Only the worker-side lei_kyb_check MCP tool reaches out, to GLEIF's public API alone, under a named-allowlist exception, never a browser tool.