Outils personnels

IG Rubis ActivationReport

De documentation SEPAmail.

SEPAmail – Norme 1206

Cette page fait partie de la version 1206 de la norme.

Sauf indication contraire, elle a été validée par les instances concernées et s'impose à tous les adhérents SEPAmail.
ATTENTION ! La version 1606 de la norme est disponible, vérifiez si cette page est toujours valable.

  • These implementation rules shall be applied in accordance with ISO20022 and SEPASingle Euro Payments Area est un espace européen à l’intérieur duquel les entités économiques peuvent effectuer des paiements en euros avec la même facilité, la même sécurité et les mêmes conditions que pour un paiement national. own implementation rules. Thus, unless explicitly specified, data contained within a field or XML structure of a SEPAmailmessagerie bancaire sécurisée. message must comply with the constraints related to the equivalent field or XML structure in ISO20022 or SEPASingle Euro Payments Area est un espace européen à l’intérieur duquel les entités économiques peuvent effectuer des paiements en euros avec la même facilité, la même sécurité et les mêmes conditions que pour un paiement national. messages.
  • for an explanation of the color coding used in the tables below, see this page
  • for general rules applying to all fields, see this page
  • for business rules directing these IG, see this page


Reference document

The underlying message, pain.014.001.01, is described by an ISO 20022 document, entitled "Creditor Payment Activation Request : Message Definition Report", in its october 2010 version, with which the reader should be familiar.

It is available directly from ISO 20022 here.


Introduction

This document describes the contents of the RUBISRèglement Universel Bancaire Immédiat & SEPA (application SEPAmail) message used to accept or reject payment as requested by a debtor.

The full name of this message is sepamail_message_payment.activation_PaymentActivationReport.

This message can be used in two cases :

  • normally, it is generated and sent by the debtor upon reception of a Rubis ActivationRequest message, to indicate his approval or rejection.
  • it can also be generated and sent by the debtor's bank, after the debtor approved the payment, if the actual payment cannot proceed for purely internal reasons (account closed ...)

This message contains one or several ISO pain.014 structures. For adaptability reasons, this message also includes non-ISO parts. All message parts are described in this document


source ActRep_Intro.txt, date Fri Nov 02 09:21:21 CET 2012


Header

source ActRep_Header.txt, date Fri Dec 16 13:09:35 CET 2011


Ref Mult Message Element SEPAmailmessagerie bancaire sécurisée. requirement
A [1..1] ++ Header Global element for message
A1 [1..1] +++ CreDtTm Creation date and time, ISO format. This date will be used as instruction date for the associated payments, if any.
A2 [1..1] +++ NbOfReports Mandatory. Number of RepCompl elements contained in the message
A3 [0..n] +++ Documents Any document justifying the payment decision. The documents attached to the Rubis ActivationRequest message must not be forwarded here.
A3.1 [1..1] ++++ Type Type of document attached. Possible values are mandate, invoice and information. In this message, only the last two values should be used.
A3.2 [0..1] ++++ Date reference date of the document
A3.3 [1..1] ++++ Title title of the document
A3.4 [1..1] ++++ Reference internal reference
A3.5 [1..1] ++++ Lang language used on the document, 2-letter code
A3.6 [0..1] ++++ Contents
A3.6.1 [1..1] +++++ mime-type type of data in the document. Usage rule : only the following values can be used : image/gif, image/jpeg, image/png, image/vnd.microsoft.icon, applicationune application SEPAmail est liée à un service bancaire proposé. Elle peut se définir comme une séquence de messages utilisant le dispositif technique SEPAmail/pdf.
A3.6.2 [0..1] +++++ name original document name
A3.6.3 [1..1] +++++ data actual document contents

source ActRep_Header_1206.tab, date Fri Nov 02 09:21:21 CET 2012



Body

