Standards 1206:Busines rules (RUBIS)

Scope of the document

This document describes the global mechanism of the payment request SEPAmail system. It is designed for functional users, the technical elements being specified in the related directives (implementation guidelines).

Overview The SEPAmail system includes :

• a secure interbank network ensuring the routing of structured messages complying with the standards shared by the SEPA¬mail users. The SEPAmail network rolls out by interconnecting application servers installed in each member entity.
• value-added business services that may be mutualised,proposed by the SEPAmail system by using a family of structured messages related to each business service that is available on the network.

One of these business services is RUBIS, which intends to specify a set of rules and tools that allow the management of electronic payment request for which the settlement is validated by the debtor :

• creation of payment request by the creditor
• validation by the debtor
• management of a creditors referential
• capability for debtors to enroll with creditors

Messages of the RUBIS family

RUBIS is the SEPAmail application using the payment.activation ecosystem.

Three messages have been specified so far in this ecosystem :

• PaymentActivationRequest
• PaymentActivationReport
• PaymentActivationEnroll

The usage of these messages and their related rules are detailed below.

Payment request message

This message is initiated by the creditor (sender) and used to request the payment of a known amount. If the debtor (receiver) answers, it will necessarily by with a response message to the payment request (PaymentActivationReport, detailed below), and this, whatever the nature of its response. Note that the payment request message may also be just totally ignored by the receiver.

If the requested settlement (or more precisely, one of the requested settlements) is accepted, it is up to the member to decide to initiate one or several related payments.

The message is based on the pain.013 message of the ISO 20022 standards, CreditorPaymentActivationRequest, to which are added data specific to RUBIS. However, it is important to note that a single payment request message may include several pain.013 messages, for instance if the creditor wishes to propose different payment modes (immediate with discount, in three times free of charge...).

NOTE: In this version, only one settlement mode may be proposed (a single pain.013 in the ActivationRequest) and the payment must be either a differed or immediate payment (a single Payment Instruction in the pain.013)

The response message to a payment request

This message may be used in tow different cases :

• initiated by the debtor, after reception of a payment request message. In this case, the message indicates if the debtor accepts one or the other proposed payment of if he rejects all of them. The message also allows the debtor to select options (immediate payment ...), or even to propose another payment method. If this message includes some payment validation, it may activate, when initiated by the member, an order that will enable the payment achievement.
• initiated by the debtor bank, within its contractual relationship with its customer, to indicate an evolution of the status of the credit transfer order.

The PaymentActivationReport message is based on the pain.014 message of the ISO 20022 standards, CreditorPaymentActivationRequestStatusReport, to which are added data specific to RUBIS. Similarly, the payment request message may include several pain.013, a response message may include several pain.014. The following rules apply :

• the pain.013 and pain.014 are linked by the « payment data identification » parameter of the pain.013.
• a single pain.014, in the response message, may represent the payment method that is accepted.
• on the other hand, it may exist several pain.014 with payment methods that are rejected (RJCT status).
• if all the payments modes are rejected and the debtor wishes to communicate, all the received pain.013 must then be sent back with the format pain.014 with a status set to RJCT.
• after having accepted or rejected a payment method, the debtor is still able to indicate a reject or a validation. The bank mandate imposes then that the creditor is informed of this new choice by the debtor, whose exact meaning will depend on the contractual relationship they have.

It is therefore possible to send several PaymentActivationReport messages as a response of the same PaymentActivationRequest message in order to reflect the evolution of the consideration of the payment request.

Service enrollment message

Via channels external to SEPAmail, a debtor might be invited to by one of its creditors to use the RUBIS system to settle its future invoices. As a response of this message, the debtor may accept or not to use this system and specify some processing modes. A message of enrollment to the service, PaymentActivationEnroll, will then be sent.

This message may also be sent for any case of enrollment modification:

• modification of bank account ID
• deregistration

This message is strictly non-ISO.

Additional documents

The objective of these documents is to specify the usage of some fields of the Rubis messages. They are not, as such, part of the SEPAmail standard.

• the correspondance (mapping) ActivationRequest and ActivationReport
• the mapping between ActivationReport and the pacs.008 message