General principles (RUBIS)

Usage context

RUBIS intends to enable the following use cases:

• Occasional credit transfer between 2 entities (companies or individuals)
• Recurrent invoices settlement with a systematic validation by the payer

The RUBIS definition does not prejudge of the mode of money transfer (credit transfers, direct debits, card clearing) that will be used while anticipating that the reference mode will be credit transfers, so the SEPA Credit Transfer in the European context.

In addition, for recurrent invoices settlement, complementary needs are considered:

• RUBIS is initiated by the customer and therefore each settlement has to be validated by the debtor. No implicit validation will be accepted, this need being already enabled by the payment by direct debit
• RUBIS has to facilitate its own business development, ie encourage debtor customers to use the service with no excessive complexity for invoices issuers.
• RUBIS must propose a solution solving the major drawback for creditors which is the lettering difficulty between the credit transfer and the initial invoice.

A comprehensive service

RUBIS includes three major components:

1. An enrollment service with the creditors using RUBIS
   • This service allows a very simple enrollment of the debtor with the creditor in order to receive payment requests. This enrollment is, of course, managed by the debtor, as stated in the RUBIS requirements. It is based on prior enrollment of creditors in a shared referential
   • The enrollment uses an alias of the IBAN, the QXBAN, ensuring to the debtor that his IBAN is not communicated to the creditor, which is currently the case with cheques.
   • This service, as well as the referential, cannot be used for occasional settlements between individuals or with companies.
2. An electronic transmission of settlement messages including an XML message and, as an option, a PDF file
   • directly issued by the creditor (who may be an individual, a utilities company or a company) to its own bank
   • sent to the debtor (individual or company) by its own bank and therefore allowing an electronic validation authenticated by the debtor bank.
   • A confirmation message as the validation is performed
3. a SEPA Credit Transfer (SCT) sent to the creditor bank
   • with an identical copy of basic elements of the initial payment request
   • so that the creditor which receives the credit transfer may automatically match the credit transfer with the “customer account”to which the payment request was sent.