1- État d’avancement au niveau de la communauté européenne
Nous avons démarré effectivement le 9 octobre à 00h00, comme prévu.
Sur les flux intra-communauté SEPAmail, qui représentent entre 80% et 82% de l’ensemble des flux et 90% à 95% des banques françaises, nous n’avons aucun souci : tout fonctionne parfaitement.
En revanche, sur les flux extra-communauté SEPAmail[1], nous avons beaucoup plus de soucis dont je vais vous présenter une synthèse.
Utilisation des certificats / listes d’Autorités de Certification (AC) de confiance
Des failles de sécurité sont apparues dues à une mauvaise implémentation QWAC PSD2[2] en tant qu’émetteurs ou, en tant que récepteurs, des certificats EV TLS[3]. Nous nous sommes rendu compte que parmi les 50 Routing and Verification Mechanisms (RVM) connectés (sur un total de 65), une quinzaine avait encore des problèmes de certificat.
Utilisation des BIC[4] 8 au lieu des BIC 11
Nous nous sommes retrouvés avec des RVM, voire des Prestataires de Services de Paiement (PSP), qui n’utilisent pas les BIC 11 mais uniquement des BIC 8, contrairement aux spécifications de l’API (Application Programming Interface) et à celles de l’European Payment Council (EPC). Nous avons donc demandé une clarification immédiate à l’EPC parce que cela pose un certain nombre de problèmes, avec les rejets associés.
Utilisation de champ optionnel «Remittance Information» pour les sous-comptes
Beaucoup de rejets liés aux établissements de paiement et aux établissements de monnaie électronique, qui sont normalement situés dans la Remittance Information optionnelle. Certains ont considéré que quand ils n’avaient rien à mettre, il fallait mettre un tableau vide, alors que d’autre n’ont rien mis du tout, ce qui occasionne un rejet. Ces erreurs d’interprétation des spécifications sont un point sur lequel j’avais alerté l’EPC il y a deux ans : avec des formats ultra permissifs où chacun peut faire ce qu’il veut, c’est un cauchemar en termes d’interopérabilité.
Détermination du BIC à partir de L’IBAN
Certains PSP rencontrent encore des difficultés à appliquer les règles de l’EPC, notamment à utiliser les National Institution ID lists. En France, nous n’avons pas de souci à ce propos car notre liste (dont la gestion est assurée par la Banque de France) est stable et disponible. Mais d’autres communautés n’ont pas ce type de liste, ou bien il y a des écarts entre la liste nationale et l’EPC Directory Service (EDS), ce qui crée des problèmes d’atteignabilité.
Rejet de VoP requests émis par des PISP (qui ne sont pas teneur de compte)
Il y a une problématique liée aux PISP. Bien évidemment, nos amis de l’European Third-Party Providers Association (ETPPA, qui regroupe les initiateurs de paiement (PISP) et les agrégateurs (AISP)) sont très vigilants là-dessus car le scheme est asymétrique concernant les PISP, qui sont là en tant que donneurs d’ordres, mais pas en tant que teneurs de comptes. Or certains RVM, notamment en Allemagne, font des vérifications sur l’existence d’un account holding associé au participant. Mais le PISP n’y en a pas, d’où un rejet qui n’est pas normal et, là encore, un problème d’interopérabilité.
Taux important de NOAP (contrôle impossible au niveau applicatif)
Beaucoup de contrôles impossibles au niveau applicatif ou des time out intempestifs.
Nombre important de rejets techniques
Nous sommes en quelque sorte victimes du « plat de spaghettis ». En face de moi, j’ai 70 points d’entrée : 50 RVM et 20 PSP en stand alone. Quand Éric Ducoulombier m’a appelé le lendemain du démarrage, je lui ai dit : « face à un tel plat de spaghettis, il est normal qu’on soit dans une telle pagaille au niveau de l’interprétation des spécifications, avec beaucoup de rejets techniques. L’EPC ne peut pas faire grand-chose, il faut que chacun se débrouille en bilatéral », ce qui fait malgré tout 70 x 69 interactions.
Problèmes d’indisponibilité réseau
Nous étions de chaque côté, à nous dire « Je ne comprends pas, je t’ai envoyé la requête ». « Je ne l’ai pas reçue ». Et puis nous avons eu des retours avec des horodatages (time stamps) dans le passé, voire dans le futur. Il y a donc un souci au niveau réseau, et c’est un peu logique : en interne SEPAmail travaille avec des lignes spécialisées (LS), et donc un réseau privé entièrement sécurisé avec de très gros volumes et aucun problème de disponibilité ; mais quand on passe en cross-border, on utilise le réseau le plus mauvais au monde qu’est Internet.
2 – Point de situation sur DIAMOND2
État des lieux avant l’ouverture du service
156 établissements sont raccordés à SEPAmail.eu, ainsi que 3 prestataires référencés, qui hébergent notamment des banques de taille plus modeste. Les tests que nous avons durant la phase pilote (à partir du 15 septembre) ont notamment montré qu’en cross-border il y avait encore beaucoup d’erreurs en termes de spécifications.
5 autres établissements nous ont fait part de leur intention de nous rejoindre, mais pas avant novembre 2025. Je leur ai rappelé que de ce fait ils n’étaient pas conformes au règlement sur le paiement instantané (IPR).
Les tests de performance ont pu être menées jusqu’à leur terme avec une bonne capacité, puisque nous avons a été jusqu’à plus de 1 000 Transactions Par Seconde (TPS).
Et nous avons donc effectivement démarré le 9 octobre à 0h00.
Suivi du démarrage
5 jours après le démarrage, nous avions reçu 8 millions de demandes d’interrogation. Le démarrage a été progressif : certaines banques sont parties « pied au plancher », d’autres ont démarré plus progressivement. Comme le montrent les graphiques ci-dessous, il y a eu un « big bang » avec une pointe autour du 10 octobre, et nous avons maintenant un trend un peu plus important avec une baisse logique pendant le week end.
Comme je l’indiquais plus haut, pour les flux domestiques (qui représentent 80% à 85%) nous n’avons rencontré aucun problème, alors que nous en avons rencontré sur la partie « interopérée ».
Sur la slide suivante, on voit que du point de vue du donneur d’ordre (émetteur de VoP), le taux (cumulé) de « match » et « almost match » se situe entre 65% et 70%, et que le taux de NOAP est allé en décroissant. On voit aussi que deux adhérents (A et B) ont démarré « pied au plancher » et les autres ont raccordé leurs applications amonts plus progressivement.
Du point de vue du teneur de compte (récepteur de VoP), le taux de match/almost match est encore plus élevé (80%).
En résumé
- Un très bon début: avec une grande satisfaction sur les flux domestiques (à l’intérieur de la communauté SEPAmail) soit près de 85% de tous les flux , mais avec, sur les flux cross-border, des difficultés d’interprétation des spécifications qui devront être résolues soit via des contacts bilatéraux soit via des clarifications au niveau de l’EPC.
- Pas de vagues (à ce stade) au niveau des utilisateurs (Payment Services Users, PSU). On pouvait craindre que les call centers des banques soient submergés de réclamations ou demandes d’explications, mais les dernières informations qui m’ont été remontées par les banques montrent que cela n’a pas été le cas.
- Pas d’impact sur les paiements. On pouvait craindre également qu’en cas de NOAP ou de « no match » les paiements s’arrêtent, mais ici aussi, les dernières informations qui m’ont été remontées par les banques montrent que cela n’a pas été le cas.
Merci de votre attention
***
Hervé Sitruk
Merci Jacques. Qu’en est-il pour les autres pays européens ?
Jacques Vanhautère
Il y a des flux importants des communautés belge et néerlandaise, qui ont elles aussi démarré « pied au plancher », mais qui étaient déjà opérationnelles et avaient donc l’habitude.
Côté allemand, on a découvert qu’il y avait une myriade de tout petits RVM qui ont fait chacun leur propre interprétation. De ce fait, nous avons quelques soucis côté Allemagne.
Côté Italie, avec CBI[5], il n’y a pas de soucis, cela marche bien également.
Marie-Christine Caffet
Parmi les principaux problèmes que rencontrent les médiateurs, il y a les contestations de virements liées aux usurpations d’identité. Il y a sans doute (je n’ai pas le chiffre exact) plusieurs centaines de milliers d’usurpations d’identité par an. Comment faire pour vérifier ?
Jacques Vanhautère
Si quelqu’un donne mon IBAN et saisit « Jacques Vanhautère », la VoP ne va pas vérifier mon identité mais la bonne correspondance entre mon nom et mon IBAN. On peut donc très bien se retrouver dans une situation où si Mme Michu veut faire un virement vers Oussama Ben Laden aux îles Caïman, et si c’est bien Oussama Ben Laden et le bon IBAN, la correspondance sera parfaite. La VoP n’est pas une solution miracle. Ce n’est qu’un des éléments qui va permettre d’éviter les rejets et de lutter contre la fraude à l’IBAN = je substitue mon IBAN par un autre, là, la VOP est parfaitement dans son rôle et le détectera immédiatement.
Hervé Sitruk
Merci Jacques.
[1] Les flux en provenance de l’étranger mais aussi des petits RVM français qui se raccordent à SEPAmail quand ils veulent envoyer des flux vers les banques françaises et ceux des banques françaises qui se connectent directement au travers de l’API VOP sans passer par un RVM.
[2] Certificats Qualifiés DSP2 pour l’authentification de sites web dans l’UE
[3] Certificats à validation étendue
[4] Le code BIC : la carte d’identité de votre banque
[5] CBI et SEPAmail.eu viennent de signer un accord pour la mise en place d’une solution interopérable d’IBAN Name Check – Vérification du bénéficiaire (VoP) (communiqué du 9 octobre 2024)
