Glossaire du registre d’information
Le vocabulaire de la déclaration du registre d’information est réparti entre plusieurs documents, et un terme qui désigne une chose dans votre classeur s’écrit souvent autrement dans les retours que vous recevez. Voici les termes employés par ce validateur, définis une fois pour toutes. Lorsqu’une définition repose sur un document publié, la source figure en dessous.
- Registre d’informationRoI
- L’état structuré dans lequel une entité financière recense ses accords contractuels portant sur l’utilisation de services TIC fournis par des prestataires tiers, et qu’elle déclare à son autorité de surveillance. Ce n’est pas un document rédigé : c’est un ensemble de modèles tabulaires aux champs définis, avec des identifiants et des valeurs issues de listes fermées — c’est précisément ce qui permet de le contrôler mécaniquement.
- Règlement d’exécution (UE) 2024/2956la norme technique d’exécution
- La norme technique d’exécution qui fixe les modèles et le format de déclaration du registre d’information. C’est le texte sur lequel ce validateur est construit : la structure des modèles, la liste des champs et les formes déclarables en proviennent, ainsi que des documents publiés par l’ABE à ses côtés.
- Modèles RTRT.01.01 … RT.07.01
- Les modèles de déclaration qui composent le registre. Chacun correspond à une feuille du classeur, nommée d’après son code, et porte un ensemble de champs défini. RT.99.01 fait exception : c’est une légende d’options énumérant les valeurs autorisées, et non un modèle à déclarer. Le tableau plus bas recense tous les modèles connus du validateur ; il est généré à partir de la spécification, non saisi à la main.Le modèle de déclaration des AES comporte 14 modèles de déclaration, de RT.01.01 à RT.07.01, plus RT.99.01, qui est une légende d'options et non un modèle à déclarer.
- Modèle de donnéesDPM
- Le modèle de données de l’ABE, et la notation que parlent ses systèmes. Chaque modèle RT possède un équivalent DPM noté B_xx.xx, et chaque colonne un code noté c0010, c0020, etc. Vous regardez RT.05.01 ; le retour que vous recevez parle de B_05.01 c0010. C’est le même endroit. Chaque anomalie signalée par ce validateur affiche les deux notations, pour vous éviter la traduction.
- Paquet de reporting xBRL-CSV
- La forme que prend réellement une déclaration : non pas un tableur, mais une archive ZIP organisée selon une structure définie, contenant le registre sous forme de fichiers CSV et les métadonnées qui indiquent au système destinataire comment les lire. Le paquetage est une étape distincte de l’exactitude du contenu : un registre peut être parfaitement correct et échouer parce que le paquet ne l’est pas.Une déclaration est un paquet de reporting xBRL-CSV conforme à Report Package 1.0, contenant META-INF/reportPackage.json et un dossier reports. Voir la source
- UTF-8
- L’encodage de caractères qu’un paquet de reporting doit utiliser. Le détail compte plus qu’il n’y paraît : un nom d’entité accentué ou une espace insécable enregistrée depuis un tableur dans un encodage ancien est une cause fréquente de rejet d’un paquet pourtant correct à l’écran.Les rapports doivent utiliser l'encodage UTF-8. Voir la source
- Listes ferméesmenus déroulants, préfixe eba_
- De nombreux champs n’acceptent qu’une valeur issue d’une liste publiée : un pays, une devise, un type d’accord. Ces valeurs doivent être écrites sous la forme codée attendue par la taxonomie, et non avec les mots qu’emploierait un lecteur — c’est pourquoi un registre parfaitement lisible par une personne peut rester faux pour une machine.Les valeurs issues d'une liste fermée doivent être écrites avec le préfixe eba_, par exemple eba_CT:x12. Voir la source
- Identifiant d’entité juridiqueLEI
- Un code de 20 caractères identifiant une entité juridique, défini par la norme ISO 17442 : dix-huit caractères alphanumériques suivis de deux chiffres de contrôle. Ces chiffres se calculent à partir du reste du code par l’algorithme MOD 97-10 : une erreur de saisie peut donc être détectée hors ligne, sans demander à quiconque si le code existe. C’est exactement ce que fait ce validateur.
- GLEIF
- La Global Legal Entity Identifier Foundation, qui exploite la base des LEI émis. C’est la limite de ce qu’un outil hors ligne peut établir : un chiffre de contrôle prouve qu’un code est bien formé, non qu’il a été émis, ni qu’il est toujours actif. Un LEI structurellement valide mais absent de la base passera ici et pourra malgré tout être rejeté.Plusieurs contrôles publiés exigent qu'un LEI soit valide au regard de la base GLEIF, ce qu'aucun outil hors ligne ne peut établir. Voir la source
- EUIDdéfinition en attente de vérification
- L’identifiant unique européen, qui figure aux côtés du LEI dans les contrôles d’identifiants publiés par l’ABE. Sa définition complète et ses règles de validation ne sont pas encore adossées aux documents de spécification conservés dans ce dépôt : aucune règle ne le contrôle ici, et rien de plus n’est affirmé à son sujet.
- Règles de validation
- Les contrôles publiés auxquels un registre est soumis avant d’être accepté : contrôles techniques au niveau du fichier, contrôles au niveau du modèle, règles métier portant sur le contenu, et contrôles d’identifiants. Ce validateur en met en œuvre une partie et le dit : un résultat sans anomalie signifie que les contrôles exécutés n’ont rien relevé, non qu’une déclaration sera acceptée.L'ABE publie 120 contrôles pour la déclaration du registre d'information, répartis en quatre catégories : contrôles techniques, contrôles techniques DPM, règles de validation métier DPM et contrôles LEI/EUID. Voir la source
- Bloquant et avertissement
- La façon dont cet outil gradue ce qu’il trouve. Bloquant : la valeur est fausse en elle-même — un identifiant qui échoue à son chiffre de contrôle, un champ obligatoire laissé vide. Avertissement : quelque chose mérite un regard mais peut être légitime. Ce sont les mots de ce validateur pour ses propres constats, non une classification réglementaire, et chaque anomalie indique la règle et la source dont elle relève.
- Prestataire tiers de services TIC
- La contrepartie dont une entité financière consigne les services dans le registre — le côté fournisseur de l’accord. Une grande part du registre existe pour décrire qui elle est, ce qu’elle fournit et comment l’accord est structuré : d’où le poids des identifiants et des classifications en listes fermées dans le contenu.
- Autorité compétenteANC
- L’autorité nationale de surveillance à laquelle une entité financière transmet son registre. Laquelle, dans quelle fenêtre et par quel canal dépend de l’entité et de l’État membre ; ces questions relèvent de l’autorité elle-même, et ce site n’y répond pas à sa place.
Référence des modèles
Tous les modèles de déclaration reconnus par ce validateur, avec le code DPM sous lequel le même modèle apparaît dans les retours de validation. Généré à partir de la spécification : ce tableau ne peut pas diverger de ce que l’outil lit réellement.
| Modèle | Code DPM | Champs |
|---|---|---|
| RT.01.01 | B_01.01 | 6 |
| RT.01.02 | B_01.02 | 11 |
| RT.01.03 | B_01.03 | 4 |
| RT.02.01 | B_02.01 | 5 |
| RT.02.02 | B_02.02 | 18 |
| RT.02.03 | B_02.03 | 2 |
| RT.03.01 | B_03.01 | 2 |
| RT.03.02 | B_03.02 | 3 |
| RT.03.03 | B_03.03 | 2 |
| RT.04.01 | B_04.01 | 4 |
| RT.05.01 | B_05.01 | 9 |
| RT.05.02 | B_05.02 | 7 |
| RT.06.01 | B_06.01 | 10 |
| RT.07.01 | B_07.01 | 12 |