Prélèvements SEPA: Date Butoir 1er Février 2014

[Turbo-057]

Question pour ceux des banques françaises comment abordez vous la problématique des white et black liste ?

De même vis a vis des créanciers quand il s'agit d'un nouveau vous ne le connaitrez que lorsqu'il enverra le premier prélèvement donc comment faire pour stocker le créancier et son mandat AVANT que le prélèvement ne se présente ? Car cela compléxifie la gestion de ces fameuses listes ...

 

[Turbo-057]

Problématique de la Volumétrie

Auparavant chaque créancier divisait ses prélèvements pour les envoyer par banque en fonction de la banque de son client.
Ce n'est plus le cas en mode SDD, en effet le créancier envoi a sa banque qui va ensuite faire les prélèvements soit en interne soit chez les autres banques.
Résultat pour de gros créanciers, genre fournisseur d'energie, provideur telephonique, ... on peut se retrouver avec des volumes multiplié par mille voire 10 000 ...

Certains sont ils face à cette problématique ?
Avant quand on avait 10 000 clients chez un fournisseurs on recevait 10000 instruction.
Maintenant si on a ce fournisseur en compte chez soit et qu'il a plusieurs millions de clients on recoit plusieurs millions d'instructions à executer ... le cout de traitement (durée, consommation, stockage ...) de 10 000 opérations n'étant pas le même que le cout de traitement de plusieurs millions ce n'est donc pas neutre.

Certains ont ils déja abordés/connus cette problématique chez eux ?

 

[LMDP]

Coté "créancier", j'ai effectivement plusieurs clients qui profitent du passage à SEPA pour regrouper le traitement de leurs paiements auprès d'une seule banque. Par contre, côté "banque", je n'en ai pas encore rencontré qui serait ennuyée de voir les volumes traités (et facturés) s'accroitre.

Concrètement cependant, je travaille aussi pour de petits établissements, dont l'architecture et la technique ne sont tout simplement pas dimensionnés pour absorber une multiplication par 100 des volumes d'opérations. Je pense à une banque qui traite environ 100.000 paiements par jour, ce qui implique parfois des temps de traitement proche d'une heure, si demain, elle devait multiplier ce volume par 20, il y aurait un gros problème. Mais assez logiquement, ce cas de figure ne devrait pas se produire : quand le client s'appelle, par exemple, France Telecom, il ne va normalement pas s'adresser à la petite banque de province pour traiter un million de SDD par mois.

Pour le cas très improbable ou un très gros remettant sollicitait l'un des petits établissements que je connais, et bien celui-ci devrait tout simplement refuser ce client. Mais encore une fois, je ne vois pas comment on pourrait aboutir à cette situation, car un créancier qui cherche une banque capable de traiter ses très gros volumes de SDD va procéder par appel d'offre et mise en concurrence des banques, ne vont donc répondre, par définition, que celles qui sont à même d'absorber la charge.


Edit : et pour répondre à la question précédente des black et white list, pour l'instant, beaucoup de mes clients ne savent même pas que ça va bientôt exister. Je parle bien des banques. Vu le retard pris sur SEPA, la question des black et white list ne fait, à ma connaissance, même pas l'objet d'études préalables.

 

[Turbo-057]

Disons que la on viens de recevoir un créancier assez important pour lequel en moyenne on avait a peu pres 10 000 du coup on recevait 10 000 opérations par fichiers.
Et la ils nous envoi un fichier de 345 000 opérations en une fois. le temps de traitement est clairement plus long et plus cher, consommateur de ressources systèmes. Sans compter l'espace disque de stockage de ces données 10 ans.
Ce qui m'inquiéte c'est surtout si l'on cumule ce type de créanciers un, 2, 3 ca passera dans l'infra actuelle mais si on en rajoute une centaine ... il faut anticiper un minimum et comme aucune entreprise n'a de réel vue de leur migration c'est complexe ... Et pour augmenter l'infra il y a toujours un délai minimum.


