STRUCT-CLOSED-TABLE-ROWS - Closed table B_99.01 admits at most one row (B_99.01)
Template B_99.01 is the only closed table and admits at most one data row; every additional row is a blocking finding.
- Layer
- STRUCT
- Severity
- blocking
- Templates
- B_99.01
- Columns
- Taxonomy version
- eba-4.0-errata5
- Status
- founder-approved
Reviewed at gate 1 (founder) on
Content last changed
Official control text (EBA, verbatim)
For closed tables, No row identifier can be reported twice
Source: EBA technical check 804 (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-CLOSED-TABLE-ROWS.
What this rule checks
Template B_99.01 (Definitions from Entities making use of the ICT Services) is the only closed table of the register. Measured in the taxonomy package: its natural key is empty and all 19 columns are pinned to one fixed DPM row - so a second data row necessarily repeats the same row identity, which is exactly what EBA check 804 forbids. The official sample package reports B_99.01 with exactly one data row.
The check is metadata-driven: any keyless template admits at most one row, and every row beyond the first yields one blocking finding, addressed by row number alone (keyless rows have no natural key to point at). The other 14 templates have natural keys, so this check does not apply to them - their duplicates are STRUCT-KEY-UNIQUE.
The check lives on the data side because the register model can hold many B_99.01 rows entered in the UI; the package writer serializes the single-row shape exactly like the official sample.
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
- Definitions entered as several rows - one row per definition - instead of a single row with all definition columns filled.
- An import merged last year's B_99.01 row with a manually entered one.
How to fix it, step by step
- Open template B_99.01 - the finding names every extra row by its row number.
- Consolidate the content into the first row: B_99.01 is one row of definition columns, not a list.
- Delete every row beyond the first.
- Run the validation again and confirm the finding is gone.
Example: fails vs passes
Fails - two data rows in the closed table; the finding points at row 2 of B_99.01:
| Row number in B_99.01 | Result |
|---|---|
| 1 | passes - the single allowed row |
| 2 | STRUCT-CLOSED-TABLE-ROWS (blocking): maxRows = 1, actualRows = 2 |
Passes - exactly one data row in B_99.01 (the shape of the official sample package).
Related rules
- STRUCT-KEY-UNIQUE - the open-table counterpart: duplicates in the 14 keyed templates are reported there.
- STRUCT-MANDATORY - B_99.01 has no required columns, so key-emptiness findings never occur in it; the row-count limit here is its only structural row constraint.
Fix it in the RoI Builder - it points at the exact row and cell and re-checks as you type.
This page describes what the software does. It is neither legal advice nor an interpretation of any regulation, and using the product does not by itself make any submission complete, correct or acceptable to any authority. The responsibility for what is filed stays with the entity that files it.