ISO 15022-1:1999

NORME ISO
INTERNATIONALE 15022-1
Première édition
1999-03-01
Valeurs mobilières — Schéma des
messages (Dictionnaire des Champs de
Données) —
Partie 1:
Règles de construction des champs de
données et des messages et guide
d'utilisation
Securities — Scheme for messages (Data Field Dictionary) —
Part 1: Data field and message design rules and guidelines
Numéro de référence
©
ISO 1999
PDF – Exonération de responsabilité
Le présent fichier PDF peut contenir des polices de caractères intégrées. Conformément aux conditions de licence d'Adobe, ce fichier peut
être imprimé ou visualisé, mais ne doit pas être modifié à moins que l'ordinateur employé à cet effet ne bénéficie d'une licence autorisant
l'utilisation de ces polices et que celles-ci y soient installées. Lors du téléchargement de ce fichier, les parties concernées acceptent de fait la
responsabilité de ne pas enfreindre les conditions de licence d'Adobe. Le Secrétariat central de l'ISO décline toute responsabilité en la
matière.
Adobe est une marque déposée d'Adobe Systems Incorporated.
Les détails relatifs aux produits logiciels utilisés pour la création du présent fichier PDF sont disponibles dans la rubrique General Info du
fichier; les paramètres de création PDF ont été optimisés pour l'impression. Toutes les mesures ont été prises pour garantir l'exploitation de
ce fichier par les comités membres de l'ISO. Dans le cas peu probable où surviendrait un problème d'utilisation, veuillez en informer le
Secrétariat central à l'adresse donnée ci-dessous.
© ISO 1999
Droits de reproduction réservés. Sauf prescription différente, aucune partie de cette publication ne peut être reproduite ni utilisée sous quelque
forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie et les microfilms, sans l'accord écrit de l’ISO à
l’adresse ci-après ou du comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 56 � CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax. + 41 22 734 10 79
E-mail copyright@iso.ch
Web www.iso.ch
Version française parue en 2000
ImpriméenSuisse
ii © ISO 1999 – Tous droits réservés

Sommaire Page
Avant-propos.iv
Introduction.v
1 Domaine d'application.1
2 Références normatives .1
3 Termes et définitions.2
4 Syntaxe et format lexical de l'ISO 7775 améliorée .5
4.1 Principes de base .5
4.2 Jeux de caractères et format lexical.5
4.3 Structure des messages et règles de création.8
5 Dictionnaire des Champs de Données .15
5.1 Contenu .15
5.2 Accès au Dictionnaire des Champs de Données .16
5.3 Statut du Dictionnaire des Champs de Données .16
5.4 Relation EDIFACT — ISO 7775 améliorée .16
6 Catalogue des Messages .17
6.1 Contenu .17
6.2 Accès au Catalogue des Messages .19
6.3 Relation EDIFACT — ISO 7775 améliorée .20
Annexe A (informative) Guide de création des messages.21
Bibliographie .25
© ISO 1999 – Tous droits réservés iii

