La gestion des flux (RUBIS)

Initiation de la transaction

RUBIS part du principe (de bon sens) que celui qui veut recevoir les fonds (le créancier) doit être à l’initiation du processus et ce pour les raisons suivantes :

• Le créancier est le plus intéressé pour la réalisation du transfert des fonds, et donc doit être le responsable de la supervision du processus de paiement
• Le créancier peut définir dès l’initiation du processus les références qui lui permettront de traiter le mouvement de fonds en automatique (Straight Trough Processing).
• En initiant la transaction (demande de règlement), le créancier prend date et pourra ainsi faire état de sa demande en cas de litige.

Remarque : cette description est conforme au processus habituel de paiement dans lequel le créancier envoie une facture (ou facture pro forma, quittance, ...) avant de recevoir le paiement.

Circulation des flux entre créancier et débiteur

La circulation des flux se fait en respectant le modèle 4 coins : créancier, banque du créancier, banque du débiteur, débiteur.

1. Envoi de la demande de paiement comportant
   • Les références de la demande de règlement, qui serviront de références pour le virement (libellé, end2end, ultimate, sur la base des champs du virement SEPA)
   • Le montant
   • Le compte du créancier à créditer
   • D’éventuelles informations complémentaires sur la livraison des biens ou la mise à disposition du service
2. Acceptation par le débiteur en donnant un ordre de règlement à sa banque
3. Génération d’un message de retour en confirmant l’acceptation par le donneur d’ordre (débiteur)
4. virement de fonds réalisé par la banque du débiteur vers la banque du créancier
5. Réception des fonds
6. Contrôle et dénotage du virement, de la confirmation de règlement vis-à-vis de la demande de règlement émise par le créancier

Le principe de fonctionnement RUBIS

Les flux précédents sont mis en oeuvre en utilisant la messagerie SEPAmail, ce qui présente le double intérêt :

• sécuriser les flux de demande de règlement et de réponse entre le créancier et le débiteur
• articuler ces flux avec ceux liés au virement

• le créancier et le débiteur adhèrent chacun au système auprès de leur banque respective
  • garantissant ainsi l'authentification des acteurs pour le service
• le créancier (futur payé) envoie un message "demande de règlement" au débiteur (payeur
  • en valorisant la messagerie SEPAmail pour gérer les erreurs d'acheminement et de non disponibilité
• le payeur doit valider systématiquement la demande pour qu'elle puisse être réglée
  • charge à la banque du débiteur de mettre en oeuvre les outils permettant cette validation
• le créancier est informé de la validation du débiteur
  • suivant les cas cette information peut être de différents natures : ordre donné à sa banque par le débiteur de procéder au transfert, transfert en exécution, assurance donnée par la banque du débiteur que le transfert sera réalisé
• le règlement se fait directement entre la banque du débiteur et la banque du créancier en utilisant les circuits SEPA existants
• le règlement se fait à la date prévue entre le débiteur et le créancier
  • le règlement ne peut pas se faire avant l'acceptation par le débiteur, il peut être immédiat ou différé suivant les indicateurs positionnés par le créancier et la demande du débiteur
• la banque du débiteur envoie les références de dénotage fournies par le créancier
  • le virement complété suivant les normes RUBIS permet au créancier de pouvoir dénoter uniquement à partir des données reçues dans le relevé électronique

les flux entre un créancier et son débiteur

Ce schéma reprend les flux à l’initiative d’un créancier-facturier une fois le créancier en possession de l’identifiant du payeur.

1. Le créancier envoie une demande de règlement (puce 1) reprenant les éléments obligatoires et/ou optionnels décrits dans les directives du message RUBIS payment-request.
2. La banque du créancier complète avec le BIC et route vers la banque du débiteur (puce 2)
   • La banque du débiteur émet un accusé réception (puce 2bis, réponse protocolaire SEPAmail, présente dans toutes les applications et non spécifique à RUBIS) permettant d’indiquer que le message a été reçu et qu’il est mis à disposition du client (ou non suivant les cas : IBAN inconnu, service non accessible, …)
3. La banque du débiteur (puce 3) offre sur les canaux définit dans son offre commerciale la mise à disposition pour validation de la demande de règlement. L’avertissement (SMS, email, autre) du client de l’arrivée d’une demande est à la discrétion de la banque du débiteur et hors du champ de RUBIS. Le choix du compte du virement est un service pouvant être offert par la banque du payeur.
4. Une fois validé, une confirmation de l’ordre de règlement (payment-report, puce 4) est envoyée à la banque du créancier. Différents codes réponses peuvent préciser cette confirmation : refus, acceptation avec règlement en attente, acceptation avec règlement garantie, acceptation avec règlement en compensation.
   • une réponse protocolaire SEPAmail est envoyée à la banque du débiteur par la banque du créancier (puce 4bis)
5. La banque du créancier route vers le créancier la confirmation (puce 5).
6. La banque du débiteur émet, le cas échéant, le virement (puce 6) en conformité avec la demande de son client-payeur et sur la base des données remplies dans le payment-request (flux 1).
7. Le relevé électronique du créancier (AFB120 ou autre format, puce 7) reprend les données inscrites dans le virement SEPA permettant ainsi une réconciliation automatique des flux émis (puce 1) et des virements reçus (puce 6).

Ce schéma met aussi en évidence les 4 domaines utilisés par RUBIS :

• domaine concurrentiel entre une banque et son créancier
• domaine coopératif SEPAmail entre la banque du créancier et la banque du débiteur
• domaine concurrentiel entre la banque du débiteur et le débiteur
• domaine coopératif SEPA

les flux entre deux particuliers

Ces flux peuvent s'étendre à deux entités quelconques : particuliers, entreprises, administrations. En effet RUBIS réalise des demandes de règlements IBAN vers IBAN sans préjuger de la nature juridique ou organisationnelle de l'entité gérant cet IBAN.