A missing namespace is not a cosmetic problem
Two columns carry the type of ICT service: B_05.02 column 0020 and B_07.01 column 0040. Both take a value from list TA4, the nineteen service types from S01 to S19. Our transcription of the annex recorded them as key columns and gave them no list, so the packager wrote a bare S17 where the taxonomy requires eba_TA:S17.
The difference is invisible in a spreadsheet and fatal in a filing. A bare S17 is a string that resolves to nothing; eba_TA:S17 is a member of a domain the taxonomy knows about. Every fact in those columns was rejected. Nothing in the file looked wrong, and nothing we could have run against our own rules would have found it, because our own rules said the column had no list.
The lesson is narrower than it sounds. It is not that transcription is hard. It is that a transcription error is invisible to any test written from the same transcription, and the only cure is an outside reference.
- Check every closed-list column against the EBA's own sample instance, not against your reading of the annex
- A value that looks filled in your product can still be a value the taxonomy cannot resolve
- The sample instance is the cheapest oracle available: it shows which columns carry a namespace prefix
Three columns are booleans and look like text
B_02.03, B_03.01 and B_03.03 each carry a column the annex labels Link, with the type hint TRUE. Read quickly, that is a text column containing the word TRUE. It is not. The underlying element is a boolean, and the taxonomy enforces it.
Our builder filled those columns with qx2000, an identifier type from an entirely different list, because the code that wrote them had been copied from a neighbouring column. The taxonomy rejected every one with a schema type error. The value was not merely wrong for the column; it was the wrong kind of thing.
This is worth dwelling on because it is the failure mode of every register assembled by hand. A column is filled with something plausible, and plausible is not the test. The test is whether the element accepts it.
A key column is the row's identity, not just a required field
B_04.01 records the entities making use of each ICT service. Column 0030 says whether the entity is a branch, from a two-value list: x838 for a branch, x839 for not a branch. Column 0040 is the branch's identification code.
We reasoned that a filer with no branches has no branch to identify, so we treated 0040 as conditional and left it empty. The taxonomy disagreed, and the way it disagreed is the interesting part. It did not report one empty cell. It reported every fact in the row as dimensionally invalid, because the key columns are what give the row its identity in the dimensional model. A row missing a key is not a row with a gap; it is a row the taxonomy cannot place at all.
An entity that is not a branch reports its own LEI in that column, and the row validates. We had relaxed a rule that turned out to be correct, which is a specific kind of mistake: we made the product more permissive than the regulator, and a more permissive validator is worse than no validator, because it tells you that you are ready when you are not.
- A row with an empty key column fails entirely, not partially
- Every column marked as a key in the templates is load-bearing, even where it reads as inapplicable
- Relaxing a rule because it seems too strict is the one direction a compliance tool must not guess in
Clearing the structure reveals a second category nobody checks
Once the structural errors were fixed the package loaded, and a different set of failures appeared: the EBA's own business validation rules, by name. v8855_m, v8862_m, v8865_m, v8885_m, v8886_m. These are conditional-mandatory rules. If any of the other columns in a B_05.01 row is populated, column 0110, the ultimate parent's identifier, cannot be empty. A package missing it parses, loads against the taxonomy and is rejected anyway.
There are fifty-eight active rules of this kind in the EBA's published set. They are not exotic. Most are the same shape: fill in part of a row and the rest becomes mandatory. But they are invisible to structural validation, which means a file can be technically perfect and still come back.
Every one of those rules is classified as a warning rather than an error, which matters more than it sounds. A register that trips them is still accepted. A tool that reports them as blocking would stop a filing an authority would have taken, which is the opposite of useful.
What this means if you are assembling a register
The practical conclusion is not that this is impossibly difficult. It is that the checks you can run against your own understanding will not find the errors that matter, because they share the understanding. Three kinds of check are worth having, and they are independent of each other.
First, structural: does the package load against the real taxonomy? Arelle is free and the EBA publishes the taxonomy package. Second, the business rules: the EBA publishes those as a spreadsheet, and parsing their expressions is more reliable than reading them. Third, and least glamorous, a comparison of your column definitions against the EBA's own sample instance, which will show you every column where your reading of the type differs from theirs.
None of this guarantees acceptance. An authority's validator is not ours and a clean result here means only that these checks found nothing. But it moves the discovery of an eighty-eight-error package from the week of the deadline to whenever you like.