STRUCT-MANDATORY - Key columns must not be empty (B_01.01, B_01.02, B_01.03, B_02.01, B_02.02, B_02.03, B_03.01, B_03.02, B_03.03, B_04.01, B_05.01, B_05.02, B_06.01, B_07.01)

Official control text (EBA, verbatim)

For open tables, the key columns values cannot be empty

Source: EBA technical check 805 (sheet "Technical checks", category "Additional Plain-csv" in the official overview of the RoI technical checks). The RoI Builder runs it as structural check STRUCT-MANDATORY.

What this rule checks

The check covers every column marked required in the curated taxonomy metadata. Measured in eba-4.0-errata5, the required flag coincides exactly with the 35 natural-key columns of the 14 open templates - from a single key column (c0010) in B_01.01, B_01.02, B_02.01 and B_05.01 up to the 8-column key of B_02.02 (c0010, c0020, c0030, c0050, c0060, c0130, c0150, c0160). The keyless closed table B_99.01 has no required columns and is exempt - the control text says "for open tables".

Every row must have every key column filled: an empty cell in a required column is one blocking finding per cell. An empty cell is null - this check reports emptiness only and does not judge what a filled cell contains.

This check also underpins two neighbours: rows with an incomplete key are excluded from STRUCT-KEY-UNIQUE (each empty key cell is already blocking here, so nothing passes silently and no cell is double-reported), and cross-template references with an empty key component are skipped by STRUCT-FK for the same reason. Requiredness of NON-key data columns is a different layer: the W2 row-completeness rules, severity warning.

This is a structural check (STRUCT layer, severity: blocking). If it fails, the package is technically rejected on receipt (feedbackMain = REJECTED). The structural layer is the only layer that blocks a filing.

Most common causes

• The row was started from the data columns and the key cell was left "for later".
• A column shift in a pasted sheet moved the key value into a neighbouring column.
• Two sheets were merged and one of them kept the key in a different column position.

How to fix it, step by step

1. Open the flagged template and find the row - the finding gives the row number and the column code of the empty key cell.
2. Fill the flagged key cell with the real identifier (LEI, contractual arrangement reference number, function identifier, country code of provision, and so on - whatever the column holds).
3. If the row exists by mistake, delete the entire row instead.
4. Run the validation again and confirm the finding is gone - and watch for STRUCT-KEY-UNIQUE if the newly filled key duplicates another row.

Example: fails vs passes

Fails - the second key column of B_01.03 (List of branches) is empty; the finding points at column c0020 of this row:

c0010 (Identification code of the branch)	c0020 (LEI of the financial entity head office of the branch)
ENT-1	(empty)

Passes - both key cells filled:

c0010 (Identification code of the branch)	c0020 (LEI of the financial entity head office of the branch)
ENT-1	549300Q5EH2NP82EPE32

Related rules

• STRUCT-KEY-UNIQUE - uniqueness of the same natural keys; rows with an incomplete key are handled here first.
• STRUCT-FK - cross-template references resolve against these keys; references with an empty component are skipped there because they are already blocking here.
• v8858_m - an example of the W2 row-completeness family: requiredness of NON-key columns is a warning, not a blocking finding.