v8892_m - LEI format of the head-office row key (B_01.03)

Official expression (EBA, verbatim)

match({tB_01.03, c0030}[get LHH], "^[A-Z0-9]{18}[0-9]{2}$")

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

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

What this rule checks

Template B_01.03 (List of branches) has one row per branch. The row key is composite: c0010 (Identification code of the branch) plus c0020 (LEI of the financial entity head office of the branch).

The rule checks the second part of the key: the value of c0020 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. The first key column, c0010 (Identification code of the branch), is not subject to this rule - a branch code does not have to be an LEI.

In the published expression the anchor is written as c0030 with the key property [get LHH]. [get LHH] reads the key property LHH - the LEI code of the head office, physically column c0020 in the csv file; the c0030 in the expression is only the context anchor, and the rule does not concern the branch name. The artifact's own Description says "column 0020", and the finding points at column c0020 - its row key carries both key values (c0010 and c0020). 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 an 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

• c0020 holds the branch's own identifier or a national number instead of the head office's LEI.
• Lowercase letters, spaces or a wrong length - the pattern requires exactly 20 characters, uppercase A-Z and digits only.
• The key columns were shifted in a CSV or Excel export and another value landed in c0020.

How to fix it, step by step

1. Open template B_01.03 and find the flagged row. The finding gives the row number and both key values: c0010 (Identification code of the branch) and the offending c0020.
2. Replace the value in c0020 with the LEI of the branch's head office: exactly 20 characters, 18 uppercase letters or digits followed by 2 digits.
3. Remember that c0020 is part of the composite row key: rows are identified by the pair c0010 plus c0020, so correct the cell rather than duplicate the row.
4. Run the validation again and confirm the v8892_m warning for that row is gone.

Example: fails vs passes

Fails - the head-office LEI is 21 characters long and ends with a lowercase letter; the finding points at column c0020 and carries the offending value:

c0010 (Identification code of the branch)	c0020 (LEI of the financial entity head office of the branch)
BR-001	549300Q5EH2NP82EPE34a

Passes - the head-office LEI matches the pattern:

c0010 (Identification code of the branch)	c0020 (LEI of the financial entity head office of the branch)
BR-001	DUMMYLEI123456789012

Related rules

• v8890_m and v8891_m - the same key-format family: the LEI pattern of the row key of B_01.01 (v8890_m) and B_01.02 (v8891_m); the family members v8893_m to v8897_m are inactive on the current EBA list.
• v8856_m and v8857_m - the coupled pair of data columns on the same template: a filled branch name (c0030) requires the branch country (c0040) and the other way round.