v8891_m - LEI format of the B_01.02 row key (B_01.02)

Official expression (EBA, verbatim)

match({tB_01.02, c0020}[get ESI], "^[A-Z0-9]{18}[0-9]{2}$")

Precondition (verbatim): {v_B_01.02} - the rule is evaluated only when template B_01.02 is part of the filing (its filing indicator is true).

Description in the EBA artifact (verbatim): "This VR checks the format of column 0010 (LEI code)"

What this rule checks

Template B_01.02 (List of entities within the scope of the register of information) has one row per entity within the scope of the Register of Information (RoI). The row key is c0010 (LEI of the entity).

The rule checks the row key itself: the value of c0010 in every row must match the pattern ^[A-Z0-9]{18}[0-9]{2}$ - exactly 20 characters, the first 18 being uppercase letters A-Z or digits, the last 2 being digits.

In the published expression the anchor is written as c0020 with the key property [get ESI]. [get ESI] reads the key property ESI - the LEI code of the entity reported in the register, physically column c0010 in the csv file; the c0020 in the expression is only the context anchor, and the rule does not concern the entity name. The artifact's own Description says "column 0010", and the finding points at column c0010. This rule has no XBRL counterpart (xbrl = No) - it exists for the plain-csv register format.

The rule checks only the character pattern. An LEI that matches the pattern but has an incorrect ISO 17442 check-digit sum still passes this rule; whether the LEI exists in the GLEIF database is checked separately by the W3 identifier checks (for example VR_2 on B_01.01, VR_23 on B_01.02).

This is a warning-level check (layer W2, severity: warning). It does not technically block or reject a filing at the ESAs - a technical rejection can only be caused by the structural file checks (STRUCT layer). A violation shows up as a warning in the validation feedback. The rule is active on the current EBA validation rules list (status as of 2026-06-23).

Most common causes

• c0010 holds an internal or national identifier instead of the entity's LEI (for example ID-KRAJOWE-77).
• Lowercase letters, spaces or a wrong length - the pattern requires exactly 20 characters, uppercase A-Z and digits only.
• The key column was shifted in a CSV or Excel export and another value landed in c0010.

How to fix it, step by step

1. Open template B_01.02 and find the flagged row. The finding gives the row number and the offending key value from c0010.
2. Replace the value in c0010 with the entity's LEI: exactly 20 characters, 18 uppercase letters or digits followed by 2 digits.
3. Remember that c0010 is the row key: rows are identified by this value, so correct the cell rather than duplicate the row.
4. Run the validation again and confirm the v8891_m warning for that row is gone.

Example: fails vs passes

Fails - the key is not an LEI; the finding points at column c0010 and carries the offending value:

c0010 (LEI of the entity)	c0020 (Name of the entity)
ID-KRAJOWE-77	Bank Testowy A

Passes - the key is a valid-format LEI:

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

Related rules

• v8890_m to v8897_m - the same key-format family: each rule checks the LEI pattern of a key property of a different template (v8890_m on B_01.01, v8892_m on B_01.03; v8893_m to v8897_m are inactive on the current EBA list).
• v8826_m - the LEI pattern on a data column of the same template: c0060 (LEI of the direct parent undertaking of the entity).
• VR_23 - W3 identifier check on B_01.02: whether the LEI exists in the GLEIF database.