Guide d utilisation du standard IS 20022 PU DES EISES INFATISEES D DES DE PAIEENT essage «Customer Credit Transfer Initiation» <pain.001.001.03> Ce guide comprend l acquisition du : - Virement éligible SEPA - Virement international ou non éligible SEPA - Virement de Trésorerie - Virement Déplacé - Virement Commercial Version : 2.0 Date : Juin 2010 Statut : Version Validée Guide d utilisation du CustomerCreditTransferInitiation V2.0 06/2010 Page 1
SAIE 1. PINCIPES GENEAUX DES ESSAGES IS 20022... 4 1.1. PUQUI UN GUIDE D UTILISATIN... 4 1.2. PESENTATIN DES GUIDES D UTILISATIN... 4 1.3. INTDUCTIN A XL... 4 1.4. PEIETE DE LA FAILLE «PAYENTS» DES STANDADS IS 20022... 7 1.5. EFEENCES NATIVES ET DCUENTS SUPPTS... 8 1.6. CNTAT BILATEAL... 8 1.7. STANDAD ET PTCLES... 9 1.8. NTATINS ADPTEES... 9 1.8.1. Les statuts de données... 9 1.8.2. Les index de données... 9 1.9. EGLES GENEALES DE TNCATUE... 9 1.10. CAACTEES AUTISES... 10 1.11. FAT DES NTANTS... 10 1.12. FICHIE ET ESSAGE... 10 2. EGLES PATICULIEES DES DES DE PAIEENT... 11 2.1. PEIETE FNCTINNEL DE CE GUIDE... 11 2.2. SCHEA DE EFEENCES... 11 2.3. APPEL SU LES CAACTEES AUTISES... 11 2.4. LA STUCTUE DU ESSAGE... 12 2.5. EGUPEENT DES PEATINS... 13 2.6. DES DE CPTABILISATIN DES PEATINS... 14 2.7. LES DIFFEENTS INTEVENANTS DANS L DE DE PAIEENT... 14 2.7.1. Du côté du «débit»... 15 2.7.2. Du côté du «crédit»... 16 2.8. DES DE EGLEENT AU BENEFICIAIE... 17 2.8.1. Le crédit en compte :... 17 2.8.2. La mise à disposition des fonds :... 18 2.8.3. Le règlement par chèque :... 18 2.8.4. Tableau de synthèse :... 18 2.8.5. Conclusion :... 19 2.9. PINCIPES DE EFEENCEENT... 19 2.9.1. Les références techniques... 19 2.9.2. Les références fonctionnelles ou comptables... 20 2.9.3. La référence de bout en bout <EndToEndId> (EndToEndIdentification) (index 2.30)... 20 2.9.4. Les références commerciales... 20 2.10. IDENTIFICATIN DU SEVICE ASSCIE AU PAIEENT ET DE LA NATUE DU PAIEENT... 21 2.10.1. L identification du type de service associé au paiement - «PaymentTypeInformation»... 21 2.10.2. Identification de la nature du paiement - «Purpose»... 22 2.11. LES NTANTS... 22 2.12. DECLAATIN A LA BALANCE DES PAIEENTS... 23 2.13. STUCTUE DES ADESSES... 24 2.14. LES IDENTIFIANTS DES INTEVENANTS NN BANCAIES... 24 3. DESCIPTIN DETAILLEE DU CUSTECEDITTANSFEINITIATIN... 26 3.1 GENEALITES... 26 3.2 GUIDES SPECIFIQUES... 28 3.2.1 Guide Virement Eligible SEPA... 28 3.2.2 Guide Virement International ou Non Eligible SEPA... 36 3.2.3 Guide Virement de Trésorerie... 43 3.2.4 Guide Virement Déplacé... 49 3.2.5 Guide Virement Commercial... 56 4. ANNEXES... 62 ANNEXE 1 : HISTIQUE DES VESINS... 62 ANNEXE 2 : EXEPLE DE VIEENT ELIGIBLE SEPA... 63 ANNEXE 3 : EXEPLE DE VIEENT INTENATINAL U NN ELIGIBLE SEPA... 67 Guide d utilisation du CustomerCreditTransferInitiation V2.0 06/2010 Page 2
ANNEXE 4 : EXEPLE DE VIEENT DE TESEIE... 71 ANNEXE 5 : EXEPLE DE VIEENT DEPLACE... 74 ANNEXE 6 : EXEPLE DE VIEENT CECIAL... 78 ANNEXE 7 : CDIFICATIN DES IDENTIFIANTS DE TYPE «PATY»... 83 AVIS AUX LECTEUS 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 20022 p ain.001.001.03. En cas de nouvelle version IS 20022 de ce message, sans évolution fonctionnelle significative, ce guide ne sera pas systématiquement réactualisé. Guide d utilisation du CustomerCreditTransferInitiation V2.0 06/2010 Page 3
1. Principes généraux des messages IS 20022 1.1. Pourquoi un guide d utilisation Comme pour tout standard générique ouvert, la mise en œuvre des nouveaux standards IS 20022 nécessite des précisions consignées dans des guides d utilisation. La finalité de ces guides est de limiter les différentes interprétations possibles et les nombreuses options du standard IS 20022 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 respectant toutefois le standard IS 20022. De plus, les standards IS 20022 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. 1.2. Présentation des guides d utilisation Tous les guides d utilisation des messages financiers IS 20022 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 qui 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 qui détaille le mode d utilisation de la structure du message et des données sous forme de guide spécifique a chaque type d opérations. 1.3. 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 une méthode universelle et standardisée 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 CustomerCreditTransferInitiation V2.0 06/2010 Page 4
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>PAIS </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>PAIS</TownName> </PostalAddress> Guide d utilisation du CustomerCreditTransferInitiation V2.0 06/2010 Page 5
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="EU">2000000</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 20022 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.001.001.03" xmlns:xsi="http://www.w3.org/2001/xlschemainstance" xsi:schemalocation="urn:is:xsd:$pain.001.001.03 $pain.001.001.03.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 20022 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 Pour exemple le schéma complet du standard IS 20022 CustomerCreditTransferInitiation pain.001.001.03.xsd est disponible sur le site www.iso20022.org Guide d utilisation du CustomerCreditTransferInitiation V2.0 06/2010 Page 6
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 20022 egistry, 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 20022 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 egistry contient différents niveaux de maturité des standards : Provisionnaly registered : en attente de validation egistered : 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 «egistration Authority», l autorité d enregistrement. emarque : 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 20022. 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 20022. 1.4. Périmètre de la famille «payments» des standards IS 20022 A la date de publication de ce guide, les standards IS 20022 disponibles couvrent les échanges Client- Banque, la relation Banque-Banque et la relation Banque-Client pour les Credit Transfers, les Direct Debits et les opérations connexes à ces deux moyens de paiements 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 CustomerCreditTransferInitiation V2.0 06/2010 Page 7
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. 1.5. éférences normatives et documents supports Ces guides s appuient sur les standards et la documentation IS 20022 ainsi que sur les travaux connexes à ces standards. UL des organismes travaillant sur le sujet IS 20022 : www.iso20022.org SWIFT : www.swift.com (envoi vers IS 20022) World Wide Web Consortium (W3C) http://www.w3.org/xl/ schémas et datatypes http://www.w3.org/t/xmlschema11-2/ les structures http://www.w3.org/t/2009/c-xmlschema11-1-20090430/structures.html Interactive Financial exchange Forum : www.ifxforum.org Treasury Integration Standards Team : www.twiststandards.org pen Applications Group (AGi) : www.openapplications.org/wg/paymentharmonization/paymentharmonization.htm European payments council http://www.europeanpaymentscouncil.eu/index.cfm 1.6. 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, sur les Guide d utilisation du CustomerCreditTransferInitiation V2.0 06/2010 Page 8
protocoles de transport des données, sur d éventuels cut-off-time 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. 1.7. 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 ). 1.8. Notations adoptées 1.8.1. 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 20022 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 20022 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é. 1.8.2. Les index de données Chaque donnée répertoriée dans les standards de messages IS 20022 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.yyy). Le premier nombre correspond au numéro de niveau du message (confer. 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 1.0 1.9. ègles générales de troncature Si les données d éléments de messages au standard IS 20022 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). Guide d utilisation du CustomerCreditTransferInitiation V2.0 06/2010 Page 9
1.10. Caractères autorisés Les caractères autorisés dans les messages IS 20022 sont ceux de la norme UTF8. Cependant, les banques françaises se limitent au jeu de caractères latins, composé de : 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 S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / -? : ( )., + 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. IPTANT : Il faut respecter la nomenclature des «Data Type» : - ettre des majuscules pour les codes, exemple «SEPA» dans l élément ServiceLevel. - ettre des minuscules pour les Indicators, exemple «false» pour BatchBooking. 1.11. 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 100000.00 peut être renseigné par 100000 ) - 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écimale doit être compatible avec la norme IS 4217 relative aux devises. Pour les montants d une longueur supérieure à 14 caractères avant le séparateur de décimale, le client devra impérativement vérifier auprès de sa banque s il peut être traité. 1.12. 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 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 CustomerCreditTransferInitiation V2.0 06/2010 Page 10
2. ègles particulières des rdres de Paiement 2.1. Périmètre fonctionnel de ce guide Ce guide couvre les différents types d ordres de paiement par lesquels un donneur d'ordre donne une instruction à une banque pour effectuer un transfert de fonds de son propre compte (ou d'un compte pour lequel le donneur d'ordre détient un mandat) en faveur d'un bénéficiaire, quelle que soit sa zone géographique et la devise utilisée. Ce standard est utilisable pour les opérations unitaires ou regroupées par lot (s), qu elles soient STP (Straight Through Processing) ou non, SEPA ou non. A titre de comparaison, les formats actuellement utilisés en France pour ce type d instruction sont : Le format CFNB 160 Le format CFNB 320 emarques importantes : Ce guide s appuie sur la version pain.001.001.03 du message CustomerCreditTransferInitiation. Ce guide est général, ce chapitre décrit donc des règles qui ne s appliquent pas toutes à chacun des types de virements. Les informations propres à un type de virement donné (virement international ou non éligible SEPA, virement SEPA...) sont disponibles dans un des guides spécifiques du chapitre 3. Les services de «Lettres chèques» couverts par le message CustomerCreditTransferInitiation ne seront pas traités. 2.2. Schéma de références Le schéma XL CustomerCreditTransferInitiation a été défini et validé par l International rganization for Standardization (IS) et fait donc partie de la bibliothèque des standards IS 20022. Cette dernière est disponible avec sa documentation sur le site de l IS 20022 (www.iso20022.org). La déclinaison SEPA de ce schéma XL figure dans les Implementation Guidelines de l EPC disponible sur le site www.europeanpaymentscouncil.eu ainsi que toute la documentation SEPA. 2.3. appel sur les caractères autorisés Les caractères autorisés dans les messages sont définis au chapitre «1.10 Caractères autorisés» cidessus. Guide d utilisation du CustomerCreditTransferInitiation V2.0 06/2010 Page 11
2.4. La structure du message Le message CustomerCreditTransferInitiation 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 seul et même message (éférence du message, date et heure de création, type de regroupement, 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 débit de la transaction. Il est utilisé comme niveau de regroupement lorsque l émetteur souhaite transmettre ses transactions dans un ou plusieurs lots. Ainsi, il contient les informations relatives à la partie débit (Date d exécution demandée, type de remise, nature des opérations contenues dans la remise, raison sociale du donneur d ordre, compte du donneur d ordre Ce bloc est obligatoire et peut être répétitif. Le niveau transaction (CreditTransferTransactionInformation) Il contient les éléments relatifs au crédit de la transaction (éférence, montant, devise, raison sociale du bénéficiaire, compte du payé, déclaration réglementaire, motifs de paiement ) Ce bloc est obligatoire et peut être répétitif. Ces blocs sont organisés comme suit : 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. Guide d utilisation du CustomerCreditTransferInitiation V2.0 06/2010 Page 12
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). CustomerCreditTransferInitiation IS 20022 Standard essage item ccur. A. GUPHEADE [1..1] essageidentification [1..1] CreationDateTime [1..1] Authorisation [0..2] NumberfTransactions [1..1] ControlSum [0..1] + InitiatingParty [1..1] + ForwardingAgent [0..1] B. PAYENTINFATIN [1..n] PaymentInformationIdentification [1..1] Paymentethod [1..1] BatchBooking [0..1] NumberfTransactions [0..1] ControlSum [0..1] + PaymentTypeInformation [0..1] equestedexecutiondate [1..1] PoolingAdjustmentDate [0..1] + Debtor [1..1] + DebtorAccount [1..1] + DebtorAgent [1..1] + DebtorAgentAccount [0..1] + UltimateDebtor [0..1] ChargeBearer [0..1] + ChargesAccount [0..1] + ChargesAccountAgent [0..1] C. CEDITTANSFETANSACTININFATIN [1..n] + PaymentIdentification [1..1] + PaymentTypeInformation [0..1] + Amount [1..1] + ExchangeateInformation [0..1] ChargeBearer [0..1] + ChequeInstruction [0..1] + UltimateDebtor [0..1] + IntermediaryAgent1 [0..1] + IntermediaryAgent1Account [0..1] + IntermediaryAgent2 [0..1] + IntermediaryAgent2Account [0..1] + IntermediaryAgent3 [0..1] + IntermediaryAgent3Account [0..1] + CreditorAgent [1..1] + CreditorAgentAccount [0..1] + Creditor [0..1] + CreditorAccount [0..1] + UltimateCreditor [0..1] + InstructionforCreditorAgent [0..n] InstructionForDebitorAgent [1..1] + Purpose [0..1] + egulatoryeporting [0..10] + Tax [0..1] + elatedemittanceinformation [0..10] + emittanceinformation [0..1] NIVEAU «ESSAGE» NIVEAU «LT» NIVEAU «TANSACTIN» 2.5. egroupement des opérations Les règles d homogénéité des lots étant spécifiques à chaque établissement, elles seront gérées par un accord bilatéral préalable entre le client et sa banque. Guide d utilisation du CustomerCreditTransferInitiation V2.0 06/2010 Page 13
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 débit global sur le compte à débiter pour l ensemble des transactions (CreditTransferTransactionInformation) contenues dans le lot (PaymentInformation). La comptabilisation unitaire (par transaction) : ce mode doit être utilisé lorsque l émetteur souhaite que sa banque effectue un débit par transaction sur le compte à débiter. Le choix du mode de comptabilisation est géré par un accord bilatéral préalable 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 20022 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. 2.7. Les différents intervenants dans l ordre de paiement Le CustomerCreditTransferInitiation 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 - Scénarios ou Note : ce schéma met en scène le maximum d intervenants pouvant être identifiés dans le standard IS 20022 CustomerCreditTransferInitiation. Il appartient au client, suivant les services proposés par sa banque, de distinguer ou non chaque intervenant (financier et non financier). Guide d utilisation du CustomerCreditTransferInitiation V2.0 06/2010 Page 14
INTEVENANT SYNNYES DESCIPTIN INITIATINGPATY (1.8) DEBT (2.19) ULTIATEDEBT (2.23 ET 2.70) CEDIT (2.79) ULTIATECEDIT (2.81) Emetteur Emetteur de l instruction de paiement à la banque (d acheminement ou 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 payeur, - ou en tant que payeur et donneur d ordre initial. Dans ces 2 cas, le nom seul peut suffire pour l identifier, les autres informations sont renseignées au niveau du Payeur. Payeur. Titulaire du compte à débiter Donneur d'ordre Initial Payé. Titulaire du compte à créditer Bénéficiaire Final Entité titulaire du compte à débiter. C est l entité en relation avec la banque d exécution. Elle n est pas obligatoirement en relation avec le bénéficiaire final. Si le payeur est représenté par la même entité que l émetteur, les informations relatives au payeur doivent être précisées à ce niveau. Entité en relation avec le payé ou le bénéficiaire final. Elle donne instruction au payeur (qui instruit «pour compte de») de réaliser un ordre de paiement pour un bénéficiaire avec lequel elle est en relation et auquel elle doit le montant à payer. Hormis dans le cadre de certains services à valeur ajoutée, les informations la concernant seront ignorées par la banque. Si elle est représentée par la même entité que le payeur, les informations relatives au donneur d ordre initial ne sont pas renseignées dans le message. L Ultimate Debtor peut être une entité fonctionnelle du Debtor. Entité titulaire du compte à créditer. C est l entité qui reçoit les fonds. Elle n est pas obligatoirement en relation avec le payeur ou le donneur d ordre initial, dans ce cas les informations relatives au bénéficiaire final figurent dans le «UltimateCreditor». Bénéficiaire final lorsque celui-ci est différent du payé. Hormis dans le cadre de certains services à valeur ajoutée, les informations le concernant seront ignorées par la banque. DEBTAGENT (2.21) Banque d'exécution Banque qui tient le compte à débiter et qui exécute les ordres de paiement. CEDITAGENT (2.77) Banque du payé Banque qui tient le compte à créditer. FWADINGAGENT (1.9) INTEEDIAYAGENT1, 2 ET 3 (2.71, 2.73, 2.75) Banque d'acheminement Banques intermédiaires Banque qui reçoit de l émetteur ses ordres de paiement déplacés et les achemine vers les banques d'exécution concernées. Banques en charge d'acheminer les instructions et/ou les fonds entre la Banque d'exécution et la Banque du payé. 2.7.1. Du côté du «débit» Intervenants non-financiers Le standard IS 20022 permet de distinguer : Le Client émetteur de l ordre [InitiatingParty (Confer du schéma)], Le Client payeur titulaire du compte [Debtor (Confer )], Le donneur d ordre initial [UltimateDebtor (Confer )] s il n est pas le titulaire du compte. Les obligations réglementaires de la Banque d exécution Compte tenu du règlement européen EC 1781/2006, la banque d exécution peut être tenue de transmettre à la banque intermédiaire ou à celle du payé les nom et adresse du titulaire du compte à débiter (payeur), Guide d utilisation du CustomerCreditTransferInitiation V2.0 06/2010 Page 15
l adresse pouvant être remplacée par un identifiant. Ces informations devant être garanties par la banque d exécution, elles ne peuvent être issues que de son propre système d information (informations enregistrées à l ouverture du compte puis lors des mises à jour). Le message «CustomerCreditTransferInitiation» ne permet pas de distinguer l identifiant du client de celui utilisé par la banque. Par conséquent, si une banque a opté pour l utilisation de l identifiant en lieu et place de l adresse, les contraintes suivantes s appliqueront à la banque et à son client : Le client devra fournir un identifiant payeur unique à sa banque Quel que soit l identifiant renseigné par le client, la banque appliquera l identifiant payeur unique préalablement défini. La banque a cependant la possibilité de véhiculer des identifiants spécifiques transmis au niveau de l UltimateDebtor qui peut agir comme entité fonctionnelle du Debtor. Les limites des systèmes d échanges Certains systèmes actuels d échanges interbancaires ne permettant de renseigner qu un seul nom d intervenant côté «débit», la banque d exécution ne pourra transmettre que les nom et adresse du titulaire du compte débité. Intervenants financiers Le standard IS 20022 permet de distinguer : La Banque d exécution [DebtorAgent (Confer )] qui tient le compte à débiter, La Banque d acheminement [ForwardingAgent (Confer )] qui reçoit de l émetteur ses ordres de paiement déplacés et les achemine vers les banques d'exécution concernées. Ce qui permet de répondre aux deux scénarios suivants : 1. Le scénario d ordres de paiement direct : Il s agit du cas le plus courant où le client émetteur (InitiatingParty) transmet ses ordres de paiements directement à la banque d'exécution (DebtorAgent) qui tient le(s) compte(s) à débiter du payeur. A noter : dans ce scénario, la banque d acheminement (ForwardingAgent) n est pas identifiée dans le message 2. Le scénario d ordres de paiement déplacé L'ordre de paiement déplacé est une instruction donnée par un émetteur (InitiatingParty), pour demander à sa banque (ForwardingAgent) de transmettre un ou plusieurs ordres de paiement à une autre banque (DebtorAgent) chargée de les exécuter. Ce type d'opération ne peut s'exécuter que dans le cadre de conventions bilatérales entre la banque qui reçoit l'instruction initiale (la banque d'acheminement), et la banque d'exécution. Par ailleurs un contrat régit également les relations entre la banque d'exécution et le payeur dont elle tient le compte à débiter. Pour ces deux scénarios, la banque d exécution doit toujours être spécifiée tandis que la banque d acheminement ne pourra être renseignée que dans le cas du scénario d ordres de paiement déplacé. 2.7.2. Du côté du «crédit» Les règles décrites ci-après s appliquent aux règlements par crédit en compte. Pour les règlements par mise à disposition et «SWIFT to cheque» se référer au chapitre odes de règlement au bénéficiaire. Intervenants non-financiers Le standard permet de distinguer : Le Client payé [Creditor (Confer )] titulaire du compte à créditer, Le Client bénéficiaire final [UltimateCreditor (Confer )], s il n est pas le titulaire du compte à créditer. Guide d utilisation du CustomerCreditTransferInitiation V2.0 06/2010 Page 16
Les limites des systèmes d échanges Les systèmes actuels d échanges interbancaires ne permettant de renseigner qu un seul nom d intervenant côté «crédit», la banque d exécution ne pourra transmettre que le nom du titulaire du compte à créditer (informations requises pour l exécution de l opération dans de nombreux pays). De ce fait, tant que les systèmes d échanges et les banques n auront pas intégré les nouveaux standards en mesure de véhiculer des informations sur différents intervenants au crédit, les renseignements fournis par l émetteur sur la qualité des intervenants ne pourront être utilisés par la banque que dans le cadre de services spécifiques (virement commercial, reporting enrichi ). Intervenants financiers Le standard IS 20022 permet de distinguer : La banque du payé [CreditorAgent (Confer )] qui tient le compte à créditer, La ou les banques intermédiaires [IntermediaryAgents (Confer )] suivant le circuit d acheminement des fonds à la Banque du payé, Ce qui permet de répondre aux deux scénarios suivants : 1. Le scénario usuel : Il s agit du cas standard où le client demande à la banque d exécution (DebtorAgent) d effectuer un paiement vers la banque du payé (CreditorAgent) sans imposer de banque intermédiaire. 2. Le scénario complexe : Ce cas de figure se produit lorsque le client demande à la banque d exécution de transmettre le paiement via une banque intermédiaire désignée (IntermediaryAgent). Ce type d'opération ne peut s'exécuter que dans le cadre d un virement dans lequel la banque du payé ne peut être atteinte que via une banque intermédiaire désignée. D une manière générale seule une banque intermédiaire est permise dans le circuit. Si les informations relatives à la banque intermédiaire 2 et à la banque intermédiaire 3 sont présentes, elles seront ignorées par la banque d acheminement et par la banque d exécution sauf s il s agit d opérations en devise délocalisée. Dans ce cas les banques intermédiaires seront considérées comme les banques de couverture de ces opérations déplacées (ex : virement en USD en Allemagne). Ce type d'opération ne peut s'exécuter que dans le cadre d un virement international et nécessite un accord spécifique avec la banque d exécution. Il n est utilisé que pour des opérations particulières qui demandent une désignation spécifique du circuit interbancaire. 2.8. odes de règlement au bénéficiaire Trois modes de règlement au bénéficiaire sont retenus : le crédit en compte, la mise à disposition des fonds et le règlement par chèque. Il n existe pas pour le moment de zone 1 spécifique «mode de règlement au bénéficiaire», le tableau de synthèse en 2.8.4 et la conclusion en 2.8.5 indiquent comment le reconnaître. appel : les services de «Lettres chèques» sont exclus de ce guide. 2.8.1. Le crédit en compte : Dans ce mode de règlement l identification du compte à créditer est obligatoire. Elément 2.79 (Creditor Name ) : obligatoire. Elément 2.80 (CreditorAccount ) : obligatoire, l utilisation du code IBAN est recommandée dans tous les cas de figure et obligatoire pour les opérations SEPA. 1 L élément 2.2 (Paymentethod) est, quant à lui, toujours renseigné à «TF». Guide d utilisation du CustomerCreditTransferInitiation V2.0 06/2010 Page 17
2.8.2. La mise à disposition des fonds : Les fonds sont mis à disposition du bénéficiaire dans une banque («CreditorAgent» située dans le pays du bénéficiaire) en utilisant les informations transmises par la banque d exécution pour identifier et prévenir le bénéficiaire : nom du bénéficiaire et un «ID» permettant l identification de celui-ci, par exemple le numéro de passeport. Il est recommandé d utiliser l élément «UltimateCreditor» pour renseigner les coordonnées du bénéficiaire final. S il n est pas renseigné, la banque utilisera alors les coordonnées spécifiées dans l élément «Creditor». Le nom du bénéficiaire et une identification de celuici doivent obligatoirement être spécifiés. n utilisera les 2 occurrences des codes d instruction à la banque du bénéficiaire pour indiquer la mise à disposition et alerter ce dernier. Elément 2.81 (UltimateCreditor Name ) : recommandé (obligatoire si Creditor n est pas renseigné) Elément 2.81 (UltimateCreditor ID ) : recommandé (obligatoire si Creditor n est pas renseigné) Elément 2.79 (Creditor Name ) : obligatoire si UltimateCreditor n est pas renseigné Elément 2.79 (Creditor ID ) : obligatoire si UltimateCreditor n est pas renseigné Elément 2.83 occ. 1 (code de InstructionForCreditorAgent) : «HLD» Elément 2.83 occ. 2 (code de InstructionForCreditorAgent) : «TELB» ou «PHB» Elément 2.84 (InstructionInformation de InstructionForCreditorAgent) : adresse électronique ou numéro de téléphone. 2.8.3. Le règlement par chèque : Dans ce cas nommé «SWIFT to Cheque», le chèque est envoyé au bénéficiaire par une banque désignée par la banque d exécution, le plus souvent dans le pays de résidence du bénéficiaire : le nom et l adresse du bénéficiaire du chèque sont alors obligatoires. La banque qui établira le chèque est une banque qui a un accord spécifique avec la banque d exécution. En l absence d accord, la banque d exécution émettra un chèque tiré sur ses caisses et payable à ses guichets. De ce fait, la banque du bénéficiaire (CreditorAgent) sera ignorée pour ce mode de règlement. Elément 2.81 (UltimateCreditor Name ): recommandé (obligatoire si Creditor n est pas renseigné) Elément 2.81 (UltimateCreditor Postal Address ): recommandé (obligatoire si Creditor n est pas renseigné) Elément 2.79 (Creditor Name ) : obligatoire si UltimateCreditor n est pas renseigné Elément 2.79 (Creditor Postal Address ) : obligatoire si UltimateCreditor n est pas renseigné Elément 2.83 (code de InstructionForCreditorAgent) : «CHQB» 2.8.4. Tableau de synthèse : Index Nom de l élément Le crédit en compte 2.79 Creditor Name 2.80 CreditorAccount IBAN 2.79 ou 2.81 (*) bligatoire La mise à disposition des fonds Le règlement par chèque ecommandé Creditor or UltimateCreditor Name bligatoire bligatoire Creditor or UltimateCreditor ID Creditor or UltimateCreditor PostalAddress 2.83 Code of Instruction ForCreditorAgent (1ère occurrence) ecommandé HLD bligatoire CHQB Guide d utilisation du CustomerCreditTransferInitiation V2.0 06/2010 Page 18
Code of Instruction ForCreditorAgent (2ème occurrence) TELB ou PHB 2.84 InstructionInformation of InstructionForCreditorAgent Dépend de 2.83 (*) Si les deux éléments sont renseignés, les informations doivent être prises dans l élément 2.81 «UltimateCreditor». 2.8.5. Conclusion : Le ode de èglement peut être reconnu comme suit : L élément 2.80 (CreditorAccount) est renseigné : Crédit en Compte Si l élément 2.80 n est pas renseigné : L élément 2.83 (code de InstructionForCreditorAgent) : A pour valeur «CHQB», il s agit d un «SWIFT to Cheque», A pour valeur «HLD», il s agit d une ise à Disposition. 2.9. 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 bénéficiaire. Dans le standard CustomerCreditTransferInitiation IS 20022, chaque intervenant non financier (de l'émetteur au bénéficiaire) peut, pour ses besoins de rapprochement dans son système d'information, disposer de quatre types de références : les références techniques les références fonctionnelles ou comptables la référence de bout en bout les références commerciales appel : les services proposés par les banques sont susceptibles de ne pas transporter ou de ne transporter que partiellement les références présentées ci-après. Ces services sont différenciés en fonction des capacités des systèmes d échange. 2.9.1. 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. Ces références sont utilisées spécifiquement dans la relation entre le client émetteur (InitiatingParty) et sa banque d'acheminement (ForwardingAgent) ou sa banque d'exécution (DebtorAgent). 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 ), confer. 1.4 Périmètre des Standards IS 20022. 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, Etebac 5, PeSIT, FTP ), identifie l'enveloppe technique utilisée pour le transport d'un fichier et de son contenu [le(s) message(s) IS 20022 CustomerCreditTransferInitiation en l'occurrence]. Connue de la banque qui reçoit l instruction de paiement, elle est identifiée lors de la phase d acquisition des Guide d utilisation du CustomerCreditTransferInitiation V2.0 06/2010 Page 19
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 20022. La référence message <sgid> (essageidentification) (index 1.1) Cette référence, propre aux standards IS 20022, doit permettre d'identifier de manière unique et non ambiguë le message qui est composé d'une ou plusieurs instructions de paiement. Cette référence figure dans le corps du message IS 20022 et se caractérise par le tag <sgid> (essageidentification) du bloc GroupHeader du message. 2.9.2. Les références fonctionnelles ou comptables Elles sont destinées à identifier les différents ensembles de l ordre de paiement, lot et transaction. Ces références sont utilisées dans la relation entre le client titulaire du compte à débiter 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 débit, relevés prévisionnel et comptable ) éférence de lot <PmtInfId> (PaymentInformationIdentification) (index 2.1) Cette référence permet d'identifier le lot de transactions. Cette référence est utilisée comme référence comptable lorsque le lot est comptabilisé globalement (BatchBooking = true ou accord bilatéral prévalant). Il s agit également de la référence restituée sur les Accusés de éception au niveau Lot. éférence de transaction <InstrId> (InstructionIdentification) (index 2.29) 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 (BatchBooking true ou accord bilatéral prévalant). Si cette référence est absente, c'est la référence de bout-en-bout <EndToEndId> 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 éception au niveau Transaction. 2.9.3. La référence de bout en bout <EndToEndId> (EndToEndIdentification) (index 2.30) 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 cet identifiant mais doivent le transporter sans altération jusqu au bénéficiaire. 2.9.4. Les références commerciales Ces références sont utilisées spécifiquement dans la relation entre le client donneur d'ordre et le bénéficiaire d'un paiement, afin de reconnaître précisément la nature et l'objet du règlement (comme les numéros de factures, les montants initiaux...) ce qui permet au bénéficiaire de faire un rapprochement entre ses créances (montant à recevoir) et les fonds reçus. Elles sont présentes dans la partie du message destinée aux informations de paiement qui se compose de deux blocs : o l avis de paiement <ltdmtinf> (elatedemittanceinformation), dans lequel on trouve : La référence du paiement <mtid> (emittanceidentification) (index 2.92) Cette référence est utilisée pour réconcilier un avis séparé envoyé directement au payé du paiement reçu par celui-ci. o le motif de paiement <mtinf> (emittanceinformation), dans lequel on peut renseigner les informations de paiement de façon structurée et/ou de façon non-structurée. Dans la partie structurée, deux autres références commerciales sont utilisables : Le Numéro de référence du document <Nb> (Number de eferreddocumentinformation) (index 2.107) Guide d utilisation du CustomerCreditTransferInitiation V2.0 06/2010 Page 20