Guide d utilisation du standard ISO POUR DES REMISES INFORMATISEES D ORDRES DE PRELEVEMENTS SEPA

Transcription

1 Guide d utilisation du standard IS PUR DES REISES INFRATISEES D RDRES DE PRELEVEENTS SEPA essage «Customer Direct Debit Initiation» <pain > Ce guide comprend l acquisition du Prélèvement SEPA («SDD Core») et du Prélèvement SEPA Interentreprises («SDD B2B») Version : 1.1 Date : Avril 2010 Statut : Validé Guide d utilisation du CustomerDirectDebitInitiation - V1.1 04/2010 Page 1

2 SAIRE 1. PRINCIPES GENERAUX DES ESSAGES IS PURQUI UN GUIDE D UTILISATIN PRESENTATIN DES GUIDES D UTILISATIN INTRDUCTIN A XL PERIETRE DE LA FAILLE «PAYENTS» DES STANDARDS IS REFERENCES NRATIVES ET DCUENTS SUPPRTS CNTRAT BILATERAL STANDARD ET PRTCLES NTATINS ADPTEES Les statuts de données Les index de données REGLES GENERALES DE TRNCATURE CARACTERES AUTRISES FRAT DES NTANTS FICHIER ET ESSAGE REGLES PARTICULIERES DES RDRES DE PRELEVEENTS SEPA (SDD CRE) ET SEPA INTERENTREPRISES (SDD B2B) PERIETRE FNCTINNEL DE CE GUIDE SCHEA DE REFERENCES RAPPEL SUR LES CARACTERES AUTRISES LA STRUCTURE DU ESSAGE REGRUPEENT DES PERATINS DES DE CPTABILISATIN DES PERATINS LES DIFFERENTS INTERVENANTS DANS LE TRAITEENT DES PRELEVEENTS SEPA Du côté du «Crédit» Du côté du «Débit» Spécificités liées aux tiers créancier et tiers débiteur PRINCIPES DE REFERENCEENT Les références techniques Les références fonctionnelles ou comptables La référence de bout en bout <EndToEndId> (EndToEndIdentification) (2.31) Les références commerciales IDENTIFICATIN DU SERVICE ASSCIE AU PRELEVEENT ET DE LA NATURE DE L PERATIN Identification du type de service attaché au lot de prélèvements - PaymentTypeInformation» (index 2.6) Identification de la nature du prélèvement - Purpose (index 2.76) LE NTANT DECLARATIN A LA BALANCE DES PAIEENTS L IDENTIFIANT CREANCIER SEPA (ICS) AUTRES IDENTIFIANTS NN BANCAIRES LA DEATERIALISATIN DES DNNEES DU ANDAT LES ISES A JUR RELATIVES AU ANDAT PRINCIPES DE RESTITUTINS GUIDE SPECIFIQUE GENERALITES GUIDE SPECIFIQUE ANNEXES ANNEXE 1 : historique des versions ANNEXE 2 : EXEPLES XL.. 37 ANNEXE 3 : EXEPLE DE ANDAT Guide d utilisation du CustomerDirectDebitInitiation - V1.1 04/2010 Page 2

3 AVIS AUX LECTEURS Ce guide est réalisé sur la base de la version parue en avril 2009 et entrée en vigueur en novembre 2009 du message IS pain En cas de nouvelle version IS de ce message sans évolution fonctionnelle significative, ce guide ne sera pas systématiquement réactualisé. Guide d utilisation du CustomerDirectDebitInitiation - V1.1 04/2010 Page 3

4 1. Principes généraux des messages IS Pourquoi un guide d utilisation Comme pour tout standard générique ouvert, la mise en œuvre des nouveaux standards IS nécessite des précisions consignées dans des guides d utilisation (à l instar des «essage Implementation guidelines» d EDIFACT). La finalité de ces guides est de limiter les différentes interprétations possibles et les nombreuses options du standard IS qui pourraient conduire à des mises en œuvre divergentes dans les systèmes des banques, des entreprises et dans les solutions des éditeurs. De ce fait, ces guides apportent des recommandations complémentaires tout en respectant le standard IS De plus, les standards IS vont coexister avec d autres standards au moins dans un premier temps. Cette coexistence va nécessiter de mettre en œuvre des règles de transformation d un standard à un autre. Pour éviter à chaque banque de définir ses propres règles et ainsi de risquer des incohérences, ces guides présentent des recommandations de gestion de cette phase transitoire Présentation des guides d utilisation Tous les guides d utilisation des messages financiers IS produits par le Groupement des Utilisateurs Français de SWIFT (GUF) se composent des trois parties suivantes : - les règles générales qui ont un caractère transversal sans s appliquer directement à un message en particulier, - les règles particulières contiennent d une part la définition fonctionnelle du message, d autre part des précisions sur les règles d'utilisation des données. - Un descriptif technique détaillant le mode d utilisation de la structure du message et des données sous forme de guides spécifiques à chaque type d opérations Introduction à XL En 1999, SWIFT a adopté la syntaxe XL pour tous les développements de nouveaux standards. Le choix de la syntaxe XL répond tout d abord à une volonté de disposer d une syntaxe plus souple et plus facile à maintenir. C est aussi un choix d adoption d une syntaxe non-propriétaire et largement utilisée aussi bien par les éditeurs de logiciels que par d autres communautés d acteurs. En effet, XL est la syntaxe privilégiée pour les échanges entre applications et dans le monde Internet. Qu est ce qu XL? XL, extensible arkup Language, est un métalangage universel et standardisé par le World Wide Web Consortium (W3C) pour la représentation textuelle de données structurées, déchiffrable par l homme et par des programmes. XL est une syntaxe composée de balises extensibles. Il permet à chacun de représenter ses données selon le périmètre et le besoin qu il entend couvrir en créant les balises appropriées. XL est une syntaxe de structuration de documents qui différencie contenu, structure et présentation en séparant ces trois fonctions dans trois documents distincts. Guide d utilisation du CustomerDirectDebitInitiation - V1.1 04/2010 Page 4

