Outils personnels

IG Rubis ActivationRequest

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.013.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 SEPAmailmessagerie bancaire sécurisée./RUBISRèglement Universel Bancaire Immédiat & SEPA (application SEPAmail) message used to request payment from a debtor.

The full name of this message is sepamail_message_payment.activation_PaymentActivationRequest.

This message is normally generated and sent by the creditor to its bank, which then forwards it to the debtor's bank, for final validation by the debtor.

The answer to this message is always a PaymentActivationReport message, accepting or rejecting the payment. A second PaymentActivationReport message may be sent later, if the payment is accepted by the debtor, but could not be settled.

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

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


Header

source ActReq_Header.txt, date Fri Dec 16 12:56:45 CET 2011


Ref Mult Message Element SEPAmailmessagerie bancaire sécurisée. requirement
A [1..1] ++ Header Global header for message
A1 [1..1] +++ CreDtTm Creation date and time, ISO format
A2 [1..1] +++ NbOfRequests Number of ReqCompl elements contained in the message
A3 [0..n] +++ Documents Any document justifying the payment request
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.
This field is valued by the creditor under its own resposability and is not supposed to be controlled by the SEPAmailmessagerie bancaire sécurisée. member.
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 ActReq_Header.tab, date Wed Aug 29 16:56:20 CEST 2012



ISO and Non-ISO parts

Each RequestAndComplements element describes one proposed payment modality. If the creditor wishes to offer several payments modalities (e.g. immediate or in three monthly installments), several ReqCompl elements must be present in the message. The debtor will then choose the one s/he wishes to use, if any.

Each ReqCompl element has the following contents:

source ActReq_Body.txt, date Fri Dec 16 12:56:45 CET 2011


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

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


ISO Part : CreditorPaymentActivationRequestV01

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 R24) and guidelines (G1, G2).

source ActReq_ISO.txt, date Fri Dec 16 12:56:45 CET 2011


