Standards:IG mobility

L'écosystème mobility comporte quatre messages :

Message	MsgTyp
AccountSwitchingRequest	accountswitching.request@mobility
AccountSwitchingResponse	accountswitching.response@mobility
AccountSwitchingForward	accountswitching.forward@mobility
AccountSwitchingNotify	accountswitching.notify@mobility

Généralités et exemples

La plupart des messages acheminés dans cette application ayant été définis par le CFONB, le lecteur consultera utilement leur site public pour y consulter l'intégralité des documents.

En particulier, le document faisant référence pour la version 1606 de la Norme SEPAmail, en ce qui concerne les IG pour les messages SwitchingRequest, SwitchingResponse et SwitchingForward, est le Guide d'Utilisation des Messages pour la Mobilité Bancaire, rédigé par le CFONB, dans sa version 1.0, datée du 23 février 2016.

Il est accessible à partir de cette page.

Le message AIGUE-MARINE AccountSwitchingRequest

Ce message est envoyé par l'Établissement d'Arrivée (ÉA) à l'Établissement de Départ (ÉD). Il lui transmet les éléments du Mandat de Mobilité, et lui demande de communiquer les informations sur les opérations comprises dans le périmètre de la mobilité.

Le message a été spécifié par le CFONB, il est simplement inclus dans un message SEPAmail standard pour être transporté.

Le message AIGUE-MARINE AccountSwitchingResponse

Ce message est envoyé par l'Établissement de Départ (ÉD) à l'Établissement d'Arrivée (ÉA), en réponse à un message AccountSwitchingRequest.

Il contient :

• soit un rejet de la demande, auquel cas il en précise la raison
• soit une acceptation de la demande, auquel cas il contient également les informations sur les opérations contenues dans le périmètre de la mobilité.

Les règles d'usage de ce message sont les suivantes :

• Le nombre de messages AccountSwitchingResponse, en réponse à un seul message AccountSwitchingRequest, est laissé au choix de l'expéditeur (ÉD), et pourra donc être compris entre 1 et 4.
• Il doit impérativement y avoir, en cumul sur l'ensemble des messages d'envoi d'informations, 4 blocs d'informations : virements permanents émis, virements récurrents reçus, prélèvements reçus, chèques.
• Chaque message devra comporter au minimum un bloc
• Un bloc pour lequel il n'y a aucune information à transmettre devra néanmoins être présent dans un message, et renseigné à zéro.

Ce message a été spécifié par le CFONB, il est simplement inclus dans un message SEPAmail standard pour être transporté.

Le message AIGUE-MARINE AccountSwitchingForward

Ce message est envoyé par l'Établissement d'Arrivée (ÉA) vers chacun des Établissements d'Émetteurs (ÉÉ). Il reprend les informations obtenues de l'Établissement de Départ (ÉD) sur les opérations devant être modifiées par les émetteurs.

Le message a été spécifié par le CFONB, il est simplement inclus dans un message SEPAmail standard pour être transporté.

Le message AIGUE-MARINE AccountSwitchingNotify

Généralités

Ce message est envoyé par l'Établissement d'Émetteur (ÉÉ) à l'Établissement d'Arrivée (ÉA).

Il intervient obligatoirement en réponse à un message AccountSwitchingForward envoyé par l'ÉA.

Besoin fonctionnel

Même s'il n'est pas prévu dans le schéma de la Profession, ce flux retour est indispensable dans le cadre d'une messagerie correctement structurée. En effet, le destinataire d'un message doit au minimum disposer d'un moyen d'indiquer que le contenu d'un message n'est pas correct.

Nous ne parlons pas ici de réponse protocolaire ou technique, qui est assurée par la missive d'acquittement, mais bien d'une réponse métier.

Voici par exemple un cas dans lequel ce message est indispensable :

• si l'établissement d'émetteur reçoit un message pour un émetteur qu'il ne peut pas joindre, par exemple parce qu'il n'est plus parmi ses clients, alors qu'il est responsable de l'acheminement de l'information vers cet émetteur, il doit pouvoir informer l'ÉA, pour que celui-ci puisse éventuellement faire parvenir cette information à l'émetteur concerné et remplir ainsi son obligation légale.

Pour des raisons de responsabilité des uns et des autres, il est donc nécessaire d'avoir un flux retour.

Cas d'usage

Dans le cadre actuel, pour simplifier la mise en place du flux 4R, seuls les messages à l'initiative de l'ÉÉ sont prévus.

Voici les deux cas d'usage concernés :

• positif : message pouvant être transmis à l'émetteur
• négatif : message non transmis, pour une raison à préciser, par exemple
  • émetteur inconnu
  • émetteur non joignable

Fonctionnement du message

L'ÉÉ doit envoyer un et un seul message AccountSwitchingNotify par message AccountSwitchingForward reçu.

Il doit être envoyé aussitôt que possible, c'est-à-dire dès que les éléments internes à l'ÉÉ permettent de déterminer si l'émetteur est connu et si le message pourra lui être transmis.

Il n'est pas nécessaire que le message ait été effectivement envoyé à l'émetteur pour envoyer le message AccountSwitchingNotify positif.

Le délai opérationnel d'envoi du flux retour sera donc de deux jours ouvrables.

Contenu du message

Le contenu du message est extrêmement simple :

• le rappel des éléments de la demande, selon les principes de SEPAmail (messages auto-portés)
• une réponse, positive ou négative
• si elle est négative, éventuellement une précision sur son statut (pourquoi est-elle négative ?)

Rappelons que les éléments de nature commerciale, du genre "plus de relation entre l'émetteur et son client", doivent rester strictement dans la sphère des relations entre l'Émetteur et le Client.

Le message a été conçu selon les mêmes lignes que ceux du CFONB, en ajoutant simplement un bloc 2 au message AccountSwitchingForward que l'ÉÉ reçoit. Ce bloc 2 peut donc avoir deux contenus, selon que le message est positif ou négatif.

Dans le cas positif, le contenu est fixe (code de retour positif TS01), l'ÉÉ conservant la possibilité d'ajouter des précisions dans le champ AdditionalInformation.

Dans le cas négatif, le code de retour peut prendre l'une des 3 valeurs suivantes :

• BE01 (InconsistentWithEndCustomer, message incorrect)
• BE06 (UnknownEndCustomer, émetteur inconnu ou ne pouvant être joint)
• MS03 (NotSpecifiedReasonAgentGenerated, autres cas)

Voici le contenu de ce message :

• dans le cas positif
• dans le cas négatif

Extensions futures

Dans des versions ultérieures, explicitement exclues du périmètre actuel de SEPAmail, il pourrait être possible de prendre en compte d'autres cas d'usage de ce message, notamment à l'initiative de l'émetteur :

• le cas négatif
  • Client inconnu (ou plus de contrat en cours)
  • Modification déjà réalisée
• le cas positif
  • client identifié, modification réalisée

Schémas XML

Les schémas du CFONB sont disponibles sur cette page. Rappelons qu'ils concernent, pour la norme SEPAmail, les messages SwitchingRequest, SwitchingResponse et SwitchingForward.

Le schéma du quatrième message, SwitchingNotify, est accessible ici.

Enfin, voici les schémas XML de l'encapsulation SEPAmail des 4 messages de l'écosystème mobility.

Nom	Schéma
AccountSwitchingRequest	Schéma
AccountSwitchingResponse	Schéma
AccountSwitchingForward	Schéma
AccountSwitchingNotify	Schéma