5 Les règles de présentation La structure de données Le contenu Ainsi XL est entouré de nombreux autres standards comme XSL pour la présentation des documents, les schémas pour la formalisation des modèles de document. La finalité des documents SWIFT étant le traitement automatique par des applications, SWIFT n a pas recours aux règles de présentation qui concernent l affichage des données. Les balises ou «tags» La syntaxe XL utilise des balises (ou «tags») pour structurer les données. Une balise commence par le caractère < et se termine par le caractère >. Toute balise ouvrante doit obligatoirement être fermée plus loin dans le message par une balise fermante du même nom. Par exemple la balise <Address> est une balise ouvrante alors que la balise </Address> est une balise fermante. Une balise fermante commence par les deux caractères </. Toute donnée est ainsi encapsulée entre une balise ouvrante <balise> et une balise fermante </balise> (Sachant qu'une donnée peut éventuellement être un ensemble d'éléments XL). Ex : <PostCode>75002</PostCode> Imbrication des balises XL Une règle importante est la règle d'imbrication des balises XL. Si à une balise ouvrante correspond une balise fermante, les balises ne peuvent en aucun cas se chevaucher. L exemple suivant n'est pas correct : <PostalAddress> <StreetName>18 rue La Fayette <PostCode>75009 <TownName>PARIS </PostalAddress> </StreetName> </PostCode> </TownName> Les balises doivent obligatoirement être imbriquées les unes dans les autres. Au contraire de l'exemple précédent, celui qui suit est syntaxiquement correct : <PostalAddress> <StreetName>18 rue La Fayette </StreetName> <PostCode>75009</PostCode> <TownName>PARIS</TownName> </PostalAddress> Guide d utilisation du CustomerDirectDebitInitiation - V1.1 04/2010 Page 5

6 Enfin, tout message XL doit et ne peut avoir qu'une seule balise racine. Toutes les autres balises du message devront être contenues dans la balise racine <Document>. Les attributs XL Une balise XL peut posséder un ou plusieurs attributs. L'attribut fournit un complément d'information associé à la balise en question. Un attribut de balise est constitué de deux parties : un nom et une valeur. La valeur doit être comprise soit entre des simples cotes soit entre guillemets. De plus, le nom est séparé de la valeur par le signe d'égalité. <TagName attribut1="valeur1">donnée du tag</tagname> : <Amt> <InstdAmt Ccy="EUR"> </InstdAmt> </Amt> La structure d un document contenu XL Un document contenu XL est structuré en 3 parties : La première partie, appelée prologue permet d'indiquer la version de la norme XL utilisée pour créer le document (cette indication est obligatoire) ainsi que le jeu de caractères (en anglais encoding) utilisé dans le document. Ainsi le prologue est une ligne du type <?xml version="1.0" encoding="utf-8"?> Le prologue se poursuit avec des informations facultatives sur des instructions de traitement à destination d'applications particulières. Leur syntaxe est la suivante : <?instruction de traitement?> Le second élément est une déclaration de type de document (à l'aide d'un fichier annexe de type Schéma ou de type DTD - Document Type Definition). L IS a retenu les déclarations de type schéma qui sont plus descriptives que les DTD. Cette déclaration permet de faire référence au modèle de document utilisé pour la création de ce message. <Document xmlns="urn:is:xsd:$pain " xmlns:xsi=" xsi:schemalocation="urn:is:xsd:$pain $pain xsd"> Et enfin la dernière composante d'un fichier XL est l'arbre des éléments qui constitue le cœur du document lui-même. Il contient les différentes balises décrivant le document. Le schéma de modélisation La description des modèles de document IS en XL est réalisée au sein de schémas. Un schéma utilise un langage de description spécifique (XSD). Les schémas permettent de décrire les balises qui sont présentes dans le document, la structure et l enchaînement de ces balises (hiérarchie des balises) ainsi que les codes autorisés pour certaines données, le nombre d occurrences possibles, la présence obligatoire ou facultative de certaines données Guide d utilisation du CustomerDirectDebitInitiation - V1.1 04/2010 Page 6

7 Un langage de balise : <adresse> <rue>18 rue La Fayette</rue> < cp >75009</ cp > <ville>paris</ville> </adresse> Le contenu Un langage de spécification de structure : < xs : complextype name =" adresse "> Les schémas < xs : sequence > < xs : element name =" rue " type=" ax70text " minccurs =" 0 " maxccurs =" 2 " /> < xs : element name =" cp " type=" ax6text " minccurs =" 1 " maxccurs =" 1 " /> < xs : element name =" ville " type=" ax70text " minccurs =" 1 " maxccurs =" 1 " /> </ xs : sequence > </ xs : complextype > Le dictionnaire Pour élaborer les nouveaux standards en XL appliqués aux messages financiers, une méthode de modélisation fonctionnelle des besoins a été mise en place en s appuyant sur des standards reconnus. Dans cette méthode est définie l utilisation d un dictionnaire, appelé IS Registry, dans lequel sont stockés tous les standards aussi bien de données que de processus métiers. L objet de ce dictionnaire est de recenser les données utilisées dans les standards IS et d éviter toute duplication. Le dictionnaire de données est utilisé dans la construction des schémas dans la mesure où les noms des balises hiérarchisées dans les schémas proviennent obligatoirement du dictionnaire. Le Registry contient différents niveaux de maturité des standards : Provisionnaly registered : en attente de validation Registered : validé et actif bsolete : standard à ne plus utiliser, mais conservé encore quelques temps dans la base. La gestion de ce dictionnaire a été confiée à SWIFT qui est la «Registration Authority», l autorité d enregistrement. Remarque : SWIFT dispose également depuis longtemps d un dictionnaire qui lui est propre, le SWIFT Standards Financial Dictionary. Ce dictionnaire a été, et est encore utilisé par SWIFT, pour les projets qui ne sont pas encore acceptés au niveau IS Il peut être utilisé par les personnes actives dans les groupes de standardisation pour avoir connaissance de l existant, mais il ne devrait progressivement plus être utilisé par les utilisateurs de standards IS Périmètre de la famille «payments» des standards IS A la date de publication de ce guide, les standards IS disponibles portant sur les paiements couvrent les échanges Client-Banque, la relation Banque-Banque et la relation Banque-Client pour les Credit Transfers, les Direct Debits et le reporting général sur le compte. Les différents messages sont représentés dans l illustration ci-après : Guide d utilisation du CustomerDirectDebitInitiation - V1.1 04/2010 Page 7