Ref Mult   Message Element SEPAmailmessagerie bancaire sécurisée. requirement
1.0 [1..1] + GroupHeader
1.1 [1..1] ++ MessageIdentification Will be used in the pain.014 reply (2.1 OriginalMessageIdentification) to allow reconciliation.
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] ++ NumberOfTransactions
1.4 [0..1] ++ ControlSum
1.5 [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.
2.0 [1..*] + PaymentInformation R10, R11, R12, R13, R14, R5, R6, R7, R8, R9
2.1 [0..1] ++ PaymentInformationIdentification Mandatory. Will be sent back by Report message for matching purposes between Request and Report.
2.2 [1..1] ++ PaymentMethod Mandatory. The only value currently accepted here is "TRF". Note : if the OtherPmtMtd field, in the non-ISO part, is used, this field will be ignored.
2.3 [0..1] ++ PaymentTypeInformation
2.4 [0..1] +++ InstructionPriority
2.5 [0..1] +++ ServiceLevel
2.6 [1..1] {Or ++++ Code
2.7 [1..1] Or} ++++ Proprietary
2.8 [0..1] +++ LocalInstrument
2.9 [1..1] {Or ++++ Code
2.10 [1..1] Or} ++++ Proprietary
2.11 [0..1] +++ CategoryPurpose
2.12 [1..1] {Or ++++ Code
2.13 [1..1] Or} ++++ Proprietary
2.14 [1..1] ++ RequestedExecutionDate Mandatory.
2.15 [1..1] ++ Debtor Mandatory: Name
2.16 [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).)
2.17 [1..1] ++ DebtorAgent Mandatory (AT-13 BICBank Identifier Code, norme ISO 9362:1994 of the Debtor Bank) Usage Rule: Only BICBank Identifier Code, norme ISO 9362:1994 is allowed.
2.18 [0..1] ++ UltimateDebtor
2.19 [0..1] ++ ChargeBearer 2.40 should be used instead of this element
2.20 [1..*] ++ CreditTransferTransaction G1, G2. Usage Rule: only one occurrence of this structure can be used.
2.21 [1..1] +++ PaymentIdentification
2.22 [0..1] ++++ InstructionIdentification
2.23 [1..1] ++++ EndToEndIdentification Will be forwarded as is into the Rubis ActivationReport message.
2.24 [0..1] +++ PaymentTypeInformation
2.25 [0..1] ++++ InstructionPriority
2.26 [0..1] ++++ ServiceLevel
2.27 [1..1] {Or +++++ Code
2.28 [1..1] Or} +++++ Proprietary
2.29 [0..1] ++++ LocalInstrument
2.30 [1..1] {Or +++++ Code
2.31 [1..1] Or} +++++ Proprietary
2.32 [0..1] ++++ CategoryPurpose
2.33 [1..1] {Or +++++ Code
2.34 [1..1] Or} +++++ Proprietary
2.35 [1..1] +++ Amount Usage rule : this amount MUST NOT be zero.
2.36 [1..1] {Or ++++ InstructedAmount R21, R22
2.37 [1..1] Or} ++++ EquivalentAmount
2.38 [1..1] +++++ Amount R21, R22
2.39 [1..1] +++++ CurrencyOfTransfer R22
2.40 [1..1] +++ ChargeBearer Mandatory. The only currently accepted value is SLEV.
2.41 [0..1] +++ ChequeInstruction
2.42 [0..1] ++++ ChequeType
2.43 [0..1] ++++ ChequeNumber
2.44 [0..1] ++++ ChequeFrom
2.45 [1..1] ++++ Name
2.46 [1..1] ++++ Address
2.47 [0..1] ++++ DeliveryMethod
2.48 [1..1] {Or +++++ Code
2.49 [1..1] Or} +++++ Proprietary
2.50 [0..1] ++++ DeliverTo
2.51 [1..1] +++++ Name
2.52 [1..1] +++++ Address
2.53 [0..1] ++++ InstructionPriority
2.54 [0..1] ++++ ChequeMaturityDate R23
2.55 [0..1] ++++ FormsCode
2.56 [0..2] ++++ MemoField
2.57 [0..1] ++++ RegionalClearingZone
2.58 [0..1] ++++ PrintLocation
2.59 [0..1] +++ UltimateDebtor
2.60 [0..1] +++ IntermediaryAgent1 R18
2.61 [0..1] +++ IntermediaryAgent2 R19
2.62 [0..1] +++ IntermediaryAgent3
2.63 [1..1] +++ CreditorAgent Mandatory. BICBank Identifier Code, norme ISO 9362:1994
2.64 [1..1] +++ Creditor Mandatory. See below for full details of this element.
2.65 [0..1] +++ CreditorAccount 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).). For interbank exchanges, this MUST NOT be a 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)..
2.66 [0..1] +++ UltimateCreditor
2.67 [0..*] +++ InstructionForCreditorAgent
2.68 [0..1] ++++ Code R20
2.69 [0..1] ++++ InstructionInformation
2.70 [0..1] +++ Purpose
2.71 [1..1] {Or ++++ Code
2.72 [1..1] Or} ++++ Proprietary
2.73 [0..10] +++ RegulatoryReporting
2.74 [0..1] +++ Tax
2.75 [0..10] +++ RelatedRemittanceInformation
2.76 [0..1] ++++ RemittanceIdentification
2.77 [0..1] ++++ RemittanceLocationMethod
2.78 [0..1] ++++ RemittanceLocationElectronicAddress
2.79 [0..1] ++++ RemittanceLocationPostalAddress
2.80 [1..1] +++++ Name
2.81 [1..1] +++++ Address
2.82 [0..1] +++ RemittanceInformation Only unstructured remittance information is allowed in SEPAmailmessagerie bancaire sécurisée.
2.83 [0..*] ++++ Unstructured Only one occurrence may be used in order to forward a proposal of remittance information to the debtor. Due to later truncation, the length of this value must not exceed 105 characters.
2.84 [0..*] ++++ Structured Not allowed in SEPAmailmessagerie bancaire sécurisée.
2.85 [0..*] +++++ ReferredDocumentInformation
2.86 [0..1] ++++++ Type
2.87 [1..1] +++++++ CodeOrProprietary
2.88 [1..1] {Or ++++++++ Code
2.89 [1..1] Or} ++++++++ Proprietary
2.90 [0..1] +++++++ Issuer
2.91 [0..1] ++++++ Number
2.92 [0..1] ++++++ RelatedDate
2.93 [0..1] +++++ ReferredDocumentAmount
2.94 [0..1] ++++++ DuePayableAmount R21, R22
2.95 [0..1] ++++++ DiscountAppliedAmount R21, R22
2.96 [0..1] ++++++ CreditNoteAmount R21, R22
2.97 [0..1] ++++++ TaxAmount R21, R22
2.98 [0..*] ++++++ AdjustmentAmountAndReason
2.99 [1..1] +++++++ Amount R21, R22
2.100 [0..1] +++++++ CreditDebitIndicator
2.101 [0..1] +++++++ Reason
2.102 [0..1] +++++++ AdditionalInformation
2.103 [0..1] ++++++ RemittedAmount R21, R22
2.104 [0..1] +++++ CreditorReferenceInformation
2.105 [0..1] ++++++ Type
2.106 [1..1] +++++++ CodeOrProprietary
2.107 [1..1] {Or ++++++++ Code
2.108 [1..1] Or} ++++++++ Proprietary
2.109 [0..1] +++++++ Issuer
2.110 [0..1] ++++++ Reference
2.111 [0..1] +++++ Invoicer
2.112 [0..1] +++++ Invoicee
2.113 [0..3] +++++ AdditionalRemittanceInformation

source ActReq_ISO_1206.tab, date Tue Jul 02 16:42:56 CEST 2013


This is the detail of fields under Cdtr element (2.64 above).

source ActReq_ISO_Cdtr.txt, date Tue Jun 19 17:04:40 CEST 2012


