-
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
-
Guide dutilisation du CustomerCreditTransferInitiation V2.1
12/2013 Page 2
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
-
Guide dutilisation du CustomerCreditTransferInitiation V2.1
12/2013 Page 3
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.
-
Guide dutilisation du CustomerCreditTransferInitiation V2.1
12/2013 Page 4
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.
-
Guide dutilisation du CustomerCreditTransferInitiation V2.1
12/2013 Page 5
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
-
Guide dutilisation du CustomerCreditTransferInitiation V2.1
12/2013 Page 6
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
-
Guide dutilisation du CustomerCreditTransferInitiation V2.1
12/2013 Page 7
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.
-
Guide dutilisation du CustomerCreditTransferInitiation V2.1
12/2013 Page 8
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.
-
Guide dutilisation du CustomerCreditTransferInitiation V2.1
12/2013 Page 9
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.
-
Guide dutilisation du CustomerCreditTransferInitiation V2.1
12/2013 Page 10
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).
-
Guide dutilisation du CustomerCreditTransferInitiation V2.1
12/2013 Page 11
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.
-
Guide dutilisation du CustomerCreditTransferInitiation V2.1
12/2013 Page 12
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.
-
Guide dutilisation du CustomerCreditTransferInitiation V2.1
12/2013 Page 13
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).
-
Guide dutilisation du CustomerCreditTransferInitiation V2.1
12/2013 Page 14
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
-
Guide dutilisation du CustomerCreditTransferInitiation V2.1
12/2013 Page 15
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).
-
Guide dutilisation du CustomerCreditTransferInitiation V2.1
12/2013 Page 16
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).
-
Guide dutilisation du CustomerCreditTransferInitiation V2.1
12/2013 Page 17
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
Le standard ISO 20022 permet de distinguer :
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).
-
Guide dutilisation du CustomerCreditTransferInitiation V2.1
12/2013 Page 18
Intervenants financiers
Le standard ISO 20022 permet de distinguer :
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 .
-
Guide dutilisation du CustomerCreditTransferInitiation V2.1
12/2013 Page 19
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
Creditor or UltimateCreditor
ID
Recommand
Creditor or UltimateCreditor
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 .
-
Guide dutilisation du CustomerCreditTransferInitiation V2.1
12/2013 Page 20
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, ).
-
Guide dutilisation du CustomerCreditTransferInitiation V2.1
12/2013 Page 21
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.
-
Guide dutilisation du CustomerCreditTransferInitiation V2.1
12/2013 Page 22
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.
-
Guide dutilisation du CustomerCreditTransferInitiation V2.1
12/2013 Page 23
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.
-
Guide dutilisation du CustomerCreditTransferInitiation V2.1
12/2013 Page 24
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.
-
Guide dutilisation du CustomerCreditTransferInitiation V2.1
12/2013 Page 25
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.
-
Guide dutilisation du CustomerCreditTransferInitiation V2.1
12/2013 Page 26
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
-
Guide dutilisation du CustomerCreditTransferInitiation V2.1
12/2013 Page 27
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).
-
Guide dutilisation du CustomerCreditTransferInitiation V2.1
12/2013 Page 28
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 :
S'applique uniquement aux lments optionnels du standard ISO.
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 :
S'applique uniquement aux lments optionnels du standard ISO.
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 :
-
Guide dutilisation du CustomerCreditTransferInitiation V2.1
12/2013 Page 29
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)
-
Guide dutilisation du CustomerCreditTransferInitiation V2.1
12/2013 Page 30
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.
-
Guide dutilisation du CustomerCreditTransferInitiation V2.1
12/2013 Page 31
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