Outils personnels

SMIRK REF1201, le référentiel icqx@scheme

De documentation SEPAmail.

Cette page contient des modifications qui ne sont pas marquées pour la traduction.

SEPAmail – Norme 1206

Cette page fait partie de la version 1206 de la norme.

Sauf indication contraire, elle a été validée par les instances concernées et s'impose à tous les adhérents SEPAmail.
ATTENTION ! La version 1606 de la norme est disponible, vérifiez si cette page est toujours valable.


Principes généraux

Le référentiel des ICQX (icqx@scheme) contient tous les créanciers personnes morales inscrits auprès de SEPAmail, qu'ils soient « vi­sibles » par les débiteurs ou non.


Comme son nom l'indique, il est maintenu par le Scheme manager, ou par le QXOO (QX Operational Office).


Il est mis à jour à l'initiative de la banque du créancier, sur demande du créancier, que ce soit lors de la création de l'enregistrement (correspondant donc à une de­mande d'ICQX) ou lors d'un changement de contenu. Dans tous les cas, cette mise à jour passe par l'adhérent SEPAmail dont dépend le créancier, et est faite sous sa responsabilité.


Seuls les créanciers personnes morales peuvent être inscrits dans ce référentiel. Les personnes phy­siques ne sont inscrites dans aucun référentiel.


L'ICQX sert d'index dans ce référentiel. Il est unique pour un créancier donné, quels que soient les changements de situation qui puissent l'affecter (changement d'adresse, de nom, de banque ...). Le seul changement pouvant intervenir dans cet ICQX concerne le 7ème caractère (position 3 du business code), qui est laissé à la libre disposition du créancier. Dans le référentiel, ce caractère sera systématiquement forcé à 'Z'. En revanche, d'autres valeurs pourront être utilisées pour la recherche.


Lorsqu'un créancier est présent dans le référentiel, il peut « s'inscrire » à un ou plusieurs « services ». Ces services correspondent à tout ou partie d'une application SEPAmail, et seront par exemple :

  • RUBIS inscription
  • RUBIS émission
  • RUBIS réception
  • DIAMOND émission
  • GEMME émission
  • GEMME réception

Contenu du référentiel

Le référentiel contient tous les éléments relatifs à un créancier : éléments d'identification, éléments bancaires, éléments de communication avec les débiteurs et bien sûr éléments relatifs au référentiel lui-même.

Voici la liste détaillée de ces éléments :

1. Index

  • ICQX (avec le 3ème caractère du business code mis à 'Z')

2. Éléments de désignation

  • Nom (PartyName) [chaîne de 1 à 140 caractères]
  • Nom courant (DisplayName) [chaîne de 1 à 140 caractères]
  • Logo [image]
  • Vignette (thumbnail) [image]
  • Adresse postale [format ISO 20022]

3. Éléments d'identification [1]

