+33 (0)1 44 30 70 80 numerique@cinov-it.fr

Il est facile de constater les traumatismes provoqués, ressentis par tout un chacun dans l’exécution de ses ordres de paiements, et, de prendre fait et cause contre nos bonnes vieilles banques françaises. Certes elles ne sont pas exemptes de tout reproche : loin s’en faut… je ne reviendrais pas sur leur absence de communication et d’information à l’encontre des plus petits de leurs clients, que ce soit les PME, les TPE et les particuliers, tous n’ont eu droit à rien ou tellement pas grand chose que l’on peut l’assimiler à rien. Il est tout aussi vrai que la période de transition va leur permettre de fiabiliser leur organisation, leur système d’information et, je ne peux que l’espérer, leur communication.

Regardons en face du côté des remettants… et bien là aussi, on trouve de tout et du grand n’importe quoi. En voici quelques exemples :

  • un remettant, établissement financier français, lorsqu’il voit ses SDD rejetés pour quelque raison que ce soit, les représente via sa filiale belge, nouvel ICS, même RUM, même coordonnées destinataires. En voilà un qui a parfaitement saisi les opportunités du SEPA… cela peut s’apparenter à de l’escroquerie, et, est parfaitement contestable par les débiteurs, étant donné qu’ils n’ont rien signé vis-à-vis de cet ICS. Le seul souci est que dans le meilleur des cas, s’ils ont fait une opposition sur le créancier français, celle-ci n’a pu être reconduite sur l’ICS belge, pour la simple et bonne raison que la continuité des oppositions n’adressaient que les prélèvements franco-français et qu’il est impossible de lier l’ICS français à l’ICS belge, d’où la nécessité de connaître ses droits (refus et demande de remboursement) et les obligations de ses créanciers (prénotification 14 jours calendaires avant l’échéance) et de sa banque (alerte sur l’arrivée d’un prélèvement remis par un nouveau créancier)
  • un remettant, lui, a du mal à assimiler la Référence Unique du Mandat. En effet, sa remise de plusieurs centaines de SDD ne porte qu’une seule RUM initiée à 1 inscrite sur chacun de ses mandats contenus dans chaque SDD. Comme unique, on ne fera pas mieux !
  • des remettants ont migré leurs prélèvements français vers le SEPA Direct Debit… pour ce faire, ils ont bien renseigné leur RUM avec le « ++ » stupide recommandé par le CFONB, ont émis leur FIRST avec un amendment indicator à TRUE, et, renseigner leur ancien NNE dans la zone afférente à l’ancien identifiant du créancier. Tout allait pour le mieux dans le meilleur des mondes. Ils remettent le couvert et présentent un premier RCUR. Là pour une raison inconnue, ils modifient leur RUM en omettant le « ++ » et se retrouvent devant une masse de rejets venant de certaines banques, alors que d’autres les acceptent sans sourciller. Ce sont les premières qui ont raison : la RUM a bien été modifiée, il fallait soit présenter un RCUR avec la même RUM que le FIRST, ou, émettre un nouveau FIRST, amendment indicator à TRUE et l’ancienne RUM renseignée dans la zone amendable

 

Un dernier constat qui ouvre de belles opportunités pour les 30 prochaines décennies :

 

J’ai souscrit sur janvier et février deux contrats auprès de deux nouveaux prestataires : l’un dans la téléphonie, l’autre pour une mutuelle de santé. A chaque fois, j’ai fait le tour des offres et regarder particulièrement les fonctionnalités « paiements », pour lesquelles, je le sais, je peux être quelque peu casse-pieds.

Commençons par l’opérateur de téléphonie : je vais en magasin. Je trouve un conseiller super sympa, qui comprend mon besoin et nous convenons d’une offre adaptée à mes besoins. On passe à l’enrôlement et tout va bien jusqu’à la saisie des coordonnées bancaires. « J’ai besoin de votre RIB » me dit-il. « Je n’ai qu’un BIC et un IBAN à vous donner » répondis-je. « Pas grave, je sais comment le traduire en Code banque, code guichet, numéro de compte, clé RIB »… sauf, que mon BIC/IBAN est espagnol et que la structure du compte espagnol n’a rien à voir avec la structure d’un compte français, d’où la normalisation BIC/IBAN portée par le SEPA… aucun opérateur de téléphonie en France n’est compliant SEPA. Ils ont tous monté une plateforme de paiement dans laquelle se déverse les ordres de paiements de leurs organisations et qu’ils convertissent en SDD ou SCT selon le cas… en l’absence de tout respect de la conformité et de l’exhaustivité des opportunités apportées par la DSP, les règlements associés, les Rulebooks et les Guidelines, bref tout ce qui contribue au SEPA.

Deuxième exemple, les mutuelles de santé… là encore, je fais une étude de marché, mais cette fois, je le fais par Internet : on est de CINOV-IT ou on ne l’est pas ! Très souvent, je tombe devant la même problématique que mon opérateur de téléphonie. D’autres fois, on me laisse saisir un BIC et un IBAN mais ES ne passe pas : pas mal, mais peut mieux faire encore… L’une d’entre elles m’annonce dès la première page de l’enrôlement de « Saisie de vos coordonnées civiles et postales selon la norme SEPA » : je suis aux anges… et toutes les cases vont bien conformément à ce que demande l’ISO 20022… je plane littéralement… et puis, badaboum, catastrophe, arrive la saisie des coordonnées bancaires qui me demande « Code banque », « Code guichet », « Numéro de compte », « Clé RIB ». La chute est dure…

 

Rassurez-vous j’ai pu trouver une solution pour les deux cas… un détournement pas un ultimate debtor pour la téléphonie, sans que l’opérateur de téléphonie ne soit en mesure de le gérer, ni ne  s’en rende compte, et, une mutuelle avisée, innovante full compliant SEPA… C’est normal, je l’ai accompagnée en janvier 2013 dans cette migration  : on n’est jamais aussi bien servi que par soi-même.