8 Credit Transfer Initiation R essages and Status Exceptions & Investigations Advice & Statement Cash management Change/Verify Account Identification Bank Account management Direct Debit Initiation R essages and Status Advice & Statement Exceptions & Investigations Cash management E-andates Change/verify Account Identification Debtor s financial institution Direct Debits / Credit Transfers R essages and Status Exceptions & Investigations Cash anagement E-andates Change/Verify Account Identification Creditor s financial institution IS Candidate IS (in development) Debtor Creditor NB : Toutes les potentialités de ces nouveaux standards ne seront effectives qu'à compter du moment où elles auront été mises en œuvre par les différents acteurs Références normatives et documents supports Ces guides s appuient sur les standards et la documentation IS ainsi que sur les travaux connexes à ces standards. URL des organismes travaillant sur le sujet IS : SWIFT : (Renvoi vers IS 20022) World Wide Web Consortium (W3C) schémas et datatypes les structures Interactive Financial exchange Forum : Treasury Integration Standards Team : pen Applications Group (AGi) : European payments council Contrat bilatéral Lorsque deux parties (banque et client) décident de s échanger électroniquement des informations dans le cadre de la mise en œuvre d un service, elles signent préalablement un contrat bilatéral. Ce contrat définit l ensemble des spécificités commerciales, techniques, juridiques, etc., convenues bilatéralement entre les deux parties. Il porte notamment, ces points n étant pas définis par ailleurs, Guide d utilisation du CustomerDirectDebitInitiation - V1.1 04/2010 Page 8

9 sur les protocoles de transport des données, sur d éventuels cut-off-times pour traitement des données reçues ainsi que sur l environnement en matière de sécurité. Les guides d utilisation ne représentent donc qu une des composantes du contrat bilatéral Standard et protocoles Le standard de message spécifié dans ce guide d utilisation est totalement indépendant du protocole d'échange. Ainsi, le message défini peut être échangé avec les protocoles SWIFT (FileAct, InterAct) mais aussi avec d autres protocoles d'échanges (EBICS, Etebac 5, ) Notations adoptées Les statuts de données Le caractère obligatoire ou non d une donnée ou d un groupe de données est défini par un statut. Les messages normalisés par l IS ne prévoient que deux statuts qui sont «obligatoire» et «facultatif». Le statut «facultatif» prévu dans les définitions de messages normalisés IS a été redéfini plus précisément de façon à ne laisser aucune ambiguïté sur l utilisation des objets (groupes de données, données) dans les guides d utilisation des messages XL élaborés sous l égide du Groupement des Utilisateurs Français de SWIFT (GUF). Le caractère obligatoire ou facultatif est représenté sous la forme suivante qui précise le nombre d occurrences minimales et maximales : [0..1] : l élément est présent 0 ou 1 fois. Il est donc facultatif [0..n] : l élément est présent 0 ou n fois. Il est donc facultatif [1..1] : l élément est présent 1 fois. Il est donc obligatoire [1..n] : l élément est présent 1 ou n fois. Il est donc obligatoire. L interprétation du statut des données est également conditionnée par l élément «r». Par exemple, la présence de «r» pour plusieurs sous-éléments rattachés à un même élément avec un statut [1...1] signifie que un et un seul élément doit être renseigné Les index de données Chaque donnée répertoriée dans les standards de messages IS est indexée par un numéro. Ce numéro est attribué en séquence. Il est composé de deux nombres séparés par un point (x.yy). Le premier nombre correspond au numéro de niveau du message (cf. chapitre structure du message). Le second est le numéro de la donnée dans le niveau correspondant. Ainsi, la première donnée du premier niveau aura un index Règles générales de troncature Si les données d éléments de messages au standard IS doivent être exploitées par d autres standards, les règles habituelles de cadrage à appliquer sont : de cadrer à gauche les zones alphanumériques et de les compléter à droite par des blancs si besoin, de cadrer à droite les zones numériques et de les compléter à gauche par des zéros si besoin. Quand la zone émettrice est de taille supérieure à celle de la zone réceptrice, les zones alphanumériques sont tronquées à droite et les zones numériques sont tronquées à gauche. Les exceptions à ces règles, si elles existent, sont précisées dans la description détaillée (chapitre 3) Caractères autorisés Les caractères autorisés dans les messages IS sont ceux de la norme UTF8. Cependant, les banques françaises se limitent au jeu de caractères latins, composé de : Guide d utilisation du CustomerDirectDebitInitiation - V1.1 04/2010 Page 9

10 a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L N P Q R S T U V W X Y Z / -? : ( )., + Espace Néanmoins, d autres caractères comme les caractères accentués (é, è, ê, â...) ou des caractères particuliers (@) peuvent être échangés sous réserve d accord bilatéral entre la banque et son client. Ces caractères spécifiques peuvent faire l objet d une convention par la banque d exécution avant l échange interbancaire. Par contre, les caractères qui ne font partie ni des caractères latins cités ci-dessus ni d une convention avec la banque d exécution sont des caractères interdits. Il est recommandé de ne pas utiliser des caractères tels que le «&» de «Père & Fils» ou «<» ou «>». L utilisation de tels caractères peut amener des rejets des messages. IPRTANT : Il faut respecter la nomenclature des «Data Type» : - ettre des majuscules pour les codes, exemple «HIGH» pour InstructionPriority. - ettre des minuscules pour les Indicators, exemple «false» pour Batchbooking Format des montants - Le montant est exprimé en chiffres sans virgule, espace, autre signe ou lettre. - Le séparateur des décimales est représenté par un point. - Il n est pas obligatoire de renseigner les décimales non significatives (par exemple peut être renseigné par ) - 5 décimales maximum après le point - La longueur maximale d un montant est de 18 caractères (séparateur de décimale compris) - Le nombre de décimales doit être compatible avec la norme IS 4217 relative aux devises. Pour les montants d une longueur supérieure à 14 caractères, le client devra impérativement vérifier auprès de sa banque s ils peuvent être traités Fichier et message Les échanges électroniques entre l entreprise et la banque peuvent être effectués soit sous forme de message soit sous forme de fichier. Le fichier est utilisé pour tout transfert suivant un protocole de transfert de fichier. Il correspond à une entité physique regroupant un ou plusieurs messages. Le message est soit un élément du fichier, soit un élément d échange à part entière dans le cadre d une relation interactive. Lorsque le client remet ses ordres de paiement ou de prélèvement sous forme de fichier à la banque, celle-ci définira dans son contrat d échange quelles sont les modalités de regroupement des messages dans le fichier. Compte tenu des différentes combinaisons possibles, chaque banque, au travers d un contrat bilatéral, aura préalablement convenu avec son client des caractéristiques de regroupement des opérations par nature, service et autre afin de garantir une homogénéité de traitement par message ou par fichier Guide d utilisation du CustomerDirectDebitInitiation - V1.1 04/2010 Page 10

11 2. Règles particulières des rdres de Prélèvements SEPA (SDD Core) et SEPA interentreprises (SDD B2B) 2.1. Périmètre fonctionnel de ce guide Ce guide décrit le format d acquisition d ordres de prélèvements SEPA. Il permet à un créancier (donneur d'ordre) de donner une instruction à sa banque sur la base d un mandat (entre le créancier et le débiteur) pour effectuer un prélèvement sur le compte d un débiteur. Les comptes du créancier et du débiteur doivent être localisés dans la zone SEPA. Deux instruments de prélèvement domestique européen ont été définis : Le prélèvement SEPA Le prélèvement SEPA interentreprises Ces deux instruments utilisent le même format de message d acquisition. A titre de comparaison, le format actuellement utilisé en France pour ce type d instruction est le format CFNB 160 prélèvement. Remarques importantes : Ce guide s appuie sur : o la version pain du message IS CustomerDirectDebitInitiation. o la version 4.0 du Rulebook et des Implementation Guidelines «SDD Core» de l EPC o la version 2.0 du Rulebook et des Implementation Guidelines «SDD B2B» de l EPC La gestion du mandat électronique (e-mandat) n est pas prise en compte dans cette version du document (donnée 2.62 «ElectronicSignature» ignorée dans ce guide) Schéma de références Le schéma XL CustomerDirectDebitInitiation a été défini par l International rganization for Standardization et fait donc partie de la bibliothèque des standards IS Cette dernière est disponible avec sa documentation sur le site de l IS ( La déclinaison SEPA de ce schéma XL figure dans les Implementation Guidelines de l EPC disponibles sur le site ainsi que toute la documentation SEPA Rappel sur les caractères autorisés Les caractères autorisés dans les messages sont définis au chapitre 1.10 ci-dessus. Guide d utilisation du CustomerDirectDebitInitiation - V1.1 04/2010 Page 11

12 2.4. La structure du message Le message CustomerDirectDebitInitiation est composé de données structurées regroupées dans des «blocs». Il existe trois blocs d'information formant chacun un niveau du message : Le niveau message (GroupHeader) Il contient des informations relatives à l ensemble des informations véhiculées dans un et un seul message (Référence du message, date et heure de création, nombre de transactions, identification de l émetteur ) Ce niveau est obligatoire et doit être présent une seule fois par message. Le niveau lot (PaymentInformation) Il contient des éléments relatifs au crédit du compte du créancier (date d échéance, type de prélèvement, nature des opérations contenues dans la remise, raison sociale du créancier, compte du créancier, identifiant SEPA du créancier ). Ce bloc est obligatoire et peut être répétitif. Le niveau transaction (DirectDebitTransactionInformation) Il contient les éléments relatifs au débit de la transaction au compte du débiteur (Références, référence unique du mandat, montant, nom ou raison sociale du débiteur, compte du débiteur, motif de paiement ). Ce bloc est obligatoire et peut être répétitif. Ces blocs sont organisés comme suit : Guide d utilisation du CustomerDirectDebitInitiation - V1.1 04/2010 Page 12

13 Le message est composé de données structurées identifiées par des «balises» elles-mêmes regroupées dans des blocs dont voici la synthèse. Le signe + dans la première colonne signifie que la balise est constituée de plusieurs sous éléments détaillés à part dans les spécifications. n trouvera ce signe en particulier pour les éléments composites (ex : Initiating Party). CustomerDirectDebitInitiation SWIFT Standard essage item ccur. A. GRUPHEADER [1..1] essageidentification [1..1] CreationDateTime [1..1] + Authorisation [0..2] NumberfTransactions [1..1] ControlSum [0..1] + InitiatingParty [1..1] + ForwardingAgent [0..1] NIVEAU «ESSAGE» B. PAYENTINFRATIN [1..n] PaymentInformationIdentification [1..1] Paymentethod [1..1] BatchBooking [0..1] NumberfTransactions [0..1] ControlSum [0..1] + PaymentTypeInformation [0..1] RequestedCollectionDate [1..1] + Creditor [1..1] + CreditorAccount [1..1] + CreditorAgent [1..1] + CreditorAgentAccount [0..1] + UltimateCreditor [0..1] ChargeBearer [0..1] + ChargesAccount [0..1] + ChargesAccountAgent [0..1] + CreditorSchemeIdentification [0..1] NIVEAU «LT» C. DIRECTDEBITTRANSACTININFRATIN [1..n] + PaymentIdentification [1..1] + PaymentTypeInformation [0..1] InstructedAmount [1..1] ChargeBearer [0..1] + DirectDebitTransaction [0..1] + UltimateCreditor [0..1] + DebtorAgent [1..1] + DebtorAgentAccount [0..1] + Debtor [1..1] + DebtorAccount [1..1] + UltimateDebtor [0..1] InstructionforCreditorAgent [0..1] + Purpose [0..1] + RegulatoryReporting [0..10] + Tax [0..1] + RelatedRemittanceInformation [0..10] + Remittanceinformation [0..1] NIVEAU «TRANSACTIN» Guide d utilisation du CustomerDirectDebitInitiation - V1.1 04/2010 Page 13

14 2.5. Regroupement des opérations Un lot est obligatoirement homogène sur les critères suivants : ême type de prélèvement SEPA (index 2.11 «LocalInstrument») - Prélèvements SEPA (SDD Core) - Prélèvements SEPA interentreprises (SDD B2B) ême séquence de présentation (index 2.14 «SequenceType») - Ponctuel (ne-off FF) - Premier d une série (First FRST) - Suivant d une série (recurrent RCUR) - Dernier d une série (final FNAL) 2.6. odes de comptabilisation des opérations Deux modes de comptabilisation des transactions sont possibles : La comptabilisation par lot (pour un ensemble de transactions) : ce mode doit être utilisé lorsque l émetteur souhaite que sa banque effectue un crédit global sur le compte à créditer pour l ensemble des transactions (DebitDirectTransactionInformation) contenues dans le lot (PaymentInformation). La comptabilisation unitaire (par transaction) : ce mode doit être utilisé lorsque l émetteur souhaite que sa banque effectue un crédit par transaction sur le compte à créditer. Le choix du mode de comptabilisation est généralement géré par un accord bilatéral convenu préalablement entre le client et sa banque. Par ailleurs, la donnée facultative «BatchBooking» (index 2.3) peut être utilisée pour indiquer cette option. Cette donnée figure dans le corps du message IS et se caractérise par le tag <BtchBookg> du bloc PaymentInformation du message. Si le choix est fixé par contrat, il prévaudra sur celui qui pourrait être indiqué dans le message Les différents intervenants dans le traitement des prélèvements SEPA Le CustomerDirectDebitInitiation permet l identification de plusieurs intervenants. Il ouvre par conséquent la voie à plusieurs scénarios d échanges qu il convient de définir : - Scénarios ou ou - Scénarios ou Guide d utilisation du CustomerDirectDebitInitiation - V1.1 04/2010 Page 14

15 Note : ce schéma met en scène le maximum d intervenants pouvant être identifiés dans le standard IS «CustomerDirectDebitInitiation». Il appartient au client, suivant les services proposés par sa banque, de distinguer ou non chaque intervenant. Guide d utilisation du CustomerDirectDebitInitiation - V1.1 04/2010 Page 15

16 PARTY SYNNYS DESCRIPTIN INITIATINGPARTY (INDEX 1.8) CREDITR (INDEX 2.19) ULTIATECREDITR (2.23 ET 2.69) DEBTR (INDEX 2.72) ULTIATEDEBTR (INDEX 2.74) CREDITRAGENT (INDEX 2.21) DEBTRAGENT (INDEX 2.70) Emetteur Créancier Titulaire du compte à créditer Tiers Créancier Débiteur : Titulaire du compte à débiter Tiers débiteur Banque du créancier et banque d exécution Banque du débiteur Emetteur de l ordre de prélèvement à la banque d exécution. Les coordonnées de cette entité doivent obligatoirement figurer dans le message. C est l entité en charge des échanges avec la banque, mais elle peut aussi agir : - en tant que créancier, Dans ces 2 cas, le nom seul peut suffire pour l identifier, les autres informations sont renseignées au niveau du créancier. Entité titulaire du compte à créditer. C est l entité en relation avec la banque d exécution. Si la même entité fait office d émetteur et de créancier, le détail des informations relatives à cette entité doit être précisé uniquement à ce niveau. Détenteur de la créance commerciale lorsque celui-ci n est pas le titulaire du compte à créditer. Il donne instruction au créancier (par exemple : cas d une centrale d encaissement) de collecter les fonds auprès du débiteur. Entité titulaire du compte à débiter. Entité en relation commerciale avec le créancier ou le tiers créancier et qui ne détient pas le compte à débiter. Il donne instruction au débiteur de payer les fonds en son nom. Banque qui tient le compte à créditer Banque qui tient le compte à débiter Du côté du «Crédit» Intervenants non-financiers Le standard IS permet de distinguer : L émetteur de l ordre [InitiatingParty (Cf du schéma)], Le créancier, [Creditor (Cf )], titulaire du compte à créditer, Le tiers créancier [UltimateCreditor (Cf )] si celui-ci n est pas le titulaire du compte à créditer. Intervenants financiers Le standard IS prévoit : La Banque d exécution [CreditorAgent] qui tient le compte à créditer Du côté du «Débit» Intervenants financiers Le standard IS prévoit : La Banque du débiteur [DebtorAgent] qui tient le compte à débiter, Guide d utilisation du CustomerDirectDebitInitiation - V1.1 04/2010 Page 16

17 Intervenants non-financiers Le standard IS permet de distinguer : Le débiteur [Debtor] (Cf )] titulaire du compte à débiter Le tiers débiteur [UltimateDebtor (Cf )], s il n est pas le titulaire du compte à débiter Spécificités liées aux tiers créancier et tiers débiteur Le créancier et le débiteur sont les deux acteurs détenteurs de compte, mais ils ne sont pas obligatoirement les acteurs connus lors de la négociation de la transaction commerciale. Cependant, leurs coordonnées figurent toujours sur le mandat. Les données concernant les tiers créancier et débiteur ne figurent pas dans les informations minimum à restituer dans les Schemes de l EPC. Cependant, afin d éviter toute ambigüité, tant pour le créancier que pour le débiteur, sur les intervenants liés à la transaction commerciale, il est fortement recommandé aux banques de restituer systématiquement, lorsqu elles existent, les informations relatives aux tiers créancier et débiteur Principes de référencement Afin d'être en mesure d'assurer une traçabilité de bout en bout des différents éléments échangés et traités (fichier, message, lot, transaction), il est nécessaire d'adopter des règles de référencement ne laissant aucune ambiguïté aussi bien du côté de l'émetteur que du côté du destinataire. Dans le standard CustomerDirectDebitInitiation IS 20022, chaque intervenant non financier (de l'émetteur au destinataire) peut, pour ses besoins de rapprochement dans son système d'information, disposer de plusieurs types de références : les références techniques les références fonctionnelles/comptables La référence de bout en bout les références commerciales Les références techniques Elles visent à identifier de manière unique et non ambiguë les éléments physiques (fichier et/ou message) nécessaires pour véhiculer le contenu d'un service financier en électronique bancaire. Ces références sont utilisées spécifiquement dans la relation entre le client émetteur (InitiatingParty) et la banque d'exécution (CreditorAgent). Suivant la nature des flux et le processus de traitement des Banques, ces références peuvent être rappelées dans les services de reporting "techniques" qu'elles mettent à disposition de l'émetteur (Accusé de réception applicatif (PSR) ). Il existe deux types de référence technique : La référence fichier Cette référence, propre à certains protocoles de transfert de fichier (FileAct, EBICS ), identifie l'enveloppe technique utilisée pour le transport d'un fichier et de son contenu [le(s) message(s) IS CustomerDirectDebitInitiation en l'occurrence]. Connue de la banque qui reçoit l ordre de prélèvement, elle est identifiée lors de la phase d acquisition des flux par le protocole de transport et non dans le corps du message, c est pourquoi elle n apparaît pas dans les standards IS La référence message <sgid> (essageidentification) (index 1.1) Cette référence, propre aux standards IS 20022, permet d'identifier de manière unique et non ambiguë le message qui est composé d'un ou plusieurs ordres de prélèvement. Guide d utilisation du CustomerDirectDebitInitiation - V1.1 04/2010 Page 17

18 Cette référence figure dans le corps du message IS et se caractérise par le tag <sgid> (essageidentification) du bloc Group Header du message Les références fonctionnelles ou comptables Elles sont destinées à identifier les différents ensembles de l ordre de prélèvement (lot, transaction). Ces références sont utilisées dans la relation entre le client titulaire du compte à créditer et sa banque, afin de reconnaître précisément l'ensemble concerné. Elles sont rappelées dans les services de reporting "fonctionnels" que la Banque met à disposition du client titulaire du compte (Accusé de réception applicatif, avis de crédit, relevé prévisionnel et comptable ). Référence de lot <PmtInfId> (PaymentInformationIdentification) (index 2.1) Cette référence permet d'identifier le lot de transactions détaillées au niveau DirectDebitTransactionInformation du message. Cette référence est utilisée comme référence comptable lorsque le lot est comptabilisé globalement. Il s agit également de la référence restituée sur les Accusés de Réception au niveau Lot. Référence de transaction <InstrId> (Instruction Identification) (index 2.30) Cette référence sert à identifier de manière unique et non ambiguë une transaction et peut être rappelée dans les services de reporting proposés par la Banque. Cette référence est utilisée comme référence comptable lorsque les transactions sont comptabilisées individuellement. Si cette référence est absente, c'est la référence End-To-End <EndToEndId> (index 2.31) du bloc PaymentIdentification qui sera utilisée à cette fin. Il s agit également de la référence restituée sur les Accusés de Réception au niveau Transaction La référence de bout en bout <EndToEndId> (EndToEndIdentification) (2.31) Cette référence est obligatoire et est destinée à être échangée dans toute la chaîne de traitement. Il est de la responsabilité de l émetteur de renseigner de manière unique et non ambiguë cette référence. Les banques ne sont pas en charge de contrôler cette référence mais doivent la transporter sans altération jusqu au destinataire Les références commerciales Ces références sont utilisées spécifiquement dans la relation entre l émetteur et le destinataire d'un prélèvement, afin de reconnaître précisément la nature et l'objet du prélèvement (comme les numéros de factures, les montants dus,...) ce qui permet au débiteur de faire un rapprochement entre ses échéances (montant dû) et les fonds débités. Elles sont présentes dans le motif de paiement <RmtInf> (RemittanceInformation index 2.88), dans lequel on peut renseigner les informations de paiement de façon non-structurée (limité à 140 caractères) et/ou de façon -structurée (limité à 35 caractères). Dans la partie structurée, une seule référence est utilisable : La référence identifiant le créancier (et fournie par lui) <CdtrRefInf> (CreditorReferenceInformation - index 2.110) 2.9. Identification du service associé au prélèvement et de la nature de l opération Identification du type de service attaché au lot de prélèvements - PaymentTypeInformation» (index 2.6) C est un ensemble de données à destination des banques intervenant dans le circuit. Il permet, en particulier à la première banque du circuit, d identifier le type de service qu elle doit offrir. Ces données doivent être obligatoirement renseignées au niveau «Lot». Son utilisation est définie de manière bilatérale entre le client et la première banque du circuit. Dans le standard IS, cette donnée est constituée des éléments suivants : Index Composant IS Commentaire 2.7 InstructionPriority Non utilisé pour les prélèvements SEPA Guide d utilisation du CustomerDirectDebitInitiation - V1.1 04/2010 Page 18

19 2.8 ServiceLevel Voir ci-après les cas d utilisation 2.9 Code Voir ci-après les cas d utilisation u 2.10 Proprietary Non utilisé pour les prélèvements SEPA 2.11 LocalInstrument Voir ci-après les cas d utilisation 2.12 Code Voir ci-après les cas d utilisation u 2.13 Proprietary Non utilisé pour les prélèvements SEPA 2.14 SequenceType Voir ci-après les cas d utilisation 2.15 CategoryPurpose Codification décrite ci-après 2.16 Code Utilisation soumise à accord u 2.17 Proprietary Non utilisé pour les prélèvements SEPA La donnée (2.8) «ServiceLevel» est obligatoire pour les prélèvements SEPA. Elle permet de définir un «scheme» complet ou une pratique bancaire, décrit par ailleurs, pour préciser les conditions de traitement d une opération de bout en bout. Sa valeur doit être renseignée sous forme de code et seule la valeur «SEPA» est admise. La donnée 2.11 «LocalInstrument» est obligatoire pour les prélèvements SEPA. Elle permet de renseigner le type de prélèvement. Sa valeur doit être renseignée sous forme de code et seuls les codes «CRE» (Prélèvement SEPA «SDD Core») ou «B2B» (prélèvement SEPA interentreprises «SDD B2B») sont admis. La donnée 2.14 «SequenceType» est obligatoire pour les prélèvements SEPA. Elle permet de renseigner la séquence de présentation du prélèvement SEPA. Le prélèvement SEPA peut être utilisé pour des opérations récurrentes ou ponctuelles. Une opération ponctuelle est caractérisée par la mention FF (pour one-off), cette seule opération est présentée par le créancier ; elle n est pas suivie d autres opérations au titre du même mandat. Le premier prélèvement SEPA d une série se distingue des opérations suivantes par la mention FRST (pour first) Les opérations consécutives à la première d une série sont marquées RCUR (pour recurrent). La dernière opération d une série peut éventuellement comporter la mention FNAL (pour final). La donnée 2.15 «CategoryPurpose» est une donnée facultative. Elle peut être transportée tout au long de la chaîne par les banques successives, sauf au destinataire qui dispose du code Purpose (2.76) pour identifier la nature de la transaction. Chaque acteur de la chaîne (généralement les banques) peut, en fonction des accords passés avec le client donneur d ordre, ou avec le débiteur, associer à ce code un service spécifique. La liste complète des codes «CategoryPurpose» se trouve sur le site de l IS à l adresse suivante : Identification de la nature du prélèvement - Purpose (index 2.76) C est un code à l intention du destinataire de l opération ; il se situe au niveau de chaque transaction et aide le destinataire à réconcilier le prélèvement avec sa comptabilité. La présence de cette donnée est facultative, elle est constituée des éléments suivants : Index Composant Commentaire 2.76 Purpose 2.77 Code Codification décrite ci-après u 2.78 Proprietary Non utilisé pour les prélèvements SEPA Le code «Purpose», quand il est présent, doit être transporté tout au long de la chaîne jusqu au débiteur. Les banques n exploiteront pas ce code (les services sont définis par les codes de «Type de Service associé au lot de prélèvements» examinés précédemment). Les banques n assurent pas de contrôle Guide d utilisation du CustomerDirectDebitInitiation - V1.1 04/2010 Page 19

20 de vraisemblance entre la valeur de ce code et les codes de «Type de Service associé au lot de prélèvements». La liste complète des codes «Purpose» se trouve sur le site de l IS à l adresse suivante : Exemple de codes possibles (liste non exhaustive) : GVT : Paiement pour l'administration (hors paiement des taxes, sécurité sociale ) ou de l'administration TAXS : Paiement de taxes (autres que TVA) LAN : Paiement de prêt ou emprunt INSU : Paiement de prime d'assurance Le montant Dans le standard CustomerDirectDebitInitiation IS 20022, un seul type de montant de transactions «InsructedAmount» est possible. Le montant est toujours exprimé en euro pour le Prélèvement SEPA, quelle que soit la devise de tenue de compte du créancier ou du débiteur. Balise «InstructedAmount» (index 2.44). <InstdAmt Ccy="EUR"> </InstdAmt> Rappel : Le format du montant est détaillé au Déclaration à la balance des paiements Les modalités détaillées de déclaration à la Balance des Paiements sont décrites dans le recueil des «textes applicables aux relations financières avec l étranger» édité et mis à jour par la Direction de la Balance des Paiements de la Banque de France. Lorsqu une opération doit être déclarée à la Balance des Paiements par la banque, elle doit contenir les informations suivantes : Code motif économique ontant devant être déclaré avec ce code économique Code pays (celui du pays concerné autre que la France) L identifiant du créancier (SIRET) quand il est nécessaire pour la déclaration sera récupéré du système d information de la banque qui tient son compte. Dans le message IS CustomerDirectDebitInitiation, ces informations sont représentées par : La donnée 2.79 RegulatoryReporting Il s agit d une donnée composite qui comprend : Le code économique : 2.79 «Code» (la liste des codes économiques est fournie par la banque) Le montant devant être déclaré avec ce code économique : 2.79 «Amount». Si le montant n est pas renseigné à ce niveau, le montant de l opération sera pris en compte. Un texte additionnel : 2.79 Information (il est recommandé de ne pas utiliser cette donnée) Bien que plusieurs occurrences soient possibles pour cette donnée composite, il est recommandé de n utiliser qu une seule occurrence par paiement. Le code pays de l intervenant concerné Le code pays utilisé pour la déclaration est celui de l intervenant qui n est pas résident. Guide d utilisation du CustomerDirectDebitInitiation - V1.1 04/2010 Page 20

21 Remarque : Les modalités concernant la balance de paiements sont susceptibles d évoluer, de ce fait, il est fortement recommandé de se renseigner auprès de sa banque L identifiant créancier SEPA (ICS) Les créanciers sont désignés par un identifiant dont la structure est unique au niveau de la zone SEPA. Cependant, la gestion de cet identifiant n est pas centralisée. Il se fonde sur un identifiant national encapsulé selon un algorithme public fourni par l EPC. L identifiant créancier SEPA français se base sur le NNE (identifiant spécifique pour les prélèvements nationaux) qui est encapsulé afin de répondre à la norme SEPA. Il comprend les éléments suivants : a) le code pays «FR», b) une clé de contrôle calculée sur les éléments a) et d) (2 caractères), c) une extension, appelée code activité («Creditor Business Code»), destinée à permettre au créancier d identifier dans son organisation des lignes métiers, services de traitement ou autres. Cet élément n est pas pris en compte dans le calcul de la clé, (cf. b) (3 caractères). Ce code est géré par le créancier à sa convenance (par défaut, ou si le créancier ne souhaite pas utiliser de code activité, la valeur «ZZZ» est attribuée) d) le NNE (Numéro National d Emetteur), soit 6 chiffres. Un créancier, disposant d un identifiant créancier SEPA d un autre pays, peut présenter des ordres de prélèvements SEPA avec cet identifiant. Remarques : Toutes les informations concernant l identifiant créancier SEPA se trouvent dans la brochure CFNB «Le prélèvement SEPA» (Fiche N 2). Attention : Au niveau du message IS 20022, l identifiant créancier SEPA ne fait pas partie des caractéristiques du créancier (index 2.19) mais il se trouve dans une donnée spécifique «CreditorSchemeIdentification» (index 2.27) Exemple : <CdtrSchmeId> <Id> <PrvtId> <thr> <Id>FR00ZZZ123456</Id> Identifiant Créancier SEPA <SchmeNm> <Prtry>SEPA</Prtry> </SchmeNm> </thr> </PrvtId> </Id> </CdtrSchmeId> Remarque importante : l ICS d un créancier (personne morale ou personne physique) figurera toujours dans l élément <PrivateIdentification> Autres identifiants non bancaires Les intervenants non bancaires peuvent être identifiés selon différents critères : Le nom L adresse postale Un ou plusieurs identifiants Guide d utilisation du CustomerDirectDebitInitiation - V1.1 04/2010 Page 21

