IG Rubis ActivationReport

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 SEPA own implementation rules. Thus, unless explicitly specified, data contained within a field or XML structure of a SEPAmail message must comply with the constraints related to the equivalent field or XML structure in ISO20022 or SEPA 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 RUBIS 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

</svnig>

Header

</svnig>

Ref	Mult	Message Element	SEPAmail 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, application/pdf.
A3.6.2	[0..1]	+++++ name	original document name
A3.6.3	[1..1]	+++++ data	actual document contents

</svnig>

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 SEPAmail 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 : </svnig>

Ref	Mult	Message Element	SEPAmail 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

</svnig>

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. </svnig>

Ref	Mult		Message Element	SEPAmail 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, BIC (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 SCT 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 SEPAmail
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. IBAN (or QXBAN), copied from the Request (2.16)
3.121	[0..1]		++++ DebtorAgent	Mandatory. BIC, copied from the Request (2.17)
3.122	[1..1]		++++ CreditorAgent	Mandatory. BIC, copied from the Request (2.63)
3.123	[1..1]		++++ Creditor	Mandatory: Name and ICQX if present in Rubis ActivationRequest message, copied from tag 2.64.
3.124	[0..1]		++++ CreditorAccount	Mandatory. IBAN, copied from the Request (2.65)
3.125	[0..1]		++++ UltimateCreditor	Copied from the Request (2.66)

</svnig>

Non-ISO part

This part is only used by the SEPAmail/RUBIS system, to provide additional services both to creditor and debtor. </svnig>

Ref	Mult	Message Element	SEPAmail 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 IBAN 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.

</svnig>

IG Rubis ActivationReport

Reference document

Introduction

Header

Body

ISO part : CreditorPaymentActivationRequestStatusReportV01

Non-ISO part

Navigation menu

Search