[pour tous : type = chaîne (1 à 16 car) parmi une énumération ("SIRET", "SIREN" ... "Other"), valeur = chaîne de 1 à 35 caractères pouvant ou non avoir un format figé]

  • SIRET
  • SIREN
  • TVA intracommunautaire
  • autre (pour l'administration)
  • forme juridique
  • activité

4. Éléments bancaires

  • BIC (correspond au BIC de dernière mise à jour)

5. Éléments liés au référentiel

  • Dates de validité (début – fin, correspondant à la validité de l'ICQX) [2 dates format ISO]
  • Date de dernière mise à jour [format ISO]
  • Compte de test (booléen) (toujours égal à false dans l'usage actuel)

6. Éléments liés à un service (0 à N blocs possibles)

  • Nom du service («RUBIS  inscription » par exemple) [valeur dans une énumération]
  • Activité vis-à-vis de ce service (booléen)
  • Portée (locale ou globale) ["local" ou "global"]
  • QXBAN associé(s)
  • Communication avec débiteurs (0 à 3 identifiants possibles)
    • Nom de l'identifiant du débiteur [chaîne de 1 à 70 caractères]
    • Où et comment le trouver (texte et/ou image) [chaîne de 1 à 140 caractères + image]


Tous les éléments des blocs 1, 2, 4 et 5 sont obligatoires. Concernant ceux d'identification (bloc 3), au moins un des quatre premiers éléments doit être fourni, et plusieurs peuvent être présents (sauf SIRET et SIREN, qui sont exclusifs l'un de l'autre).


L'ensemble des éléments des blocs 1 à 5 constituent une structure dénom­mée ICQXCard, qui est transportée intégralement dans certains messages de gestion du référentiel, décrits plus loin dans ce document. Cette structure n'est utilisée nulle part ailleurs dans SEPAmail.


Les éléments liés à un service (bloc 6) constituent une ServiceCard. Chaque créancier enregistré dans le référentiel peut disposer de 0, une ou plusieurs ServiceCards.

La portée figurant dans une ServiceCard est à interpréter ainsi :

  • local : le pays du créancier (ou du QXOO local), correspondant au code pays figurant dans l'ICQX
  • global : tous les pays

Exemple

Un créancier qui envoie et reçoit des messages RUBIS, et qui accepte les messages d'inscription à ce service, aura un enregistrement comportant :

  • les blocs 1, 2, 4 et 5 complets
  • suffisamment d'éléments dans le bloc 3 pour que sa banque ait pu valider son identité
  • 3 ServiceCards (bloc 6), avec le champ "actif" à true dans les trois, et un ou plusieurs QXBAN dans chaque ServiceCard [2] :
    • une pour le service "RUBIS inscription", comportant au moins 1 et au plus 3 blocs "communication avec le débiteur"
    • une pour le service "RUBIS émission", sans blocs "communication avec le débiteur"
    • une pour le service "RUBIS réception", sans blocs "communication avec le débiteur"


Accès du client final aux données du référentiel

Toute banque adhérente à SEPAmail est tenue de donner accès aux données des blocs 1 à 3 à l'ensemble de ses clients SEPAmail.

Pour l'utilisation du service "RUBIS inscription", elles devront être complétées par les éléments "communication avec le débiteur" (contenues dans la ServiceCard, bloc 6) correspondantes.

L'affichage et les modes de recherche ne sont pas spécifiés par SEPAmail.

Utilisation du référentiel

À partir du moment où un créancier est inscrit dans ce référentiel, il se contente d'envoyer, dans les messages qu'il émet, son ICQX. La banque du débiteur peut alors consulter le référentiel, ou un mi­roir local qu'elle maintient à jour, pour obtenir toutes les informations nécessaires sur ce créancier et les présenter aux débiteurs.


Processus et messages autour du référentiel

Tous les messages relatifs à ce réferentiel appartiennent à l'écosystème scheme. Sauf mention contraire, l'adresse destinataire des messages à destination du Scheme sera ICQX@scheme.sepamail.eu ou ICQX@fr.scheme.sepamail.eu.

Les BIC correspondant à cette adresse [3] sont :

  • pour le QXOO, SKEMQX..XXX, où .. doivent être remplacés par le code du pays
  • pour le Scheme Manager, SKEMQXQXXXX

Création d'un créancier

Le créancier communique les informations de son ICQXCard à sa banque, sauf bien sûr l'ICQX [4].


La banque réalise les tests de vérification d'identité du créancier, qui sont de son entière res­ponsabilité.

  • S'ils sont négatifs, elle lui répond par un rapport négatif et le processus est terminé.
  • S'ils sont positifs, elle envoie cette ICQXCard au Scheme par le biais d'un mes­sage CreditorCreationRequest.
  • Le Scheme attribue un ICQX au créancier et répond à la banque par un CreditorCrea­tionReport positif[5] contenant cet ICQX. Ce créancier n'a aucun service associé lors de sa création.
  • La banque envoie alors au créancier un rapport positif, contenant au minimum son ICQX.

Le message CreditorCreationRequest peut donc être acheminé

  • par le créancier à sa banque s'ils utilisent les échanges SEPAmail
  • par la banque du créancier au Scheme


Obtention d'un ICQX

Rapport de création d'un créancier

Ce rapport est acheminé par un message CreditorCreationReport, qui peut être positif ou né­gatif. S'il est positif, ce message contient une ICQXCard complète.


S'il est négatif, le créancier n'est pas créé dans le référentiel du Scheme, et la procédure doit re­prendre au début, après correction des anomalies bien sûr.


Le message CreditorCreationReport peut donc être acheminé

  • par le Scheme à la banque du créancier
  • par la banque du créancier au créancier, s'ils utilisent les échanges SEPAmail

Mise à jour d'un créancier

Le processus de mise à jour d'un créancier est très similaire à celui de création : le créancier transmet les informations de mise à jour à sa banque – en cas de changement, à sa nouvelle banque.


La banque réalise les tests de vérification d'identité du créancier[6].

  • S'ils sont négatifs, elle lui répond par un rapport négatif et le processus est terminé.
  • S'ils sont positifs, elle envoie l'ICQXCard au Scheme par le biais d'un mes­sage CreditorUpdateRequest.
  • Le Scheme met à jour le référentiel et répond à la banque par un CreditorUpdateReport po­sitif[7].
  • La banque répond alors au créancier par un rapport positif, contenant au moins son ICQX.

Le message CreditorUpdateRequest peut donc être acheminé

  • par le créancier à sa banque s'ils utilisent des échanges SEPAmail
  • par la banque du créancier au Scheme

Rapport de mise à jour d'un créancier

Ce rapport est acheminé par un message CreditorUpdateReport, qui peut être positif ou né­gatif. De même que pour le rapport de création d'un ICQX, s'il est positif, ce message contient une ICQXCard complète.


Si le rapport est négatif, l'enregistrement du créancier dans le référentiel et l'ICQXCard sont in­changés.


Le message CreditorUpdateReport peut donc être acheminé

  • par le Scheme à la banque du créancier
  • par sa banque au créancier, s'ils utilisent des échanges SEPAmail

Diffusion d'information sur un créancier

Lorsqu'un créancier est prêt à émettre ou à recevoir les messages d'un service particulier, il est de la responsabilité de sa banque de transmettre cette information à l'ensemble du réseau SEPAmail.


Elle se fait par le biais d'un message CreditorActivationAdvise, qui contient l'ICQX du créancier et la ServiceCard concernée. Le même message permet aussi de suspendre l'activité d'un créancier sur un service spécifique.


Le message est adressé par la banque du créancier à toutes les autres banques et au Scheme, qui met à jour son référentiel à réception.

Demande de consultation du référentiel

Lorsqu'une banque reçoit un message, typiquement de l'écosystème Rubis, contenant un ICQX, elle peut consulter le Scheme pour obtenir les informations relatives au créancier détenteur de cet identifiant.


La consultation du référentiel sert également à la banque du débiteur pour mettre à disposition le service d'inscription RUBIS.


Ceci se fait par un message CreditorInformationRequest, mentionnant l'ICQX du créancier[8]. L'ICQX fourni peut contenir un caractère quelconque en position 7, il sera systématiquement forcé à 'Z' par le Scheme avant consultation du référentiel.


ICQXCARD-obtention.png

Réponse à consultation du référentiel

En réponse à un message CreditorInformationRequest, le Scheme répond par un message CreditorInformationReport, contenant l'ICQXCard complète du créancier, et l'ensemble des ServiceCards relatives à ce créancier.

Synchronisation du référentiel entre banques

Pour limiter les messages de consultation, il serait cohérent que chaque banque dispose d'un miroir local de son contenu. Les conditions exactes de constitution et de mise à jour de ce miroir restent à définir.

ICQX-service-inscription.png

Récapitulatif des messages créés

Messages Scheme

Nom du message Utilisation acteurs
CreditorCreationRequest Création d'un créancier Banque créancier ↔ Scheme
Créancier ↔ Banque créancier
CreditorCreationReport
CreditorUpdateRequest Mise à jour d'un créancier Banque créancier ↔ Scheme
Créancier ↔ Banque créancier
CreditorUpdateReport
CreditorInformationRequest Consultation du référentiel Banques ↔ Scheme
CreditorInformationReport

Des messages supplémentaires pourront être créés, notamment ceux gérant la réplication du référentiel dans les banques.

Messages interbancaires

Nom du message Utilisation acteurs
CreditorActivationAdvise Diffusion d'un service associé à un créancier Banque créancier → autres banques
Banque créancier → Scheme
PaymentActivationEnroll Inscription d'un débiteur (service RUBIS inscription) Banque débiteur → banque créancier

Phase transitoire

Pour accélérer la mise en place de ce système, sans la rendre dépendante de l'implémentation effective du référentiel et de l'écosystème correspondant, on peut à court terme travailler ainsi :

  • le référentiel est remplacé par une feuille de calcul maintenue par le Scheme
  • la feuille est envoyée par mail aux adhérents, une fois par jour, dès lors qu'il existe au moins une mise à jour
  • les messages d'inscription et de modification, ainsi que leurs rapports, sont remplacés par des formulaires papier. Ceux-ci seront supprimés au fur et à mesure de la disponibilité des messages SEPAmail correspondants.

  1. L'adresse internet du créancier n'est pas retenue ici, pour des raisons de reroutage et de mise à jour
  2. le même QXBAN peut être ou non utilisé pour plusieurs services. Par ailleurs, un service peut comporter plusieurs QXBAN – par exemple, pour le service RUBIS émission, il est possible qu'un créancier remette ses demandes de règlement sur plusieurs banques
  3. Ce sont en fait des pseudo-BIC, aucun enregistrement auprès de SWIFT n'est réalisé pour eux
  4. ceci peut ou non se faire par le biais d'un message CreditorCreationRequest, selon le mode de communication entre la banque et son client.
  5. sauf des éventuels cas d'erreur à définir dans une version ultérieure de la norme (créancier existant déjà ?)
  6. Ces tests sont les mêmes que lors d'une création, ils ne doivent pas être limités aux éléments mis à jour. La banque engage sa responsabilité sur l'ensemble des éléments fournis.
  7. sauf des éventuels cas d'erreur à définir
  8. on pourrait ajouter la date de la dernière mise à jour connue par la banque, afin de limiter le volume du message de retour (un simple « rien de neuf » suffirait alors). Est-ce utile ? À définir dans une version ultérieure de la norme, en conjonction avec les processus de synchronisation/miroir entre Scheme et banques

<languagues />