Migration SEPA SDD, plus dur sera le retour

En effet, les premiers échanges retour montrent une assez grande hétérogénéité sur les fichiers retours camt054.

Le Message « Bank to Customer Debit Credit Notification» <camt.054.001.02> est le relevé d’opérations qui est envoyé par la banque au titulaire du compte ou à un tiers autorisé à recevoir l’avis. L’avis d’opéré informe le titulaire du compte ou le tiers autorisé, des mouvements de débits et/ou de crédits relatifs au compte. Le message peut concerner plusieurs comptes. Il fournit des informations pour la gestion du compte et/ou le rapprochement comptable.

Il peut servir pour :

  • Rendre compte de mouvements comptabilisés ou en attente,
  • Aviser d’un ou de plusieurs mouvements débiteurs,
  • Aviser d’un ou de plusieurs mouvements créditeurs.

Il peut donner des informations détaillées sur les opérations individuelles qui composent un mouvement. Ce message ne contient pas d’information sur le solde du compte.

Le camt.054.001.02, BankToCustomer DebitCreditNotification , Relevé d’opérations / Avis d’opéré est le fichier XML SEPA correspondant au fichier texte CFONB 240.
Pour le SDD, ce format permet à la banque de l’émetteur de restituer à son client les informations concernant les prélèvements SEPA impayés (rejetés/retournés).
Pour indiquer la nature du rejet ou du retour, la banque utilise un code motif de retour du prélèvement. La liste complète des codes motif de retour possibles se trouve sur le site de l’ISO à l’adresse suivante : www.iso20022.org.

Exemple de codes possibles :

  • AC04 : Closed Account Number (compte clos),
  • AM04 : Insufficient funds (provision insuffisante).

La correspondance entre la codification ISO (sur 4 positions) et la codification CFONB (sur 2 positions) des codes motifs de rejets/retour est disponible dans la brochure « Codes motifs de rejet/retour » sur le site du CFONB à l’adresse suivante : www.cfonb.org

Pour les prélèvements SEPA rejetés/retournés, la nature du R-message est identifiée dans l’élément Additional Information avec le mot code /RTYP/ suivi de :

  • RJCT pour un reject,
  • RTRN pour un return.

Source : Guide d’utilisation du standard ISO 20022 POUR DES RELEVES D’OPERATIONS « Guide d’utilisation du BankToCustomerDebitCreditNotification – V1.1 – 05/2013 »

Pour les entreprises qui automatisaient le traitement des fichiers retours CFONB240 l’exercice est plutôt périlleux. Car pour tester leurs nouvelles chaines de traitements, elles ont du recourir à des fichiers test, crée manuellement par les banques et qui ne reprenaient même pas, pour certaines banques, les données de gestion issues du SDD aller ?
Quels sont donc les moyens d’obtenir alors des fichiers « tests » de qualité ? Basculer en production au plus vite et obtenir réellement des rejets en les provoquant : comptes clôturés, BIC IBAN erronés, auto prélèvement rejeté…la méthode n’est pas des plus orthodoxes, mais permet d’éprouver les chaines de traitement dans un environnement réel.
La vraie vie quoi !

Serez vous prêt ?

Une réflexion au sujet de « Migration SEPA SDD, plus dur sera le retour »

  1. Si l’adaptation des ordres de virement et de prélèvement est relativement bien appréhendée par les entreprises et les banques soucieuses de migrer au système SEPA avant l’échéance du 1er février 2014, il en va tout autrement des flux retours qui sont envoyés par les banques à leurs donneurs d’ordres. A un mois de la date butoir, certaines banques sont encore en train d’adapter leurs systèmes pour fournir des messages XML d’avis d’opérés et d’accusés de réception (camt.054 et pain.002) à leurs clients. Et l’on constate une diversité d’interprétations du standard ISO 20022. Des réajustements en perspective pour 2014…

    Du côté des entreprises le challenge est d’autant plus important que le pool bancaire est large et le système d’information hétérogène. Il s’agit de s’adapter au choix d’implémentation de balises de chaque banque pour remonter la bonne information au format et à la codification attendus par chaque application.

    Ajoutez à tout cela les nouvelles versions des messages qui se succèdent (pendant que nous implémentons la version 2 des messages camt.054.001 dans les banques et les entreprises, ISO publie la version 4 et l’EPC travaille sur la version 3). Pour les messages pain.002 on constate même en ce moment la cohabitation des version 2 et 3, y compris au sein d’une même banque. Sans parler du futur relevé de compte XML (camt.053). Ce travail itératif d’adaptation et les cycles de tests qui en découlent peuvent donner l’impression que le projet SEPA dérape.

    C’est pour ces raisons que chez NEOFI Solutions nous appréhendons la problématique SEPA avec une solution agile, collaborative et autonome.

    Agile car le mapping entre les balises des messages et XML et les informations injectées dans les applications reste paramétrable, rien n’est codé en dur.

    Collaborative car la bibliothèque de la communauté des utilisateurs (NEOFI Link Community) est régulièrement enrichie des nouveaux schémas, formats, versions et traitements élaborés par cette même communauté.

    Autonome car la solution est installée dans le système d’information des entreprises et celles-ci sont formées pour apporter les ajustements par un simple paramétrage.

    Notre Pack Ready for SEPA concentre tous ces concepts et permet une migration des flux entreprise/banque et banque/entreprise en quelques semaines.

    Pour plus d’information : http://www.readyforsepa.com

    Michel COSTANDI
    Directeur de projets
    http://www.neofi-solutions.com

    Suivez l’actualité SEPA sur mon blog : http://blog.michelcostandi.com

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *