Cas d'usage (RUBIS)

RUBIS peut potentiellement prendre en compte de nombreux cas d'usage bien au delà de sa cible initiale.

Cœur de cible RUBIS

RUBIS a été conçu pour répondre au besoin exprimé du Ministère des Finances d'un moyen de paiement à la main du client. RUBIS a pour vocation de remplacer le chèque ou le TIP dans deux cas d'usage :

• le paiement de factures, quittances,... présentant une certaine régularité, pour les personnes, morales ou physiques, pour qui le prélèvement ne peut pas convenir
• le transfert de fonds entre particuliers, qui mobilise à ce jour plus le chèque que le virement, compte tenu de la complexité de saisir des IBAN sur une banque en ligne.

RUBIS pour les flux urgents

Le virement étant par nature du système SCT à au moins 1 jour, l'immédiateté de mise à disposition des fonds n'est pas native dans RUBIS. L'application RUBIS n'est donc pas disponible en l'état pour des flux urgents et nécessiterait, en tout cas, un accord explicite préalable des banques participantes.

Il est cependant possible d'imaginer une future version de RUBIS ou l'immédiateté est atteinte, non pas au travers de l'accélération du virement, mais dans le traitement de la réponse après validation du client : cette réponse pourrait avoir valeur de transfert auprès de la banque du créancier. Ceci est possible dès aujourd'hui dans les messages RUBIS. Il serait néanmoins nécessaire

• de mettre en place des règles particulières entre banques sur ce sujet
• que chaque banque de débiteur définisse un système de gestion du risque entre une réponse immédiate et un virement décalé : serveur d'autorisation comme pour la monétique ? comptabilité temps réel ? réservation préalable des fonds ? voire un mix de ces solutions.

Ce point serait similaire à l'utilisation du système monétique ou le flux d'autorisation est considéré comme assurance de paiement alors que le flux effectif de compensation interviendra plus tard, avec une vitesse similaire à celle du virement.

Commerce électronique

Le commerce électronique met en évidence des besoins multiples :

• une sécurité des paiements
• une ergonomie simple pour pallier l'absence d'humains
• une vitesse du paiement ou d'assurance du paiement (voir paragraphe précédent) lorsque la livraison doit être déclenchée très rapidement (vente d'information ou de logiciels)
• de multiples cas d'interactions avec le client : centre d'appel, web, smartphone.

Le positionnement de RUBIS sur le commerce électronique se base sur :

• une interaction à la main du client pour la mise en relation :
  • inscription préalable du client-débiteur sur le site de commerce électronique
  • une transmission en direct du RIS2D (format code-à-barre du QXBAN)
• une validation au travers de sa propre banque à distance (ou de l'application smartphone de sa banque) pour la validation du paiement

Schéma comparatif entre le paiement par carte et le paiement RUBIS en e-commerce.

L'inscription préalable a pour avantage de permettre l'utilisation du canal "centre d'appel" ensuite, et présente une limite d'utilisation pour les achats "compulsifs". Pour ces derniers, la nécessaire transmission du QXBAN (30 caractères) ou du RIS2D limite fortement cette compulsivité.

Paiements de niches

RUBIS pourrait résoudre aussi des paiements complexes tels que :

• paiement contre livraison, souvent appelé au cul du camion, paiements qui posent de nombreux soucis en inter-entreprises
• paiements fléchés, c'est-à-dire mettant en oeuvre des contrôles très spécifiques (réseau de santé par exemple)
• frais professionnels avec transfert directement à la comptabilité de l'entreprise des factures

Paiement de billet électronique

RUBIS, couplé avec une application d'envoi de billet électronique (message secure ou message dédié) peut permettre une automatisation complète de ce cas de vente.

• Les flux de 1 à 5 sont les flux de base de RUBIS
• à l'arrivée du flux 5, le vendeur de billet peut à son tour envoyer un billet électronique sous forme de code-à-barres pour une lecture simplifiée par exemple, ou un PDF imprimable directement de manière sécurisée (flux 6, 7, 8)

L'ardoise électronique en commerce de proximité utilisable par un tiers

Le concept ci-dessous reprend le principe d'ardoise sur la base des services RUBIS.

Dans un premier temps, l'utilisateur signe un contrat avec le commerce de proximité pour utiliser ce service. Le contrat prévoit que ce service est accessible tant à l'utilisateur mais potentiellement par un tiers, par exemple, la Nounou des enfants avec, le cas échéant, un montant maximal par dépense sur ce tiers.

L'utilisateur s'enregistre au travers du service d'inscription RUBIS en indiquant, comme convenu avec le commerce au préalable, son QXBAN et le numéro d'une carte d'identification (NFC, code à barre) appartenant à la Nounou. Le commerce met en place :

• une cible NFC pour lire l'identifiant de la carte d'identification
• une base logicielle permettant d'associer l'identifiant de la carte et le QXBAN et le cas échéant, la gestion des limites de paiements, voire même des alertes si certains aliments ne sont pas autorisés.

Lorsque la Nounou passe en caisse, elle valide avec sa carte d'identification, le commerce émet immédiatement une demande de règlement avec le montant des achats et la liste complète (le ticket sous format PDF). L'utilisateur peut ainsi recevoir et valider le paiement.

Pour des raisons de facilité, il semble utile que le contrat initial autorise un passage sans validation immédiate tout en attendant la validation pour autoriser le passage suivant.

Ce cas d'usage, bien que théorique, montre la puissance du service RUBIS ainsi que la capacité d'une banque à créer des nouveaux services compétitifs indépendamment des autres banques.