Each "ReportAndComplements" element describes exactly one payment method, which can be either accepted or rejected.

  • Usage rule 1 : No more than one payment in a given PaymentActivationReport message can be accepted.
  • Usage rule 2 : If the debtor accepts one payment among several proposed by the creditor, the PaymentActivationReport MAY include only the accepted payment. It MAY also include all other payments, each one with a rejected status (RJCT).
  • Usage rule 3 : If the debtor rejects all proposed payments, the PaymentActivationReport message MUST include all payments, each one with a rejected status (RJCT).
  • Usage rule 4 : All fields of the pacs.008 message MUST be kept. In other words, if an optional field is present in the SEPAmailmessagerie bancaire sécurisée. message, but appears in the pacs.008 message, it MUST be kept throughout the circuit and its value MUST be inserted at the correct place in the outgoing messages. See also the documents annexed to the business rules for information about field mapping between the different messages.

Each RepCompl element has the following contents :

source ActRep_Body.txt, date Thu Aug 23 17:52:52 CEST 2012


Ref Mult Message Element SEPAmailmessagerie bancaire sécurisée. requirement
B [1..n] ++ RepCompl ISO + non-ISO parts. This element must be present as many times as described by the NbOfReports element, in the header.
B1 [1..1] +++ Report CreditorPaymentActivationReport, as per ISO 20022 pain.014.001.01
B2 [1..1] +++ Complements Non-ISO part, described further in this document

source ActRep_Body.tab, date Wed Aug 29 16:56:20 CEST 2012


ISO part : CreditorPaymentActivationRequestStatusReportV01

Please note : this whole part is directly copied from ISO20022 documents, and is only provided here for ease of reference. The indices in first column match the ones in this document Please refer to it as well for detailed description of rules R1 through R26.

source ActRep_ISO.txt, date Fri Dec 16 13:09:35 CET 2011


Ref Mult   Message Element SEPAmailmessagerie bancaire sécurisée. requirement
1.0 [1..1] + GroupHeader
1.1 [1..1] ++ MessageIdentification
1.2 [1..1] ++ CreationDateTime This is a technical date, which may be different from the same field in main message
1.3 [1..1] ++ InitiatingParty Name of the party sending the message (Nm) is mandatory if it is not a bank, BICBank Identifier Code, norme ISO 9362:1994 (in Id) is mandatory if it is a bank.
Must indicate the debtor when this message is generated by his action (acceptance or rejection), and the debtor's agent in other cases.

