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.
Un sous-participant transmet ses flux au participant direct qui se charge de les transmettre à l’ACH.
En réception, l’ACH transmet les flux au participant direct qui les transmet au sous-participant.
On dit qu’un PSP est reachable, ou atteignable, par un système d’échanges lorsqu’il est possible de lui transmettre un paiement en passant par le dit système.
Un PSP peut être atteignable par un système et non accessible par un autre s’il n’est pas déclaré.
Un PSP peut être participant direct ou sous-participant sur un ou plusieurs systèmes d’échanges (CORE, STEP2, TARGET 2 …) mais il ne peut être à la fois participant direct et sous-participant d’un même système d’échange.
Si un paiement ne peut être émis à un PSP destinataire pour raison de non accessibilité, le PSP du donneur d’ordre peut alors tenter d’atteindre le PSP du bénéficiaire par un autre système par lequel il serait accessible.
PEACH (Pan-European ACH) est un ACH automatisée paneuropéenne (PE-ACH) capable d’échanger les opérations automatiques conformes au SEPA dans l’ensemble de la zone euro.
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 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 ou 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.
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.
MODULE CLIENTELE
Ce module assure le traitement des fichiers d’ordre clientèle (Pain), sct et sdd, 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.