Cette release concerne l’évolution des paiements européens du Sepa qui seront irréversibles à dater du 18/03/2024.
L’EPC a prévu une évolution des Rulebooks pour les quatre schemes de paiement SEPA (SCT, SCT Inst, SDD Core et SDD B2B) avec une date d’entrée en vigueur au 18 mars 2024.
Cette évolution prévoit une montée de version des fichiers XML du format ISO20022 version 2009 vers le format ISO20022 version 2019 pour tous les messages SEPA décrits ci-dessus et sera appliquée à cette date sur les systèmes d’échange STEP2 et CORE.
Qualifiée de Bing-Bang par la profession bancaire, cette nouvelle release est majeure car tous les formats des messages sont impactés.
A partir du 19 mars 2024, seuls les fichiers respectant la norme ISO20022 version 2019, contenant les messages PSP à PSP, seront échangeables dans les systèmes de clearing.
A partir de novembre 2025, les fichiers Corporate à PSP devront respecter cette norme.
De même l’utilisation des adresses structurées deviendra obligatoire à partir de cette date.
Pour échanger et compenser ses flux financiers avec ses contreparties, un Prestataire de Services de Paiement (PSP) doit être connecté à un Automated Clearing House (ACH) comme participant direct ou comme sous-participant.
SEPA++ de SIB est une suite logicielle “full Sepa” destinée aux sous-participants. Elle assure le traitement des opérations d’ordre clientèle et des opérations interbancaires SCT, SDD Core et BtoB et Inquiris reçues et émises au clearing au format natif XML (Norme UNIFI ISO 20022).
SEPA++ contrôle l’intégralité des opérations, à travers des API et des Web Services, par échange de la data avec le CORE Banking du PSP.
Une suite logicielle Sepa complète
INTERBANCAIRE SDD B2B
Ce module assure le traitement interbancaire (pacs) propre aux SDD B2B , notamment l’absence de remboursement après exécution du SDD.
Il traite également les différentes R-transactions associées aux SDD B2B : Retour, Rejets, annulations, reversements, émis et reçus du Clearing.
Les SDD B2B sont contrôlés, notamment le Mandat et l’ICS à travers des API ou des Web Services.
Les SDD en anomalie sont retournés vers le Participant Direct, accompagnés du reason code normalisé SEPA.
INTERBANCAIRE SDD CORE
Ce module assure le traitement interbancaire (pacs) des SDD B2C et de ses particularités, délai de rejet de huit semaines pour tout motif, de treize mois pour absence de mandat …
Il traite les différentes R-transactions associées aux SDD Core : Retour, Rejets, annulations, reversements, émis et reçus du Clearing, propres aux SDD Core.
Les SDD Core sont contrôlés, notamment le Mandat et l’ICS à travers des API ou des Web Services
Les SDD en anomalie sont retournés vers le Participant Direct, accompagnés du reason code normalisé SEPA.
MODULE CLIENTELE SDD Core et B2B
Ce module assure le traitement interbancaire (pacs) des SDD B2C et de ses particularités, délai de rejet de huit semaines pour tout motif, de treize mois pour absence de mandat …
Il traite les différentes R-transactions associées aux SDD Core : Retour, Rejets, annulations, reversements, émis et reçus du Clearing, propres aux SDD Core.
Les SDD Core sont contrôlés, notamment le Mandat et l’ICS à travers des API ou des Web Services
Les SDD en anomalie sont retournés vers le Participant Direct, accompagnés du reason code normalisé SEPA.
INTERBANCAIRE SCT
Ce module assure le traitement interbancaire (pacs) des SCT, flux et des différentes R-transactions qui y sont associées : retour, rejet, demande de rappel avec ou sans réponse négative, émis et reçus du Clearing, annulations…
Les SCT en anomalie sont retournés vers le Participant Direct accompagnés du reason code normalisé SEPA. Un Rappel de SCT, ou Recall, peut être initié à la demande du PSP, ou du donneur d’ordre. Dans ce dernier cas, il s’agit d’un Request for Recall by the Originator (RFRO).Une procédure Inquiry peut être initiée par la banque de Donneur d’Ordre (D.O.) sur la base d’une demande de renseignements et/ou de correction.
INSTANT PAYMENT SCT Ins
Ce module permet de transférer des fonds en euros en moins de 10 secondes, 24h/24h et 7j/7j et 365j/365j, entre les comptes bancaires des clients des PSP.
Le délai cible pour effectuer un SCT Inst est de 10 s maximum après que le PSP ou Banque de l’émetteur ait apposé son horodatage sur la transaction. Ce dernier doit avoir reçu un message du PSP ou Banque du bénéficiaire l’informant que les fonds ont été mis à disposition du bénéficiaire par crédit en compte ou un message l’informant que la transaction a été rejetée.
Les R-Transactions liées à l’IP peuvent être des rejets, des demandes de retour des fonds, Recall ou RFRO, des demandes d’investigation et de transfer back.
MODULE CLIENTELE SCT
Ce module assure le traitement des fichiers d’ordre clientèle (Pain), SCT remis au PSP pour être échangés au clearing avec génération du reporting et la restitution des avis et relevés des opérations en provenance du clearing (Camt).
Le module fournit les éléments comptables au Core Banking sous forme de CRE (Comptes-rendus d’évènements).
L’évolution du Sepa
La base ISO 20022 utilisée pour le SEPA dès son origine doit évoluer vers une version dite « 2019 » pour tous les schémas d’opérations SCT et SDD.
Cette évolution est nécessitée par la mise en œuvre opérationnelle du Request to Pay et la migration des systèmes TARGET2 et SWIFT MX nécessitant une structure d’information plus aboutie.
La suite logicielle SEPA++ de SIB a intégré les différentes releases de l’EPC depuis son origine et s’est enrichie ces dernières années des messages suivants :
- Demandes de restitution des fonds par l’émetteur ou par son PSP.
- Demandes de modification des dates de valeur.
- Regroupement de rappels dans un seul message.
- Request for Status Update en réponse aux Requests et Inquiry.
- Request To Pay pour l’acquittement des factures émises par des tiers.
- Paiement instantané utilisé en tant que tel et en paiement de RTP.