Notice that this rule is different from the original one provided by ISO20022.
1.4 [0..1] ++ DebtorAgent
1.5 [0..1] ++ CreditorAgent
2.0 [1..1] + OriginalGroupInformationAndStatus
2.1 [1..1] ++ OriginalMessageIdentification MUST match the MessageIdentification (1.1) in the associated pain.013 message
2.2 [1..1] ++ OriginalMessageNameIdentification MUST contain "pain.013.001.01
2.3 [0..1] ++ OriginalCreationDateTime If present, MUST contain CreationDateTime (1.2) from Rubis ActivationRequest message.
2.4 [0..1] ++ OriginalNumberOfTransactions If present, MUST contain NbOfTxs (1.3) from Rubis ActivationRequest message.
2.5 [0..1] ++ OriginalControlSum If present, MUST contain ControlSum (1.4) from Rubis ActivationRequest message.
2.6 [0..1] ++ GroupStatus R8
2.7 [0..*] ++ StatusReasonInformation
2.8 [0..1] +++ Originator
2.9 [0..1] +++ Reason
2.10 [1..1] {Or ++++ Code Can be used here, if all transactions have the same status. See below for possible values
2.11 [1..1] Or} ++++ Proprietary
2.12 [0..*] +++ AdditionalInformation R9
2.13 [0..*] ++ NumberOfTransactionsPerStatus
2.14 [1..1] +++ DetailedNumberOfTransactions
2.15 [1..1] +++ DetailedStatus
2.16 [0..1] +++ DetailedControlSum
3.0 [0..*] + OriginalPaymentInformationAndStatus
3.1 [1..1] ++ OriginalPaymentInformationIdentification Must match the PaymentInformationIdentification of one of the pain.013 parts of the original Rubis ActivationRequest message.
3.2 [0..1] ++ OriginalNumberOfTransactions
3.3 [0..1] ++ OriginalControlSum
3.4 [0..1] ++ PaymentInformationStatus
3.5 [0..*] ++ StatusReasonInformation
3.6 [0..1] +++ Originator
3.7 [0..1] +++ Reason
3.8 [1..1] {Or ++++ Code
3.9 [1..1] Or} ++++ Proprietary
3.10 [0..*] +++ AdditionalInformation R9
3.11 [0..*] ++ NumberOfTransactionsPerStatus
3.12 [1..1] +++ DetailedNumberOfTransactions
3.13 [1..1] +++ DetailedStatus
3.14 [0..1] +++ DetailedControlSum
3.15 [0..*] ++ TransactionInformationAndStatus
3.16 [0..1] +++ StatusIdentification
3.17 [0..1] +++ OriginalInstructionIdentification Valued with the relevant InstructionId (2.22)
3.18 [0..1] +++ OriginalEndToEndIdentification Mandatory. Must be forwarded into the relevant SCTSEPA Credit Transfer ou virement SEPA, virement standard exécuté dans la zone SEPA, en euros sans limite de montant, dans un délai maximum de trois jours transaction (pacs.008), but not in Fi2FiCustomerCreditTransfer/CdtTrfTxInf/PmtId/EndToEndId, which shall contain the debtor end-to-end reference. This reference must be stored in the first 35-char block of the Unstructured RemittanceInformation, right-padded with spaces.
3.19 [0..1] +++ TransactionStatus R10,R11,R12,R13. Mandatory. Usage rules : following values are accepted:
ACCP (Accepted Customer Profile)
ACSC (Accepted with settlement complete)
ACSP (Accepted by debtor)
ACWC (Accepted with Change -- the change can be either payment date, amount or anything else)
RJCT (Rejected).
To indicate guarantee of payment, the PmtGuarantee element, in the non-ISO part, must be used.
3.20 [0..*] +++ StatusReasonInformation
3.21 [0..1] ++++ Originator
3.22 [0..1] ++++ Reason
3.23 [1..1] {Or +++++ Code
3.24 [1..1] Or} +++++ Proprietary
3.25 [0..*] ++++ AdditionalInformation R9
3.26 [0..*] +++ ChargesInformation
3.27 [1..1] ++++ Amount R14,R15
3.28 [1..1] ++++ Party
3.29 [0..1] +++ AcceptanceDateTime As per ISO, date at which bank has applied checks such as authorization, availability of funds ...
3.30 [0..1] +++ AccountServicerReference
3.31 [0..1] +++ ClearingSystemReference
3.32 [0..1] +++ OriginalTransactionReference
3.33 [0..1] ++++ InterbankSettlementAmount R14,R15
3.34 [0..1] ++++ Amount
3.35 [1..1] {Or +++++ InstructedAmount R14,R15. This must match exactly the original amount in Rubis ActivationRequest message (2.36).
3.36 [1..1] Or} +++++ EquivalentAmount
3.37 [1..1] ++++++ Amount R14,R15
3.38 [1..1] ++++++ CurrencyOfTransfer R15
3.39 [0..1] ++++ InterbankSettlementDate MAY be set by the party sending the Report. MUST not be valued from data from the Request.
3.40 [0..1] ++++ RequestedCollectionDate If present, this field MUST contain the RequestedExecutionDate (2.14) from Rubis ActivationRequest message.
3.41 [0..1] ++++ RequestedExecutionDate If present, contains the date at which debtor requires execution by his bank.
3.42 [0..1] ++++ CreditorSchemeIdentification
3.43 [0..1] ++++ SettlementInformation
3.44 [1..1] +++++ SettlementMethod
3.45 [0..1] +++++ SettlementAccount R18,R20
3.46 [0..1] +++++ ClearingSystem R18
3.47 [1..1] {Or ++++++ Code
3.48 [1..1] Or} ++++++ Proprietary
3.49 [0..1] +++++ InstructingReimbursementAgent R16,R17,R19,R20
3.50 [0..1] +++++ InstructingReimbursementAgentAccount R21
3.51 [0..1] +++++ InstructedReimbursementAgent R16,R17,R19,R20
3.52 [0..1] +++++ InstructedReimbursementAgentAccount R22
3.53 [0..1] +++++ ThirdReimbursementAgent R17,R20
3.54 [0..1] +++++ ThirdReimbursementAgentAccount R23
3.55 [0..1] ++++ PaymentTypeInformation
3.56 [0..1] +++++ InstructionPriority
3.57 [0..1] +++++ ClearingChannel
3.58 [0..1] +++++ ServiceLevel
3.59 [1..1] {Or ++++++ Code
3.60 [1..1] Or} ++++++ Proprietary
3.61 [0..1] +++++ LocalInstrument
3.62 [1..1] {Or +++++ Code
3.63 [1..1] Or} ++++++ Proprietary
3.64 [0..1] +++++ SequenceType
3.65 [0..1] +++++ CategoryPurpose MUST be copied from the CategoryPurpose structure (2.11) in the Request message.
3.66 [1..1] {Or ++++++ Code
3.67 [1..1] Or} ++++++ Proprietary
3.68 [0..1] ++++ PaymentMethod Must be either omitted or valued with the PaymentMethod tag (2.2) from the Request.
3.69 [0..1] ++++ MandateRelatedInformation
3.70 [0..1] +++++ MandateIdentification
3.71 [0..1] +++++ DateOfSignature
3.72 [0..1] +++++ AmendmentIndicator
3.73 [0..1] +++++ AmendmentInformationDetails R26
3.74 [0..1] ++++++ OriginalMandateIdentification
3.75 [0..1] ++++++ OriginalCreditorSchemeIdentification
3.76 [0..1] ++++++ OriginalCreditorAgent
3.77 [0..1] ++++++ OriginalDebtor
3.78 [0..1] ++++++ OriginalDebtorAccount
3.79 [0..1] ++++++ OriginalDebtorAgent
3.80 [0..1] ++++++ OriginalFinalCollectionDate
3.81 [0..1] ++++++ OriginalFrequency
3.82 [0..1] +++++ ElectronicSignature
3.83 [0..1] +++++ FirstCollectionDate
3.84 [0..1] +++++ FinalCollectionDate
3.85 [0..1] +++++ Frequency
3.86 [0..1] ++++ RemittanceInformation Only unstructured remittance information is allowed in SEPAmailmessagerie bancaire sécurisée.
3.87 [0..*] +++++ Unstructured One occurrence must be present and must hold the concatenation of :
    a first block, 35 chars long, holding the end-to-end reference provided by the Debtor, right-padded with spaces
      a second block, no more than 105 chars long, holding either the original unstructured remittance info (2.83), or an updated version of it provided by the debtor.
