guide utilisation iso20022 remises informatisées d'ordres de paiement - pain.001.001.03 - v2.1 -...

Guide dutilisation du CustomerCreditTransferInitiation V2.1 12/2013 Page 1

Guide dutilisation du standard ISO 20022

POUR DES REMISES INFORMATISEES DORDRES DE PAIEMENT

Message Customer Credit Transfer Initiation

Ce guide comprend lacquisition : - du virement SEPA

- du virement international ou non SEPA

- du virement de Trsorerie

- du virement Dplac

- des informations commerciales du service de Factures Acceptes

Echance

Version : 2.1

Date : Dcembre 2013

Statut : Valid


SOMMAIRE

1. PRINCIPES GENERAUX DES MESSAGES ISO 20022 ...................................................................................... 4

1.1. POURQUOI UN GUIDE DUTILISATION ................................................................................................................... 4 1.2. PRESENTATION DES GUIDES DUTILISATION ........................................................................................................ 4 1.3. INTRODUCTION A XML ....................................................................................................................................... 4 1.4. PERIMETRE DE LA FAMILLE PAYMENTS DES STANDARDS ISO 20022 ............................................................ 7 1.5. REFERENCES NORMATIVES ET DOCUMENTS SUPPORTS ........................................................................................ 8 1.6. CONTRAT BILATERAL .......................................................................................................................................... 8 1.7. STANDARD ET PROTOCOLES ................................................................................................................................ 9 1.8. NOTATIONS ADOPTEES ........................................................................................................................................ 9

1.8.1. Les statuts de donnes .................................................................................................................................... 9 1.8.2. Les index de donnes ..................................................................................................................................... 9 1.8.3. Les lments composs .................................................................................................................................. 9 1.8.4. Les rgles applicables aux messages ............................................................................................................. 9

1.9. REGLES GENERALES DE TRONCATURE ............................................................................................................... 10 1.10. CARACTERES AUTORISES ................................................................................................................................... 10 1.11. FORMAT DES MONTANTS ................................................................................................................................... 10 1.12. CUMUL ARITHMETIQUE DES MONTANTS ............................................................................................................ 10 1.13. FICHIER ET MESSAGE ......................................................................................................................................... 11

2. REGLES PARTICULIERES DES ORDRES DE PAIEMENT ........................................................................... 12

2.1. PERIMETRE FONCTIONNEL DE CE GUIDE ............................................................................................................ 12 2.2. SCHEMA DE REFERENCES ................................................................................................................................... 12 2.3. RAPPEL SUR LES CARACTERES AUTORISES......................................................................................................... 12 2.4. LA STRUCTURE DU MESSAGE ............................................................................................................................. 13 2.5. REGROUPEMENT DES OPERATIONS .................................................................................................................... 14 2.6. MODES DE COMPTABILISATION DES OPERATIONS .............................................................................................. 14 2.7. LES DIFFERENTS INTERVENANTS DANS LORDRE DE PAIEMENT ......................................................................... 15

2.7.1. Du ct du dbit ..................................................................................................................................... 16 2.7.2. Du ct du crdit .................................................................................................................................... 17

2.8. MODES DE REGLEMENT AU BENEFICIAIRE ......................................................................................................... 18 2.8.1. Le crdit en compte ...................................................................................................................................... 18 2.8.2. La mise disposition des fonds.................................................................................................................... 18 2.8.3. Le rglement par chque .............................................................................................................................. 19 2.8.4. Tableau de synthse ..................................................................................................................................... 19 2.8.5. Conclusion ................................................................................................................................................... 20

2.9. PRINCIPES DE REFERENCEMENT ......................................................................................................................... 20 2.9.1. Les rfrences techniques ............................................................................................................................ 20 2.9.2. Les rfrences fonctionnelles ou comptables ............................................................................................... 20 2.9.3. La rfrence de bout en bout (EndToEndIdentification) (index 2.30) ............................... 21 2.9.4. Les rfrences commerciales ....................................................................................................................... 21

2.10. IDENTIFICATION DU SERVICE ASSOCIE AU PAIEMENT ET DE LA NATURE DU PAIEMENT ...................................... 21 2.10.1. Lidentification du type de service associ au paiement - PaymentTypeInformation ....................... 21 2.10.2. Identification de la nature du paiement - Purpose ......................................................................... 22

2.11. LES MONTANTS ................................................................................................................................................. 23 2.12. CUMUL ARITHMETIQUE DES MONTANTS ............................................................................................................ 23 2.13. DECLARATION A LA BALANCE DES PAIEMENTS.................................................................................................. 24 2.14. STRUCTURE DES ADRESSES ................................................................................................................................ 25 2.15. LES IDENTIFIANTS DES INTERVENANTS NON BANCAIRES ................................................................................... 25

3. DESCRIPTION DETAILLEE DU CUSTOMERCREDITTRANSFERINITIATION ..................................... 27

3.1 GENERALITES ............................................................................................................................................................ 27 3.2 GUIDES SPECIFIQUES .................................................................................................................................................. 30

3.2.1 Guide Virement SEPA .................................................................................................................................. 30 3.2.2 Guide Virement International ou Non SEPA ............................................................................................... 43 3.2.3 Guide Virement de Trsorerie...................................................................................................................... 50 3.2.4 Guide Virement Dplac .............................................................................................................................. 56 3.2.5 Guide Factures Acceptes Echance (FAE) ....................................................................................... 64

4. ANNEXES ..................................................................................................................................................................... 70

ANNEXE 1 : HISTORIQUE DES VERSIONS ........................................................................................................................ 70 ANNEXE 2 : EXEMPLE DE VIREMENT ELIGIBLE SEPA .................................................................................................. 71 ANNEXE 3 : EXEMPLE DE VIREMENT INTERNATIONAL OU NON SEPA ......................................................................... 74 ANNEXE 4 : EXEMPLE DE VIREMENT DE TRESORERIE ................................................................................................... 78 ANNEXE 5 : EXEMPLE DE VIREMENT DEPLACE ............................................................................................................. 81 ANNEXE 6 : EXEMPLE DE FACTURE ACCEPTEE A ECHEANCE ........................................................................................ 85


AVIS AUX LECTEURS

Ce guide est ralis sur la base du message ISO 20022 pain.001.001.03 entr en

vigueur en novembre 2009 et pour les paiements SEPA, il est align sur la version 7.0

des guides de mise en uvre de lEPC en vigueur au 1er Fvrier 2014.

Primtre du document

L'objectif de ce document est de raliser un guide pour linitiation des paiements sous forme lectronique par les clients partir de comptes tenus en France et Monaco.

Spcificits pour Monaco :

Monaco, ne faisant pas partie de lEspace Economique Europen, nest pas directement soumis aux exigences des rglements CE 1781/2006 et (UE) 260/2012.

Nanmoins, en vertu de larticle 9.b) de laccord montaire entre lUnion europenne et la principaut de Monaco publi le 13 octobre 2012 au JOUE, la Principaut de

Monaco est tenue dadopter des mesures quivalentes aux dispositions du rglement (CE) n1781/2006.

Les oprations mises depuis les comptes tenus Monaco ne sont pas exonres de la

fourniture des BIC et elles doivent respecter les exigences de la Recommandation

Spciale VII de GAFI en termes dinformations sur le donneur dordre.

Ces paiements pourront concerner des paiements SEPA et non SEPA.


1. Principes gnraux des messages ISO 20022

1.1. Pourquoi un guide dutilisation

Comme pour tout standard gnrique ouvert, la mise en uvre des nouveaux standards ISO 20022 ncessite des prcisions consignes dans des guides dutilisation.

La finalit de ces guides est de limiter les diffrentes interprtations possibles et les nombreuses options

du standard ISO 20022 qui pourraient conduire des mises en uvre divergentes dans les systmes des banques, des entreprises et dans les solutions des diteurs. De ce fait, ces guides apportent des

recommandations complmentaires respectant toutefois le standard ISO 20022.

De plus, les standards ISO 20022 vont coexister avec dautres standards au moins dans un premier temps. Cette coexistence va ncessiter de mettre en uvre des rgles de transformation dun standard un autre. Pour viter chaque banque de dfinir ses propres rgles et ainsi de risquer des incohrences, ces guides

prsentent des recommandations de gestion de cette phase transitoire.

1.2. Prsentation des guides dutilisation

Tous les guides dutilisation des messages financiers ISO 20022 produits par le Groupement des Utilisateurs Franais de SWIFT (GUF) se composent des trois parties suivantes :

- les rgles gnrales qui ont un caractre transversal sans sappliquer directement un message en particulier,

- les rgles particulires qui contiennent dune part la dfinition fonctionnelle du message, dautre part des prcisions sur les rgles d'utilisation des donnes.

- Un descriptif technique qui dtaille le mode dutilisation de la structure du message et des donnes sous forme de guide spcifique chaque type doprations.

1.3. Introduction XML

En 1999, SWIFT a adopt la syntaxe XML pour tous les dveloppements de nouveaux standards.

Le choix de la syntaxe XML rpond tout dabord une volont de disposer dune syntaxe plus souple et plus facile maintenir. Cest aussi un choix dadoption dune syntaxe non-propritaire et largement utilise aussi bien par les diteurs de logiciels que par dautres communauts dacteurs. En effet, XML est la syntaxe privilgie pour les changes entre applications et dans le monde Internet.

Quest ce qu XML ?

