Guides d’utilisation du standard UNIFI pour le message Customer Credit Transfer Initiation

1. Guides d’utilisation du standard UNIFIpour le messageCustomer Credit Transfer Initiation 6 décembre 2007 Commission Moyens de paiement AFTE Philippe Blanchet

2. Sommaire Sommaire • Généralités • Découpage des guides • Présentation du message • Les données « clés » • Le message du Virement SEPA • Questions

3. Généralités Généralités

4. Généralités Rappels sur les standards UNIFI • La norme ISO 20022 comme standard de l’UNIversal Financial Industry (UNIFI) pour l’ensemble des moyens de paiement • XML comme méthode de représentation des données pour ce standard • Utilisation du standard UNIFI pour tous les messages mis en place dans le cadre du SEPA • Un lancement accéléré par la mise en place du Virement SEPA le 28 janvier 2008

5. Généralités Organisation des travaux • Création d’un sous-groupe NMG (National Member Group) en relation avec le Comité de Direction du GUF (Groupement des Utilisateurs de SWIFT en France) • Sous-groupe composé des principales banques de la place. Les documents émis seront labélisés GUF et CFONB • Mandaté pour l’élaboration des guides d’utilisation des standards UNIFI d’acquisition et de restitution au client, par ordre de priorité : • Acquisition du Credit Transfer • Restitutions associées au Credit Transfer (statuts, rejets...) • Acquisition du Direct Debit • Restitutions associées au Direct Debit (statuts, rejets...) • Autres restitutions (relevés d’opération, relevés de compte...) • Les guides sont en français et s’adressent principalement à des acteurs français (banques, entreprises, éditeurs...)

6. Généralités Avancement des travaux • Travaux lancés le 23 janvier 2007 • En parallèle, travaux sur le Relevé de Comptes 120c avec émission d’une circulaire sur son évolution (www.cfonb.org) • Remontée de plusieurs « Change Requests » à destination de SWIFT • Première version du guide pour l’acquisition des virements (Credit Transfer) a été publiée par le CFONB/GUF. Cette première version couvre : • Les ordres de virement • Les ordres de virement déplacé • Les mises à disposition de fonds • Les SWIFT to Cheque • Sont ou seront présentés de manière détaillée : • Le virement SEPA Puis, • Le virement international non SEPA, le virement déplacé et le virement de Trésorerie Puis, • Le VCOM et éventuellement les Lettres-Chèques

7. Découpage des guides Découpage des guides

8. Découpage des guides Structure des guides en 4 parties • Les règles générales : elles ont un caractère transversal qui ne s’appliquent pas à un message en particulier (règles sur XML, le format des montants, les caractères autorisés...) • Les règles particulières : elles précisent des règles d’utilisation dans le contexte d’un message (par exemple, l’acquisition des virements) • Les descriptions détaillées : elles précisent des modes d’utilisation des données dans un contexte métier global (guide générique) ou dans un contexte métier particulier (guides spécifiques) • Les exemples : ils permettent d’illustrer les guides spécifiques dans la syntaxe XML

9. Découpage des guides Principes de recommandation • Aux définitions et règles d’usage de l’UNIFI, des commentaires sont ajoutés à chaque élément du message. Ils permettent : • de donner une précision sur la nature de l’élément • de faire référence à une partie du guide où l’élément est détaillé • de donner un statut pour un contexte donné :

10. Présentation du message Présentation du message

11. Présentation du message Structure du message pain.001.001.02 • Un message composé de 3 blocs correspondants à 3 niveaux • Des éléments composites • Dans le message • Par le biais de « End Points » • Des éléments codifiés faisant référence à des codes internes ou externes GroupHeader [1..1] Niveau Message Payment Information [1..n] Niveau Lot CreditTransferTransactionInformation [1..n] Niveau Transaction

12. Présentation du message Les informations gérées par le message • Le message permet de transporter un nombre important d’informations : • Des informations de routage (concernant l’émetteur, la banque d’acheminement) • Des données de contrôle (montant total, nombre de transactions) • Des données exploitables pour le traitement du fichier (Grouping,Batch Booking) • Des références (de fichier, de lot, de transaction...) • Des informations sur les niveaux de services (« scheme », service associé...) • Des détails sur les différents intervenants (payeur, payé, banques concernées...) • Des détails sur les comptes de certains de ces intervenants • Des informations sur la répartition des frais du paiement • Des informations sur les montants des transactions • Des détails sur d’éventuelles opérations de change • Des instructions spécifiques (pour les chèques, pour le payé...) • Des informations sur la nature du paiement • Des données nécessaires aux déclarations réglementaires • Des informations commerciales sur le paiement (avis de paiement, références...)

13. Présentation du message Le « Grouping » SINGLE GROUPED MIXED • L’élément « Grouping » (index 1.7) permet de donner une information sur la structure du message : Cette information sera ignorée, les messages seront tous interprétés comme « MIXED » Group Header Group Header Group Header PaymentInformation 1 PaymentInformation 1 PaymentInformation 1 Transaction Information 1 Transaction Information 1 Transaction Information 1 Transaction Information 2 Transaction Information 2 PaymentInformation 2 Transaction Information 2 Transaction Information 3 Transaction Information 3 PaymentInformation 3 PaymentInformation 2 Transaction Information 3 Transaction Information 4 PaymentInformation 3 Transaction Information 5 Transaction Information 6

14. Les données « clés » Les données « clés »

15. Les données « clés » Les intervenants et scénarios de paiement Ultimate Debtor D.O. Initial Ultimate Creditor Bénéficiaire final Bénéficiaire Debtor Payeur Creditor Payé Donneur d’Ordre (D.O.) Initiating Party Emetteur Forwarding Agent Banque d’achem. Debtor Agent Banque du Payeur Creditor Agent Banque du Payé Intermediary Ag. Banque interméd. Scénario de paiement déplacé Intervenants non financiers Intervenants financiers

