Register of Information glossary
The vocabulary of Register of Information reporting is split across several documents, and a term that means one thing in your workbook is often written another way in the feedback you get back. These are the terms this validator uses, defined once. Where a definition rests on a published document, the source is linked beneath it.
- Register of InformationRoI
- The structured record a financial entity keeps of its contractual arrangements for the use of ICT services provided by third-party providers, and reports to its supervisory authority. It is not a document written in prose: it is a set of tabular templates with defined fields, identifiers and closed-set values, which is why it can be validated mechanically at all.
- ITS (EU) 2024/2956the Implementing Regulation
- The implementing technical standard that lays down the templates and the reporting format for the Register of Information. It is the document this validator is built against: the template structure, the field list and the reportable forms all come from it and from the EBA material published alongside it.
- RT templatesRT.01.01 … RT.07.01
- The reporting templates that make up the register. Each one is a sheet in the workbook, named for its code, and each holds a defined set of fields. RT.99.01RT.99.01Options legendDefinitions from entities making use of the ICT ServicesThis template captures entity-internal explanations, meanings, and definitions of the closed set of indicators used by the financial entity in the register of information.RT.07.01 asks for the impact of losing a service as low, medium or high. RT.99.01 is where the firm writes down what it means by "high". It holds no register data of its own — it is the key to the closed-set answers given elsewhere.Without it, a supervisor reading "high" has no way to know what the firm meant by it.Full entry is the odd one out: it is an options legend listing permitted values, not a template you report. The table further down this page lists every template this validator knows, generated from the specification rather than typed by hand.The ESA reporting template carries 14 reporting templates, RT.01.01 to RT.07.01, plus RT.99.01, which is an options legend rather than a reportable template.
- Data Point ModelDPM
- The EBA’s data model, and the notation its systems speak. Every RT template has a DPM counterpart written B_xx.xx, and every column has a code written c0010, c0020 and so on. You look at RT.05.01RT.05.01ICT third-party service providersB_05.019 fieldsThis template lists and provides general information to identify: (a) the direct ICT third-party service providers; (b) the ICT intra-group service providers; (c) all subcontractors included in template B_05.02 on ICT service supply chain; (d) the ultimate parent undertaking of the ICT third-party service providers listed in points (a), (b) and (c).The vendor list. For each provider: its identification code and what kind of code that is, its name, the country of its headquarters, the total annual cost, and its ultimate parent undertaking.Every identification code here is read against the type of code it declares itself to be.Full entry ; the feedback you receive says B_05.01 c0010. They are the same place. Every finding this validator reports prints both, so you never have to translate between them.
- xBRL-CSV reporting package
- The form a submission actually takes: not a spreadsheet, but a ZIP archive laid out to a defined structure, containing the register as CSV files plus the metadata that tells the receiving system how to read them. Producing one is a packaging step, separate from getting the content right, and a register can be perfectly correct and still fail because the package is not.A submission is an xBRL-CSV reporting package following Report Package 1.0, containing META-INF/reportPackage.json and a reports folder. Source (opens in a new tab)
- UTF-8
- The character encoding a reporting package must use. This matters more than it sounds: an accented entity name or a non-breaking space saved from a spreadsheet in a legacy encoding is a common way for a package that looks right on screen to be rejected on arrival.Reports must use UTF-8 encoding. Source (opens in a new tab)
- Closed setsdrop-down values, eba_ prefix
- Many fields accept only a value drawn from a fixed published list — a country, a currency, a type of arrangement. Those values have to be written in the coded form the taxonomy expects rather than in the words a reader would use, which is why a register that reads correctly to a person can still be wrong to a machine.Values drawn from a closed set must be written with the eba_ prefix, for example eba_CT:x12. Source (opens in a new tab)
- Legal Entity IdentifierLEI
- A 20-character code identifying a legal entity, defined by ISO 17442: eighteen alphanumeric characters followed by two check digits. The check digits are computed from the rest of the code with the MOD 97-10 algorithm, so a mistyped LEI can usually be detected offline, without asking anyone whether the code exists. That is exactly what this validator does.
- GLEIF
- The Global Legal Entity Identifier Foundation, which operates the database of issued LEIs. This is the boundary of what an offline tool can tell you: a check digit proves a code is well formed, not that it was ever issued, nor that it is still active. A structurally valid LEI that is not in the database will pass here and can still be rejected.Several published checks require an LEI to be valid according to the GLEIF database, which no offline tool can establish. Source (opens in a new tab)
- EUIDdefinition pending verification
- The European Unique Identifier, which appears alongside the LEI in the identifier checks published by the EBA. Its full definition and validation rules are not yet grounded in the specification documents held in this repository, so no rule here validates it and no definition is asserted beyond that.
- Validation rules
- The published checks a register is tested against before it is accepted, spanning file-level technical checks, model-level checks, business rules about the content, and identifier checks. This validator implements a subset of them and states which; a clean result here means the checks that ran found nothing, not that a submission will be accepted.The EBA publishes 120 checks for Register of Information reporting, in four categories: technical checks, DPM technical checks, DPM business validation rules, and LEI/EUID checks. Source (opens in a new tab)
- Blocking and warning
- What happens to your submission, not how bad we think something is. The two words are the regulator’s: a failed technical check is an error that rejects the register on arrival, while a business or identifier check raises a warning — the register is accepted and you are expected to fix the issue and resubmit. Every finding here takes its severity from the check it implements rather than from a judgement of ours, and shows the rule and the source behind it.The ESAs’ technical checks are errors that reject a submitted register, while the DPM business validation and identifier checks are warnings: the register is accepted, and the entity is expected to fix the issues and resubmit. Source (opens in a new tab)
- ICT third-party service provider
- The counterparty whose services a financial entity records in the register — the supplier side of the arrangement. Much of the register exists to describe who they are, what they provide, and how the arrangement is structured, which is why identifiers and closed-set classifications carry so much of the content.
- Competent authorityNCA
- The national supervisory authority a financial entity submits its register to. Which authority, in what window and through which channel, depends on the entity and the Member State; those are questions for the authority itself, and this site does not answer them on its behalf.
RT templates
The register is not one document but a set of tables. Each is a sheet in the ESA workbook, named for its code, and each holds a defined set of fields. Between them they describe who you are, what you have contracted for, from whom, for which of your own functions, and how exposed you would be if the service stopped.
A code reads in three parts. RT.05.02RT.05.02ICT service supply chainB_05.027 fieldsThis template identifies and links the ICT third-party service providers that are part of the same ICT service supply chain.A bank’s payroll provider stores its data with a cloud host, which uses a third firm for backups. RT.05.02 records that chain rank by rank — the part of the register most firms cannot answer from their own contracts, because the answer sits with the vendor.Sub-contracting is where a dependency nobody contracted for turns up.Full entry is a reporting template, in the fifth family — the one covering ICT third-party service providers — and the second template within that family. Templates sharing a family share a subject, which is why RT.05.01RT.05.01ICT third-party service providersB_05.019 fieldsThis template lists and provides general information to identify: (a) the direct ICT third-party service providers; (b) the ICT intra-group service providers; (c) all subcontractors included in template B_05.02 on ICT service supply chain; (d) the ultimate parent undertaking of the ICT third-party service providers listed in points (a), (b) and (c).The vendor list. For each provider: its identification code and what kind of code that is, its name, the country of its headquarters, the total annual cost, and its ultimate parent undertaking.Every identification code here is read against the type of code it declares itself to be.Full entry lists the providers and RT.05.02 the supply chains they sit in.
Select any code below — or anywhere else on this site — for the template’s official description, an example of when it is used, and why it matters.
| Template | Name | DPM code | Fields |
|---|---|---|---|
| RT.01.01RT.01.01Entity maintaining the register of informationB_01.016 fieldsThis template identifies the entity maintaining and updating the register of information at entity, sub-consolidated and consolidated level, respectively.A compliance officer at a mid-size bank is preparing to submit. Before anything else the file has to say who is filing it: the bank’s own LEI, its country, its type, and which authority receives it. That single row is RT.01.01.If this row is wrong, an otherwise correct register is filed against the wrong entity.Full entry | Entity maintaining the register of information | B_01.01 | 6 |
| RT.01.02RT.01.02List of entities within the scope of consolidationB_01.0211 fieldsThis template identifies all the entities belonging to the group. Where the financial entity responsible for maintaining and updating the register of information does not belong to a group, only that financial entity shall be reported in this template.An insurance group files one register for the whole group. RT.01.02 is where each entity in the consolidation is listed — LEI, country, parent undertaking, total assets — so a supervisor can see which legal entities the rest of the register speaks for.Every LEI used elsewhere in the register is expected to have been declared here first.Full entry | List of entities within the scope of consolidation | B_01.02 | 11 |
| RT.01.03RT.01.03List of branchesB_01.034 fieldsThis template identifies the branches of the financial entities referred to in template B_01.02.A French bank runs a branch in Belgium. The branch is not a separate legal entity and has no LEI of its own, so it cannot be listed in RT.01.02. RT.01.03 is where it is named and tied back to its head office.Reporting a branch as though it were a legal entity is one of the easier structural mistakes to make.Full entry | List of branches | B_01.03 | 4 |
| RT.02.01RT.02.01Contractual arrangements – general informationB_02.015 fieldsThis template lists all contractual arrangements with direct ICT third-party service providers.The procurement team pulls every ICT contract in force. Each one is given a reference number here, together with whether it stands alone or sits under a master agreement, and what it cost last year.The reference numbers minted here are the key that binds most of the rest of the register together.Full entry | Contractual arrangements – general information | B_02.01 | 5 |
| RT.02.02RT.02.02Contractual arrangements – specific informationB_02.0218 fieldsThis template provides details in relation to each contractual arrangement listed in template B_02.01 with regard to: (a) the ICT services included in the scope of the contractual arrangement; (b) the functions of the financial entities supported by those ICT services; (c) other important information in relation to the specific ICT services provided (e.g. notice period, law governing the arrangement, etc.).For one cloud contract, this is the long form: which entity uses it, which provider supplies it, the type of service, start and end dates, notice periods on both sides, governing law, where the data sits at rest, and how sensitive it is.It carries more fields than any other template, so it is where most of the filling-in time goes.Full entry | Contractual arrangements – specific information | B_02.02 | 18 |
| RT.02.03RT.02.03List of intra-group contractual arrangementsB_02.032 fieldsThis template identifies the links between intra-group contractual arrangements and contractual arrangements with ICT third-party service providers which are not part of the group using the contractual reference numbers when part of the ICT service supply chain.A subsidiary buys data centre capacity from its own parent, which buys it in turn from an external provider. RT.02.03 links the internal arrangement to the external one.Without it, an intra-group arrangement looks like the end of the supply chain when it is not.Full entry | List of intra-group contractual arrangements | B_02.03 | 2 |
| RT.03.01RT.03.01Entities signing the contractual arrangements for receiving ICT service(s) or on behalf of the entities making use of the ICT service(s)B_03.012 fieldsThis template provides information on the entity signing the contractual arrangements with the direct ICT third-party service provider for the entity making use of the ICT services.A group signs one contract centrally and four subsidiaries use the service. RT.03.01 names the entity that actually put its signature on the paper — often not the entity using the service.Signing and using are different acts, and the register asks for both separately.Full entry | Entities signing the contractual arrangements for receiving ICT service(s) or on behalf of the entities making use of the ICT service(s) | B_03.01 | 2 |
| RT.03.02RT.03.02ICT third-party service providers signing the contractual arrangements for providing ICT service(s)B_03.023 fieldsThis template identifies all the ICT third-party service providers referred to in template B_05.01 signing the contractual arrangements referred to in template B_02.01 for providing the ICT services.The same contract seen from the other side: which of the provider’s legal entities signed it. A vendor often contracts through a local subsidiary rather than under the group name on the invoice.The signing legal entity is frequently not the brand the service is bought under.Full entry | ICT third-party service providers signing the contractual arrangements for providing ICT service(s) | B_03.02 | 3 |
| RT.03.03RT.03.03Entities signing the contractual arrangements for providing ICT service(s) to other entities within the scope of consolidationB_03.032 fieldsThis template identifies all the entities referred to in template B_01.02 signing the contractual arrangements referred to in template B_02.01 for providing the ICT services to other entities in the consolidation.A group’s shared-services company provides IT to its sister entities. It is a provider, and it is also inside the group, so RT.03.03 records it signing to supply the others.Intra-group providers are still providers, and leaving them out understates the group’s own dependencies.Full entry | Entities signing the contractual arrangements for providing ICT service(s) to other entities within the scope of consolidation | B_03.03 | 2 |
| RT.04.01RT.04.01Entities making use of the ICT servicesB_04.014 fieldsThis template identifies all entities making uses of the ICT services provided by ICT third-party service providers and registered in the register of information.One contract, several users. RT.04.01 answers the question "who actually consumes this service" — each entity, whether direct user or branch, tied back to the contract’s reference number.It is what turns a list of contracts into a map of who depends on what.Full entry | Entities making use of the ICT services | B_04.01 | 4 |
| RT.05.01RT.05.01ICT third-party service providersB_05.019 fieldsThis template lists and provides general information to identify: (a) the direct ICT third-party service providers; (b) the ICT intra-group service providers; (c) all subcontractors included in template B_05.02 on ICT service supply chain; (d) the ultimate parent undertaking of the ICT third-party service providers listed in points (a), (b) and (c).The vendor list. For each provider: its identification code and what kind of code that is, its name, the country of its headquarters, the total annual cost, and its ultimate parent undertaking.Every identification code here is read against the type of code it declares itself to be.Full entry | ICT third-party service providers | B_05.01 | 9 |
| RT.05.02RT.05.02ICT service supply chainB_05.027 fieldsThis template identifies and links the ICT third-party service providers that are part of the same ICT service supply chain.A bank’s payroll provider stores its data with a cloud host, which uses a third firm for backups. RT.05.02 records that chain rank by rank — the part of the register most firms cannot answer from their own contracts, because the answer sits with the vendor.Sub-contracting is where a dependency nobody contracted for turns up.Full entry | ICT service supply chain | B_05.02 | 7 |
| RT.06.01RT.06.01Functions identificationB_06.0110 fieldsThis template identifies and provides information on the functions of the financial entity making use of the ICT services.Before any service can be assessed, the firm names its own functions — "execution of retail payments", say — and says whether each is critical or important, why, and how long it could be down. The function identifiers defined here are used throughout RT.02.02.Nothing downstream can be classified until the functions here have been named.Full entry | Functions identification | B_06.01 | 10 |
| RT.07.01RT.07.01Assessments of the ICT servicesB_07.0112 fieldsThis template captures information in relation to the risk assessment of the ICT services (e.g. substitutability, date of last audit, etc.) when those ICT services are supporting a critical or important function or material part thereof.For each service supporting a critical or important function: could this provider be replaced, when was it last audited, is there an exit plan, could the service be brought back in house, and has an alternative provider been identified.These are the judgements no vendor can make on your behalf.Full entry | Assessments of the ICT services | B_07.01 | 12 |
| RT.99.01RT.99.01Options legendDefinitions from entities making use of the ICT ServicesThis template captures entity-internal explanations, meanings, and definitions of the closed set of indicators used by the financial entity in the register of information.RT.07.01 asks for the impact of losing a service as low, medium or high. RT.99.01 is where the firm writes down what it means by "high". It holds no register data of its own — it is the key to the closed-set answers given elsewhere.Without it, a supervisor reading "high" has no way to know what the firm meant by it.Full entry | Definitions from entities making use of the ICT Services | B_99.01 | not reported |
RT.99.01RT.99.01Options legendDefinitions from entities making use of the ICT ServicesThis template captures entity-internal explanations, meanings, and definitions of the closed set of indicators used by the financial entity in the register of information.RT.07.01 asks for the impact of losing a service as low, medium or high. RT.99.01 is where the firm writes down what it means by "high". It holds no register data of its own — it is the key to the closed-set answers given elsewhere.Without it, a supervisor reading "high" has no way to know what the firm meant by it.Full entry is the exception in the table above. It is an options legend, recording what a firm means by the closed-set values it has used elsewhere — low, medium, high — and not a template anybody reports. It is listed because it is part of the workbook, and marked because it is not register data.
Names and descriptions are the enacted text of Annex I to the ITS, in both languages. Codes and field counts are generated from the specification, so this table cannot drift from what the validator actually reads.