XML, eXtensible Markup Language, est une mthode universelle et standardise par le World Wide Web

Consortium (W3C) pour la reprsentation textuelle de donnes structures, dchiffrable par lhomme et par des programmes.

XML est une syntaxe compose de balises extensibles. Il permet chacun de reprsenter ses donnes

selon le primtre et le besoin quil entend couvrir en crant les balises appropries. XML est une syntaxe de structuration de documents qui diffrencie contenu, structure et prsentation en

sparant ces trois fonctions dans trois documents distincts.


Le contenu

Les rgles de

prsentation

La structure de

donnes

Ainsi XML est entour de nombreux autres standards comme XSL pour la prsentation des documents,

les schmas pour la formalisation des modles de document.

La finalit des documents SWIFT tant le traitement automatique par des applications, SWIFT na pas recours aux rgles de prsentation qui concernent laffichage des donnes.

Les balises ou tags

La syntaxe XML utilise des balises (ou tags ) pour structurer les donnes.

Une balise commence par le caractre < et se termine par le caractre >.

Toute balise ouvrante doit obligatoirement tre ferme plus loin dans le message par une balise fermante

du mme nom. Par exemple la balise est une balise ouvrante alors que la balise est

une balise fermante. Une balise fermante commence par les deux caractres


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 spar de la valeur par le signe d'galit.

Donne du tag :

2000000

La structure dun document contenu XML Un document contenu XML est structur en 3 parties:

La premire partie, appele prologue permet d'indiquer la version de la norme XML utilise pour crer le document (cette indication est obligatoire) ainsi que le jeu de caractres (en anglais encoding)

utilis dans le document. Ainsi le prologue est une ligne du type

Le prologue se poursuit avec des informations facultatives sur des instructions de traitement

destination d'applications particulires. Leur syntaxe est la suivante :

Le second lment est une dclaration de type de document ( l'aide d'un fichier annexe de type Schma ou de type DTD - Document Type Definition). LISO 20022 a retenu les dclarations de type schma qui sont plus descriptives que les DTD.

Cette dclaration permet de faire rfrence au modle de document utilis pour la cration de ce

message.

Et enfin la dernire composante d'un fichier XML est l'arbre des lments qui constitue le cur du document lui-mme. Il contient les diffrentes balises dcrivant le document.

Le schma de modlisation

La description des modles de document ISO 20022 en XML est ralise au sein de schmas. Un schma

utilise un langage de description spcifique (XSD). Les schmas permettent de dcrire les balises qui sont

prsentes dans le document, la structure et lenchanement de ces balises (hirarchie des balises) ainsi que les codes autoriss pour certaines donnes, le nombre doccurrences possibles, la prsence obligatoire ou facultative de certaines donnes

Pour exemple le schma complet du standard ISO 20022 CustomerCreditTransferInitiation

pain.001.001.03.xsd est disponible sur le site www.iso20022.org


Un langage de balise :

18 rue La Fayette

< cp >75009

Paris

Un langage de spcification de structure : < xs : complexType name =" adresse ">

< xs : sequence >

< xs : element name =" rue " type=" Max70Text " minOccurs =" 0 " maxOccurs =" 2 " />

< xs : element name =" cp " type=" Max6Text " minOccurs =" 1 " maxOccurs =" 1 " />

< xs : element name =" ville " type=" Max70Text " minOccurs =" 1 " maxOccurs =" 1 " />

Le contenu

Les schmas

Le dictionnaire

Pour laborer les nouveaux standards en XML appliqus aux messages financiers, une mthode de

modlisation fonctionnelle des besoins a t mise en place en sappuyant sur des standards reconnus. Dans cette mthode, est dfinie lutilisation dun dictionnaire, appel ISO 20022 Registry, dans lequel sont stocks tous les standards aussi bien de donnes que de processus mtiers.

Lobjet de ce dictionnaire est de recenser les donnes utilises dans les standards ISO 20022 et dviter toute duplication.

Le dictionnaire de donnes est utilis dans la construction des schmas dans la mesure o les noms des

balises hirarchises dans les schmas proviennent obligatoirement du dictionnaire.

Le Registry contient diffrents niveaux de maturit des standards :

Provisionnaly registered : en attente de validation

Registered : valid et actif

Obsolete : standard ne plus utiliser, mais conserv encore quelques temps dans la base.

La gestion de ce dictionnaire a t confie par lISO SWIFT qui est la Registration Authority , lautorit denregistrement.

Remarque : SWIFT dispose galement depuis longtemps dun 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 accepts au niveau ISO 20022. Il peut tre utilis par les personnes actives dans les

groupes de standardisation pour avoir connaissance de lexistant, mais il ne devrait progressivement plus tre utilis par les utilisateurs de standards ISO 20022.

1.4. Primtre de la famille payments des standards ISO 20022

A la date de publication de ce guide, les standards ISO 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 oprations connexes ces deux moyens de paiements et le reporting gnral sur le compte.


Les diffrents messages sont reprsents dans lillustration ci-aprs :

NB : Toutes les potentialits de ces nouveaux standards ne seront effectives qu' compter du moment o

elles auront t mises en uvre par les diffrents acteurs.

1.5. Rfrences normatives et documents supports

Ces guides sappuient sur les standards et la documentation ISO 20022 ainsi que sur les travaux connexes ces standards.

URL des organismes travaillant sur le sujet

ISO 20022 : www.iso20022.org

SWIFT : www.swift.com (Renvoi vers ISO 20022)

World Wide Web Consortium (W3C) http://www.w3.org/XML/

schmas et datatypes http://www.w3.org/TR/xmlschema11-2/

les structures

http://www.w3.org/TR/2009/CR-xmlschema11-1-20090430/structures.html Interactive Financial eXchange Forum : www.ifxforum.org

Treasury Integration Standards Team : www.twiststandards.org

Open Applications Group (OAGi) :

www.openapplications.org/wg/PaymentHarmonization/PaymentHarmonization.htm

European payments council

http://www.europeanpaymentscouncil.eu/index.cfm

1.6. Contrat bilatral Lorsque deux parties (banque et client) dcident de schanger lectroniquement des informations dans le cadre de la mise en uvre dun service, elles signent pralablement un contrat bilatral. Ce contrat dfinit lensemble des spcificits commerciales, techniques, juridiques, etc., convenues bilatralement entre les deux parties. Il porte notamment, ces points ntant pas dfinis par ailleurs, sur les protocoles de transport des donnes, sur dventuels cut-off times pour traitement des donnes reues ainsi que sur lenvironnement en matire de scurit. Les guides dutilisation ne reprsentent donc quune des composantes du contrat bilatral.


1.7. Standard et protocoles

Le standard de message spcifi dans ce guide dutilisation est totalement indpendant du protocole d'change. Ainsi, le message dfini peut tre chang avec les protocoles SWIFTNet (FileAct, InterAct)

mais aussi avec dautres protocoles d'changes (EBICS T, EBICS TS).

1.8. Notations adoptes

1.8.1. Les statuts de donnes

Le caractre obligatoire ou non dune donne ou dun groupe de donnes est dfini par un statut. Les messages normaliss par lISO 20022 ne prvoient que deux statuts qui sont obligatoire et facultatif .

Le statut facultatif prvu dans les dfinitions de messages normaliss ISO 20022 a t redfini plus

prcisment de faon ne laisser aucune ambigut sur lutilisation des objets (groupes de donnes, donnes) dans les guides dutilisation des messages XML labors sous lgide du Groupement des Utilisateurs Franais de SWIFT (GUF).

Le caractre obligatoire ou facultatif est reprsent sous la forme suivante qui prcise le nombre

doccurrences minimales et maximales : [0..1] : llment est prsent 0 ou 1 fois. Il est donc facultatif [0..n] : llment est prsent 0 ou n fois. Il est donc facultatif [1..1] : llment est prsent 1 fois. Il est donc obligatoire [1..n] : llment est prsent 1 ou n fois. Il est donc obligatoire.

Linterprtation du statut des donnes est galement conditionne par llment Or . Par exemple, la prsence de Or pour plusieurs sous-lments rattachs un mme lment avec un statut [1...1]

signifie que un et un seul lment doit tre renseign.

1.8.2. Les index de donnes

Chaque donne rpertorie dans les standards de messages ISO 20022 est indexe par un numro. Ce

numro est attribu en squence. Il est compos de deux nombres spars par un point (x.yyy). Le

premier nombre correspond au numro de niveau du message (confer. chapitre structure du message).

Le second est le numro de la donne dans le niveau correspondant.

Ainsi, la premire donne du premier niveau aura un index 1.0

1.8.3. Les lments composs

Dans le standard ISO, certains lments sont des lments composs, cest--dire quils ne contiennent pas de donnes en propre mais sont constitus "uniquement" de sous-lments.

Dans le prsent guide, ces lments sont identifis par le mot composed dans la colonne Data

Type .

Toutes les fois que cela a t jug ncessaire, les sous-lments ont t dtaills.

1.8.4. Les rgles applicables aux messages

Certains items doivent obir des rgles spcifiques comme des rgles de dpendance entre

lments. Elles sont dcrites dans le MDR (Message Definition Report) de la documentation ISO

la suite de la description des messages. On peut trouver par exemple : R1 PaymentTypeInformationRule

If PaymentTypeInformation is present, then CreditTransferTransactionInformation/PaymentTypeInformation is not

allowed.

R6 UltimateDebtorRule