3.88 [0..*] +++++ Structured Not allowed in SEPAmail.
3.89 [0..*] ++++++ ReferredDocumentInformation
3.90 [0..1] +++++++ Type
3.91 [1..1] ++++++++ CodeOrProprietary
3.92 [1..1] {Or +++++++++ Code
3.93 [1..1] Or} +++++++++ Proprietary
3.94 [0..1] ++++++++ Issuer
3.95 [0..1] +++++++ Number
3.96 [0..1] +++++++ RelatedDate
3.97 [0..1] ++++++ ReferredDocumentAmount
3.98 [0..1] +++++++ DuePayableAmount R14,R15
3.99 [0..1] +++++++ DiscountAppliedAmount R14,R15
3.100 [0..1] +++++++ CreditNoteAmount R14,R15
3.101 [0..1] +++++++ TaxAmount R14,R15
3.102 [0..*] +++++++ AdjustmentAmountAndReason
3.103 [1..1] ++++++++ Amount R14,R15
3.104 [0..1] ++++++++ CreditDebitIndicator
3.105 [0..1] ++++++++ Reason
3.106 [0..1] ++++++++ AdditionalInformation
3.107 [0..1] +++++++ RemittedAmount R14,R15
3.108 [0..1] ++++++ CreditorReferenceInformation
3.109 [0..1] +++++++ Type
3.110 [1..1] ++++++++ CodeOrProprietary
3.111 [1..1] {Or +++++++++ Code
3.112 [1..1] Or} +++++++++ Proprietary
3.113 [0..1] ++++++++ Issuer
3.114 [0..1] +++++++ Reference
3.115 [0..1] ++++++ Invoicer
3.116 [0..1] ++++++ Invoicee
3.117 [0..3] ++++++ AdditionalRemittanceInformation
3.118 [0..1] ++++ UltimateDebtor
3.119 [0..1] ++++ Debtor Mandatory: Name. All structure is copied from the Debtor structure (2.15) in the Request
3.120 [0..1] ++++ DebtorAccount Mandatory. IBANInternational Bank Account Number, norme ISO 13616:2003 (or QXBANle QXBAN est une instance alias de l'IBAN (International Bank Account Number) interne au système SEPAmail. Il est créé pour un BIC à l'aide d'un algorithme spécifié par le Scheme, en conformité avec la définition et les règles génériques de création d'un IBAN pour un code pays « QX » (pas de pays avec ce code).), copied from the Request (2.16)
3.121 [0..1] ++++ DebtorAgent Mandatory. BICBank Identifier Code, norme ISO 9362:1994, copied from the Request (2.17)
3.122 [1..1] ++++ CreditorAgent Mandatory. BICBank Identifier Code, norme ISO 9362:1994, copied from the Request (2.63)
3.123 [1..1] ++++ Creditor Mandatory: Name and ICQXidentifiant unique d'un créancier dans le réseau SEPAmail. Cet identifiant est géré par le SCHEME. Il est unique pour une entité économique et pérenne. if present in Rubis ActivationRequest message, copied from tag 2.64.
3.124 [0..1] ++++ CreditorAccount Mandatory. IBANInternational Bank Account Number, norme ISO 13616:2003, copied from the Request (2.65)
3.125 [0..1] ++++ UltimateCreditor Copied from the Request (2.66)

