ABN AMRO addendum on the XML Message for European Direct Debit Initiation

Transcription

1 ABN AMRO addendum on the XML Message for European Direct Debit Initiation

2 Table of contents 1 Introduction Message description Group Header Message Identification Creation Date Time Batch Booking Number Of Transactions Control Sum Grouping Initiating Party Payment Information Payment Information Identification Payment Method Payment Type Information ServiceLevel Code Local Instrument Code Sequence Type Category Purpose Requested Collection Date Creditor Creditor Account Creditor Agent Ultimate Creditor Charge Bearer Direct Debit Transaction Information Payment Identification Instruction Identification End To End Identification Instructed Amount Direct Debit Transaction Mandate Related Information Mandate Identification... 7

3 2.43 Date Of Signature Amendment Indicator Amendment Information Details Original Mandate Identification Original Creditor Scheme Identification Original Debtor Account Original Debtor Agent Electronic Signature Creditor Scheme Identification Ultimate Creditor Debtor Agent Debtor Debtor Account UltimateDebtor Purpose Code Remittance Information Unstructured Structured Creditor Reference Information Reporting Posting of the batch Posting of r-transactions Overview transaction types... 9

4 1 Introduction This addendum describes the ABNAMRO additions on the Implementation Guidelines for the XML Customer Direct Debit Initiation message UNIFI (ISO20022). This addendum provides guidance on the use of the ABNAMRO specific extra functionality for sending a Direct Debit Initiation Message, and comply with the SEPA Business-to-Business Direct Debit Scheme Customer-to-Bank Implementation Guidelines v1.1 and the SEPA Core Direct Debit Scheme Customer-to-Bank Implementation Guidelines v3.3 of the European Council of Payments (EPC). The addendum is based on the Implementation Guidelines that have been developed by the Netherlands Bankers Association (NVB). The utmost has been done to make sure the information in this publication is correct. However, ABNAMRO can by no means be held responsible for any loss or damage incurred to any incorrect or incomplete information as described in this publication. Please contact your account manager at ABNAMRO for any further information. 1.1 Character Set The UTF8 character encoding standard must be used in the UNIFI messages. The Latin character set, commonly used in international communication, must be used. It contains the following characters : a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z / -? : ( )., ' + Space Note: the above is about characters that can be used within the tags. For the message itself also other characters (especially < and >) can be used. The following characters will be blanked out in channel Access Online if used: : ' Message Structure The description of the UNIFI document models can be found in a number of schemes. A specific description language (XSD) is used in those schemes. The schemes make it possible to give a description of the tags in the document, the structure and sequence of those beacons (hierarchy of tags) as well as the codes which are allowed for some specific data, the number of possible cases, the obligatory or optional character of some of the data, etc. XSD : > Catalogue of UNIFI Messages > Payments > Payment Initiation > CustomerDirectDebitInitiationV01 A file containing an XML- pain message has the following structure : <?xml version="1.0" encoding="utf-8"?> <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain " xmlns:xsi=" <pain > message content </pain > </Document> A file must contain one single Document (envelope), which contains one single XML-message.

5 2 Message description For each field information is added if specific ABNAMRO information is required. 1.0 Group Header 1.1 Message Identification Addendum: This reference needs to be unique for a period of minimal one Year. 1.2 Creation Date Time 1.4 Batch Booking Addendum: This indicator is overruled with the agreed value administrated in the SDD creditor contract. Don t use this field. 1.5 Number Of Transactions Addendum: The maximum number of transactions allowed is administrated in the SDD creditor contract. The technical maximum of a batch is different per channel. Please consult your channel documentation for more information. 1.6 Control Sum Addendum: The maximum allowed total of all individual amounts is administrated in your SDD creditor contract 1.7 Grouping 1.8 Initiating Party Addendum: For future use 2.0 Payment Information 2.1 Payment Information Identification Addendum: Payment Information Identification will be included in account reporting, if in the SDD creditor contract batch booking is true. 2.2 Payment Method 2.3 Payment Type Information 2.5 ServiceLevel 2.6 Code 2.9 Local Instrument 2.10 Code