If UltimateDebtor is present, then CreditTransferTransactionInformation/UltimateDebtor is not allowed.

If CreditTransferTransactionInformation/UltimateDebtor is present, then UltimateDebtor is not allowed.

CreditTransferTransactionInformation/UltimateDebtor and UltimateDebtor may both be absent.

Ceci a t retranscrit dans la colonne Status des feuilles dtailles par oprations bancaires.


1.9. Rgles gnrales de troncature

Si les donnes dlments de messages au standard ISO 20022 doivent tre exploites par dautres standards, les rgles habituelles de cadrage appliquer sont :

de cadrer gauche les zones alphanumriques et de les complter droite par des blancs si besoin,

de cadrer droite les zones numriques et de les complter gauche par des zros si besoin. Quand la zone mettrice est de taille suprieure celle de la zone rceptrice, les zones alphanumriques

sont tronques droite et les zones numriques sont tronques gauche.

Les exceptions ces rgles, si elles existent, sont prcises dans la description dtaille (chapitre 3).

1.10. Caractres autoriss

Les caractres autoriss dans les messages ISO 20022 sont ceux de la norme UTF8. Cependant, les

banques franaises se limitent au jeu de caractres 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 M N O P Q R S T U V W X Y Z

0 1 2 3 4 5 6 7 8 9

/ - ? : ( ) . , + Espace

Nanmoins, dautres caractres comme les caractres accentus (, , , ...) ou des caractres particuliers (@) peuvent tre changs sous rserve daccord bilatral entre la banque et son client. Ces caractres spcifiques peuvent faire lobjet dune convention par la banque dexcution avant lchange interbancaire.

Par contre, les caractres qui ne font partie ni des caractres latins cits ci-dessus ni dune convention avec la banque dexcution sont des caractres interdits. Il est recommand de ne pas utiliser des caractres tels que le & de Pre & Fils ou < ou > . Lutilisation de tels caractres peut amener des rejets des messages.

IMPORTANT :

Il faut respecter la nomenclature des Data Type :

- Mettre des majuscules pour les codes, exemple SEPA dans llment ServiceLevel. - Mettre 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 sparateur des dcimales est reprsent par un point. - Il nest pas obligatoire de renseigner les dcimales non significatives (par exemple 100000.00

peut tre renseign par 100000) - 5 dcimales maximum aprs le point - La longueur maximale dun montant est de 18 caractres (sparateur de dcimale compris) - Le nombre de dcimale doit tre compatible avec la norme ISO 4217 relative aux devises.

Pour les montants dune longueur suprieure 14 caractres avant le sparateur de dcimale, le client devra imprativement vrifier auprs de sa banque sil peut tre trait.

1.12. Cumul arithmtique des montants

Une somme arithmtique des montants, sans notion de devise, permet doprer un contrle de cohrence des montants prsents dans un message.

Prconisations dexpression de cette somme dans le cas spcifique dun message compos exclusivement de flux SEPA :

- 2 dcimales maximum aprs le point. - Il nest pas obligatoire de renseigner les dcimales non significatives (par exemple 100000.00

peut tre renseign par 100000).


1.13. Fichier et message

Les changes lectroniques entre lentreprise et la banque sont effectus 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.

Compte tenu des diffrentes combinaisons possibles, chaque banque, au travers dun contrat bilatral, aura pralablement convenu avec son client des caractristiques de regroupement des

oprations par nature, service et autre afin de garantir une homognit de traitement par message

ou par fichier.


2. Rgles particulires des Ordres de Paiement

2.1. Primtre fonctionnel de ce guide

Ce guide couvre les diffrents types dordres 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 dtient un mandat) en faveur d'un bnficiaire, quelle que soit sa zone

gographique et la devise utilise. Ce standard est utilisable pour les oprations unitaires ou regroupes

par lot (s), quelles soient STP (Straight Through Processing) ou non, SEPA ou non.

A titre de comparaison, les formats actuellement utiliss en France pour ce type dinstruction sont : Le format CFONB 160 Le format CFONB 320

Remarques importantes :

Ce guide sappuie sur la version pain.001.001.03 du message CustomerCreditTransferInitiation. Ce guide est gnral, ce chapitre dcrit donc des rgles qui ne sappliquent pas toutes chacun des

types de virements. Les informations propres un type de virement donn (virement international ou

non SEPA, virement SEPA ...) sont dcrites dans un des guides spcifiques du chapitre 3.

Les services de Lettres chques couverts par le message CustomerCreditTransferInitiation ne seront pas traits.

2.2. Schma de rfrences

Le schma XML CustomerCreditTransferInitiation a t dfini et valid par lInternational Organization for Standardization (ISO) et fait donc partie de la bibliothque des standards ISO 20022. Cette dernire

est disponible avec sa documentation sur le site de lISO 20022 (www.iso20022.org). La dclinaison SEPA de ce schma XML figure dans les Implementation Guidelines de lEPC disponible sur le site www.europeanpaymentscouncil.eu ainsi que toute la documentation SEPA.

2.3. Rappel sur les caractres autoriss

Les caractres autoriss dans les messages sont dfinis au chapitre 1.10 Caractres autoriss ci-avant.


2.4. La structure du message

Le message CustomerCreditTransferInitiation est compos de donnes structures regroupes dans des blocs . Il existe trois blocs d'information formant chacun un niveau du message :

Le niveau message (GroupHeader) Il contient des informations relatives lensemble des informations vhicules dans un seul et mme message (Rfrence du message, date et heure de cration, type de regroupement, nombre

de transactions, identification de lmetteur) Ce niveau est obligatoire et doit tre prsent une seule fois par message.

Le niveau lot (PaymentInformation) Il contient des lments relatifs au dbit de la transaction. Il est utilis comme niveau de