Ref Mult   Message Element SEPAmailmessagerie bancaire sécurisée. requirement
4.1.0 [0..1] ++++ Name Mandatory
4.1.1 [0..1] ++++ PostalAddress
4.1.2 [0..1] +++++ AddressType
4.1.3 [0..1] +++++ Department
4.1.4 [0..1] +++++ SubDepartment
4.1.5 [0..1] +++++ StreetName
4.1.6 [0..1] +++++ BuildingNumber
4.1.7 [0..1] +++++ PostCode
4.1.8 [0..1] +++++ TownName
4.1.9 [0..1] +++++ CountrySubDivision
4.1.10 [0..1] +++++ Country
4.1.11 [0..7] +++++ AddressLine
4.1.12 [0..1] ++++ Identification Mandatory for icqx@scheme registered users
4.1.13 [1..1] {Or +++++ OrganisationIdentification
4.1.14 [0..1] ++++++ AnyBIC
4.1.15 [0..*] ++++++ Other
4.1.16 [1..1] +++++++ Identification Must contain the 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.
4.1.17 [0..1] +++++++ SchemeName
4.1.18 [1..1] {{Or ++++++++ Code
4.1.19 [1..1] Or}} ++++++++ Proprietary Must contain the value SEPAMAIL.EU
4.1.20 [0..1] +++++++ Issuer
4.1.21 [1..1] Or} +++++ PrivateIdentification
4.1.22 [0..1] +++++ DateAndPlaceOfBirth
4.1.23 [1..1] ++++++ BirthDate
4.1.24 [0..1] ++++++ ProvinceOfBirth
4.1.25 [1..1] ++++++ CityOfBirth
4.1.26 [1..1] ++++++ CountryOfBirth
4.1.27 [0..*] +++++ Other
4.1.28 [1..1] ++++++ Identification
4.1.29 [0..1] ++++++ SchemeName
4.1.30 [1..1] {{Or +++++++ Code
4.1.31 [1..1] Or}} +++++++ Proprietary
4.1.32 [0..1] ++++++ Issuer
4.1.33 [0..1] ++++ CountryOfResidence
4.1.34 [0..1] ++++ ContactDetails

source ActReq_ISO_Cdtr.tab, date Mon Feb 18 10:13:32 CET 2013


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 ActReq_NonISO.txt, date Wed Aug 29 16:56:20 CEST 2012


Ref Mult Message Element SEPAmailmessagerie bancaire sécurisée. requirement
B2.1 [1..1] +++ Title Payment description, such as "Payment upon validation". This is presented to the user through the debtor's bank interface.
B2.2 [1..1] +++ PmtCond Mandatory. Specific payment conditions
B2.2.1 [1..1] ++++ PmtModifAccepted Mandatory. Are modified payment amounts accepted by the creditor ?
B2.2.2 [1..1] ++++ ImmPmtAccepted Mandatory. Is immediate payment accepted by the creditor ?
B2.2.3 [0..1] ++++ DelayPenalty Penalties applicable in case of payment delay. This is free text, considering the wide variety of possibilities.
B2.2.4 [0..1] ++++ ImmPmtRebate Discount rate for immediate payment. Even if immediate payment is accepted by the creditor, this field is not mandatory. Its absence means immediate payment implies no discount.
B2.3 [0..1] +++ OtherPmtMtd Payment method requested by creditor. Possible values are 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.5 [0..1] +++ PmtGuarantee Payment guarantee to be applied to this transaction. Possible values are
AUTO transfer will be automatically guaranteed
DBTR transfer will be guaranteed if debtor agrees
NONE no guarantee can be applied to transfer
XXXX transfer is not possible
Currently, this field is not taken into account.
B2.6 [0..1] +++ TrfNature Nature of the generated payment. Possible values are IMMED and TERM, see note N1 below for their meaning. This field MUST NOT be set to IMMED if B2.2.2 is false. Currently, this field MAY be ignored by the debtor's bank.
B2.7 [0..3] +++ CustRef Customer references, delivered by the creditor, unambiguously identifying the debtor in the creditor reference system for one given contract.
If several RequestComplements are present, this field MUST have the same value(s) in all structures.
B2.8 [1..1] +++ RltnType Type of relation between creditor and debtor. Possible values are B2B, B2C, C2B and C2C.
If this field is B2B or B2C, there SHOULD BE an 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. in element 4.1.12 above.

source ActReq_NonISO_1206.tab, date Thu Mar 21 19:34:04 CET 2013


N1 : The meaning of the possible values for TrfNature field is as follows :

  • IMMED : the default option displayed to the debtor will be a transfer initiated upon validation (immediate transfer, in French facture à vue)
  • TERM : the default option displayed to the debtor will be a transfer occurred on the RequestedExecutionDate (index 2.14) (transfer at term, in French facture à échéance).

If this field is not present and immediate payment is allowed, the default nature applied will be IMMED.

If this field is not present and immediate payment is not allowed, the message is then inconsistant and thus shall be rejected.


source ActReq_NonISO_notes.txt, date Mon Jun 18 12:43:28 CEST 2012