STRUCT-LEI-FORMAT - LEI values must match the LEI format pattern (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 separate EBA W1 control text: it is a product mechanic of the structural layer (identifier patterns, blueprint task F2.E3.T1). The pattern below is the exact LEI format pattern the official W2 LEI rules check (measured, N-13), applied here per cell:

^[A-Z0-9]{18}[0-9]{2}$

The finding carries only this synthetic STRUCT id, never an official W2 rule code (N-13).

What this rule checks

The check covers the lei-typed columns. Measured in eba-4.0-errata5, these are 9 columns: the key identifier columns c0010 in B_01.01 and B_01.02, c0020 in B_01.03, B_02.02, B_03.01, B_03.03 and B_04.01, c0040 in B_06.01 - plus the fact column c0060 (LEI of the direct parent undertaking of the entity) in B_01.02. Selection is metadata-driven via the column data type.

Every non-empty cell must match the pattern: exactly 20 characters, the first 18 from A-Z and 0-9, the last 2 digits. Lowercase letters, spaces, a wrong length or punctuation all fail. An empty cell is skipped here - emptiness of the key LEI columns is STRUCT-MANDATORY.

Layer context: at the ESAs the same pattern is checked by the W2 rules (severity warning - e.g. v8891_m for the B_01.02 key, v8826_m for the parent LEI). The RoI Builder additionally runs the pattern at the blocking structural layer, so a malformed identifier is stopped before a package is built. Check digits are a separate check (STRUCT-LEI-CHECKSUM); whether the LEI exists in the GLEIF database is a W3 check (e.g. VR_12), which never blocks.

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

• A truncated or overlong code after copying - the LEI must have exactly 20 characters.
• Lowercase letters (the pattern accepts capitals only) or spaces around/inside the code.
• A different identifier (national registration number, internal code) pasted into an LEI column.

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. Copy the entity's 20-character LEI from its source and paste it into the flagged cell; remove spaces, convert to capitals.
3. If the entity's identifier is not an LEI at all, it does not belong in an lei-typed column - check which row you are editing.
4. Run the validation again; a format-valid code is then still checked by STRUCT-LEI-CHECKSUM.

Example: fails vs passes

Fails - 21 characters and a lowercase letter at the end; the finding points at column c0010 of this B_01.02 row:

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

Passes - a 20-character LEI matching the pattern:

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

Also passes (edge case) - an empty c0060 (LEI of the direct parent undertaking of the entity) cell in B_01.02: this format check skips empty cells; for the KEY columns emptiness is blocked by STRUCT-MANDATORY.

Related rules

• STRUCT-LEI-CHECKSUM - the second stage on the same columns: a format-valid code must also have valid ISO 17442 check digits.
• v8891_m - W2 (warning): the key c0010 of every B_01.02 row must match the same LEI pattern.
• v8826_m - W2 (warning): a filled parent LEI (c0060 in B_01.02) must match the same pattern.
• VR_12 - W3: the LEI of a B_01.02 row must have a record in the GLEIF database (never blocking).