source ActRep_ISO_1206.tab, date Mon Nov 05 15:50:10 CET 2012


Non-ISO part

This part is only used by the SEPAmailmessagerie bancaire sécurisée./RUBISRèglement Universel Bancaire Immédiat & SEPA (application SEPAmail) system, to provide additional services both to creditor and debtor.

source ActRep_NonISO.txt, date Wed Aug 29 16:56:20 CEST 2012


Ref Mult Message Element SEPAmailmessagerie bancaire sécurisée. requirement
B2.1 [0..1] ++++ OtherPmtMtd This field should be used if the debtor prefers another payment method than the one requested by the creditor.
B2.1.1 [1..1] +++++ PmtMtd Payment method chosen by debtor. Possible values are CHK (check), TRF (Transfer), DD (Direct Debit), and CARD (payment card). If this field is present, the PaymentMethod field, in the ISO part, will be ignored.
B2.1.2 [0..1] +++++ PmtMtdId Payment method-specific identifier : mandatory for CARD (rhe card number), it is optional in all other cases. For TRF payment, this field can be used to indicate another IBANInternational Bank Account Number, norme ISO 13616:2003 to be used for the transfer. For CHK or DD, it may hold an internal reference number.
B2.2 [0..1] ++++ PmtGuarantee Should be set to true if the bank guarantees the related payment
B2.3 [1..1] ++++ ImmPmt Mandatory. Reflects the decision of the Debtor about accepting immediate payment, if proposed by the creditor. Usage rule : if ImmPmtAccepted was set to false in the Request message, ImmPmt must be set to false in the Report message. Otherwise, ImmPmt is set to true (accepts) or false (does not accept) according to the choice of the debtor.
B2.4 [0..1] ++++ ImmPmtRebate Value copied from the Rubis ActivationRequest message (B2.2.4).
B2.5 [0..n] ++++ PmtModif Debtor modified the amount to be paid, whether more or less than the instructed amount. This is possible only if the creditor accepts it (B2.2.1 true in the Request message). Each modified sum must be indicated by a PmtModif element and the associated PmtId.
B2.5.1 [1..1] +++++ PmtId The related PaymentIdentification, as it appears in the Request message.
B2.5.2 [1..1] +++++ Amt The amount accepted by the debtor, possibly with a currency code attribute.
B2.6 [0..1] ++++ TrfNature The nature of the requested transfer. Possible values are IMMED and TERM. This field must match exactly the TrfNature field of the associated Rubis ActivationRequest message.
B2.7 [0..3] ++++ CustRef Customer reference, delivered by the creditor, unambiguously identifying the debtor in the creditor reference system. MUST match exactly tag B2.7 in the Request message.
B2.8 [0..1] ++++ DecisionDate Date at which the debtor notified his/her decision.

source ActRep_NonISO_1206.tab, date Wed Jun 05 09:43:22 CEST 2013