22 Le pays de résidence Les coordonnées d un contact Selon le standard IS 20022, les identifiants sont décomposés de la façon suivante : Identifiant Identifiant u rganisationidentification Soit de type rganisation BICrBEI «Business Identifier Code» ther Un ou plusieurs autres identifiants organisés Identification L identifiant SchemeName Le type d identifiant Code Selon un code IS u Proprietary Selon un code propriétaire Issuer L émetteur de l identifiant u PrivateIdentification Soit de type Personne physique DateAndPlacefBirth Date et lieu de naissance ther Un ou plusieurs autres identifiants privés Identification L identifiant SchemeName Le type d identifiant Code Selon un code IS u Proprietary Selon un code propriétaire Issuer L émetteur de l identifiant Dans le cadre des prélèvements SEPA, pour les intervenants non bancaires autres que le créancier, un seul identifiant peut être utilisé soit sous forme rganisation (en utilisant soit le BIC soit un autre type d identifiant) soit sous forme Personne physique (en utilisant soit la date et lieu de naissance soit un autre type d identifiant) En France, il peut être intéressant d utiliser un identifiant tel que le SIRET de manière harmonisée (notamment afin de permettre une restitution, si besoin, dans un format autre que l IS 20022) Exemple d utilisation du SIRET pour un tiers créancier : <UltmtCdtr> <Nm>Nom du tiers creancier</nm> Nom du tiers créancier <Id> <rgid> <thr> <Id> </Id> N SIRET du tiers créancier <SchmeNm> <Prtry>SIRET</Prtry> renseigner ici le fait qu il s agit d un N SIRET </SchmeNm> </thr> </rgid> </Id> </UltmtCdtr> La dématérialisation des données du mandat La correspondance entre les données du mandat qui doivent être dématérialisées pour être éventuellement transmises avec chaque ordre de prélèvement SEPA et les noms des balises XL se trouve dans la liste ci-dessous (la lettre correspond à la donnée figurant sur l exemple de mandat disponible en annexe 3) : a) Index 2.48 : andateidentification b) Index 2.71 : Debtor / Name c) L adresse du débiteur n est pas transmise d) Index 2.73 : DebtorAccount / Identification / IBAN e) Index 2.70 : DebtorAgent / FinancialInstitutionIdentification / BIC Guide d utilisation du CustomerDirectDebitInitiation - V1.1 04/2010 Page 22