Quand a la facturation comment dire pour l'heure le service était "offert" donc je sens que la discussion va avoir lieu pour une éventuelle facturation future.
Alors certes l'infrastructure va l'absorber mais si on se récupère une trentaine de gros créanciers qui le même jour nous envoi l'entièreté de leur volume regroupé ... cela risque de conduire a une demande d'augmentation de l'infrastructure (facile suffit de passer un coup de fil et de payer le nécessaire en plus) mais dans ce cas quand on va envoyer la facture au service commercial je pense qu'il va revoir son optique de gratuité. Si on le facture là clairement plus d'objection a augmenter la note d'infrastructure.

Comme très peu de gros créancier ont migrés pour l'heure je ne suis pas certains que ce problème se voit meme chez les mastodontes bancaires si des Oranges collent toutes leurs opérations dans une seule banque et bien il va falloir adapté l'infra j'ai des amis bossant dans certains grand groupes francais et meme chez ces derniers l'infra ne pourrait répondre sans accroitre cette dernière.

 

[LMDP]

Service offert ! Wahou !

Il me semble que si le créancier multiplie son volume par 35, que, bien entendu, cela va avoir un coût non négligeable chez vous (notamment en stockage, ainsi que tu le mentionnes), et que ce coût n'est pas répercuté sur le créancier, alors celui-ci pourrait, au minimum, convenir d'envoyer ses opérations sur 3 jours, par bloc de 100.000 environ, plutôt que 350.000 d'un coup.

Certaines banques n'hésitent pas à le préciser, ainsi, la dernière que j'ai interrogé m'a répondu qu'elle pouvait traiter théoriquement n'importe quel volume, mais qu'elle recommandait, pour un temps de traitement optimal, de se limiter à 100.000 opérations par fichier.

 

[Turbo-057]

L'aspect marketing et commercial c'est pas chez moi. Je suis en charge de la mise en place du projet.
Donc pour le moment c'est ainsi surement pour favoriser le gain de nouveaux clients mais bon. Moi je ne suis pas vendeur

Le stockage a la rigueur c'est le cout le moins genant l'espace disque est une denrée dont le cout au To ne cesse de baisser.
Celui qui me pose un soucis c'est surtout la consommation système vu avec les ingénieurs systèmes, si je la limite ca prend du temps a traiter et donc peu réduire le débit du flux de paiement si je laisse la porte ouverte sans limite ca risque de ralentir d'autres traitement n'ayant rien a voir. Bref le bon compromis est à trouver. Pour le moment ce flux ne me pose pas de soucis ca passe sans problème.
Mais si on cumule des clients de ce genre il faut lisser la charge car le max c'est 1Millions / jour donc 5 de ce genre et ce sera a stock sans compter qu'il n'y a pas que les flux SDD mais également les SCT et autres flux dans le meme système de paiement.

Je pense qu'une recommandation en ce sens de diviser en plusieurs jours n'est pas inintéressante meme si coté Front on dit forcément que cela ne se fait pas d'imposer des contraintes aux clients ... mais dans ce cas je leur présente une facture d'infra en retour. Ou alors éventuellement un envoi du fichier à X jours de la date d'execution cela permet de faire tourner de nuit ou en we dans des plages beaucoup plus souple.

 

[Turbo-057]

Pour les concernés, pour l'heure la migration ne va pas vraiment en s'amplifiant.
Volume restant assez stable. Toujours pas d'affolement en vue.

Et toujours la date du 1er février 2014 visée.
Pour le volet banque la plupart sont prêtes a priori (sauf la grosse interrogation des volumes qui vont explosés probablement)
Par contre coté entreprise alors là ca risque d'etre folklorique. Vont tous débarqués pendant les fêtes ou alors la veille de la mise en place ou encore mieux le lendemain...

