Use cases (RUBIS)

RUBIS may potentially support many use cases, even more than its initial specification.

Positionnement actuel et possible de RUBIS

RUBIS core business

RUBIS has been designed to meet the need specified by the Ministry of Finance of a means of payment managed by the customer. RUBIS intends to replace the cheque or the TIP in two use cases:

• the settlement of invoices, bills...which are quite regular, for natural or legal entities who cannot use the direct debit
• the money transfer between individuals, which is more performed through cheques today than through credit transfer, as entering some IBAN on remote banking is complex.

RUBIS for urgent flows

As the credit transfer is at a minimum of 1 day due to the SCT nature, the fact to provide immediately funds is not native in RUBIS. The RUBIS application is therefore not directly available for money flows and would need, in any case, that member banks provide a prior explicit agreement.

It is however possible to think of a future version of RUBIS to reach the immediate availability. This would not be done through the credit transfer acceleration but in the response processing after the customer validation: this response may represent a transfer for the creditor bank. This is already possible with RUBIS messages. It would however involve:

• to set up specific rules between banks for this matter
• that each debtor bank specifies a risk management system between an immediate response and a delayed credit transfer: authorisation server as for bank card business ? real-time accounting ? pre-reservation of funds ? or even a mix of those solutions.

This point would be similar to the use of the bank card system where the authorisation flow is considered as the payment guarantee, even though the actual clearing flow occurs later, with a speed similar to the credit transfer speed.

Electronic commerce

Electronic commerce reveals several needs:

• a security of payments
• a simple ergonomy to compensate the absence of humans
• a speed of the payment or of the payment guarantee (refer to the previous paragraph) when the delivery must occur very quickly (sale of data or software)
• several interactions with the customer: call centre, web, smartphone.

The RUBIS positionning on electronic commerce is based on:

• an interaction managed by the customer to initiate the relationship:
  • prior enrollment of the debtor-customer on the ecommerce site
  • a direct transmission of the RIS2D (QXBAN bar-code format)
• a validation through its own remote banking (or through its bank smartphone application) for the payment validation

Diagram comparing the payment with card and the the RUBIS payment for ecommerce.

The prior enrollment provides the benefit to allow the use of the‘call centre’ channel afterwards and limits «compulsive» purchases. These «compulsive” purchases are highly limited by the need to transmit the QXBAN (30 characters) or the RIS2D.

Niche payments

• payments on delivery, i.e. right at the truck, payments which create lots of problems for inter-firms
• controlled payments with very specific controls (e.g. health network)
• business expenses being directly transferred to the accounting department of the company issuing the invoices

Electronic ticket payment

RUBIS, paired with an application of electronic ticket transmission (message secure or dedicated message) may allow a comprehensive automation of this sale situation.

• Flows from 1 to 5 are the core flows of RUBIS
• at the end of flow 5, the ticket vendor may also send an electronic ticket with a bar-code format to simplify the reading for instance, or with a securely printable PDF (flows 6, 7, 8)

The electronic account for face to face commerce, usable by a third-party

The concept below is based on the account principle with RUBIS services.

First, the user signs a contract with the face to face commerce to use this service. The contract includes the possible use of the service by the user but also by a third-party, e.g. the children baby-sitter. A limit of the maximum amount per purchase might be set up for the third-party.

The user registers through the the RUBIS enrollment service and indicates, as previously agreed with the commerce, his QXBAN and the identifier of one of the baby-sitter's ID-card. The commerce sets up:

• an NFC reader to access the ID-card identifier
• an application with a base in order to match the ID-Card identifier with the QXBAN and if needed with the payments limits management system, even with the alerts systems if some goods are not permitted.

When the baby-sitter goes to the checkout, she validates with her ID-card, the commerce immediately issues a payment request with the purchases amount and the full list (the receipt as a PDF). The user can therefore receive and validate the payment.

To facilitate the process, it seems useful that the initial contract includes the authorisation for one checkout without immediate validation, while waiting for the validation to authorise the next checkout.

This use case, although theoritical, demonstrates the high capacity of the RUBIS service as well as the capability for a bank to create new services that are competitive and this independently from other banks.