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.01RT.99.01Légende d’optionsDéfinitions des entités ayant recours aux services TICCe modèle reprend les explications, les significations et les définitions, internes à l’entité, de l’ensemble fermé d’indicateurs utilisé par l’entité financière dans le registre d’informations.RT.07.01 demande de qualifier l’incidence d’une interruption de service : faible, moyenne ou élevée. RT.99.01 est l’endroit où l’entité écrit ce qu’elle entend par « élevée ». Elle ne porte aucune donnée du registre : elle est la clé de lecture des réponses à listes fermées données ailleurs.Sans elle, un superviseur lisant « élevée » n’a aucun moyen de savoir ce que l’entité entendait par là.Fiche complète 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.01RT.05.01Prestataires tiers de services TICB_05.019 champsCe modèle énumère et fournit des informations générales permettant d’identifier: a) les prestataires tiers directs de services TIC; b) les prestataires de services TIC intra-groupe; c) tous les sous-traitants inclus dans le modèle B_05.02 qui font partie de la chaîne d’approvisionnement des services TIC; d) l’entreprise mère ultime des prestataires tiers de services TIC énumérés aux points a), b) et c).La liste des prestataires. Pour chacun : son code d’identification et le type de ce code, son nom, le pays de son siège, le coût annuel total et son entreprise mère ultime.Chaque code d’identification y est lu au regard du type de code qu’il déclare être.Fiche complète ; 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 (s’ouvre dans un nouvel onglet)
- 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 (s’ouvre dans un nouvel onglet)
- 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 (s’ouvre dans un nouvel onglet)
- 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 (s’ouvre dans un nouvel onglet)
- 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 (s’ouvre dans un nouvel onglet)
- Bloquant et avertissement
- Ce qu’il advient de votre dépôt, et non le degré de gravité que nous lui prêtons. Les deux mots sont ceux du régulateur : un contrôle technique en échec est une erreur qui fait rejeter le registre à l’arrivée, tandis qu’un contrôle métier ou d’identifiant produit un avertissement — le registre est accepté et il vous revient de corriger puis de redéposer. Chaque anomalie tient sa gravité du contrôle qu’elle met en œuvre, non d’une appréciation de notre part, et indique la règle et la source dont elle relève.Les contrôles techniques des AES sont des erreurs qui entraînent le rejet du registre déposé, tandis que les règles de validation métier DPM et les contrôles d’identifiants sont des avertissements : le registre est accepté, et l’entité est tenue de corriger puis de redéposer. Voir la source (s’ouvre dans un nouvel onglet)
- 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.
Modèles RT
Le registre n’est pas un document mais un ensemble de tableaux. Chacun correspond à une feuille du classeur des AES, nommée d’après son code, et porte un ensemble de champs défini. Ensemble, ils décrivent qui vous êtes, ce que vous avez contracté, auprès de qui, pour lesquelles de vos propres fonctions, et à quoi vous seriez exposé si le service s’arrêtait.
Un code se lit en trois temps. RT.05.02RT.05.02Chaîne d’approvisionnement des services TICB_05.027 champsCe modèle indique et relie les prestataires tiers de services TIC qui font partie de la même chaîne d’approvisionnement des services TIC.Le prestataire de paie d’une banque héberge ses données chez un fournisseur cloud, lequel recourt à une troisième société pour les sauvegardes. RT.05.02 consigne cette chaîne rang par rang — la partie du registre à laquelle la plupart des entités ne peuvent pas répondre avec leurs seuls contrats, la réponse étant chez le prestataire.La sous-traitance est l’endroit où surgit une dépendance que personne n’a contractée.Fiche complète est un modèle de déclaration, de la cinquième famille — celle des prestataires tiers de services TIC — et le deuxième modèle de cette famille. Les modèles d’une même famille partagent un sujet : RT.05.01RT.05.01Prestataires tiers de services TICB_05.019 champsCe modèle énumère et fournit des informations générales permettant d’identifier: a) les prestataires tiers directs de services TIC; b) les prestataires de services TIC intra-groupe; c) tous les sous-traitants inclus dans le modèle B_05.02 qui font partie de la chaîne d’approvisionnement des services TIC; d) l’entreprise mère ultime des prestataires tiers de services TIC énumérés aux points a), b) et c).La liste des prestataires. Pour chacun : son code d’identification et le type de ce code, son nom, le pays de son siège, le coût annuel total et son entreprise mère ultime.Chaque code d’identification y est lu au regard du type de code qu’il déclare être.Fiche complète recense les prestataires, RT.05.02 les chaînes d’approvisionnement dans lesquelles ils s’inscrivent.
Sélectionnez un code ci-dessous — ou n’importe où ailleurs sur ce site — pour obtenir la description officielle du modèle, un exemple d’usage et ce qui s’y joue.
| Modèle | Intitulé | Code DPM | Champs |
|---|---|---|---|
| RT.01.01RT.01.01Entité tenant le registre d’informationsB_01.016 champsCe modèle indique l’entité qui tient et met à jour le registre d’informations au niveau de l’entité ainsi qu’aux niveaux sous-consolidé et consolidé, respectivement.Un responsable conformité, dans une banque de taille moyenne, prépare la transmission. Avant toute chose, le fichier doit dire qui le dépose : le LEI de la banque, son pays, son type et l’autorité destinataire. Cette ligne unique, c’est RT.01.01.Si cette ligne est fausse, un registre par ailleurs correct est déposé au nom de la mauvaise entité.Fiche complète | Entité tenant le registre d’informations | B_01.01 | 6 |
| RT.01.02RT.01.02Liste des entités comprises dans le périmètre de consolidationB_01.0211 champsCe modèle indique toutes les entités appartenant au groupe. Lorsque l’entité financière responsable de la tenue et de la mise à jour du registre d’informations n’appartient pas à un groupe, seule cette entité financière est déclarée dans ce modèle.Un groupe d’assurance dépose un registre unique pour l’ensemble du groupe. RT.01.02 recense chaque entité du périmètre de consolidation — LEI, pays, entreprise mère, total de bilan — afin qu’un superviseur sache de quelles entités juridiques parle le reste du registre.Chaque LEI employé ailleurs dans le registre est censé avoir été déclaré ici d’abord.Fiche complète | Liste des entités comprises dans le périmètre de consolidation | B_01.02 | 11 |
| RT.01.03RT.01.03Liste des succursalesB_01.034 champsCe modèle indique les succursales des entités financières visées au modèle B_01.02.Une banque française exploite une succursale en Belgique. La succursale n’est pas une entité juridique distincte et n’a pas de LEI propre : elle ne peut donc pas figurer dans RT.01.02. C’est dans RT.01.03 qu’elle est nommée et rattachée à son siège.Déclarer une succursale comme s’il s’agissait d’une entité juridique est l’une des erreurs de structure les plus faciles à commettre.Fiche complète | Liste des succursales | B_01.03 | 4 |
| RT.02.01RT.02.01Accords contractuels — informations généralesB_02.015 champsCe modèle énumère tous les accords contractuels conclus avec des prestataires tiers directs de services TIC.L’équipe achats rassemble tous les contrats TIC en vigueur. Chacun reçoit ici un numéro de référence, avec l’indication qu’il est isolé ou rattaché à un accord-cadre, et son coût de l’exercice précédent.Les numéros de référence créés ici sont la clé qui relie entre elles la plupart des autres parties du registre.Fiche complète | Accords contractuels — informations générales | B_02.01 | 5 |
| RT.02.02RT.02.02Accords contractuels — informations spécifiquesB_02.0218 champsCe modèle fournit des détails sur chaque accord contractuel énuméré dans le modèle B_02.01 en ce qui concerne: a) les services TIC inclus dans le champ d’application de l’accord contractuel; b) les fonctions des entités financières soutenues par ces services TIC; c) d’autres informations importantes concernant les services TIC spécifiques fournis (par exemple: délai de préavis, droit régissant l’accord, etc.).Pour un même contrat cloud, c’est le formulaire détaillé : quelle entité l’utilise, quel prestataire le fournit, le type de service, les dates de début et de fin, les préavis de part et d’autre, le droit applicable, le lieu de stockage des données et leur sensibilité.Il porte plus de champs que tout autre modèle : c’est là que passe l’essentiel du temps de saisie.Fiche complète | Accords contractuels — informations spécifiques | B_02.02 | 18 |
| RT.02.03RT.02.03Liste des accords contractuels intra-groupeB_02.032 champsCe modèle indique les liens entre les accords contractuels intra-groupe et les accords contractuels conclus avec des prestataires tiers de services TIC qui ne font pas partie du groupe en utilisant les numéros de référence des accords contractuels lorsqu’une partie de la chaîne d’approvisionnement des services TIC est intra-groupe.Une filiale achète sa capacité de centre de données à sa propre maison mère, qui l’achète elle-même à un prestataire externe. RT.02.03 relie l’accord interne à l’accord externe.Sans lui, un accord intra-groupe paraît clore la chaîne d’approvisionnement alors qu’il ne la clôt pas.Fiche complète | Liste des accords contractuels intra-groupe | B_02.03 | 2 |
| RT.03.01RT.03.01Entités qui signent les accords contractuels pour la réception d’un ou de plusieurs services TIC ou pour le compte des entités ayant recours au(x) service(s) TICB_03.012 champsCe modèle fournit des informations sur l’entité qui signe les accords contractuels avec le prestataire tiers direct de services TIC pour le compte de l’entité ayant recours aux services TIC.Un groupe signe un contrat de façon centralisée et quatre filiales utilisent le service. RT.03.01 nomme l’entité qui a réellement apposé sa signature — souvent différente de celle qui utilise le service.Signer et utiliser sont deux actes distincts, et le registre les demande séparément.Fiche complète | Entités qui signent les accords contractuels pour la réception d’un ou de plusieurs services TIC ou pour le compte des entités ayant recours au(x) service(s) TIC | B_03.01 | 2 |
| RT.03.02RT.03.02Prestataires tiers de services TIC qui signent les accords contractuels pour la fourniture de services TICB_03.023 champsCe modèle indique tous les prestataires tiers de services TIC visés au modèle B_05.01 qui signent les accords contractuels visés au modèle B_02.01 pour la fourniture des services TIC.Le même contrat vu de l’autre côté : laquelle des entités juridiques du prestataire l’a signé. Un fournisseur contracte souvent par une filiale locale plutôt que sous le nom du groupe figurant sur la facture.L’entité juridique signataire n’est fréquemment pas la marque auprès de laquelle le service est acheté.Fiche complète | Prestataires tiers de services TIC qui signent les accords contractuels pour la fourniture de services TIC | B_03.02 | 3 |
| RT.03.03RT.03.03Entités signataires des accords contractuels pour la fourniture de services TIC à d’autres entités relevant du périmètre de consolidationB_03.032 champsCe modèle indique toutes les entités visées au modèle B_01.02 qui signent les accords contractuels visés au modèle B_02.01 pour la fourniture de services TIC à d’autres entités relevant du périmètre de consolidation.Le centre de services partagés d’un groupe fournit l’informatique à ses entités sœurs. Il est prestataire, et il appartient au groupe : RT.03.03 consigne sa signature pour fournir les autres.Un prestataire intra-groupe reste un prestataire, et l’omettre revient à sous-estimer les dépendances propres du groupe.Fiche complète | Entités signataires des accords contractuels pour la fourniture de services TIC à d’autres entités relevant du périmètre de consolidation | B_03.03 | 2 |
| RT.04.01RT.04.01Entités ayant recours aux services TICB_04.014 champsCe modèle indique toutes les entités qui utilisent les services TIC fournis par des prestataires tiers de services TIC et qui sont inscrites dans le registre d’informations.Un contrat, plusieurs utilisateurs. RT.04.01 répond à la question « qui consomme réellement ce service » : chaque entité, utilisateur direct ou succursale, rattachée au numéro de référence du contrat.C’est ce qui transforme une liste de contrats en cartographie des dépendances.Fiche complète | Entités ayant recours aux services TIC | B_04.01 | 4 |
| RT.05.01RT.05.01Prestataires tiers de services TICB_05.019 champsCe modèle énumère et fournit des informations générales permettant d’identifier: a) les prestataires tiers directs de services TIC; b) les prestataires de services TIC intra-groupe; c) tous les sous-traitants inclus dans le modèle B_05.02 qui font partie de la chaîne d’approvisionnement des services TIC; d) l’entreprise mère ultime des prestataires tiers de services TIC énumérés aux points a), b) et c).La liste des prestataires. Pour chacun : son code d’identification et le type de ce code, son nom, le pays de son siège, le coût annuel total et son entreprise mère ultime.Chaque code d’identification y est lu au regard du type de code qu’il déclare être.Fiche complète | Prestataires tiers de services TIC | B_05.01 | 9 |
| RT.05.02RT.05.02Chaîne d’approvisionnement des services TICB_05.027 champsCe modèle indique et relie les prestataires tiers de services TIC qui font partie de la même chaîne d’approvisionnement des services TIC.Le prestataire de paie d’une banque héberge ses données chez un fournisseur cloud, lequel recourt à une troisième société pour les sauvegardes. RT.05.02 consigne cette chaîne rang par rang — la partie du registre à laquelle la plupart des entités ne peuvent pas répondre avec leurs seuls contrats, la réponse étant chez le prestataire.La sous-traitance est l’endroit où surgit une dépendance que personne n’a contractée.Fiche complète | Chaîne d’approvisionnement des services TIC | B_05.02 | 7 |
| RT.06.01RT.06.01Identification des fonctionsB_06.0110 champsCe modèle indique les fonctions de l’entité financière ayant recours aux services TIC et fournit des informations sur elles.Avant de pouvoir évaluer un service, l’entité nomme ses propres fonctions — « exécution des paiements de détail », par exemple — et indique si chacune est critique ou importante, pourquoi, et combien de temps elle pourrait être interrompue. Les identifiants de fonction définis ici servent dans tout RT.02.02.Rien en aval ne peut être classé tant que les fonctions n’ont pas été nommées ici.Fiche complète | Identification des fonctions | B_06.01 | 10 |
| RT.07.01RT.07.01Évaluations des services TICB_07.0112 champsCe modèle recueille des informations relatives à l’évaluation des risques des services TIC (par exemple, la substituabilité, la date du dernier audit, etc.) lorsque ces services TIC soutiennent une fonction critique ou importante, ou une partie significative de celle-ci.Pour chaque service soutenant une fonction critique ou importante : ce prestataire est-il remplaçable, quand a-t-il été audité pour la dernière fois, existe-t-il un plan de sortie, le service pourrait-il être réinternalisé, un prestataire de remplacement a-t-il été identifié.Ce sont les appréciations qu’aucun prestataire ne peut porter à votre place.Fiche complète | Évaluations des services TIC | B_07.01 | 12 |
| RT.99.01RT.99.01Légende d’optionsDéfinitions des entités ayant recours aux services TICCe modèle reprend les explications, les significations et les définitions, internes à l’entité, de l’ensemble fermé d’indicateurs utilisé par l’entité financière dans le registre d’informations.RT.07.01 demande de qualifier l’incidence d’une interruption de service : faible, moyenne ou élevée. RT.99.01 est l’endroit où l’entité écrit ce qu’elle entend par « élevée ». Elle ne porte aucune donnée du registre : elle est la clé de lecture des réponses à listes fermées données ailleurs.Sans elle, un superviseur lisant « élevée » n’a aucun moyen de savoir ce que l’entité entendait par là.Fiche complète | Définitions des entités ayant recours aux services TIC | B_99.01 | non déclaré |
RT.99.01RT.99.01Légende d’optionsDéfinitions des entités ayant recours aux services TICCe modèle reprend les explications, les significations et les définitions, internes à l’entité, de l’ensemble fermé d’indicateurs utilisé par l’entité financière dans le registre d’informations.RT.07.01 demande de qualifier l’incidence d’une interruption de service : faible, moyenne ou élevée. RT.99.01 est l’endroit où l’entité écrit ce qu’elle entend par « élevée ». Elle ne porte aucune donnée du registre : elle est la clé de lecture des réponses à listes fermées données ailleurs.Sans elle, un superviseur lisant « élevée » n’a aucun moyen de savoir ce que l’entité entendait par là.Fiche complète fait exception dans le tableau ci-dessus. C’est une légende d’options, qui consigne ce que l’entité entend par les valeurs à liste fermée employées ailleurs — faible, moyenne, élevée — et non un modèle que l’on déclare. Il figure ici parce qu’il fait partie du classeur, et il est signalé parce qu’il ne porte pas de données du registre.
Les intitulés et les descriptions sont le texte de l’annexe I des NTE, dans les deux langues. Les codes et le nombre de champs sont générés à partir de la spécification : ce tableau ne peut pas diverger de ce que le validateur lit réellement.