Filing a Register of Information for many entities, not one
Most guidance on the Register of Information is written for a single financial entity producing a single register. If you file for twenty, that guidance is not wrong, but it answers the wrong question — the difficulty is no longer completing a template, it is doing the same classification twenty times without producing twenty inconsistent answers.
Who this page is for
Organisations that file for a range of entities rather than for one.
- Management companies and fund administrators filing across a range of funds
- Insurance brokerage networks and groups
- Accounting and domiciliation firms filing on behalf of the entities they serve
- Group functions maintaining a register at consolidated or sub-consolidated level
What actually repeats, and what does not
The providers, the functions and the criticality judgements repeat across entities. The entity details, the contract references and the package do not.
Twenty funds administered by one house rarely have twenty distinct ICT estates. They share a custodian, a fund accounting platform, a transfer agent, a data vendor and a reporting tool, and the classification of each of those — what function it supports, what service type it is, whether it underpins something critical or important — is a judgement made once and applied.
What does not repeat is the entity layer: identifiers, branches, the contractual arrangement references, and the package that gets filed. That split is why a book of entities is not a multiple of one entity, and it is also why the work is worth doing centrally rather than fund by fund.
Does a group file one register or one per entity?
A register is maintained at entity level, or at sub-consolidated and consolidated level — and a consolidated register covers every financial entity and ICT intra-group provider in the group.[1]
Which entities belong in a consolidated register is not settled by the implementing standard alone: a parent undertaking has to take the relevant sectorial Union legislation into account when deciding. That is a question to answer before the data collection rather than during it, because it determines whose contracts you are gathering.[1]
It is also the question most often deferred, because it looks like a legal formality and is in fact the scoping decision the whole exercise rests on.
What goes wrong at volume that does not go wrong once
Consistency and uniformity — the same provider named two ways, or the same function identified differently in two entities.
The implementing standard names six data quality principles, and two of them are about agreement rather than correctness. A register assembled by several teams passes every field-level check while describing the same provider under two names, or classifying the same shared platform as critical in one entity and not in another. Nothing in the file is malformed; the set is simply not one dataset.[2]
A supervisor comparing entities within a group sees that immediately, and it is the kind of finding that is expensive to explain after the fact and cheap to prevent before it. The engagement handles it by making the classification once and applying it, rather than by reconciling twenty answers afterwards.
What bites at volume during submission
Filename reuse and the identifier synchronisation window — both of which only become schedule risks when there are many filings to make.[3]
A filename that has already been used is rejected, which is a non-event for one filing and a real ordering problem for twenty. The CSSF also states that a register can only be uploaded once the entity’s LEI has been synchronised into the submission portal, which happens once daily overnight — so an identifier communicated on the deadline arrives too late.[4]
Neither is a data quality problem, and neither is visible in the register file. They are the reason a volume filer wants the submission sequence planned rather than discovered.
Questions from people filing at volume
We have entities in more than one country. Does that change the work?
It changes the submission rather than the classification. The templates and the checks are the same instrument everywhere; what differs is which authority receives the package and the mechanics of getting it to them. The classification work is done once regardless.
Can we run part of this in-house and buy the rest?
Yes, and the natural seam is between collection and classification. Gathering contracts and entity data is work your own people can do and know where to look for; deciding function identifiers, service types and criticality is where the judgement and the exposure sit.
What happens next cycle?
The classification carries forward until the underlying arrangements change; the assembly does not. In practice a subsequent cycle is a diff against the previous register plus a rebuild of the package, which is a materially smaller exercise than the first.
One of our entities has already been rejected. Does this help?
Not directly — a rejection starts from the error code rather than from your contracts, and there is a separate, faster engagement for that. It is worth fixing the rejection first and then deciding what to do about the rest of the book.
What to send
The number of entities you file for, an order of magnitude of ICT contractual arrangements per entity, and the authority you file with. That is enough for a figure rather than a range.
Sources
- [1]A register maintained at sub-consolidated and consolidated level must include all financial entities and ICT intra-group service providers that are part of the sub-group and the group; parent undertakings take the relevant sectorial Union legislation into account when deciding which entities to include. Source (opens in a new tab) ↩
- [2]The ITS names six data quality principles the register must satisfy: accuracy, completeness, consistency, integrity, uniformity and validity. Source (opens in a new tab) ↩
- [3]The CSSF publishes guidance interpreting the error messages raised when a Register of Information is submitted, naming codes ICTO001 to ICTO012 — among them a 20MB file size limit, a rejection when a filename has already been used, and a required reference date of 31/12/2025 for the 2026 exercise. Source (opens in a new tab) ↩
- [4]The CSSF states that a register can only be uploaded once its entity’s LEI has been synchronised into the submission portal, which happens once daily overnight — so an LEI communicated on the deadline is too late. Source (opens in a new tab) ↩