The management of debtors enrollment (RUBIS 1206)

RUBIS includes an enrollment RUBIS service, especially appropriate for creditors.

The list of creditors stored on the RUBIS enrollment service is called the RUBIS referential.

IMPORTANT NOTE, this RUBIS referential should not be mixed up with the ICQX@SCHEME referential whose scope is much larger, clic here to view the details. The scope of the RUBIS referential is to facilitate the migration of customers-debtors.

Creation fo the RUBIS referential

The RUBIS referential is a subset of the ICQX@SCHEME referential. It includes blocks 1,2,3 and items 'Communication with debtors' from the block 6 for creditors having the 'Activity' item set to‘true’on the RUBIS enrollment service.

Eligibility criteria for the RUBIS enrollment service are:

• owning an ICQX (the RUBIS equivalent to the ICS for the SEPA direct debits) - clic here to see the preliminary process of a creditor creation in order to get an ICQX
• having a recurrent billing activity, as a firm using a lot direct debits. Actually, the RUBIS enrollment service cannot be used by creditors-individuals.

The RUBIS enrollment service is optional. Only creditors wishing to be listed on the RUBIS referential subscribe to the service. We can easily imagine that a company, mostly active in B2B business, does not use the functionalities of the RUBIS enrollment service.

We should note that the creditor IBAN is not a data indicated in the RUBIS referential as the debtor does not use it to enroll with a creditor. On the other hand, in order to allow the routing of the debtors enrollment flows up to the relevant creditor, the IBAN is included in the ICQX@SCHEME referential. It is part of the data of the enrollment RUBIS ServiceCard RUBIS that are sent to banks.

The enrollment with a creditor bank for the RUBIS enrollment service is not necessarily linked to the remittance of payment requests flows (in this case, the IBAN stored in the ServiceCards of RUBIS issuing and RUBIS enrollment are different). However, a creditor bank could set this rule when starting the service.

In addition, in case of the enrollment of the creditor to the RUBIS enrollment service with several banks, only the last enrollment is processed.

Flows related to the RUBIS referential creation are described below:

1. the creditor requests the activation of the RUBIS enrollment service using the process specified by its bank (Section 1).This process may be manual or electronic and/or based on messages of a SEPAmail ecosystem (secure or scheme, for instance). It is assumed for this phase that creditor owns an ICQX, and therefore that it has already been created at the Scheme level.
2. The creditor bank MUST validate the information provided by the creditor, especially the validity of the ICQX, of the images and of the logos that are sent (Section 2).
3. Once the validation performed, the creditor bank informs other banks and the Scheme Manager of this new entry in the RUBIS referential (Section 3). This information is transmitted with the the CreditorActivationAdvise message of the scheme family.
4. The creditor bank waits for the acknowledgement receipt from the various banks and may inform its creditor that the distribution has been finalised (Section 4).

Sharing the RUBIS referential

The RUBIS referential is shared between banks through specific messages of the scheme ecosystem. These messages are dedicated to the ICQX@SCHEME referential. All SEPAmail members may have access to information related to a creditor listed in the ICQX@SCHEME referential, either locally, or through the Scheme which is managing the referential.

Requirements to the debtor bank for the RUBIS enrollment service

Each debtor bank member of RUBIS must set up the necessary functions:

• to present the RUBIS referential to debtors via at least one channel (remote banking is the preferred one)
• to allow debtors to enroll with a creditor in order to provide the creditor with his approval to receive settlements requests via RUBIS. This function allows the transmission of the debtor Bank ID (QXBAN) with an ActivationEnroll message of the RUBIS family.

The enrollment message allows the transmission of a field representing the reference of this customer with the creditor. Indeed, this information is necessary for the creditor, in addition to the name and first name which might have homonyms, to relate the received QXBAN to the appropriate customer reference. The creditor remains responsible of checking this assignment.

In order to help the debtor to entry the correct reference, it is specified that the RUBIS referential includes communication items with the debtor. These items include at minimum one picture showing where the debtor can take the reference from.

The picture below illustrates two possible examples.

This picture, provided by the creditor, must be controlled by the creditor Bank when the creditor requests the activation of the RUBIS enrollment service.

Deregistration from a creditor

The same ActivationEnroll message, used to inform the creditor of a debtor enrollment, may also be used in case the creditor wishes to deregister. As a first analysis, this function, if proposed to a debtor, must be linked with an appropriate management of the next messages sent by this creditor. The rules will be specified at the end of the testing phase.

Flexible management in case of absence of preliminary enrollment of the debtor

When a creditor is listed in the RUBIS referential and when it issues a payment request to a debtor who is not enrolled with him by having used an ActivationEnroll message, the debtor bank will not reject directly the payment request only because the preliminary ActivationEnroll message is missing.