16. Les données « clés » Zoom sur le Payeur (Debtor) • Structure de l’élément Debtor (index 2.15) avec « End Points » • Contraintes liées au règlement européen 1781/2006 • Dans certains cas, la banque d’exécution garantit les données du titulaire du compte à débiter (donc du Payeur). Elle doit donc les extraire de son propre Système d’Information. • Pour ces cas, la banque écrase toute information renseignée au niveau du Payeur, y compris des identifiants particuliers qu’il souhaite transmettre au bénéficiaire (mais qui ne sont pas gérés dans le SI de la banque).

17. Les données « clés » Les références • Les références techniques • La référence fichier : non gérée dans le corps du message • La référence message (MessageIdentification, index 1.1) • Les références fonctionnelles ou comptables • La référence de lot (PaymentInformationIdentification, index 2.1) : requise en cas de comptabilisation globale car restituée sur le relevé de compte • La référence de transaction (InstructionIdentification, index 2.25) : recommandée pour la comptabilisation unitaire, sinon on prend la référence de bout en bout • La référence de bout en bout (EndToEndIdentification, index 2.26) • Seule référence obligatoire et transportée dans toute la chaîne de traitement • Les références commerciales • La référence du paiement (RemittanceIdentification, index 2.78) • Le numéro de référence du document (ReferredDocumentNumber, index 2.92) • La référence du bénéficiaire (CreditorReference, index 2.105)

18. Les données « clés » Les services associés au paiement • L’identification du type de service attaché au paiement • Plusieurs éléments regroupés dans un bloc présent au niveau Lot et au niveau Transaction. Le niveau lot est recommandé. Si le bloc est présent au niveau lot alors il est exclu au niveau transaction. Le bloc est composé de : • L’identification de la nature du paiement • La nature de paiement est déterminée par le « Purpose » (index 2.64) • Si le « Category Purpose » a vocation à être exploité par la banque du Payeur, le « Purpose » est destiné au bénéficiaire. Par conséquent, la banque n’effectue pas de contrôle de cohérence entre les deux éléments • Il est codifié de manière pré-définie (ex : INSU, SALA...) ou avec des codes propriétaires

19. Les données « clés » Les modes de règlement

20. Les données « clés » Les modes de comptabilisation • Deux modes de comptabilisation sont possibles : • La comptabilisation globale (par Lot) • La comptabilisation unitaire (par Transaction) • L’élément «Batch Booking » (index 1.4) permet de préciser si : • La comptabilisation est globale : valeur = « TRUE » • La comptabilisation est unitaire : valeur = « FALSE » • Si l’élément n’est pas renseigné (optionnel), il est interprété comme « FALSE » MAIS : Le mode de comptabilisation est généralement géré par accord bilatéral entre la banque et son client. Dans tous les cas, cet accord prévaut. • Rappel : en cas de comptabilisation par lot, la référence de lot (Payment Information Identification) est requise.

21. Les données « clés » La date d’exécution demandée • La date souhaitée par le client pour l’exécution de sa remise est renseignée dans l’élément « Requested Execution Date » (index 2.13) • Cette date est définie par l’UNIFI comme la date de comptabilisation au débit du client • Cette date est définie dans le cadre du SEPA comme la date de comptabilisation au débit du client • Actuellement, c’est la date de règlement qui est spécifiée par les clients pour les virements domestiques Par conséquent : Analyse d’impact à prévoir dans les chaînes de fabrication des ordres de virement UNIFI

22. Les données « clés » La balance des paiements • Le bloc Regulatory Reporting (index 2.67) permet de gérer les déclarations réglementaires (CRP pour la balance des paiements) pour les opérations demandant une déclaration. • Ce bloc permet de récupérer : • Le code économique : code de l’élément « Regulatory Details », index 2.73 • Le montant : si le montant n’est pas renseigné à ce niveau (index 2.74), il sera pris au niveau de la transaction (index 2.38 ou 2.40) • Le code pays est récupéré du système d’information de la banque si l’intervenant non-résident est le client de la banque (Payeur). Sinon, il est récupéré au niveau de l’intervenant concerné dans le message (s’il est renseigné).

23. Les données « clés » Les informations commerciales du paiement (Remittance Information) • Le message permet de présenter ces informations de manière structurée ou non structurée, sans limite d’occurrences dans les deux cas : • L’élément non structuré (index 2.85) prévoit 140 caractères libres • L’élément structuré (index 2.86) est composé de 22 éléments Dans le contexte actuel des systèmes d’échange, il est recommandé de renseigner les informations de paiement de manière non structurée avec une seule occurrence. • Les modalités de circulation de ces informations sont gérées dans le bloc « Related Remittance Information » (index 2.77)

24. Le message du Virement SEPA Le message du Virement SEPA

25. Le message du Virement SEPA Le Virement SEPA (Eligible SEPA) • Virement en euro • Virement à l’intérieur de la zone SEPA y compris les opérations nationales • Tout montant • Non urgent • BIC/IBAN obligatoire (pour les comptes Donneur d’ordre et Bénéficiaire) • Référence (35 caractères) et libellé de l’opération (140 caractères) transmis intégralement de bout en bout

26. Le message du Virement SEPA Le message Virement SEPA (Eligible SEPA) • Devise uniquement en « EUR » • BIC/IBAN obligatoire pour le Payeur et le Payé • Méthode de paiement « TRF » • Payment Type Information interdit (ignoré) au niveau transaction • Service Level = « SEPA » si renseigné • Charge Bearer à « SLEV » au niveau Lot • Pas de montant équivalent • Informations sur le paiement de manière non structurée

27. Questions ?