Meme les impots Fr (donc l'état) n'a pas encore migré tout va bien on y croit.

Dernier chiffre ici : [lien réservé abonné]
ou ici : [lien réservé abonné]

On voit meme une légère diminution sur le SDD par rapport à aout (surement les congés)

Maintenant on est en mode attente de mon coté tout est maintenant prêt ... sauf les clients lol
Et on m'a du coup balancé la responsabilité et les joies d'un nouveau projet du meme genre, la migration des autres moyens de paiement vers les news normes XML pour 2016. Splendide.

Faudrait dire aux politiques de laisser faire les banquiers au vu des couts que cela va représenter en investissement tous ces changements les clients vont bien le payer à terme. Et le gain client me parait plus que négligeable.

 

[hargneux]

Les impôts c'est prévu pour le 16 janvier ! en espérant que les test auront été fait avant....
Dans les derniers avis ils ont indiqué l'ICS et le RUN.
D'autres ne peuvent pas emettre autant de lignes qu'ils en ont besoin....

Pour le reste ca patauge ferme, certaine banque rejette les prélèvement RECUR s'ils n'y a pas eu de FIRST avant, mais comme c'est pas une obligation d'autres ne le font pas.
Bon les banques sont prêtes y compris les plans B et C mais ca va couter cher à ceux qui seront à la traine.

 

[LMDP]

Les créanciers dont je m'occupe seront tous prêts à temps

Au niveau des banques, j'ai encore pas mal de réserves : procédures pas au point, information dispersée, formation plus que limitée des équipes... techniquement, ça fonctionnera, par contre, pour le reste...

Phénomène un peu inquiétant, face au nombre très élevé de cas particuliers (le RCUR précédant le FRST est un bon exemple), beaucoup d'établissements réagissent de la même manière : en levant les contrôles ! La banque du débiteur dit "si je contrôle de manière rigoureuse, je vais bloquer trop d'opérations, c'est à la banque du créancier -variante : c'est à mon chef de file / c'est au CSM- de contrôler, donc je ne contrôle quasiment plus rien". Problème : les compensateurs se disent la même chose, et la banque du créancier estime que "c'est au créancier d'émettre des opérations convenables". Au final, et c'est quelque chose que je constate au quotidien, plus personne ne contrôle quoi que ce soit, avec tous les risques, notamment de fraude, que cela implique. Je ne l'ai pas vu, mais un banquier m'a même parlé d'un établissement qui a tenté d'annuler un SCT émis en double grâce à un SDD REVERSAL. Les pros du SEPA apprécieront le niveau !

Côté créancier, le faible niveau d'avancement semble s'expliquer par un raisonnement qui consiste à croire que "on nous a fait le coup pour le passage à l'an 2000, on a engagé des budgets importants et ça n'a servi à rien, alors cette fois, on ne va pas se faire avoir". En plus, l'infos à destination des particuliers, indiquant que les autorisations de prélèvement restent valable et que pour le débiteur, le passage à la norme SEPA ne change rien est, elle, bien passée et largement relayée. Donc beaucoup de créancier attendent et estiment que c'est à leur banque de faire le boulot. Ils n'ont clairement pas compris que ce projet n'a rien à voir, ni sur le fond ni dans la forme, avec le passage à l'an 2000.

Pour ma part, je reste donc extrêmement pessimiste.

 

[Turbo-057]

Nous ca va pour le moment ca marche pas mal mais bon les volumes sont encore très light hormis 2-3 gros clients (opérateurs télécom ...) ca reste très faible.
Pour les RECUR nous on a pris le parti de l'accepter meme sans le FIRST. Mais bon cela peut au pire être modifier ensuite facilement. Et c'est plus simple que de balancer des Rejets au client. (histoire d'avoir une bonne relation commerciale)

Pour les tests ici en général les commerciaux nous informent tel client arrive ... et boumm ils attaquent en Prod direct sans test alors des fois c'est assez fun genre fichier pas top et allez 5 a 10 000 rejets, on recommence.
On a meme un client qui avait automatisé un peu trop confiant son système il a du coup imprimé des milliers d'avis de non paiement pour envoyer a ses clients ... heureusement qu'il les a pas posté

Niveau plan B et C ici rien n'a été acté par l'ABBL, je ne savais pas que la France on avait prévu.
Les seuls plan prévu le sont par les banques elles-mêmes. (Cellule de telephone pour support, assistance migration ...) et ca va finir en manuel pour ceux qui sont a la ramasse.

@LMDP ben j'en connais qui cherche des SSII pour leur faire leur migration (Et ils n'ont rien débuté) la sont en mode crise ... celui qui précède le mode panique.

Magnifique le coup du SDD Reversal et y a eu surenchère avec un refus SDD sur le retour des fonds ? histoire de faire un beau bordel.

Pour les autorisations de prélèvements quand on sait comment ca a été géré coté banque je serai curieux de voir le créancier en demander une copie a la banque pour fournir a son client qui a fait opposition sur le prélèvement.

Le gros hic coté Banque c'est la formation des service BO, ou commerciaux sur ces services SEPA.
Ils ont du mal a comprendre qu'il faut s'adapter a ce nouveau langage et mode de travail.
La plupart me sorte que c'est technique et que c'est pas leur job. Et meme en insistant c'est difficile a faire passer y a un vrai blocus chez certain et vu que des fois la hiérarchie cautionne pas évident.

J'avais connu ce problème pour le SCT en 2004 je m'occupais du sujet (mais pas encore en tant que chef de projet) et ca avait été délicat mais l'ajustement s'est fait après quelques mois. Mais les clients ne changeait quasi rien en SCT l'époque c'était plus light.

La on a eu des clients qui ne font meme pas la nuance entre SCT et SDD (notamment certaines petites banques) et ils sont totalement perdus.

 

[Turbo-057]

Je serai bien en congé le 2 février pour contempler de loin mais je doute que mes chefs les acceptent

 

[Turbo-057]

Question

Par rapport à EndDateRegulation.
La norme impose ISO20022 cela impose t'il donc également de virer les MT940 au profit des messages ISO XML correspondant : camt.053
J'ai souvent ce type de demande de certains "clients" or le soucis souvent le client a bien un compte en Euro mais sur lequel transite des ordres SEPA et des ordres en Euro non SEPA. Et je ne peux faire le distinguo par opérations sur l'extrait.
Du coup la on laisse le choix au lcient soit format Mt940 soit format XML.

Comment avez vous aborder cette problématique ?

 

[LMDP]

Bonjour Turbo-057,

L'utilisation obligatoire de la norme ISO20022 s'applique aux opérations SEPA entre prestataires de services de paiement, et lorsqu'un émetteur "professionnel" transmet une remise de paiement à son PSP, elle ne s'applique pas en matière de restitutions du PSP vers le client.

Le MT940, c'est à dire l'extrait de compte restitué par le PSP au client est hors du champ d'application des Rulebook et de la Directive 260/2012. Il n'y a aucune obligation d'utiliser la norme ISO, et aucun problème à restituer des opérations SEPA dans un relevé de compte au format MT940.


Cf extraits de la Directive :

Annexe de la Directive 260/2012 : "La norme, pour le format de message visé à l’article 5, paragraphe 1, points b) et d), doit être la norme ISO 20022 XML"

Messages visés à l'article 5, §1, points B et D : virements et prélèvements SEPA transmis entre prestataires de services de paiement, (point B) et opérations de virements et de prélèvements initiés en nombre par un client-émetteur qui n'est pas un consommateur (point D. Je ne reproduis pas le texte complet et exact, mais pour moi, il n'y a pas d'ambiguïté)

La plupart des banques avec lesquelles je travaille proposent d'ailleurs des restitutions au format CAMT ou au format SWIFT (voire des fax..), au choix du client.

 

[Turbo-057]

Pour ma part je suis positionné coté Banque, mais j'ai des clients qui sont des banques également.
Du coup le client n'est pas forcément un corporate la c'est dans le cas du direct.
En indirect la je dialogue en mode bank to bank. (vente du service aux banques n'ayant pas envie d'investir ) ce mode est un peu plus complexe que le direct ou la la relation est facilement définie.
En mode indirect j'ai eu des questions qui te ferait frémir sachant qu'elles viennent de banquiers.
La plus fréquente étant bien entendu, peut on rester sans rien changer.

Je vois qu'a priori tout le monde a fait le choix de proposer les 2 options.
La directive reste encore assez flou sur le volet "extrait" mais de toute manière c'est de la valeur ajouté pour plus tard vu que d'ici 2-3 ans on aura également d'autres canaux paiements qui vont migrer vers la norme XML.

 

[LMDP]

Ah oui, je n'avais pas pensé à ce cas ! Le client est aussi une banque...

Quoi qu'il en soit, d'après ma compréhension de la Directive, le format ISO est obligatoire pour les flux de SCT et de SDD, pas en cas de restitutions de type "avis d'opération" ou "extrait de compte". Donc même si le client destinataire de la restitution est une banque, je ne pense pas qu'il y ait contre indication règlementaire à conserver le MT940.

Par contre, dans le cas cité du client qui est aussi une banque, on ne parle pas d'un sous-participant, qui bien que n'étant pas branché en direct émet et reçoit des opérations SEPA ? On parle bien de la banque qui, ne sachant traiter les SCT / SDD transmet des opérations aux format PAIN.001 ou PAIN.008 à un autre établissement ?

Dans le premier cas (banque sous-participante), ça ne me choquerait pas qu'il n'y ait pas de restitution CAMT, certains utilisent des outils dédiés qui leur permettent de suivre plus rapidement et avec plus de précision les flux échangés avec leur chef de file.

Par contre, la banque incapable de traiter des opérations "pacs" qui transmet des "pain" à un confrère pour qu'elle gère à sa place, ça, effectivement, j'ai jamais vu ! (Et cela voudrait dire que la banque en question n'est pas adhérente SEPA !). C'est ce cas là que vous évoquez ?


PS : effectivement, le XML devient la norme, ne pas l'utiliser, c'est simplement reculer l'échéance.

 

[Turbo-057]

J'ai les 2 cas, le classique sous participant qui reçoit les "pain" client et me fournit du "pacs" pour transmission vers EBA.
Et également l'autre cas, j'ai bien des banques qui n'ayant pas de système "Sepa" me balance les "pains" reçu de ses propres clients (001,008 et 007) - (Mais ils sont déclarés néanmoins dans les systèmes SEPA mais n'ayant de systèmes capable de les traiter ils les envoient direct.
Au début je pensais même a une erreur de la banque en question mais non on m'a confirmé qu'ils allaient faire cela.

 

[Turbo-057]

https://www.moneyvox.fr/votre-argent/actualites/41829/prelevement-sepa-un-premier-bug-importance-touche-41.300-clients-edf

Ca commence ...
Le 1er publié et surement pas le dernier ...

 

[LMDP]

https://www.moneyvox.fr/votre-argent/actualites/41829/prelevement-sepa-un-premier-bug-importance-touche-41.300-clients-edf

Ca commence ...
Le 1er publié et surement pas le dernier ...

Ca n'a duré que 2 jours, vraiment ? Parce que chez moi, ça fait presque 1 mois que l'on reçoit les RCUR d'EDF avant les FRST... (par charité, je ne vais pas aller vérifier les dates exactes dans le système). Et des confrères banquiers m'ont signalé que dans un premier temps, EDF se défaussait sur les banques lorsque les clients mécontents appelaient.
En tout cas, s'ils corrigent leurs traitements, je vais tout de suite avoir bien moins d'opérations en suspens.

 

[Turbo-057]

Ca c'est un problème bien connu le coup des Recur et First.

 

[Turbo-057]

Après le bug de la soc gen les prochains sont sur les rails
Toujours une volumétrie faible voire ridicule ... le gros rush s'annonce s'annonce ... mais rien ne vient.
Hormis quelques clients affolés n'ayant pas encore débuté
Et chez vous pareil ?

A J-23 je commence bien a me demander ce que ca va être post 1er février.
Cela demande encore si l'on ne peut pas continuer a accepter les anciens ordres.
Et sans parler du fait qu'on commence a s'amuser a corriger les fichiers des clients pour éviter trop de refus.