STRUCT-KEY-UNIQUE - Natural keys must be unique (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, you cannot have multiple rows with identical key values

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

What this rule checks

The check covers the 14 open templates. Each has a natural key defined by the taxonomy - from a single column (c0010: the LEI in B_01.02, the contractual arrangement reference number in B_02.01, the provider identification code in B_05.01) up to the 8-column key of B_02.02. No two rows of a template may carry an identical key: every occurrence after the first yields one blocking finding on that row, and the finding parameters carry the row number of the first occurrence.

Rows with an INCOMPLETE key (any empty key cell) are excluded here: each empty key cell is already a blocking STRUCT-MANDATORY finding, so nothing passes silently and no cell is double-reported. The keyless closed table B_99.01 is out of scope - its row limit is STRUCT-CLOSED-TABLE-ROWS.

This is the only uniqueness enforcer of the validation stack: measured on the official rules list, W2 contains zero uniqueness rules (0 of 71) - duplicates are a structural matter. A detail worth knowing when reading the official artifacts: EBA check 806 sits in the "DPM Technical Checks" sheet while its category reads "Additional Plain-csv" (the only such row; documented in the mapping spec as published).

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 same entity, arrangement or provider was entered twice (e.g. after merging two working sheets).
• A copied row was edited in the data columns but the key cells were left unchanged.
• In B_02.02 the rows differ in a non-key column only - all 8 key columns are identical, so for the register it is the same row reported twice.

How to fix it, step by step

1. Open the flagged template and find the flagged row - the finding gives its row number, the key values and the row number of the first occurrence.
2. Compare the two rows. If they describe the same thing, merge the differences into the first row and delete the duplicate.
3. If they describe different things, correct the key cell that wrongly repeats the first row's key (e.g. the reference number or the rank).
4. Run the validation again and confirm the finding is gone.

Example: fails vs passes

Fails - two B_01.02 rows with the same key; the finding flags row 2 and points back at row 1 (firstRowNumber = 1):

Row	c0010 (LEI of the entity)	c0020 (Name of the entity)
1	549300Q5EH2NP82EPE32	Bank Testowy A
2	549300Q5EH2NP82EPE32	Bank Testowy A - oddzial

Passes - each row has its own key (here: a distinct LEI per entity); a branch is not a second B_01.02 row under the same LEI - branches live in B_01.03 under their own two-column key.

Related rules

• STRUCT-MANDATORY - empty key cells are reported there; rows with an incomplete key are excluded from this uniqueness check.
• STRUCT-CLOSED-TABLE-ROWS - the closed-table counterpart: the keyless B_99.01 admits at most one row.
• STRUCT-FK - cross-template references resolve against these natural keys, so duplicated keys would make reference targets ambiguous.