Avant-propos
L'ISO (Organisation internationale de normalisation) est une fédération mondiale d'organismes nationaux de
normalisation (comités membres de l'ISO). L'élaboration des Normes internationales est en général confiée aux
comités techniques de l'ISO. Chaque comité membre intéressé par une étude a le droit de faire partie du comité
technique créé à cet effet. Les organisations internationales, gouvernementales et non gouvernementales, en
liaison avec l'ISO participent également aux travaux. L'ISO collabore étroitement avec la Commission
électrotechnique internationale (CEI) en ce qui concerne la normalisation électrotechnique.
Les projets de Normes internationales adoptés par les comités techniques sont soumis aux comités membres pour
vote. Leur publication comme Normes internationales requiert l'approbation de 75 % au moins des comités
membres votants.
La Norme internationale ISO 15022-1 a été élaborée par le comité technique ISO/TC 68, Banque, valeurs
mobilières et autres services financiers, sous-comité SC 4, Valeurs mobilières et autres instruments financiers
concernés.
L'ISO 15022 annule et remplace l’ISO/TR 7775:1997 et l’ISO 11521:1996.
L'article 1 de la version française de la présente partie de l'ISO 15022 inclut le Rectificatif technique 1
[ISO 15022-1:1999/Cor.1:1999(E)] publié en anglais séparément.
L'ISO 15022 comprend les parties suivantes, présentées sous le titre général Valeurs mobilières — Schéma des
messages (Dictionnaire des Champs de Données):
� Partie 1: Règles de construction des champs de données et des messages et guide d'utilisation
� Partie 2: Mise à jour du Dictionnaire des Champs de Données et du Catalogue des Messages
L’annexe A de la présente partie de l’ISO 15022 est donnée uniquement à titre d’information.
iv © ISO 1999 – Tous droits réservés

Introduction
La présente partie de l’ISO 1522 remplace l’ISO/TR 7775, Valeurs mobilières — Types de messages,et
l’ISO 11521, Valeurs mobilières — Structure des messages type interdépositaires. Au milieu des années quatre-
vingt-dix, il était communément admis que les Normes internationales régulant la communication entre les acteurs
du secteur des valeurs mobilières devaient être rapidement révisées dans le but (1) de réduire le temps nécessaire
à la mise sur le marché des nouveaux types de message et (2) d’améliorer la capacité de traitement automatisé.
L’ISO 15022 définit les principes permettant de fournir aux différents groupes d’utilisateurs les outils de création
des types de message leur permettant de gérer leurs propres flux d’informations. Ces outils sont les suivants:
� un jeu de règles de création des messages et de la syntaxe;
� un dictionnaire des champs de données;
� un catalogue des messages actuels et futurs créés par ce secteur, comportant les champs et les règles
mentionnés ci-dessus.
Afin de répondre aux besoins évolutifs de ce secteur au fur et à mesure qu’ils apparaissent, le Dictionnaire des
Champs de Données et le Catalogue des Messages ne font pas partie de la norme: ils sont disponibles auprès
d’un Organisme d’enregistrement qui, le cas échéant, les met à jour à la demande des acteurs de ce secteur.
Pour préserver les investissements déjà effectués par ce secteur, la syntaxe proposée dans la présente partie de
l’ISO 15022, appelée “syntaxe de l'ISO 7775 améliorée”, s’inspire de la syntaxe utilisée pour les anciennes
ISO 7775 et ISO 11521. Toutefois, pour assurer la promotion et la publicité d’EDIFACT (Electronic Data
Interchange For Administration, Commerce and Transport), une autre norme a été élaborée par les Nations Unies,
adoptée par l’ISO en 1988 sous le nom de ISO 9735 et recommandée comme étant la Norme internationale en
matière d’échange électronique de données: l'ISO 15022 gère également la syntaxe EDIFACT. Pour savoir quels
pays utilisent ou pourraient utiliser EDIFACT, l’Organisme d’enregistrement doit répertorier les champs et
messages EDIFACT à utiliser par les acteurs du secteur des valeurs mobilières. Le Dictionnaire des Champs de
Données de l'ISO 15022 montre comment formater chaque élément de données requis dans les messages de
valeurs mobilières, à la fois dans la syntaxe de l'ISO 7775 améliorée et dans la syntaxe EDIFACT. De même, le
Catalogue des Messages présente des messages structurés selon les règles de création et la syntaxe de
l'ISO 7775 améliorée et d’EDIFACT.
L'ISO 15022 présente
� les règles de création des messages et la syntaxe de l'ISO 7775 améliorée;
� l’organisation du Dictionnaire des Champs de Données et du Catalogue des Messages;
� les niveaux de service et les procédures de l’Organisme d’enregistrement, y compris son contrôle par l’ISO.
La syntaxe EDIFACT à laquelle ce document fait référence est décrite dans l'ISO 9735.
La souplesse de cette nouvelle structure doit permettre aux groupes de ce secteur d’élaborer des messages dans
une langue internationale et de migrer éventuellement vers EDIFACT, à une vitesse qui répond à l’urgence de
leurs besoins. Si aucun des messages enregistrés dans le Catalogue des Messages ne répond à leurs exigences,
les groupes de ce secteur seront à même de se mettre d’accord sur l’utilisation d’un nouveau message et de créer
celui-ci à partir des champs approuvés de l'ISO 7775 améliorée et/ou de la syntaxe EDIFACT. L’Organisme
d’enregistrement créera les champs supplémentaires requis et enregistrera les nouveaux types de message et
leurs versions dans le Catalogue des Messages, afin d’éviter que des groupes différents ne présentent les mêmes
requêtes. L’Organisme d’enregistrement veillera à ce que les nouveaux champs et les nouveaux messages soient
disponibles dans les formats ISO 7775 améliorée et EDIFACT.
© ISO 1999 – Tous droits réservés v

Le traitement automatisé sera sans doute amélioré, puisque chaque groupe d’utilisateurs pourra définir clairement
ses propres exigences professionnelles et créer des versions de type de message adaptées aux marchés. Cette
approche diffère des messages internationaux de type générique définis jusqu’à présent par l’ISO. En effet, ces
derniers n’identifiaient pas clairement les particularités de chaque marché et subordonnaient donc les interfaces de
communication à d’autres règles qui devaient être approuvées bilatéralement par les expéditeurs et les
destinataires.
Bien que cette nouvelle structure autorise plusieurs versions du même type de message, il est probable que les
acteurs des différents marchés limiteront naturellement la création des messages à ce qui est réellement
indispensable, jusqu’à ce qu’une plus grande convergence des pratiques des marchés permette de développer de
véritables Normes internationales en la matière, favorisant le traitement automatisé. De même, il est probable que
les acteurs des marchés conduiront naturellement à migrer vers EDIFACT, à un rythme approprié. La double
structure du Dictionnaire des Champs de Données et du Catalogue des Messages facilitera la migration et le
développement de tous les mécanismes de conversion nécessaires.
NOTE L'ISO 15022 vise non seulement à intégrer, mais aussi à être compatible avec, les précédentes ISO 7775 et
ISO 11521 portant sur les messages propres aux valeurs mobilières telles qu’elles ont été mises à jour par l'ISO/TR 7775. Par
conséquent, le Dictionnaire des Champs de Données et le Catalogue des Messages tiennent compte des champs de données
et des messages de l'ISO/TR 7775. Toutefois, certains des anciens champs et messages ne sont pas entièrement conformes à
la syntaxe de l'ISO 7775 améliorée, et aucun n’est conforme à EDIFACT. De plus, le dictionnaire initial des champs de données
comprend les dictionnaires de données de l’ISITC (Industry Standardization for Institutional Trade Communications), DSTU
1/1995, et du SSAB (Securities Standards Advisory Board).
Une liste des normes liées à la présente partie de l'ISO 15022 est donnée dans la bibliographie.
vi © ISO 1999 – Tous droits réservés

NORME INTERNATIONALE ISO 15022-1:1999(F)
Valeurs mobilières — Schéma des messages (Dictionnaire des
Champs de Données) —
Partie 1:
Règles de construction des champs de données et des messages
et guide d'utilisation
1 Domaine d'application
La présente partie de l'ISO 15022 présente
� une description des règles de création des messages et de la syntaxe de l'ISO 7775 améliorée;
� le contenu et l’organisation du dictionnaire des champs de l'ISO 7775 améliorée et EDIFACT pour les
messages relatifs aux valeurs mobilières;
� le contenu et l’organisation du catalogue des messages relatifs aux valeurs mobilières élaborés à partir des
syntaxes de l'ISO 7775 améliorée et EDIFACT.
Si nécessaire, elle se réfère à la syntaxe EDIFACT afin de faciliter les références croisées entre les concepts
spécifiques à l'ISO 7775 améliorée et ceux propres à EDIFACT. La présente partie de l'ISO 15022 ne décrit pas la
syntaxe EDIFACT: cette dernière est définie dans l'ISO 9735 à laquelle il est fait référence ici.
La présente partie de l'ISO 15022 concerne l’échange électronique de données entre les acteurs du secteur des
valeurs mobilières, indépendamment de tout réseau de communication. Ainsi, les règles permettant de définir la
manière et le moment où le message doit être envoyé, les accusés de réception et la protection des messages ne
font pas partie du domaine d’application de la présente partie de l'ISO 15022 car elles dépendent du réseau.
La mise à jour de la présente partie de l'ISO 15022 est décrite dans la partie 2 de l'ISO 15022.
La présente partie de l'ISO 15022 contient des éléments de données liés à des dates où l'année est formatée en
moins de quatre chiffres. Le format de ces éléments de données sera considéré, et si nécessaire amendé, à
l'occasion de la prochaine révision. En attendant, il est recommandé que les utilisateurs considèrent, dans le
contexte de leur mise en application de la présente partie de l'ISO 15022, toutes prescriptions d'amendement en
relation avec l'an 2000 et leur environnement des affaires.
2 Références normatives
Les documents normatifs suivants contiennent des dispositions qui, par suite de la référence qui y est faite,
constituent des dispositions valables pour la présente partie de l'ISO 15022. Pour les références datées, les
amendements ultérieurs ou les révisions de ces publications ne s’appliquent pas. Toutefois, les parties prenantes
aux accords fondés sur la présente partie de l'ISO 15022 sont invitées à rechercher la possibilité d'appliquer les
éditions les plus récentes des documents normatifs indiqués ci-après. Pour les références non datées, la dernière
édition du document normatif en référence s’applique. Les membres de l'ISO et de la CEI possèdent le registre des
Normes internationales en vigueur.
ISO/CEI 646, Technologies de l'information — Jeu ISO de caractères codés à 7 éléments pour l'échange
d'informations.
© ISO 1999 – Tous droits réservés 1

ISO 8859-1, Technologies de l'information — Jeux de caractères graphiques codés sur un seul octet — Partie 1:
o
Alphabet latin n 1.
ISO 9735 (toutes les parties), Échange de données informatisé pour l'administration, le commerce et le transport
(EDIFACT) — Règles de syntaxe au niveau de l'application.
ISO/CEI 10646-1, Technologies de l'information — Jeu universel de caractères codés à plusieurs octets —
Partie 1: Architecture et table multilingue.
Il est également fait référence à l'ISO/TR 7775, qui renvoie au rapport technique (type 2) 7775. Ce document
contient tous les types de messages figurant dans l'ISO 7775 et l'ISO 11521, telles que mises à jour et complétées
par l’Agence de mise à jour de l'ISO 7775 jusqu’à septembre 1994.
3 Termes et définitions
Pour les besoins de la présente partie de l'ISO 15022, les termes et définitions suivants s'appliquent.
3.1
bloc de champs de données
jeu prédéfini et identifié de champs de données dont les fonctions sont en rapport les unes avec les autres et ayant
trait à un concept industriel ou commercial
NOTE Un bloc de champs de données est identifié par un début et une fin de bloc, comportant chacun le nom du bloc, qui
décrit sa signification propre. Le bloc de champs de données peut se répéter, de même qu’inclure d’autres champs de données,
par emboîtement.
3.2
groupe d’utilisateurs
institutions financières partageant les mêmes pratiques de marché et utilisant les mêmes normes pour leurs
messages
3.3
composant
élément de données simple faisant partie d’un élément de données composé et identifié par sa position dans cet
élément
3.4
élément de données composé
élément de données contenant plusieurs composants
3.5
élément de données
donnée dont l’identification, la description et la valeur ont été précisées
NOTE Dans certains contextes, l’élément de données est considéré comme indivisible.
3.6
attribut d’élément de données
�EDIFACT uniquement� identificateur unique d’un élément de données dans un répertoire d’éléments de données
EDIFACT (voir attribut de champ)
3.7
champ de données
un champ de données se compose d’un attribut de champ suivi d’une donnée
NOTE Il sert à transmettre un élément de données simple ou composé représentant une information significative.
2 © ISO 1999 – Tous droits réservés

3.8
donnée
expression d’un élément de données simple ou composé dans un format spécifique et identifié par l’attribut de
champ qui précède
3.9
code du créateur de modèle de données
chaîne de caractères servant à identifier l’institution ou l’organisation de marché possédant le modèle de données
3.10
sous-code du créateur de modèle de données
identification du modèle de données du créateur de modèle de données
3.11
modèle de données
un modèle de données se compose de deux sous-champs: le code du créateur du modèle et le sous-code du
créateur du modèle. Ces sous-champs permettent d’identifier dans l'attribut d’un champ de données le modèle
propriétaire de la donnée
3.12
champ de données discret
champ de données exprimant une donnée particulière
NOTE L’attribut d’un champ de données discret n’a pas besoin de qualificatif précisant la signification de la donnée.
3.13
attribut de champ
chaîne de caractères unique identifiant la signification, le format et la valeur de la donnée qui suit (voir attribut
d’élément de données)
NOTE L’attribut de champ est constitué d’un type de champ, éventuellement suivi d’un qualificatif et d’un modèle de
données.
3.14
type de champ
chaîne de caractères unique commençant par l’attribut du champ et identifiant le format et la valeur de la donnée
NOTE Il identifie également la signification de la donnée qui suit (voir champ de données discret) ou sa classe (voir champ
de données générique).
3.15
champ de données générique
champ de données servant à exprimer les données d’une famille ou d’une classe d’éléments de données de même
nature, comme des dates ou des montants
NOTE L’attribut d’un champ de données générique contient un qualificatif indiquant la signification exacte de la donnée qui
suit.
3.16
groupe de segments
�EDIFACT uniquement� regroupement de segments identifiés et pouvant généralement être répétés
3.17
message
ensemble de champs de données et/ou de blocs de champs de données qui, échangés d’une partie à une autre,
permettent de communiquer des informations significatives
NOTE Dans EDIFACT, il s’agit d’un jeu de segments classés selon l’ordre indiqué dans le répertoire des messages
EDIFACT, commençant avec un en-tête et finissant avec une fin de message.
© ISO 1999 – Tous droits réservés 3

3.18
code du message
chaîne de caractères unique identifiant le type du message
3.19
descripteur de message
chaîne de caractères précisant le domaine d’application du message et les champs à même d’être utilisés
NOTE Le descripteur de message se compose du code du message, éventuellement suivi d’un numéro de version et d’un
sous-format de version de message.
3.20
type de message
jeu de données ou d’éléments de données identifié et structuré servant à communiquer des informations relatives
à un domaine d’application particulier
3.21
code du créateur de version de message
chaîne de caractères servant à identifier l’institution ou le segment de marché qui possède le sous-format de
versiondumessage
3.22
sous-code du créateur de version de message
identification du sous-format de la version de message correspondant au créateur de version de message
3.23
sous-format de version de message
un sous-format de version de message se compose de deux sous-champs: le code du créateur de version de
message et le sous-code du créateur de version de message. Ces sous-champs permettent d’identifier dans le
descripteur de message le sous-format propriétaire
3.24
segment emboîté
�EDIFACT uniquement� segment directement lié à un autre dans un groupe de segments identifié et structuré
répondant aux exigences d’un type de message particulier
3.25
élément de données qualifié
élément de données dont la signification exacte est précisée par le qualificatif qui lui est associé
3.26
segment qualifié
�EDIFACT uniquement� segment dont la signification exacte est précisée par le qualificatif qui lui est associé
3.27
qualificatif
élément de données dont la valeur, représentée par un code, donne une signification particulière à la fonction d’un
autre élément de données, donnée ou segment
3.28
segment répété
�EDIFACT uniquement� segment pouvant se répéter dans un message, comme précisé dans les spécifications du
type de message correspondant
3.29
segment
�EDIFACT uniquement� jeu prédéfini et identifié de valeurs d’éléments de données dont les fonctions sont en
rapport les unes avec les autres
NOTE Un segment commence par un attribut et se termine par un symbole de terminaison.
4 © ISO 1999 – Tous droits réservés

3.30
attribut de segment
�EDIFACT uniquement� élément de données simple identifiant de façon unique un segment
3.31
séparateur
caractère(s) utilisé(s) pour la séparation syntaxique des données
3.32
séquence
ensemble de champs de données prédéfini donné uniquement à titre informatif
3.33
élément de données simple
élément de données constitué d’une seule valeur
3.34
sous-champ
sous-division ou sous-partie d’un élément de données composé, d’un attribut de champ ou d’un descripteur de
message
3.35
numéro de version
permet de gérer simultanément plusieurs versions d’un type de message
4 Syntaxe et format lexical de l'ISO 7775 améliorée
4.1 Principes de base
Les messages élaborés en conformité avec l'ISO 7775 améliorée qui font partie du Catalogue des Messages
obéissent aux principes de base ci-dessous:
� les messages doivent être indépendants de tout système ou réseau;
� il convient que leur domaine d’application ne dépende ni de l’expéditeur ni du destinataire;
� il convient qu'un attribut de champ identifie de façon unique la donnée qui suit, indépendamment du type de
message ou de la position du champ de données dans le message.
4.2 Jeux de caractères et format lexical
La présente partie de l'ISO 15022 prend en charge les champs de données qui respectent les jeux de caractères
ci-dessous:
� ISO/CEI 8859-1 (Latin 1);
� ISO/CEI 8859-1, qui se compose de 191 caractères graphiques et gère tous les caractères des langues
suivantes: danois, néerlandais, anglais, féroïen, finnois, français, allemand, islandais, irlandais, italien,
norvégien, portugais, espagnol et suédois;
� ISO/CEI 10646-1 (UCS, Universal Multiple-Octet Coded Character Set). Ce jeu de caractères gère la plupart
des langues non latines;
� binaire.
© ISO 1999 – Tous droits réservés 5

4.2.1 Précision du format lexical
Le format d’un champ et ses composants sont documentés de la façon suivante:
Restrictions de longueur nn 1 caractère minimum et
nn caractères maximum
nn! nombre fixe de caractères
nn-nn fourchette de caractères
nn*nn nombre maximum de lignes � nombre maximum de
caractères par ligne
Type de caractères n chiffres
d chiffres avec virgule décimale
s signe + ou - (si facultatif, aucun signe sous-entend une
valeur positive)
h majuscules hexadécimales
a lettres majuscules
c caractères majuscules alphanumériques
e espace blanc
y caractères ISO 9735 majuscules (UNOA - jeu de
caractères de niveau A)
z caractères ISO/CEI 8859-1 (Latin 1)
u ISO/CEI 10646-1 (USC, Universal Multiple-Octet Coded
Character Set)
bbinaire
“/” caractère tel quel, ou
“text” texte tel quel
La plupart des données figurant dans le Dictionnaire des Champs de Données acceptent les lettres et autres
caractères minuscules, ainsi que les caractères majuscules alphanumériques. Ce sont des données de type z,
c’est-à-dire qu’elles peuvent contenir des caractères de l'ISO/CEI 8859-1 (Latin 1), identique à la liste de codes
UNOC d’Edifact. Certains réseaux n’acceptent qu’une partie de ces caractères. Les jeux partiels acceptables de
type Latin 1 sont les suivants:
� ISO/CEI 646 Avec une option propre aux USA. Il s’agit d’un jeu de caractères codé sur 7 bits.
Les codes imprimables allant de 32 à 127 sont les mêmes que ceux de Latin 1;
� ISO 9735 Liste de codes UNOA d’Edifact - Jeu de caractères de niveau A (code existant ‘y’). Il s’agit
également de la Police internationale de caractères du télex;
� ISO 9735 Liste de codes UNOB d’Edifact- Jeu de caractères de niveau B. Lettres majuscules et minuscules;
� jeu de caractères S.W.I.F.T;
� page de codes 1252 de Windows - Latin 1 de Windows (ANSI); c'est en fait une version élaborée de
ISO/CEI 8859-1.
6 © ISO 1999 – Tous droits réservés

4.2.2 Séparateurs
En plus du jeu de caractères permettant de définir les champs de données, des caractères de contrôle doivent
séparer les éléments suivants:
� les champs de données dans un message (séparateur de champ);
� l’attribut d’un champ et la donnée (séparateur d’attribut);
� les sous-champs d’une donnée, d’un attribut de champ ou d’un descripteur de message (séparateur de
sous-champ).
De même, s’il est nécessaire d’inclure un caractère de contrôle dans le texte, celui-ci doit être précédé d’un
caractère de libération le signalant comme texte. Il convient que le caractère de libération lui-même soit également
précédé d’un autre caractère de libération s’il doit être traité comme du texte.
Les séparateurs et caractères de libération définis sont les suivants:
� séparateur de champ CRLF (retour de chariot-saut de ligne)
� séparateur d’attribut “:” (deux-points) (lorsqu’ils ne sont pas de nouveau suivis par «:» ou le
second “/” après “::”
� séparateur de sous-champ “/”, ou “::” dans un attribut de champ
� caractère de libération “?”
Par ailleurs, la fin d’un message est signalée par un délimiteur de message dont le format est CRLF “-” (retour de
chariot-saut de ligne-signe moins).
Voir l’exemple en 4.3.2.1.
4.2.3 Notation utilisée
Les notations ci-dessous permettent de décrire l’utilisation des sous-champs, champs de données, séquences de
champs de données ou blocs de champs de données. Elles permettent également de décrire la structure et
l’utilisation ou le format des champs de données et des messages.
Le nom d’un élément ou l’ensemble d’éléments est généralement encadré par “<….>” (les caractères ne
faisant pas partie du message).
Si, dans un champ, un caractère ou un sous-champ est facultatif, il figurera entre crochets “[…]” (les caractères [ et
] ne faisant pas partie du message).
Les autres éléments (par exemple, un élément extrait d’un ensemble d’éléments) sont séparés par le signe “|” (le
caractère | ne faisant pas partie du message).
Les exemples ci-dessous illustrent ces points.
EXEMPLE 1 2!z[1n]
signifie que le champ est long de 2 caractères de type Latin 1, ou de 2 caractères suivis d’un chiffre.
EXEMPLE 2 3!c[“/”3!c[“/”8z]]
signifie que le format peut être divisé en trois parties (sous-champs) séparées par des “/”, et comprendre
sous-champ 1 uniquement 3!c
sous-champs 1 & 2 3!c“/”3!c
ou sous-champs 1, 2 & 3 3!c“/”3!c“/”8z
NOTE Dans cet exemple, le sous-champ 3 peut comprendre n’importe quel caractère de type Latin 1, tandis que les
sous-champs 1 et 2 peuvent uniquement comprendre des caractères majuscules alphanumériques.
© ISO 1999 – Tous droits réservés 7

EXEMPLE 3 |
EXEMPLE 4 [[|]]
signifie soit séquence A; séquence A, B; séquence A, B, C soit séquence A, B, D.
4.2.4 Définition des nombres
Les nombres sont souvent indiqués au format d. Ce format rend obligatoire l’usage d’un séparateur décimal
(comme la virgule) et d’un chiffre au moins avant la virgule. Les zéros sont autorisés, quelle que soit leur place.
Exemples de formats valides:
123, 12,3 0,123 123 456, 123,0
001 23,
Exemples de formats non valides:
123 12.3 .123 ,123
123 456, 123.456, 123,456,
4.3 Structure des messages et règles de création
Cette partie décrit les différents composants d’un message et la façon dont ceux-ci peuvent se combiner entre eux.
Chaque message comprend
� un descripteur de message;
� un certain nombre de champs de données et/ou de blocs de champs de données;
� un délimiteur de message.
L’en-tête du message, qui contient le descripteur de message, et la fin du message, qui contient le délimiteur de
message, dépendent d’un système, d’un réseau ou d’un moyen de transmission et, à ce titre, ne font pas partie de
la présente partie de l'ISO 15022. Toutefois, les descripteur et délimiteur d’un message font partie de la présente
partie de l'ISO 15022.
L’ordre dans lequel les champs ou blocs de champs de données d’un message sont créés n’a pas d’importance.
Cela n’aura aucun impact sur la signification du message.
4.3.1 Descripteur de message
Le contenu de chaque message doit être précédé d’un descripteur de message. Ce dernier définit le domaine
d’application du message, les champs qui peuvent être précisés et leurs conditions d’utilisation.
Le descripteur de message doit figurer dans l’en-tête. Il se compose de trois sous-champs au maximum: un code
de message, un numéro de version facultatif et un sous-format de version de message également facultatif.
La séquence suivante est recommandée:
[ [
[]]]
au format suivant:
3!c [“/”3!c[“/”4!c[4c]]]
8 © ISO 1999 – Tous droits réservés

Le code du message (3!c) renvoie à un type de message qui définit son domaine d’application (un ordre d’achat,
par exemple).
Le numéro de version (“/”3!c) permet de gérer plusieurs versions du type de message simultanément. Il définit les
champs de données qui peuvent être utilisés pour ce type de message. Si aucun numéro de version ne figure dans
le descripteur de message, il s’agira, par défaut, de la version numéro “000”. Il est à remarquer qu’il n’existe pas
nécessairement de type et de version de message génériques comprenant toutes les autres versions en cours.
Le sous-format de version de message facultatif (“/”4!c[4c]) permet de créer des sous-formats propriétaires pour
affiner la version d’un type de message, par exemple en indiquant quelles autres contraintes ou directives
générales s’appliquent. 521/005/ISIT1997 peut ainsi indiquer que le message qui suit constitue la version 5 du
message de type 521, utilisée conformément aux exigences définies par l’ISITC en 1997. Il est à remarquer que le
sous-format représente une variante définie par l’utilisateur de la version d’un type de message et qu’il doit, à ce
titre, être entièrement compatible avec cette dernière.
4.3.1.1 Sous-formats de version de message
L’Organisme d’enregistrement mettra à jour la liste des codes des créateurs de versions de message. Dans cette
liste, les codes sont constitués de quatre caractères identifiés de façon unique. Dans la mesure du possible, un
code correspond aux quatre premiers caractères du code BIC de l’institution financière demandant
l’enregistrement. Si aucun code BIC n’est disponible, les codes des créateurs de version de message sont créés
par l’Organisme d’enregistrement.
Une fois son code enregistré, le créateur peut ensuite créer ses propres sous-formats, en les identifiant par ce
code, éventuellement suivi d’un sous-code de quatre caractères qu’il choisit et qui doit être unique. L’Organisme
d’enregistrement s’assurera de la conformité des sous-formats avec la version de message correspondante. Les
sous-formats de version de message sont accessibles par n’importe quel utilisateur.
4.3.1.2 Numéro de version
Tout nouveau message est associé à un numéro de version. Par défaut, tous les messages existants
(c’est-à-dire les messages relevant de l'ISO/TR 7775) ont le numéro “000”.
Comme mentionné ci-dessus, le type du message (par exemple MT 521) identifie le domaine d’application, mais
pas le format du message. Ainsi, MT521 signifie simplement “réception contre paiement” et MT521/000 renvoie au
format ISO/TR 7775 du MT521.
Le numéro de version a une double utilité; il sert à
� identifier la nouvelle version d’une version existante qui sera éliminée après une période de transition. Ainsi,
les utilisateurs de MT 521/067 peuvent décider d’adopter un nouveau format pour la réception contre
paiement, qui sera appelé 521/089;
� identifier les formats de message utilisés par les différents groupes d’utilisateurs d’un même domaine
d’application. Par exemple, MT521/008 est la version actuellement utilisée par les dépositaires européens,
521/004 celle de l’ICSD (International Central Securities Depositories), 521/154 celle de CREST, etc.
Les versions sont décrites dans le Catalogue des Messages. Elles ne sont pas propriétaires, c’est-à-dire que tout
le monde peut les utiliser. Ainsi, à partir de l’exemple ci-dessus, DTC peut commencer à utiliser la version 521/154
sans l’autorisation de CREST.
Un groupe d’utilisateurs ne peut pas définir plusieurs versions du même type de message (excepté dans le cas
d’une transition vers une nouvelle version, comme expliqué ci-dessus). S’il veut préciser davantage les
modifications de format nécessaires dans certaines situations, ces “sous-formats” peuvent être identifiés dans le
troisième sous-champ du descripteur du message (c’est-à-dire le sous-format de version de message). Les
sous-formats de version de message sont répertoriés, mais pas décrits, dans le Catalogue des Messages. Pour
que le sous-format soit bien identifié de façon unique, le code du créateur de version de message doit être
enregistré auprès de l’Organisme d’enregistrement.
© ISO 1999 – Tous droits réservés 9

EXEMPLE:
� 521/007/ISIT0001 est le sous-format de 521/007, enregistré par l’ISITC pour une instruction de réception contre paiement;
� 521/023/DAKV est le sous-format de 521/023 enregistré par Deutsche Börse Clearing pour une instruction de réception
contre paiement;
� 521/004/CEDE0041 est le sous-format enregistré par la Cedel Bank pour une instruction de réception contre paiement
entre deux clients de Cedel;
� 521/004/CEDE0061 est le sous-format enregistré par la Cedel Bank pour une instruction de réception contre paiement
entre un client de Cedel et SICOVAM.
NOTE Tous les sous-formats d’une version de message doivent être entièrement compatibles avec le format maître de la
version, ce qui n’est pas le cas des différentes versions d’un type de message, qui ne sont généralement pas complètement
compatibles entre elles.
4.3.2 Champ de données
Un champ de données se compose d’un attribut de champ, suivi d’un séparateur d’attribut et de la donnée.

Un champ de données ne fait normalement référence qu’à un seul élément de données ou, éventuellement, à
plusieurs éléments de données liés, lorsque que ceux-ci doivent être combinés afin de constituer une information
significative. Par exemple, jour + mois + année de règlement doivent être combinés pour constituer le champ de la
date de règlement. De même, le montant de règlement s’obtient à partir de la devise et de la somme d’argent,
cette dernière, à elle seule, ne signifiant rien. En revanche, en tant qu’unités significatives, la date et le montant de
règlement peuvent être utilisées séparément et donc figurer dans des champs de données distincts.
Un champ de données n’apparaît généralement qu’une seule fois au sein d’un message s’il ne fait pas partie d’un
bloc.
Pour les nouveaux champs de données, l’attribut de champ définit de façon unique le format, les valeurs possibles
et la signification de la donnée qui suit.
L’attribut de champ et la donnée peuvent chacun être divisés en sous-champs.
4.3.2.1 Attribut de champ et séparateur d’attribut
L’attribut de champ identifie de façon unique l’objet et le format de la donnée qui suit. Il peut contenir jusqu’à trois
sous-champs, selon le type du champ de données.
� Champ de données discret
L’attribut de champ se compose uniquement d’un type de champ.
, au format suivant:
“:”2!c[1c] “:”
� Champ de données générique
L’attribut de champ se compose de deux ou trois sous-champs: un type de champ, un qualificatif et, dans certaines
circonstances, un modèle de données.
[ de modèle de données>[]], au format
suivant:
“:”2!c[1c] “::” 4!c “/” [4!c[4c]] “/”
10 © ISO 1999 – Tous droits réservés

Le type de champ (“:”2!c[1c]) identifie soit un champ spécifique (champ de données discret), soit une classe de
champs (champ de données générique). Il tient compte des attributs de champ de l'ISO/TR 7775. Le plus souvent,
un champ de données générique renvoie à une date ou à un tiers.
Le qualificatif (4!c) est un mot code de quatre caractères. Le plus souvent, les qualificatifs correspondant au champ
générique Date identifient divers types de date, comme la date de la transaction, la date du règlement ou la date
du coupon.
L’Organisme d’enregistrement mettra à jour la liste des modèles de données, lesquels sont définis de façon
unique. Le modèle de données (4!c[4c]) ne peut être utilisé que pour certains champs de données génériques (voir
le Dictionnaire des Champs de Données). Il qualifie la donnée qui suit.
EXEMPLE 1
Le champ de données discret de début de bloc comporte un champ de type:16R, qui peut être utilisé comme suit:
:16R:BLOCKNAME1 pour le début d’un bloc appelé BLOCKNAME1.
EXEMPLE 2
Le champ de données générique Date/Heure comporte un champ de type:98a, qui peut être utilisé comme suit:
:98A::TRAD//19980302 pour la date de transaction du 2 mars 1998
:98A::SETT//19980305 pour la date de règlement du 5 mars 1998
EXEMPLE 3
Le champ de données générique Tiers comporte un champ de type :95a. L’option de format P indique le code d’identification de
la banque du tiers, tandis que l’option R permet de préciser un code propriétaire (c’est-à-dire propre au créateur), comme suit:
:95P::BUYR//CITIGB2L pour l’acheteur des valeurs mobilières Citibank à Londres.
:95R::BUYR/XISM/12345678 pour l’acheteur des valeurs mobilières identifié par le code propriétaire
12345678 attribué par l’ISMA.
4.3.2.2 Statut des champs de données
Dans un message, un champ de données peut avoir l’un des statuts ci-dessous. Ces statuts sont répertoriés dans
le Catalogue des Messages.
— O obligatoire;
— C conditionnel: le champ de données peut être requis ou non, ou bien non autorisé, selon les
circonstances définies dans le Catalogue des Messages;
— F facultatif: le champ de données doit figurer lorsque l’information sous-jacente existe et est connue de
l’expéditeur. Toutefois, le message reste compréhensible sans sa présence.
4.3.2.3 Sous-champ d’une donnée
À l’intérieur d’un champ, la donnée peut être divisée en plusieurs sous-champs.
Tous les sous-champs sont séparés par des séparateurs de sous-champ, sauf lorsque le sous-champ se compose
d’une devise et d’un montant, par exemple
USD123,45
JPY10015,
Le sous-champ d’une donnée peut être un “mot code”, une “valeur structurée” ou un “texte non structuré”.
© ISO 1999 – Tous droits réservés 11

Un mot code est constitué de quatre caractères majuscules alphanumériques (par exemple 4!c).
Les valeurs structurées peuvent être des dates, des nombres entiers ou des sommes d’argent. Elles sont souvent
soumises à des restrictions quant aux valeurs maximum et minimum qu’elles peuvent prendre et à la place de la
virgule décimale.
Il n’est pas conseillé d’inclure des champs de texte non structuré, car ceux-ci empêchent souvent le traitement
automatisé.
Le sous-champ d’une donnée peut être
� obligatoire;
� conditionnel: le sous-champ peut être requis ou non, ou bien non autorisé, selon les circonstances définies
dans le Catalogue des Messages;
� facultatif: le sous-champ doit figurer lorsque l’information sous-jacente existe et est connue de l’expéditeur.
Toutefois, le message reste compréhensible sans sa présence.
Si une donnée est constituée de trois sous-champs facultatifs, A, B et C respectivement, leur présence doit être
signalée dans le champ correspondant par des séparateurs. Les séparateurs de fin sont omis.
EXEMPLE
“x/y/z” signifie que A, B et C sont présents et qu’ils ont les valeurs x, y et z respectivement;
“x/y” signifie que seuls A et B sont présents et qu’ils ont les valeurs x et y respectivement, C étant absent;
“x//y” signifie que seuls A et C sont présents et qu’ils ont les valeurs x et y respectivement, B étant absent;
“/x/y” signifie que B et C sont présents et qu’ils ont les valeurs x et y respectivement, A étant absent;
“x” signifie que seul A est présent et qu’il a la valeur x, B et C étant absents;
“/x” signifie que seul B est présent et qu’il a la valeur x, A et C étant absents;
“//x” signifie que seul C est présent et qu’il a la valeur x.
4.3.3 Blocs de champs de données
Les blocs de champs de données servent le plus souvent à préciser une séquence répétée ou apparentée de
champs de données. Par exemple, dans un relevé de compte, les informations relevant de chaque avoir peuvent
être organisées en bloc. De même, une liste de numéros de certificats pourra être considérée comme un bloc.
Un bloc de champs de données comprend les éléments suivants:
� un champ de début de bloc;
� un certain nombre de champs de données et/ou de blocs de champs de données;
� un champ de fin de bloc.
Cela sous-entend que les blocs peuvent être emboîtés les uns dans les autres. En revanche, s’ils peuvent être
récurrents dans un message, ils ne peuvent être définis de façon récursive, c’est-à-dire qu’un bloc ne peut s’inclure
lui-même.
S’il est nécessaire de répéter un champ de données dont la signification est identique au sein d’un message, ce
champ doit être inséré dans un bloc.
12 © ISO 1999 – Tous droits réservés

-----------------
...