regroupement lorsque lmetteur souhaite transmettre ses transactions dans un ou plusieurs lots. Ainsi, il contient les informations relatives la partie dbit (Date dexcution demande, type de remise, nature des oprations contenues dans la remise, raison sociale du donneur dordre, compte du donneur dordre Ce bloc est obligatoire et peut tre rptitif.

Le niveau transaction (CreditTransferTransactionInformation) Il contient les lments relatifs au crdit de la transaction (Rfrence, montant, devise, raison

sociale du bnficiaire, compte du pay, dclaration rglementaire, motifs de paiement) Ce bloc est obligatoire et peut tre rptitif.

Ces blocs sont organiss comme suit :

Le message est compos de donnes structures identifies par des balises elles-mmes regroupes

dans des blocs dont voici la synthse.

Le signe + dans la premire colonne signifie que la balise est constitue de plusieurs sous lments dtaills part dans les spcifications. On trouvera ce signe en particulier pour les lments composites

(ex : Initiating Party).


CustomerCreditTransferInitiation

ISO 20022 Standard

Message item Occur.

A. GROUPHEADER [1..1]

MessageIdentification [1..1]

CreationDateTime [1..1]

Authorisation [0..2]

NumberOfTransactions [1..1]

ControlSum [0..1]

+ InitiatingParty [1..1]

+ ForwardingAgent [0..1]

B. PAYMENTINFORMATION [1..n]

PaymentInformationIdentification [1..1]

PaymentMethod [1..1]

BatchBooking [0..1]

NumberOfTransactions [0..1]

ControlSum [0..1]

+ PaymentTypeInformation [0..1]

RequestedExecutionDate [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. CREDITTRANSFERTRANSACTIONINFORMATION [1..n]

+ PaymentIdentification [1..1]

+ PaymentTypeInformation [0..1]

+ Amount [1..1]

+ ExchangeRateInformation [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]

+ RegulatoryReporting [0..10] + Tax [0..1]

+ RelatedRemittanceInformation [0..10]

+ RemittanceInformation [0..1]

2.5. Regroupement des oprations

Les rgles dhomognit des lots tant spcifiques chaque tablissement, elles seront gres par un accord bilatral pralable entre le client et sa banque.

2.6. Modes de comptabilisation des oprations

Deux modes de comptabilisation des transactions sont possibles :

La comptabilisation par lot (pour un ensemble de transactions) : ce mode doit tre utilis lorsque lmetteur souhaite que sa banque effectue un dbit global sur le compte dbiter pour lensemble des transactions (CreditTransferTransactionInformation) contenues dans le lot (PaymentInformation).

La comptabilisation unitaire (par transaction) : ce mode doit tre utilis lorsque lmetteur souhaite que sa banque effectue un dbit par transaction sur le compte dbiter.

NIVEAU LOT

NIVEAU TRANSACTION

NIVEAU MESSAGE


Le choix du mode de comptabilisation est gr par un accord bilatral pralable entre le client et sa

banque.

Par ailleurs, la donne facultative BatchBooking (index 2.3) peut tre utilise pour indiquer cette

option. Cette donne figure dans le corps du message ISO 20022 et se caractrise par le tag

du bloc PaymentInformation du message.

Si le choix est fix par contrat, il prvaudra sur celui qui pourrait tre indiqu dans le message.

2.7. Les diffrents intervenants dans lordre de paiement

Le CustomerCreditTransferInitiation permet lidentification de plusieurs intervenants. Il ouvre par consquent la voie plusieurs scnarios dchanges quil convient de dfinir :

- Scnarios ou ou - Scnarios ou - Scnarios ou

Note : ce schma met en scne le maximum dintervenants pouvant tre identifis dans le standard ISO 20022 CustomerCreditTransferInitiation. Il appartient au client, suivant les services proposs par sa banque, de distinguer ou non chaque intervenant (financier et non financier).


INTERVENANT SYNONYMES DESCRIPTION

INITIATINGPARTY (1.8)

Emetteur Emetteur de linstruction de paiement la banque (dacheminement ou dexcution). Les coordonnes de cette entit doivent obligatoirement figurer dans le message.

Cest lentit en charge des changes avec la banque, mais elle peut aussi agir :

- en tant que payeur, - ou en tant que payeur et donneur dordre initial.

Dans ces 2 cas, le nom seul peut suffire pour lidentifier, les autres informations sont renseignes au niveau du Payeur.

DEBTOR (2.19) Payeur. Titulaire du compte dbiter

Entit titulaire du compte dbiter.

Cest lentit en relation avec la banque dexcution. Elle nest pas obligatoirement en relation avec le bnficiaire final.

Si le payeur est reprsent par la mme entit que lmetteur, les informations relatives au payeur doivent tre prcises ce

niveau.

ULTIMATEDEBTOR (2.23 ET 2.70)

Donneur d'ordre Initial

Entit en relation avec le pay ou le bnficiaire final.

Elle donne instruction au payeur (qui instruit pour compte de )

de raliser un ordre de paiement pour un bnficiaire avec lequel

elle est en relation et auquel elle doit le montant payer.

Hormis dans le cadre de certains services valeur ajoute, les

informations la concernant seront ignores par la banque. Si elle

est reprsente par la mme entit que le payeur, les informations

relatives au donneur dordre initial ne sont pas renseignes dans le message.

LUltimate Debtor peut tre une entit fonctionnelle du Debtor.

CREDITOR (2.79) Pay. Titulaire du compte crditer

Entit titulaire du compte crditer.

Cest lentit qui reoit les fonds. Elle nest pas obligatoirement en relation avec le payeur ou le donneur dordre initial, dans ce cas les informations relatives au bnficiaire final figurent dans le

UltimateCreditor .

ULTIMATECREDITOR (2.81)

Bnficiaire Final

Bnficiaire final lorsque celui-ci est diffrent du pay.

Hormis dans le cadre de certains services valeur ajoute, les

informations le concernant seront ignores par la banque.

DEBTORAGENT (2.21) Banque d'excution Banque qui tient le compte dbiter et qui excute les ordres de paiement.

CREDITORAGENT (2.77) Banque du pay Banque qui tient le compte crditer.

FORWARDINGAGENT (1.9)

Banque d'acheminement

Banque qui reoit de lmetteur ses ordres de paiement dplacs et les achemine vers les banques d'excution concernes.

INTERMEDIARYAGENT1, 2 ET 3 (2.71 , 2.73, 2.75)

Banques intermdiaires

Banques en charge d'acheminer les instructions et/ou les fonds

entre la Banque d'excution et la Banque du pay.

2.7.1. Du ct du dbit

Intervenants non-financiers

Le standard ISO 20022 permet de distinguer :

Le Client metteur de lordre [InitiatingParty (Confer du schma)], Le Client payeur titulaire du compte [Debtor (Confer )], Le donneur dordre initial [UltimateDebtor (Confer )] sil nest pas le titulaire du compte.

Les obligations rglementaires de la banque dexcution

Compte tenu du rglement europen EC 1781/2006, la banque dexcution peut tre tenue de transmettre la banque intermdiaire ou celle du pay les nom et adresse du titulaire du compte dbiter (payeur),

ladresse pouvant tre remplace par un identifiant. Ces informations devant tre garanties par la banque dexcution, elles ne peuvent tre issues que de son propre systme dinformation (informations enregistres louverture du compte puis lors des mises jour).


Le message CustomerCreditTransferInitiation ne permet pas de distinguer lidentifiant du client de celui utilis par la banque. Par consquent, si une banque a opt pour lutilisation de lidentifiant en lieu et place de ladresse, les contraintes suivantes sappliqueront la banque et son client :

Le client devra fournir un identifiant payeur unique sa banque,

Quel que soit lidentifiant renseign par le client, la banque appliquera lidentifiant payeur unique pralablement dfini.

La banque a cependant la possibilit de vhiculer des identifiants spcifiques transmis au niveau de

lUltimateDebtor qui peut agir comme entit fonctionnelle du Debtor.

Les limites des systmes dchanges

Certains systmes actuels dchanges interbancaires ne permettant de renseigner quun seul nom dintervenant ct dbit , la banque dexcution ne pourra transmettre que les nom et adresse du titulaire du compte dbit.

Intervenants financiers


La Banque dexcution [DebtorAgent (Confer )] qui tient le compte dbiter,

La Banque dacheminement [ForwardingAgent (Confer )] qui reoit de lmetteur ses ordres de paiement dplacs et les achemine vers les banques d'excution concernes.

Ce qui permet de rpondre aux deux scnarios suivants :

1. Le scnario dordres de paiement direct : Il sagit du cas le plus courant o le client metteur (InitiatingParty) transmet ses ordres de paiements directement la banque d'excution (DebtorAgent) qui tient le(s) compte(s) dbiter du payeur.

A noter : dans ce scnario, la banque dacheminement (ForwardingAgent) nest pas identifie dans le message.

2. Le scnario dordres de paiement dplac L'ordre de paiement dplac est une instruction donne par un metteur (InitiatingParty), pour demander

sa banque (ForwardingAgent) de transmettre un ou plusieurs ordres de paiement une autre banque

(DebtorAgent) charge de les excuter.

Ce type d'opration ne peut s'excuter que dans le cadre de conventions bilatrales entre la banque qui

reoit l'instruction initiale (la banque d'acheminement) et la banque d'excution.

Par ailleurs un contrat rgit galement les relations entre la banque d'excution et le payeur dont elle tient

le compte dbiter.

Pour ces deux scnarios, la banque dexcution doit toujours tre spcifie tandis que la banque dacheminement ne pourra tre renseigne que dans le cas du scnario dordres de paiement dplac.

2.7.2. Du ct du crdit

Les rgles dcrites ci-aprs sappliquent aux rglements par crdit en compte. Pour les rglements par mise disposition et SWIFT to cheque se rfrer au chapitre Modes de rglement au bnficiaire.

Intervenants non-financiers

Le standard permet de distinguer :

Le Client pay [Creditor (Confer )] titulaire du compte crditer, Le Client bnficiaire final [UltimateCreditor (Confer )], sil nest pas le titulaire du compte

crditer.

Les limites des systmes dchanges

Les systmes actuels dchanges interbancaires ne permettant de renseigner quun seul nom dintervenant ct crdit , la banque dexcution ne pourra transmettre que le nom du titulaire du compte crditer (informations requises pour lexcution de lopration dans de nombreux pays). De ce fait, tant que les systmes dchanges et les banques nauront pas intgr les nouveaux standards en mesure de vhiculer des informations sur diffrents intervenants au crdit, les renseignements fournis par

lmetteur sur la qualit des intervenants ne pourront tre utiliss par la banque que dans le cadre de services spcifiques (service de Factures Acceptes Echance, reporting enrichi).


Intervenants financiers


La banque du pay [CreditorAgent (Confer )] qui tient le compte crditer, La ou les banque(s) intermdiaire(s) [IntermediaryAgents (Confer )] suivant le circuit

dacheminement des fonds la Banque du pay,

Ce qui permet de rpondre aux deux scnarios suivants :

1. Le scnario usuel : Il sagit du cas standard o le client demande la banque dexcution (DebtorAgent) deffectuer un paiement vers la banque du pay (CreditorAgent) sans imposer de banque intermdiaire.

2. Le scnario complexe : Ce cas de figure se produit lorsque le client demande la banque dexcution de transmettre le paiement via une banque intermdiaire dsigne (IntermediaryAgent).

Ce type d'opration ne peut s'excuter que dans le cadre dun virement dans lequel la banque du pay ne peut tre atteinte que via une banque intermdiaire dsigne.

Dune manire gnrale seule une banque intermdiaire est permise dans le circuit. Si les informations relatives la banque intermdiaire 2 et la banque intermdiaire 3 sont prsentes, elles seront ignores

par la banque dacheminement et par la banque dexcution sauf sil sagit doprations en devise dlocalise.

Dans ce cas les banques intermdiaires seront considres comme les banques de couverture de ces

oprations dplaces (ex : virement en USD en Allemagne).

Ce type d'opration ne peut s'excuter que dans le cadre dun virement international et ncessite un accord spcifique avec la banque dexcution. Il nest utilis que pour des oprations particulires qui demandent une dsignation spcifique du circuit interbancaire.

2.8. Modes de rglement au bnficiaire

Trois modes de rglement au bnficiaire sont retenus :

le crdit en compte,

la mise disposition des fonds,

le rglement par chque. Il nexiste pas pour le moment de zone* spcifique mode de rglement au bnficiaire , le tableau de synthse en 2.8.4 et la conclusion en 2.8.5 indiquent comment le reconnatre.

Rappel : les services de Lettres chques sont exclus de ce guide.

2.8.1. Le crdit en compte

Dans ce mode de rglement lidentification du compte crditer est obligatoire.

Elment 2.79 (CreditorName ) : obligatoire.

Elment 2.80 (CreditorAccount ) : obligatoire, lutilisation du code IBAN est recommande dans tous les cas de figure et obligatoire pour les oprations SEPA.

2.8.2. La mise disposition des fonds

Les fonds sont mis disposition du bnficiaire dans une banque ( CreditorAgent situe dans le pays

du bnficiaire) en utilisant les informations transmises par la banque dexcution pour identifier et prvenir le bnficiaire : nom du bnficiaire et un ID permettant lidentification de celui-ci, par exemple le numro de passeport.

Il est recommand dutiliser llment UltimateCreditor pour renseigner les coordonnes du bnficiaire final. Sil nest pas renseign, la banque utilisera alors les coordonnes spcifies dans llment Creditor . Le nom du bnficiaire et une identification de celui-ci doivent obligatoirement tre spcifis.

* Llment 2.2 (PaymentMethod) est, quant lui, toujours renseign TRF .


On utilisera les 2 occurrences des codes dinstruction la banque du bnficiaire pour indiquer la mise disposition et alerter ce dernier.

Elment 2.81 (UltimateCreditorName) : recommand (obligatoire si Creditor nest pas renseign)

Elment 2.81 (UltimateCreditorID) : recommand (obligatoire si Creditor nest pas renseign)

Elment 2.79 (CreditorName) : obligatoire si UltimateCreditor nest pas renseign

Elment 2.79 (CreditorID) : obligatoire si UltimateCreditor nest pas renseign

Elment 2.83 occ. 1 (code de InstructionForCreditorAgent) : HOLD

Elment 2.83 occ. 2 (code de InstructionForCreditorAgent) : TELB ou PHOB

Elment 2.84 (InstructionInformation de InstructionForCreditorAgent) : adresse lectronique ou numro de tlphone.

2.8.3. Le rglement par chque

Dans ce cas nomm SWIFT to Cheque , le chque est envoy au bnficiaire par une banque dsigne

par la banque dexcution, le plus souvent dans le pays de rsidence du bnficiaire : le nom et ladresse du bnficiaire du chque sont alors obligatoires. La banque qui tablira le chque est une banque qui a

un accord spcifique avec la banque dexcution. En labsence daccord, la banque dexcution mettra un chque tir sur ses caisses et payable ses guichets.

De ce fait, la banque du bnficiaire (CreditorAgent) sera ignore pour ce mode de rglement.

Elment 2.81 (UltimateCreditorName): recommand (obligatoire si Creditor nest pas renseign)

Elment 2.81 (UltimateCreditorPostal Address): recommand (obligatoire si Creditor nest pas renseign)

Elment 2.79 (CreditorName) : obligatoire si UltimateCreditor nest pas renseign

Elment 2.79 (CreditorPostal Address) : obligatoire si UltimateCreditor nest pas renseign

Elment 2.83 (code de InstructionForCreditorAgent) : CHQB.

2.8.4. Tableau de synthse

Index Nom de llment Crdit en compte

Mise

disposition des

fonds

Rglement par

chque

2.79

Creditor

Name

Obligatoire

2.80 CreditorAccount

IBAN

Recommand

2.79 ou

2.81 (*)

Creditor or UltimateCreditor

Name

Obligatoire

Obligatoire


ID

Recommand


PostalAddress

Obligatoire

2.83

Code of Instruction

ForCreditorAgent

(1re occurrence)

HOLD

CHQB

Code of Instruction

ForCreditorAgent

(2me occurrence)

TELB ou PHOB

2.84 InstructionInformation of

InstructionForCreditorAgent

Dpend de 2.83

(*) Si les deux lments sont renseigns, les informations doivent tre prises dans llment 2.81 UltimateCreditor .


2.8.5. Conclusion

Le Mode de Rglement peut tre reconnu comme suit :

Llment 2.80 (CreditorAccount) est renseign : Crdit en Compte Si llment 2.80 nest pas renseign : Llment 2.83 (code de InstructionForCreditorAgent) :

A pour valeur CHQB, il sagit dun SWIFT to Cheque , A pour valeur HOLD , il sagit dune Mise Disposition.

2.9. Principes de rfrencement

Afin d'tre en mesure d'assurer une traabilit de bout en bout des diffrents lments changs et traits

(fichier, message, lot, transaction), il est ncessaire d'adopter des rgles de rfrencement ne laissant

aucune ambigut aussi bien du ct de l'metteur que du ct du bnficiaire.

Dans le standard CustomerCreditTransferInitiation ISO 20022, chaque intervenant non financier (de

l'metteur au bnficiaire) peut, pour ses besoins de rapprochement dans son systme d'information,

disposer de quatre types de rfrences :

les rfrences techniques,

les rfrences fonctionnelles ou comptables,

la rfrence de bout en bout,

les rfrences commerciales.

Rappel : les services proposs par les banques sont susceptibles de ne pas transporter ou de ne transporter

que partiellement les rfrences prsentes ci-aprs. Ces services sont diffrencis en fonction des

capacits des systmes dchange.

2.9.1. Les rfrences techniques

Elles visent identifier de manire unique et non ambigu les lments physiques (fichier et/ou message)

ncessaires pour vhiculer le contenu.

Ces rfrences sont utilises spcifiquement dans la relation entre le client metteur (InitiatingParty) et sa

banque d'acheminement (ForwardingAgent) ou sa banque d'excution (DebtorAgent).

Suivant la nature des flux et le processus de traitement des banques, ces rfrences peuvent tre rappeles

dans les services de reporting "techniques" qu'elles mettent disposition de l'metteur (Accus de

rception applicatif/PaymentStatusReport), confer. 1.4 Primtre des Standards ISO 20022.

Il existe deux types de rfrence technique :

La rfrence fichier Cette rfrence, propre certains protocoles de transfert de fichier (FileAct, EBICS T ou TS,

PeSIT, FTP), identifie l'enveloppe technique utilise pour le transport d'un fichier et de son contenu [le(s) message(s) ISO 20022 CustomerCreditTransferInitiation en l'occurrence]. Connue

de la banque qui reoit linstruction de paiement, elle est identifie lors de la phase dacquisition des flux par le protocole de transport et non dans le corps du message, cest pourquoi elle napparat pas dans les standards ISO 20022.

La rfrence message (MessageIdentification) (index 1.1) Cette rfrence, propre aux standards ISO 20022, doit permettre d'identifier de manire unique et

non ambigu le message qui est compos d'une ou plusieurs instructions de paiement.

Cette rfrence figure dans le corps du message ISO 20022 et se caractrise par le tag

(MessageIdentification) du bloc GroupHeader du message.

2.9.2. Les rfrences fonctionnelles ou comptables

Elles sont destines identifier les diffrents ensembles de lordre de paiement, lot et transaction. Ces rfrences sont utilises dans la relation entre le client titulaire du compte dbiter et sa banque afin

de reconnatre prcisment l'ensemble concern. Elles sont rappeles dans les services de reporting

"fonctionnels" que la banque met disposition du client titulaire du compte (Accus de rception

applicatif (PaymentStatusReport), avis de dbit, relevs prvisionnels et comptables, ).


Rfrence de lot (PaymentInformationIdentification) (index 2.1) Cette rfrence permet d'identifier le lot de transactions. Cette rfrence est utilise comme

rfrence comptable lorsque le lot est comptabilis globalement (BatchBooking = true ou accord

bilatral prvalant). Il sagit galement de la rfrence restitue sur les Accuss de Rception au niveau Lot.

Rfrence de transaction (InstructionIdentification) (index 2.29) Cette rfrence sert identifier de manire unique et non ambigu une transaction et peut tre

rappele dans les services de reporting proposs par la banque. Cette rfrence est utilise comme

rfrence comptable lorsque les transactions sont comptabilises individuellement (BatchBooking

true ou accord bilatral prvalant). Si cette rfrence est absente, c'est la rfrence de bout-en-bout du bloc

PaymentIdentification qui sera utilise cette fin.

Il sagit galement de la rfrence restitue sur les Accuss de Rception au niveau Transaction.

2.9.3. La rfrence de bout en bout (EndToEndIdentification) (index 2.30)

Cette rfrence est obligatoire et est destine tre change dans toute la chane de traitement.

Il est de la responsabilit de lmetteur de renseigner de manire unique et non ambigu cette rfrence. Les banques ne sont pas en charge de contrler cet identifiant mais doivent le transporter sans

altration jusquau bnficiaire.

2.9.4. Les rfrences commerciales

Ces rfrences sont utilises spcifiquement dans la relation entre le client donneur d'ordre et le

bnficiaire d'un paiement, afin de reconnatre prcisment la nature et l'objet du rglement (comme les

numros de factures, les montants initiaux...) ce qui permet au bnficiaire de faire un rapprochement

entre ses crances (montant recevoir) et les fonds reus.

Elles sont prsentes dans la partie du message destine aux informations de paiement qui se compose de

deux blocs :

o lavis de paiement (RelatedRemittanceInformation), dans lequel on trouve :

La rfrence du paiement (RemittanceIdentification) (index 2.92) Cette rfrence est utilise pour rconcilier un avis spar envoy directement au pay du

paiement reu par celui-ci.

o le motif de paiement (RemittanceInformation), dans lequel on peut renseigner les informations de paiement de faon structure et/ou de faon non-structure. Dans la partie

structure, deux autres rfrences commerciales sont utilisables :

Le Numro de rfrence du document (Number de ReferredDocumentInformation) (index 2.107)

Cette rfrence est destine transmettre lidentification des documents commerciaux objets du paiement (N de facture, n de commande).

La rfrence du Bnficiaire (Reference de CreditorReferenceInformation) (index 2.126)

Cette rfrence est demande par le pay au payeur pour rconcilier son paiement.

Dans le contexte actuel des systmes dchange, il est recommand de renseigner les informations de paiement de faon non-structure avec une seule occurrence.

2.10. Identification du Service associ au paiement et de la nature du paiement

2.10.1. Lidentification du type de service associ au paiement - PaymentTypeInformation

Le PaymentTypeInformation (index 2.6) est un ensemble de donnes destination des banques

intervenant dans le circuit. Il permet, en particulier la premire banque du circuit, didentifier le type de service quelle doit offrir. Ces donnes doivent tre obligatoirement renseignes au niveau Lot . Son utilisation est dfinie de manire bilatrale entre le client et la premire banque du circuit.


Dans le standard ISO, cette donne est constitue des lments suivants :

Index Composant ISO

2.7 InstructionPriority

2.8 ServiceLevel

2.9 Ou

Code

2.10 Proprietary

2.11 LocalInstrument

2.12 Ou

Code

2.13 Proprietary

2.14 CategoryPurpose

2.15 Ou

Code

2.16 Proprietary

La donne (2.7) InstructionPriority permet de prciser un niveau de priorit pour un paiement qui nest pas prioritaire par nature. Cette donne ne sera utilise que dans le cas dun accord bilatral.

La donne (2.8) ServiceLevel permettant didentifier le niveau de service est facultative. Nanmoins, elle permet de dfinir un Scheme complet ou une pratique bancaire, dcrits par ailleurs pour prciser

les conditions de traitement dune opration de bout en bout. Elle peut tre utilise sous la forme de codes prdfinis au niveau dune communaut (index 2.9) ou de manire ngocie entre la banque et son client (index 2.10).

Lutilisation des codes prdfinis (2.9) doit en gnral faire lobjet dun accord bilatral. Ces niveaux de service seront respects pour autant que les contraintes horaires et de donnes de la transaction

permettent leur ralisation.

La donne 2.11 LocalInstrument est destine une utilisation spcifique par une communaut

dutilisateurs. Elle peut tre utilise pour spcifier un type particulier d'opration dans un systme d'change donn, par exemple "CTR" pour un virement Fedwire aux Etats-Unis. Elle peut tre utilise

sous la forme de codes prdfinis au niveau dune communaut ( Code - index 2.12) ou de manire ngocie entre la banque et son client ( Proprietary - index 2.13).

La donne 2.14 CategoryPurpose est une donne facultative. Elle peut tre transporte tout au long

de la chane par les banques successives, sauf au destinataire qui dispose du code Purpose (2.86) pour

identifier la nature de la transaction.

Chaque acteur de la chane (gnralement les banques) peut, en fonction des accords passs avec le client

donneur dordre ou avec le bnficiaire, associer ce code un service spcifique.

La liste complte des codes ServiceLevel , LocalInstrument et CategoryPurpose est publie

sur le site de lISO sous la rubrique External Code Sets ladresse suivante : www.iso20022.org et mise jour rgulirement. NB : lutilisation du type de service attach au paiement rend lutilisation dun numro dmetteur caduque. Nanmoins, si lutilisation de ce dernier devait encore savrer indispensable dans certains cas particuliers et sous rserve dun accord bilatral pralable, llment utiliser est Identification (index 9.1.12) du payeur (2.19 Debtor).

2.10.2. Identification de la nature du paiement - Purpose

Le Purpose (index 2.86) est un code lintention du destinataire de lopration ; il se situe au niveau de chaque transaction et aide le destinataire rconcilier le paiement avec sa comptabilit.

La prsence de cette donne est facultative, elle est constitue des lments suivants :

Index Composant

2.86 Purpose

2.87 Ou

Code

2.88 Proprietary

Le code Purpose , quand il est prsent, doit tre transport tout au long de la chane jusquau

bnficiaire si les systmes dchange le permettent.


Les banques nexploiteront pas ce code (les services sont dfinis par le Type de service associ au paiement examin prcdemment). Les banques nassurent pas de contrle de vraisemblance entre la valeur de ce code et le Type de service associ au paiement .

La liste complte des codes Purpose est publie sur le site de lISO ladresse suivante : www.iso20022.org et mise jour rgulirement.

Exemple de codes possibles (liste non exhaustive) :

GOVT : Paiement pour l'administration (hors paiement des taxes, scurit sociale) ou de l'administration

TAXS : Paiement de taxes (autres que TVA)

LOAN : Paiement de prt ou emprunt

INSU : Paiement de prime d'assurance

2.11. Les montants

Dans le standard CustomerCreditTransfertInitiation ISO 20022, deux types de montants de transactions

sont possibles :

1. le montant du transfert, 2. le montant quivalent.

1er cas : le montant du transfert

Il est toujours exprim dans la devise de transfert, quelle soit ou pas identique la devise de tenue de compte.

La balise InstructedAmount (2.43) sert spcifier le montant payer. La devise de transfert doit

obligatoirement tre exprime dans lattribut Ccy .

200000.00

2me cas : le montant quivalent

Le montant de la transaction payer est exprim dans la devise de tenue de compte, mais ce montant doit

tre transfr dans une autre devise.

La balise EquivalentAmount (2.44) sert spcifier le montant quivalent de la transaction payer

dont voici lillustration :

Transfert dun montant de 200.000 euros en dollar et dont la devise de tenue de compte est en euro.

200000 USD

Notes :

Llment CcyOfTrf , devise du transfert doit obligatoirement tre renseign dans le cas du montant quivalent.

Lorsque la devise de transfert diffre de la monnaie de tenue de compte, et si un achat de devises a t convenu pralablement lors dune opration de change, il y sera fait rfrence au niveau de llment ExchangeRateInformation (2.47). Lutilisation de cette donne est soumise un accord spcifique avec la banque dexcution. Cette donne ne peut tre utilise que pour les oprations internationales.

Le montant quivalent nest pas utilis dans le cas dun scnario de paiement dplac.

2.12. Cumul arithmtique des montants

En entte de Groupe (GroupHeader), comme au niveau lot (PaymentInformation), ControlSum est le

rsultat de la somme arithmtique des montants du message, sans notion de devise. Cet lment

permet doprer un contrle de cohrence.


Selon le contrat conclu entre le client et sa banque, un mme message est susceptible de transporter

des remises (niveau lot) dune seule nature, ou de natures diffrentes (virement SEPA, virement international ou non SEPA, virement de trsorerie).

Dans le cas spcifique dun message compos exclusivement de flux SEPA, les prconisations dexpression de la somme arithmtique sont : - 2 dcimales maximum aprs le point.

- Il nest pas obligatoire de renseigner les dcimales non significatives (par exemple 100000.00 peut tre renseign par 100000).

2.13. Dclaration la balance des paiements

Les modalits dtailles de dclaration la Balance des Paiements sont dcrites dans le recueil des

textes applicables aux relations financires avec ltranger dit et mis jour par la Direction de la Balance des Paiements de la Banque de France. Les informations ci-aprs sont fournies titre indicatif et

ne se substituent en aucun cas aux textes rglementaires.

Une dclaration la Balance des Paiements doit tre ralise :

si le montant du paiement dpasse la contrevaleur de 50.000 euros

et si :

- Il sagit dun paiement destination dune banque situe hors zone SEPA - Il sagit dun paiement destination dune banque situe en France ou dans un autre pays de la

zone SEPA (cf. tableau ci-aprs) mais dont :

Le compte du donneur dordre est rsident franais et celui du bnficiaire est non rsident hors de la zone SEPA,

Le compte du donneur dordre est non rsident hors de la zone SEPA et celui du bnficiaire est rsident franais.

Tableau rcapitulatif :

Bnficiaire

Donneur dordre

FRANCE

SEPA hors FR

Hors SEPA

FRANCE NON NON OUI

SEPA hors FRANCE NON NON NON

Hors SEPA OUI NON NON

Lorsquune opration doit tre dclare la Balance des Paiements par la banque, elle doit contenir les informations suivantes :

Code motif conomique, Montant devant tre dclar avec ce code conomique, Code pays (celui du pays concern autre que la France). Lidentifiant du payeur (SIREN/SIRET) quand il est ncessaire pour la dclaration sera rcupr du systme dinformation de la banque qui tient son compte.

Dans le message ISO 20022 CustomerDirectDebitInitiation, ces informations sont reprsentes par :

La donne 2.89 RegulatoryReporting : il sagit dune donne composite qui comprend : Le code conomique : 2.89 Code (la liste des codes conomiques est disponible sur le site

de la Banque de France)

Le montant devant tre dclar avec ce code conomique : 2.89 Amount . Si le montant nest pas renseign ce niveau, le montant de lopration sera pris en compte.

Un texte additionnel : 2.89 Information (il est recommand de ne pas utiliser cette donne) Bien que plusieurs occurrences soient possibles pour cette donne composite, il est recommand

de nutiliser quune seule occurrence par paiement. Le code pays de lintervenant concern : le code pays utilis pour la dclaration est celui de

lintervenant qui nest pas rsident.


A noter : Depuis le 1er janvier 2011 les virements intra zone SEPA ne font plus lobjet de dclaration la balance des paiements.

Remarque : Les modalits concernant la balance de paiements sont susceptibles dvoluer, de ce fait, il est fortement recommand de se renseigner auprs de sa banque ou sur le site de la Banque de France.

2.14. Structure des adresses

Les adresses peuvent tre utilises pour complter les informations concernant les intervenants financiers

et non financiers.

Une adresse (index 9.1.1 PostalAddress) est compose des lments suivants :

Message Item Mult. Date Type

AddressType [0..1] Code

Department [0..1] Max70Text

SubDepartment [0..1] Max70Text

StreetName [0..1] Max70Text

BuildingNumber [0..1] Max16Text

PostCode [0..1] Max16Text

TownName [0..1] Max35Text

CountrySubDivision [0..1] Max35Text

Country [0..1] CountryCode

AddressLine [0..7] Max70Text

Tous ces lments sont optionnels.

Pour lutilisation des lments de ladresse se rfrer aux guides spcifiques de chaque type de virement. Tous les lments composant une adresse sont utilisables mais peuvent tre limits en nombre et en taille

par les systmes ou formats dchanges. Par consquent, il est prfrable de renseigner en priorit les lments les plus importants.

En cas de limitation les lments sont traits prioritairement dans lordre ci-dessous puis concatns de droite gauche pour constituer une adresse non structure.

1. Country 6. Department

2. PostalCode (Optionnel) 7. CountrySubDivision

3. TownName 7. SubDepartment

4. StreetName 9. AddressLine

5. BuildingNumber

Pour le virement SEPA la taille maximum de ladresse est de 140 caractres, cest--dire au maximum deux lignes dadresse ( AddressLine ci-dessus) ; pour les autres virements (changs en interbancaire en format swift FIN MT103 ou MT103+) la taille maximum de ladresse est de 105 caractres, cest--dire une ligne dadresse complte et 35 caractres de la deuxime.

2.15. Les identifiants des intervenants non bancaires

Les intervenants non bancaires peuvent tre identifis selon diffrents critres :

Le nom, Ladresse postale, Un ou plusieurs identifiants, Le pays de rsidence, Les coordonnes dun contact.


Selon le standard ISO 20022, les identifiants sont dcomposs de la faon suivante :

9.1.12 Identification Identifiant

9.1.13 Ou OrganisationIdentification Soit de type Organisation

9.1.14 BICOrBEI Business Identifier Code

9.1.15 Other Un ou plusieurs autres identifiants dorganisation

9.1.16 Identification Lidentifiant

9.1.17 SchemeName Le type didentifiant

9.1.18 Ou

Code Selon un code ISO

9.1.19 Proprietary Selon un code propritaire

9.1.20 Issuer Lmetteur de lidentifiant

9.1.21 Ou PrivateIdentification Soit de type Personne physique

9.1.22 DateAndPlaceOfBirth Date et lieu de naissance

9.1.27 Other Un ou plusieurs autres identifiants privs

9.1.28 Identification Lidentifiant

9.1.29 SchemeName Le type didentifiant

9.1.30 Ou

Code Selon un code ISO

9.1.31 Proprietary Selon un code propritaire

9.1.32 Issuer Lmetteur de lidentifiant

Dans le cadre des virements SEPA, pour les intervenants non bancaires, un seul identifiant peut tre

utilis soit sous forme Organisation (en utilisant le BIC et/ou un autre type didentifiant) soit sous forme Personne physique (en utilisant la date et le lieu de naissance et/ou un autre type didentifiant).

En France, il peut tre intressant dutiliser un identifiant tel que le SIRET de manire harmonise (notamment afin de permettre une restitution, si besoin, dans un format autre que lISO 20022) Exemple dutilisation du SIRET pour un donneur dordre initial :

Mr XXXXXX Nom du donneur dordre initial

12345678901234 N SIRET du donneur dordre initial

SIRET renseigner ici le fait quil sagit dun N SIRET


3. Description dtaille du CustomerCreditTransferInitiation

3.1 Gnralits

La description est base sur le message standard ISO 20022 CustomerCreditTransferInitiation

. Pour toute information complmentaire, se reporter la documentation

disponible sur le site www.iso20022.org.

Prsentation des guides

Le message est prsent sous forme de tableau reprenant :

1) des donnes dfinies par lISO 20022 :

- Index : il sagit de lidentifiant des lments composant le message. Il est utilis comme critre de tri pour la prsentation. Pour les lments composs de end points , lindex reste inchang dans la prsentation des lments du end points . Ces end points correspondent la structure

identique utilise pour les intervenants ou pour les comptes.

- Or : identifie les conditions ou entre deux ou plusieurs lments.

- Level : symbolise lindentation par profondeur de niveau. Elle correspond lindentation visuelle du Message Item.

- Message Item : nom de llment.

- : nom de la balise XML

- Mult. : le premier caractre donne le caractre obligatoire (1) ou optionnel (0), le second donne le nombre maximal doccurrences supportes par le message.

- Data Type : prcise le type de donne composite (composed, codes ou end point) ou son format.

- Definition : dfinition ISO de chaque lment.

2) des donnes utiles lexploitation des lments :

- Statut : donne le caractre (obligatoire, requis...) dfini pour un lment dans un contexte donn. Ce caractre est codifi comme suit :

Code Signification Commentaires

M Obligatoire (Mandatory)

Obligatoire dans le message standard ISO 20022.

Utilisation :

S'applique aux lments du standard ISO dont le caractre est

obligatoire et ne fait pas l'objet d'un choix marqu par un "ou

exclusif" (XOr)

R Requis

(Required)

Dans le standard not optionnel [0..1], mais rendu obligatoire dans

le guide par la communaut franaise. Utilis galement quand la norme identifie une information comme

optionnelle retenue par la communaut franaise mais compose de

deux sous-composants obligatoires avec un ou exclusif {Or [1..1]

Or [1..1] }.

D Dpendant (Dependent)

Obligatoire sous certaines conditions, en particulier en fonction d'autres

donnes dans le message.

Utilisation :

Lorsquil sagit dun sous-composant cot [1..1] dans ISO 20022 dpendant dun composant retenu comme optionnel par la communaut franaise.

S'applique galement aux lments obligatoires qui dpendent par

exemple d'un choix marqu par un "ou exclusif" (XOr).


Code Signification Commentaires

A Recommand ou

Conseill (Advised)

Utilisation vivement conseille (l'information est utile pour l'un des

intervenants ou pour le destinataire de l'opration).

Utilisation :

S'applique uniquement aux lments optionnels du standard ISO.

O Optionnel (Optional)

Peut tre utile pour le destinataire mais n'est pas ncessaire pour le

traitement de l'opration.

Utilisation :


N Non utilis (Not used)

L'utilisation de cette donne sera ignore. Cette donne ou entit, si elle

est utilise, sera ignore par le destinataire du message.

Utilisation :


N* Non trait mais

vhicul (Not used)

Cette donne est uniquement vhicule, sous rserve que les systmes

le permettent.

Quand une donne est non utilise (statut N ), elle nest pas indique dans les guides spcifiques prsents ci-aprs. Si toutefois, un logiciel devait recevoir (par erreur) une telle balise note N par la

communaut franaise, il est fond lignorer.

- Commentaires et Recommandations : prcise les informations utiles et recommandations ncessaires lutilisation. Lorsquune rfrence est faite une autre partie du guide, elle est prcise par la mention cf , suivie du chapitre en italique et en bleu. A noter que les lments

en brun et en italique concernent les end points .

Pour les donnes imbriques ou donnes composites, le statut de la donne lmentaire est li au statut de

la donne composite de rattachement. Par exemple, la structure suivante :

Message Item Statut

PartyIdentification O

Name R

Signifie que la donne Name est obligatoire quand la donne PartyIdentification est utilise.

A noter :

- Pour chaque guide spcifique, les lments ignors (statut N ) sont exclus. - Les phrases en bleu indiquent des rfrences dautres parties du guide. - Les mentions en marron sont la description dlments gnriques de niveau groupe (End Points).

Plusieurs guides sont prsents ci-aprs, il sagit de guides spcifiques pour chaque type de virement. Ils dcrivent uniquement les lments ncessaires au traitement du message dans un contexte

spcifique. Ces contextes sont dcoups comme dans le tableau page suivante :


Guides spcifiques

Offre Bancaire

/Type de flux Dfinition et Primtre Nom du guide Paragraphe

Virement SEPA Tous les virements en euro au dbit

dun compte en euro destination de bnficiaires dont la banque est situe

dans un des pays de la zone SEPA et

est accessible au virement SEPA. (Les

virements partir dun compte en devise seront traits sparment).

Virement SEPA 3.2.1 Guide

Virement SEPA

Virement

International

Les virements :

en devise,

en euro hors des pays appartenant la zone SEPA,

en euro avec des frais BEN ou OUR,

en euro sans BIC ou IBAN.

Virement

International ou

Non SEPA

3.2.2 Guide

Virement

International ou

Non SEPA

Virement Urgent Le virement urgent est caractris par

Priority High ou un CategoryPurpose Prioritaire par nature.

Virement

International ou

Non Eligible SEPA

3.2.2 Guide

Virement

International ou

Non SEPA

Virement de

Trsorerie

Le virement de trsorerie est

caractris par un CategoryPurpose

TREA et des frais partags.

Virement de

Trsorerie

3.2.3 Guide

Virement de

Trsorerie

Virement Dplac Virement dplac est caractris par un

intervenant financier supplmentaire,

le ForwardingAgent.

Virement Dplac 3.2.4 Guide

Virement Dplac

Factures

Acceptes

Echance

Informations commerciales du service

de Factures Acceptes Echance

Standard et Finanable caractris par :

(index 2.11 LocalInstrument /

Proprietary :

FAE pour standard

FAE FI pour finanable

Factures Acceptes

Echance (FAE)

3.2.5 Guides

Factures Acceptes

Echance (FAE)


3.2 Guides spcifiques

3.2.1 Guide Virement SEPA

3.2.1.1. Gnralits

3.2.1.1.1. Primtre du guide

Ce guide sappuie sur la version 7.0. du Rulebook et des Implementations Guidelines de lEPC (les lments retenus par lEPC comme lments du SEPA Core sont sur fond jaune).

Il couvre les ordres de virement en euro au dbit dun compte en euro.

Ces ordres sont destination de bnficiaires dont la banque est situe dans un des pays de la zone SEPA

et est accessible au virement SEPA.

A partir du 1er Fvrier 2014, pour les clients donneurs dordre de banques franaises, ce guide couvre galement les ordres en euros destination de bnficiaires dont les comptes sont situs dans les

Collectivits dOutre-mer (Nouvelle-Caldonie, Polynsie Franaise et Wallis-et-Futuna).

3.2.1.1.2. Prcisions sur certains index

Dans les lments Debtor et Creditor ladresse na pas t retenue au profit des seuls nom et identifiant.

Pour mmoire, ladresse du donneur dordre doit tre utilise dans les virements SEPA destination de pays SEPA hors Espace Economique Europen.

La date dexcution demande par lmetteur et renseigne dans llment RequestedExecutionDate (index 2.17) correspond la date de dbit souhaite par le client. Si toutes les conditions sont runies

(provision, cut-off, ...), elle correspond la date dacceptation par la banque et donc au dbit en compte.

3.2.1.2. Mise en uvre au 1er Fvrier 2014

Contenu des lments DebtorAgent et CreditorAgent

La rglementation europenne prvoit qu'au 1er fvrier 2014 pour les oprations nationales et au 1er

fvrier 2016 pour les oprations transfrontalires, l'metteur de virements SEPA peut ne plus fournir de

BIC. Dans le message de virement SEPA, ceci se traduit diffremment pour la banque de l'metteur et celle du bnficiaire :

Banque de l'metteur du virement (index 2.21) : L'lment Debtor Agent tant obligatoire dans le format ISO (Mult. [1..1]), si le BIC

nest pas communiqu, lmetteur est contraint dutiliser le sous-lment Other pour y faire figurer la mention "NOTPROVIDED".

NOTPROVIDED

Banque du bnficiaire du virement (index 2.77) : L'lment Creditor Agent tant optionnel en format ISO (Mult. [0..1]), en cas

dabsence de BIC, il convient de ne pas mentionner dans le message, llment dans son ensemble.


3.2.1.3 Virement multi-ordonnateurs

Certains organismes remettants, qui assurent une mission dassistance auprs de populations protges (tuteur/curateur) ou de clientles au profil particulier (huissiers), instruisent et prsentent des oprations de paiement par virement pour le compte des personnes quils reprsentent, dans un cadre dfini avec leurs banques respectives.

Dans lexemple ci-dessous dune tutelle, le terme tuteur dsigne le remettant du fichier :

Le payeur sous tutelle est le client de la banque ; cest le dbiteur, qui dtient un compte dans les livres de la banque ; il ne peut pas faire fonctionner lui-mme le compte.

Le tuteur met des paiements par virement depuis le compte du payeur (en vertu dun jugement de tutelle).

Le tuteur peut dans un mme message la banque envoyer des instructions de virements pour le compte de plusieurs clients dbiteurs sous tutelle.

Le tuteur nest pas forcment client en compte de la banque.

Le tuteur, qu'il soit par ailleurs ou non client en compte de la banque, effectue les remises dans un cadre dfini avec celle-ci et est donc clairement identifi par elle.

mission : Dans la pratique, le pain.001.001.03 mis par le tuteur comprendra presque autant de

niveaux PaymentInformation que doprations, chaque opration tant gnralement mise depuis un compte de dbiteur diffrent.

UTILISATION SPECIFIQUE DE CERTAINS ELEMENTS DU PAIN.001.

a) Identification de lmetteur (metteur pour compte de tiers).

Cette identification est destine permettre la banque de reconnatre lmetteur agissant au titre de son activit dintermdiaire. En format ISO 20022, lmetteur pour compte de tiers est l InitiatingParty .

Index 1.8 (InitiatingParty).

Informations contenues : [NOM du tuteur] et le cas chant [Identifiant].

GroupHeader

InitiatingParty Name [NOM du tuteur] Identification PrivateIdentification Other Identification [Identifiant personnel du tuteur]

Remarques :

Par mesure de simplification, il a t dcid de pouvoir faire figurer lidentifiant tuteur.

Les champs ne seront pas obligatoirement renseigns.

b) Rfrence tuteur du message. Index 1.1 MessageIdentification du pain.001 Index 2.1 OriginalMessageIdentification du pain.002

"pain.001.001.03" CustomerCreditTransferInitiation Virements SEPA

Index Or Level Message Item Mult Data Type Definition S* SEPA Core Requirements Commentaires

1.0 GroupHeader [1..1] Composed

Set of characteristics

shared by all individual

transactions included in

the message.

M En-tte de Groupe

1.1 MessageIdentification [1..1] Max35Text

Point to point reference, as

assigned by the instructing

party, and sent to the next

party in the chain to

unambiguously identify the

message.

M

Rfrence du message qui n'est pas utilise comme rfrence

fonctionnelle.

cf 2.9 Principes de rfrencement .

1.2 CreationDateTime [1..1] DateTimeDate and time at which the

message was created.M Date et heure de cration du message

1.6 NumberOfTransactions [1..1]Max15Numeric

Text

Number of individual

transactions contained in the

message.

MNombre de transactions

Ce nombre permet la banque d'effectuer un contrle de cohrence.

1.7 ControlSum [0..1] DecimalNumber

Total of all individual

amounts included in the

message, irrespective of

currencies.

R

Utilis pour permettre un contrle de cohrence. Ce total est une

somme arithmtique des montants prsents au niveau de chaque

transaction.

Prconisation : 2 chiffres au maximum aprs le point pour les dcimales

significatives, dans le cas dun message compos exclusivement de

flux SEPA.

Cf. paragraphe 2.12 cumul arithmtique des montants .

1.8 InitiatingParty [1..1] ComposedParty that initiates the

payment. M

Emetteur du message.

Si quivalent au payeur, seul le nom doit tre renseign.

cf 2.7 Les diffrents intervenants

1.8 Name [0..1] Max140Text

Name by which a party is

known and which is usually

used to identify that party.

A Usage Rule: Name is limited to 70 characters in length.

Le nom de l'metteur est recommand.

Pour les virements multi-ordonnateurs, nom du tuteur

( cf. 3.2.1.3."Virement multi-ordonnateurs" )

Limit 70 car.

1.8 Identification [0..1] ComposedUnique and unambiguous

identification of a party.O Identification de l'metteur (recommand si diffrent du payeur).

1.8 {Or OrganisationIdentification [1..1] Composed

Unique and unambiguous

way to identifying an

organisation.

OUsage Rule: Either BIC or BEI or one occurrence of Other is

allowed.

Un seul sous element de "OrganisationIdentification" est autoris.

Recommand pour l'utilisation du SIRET.

1.8 BICOrBEI [0..1] BICIdentifier

Code allocated to

organisations by the ISO

9362 Registration Authority,

under an international

identification scheme, as

described in the last version

of the standard ISO 9362

Banking (Banking

telecommunication

messages, Bank Identifier

Codes)

D

Guide dutilisation du CustomerCreditTransferInitiation - V2.1 - 12/2013 Page 32

"pain.001.001.03" CustomerCreditTransferInitiation Virements SEPA

Index Or Level Message Item Mult Data Type Definition S* SEPA Core Requirements Commentaires

1.8 Other [0..n] Composed

Unique identification of an

agent, as assigned by an

institution, using an

identification scheme.

D

1.8 Identification [1..1] Max35TextUnique and unambiguous

identification of a party.M

1.8 Or} PrivateIdentification [1..1] Composed

Unique and unambiguous

identification of a person,

eg, passport.

OUsage Rule: Either Date and Place of Birth or one occurrence of

Other is allowed

Un seul sous lment de "PrivateIdentification" est autoris.

Dans le cas de virements multi-ordonnateurs, il contiendra l'identifiant

personnel du tuteur ( cf. 3.2.1.3."Virement multi-ordonnateurs" )

1.8 Other [0..n] Composed

Unique identification of an

agent, as assigned by an

institution, using an

identification scheme.

R

1.8 Identification [1..1] Max35TextUnique and unambiguous

identification of a party.M

2.0 PaymentInformation [1..n] Composed

Set of characteristics that

applies to the debit side of

the payment transactions

included in the credit

transfer initiation.

M Niveau Lot

2.1 PaymentInformationIdentification [1..1] Max35Text

Unique identification, as

assigned by a sending party,

to unambiguously identify

the payment information

group within the message.

M

Rfrence du lot.

Elle est restitue sur le relev de compte en cas de comptabilisation par

lo

guide utilisation iso20022 remises informatisées d'ordres de paiement - pain.001.001.03 - v2.1 -...

Documents

valid guide dutilisation

virement sepa

guides dutilisation

virement dplac

virement international

standard iso

messages iso

standards iso