jeudi 21 juin 2012

Application SEPAmail : RUBIS

RUBIS permet pour un utilisateur de SEPAmail d'envoyer une demande de règlement à un autre utilisateur SEPAmail.
Ces utilisateurs sont appelés demandeur et interlocuteur payeur.
RUBIS permet aussi au payeur de répondre "oui", "non", "oui mais", voire de ne rien répondre.

Qu'est-ce qu'une demande de règlement ?

Assez simplement, on peut résumer la demande de règlement à :
  • une requête
  • pour être payé
  • de la part de quelqu'un
  • une somme d'argent définie
  • dans une devise précise
  • à une date définie
Il y a un message iso 20022 pour réaliser ce genre de demande, le pain.013.
Il permet de préciser et de typer ce que sont les dates, les devises, le moyen de paiement demandé.

Comment évite-t-on les demandes non sollicitées ?

Cela est un vrai problème et cela dépend du contexte et du demandeur.
SEPAmail prévient et prévoit ces cas.

Supposons que le demandeur est un créancier de particuliers. Il s'inscrit dans l'annuaire RUBIS, diffusé entre les adhérents.
Dans ce cas, le particulier peut choisir d'autoriser ou non le créancier à lui envoyer des demandes de règlement au travers de SEPAmail. Il utilise pour cela un message spécifique de SEPAmail ActivationEnroll.

Selon les adhérents, les règles utilisées pour ne pas importuner leur client avec des messages sans autorisation préalable seront différentes. Certains ont prévu d'avertir qu'il y a une demande de règlement de la part d'un nouveau créancier enregistré dans l'annuaire. D'autres ont prévu de ne pas distribuer le message. Enfin, certains préfèrent implémenter un système de opt-in opt-out extensible à toute paire d'interlocuteurs.
Supposons que le demandeur soit un particulier qui fasse des demandes non sollicitées, alors, comme il authentifié, il pourra être bloqué par sa banque sur déclaration d'abus.

Les principes sont assez simples :
  • pour s'échanger un premier message, il faut demander d'abord à l'autre et être deux d'accord pour l'échange. Il y a donc une phase préalable d'inscription ou de connexion (enroll).
  • il n'est pas nécessaire de demander avant chaque échange car, après acceptation initiale, les deux interlocuteurs sont considérés comme d'accord ou connectés, tant que l'un des deux ne demande pas l'arrêt.
  • pour ne plus recevoir de message de l'autre partie, il faut l'expliciter par un message de déconnexion (enroll)

Ainsi, on est bien sur un fonctionnement optin/optout classique, sachant qu'il y authentification de toutes les parties et entente entre les adhérents pour ne pas relayer les messages SEPAmail non sollicités de part et d'autre.

Est-on obligé de répondre à une demande de règlement ?

L'interlocuteur payeur n'est pas obligé de répondre au demandeur.
Sa seule obligation est la suivante:
  • s'il a répondu OUI
  • puis qu'il ne peut ou ne veut honorer le règlement,
  • il ne peut empêcher l'adhérent SEPAmail dont il le client de diffuser l'information du non règlement (notamment en arguant du secret bancaire ou de son contrat)

Si on répond oui à une demande de règlement, que se passe-t-il ?

Si on répond OUI à une demande de règlement, alors, selon le contrat passé entre l'adhérent et son client, l'adhérent peut enclencher un paiement, comme un virement, un paiement par carte ou tout autre dispositif contractuel.
Mais il n'est pas obligé de le faire.
Dans l'absolu, RUBIS peut déboucher sur un paiement par chèque de la part de l'utilisateur.

1 commentaire:

Manfred Sherlock OLM a dit…

J'ai mis à jour ce billet pour tenir compte de la modification du standard pour l'inscription d'un débiteur dans sa version 1206.
Le message EnrollReply a été remplacé par le message ActivationEnroll de l'écosystème payment.activation.