6 2.12 Sequence Type 2.13 Category Purpose Addendum: Future use 2.14 Requested Collection Date Addendum: If the requested collection date is a non target day the collection date will be shifted to the next possible TARGET date (see for the TARGET calendar) If the batch requires extra authorization due to the fact that limits of the SDD creditor contract are exceeded the due date can also shift to the next possible TARGET date Creditor Addendum: All fields will be replaced during processing with the values as administrated in the SDD creditor contract Creditor Account Addendum: The account must be registered in the SDD creditor contract. This account must be administrated within the channel Creditor Agent Addendum: The BIC that belongs to creditor account either ABNANL2A or HBUANL2R Ultimate Creditor 2.20 Charge Bearer 2.23 Direct Debit Transaction Information 2.24 Payment Identification 2.25 Instruction Identification Addendum: For future use 2.26 End To End Identification Addendum: End To End Identification will be included in account reporting, when an R- transaction is reported. (individual debit postings). It is recommendable to use the same reference here as in the remmitance information Instructed Amount Addendum: The amount per collection may not exceed the agreed limit in the SDD creditor contract, else the collection will be rejected Direct Debit Transaction 2.41 Mandate Related Information

7 2.42 Mandate Identification 2.43 Date Of Signature 2.44 Amendment Indicator 2.45 Amendment Information Details 2.46 Original Mandate Identification 2.47 Original Creditor Scheme Identification 2.51 Original Debtor Account 2.52 Original Debtor Agent 2.56 Electronic Signature 2.60 Creditor Scheme Identification Addendum: This creditor-identification identifies the current contract for SDD. This field must be the same within one payment (batch)!!! Business code: Positions 5 to 7 contain the Creditor Business Code. This code is not part of the SDD creditor contract and can be used freely. When the Creditor Business Code is not used, then the value is set to ZZZ 2.63 Ultimate Creditor 2.64 Debtor Agent 2.66 Debtor 2.67 Debtor Account 2.68 UltimateDebtor 2.70 Purpose 2.71 Code Addendum: For future use Remittance Information 2.91 Unstructured Addendum: Advice is to populate the unstructured remmitance information field as follows: <Ustrd> < Kenmerk: Omschrijving: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxx> </Ustrd>

8 In this way Kenmerk can be used for reconciliation, containing the current dutch betalingskenmerk or any other reference used by the Creditor. It is recommendable to use the same reference here as in the End to end identification field. Omschrijving can be used to give the debtor a meaningful description of the collection. The unstructured information is displayed on the statement of the debtor as initiated Structured Creditor Reference Information

9 3 Reporting 3.1 Posting of the batch On batch level the following is reported back in Tag 86 of the MT940: Field Swift code word Reference to the message Specific Values Nr 1 /TRTP/ The transaction type See Table 3 2 /PREF/ 2.1 Payment Information Identification 4 /NRTX/ 1.5 Number Of Transactions 5 /PIND/ Booking indicator 1 6 /INF/ Annex reference Future functionality Table 1 Batch posting 3.2 Posting of r-transactions R-transactions are reported as single debits. In the future other reporting modes will become available for R-transactions (f.i. aggregated). Field Swift code word Reference to the message Specific Values Nr 1 /RTYP/ The R-transaction type See Table 3 2 /MARF/ 2.42 Mandate Identification 4 /RTRN/ Reason of R-message 5 /BIC/ 2.64 Debtor Agent 5 /IBAN/ 2.67 Debtor Account 6 /NAME/ 2.66 Debtor 7 /ULTD//NAME/ 2.68 UltimateDebtor 8 /REMI/ 2.90 Remittance Information 9 /EREF/ 2.26 End To End Identification (original SDD) Table 2 R-transaction posting 3.3 Overview transaction types Transaction Type SWIFT CODE Label op afschrift TRTP CORE SEPA Incasso algemeen eenmalig TRTP CORE SEPA Incasso algemeen doorlopend RTYP REJECT SEPA Incasso trx. onverwerkbaar RTYP CANCEL SEPA Incasso trx. geannuleerd RTYP RETURN SEPA Incasso terugboeking bank RTYP REVERSAL SEPA Incasso correctieboeking RTYP REFUND SEPA Incasso terugboeking RTYP REFUND SEPA Incasso terugboeking Table 3 Transaction types 1 This field indicates how the posting is done. When the posting mode is gross (Dutch: Bruto), indicated in the MT940 as /PIND/ Bruto/, the posted amount is the same as the total amount in field 1.6 Control Sum. In the future other reporting modes will become available.