Remediation • CSSF submission errors • ESA data quality feedback

Your register was rejected. The message is four characters long and tells you almost nothing.

The CSSF publishes a guide to every error message its submission portal raises, and the ESAs publish another for the checks that run after^[1]. We have read both. This is the service for the week you do not have time to.

The engagement

Price: €2,500–4,000; Excl. VAT. The range is set by how many defects the feedback names, agreed before we start — not by hours spent.
Turnaround: 72 hours from receiving your file and your feedback
You receive: A corrected package ready to resubmit, and a note of what was wrong with each defect the feedback named

Send us the error message

What we resolve, by name

These are the messages that stop a register on arrival or come back against it afterwards, quoted as the authority prints them. Most are mechanical: the register itself is right and the package around it is not. That is why a rejection so often arrives after the work was finished.

Code	Message, as published	What clears it	Free checker
ICTO001CSSF	The filename is not compliant with the naming convention.	The filename carries six parts separated by underscores, in a fixed order ending with the reference date and a creation timestamp. Rebuild it, keep the folder inside matching.	catches it
ICTO003CSSF	The filetype is not supported. File type should be ZIP.	The archive must be a .zip. Neither .rar nor .7z is accepted, and a renamed extension is still the wrong format inside.	catches it
ICTO004CSSF	The file does not respect the authorised limit size. File size should not exceed 20MB.	The upload is capped at 20 MB. Above it the CSSF refuses the file outright and the fix is their helpdesk, not a smaller register.	catches it
ICTO005CSSF	A file has already been submitted with the same filename.	Every filename must be unique, which in practice means the creation timestamp must be one you have not used before. A resubmission that reuses yesterday’s timestamp is refused.	cannot see it
ICTO006CSSF	Reference date of the report must be 31/12/2025.	The reference date in the filename must be the one set for the exercise, not the date you built the file. For the 2026 exercise that is 2025-12-31.	catches it
ICTO007CSSF	No valid or existing LEI has been found for this entity.	The CSSF must already hold your LEI before an upload is possible. It is communicated to your line supervisor, and the portal picks it up on the overnight synchronisation.	cannot see it
ICTO009CSSF	The report cannot be decompressed.	The archive is corrupt or was compressed in a way the portal cannot open. Rebuild and re-upload; a partial transfer is the usual cause.	cannot see it
ICTO010CSSF	Folder name does not match ZIP file name.	The single folder inside the archive must carry the archive’s own name without the .zip extension.	catches it
ICTO011CSSF	ZIP file must contain one single report folder.	The archive must contain exactly one report folder. A second folder, or files sitting loose at the root, is a rejection.	catches it
ICTO012CSSF	Folder should contain exactly two subfolders named "META-INF" and "reports".	That folder must contain exactly two subfolders, named META-INF and reports. Both names are case sensitive: a folder called Reports is refused.	catches it
EBA.1.7.1ESA	Reported XBRL instances MUST NOT include filing indicators with empty or invalid values.	FilingIndicators.csv is case sensitive. Every line but the header carries true in lower case; TRUE is a rejection.	catches it
xbrlce:invalidDecimalsValueESA	Table [table] row [row] column [column] has invalid decimals [value], from report parameter decimalsMonetary.	parameters.csv must set decimalsMonetary to -3. A value of INF is the common mistake, and this single line is enough to fail a package.	catches it
330ESA	Date type metric must be reported with format 'yyyy-mm-dd'.	Dates are written yyyy-mm-dd and nothing else. Slashes, day-first order and an appended time are each rejected.	catches it

The last column is the free checker on this site, and it is marked honestly. Two of these cannot be seen in your file at all: whether a filename was used before depends on what you submitted last time, and whether the CSSF holds your LEI depends on their database. Everything else is visible before you file, which is the argument for checking first and the reason this page exists at all.

How the 72 hours are spent

Step 1
You send the file and the message
The package you submitted and the feedback you received, whichever form it arrived in. Under NDA. If the feedback is an ESA data-quality file rather than an upload error, send that instead — it names defects per row and column.
Step 2
We reproduce the rejection
Every named defect is confirmed against the published guidance before anything is changed. A fix applied to a message we have not reproduced is a guess, and a resubmission spends a filename you cannot reuse.
Step 3
Corrections, and the ones with a clock on them
Mechanical defects are corrected and the package rebuilt. Anything that depends on the CSSF — an LEI they do not yet hold — is flagged immediately, because their database synchronises overnight and a correction made on the deadline cannot land that day^[2]
Step 4
A package you can submit, and a note of what was wrong
The rebuilt package, with a short written account of each defect: what the message meant, what it was, and what changed. You resubmit under your own name. The note is what you show internally when someone asks how it happened.

What this does not do

It does not guarantee acceptance. We resolve the defects your feedback names and the ones we find alongside them; whether the register is then accepted is a decision for your authority, and no one outside it can promise you that outcome.

It is not a rebuild of your register. If the content is wrong — arrangements missing, classifications unmade — that is the assembly engagement, not this one, and we will say so on day one rather than at the end of the 72 hours.

Responsibility for the register and for submitting it remains with your management body. It does not transfer to us, and the resubmission is made under your name.

Where a defect depends on something only your authority or a vendor holds, we identify it and hand it to you with what to ask for. We do not act on your behalf with either.

Frequently asked questions

Our feedback is a spreadsheet of hundreds of rows, not one error code.

Then it is the ESA data-quality feedback rather than an upload rejection, and it is a different shape of problem: hundreds of rows usually means one defect repeated, not hundreds of defects. Send it. The count in the file is rarely the count of things to fix.

We have not filed yet, but we think something is wrong.

Run the free checker on this site first — it catches most of what is in the table above before you spend a submission on finding out. If it comes back clean and you still want a second pair of eyes on the package, that is a shorter conversation and a smaller number.

Why is this not just the sprint at a lower price?

Because it is a different problem. The sprint builds a register from contracts; this repairs a package around a register that already exists. If we open your file and find the second is really the first, we will tell you before the clock starts.

Can you resubmit for us?

No. The submission is made through your own portal access, under your own name, by the people accountable for it. We hand you a package and a note; the act of filing stays yours.

Send the error message. That is enough to start.

Four characters and a filename tell us most of what we need. If it turns out to be something we cannot fix in 72 hours, you will hear that on the first call rather than the third day.