Flows management (RUBIS)

Transaction initiation

RUBIS is based on the principle (common sense) that the one willing to receive funds (the creditor) should be the one initiating the process and this for the following reasons:

• The creditor is the most interested for the funds transfer achievement, and must therefore be responsible for checking the payment process.
• The creditor may define, right at the beginning of the process, the references that will allow him to automatically process the funds transfer (Straight Through Processing).
• While initiating the transaction (payment request), the creditor records the date and will therefore be able to stipulate his request in case of dispute.

Modèle:Note: this description is complying with the usual payment process where the creditor sends an invoice (or pro forma facture, bill...) before receiving the payment.

Flows circulation between the creditor and the debtor

The flows circulation occurs while respecting the 4 corner model: creditor, creditor bank, debtor bank, debtor.

1. Transmission of the payment request including
   • The references of the payment request, that will be used as the references of the credit transfer (description, end2end, ultimate, based on the fields of the SEPA credit transfer)
   • The amount
   • The creditor account to be credited
   • Any additional information on the goods delivery or on the service availability.
2. Acceptation by the debtor by sending a settlement order to his bank
3. Creation of a return message including the acceptation by the order issuer (debtor)
4. Funds transfer performed by the debtor bank to the creditor bank
5. Funds reception
6. Control and denotage of the credit transfer, of the settlement confirmation related to the payment request issued by the creditor

How RUBIS operates

The previous flows are processed by using the SEPAmail messaging service, which provides two benefits:

• It secures the flows of the payment request and of the response between the creditor and the debtor
• It articulates these flows with those related to the credit transfer

• the creditor and the debtor are both members of the system through their own bank
  • Providing therefore the guarantee of the actors authentication for the service
• the creditor (that will be paid) sends a message “payment request" to the debtor (payer)
  • by trusting the SEPAmail messaging service to manage errors of routing and of non-availability
• the payer must systematically validate the request so that the request can be settled
  • the debtor bank is responsible for providing the tools to allow this validation
• the creditor is informed of the validation by the debtor
  • depending on the situation, this information may be of different nature: order given by the debtor to his bank to proceed with the transfer, transfer in execution , guarantee provided by the debtor bank that the transfer will be processed.
• the settlement is performed directly between the debtor bank and the creditor bank by using the existing SEPA channels.
  • And therefore avoid financial intermediaries
• the settlement is done at the date planned between the debtor and the creditor
  • the settlement cannot be done before the debtor validation, it may be immediate or differed depending on parameters set by the creditor and by the debtor request
• the debtor bank sends the denotage references provided by the creditor
  • the credit transfer completed in accordance with the RUBIS standards allows the creditor to be able to denote only from data received in the electronic statement

flows between a creditor and its debtor

This diagram shows the flows initiated by a creditor once the creditor got the payer identifier.

1. The creditor sends a payment request (Section 1) including the mandatory and/or optional elements that are described in the specifications of the payment-request RUBIS message.
2. The creditor bank completes the request with the BIC and sends it to the debtor bank (Section 2)
   • The debtor bank sends an acknowledgement receipt (Section 2bis, SEPAmail protocol-based response, included in all the applications and not specific to RUBIS) allowing to inform that the message has been received and that it has been made available to the customer (or not, depending on the case: unknown IBAN, not accessible service, …)
3. The debtor bank (Section 3) proposes, through the channels defined in its business proposal, the availability of the payment request for validation. The customer notice (SMS, email, other) of a request reception is at the discretion of the debtor bank and out of the RUBIS scope. The choice of the credit transfer account is a service that may be proposed by the payer’s bank.
4. Once validated, a confirmation of the settlement order (payment-report, Section 4) is sent to the creditor bank. Differents response codes réponses may specify this confirmation: refusal, validation with settlement on hold, validation with settlement guaranteed, validation with settlement in clearing.
   • A SEPAmail protocol-based response is sent to the debtor bank to the creditor bank (Section 4bis)
5. The creditor bank sends the confirmation to the creditor (Section 5).
6. The debtor bank issues, if appropriate, the credit transfer (Section 6) complying with the request of its customer-payer and using the data present in the payment-request (flow 1).
7. The electronic statement of the creditor (AFB120 or other format, Section 7) includes the data indicated in the SEPA credit transfer and therefore allows the automatic reconciliation of the issued flows (Section 1) with the received credit transfers (Section 6).

This diagram also presents the four spaces used by RUBIS:

• competitive space between a bank and its creditor
• SEPAmail cooperative space between the creditor bank and the debtor bank
• competitive space between the debtor bank and the debtor
• SEPA cooperative space

flows between individuals

These flows may occur between two entities, whatever they are: individuals, companies, administrations. Indeed, RUBIS processes IBAN to IBAN payment requests without prejudging the legal or organisational nature of the entity managing this IBAN.