STRUCT-LEI-CHECKSUM - LEI check digits must verify (ISO 17442) (B_01.01, B_01.02, B_01.03, B_02.02, B_03.01, B_03.03, B_04.01, B_06.01)

Official control text (EBA, verbatim)

This check has no EBA W1 control text and no official W2 rule either: it is a product tightening beyond the official rules (measured, N-13). The official W2 LEI rules check the format pattern only; the ISO 17442 check digits (the last two digits of the code) are verified only here, under this synthetic STRUCT id - never under an official W2 rule code.

What this rule checks

The check covers the same 9 lei-typed columns as STRUCT-LEI-FORMAT (the key identifier columns of B_01.01, B_01.02, B_01.03, B_02.02, B_03.01, B_03.03, B_04.01, B_06.01 plus c0060 in B_01.02). It only examines cells that already PASS the format pattern - a format-invalid cell is reported once by STRUCT-LEI-FORMAT and never double-reported here.

The last two digits of an LEI are check digits under ISO 17442 (mod 97-10, the same scheme as in IBAN numbers). A 20-character code whose check digits do not verify practically always means a transcription error: one character mistyped, two characters swapped, or a corrupted copy. A real LEI has valid check digits by construction.

Layer context: whether the LEI actually exists in the GLEIF database is a W3 check (e.g. VR_2, VR_12), which never blocks. This structural check catches the mechanical corruption earlier, before a package is built.

This is a structural check in the RoI Builder (STRUCT layer, severity: blocking). It maps to no W1a/W1b control at the ESAs - the official validation does not technically reject a package on receipt for this finding. The RoI Builder blocks the final export on it, so the issue is caught before filing.

Most common causes

• The LEI was typed by hand and one character came out wrong.
• Two characters were swapped or dropped while copying between sheets.
• A placeholder code shaped like an LEI (e.g. the dummy from the official sample package) was left in a real row.

How to fix it, step by step

1. Open the flagged template and find the row - the finding gives the row number, the key values and the offending value.
2. Go back to the source of the LEI and copy the full 20-character code again; paste it over the flagged cell.
3. Do not "fix" single characters by eye - a code that verifies can still be the wrong entity's LEI; copying beats retyping.
4. Run the validation again and confirm the finding is gone.

Example: fails vs passes

Fails - the code matches the format pattern, but the check digits do not verify; the finding points at column c0010 of this B_01.02 row:

c0010 (LEI of the entity)	c0020 (Name of the entity)
DUMMYLEI123456789012	Bank Testowy A

DUMMYLEI123456789012 is the dummy code of the official sample package - shaped like an LEI, but not a real one.

Passes - a real LEI with valid check digits:

c0010 (LEI of the entity)	c0020 (Name of the entity)
549300Q5EH2NP82EPE32	Bank Testowy A

Edge case - 549300Q5EH2NP82EPE34a is NOT examined here: it fails the format pattern first and is reported by STRUCT-LEI-FORMAT.

Related rules

• STRUCT-LEI-FORMAT - the first stage on the same columns: the 20-character pattern; only cells passing it are examined here.
• v8826_m - W2 (warning): the official LEI rules check the format only - a format-valid code with wrong check digits passes v8826_m (N-13).
• VR_12 - W3: existence of the LEI in the GLEIF database (never blocking).
• VR_2 - W3: the same existence check for the LEI of the entity maintaining the register (B_01.01).