23 f) Index 2.19 : Creditor / Name g) Index 2.27 : CreditorSchemeIdentification / Identification / PrivateIdentification / ther h) L adresse du créancier n est pas transmise i) Index 2.14 : SequenceType j) Le lieu de signature n est pas transmis (ni dématérialisé) k) Index 2.49 : DatefSignature l) Index 2.72 : Debtor / Identification / rganisationidentification ou PrivateIdentification m) Index 2.74 : UltimateDebtor / Name n) Index 2.74 : UltimateDebtor / Identification / rganisationidentification ou PrivateIdentification o) Index 2.23 : UltimateCreditor / Name p) Index 2.23 : UltimateCreditor / Identification / rganisationidentification ou PrivateIdentification q) Le numéro d identification du contrat n est pas transmis (ni dématérialisé) r) La description du contrat n est pas transmise (ni dématérialisée) Les mises à jour relatives au mandat Remarque : Toutes les informations concernant les changements des données relatives au mandat se trouvent dans la brochure CFNB «Le prélèvement SEPA» (Fiche N 4). La mise à jour d une ou plusieurs données du mandat est spécifiée dans le format IS en positionnant l indicateur de mise à jour («Amendment Indicator» index 2.50) à «true» et avec : les anciennes données du mandat dans la ou les zones du mandat correspondantes : «riginalandateidentification», «riginalcreditorscheme» (Name or Identification), «riginaldebtoraccount» et «riginaldebtoragent». les nouvelles données du mandat dans la ou les zones de l ordre de prélèvement SEPA correspondantes. En cas d incohérence entre AmendmentIndicateur positionné à «false» et la présence de données d origine, ces données seront ignorées par la banque du créancier et elles ne seront pas transmises à la banque du débiteur. En cas d incohérence entre AmendmentIndicateur positionné à «true» et une absence de donnée d origine, la banque du créancier pourra soit rejeter les ordres de prélèvements SEPA soit positionner l indicateur à «false» dans le message interbancaire. Attention : En cas de changement de banque du débiteur, l ordre de prélèvement SEPA contenant les changements doit être transmis à la nouvelle banque du débiteur au plus tard 5 jours ouvrés bancaires avant l échéance et avec les caractéristiques suivantes : «Sequence Type» contient la valeur «FRST» «riginaldebtoragent» contient la valeur SNDA (Same andate New Debtor Agent ême mandat mais nouvelle banque de débiteur) Exemple d un changement de banque du débiteur : <ndtrltdinf> <ndtid>ru 123</ndtId> <DtfSgntr> </DtfSgntr> <AmdmntInd>true</AmdmntInd> <AmdmntInfDtls> <rgnlndtid>anc REF ANDAT ABCD</rgnlndtId> <rgnldbtragt> <FinInstnId> <thr> <Id>SNDA</Id> </thr> </FinInstnId> </rgnldbtragt> </AmdmntInfDtls> </ndtrltdinf> Guide d utilisation du CustomerDirectDebitInitiation - V1.1 04/2010 Page 23

24 2.16. Principes de restitutions Le schéma ci-dessous décrit les principes de restitution liés aux prélèvements SEPA. L ensemble des restitutions sont détaillées dans des guides spécifiques. Guide d utilisation du CustomerDirectDebitInitiation - V1.1 04/2010 Page 24