Les règles métier (RUBIS)

Objet du document

Ce document décrit le mécanisme global du système SEPAmail de demande de règlement. Il est destiné à des interlocuteurs fonctionnels, les éléments techniques figurant dans les directives correspondantes (implementation guidelines).

Présentation générale

Le système SEPAmail se compose :

• d’un réseau interbancaire sécurisé assurant le transport de messages structurés conforment aux normes partagées par les utilisateurs de SEPA­mail. Le réseau SEPAmail se déploie par l’interconnexion entre des serveurs logiciels installés dans chaque établissement adhérent.
• de services métiers à valeur ajoutée, mutualisables, supportés par le système SEPAmail au travers de l’utilisation d’une famille de messages structurés liés à chaque service métier mis en ligne sur ce réseau.

L'un de ces services métier est RUBIS, qui vise à établir un ensemble de règles et d'outils permettant de gérer des demandes de règlements électro­niques dont le règlement est validé par le débiteur :

• création des demandes de règlement par le créancier
• validation par le débiteur
• gestion d’un référentiel des créanciers
• capacité d’inscription des débiteurs auprès des créanciers

Messages de la famille RUBIS

RUBIS est l'application SEPAmail utilisant l'écosystème payment.activation.

Dans cet écosystème, trois messages ont été définis à ce jour :

• PaymentActivationRequest
• PaymentActivationReport
• PaymentActivationEnroll

Nous allons décrire en détail l'utilisation de ces messages et les règles associées.

Le message de demande de règlement

Ce message est utilisé, à l'initiative du créancier (émetteur), pour demander le versement d'une somme déterminée.

Si le débiteur (destinataire) répond, ce sera obligatoirement par le biais d'un message de réponse à demande de règlement (PaymentActivationReport, décrit plus loin), et ce quelle que soit la nature de sa réponse. Notez que le message de demande de règlement peut aussi être purement et simplement ignoré par le destinataire.

Si le règlement demandé (ou plus exactement, l'un des règlements demandés) est accepté, il est du ressort de l'adhérent de déclencher éventuellement un ou des paiements associés.

Le message est fondé sur le message pain.013 de la norme ISO 20022, CreditorPaymentActivationRequest, auquel sont ajoutées des informations spécifiques à RUBIS. Toutefois, il est important de noter qu'un seul message de demande de règlement peut contenir plusieurs messages pain.013, par exemple si le créancier souhaite proposer plusieurs modalités de paiement (comptant avec escompte, trois fois sans frais, ...).

Le message de réponse à demande de règlement

Ce message peut être utilisé dans deux cas d’usage distincts :

• à l'initiative du débiteur, après réception d'un message de demande de règlement. Dans ce cas, il indique si le débiteur accepte l’une ou l’autre des modalités de paiement proposées, ou les refuse toutes. Il permet également au débiteur d'exercer des options (paiement immédiat ...), voire de proposer un autre mode de paiement. Si ce message contient acceptation de règlement, il peut déclencher, à l'initiative de l'adhérent, un ordre en vue de la réalisation du paiement.

Exemple : acceptation de la DDR , refus de la DDR, refus après acceptation, voire acceptation après refus.

• à l'initiative de la banque du débiteur, dans le cadre de ses relations contractuelles avec son client, pour indiquer une évolution de l'état de la demande de virement.

Exemples : 
 Avant remise au client : si le client n’est pas atteignable, 
 Après décision du client pour informer de l’état d’avancement du paiement : 
  virement rejeté par la banque , 
  virement exécuté par la banque 
  …

Le message PaymentActivationReport est fondé sur le message pain.014 de la norme ISO 20022, CreditorPaymentActivationRequestStatusReport, auquel sont ajoutées des informations spécifiques à RUBIS. De même que le message de demande de règlement peut contenir plusieurs pain.013, un message de réponse peut contenir plusieurs pain.014. Les règles suivantes s'appliquent aux deux cas d’usage pré-cités :

• les pain.013 et pain.014 sont appariés par le paramètre « identification de l'information de paiement » du pain.013.
• un seul pain.014, dans le message de retour, peut représenter la modalité de paiement acceptée.
• en revanche, il peut y avoir plusieurs pain.014 avec des modalités de paiement refusées (état RJCT).
• si toutes les modalités de paiement sont refusées et que le débiteur désire communiquer, alors tous les pain.013 reçus doivent être renvoyés sous forme de pain.014 à l'état RJCT.
• après avoir accepté ou refusé une modalité de paiement, le débiteur reste toujours libre de signifier un refus ou une acceptation. le mandat de la banque du débiteur impose alors que la banque du créancier soit informée de ce nouveau choix du débiteur.

Il est donc possible d'envoyer plusieurs messages PaymentActivationReport en réponse au même message PaymentActivationRequest pour traduire l'évolution de la prise en compte de la demande de règlement.

Le message d'inscription au service

Par des canaux externes à SEPAmail, un débiteur peut être invité par l'un de ses créanciers à utiliser le système RUBIS pour le règlement de ses futures factures. En réponse à ce message, le débiteur peut accepter ou non l'usage de ce système, et préciser certains modes de fonctionnement. Un message d'inscription au service, PaymentActivationEnroll, est alors envoyé.

Ce message peut également être envoyé dans tous les cas de modification de l'inscription :

• changement de coordonnées bancaires
• désinscription

Ce message est strictement non-ISO.

Documents complémentaires

Le but de ces documents est de préciser l'usage d'un certain nombre de champs des messages de Rubis.

• la correspondance (mapping) entre ActivationRequest et ActivationReport, et entre ActivationReport et le message pacs.008.