Contents. 1. Introduction Submission of orders and reporting History of SEPA Changes for November Options in reporting 7

Transcription

1 SEPA Reporting

2 2 Contents 1. Introduction 3 2. Submission of orders and reporting 4 3. History of SEPA 5 4. Changes for November Options in reporting camt.052/053/054 Account information pain.002 Status/error file MT940, MT942 Account information DTI DTAUS Information File The reporting formats in practice Appendix Description of technical formats camt.052/053/054 Account information pain.002 Status/error file MT940, MT942 Account information DTI DTAUS Information File Business transactions and return codes EBICS order types 29

3 3 1. Introduction The introduction of SEPA has provided customers with various options of retrieving account information reports and status reports on order submissions. This brochure is designed to provide you important details of the options, including reference to the pertinent technical specifications and the various SEPA formats. The information provided in this brochure constitutes recommendations, which are based on the DFÜ Agreement of the German Banking Industry Committee. Further details as well as information on the technical fields and XML schemas (XSD) can be found in Appendix 3 of the specification of remote data transfer between customer and bank according to the DFÜ Agreement, version 2.8 of 30/04/2014, effective from 17/11/2014, which is available online at :

4 4 2. Submission of orders and reporting The introduction of SEPA has raised the standard for payments and customer reporting to ISO (XML). The Regulation (EU) No 260/2012 has made the ISO format mandatory for the submission of domestic and EU payments in the customer-bank process. This is optional in the bank-customer process. The consistent application of the ISO format from ordering to the receiving party is beneficial because in this case all payment information is forwarded as well. Customers submit the payment transaction files to banks in the pain format. In interbank dealings, the payments are subsequently exchanged between the banks in the pacs format. The customer can retrieve reports on the processing status of his submission. As an option, account information on the transactions is provided in the camt format. As an option, the bank may also provide errors/rejects to the customer as a file in pain format. UniCredit also offers its customers the option of providing account information and reports in the legacy MT940 and DTI formats. The following chapters present the various formats, providing a basis for making the optimum decision for the implementation of SEPA. Communication in ISO format (XML) Payment order Status information Customer pain pain = payment initiation Payment initiation for Credit Transfers (pain.001) Direct Debits (pain.008) pain pain = payment initiation status information** Error message/status message (pain.002) Bank Customer pacs camt pacs = payment clearing & settlement Clearing for Credit Transfers (pacs.008) Direct Debits (pacs.003) camt = cash management* Account information Notification (camt.052) Statement of account (camt.053) Batch transaction notifications (camt.054) pacs pacs = payment clearing & settlement error messages Error message/status message (pacs.002) Customer information * As an option, also as MT940 or DTI ** As an option, also as DTI

5 5 3. History of SEPA January 2008 (DFÜ Agreement Appendix 3 Version 2.2) Start of SEPA Credit Transfer Format versions: pain ct MT940 with SEPA information Formats for XML statements (camt.05x) not yet defined November 2008 (DFÜ Agreement Appendix 3 Version 2.3) No content-related format changes, although grouping and containers are taken into account: pain ct, pain ct.con November 2009 (DFÜ Agreement Appendix 3 Version 2.4) Start of SEPA Direct Debit Core and SEPA Direct Debit B2B Format versions: pain Option: Definition of XML statement formats camt , camt , camt November 2010 (DFÜ Agreement Appendix 3 Version 2.5) Format versions: pain camt still camt.05x Restructuring of the reject pain.002 message to accommodate customer requirements Structured text for return fees in MT940/MT942/DTI November 2011 No format changes November 2012 (DFÜ Agreement Appendix 3 Version 2.6) No format changes Return code AC13 if the debtor is a consumer and FF05 if a COR1 direct debit with shorter presentation period is not possible November 2013 (DFÜ Agreement Appendix 3 Version 2.7) Format versions: pain , pain , pain camt still camt.05x November 2014 (DFÜ-Anlage 3 Version 2.8) No format changes Amendments of account statement formats, see chapter 4 on page 6 Note: Every year in November, a new SEPA Rulebook comes into force that provides the basis for the continuous updates to the latest requirements. As far as you are concerned, these annual rulebook modifications mean that you may possibly also have to make updates to the formats. The German Banking Industry Committee has made an agreement that customarily both the current and the previous format versions are to be accepted. In addition, UniCredit accepts even older versions and also provides the pain.002 status information in line with the previous version. However, the respective formats do have to be used to be able to utilise the new functions.

6 6 4. Changes for November 2014 As per 17 November 2014, a new DFÜ Agreement Appendix 3, version 2.8, will be introduced, which will contain the following changes regarding reporting with account and status information (see also publication at Amendments of reporting of electronic XML statements (camt formats) camt.052/054: Optional use of Additional Information in the Group Header to indicate various use cases, e.g. whether a certain filter was set camt.05x, standardised allocation rules for Additional Entry/Transaction Information camt.05x, element group Return Information, optional field Additional Information now with allocation rule for RETURN, REJECT or REFUND in the case of returned direct debits Amendments of reporting in general New BTC for ELV card debits with PurposeCode CGDD (BTC 107 SEPA Direct Debit single entry-debit, card-generated direct debit at the point-of-sale) New BTCs for SEPA Cards Clearing (106 SCC card debit, 110 SCC return debit, 182 SCC refund, 190 SCC debit collection, 198 SCC credit collection, 199 SCC reversal) New return reasons for SEPA Cards Clearing (SVNR service not rendered and EMVL EMV liability shift) Return reason BE06 is mapped to text key extension 929 and AM09 to text key extension 935 In addition to the above-listed amendments, UniCredit will offer its customers the following new options: For camt.052/053/054, customers can configure individually whether or not the roles of debtor and creditor are reversed in R-transactions

7 7 5. Options in reporting Which report serves what purpose? The table below gives you an overview of the possible variants of electronic account information relating to account statements, account reports, batched transactions and status reports. Recommended for Options Restrictions/ to be observed MT940 Electronic account statement legacy systems MT942 DTI Payment transaction report legacy systems Electronic processing of incoming payments and returns legacy systems Not all SEPA fields are passed on Not all SEPA fields are passed on Not all SEPA fields are passed on Format MT940 MT942 DTAUS0 DTAUS1 Possible preparation time* End of day Entry date Every half-hour Entry date Every half-hour Entry date camt.053 Electronic account statement new camt End of day Entry date camt.052 camt.054 pain.002 Electronic payment transaction report new Electronic processing on incoming payments and returns new SEPA status messages prior to entry for SEPA mandate management; also for rejected files that are not posted. Electronic information on the submitted SEPA file Since June 2013 optionally also for direct debits returned prior to entry Since Nov optionally also for SEPA error messages after entry No direct debit return fees reported camt camt DK: pain pain EPC: pain Every half-hour Entry date Every half-hour Entry date Shortly after error is detected * Please do not hesitate to contact your Cash Management & ebanking Specialist if your are interested in further detailed information on the possible configurations of preparation times upon request camt.052/053/054 Account information SEPA Credit Transfer and Direct Debit orders are processed in the internationally valid uniform ISO XML standard. This makes it possible to include further information such as the IBAN (International Bank Account Number), the BIC (Business Identifier Code) for bank identification, various references and additional deviating originator and beneficiary information. In order to provide this additional information in a clear and structured manner, including in electronic account statements and account reports, ISO offers you the camt.053 account statement, the camt.052 account report and the camt.054 batched transaction notification. The camt.053 XML account statement replaces the MT940 in the SWIFT format, the camt.052 XML account report replaces the MT942 and the camt.054 XML batched transaction notification replaces the DTI in DTA format. A changeover to the camt.052, the camt.053 and the camt.054 has not been made compulsory by law. UniCredit continues to offer existing SWIFT and DTI formats in addition as an alternative to account information in the new XML format.

8 8 ISO Cash Management Message order type camt.052 C52 camt.053 C53 camt.054 C54 Definition account reports during the day account statements batched transaction details Equivalent SWIFT MT942 SWIFT MT940 DTI camt.052 and camt.053 Account reports as camt.052 messages contain all detailed information on debit or credit entries posted to the account during the day. The camt.052 thus optimally supplements the account statement contained in camt.053 by providing additional information during the day. The processing of camt messages in existing ERP systems on part of the customer requires an adaptation of the previous routines. In order to guarantee a smooth transition, existing SWIFT formats (MT94x) and the new camt.05x formats can be provided simultaneously for each account. Beginning of entry date Entry date End of entry date Beginning of next day CAMT.053 <?xml version= 1.0?> <Document xmlns= urn:iso:std:iso:20022:tech:xsd: camt xmlns:xsi= XMLSchema-instance > <BkToCstmrStmt> <GrpHdr> <MsgId> </MsgId> <CreDtTm> T19:00: :00</CreDtTm> <MsgRcpt> <Nm>Test Name</Nm> <PstlAdr> <AdrLine>Am Tucherpark 1</AdrLine> <AdrLine>80538 München</AdrLine> <Stmt> <Ntry> <Amt Ccy= EUR >2.18</Amt> <CdtDbtInd>DBIT</CdtDbtInd> <Sts>BOOK</Sts> <Cdtr> <Nm>Counterpart Name</Nm> </Cdtr> <CdtrAcct> <Id> <IBAN>DE </IBAN> CAMT.052 CAMT.052 <?xml version= 1.0?> <Document xmlns= urn:iso:std:iso:20022:tech:xsd: camt xmlns:xsi= <?xml version= 1.0?> XMLSchema-instance > <Document xmlns= urn:iso:std:iso:20022:tech:xsd: CAMT.052 <BkToCstmrStmt> camt xmlns:xsi= <GrpHdr> XMLSchema-instance > <?xml version= 1.0?> <MsgId> </MsgId> <BkToCstmrStmt> <Document xmlns= urn:iso:std:iso:20022:tech:xsd: CAMT.052 <CreDtTm> T19:00: :00</CreDtTm> <GrpHdr> camt xmlns:xsi= <?xml version= 1.0?> <MsgRcpt> <MsgId> </MsgId> XMLSchema-instance > <Document xmlns= urn:iso:std:iso:20022:tech:xsd: <Nm>Test Name</Nm> <CreDtTm> T19:00: :00</CreDtTm> <BkToCstmrStmt> camt xmlns:xsi= <PstlAdr> <MsgRcpt> <GrpHdr> XMLSchema-instance > <AdrLine>Am Tucherpark <Nm>Test 1</AdrLine> Name</Nm> <MsgId> </MsgId> <BkToCstmrStmt> <AdrLine>80538 München</AdrLine> <PstlAdr> <CreDtTm> T19:00: :00</CreDtTm> <GrpHdr> <AdrLine>Am Tucherpark <MsgRcpt> 1</AdrLine> <MsgId> </MsgId> <Rpt> <AdrLine>80538 München</AdrLine> <Nm>Test Name</Nm> <CreDtTm> T19:00: :00</CreDtTm> <PstlAdr> <MsgRcpt> <Ntry> <Rpt> <AdrLine>Am Tucherpark <Nm>Test 1</AdrLine> Name</Nm> <Amt Ccy= EUR >2.18</Amt> <AdrLine>80538 München</AdrLine> <PstlAdr> <CdtDbtInd>DBIT</CdtDbtInd> <Ntry> <AdrLine>Am Tucherpark 1</AdrLine> <Sts>PDNG</Sts> <Amt Ccy= EUR >2.18</Amt> <Rpt> <AdrLine>80538 München</AdrLine> <CdtDbtInd>DBIT</CdtDbtInd> <Sts>PDNG</Sts> <Ntry> <Rpt> <Amt Ccy= EUR >2.18</Amt> <CdtDbtInd>DBIT</CdtDbtInd> <Ntry> <Sts>PDNG</Sts> <Amt Ccy= EUR >2.18</Amt> <CdtDbtInd>DBIT</CdtDbtInd> <Sts>PDNG</Sts> CAMT.053 <?xml version= 1.0?> <Document xmlns= urn:iso:std:iso:20022:tech:xsd: camt xmlns:xsi= XMLSchema-instance > <BkToCstmrStmt> <GrpHdr> <MsgId> </MsgId> <CreDtTm> T19:00: :00</CreDtTm> <MsgRcpt> <Nm>Test Name</Nm> <PstlAdr> <AdrLine>Am Tucherpark 1</AdrLine> <AdrLine>80538 München</AdrLine> <Stmt> <Ntry> <Amt Ccy= EUR >2.18</Amt> <CdtDbtInd>DBIT</CdtDbtInd> <Sts>BOOK</Sts> <Cdtr> <Nm>Counterpart Name</Nm> </Cdtr> <CdtrAcct> <Id> <IBAN>DE </IBAN> Customer

9 9 camt.054 camt.054 messages contain the individual items for incoming and outgoing credit transfers or direct debits, which are posted in camt.053 as a bulk, with one posting item (bulked amount) corresponding to one camt.054 message. As an alternative, UniCredit also offers its customers to integrate the single transactions into the camt.053 account statement. During the day End of entry date Information on the single transactions CAMT.054 CAMT.054 <?xml version= 1.0 encoding= UTF-8?> <Document xmlns= urn:iso:std:iso:20022:tech:xsd: camt xmlns:xsi= <?xml version= 1.0 encoding= UTF-8 CAMT.054?> XMLSchema-instance > <Document xmlns= urn:iso:std:iso:20022:tech:xsd: <BkToCstmrDbtCdtNtfctn> camt xmlns:xsi= <?xml version= 1.0 encoding= UTF-8 CAMT.054?> <GrpHdr> XMLSchema-instance > <Document xmlns= urn:iso:std:iso:20022:tech:xsd: <MsgId>DDY130109AC </MsgId> <BkToCstmrDbtCdtNtfctn> camt xmlns:xsi= <?xml version= 1.0 encoding= UTF-8?> <CreDtTm> T07:30: :00</CreDtTm> <GrpHdr> XMLSchema-instance > <Document xmlns= urn:iso:std:iso:20022:tech:xsd: <MsgRcpt> <MsgId>DDY130109AC </MsgId> <BkToCstmrDbtCdtNtfctn> camt xmlns:xsi= <Nm>Test Name</Nm> <CreDtTm> T07:30: :00</CreDtTm> <GrpHdr> XMLSchema-instance > <PstlAdr> <MsgRcpt> <MsgId>DDY130109AC </MsgId> <BkToCstmrDbtCdtNtfctn> <AdrLine>Am Tucherpark <Nm>Test 1</AdrLine> Name</Nm> <CreDtTm> T07:30: :00</CreDtTm> <GrpHdr> <AdrLine>80538 München</AdrLine> <PstlAdr> <MsgRcpt> <MsgId>DDY130109AC </MsgId> <AdrLine>Am Tucherpark <Nm>Test 1</AdrLine> Name</Nm> <CreDtTm> T07:30: :00</CreDtTm> <Ntfctn> <AdrLine>80538 München</AdrLine> <PstlAdr> <MsgRcpt> <AdrLine>Am Tucherpark <Nm>Test 1</AdrLine> Name</Nm> <Ntry> <Ntfctn> <AdrLine>80538 München</AdrLine> <PstlAdr> <Amt Ccy= EUR >10.22</Amt> <AdrLine>Am Tucherpark 1</AdrLine> <CdtDbtInd>DBIT</CdtDbtInd> <Ntry> <Ntfctn> <AdrLine>80538 München</AdrLine> <Sts>BOOK</Sts> <Amt Ccy= EUR >10.22</Amt> <CdtDbtInd>DBIT</CdtDbtInd> <Ntry> <Ntfctn> <Dbtr> <Sts>BOOK</Sts> <Amt Ccy= EUR >10.22</Amt> <Nm>Counterpart Name</Nm> <CdtDbtInd>DBIT</CdtDbtInd> <Ntry> </Dbtr> <Dbtr> <Sts>BOOK</Sts> <Amt Ccy= EUR >10.22</Amt> <DbtrAcct> <Nm>Counterpart Name</Nm> <CdtDbtInd>DBIT</CdtDbtInd> <Id> </Dbtr> <Dbtr> <Sts>BOOK</Sts> <IBAN>DE </IBAN> <DbtrAcct> <Nm>Counterpart Name</Nm> <Id> </Dbtr> <Dbtr> <IBAN>DE </IBAN> <DbtrAcct> <Nm>Counterpart Name</Nm> <Id> </Dbtr> <IBAN>DE </IBAN> <DbtrAcct> <Id> <IBAN>DE </IBAN> CAMT.053 <?xml version= 1.0 encoding= UTF-8?> <Document xmlns= urn:iso:std:iso:20022:tech:xsd: camt xmlns:xsi= XMLSchema-instance > <BkToCstmrStmt> <GrpHdr> <MsgId> </MsgId> <CreDtTm> T19:00: :00</CreDtTm> <MsgRcpt> <Nm>Test Name</Nm> <PstlAdr> <AdrLine>Am Tucherpark 1</AdrLine> <AdrLine>80538 München</AdrLine> <Stmt> <Ntry> <Amt Ccy= EUR >10.22</Amt> <AddtlInfInd> <MsgNmId>camt.054</MsgNmId> <MsgId>DDY130109AC </MsgId> </AddtlInfInd> <Stmt> <Ntry> <Amt Ccy= EUR >14.22</Amt> <AddtlInfInd> <MsgNmId>camt.054</MsgNmId> <MsgId>DDY130109AC </MsgId> </AddtlInfInd> Batched transaction notifications Customer

10 pain.002 Status/error file Along with a pain.002 status/error file, you will receive concise feedback on the incorrect transactions and the type of the error in the electronic pain file format according to the international ISO standard. This will allow you to ensure clear matching with your original submissions. Creditor Creditor bank Debtor bank Debtor Example of SEPA Direct Debit Creditor initiates pain.002 pacs Reject Creditor bank initiates Debtor bank initiates Debtor initiates The use of the pain.002 status/error file offers the following benefits: The consistent use of ISO makes it possible to retain all relevant information from submission to feedback. The pain.002 status/error file supplements the information in the account statement (camt.053), since this is available only after entry. The error report is already available prior to entry (comparable to the existing error log). This is particularly interesting for SEPA Direct Debit, since in this case the order is forwarded to the debtor bank prior to the due date, making it possible for the debtor bank to verify the order prior to the due date (e. g. whether the account exists). In this case, the creditor can already be informed about a reject including a statement of the cause of error prior to the due date or prior to entry (e. g. if the account has been closed). This means that the creditor can start the investigation immediately, rather than after the due date. The possible reasons for rejecting direct debits via R-messages prior to entry are listed in the overview below: Creditor Initiated R-messages: Prior to entry Revocation/recall, e. g. confirmation of revocation Creditor bank Initiated R-messages: Prior to entry Debtor bank not SEPA-ready for direct debits Mandatory fields missing IBAN check erroneous Debtor bank Initiated R-messages: Prior to entry Reject, e. g. Debtor account does not exist Debtor account blocked Debtor Initiated R-messages: Prior to entry Mandate blocked by debtor Total direct debit blocking Refusal prior to entry

11 11 Special feature at UniCredit: Rejection always at transaction level The reason for the rejection is always indicated at transaction level, i.e. even if the submitted file is rejected at Group Header or Payment Information level, all transactions are returned, including a statement of the corresponding reason code. The reason codes at Group Header or Payment Information level are not used, making it possible to determine the error situation merely by analysing the returned transaction. The procedure is illustrated on the basis of the examples below: Reason for rejection Double Message Identification at Group Header level Incorrect control sum at Payment Information level Number of incorrect transactions within the Payment Information level exceeds the configured threshold Transaction contains incorrect IBAN pain.002 Status Reason Information at... level Original Group Information and Status Original Payment Information and Status Transaction Information and Status All transactions are listed and assigned reason code AM05, double processing All transactions are listed and assigned reason code AM10, incorrect control sum All transactions at Payment Information level are listed, incorrect ones are assigned the appropriate reason code, e. g. AC01, incorrect IBAN, and correct ones are assigned ED05, correct transaction within total file rejection Only the incorrect transaction is listed and assigned reason code AC01, incorrect IBAN Distinction between returns prior to and after entry? The relevant factor for deciding whether the return occurred prior to or after entry is always the interbank settlement date. Returns made prior to this date are posted to the creditor s account as cancellations, while returns that occur later are posted as returns. It may happen that returns made prior to entry are posted by the debtor bank to the customer s account for transparency reasons and are subsequently reversed right away. The distinction at the creditor s end is particularly relevant, given that the correct sequence type has to be selected for the subsequent submissions of direct debits. How can the creditor identify the correct R-message in this case? It cannot be clearly allocated based on the return reasons; the information provided in the table below is needed in addition (see also section 7.1 on page 20): camt.052/053 und MT940 DTI pain.002 Prior to entry Cancellation With the following BTCs in the account statement: 108 SEPA Reject (debit, B2B), 109 SEPA Reject (debit, CORE/COR1) and/or 159 SEPA Reject (credit, credit transfer) Cancellation In the remittance information of record level C with identifier SVWZ+, constant SEPA-Reject and reason code in plain text as well as with the text key 09 or 59 for SEPA DD or SEPA CT R-message Reject The MessageId contains an F at the third position. After entry Return With the following BTCs in the account statement: 108 SEPA Direct Debit Reversal (debit, B2B) 109 SEPA Direct Debit Reversal (debit, CORE/COR1) and/or 159 SEPA Return (credit, credit transfer) Return In the remittance information of record level C with identifier SVWZ+, constant RUECKUEBERWEISUNG (returned credit transfer) or RUECKLASTSCHRIFT (returned direct debit) and reason code in plain text as well as with the text key 09 or 59 for SEPA DD or SEPA CT R-message. Return optional for UniCredit customers The MessageId contains an I at the third position.

12 12 Option pain.002 also for returns after entry Using the pain.002 for returns after entry may be expedient if a uniform format is to be used for the investigation or dunning process relating to returned direct debits (the standard would be pain.002 for returns prior to entry and camt.054 for returns after entry). Since pain.002 does not permit the use of the fields for interchange fees and interest compensation, these are not shown explicitly in pain.002. The gross amount returned (incl. return fees and interest compensation) is entered in <InstrAmt>. XML version corresponds to the submission, which may lead to different versions within an XML container The reject always has the version in which it was submitted by the customer, e. g. SCT pain pain and in the case of legacy formats pain pain This has to be taken into account in particular if different versions are used for submissions or if former transactions are returned after changeover to the new version. In order to ensure that only one XML container needs to be downloaded even with different pain.002 versions UniCredit consolidates the different pain.002 versions in its containers, as shown in the example below: <?xml version="1.0"?> <con:conxml xmlns:con="urn:conxml:xsd:container.hvb " > <con:msgpain002> <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain "> </Document> </con:msgpain002> <con:msgpain002> </Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain "> </Document> </con:msgpain002> </con:conxml> 5.3. MT940, MT942 Account information The provision of account information in the international SWIFT format is the ideal choice for organisations whose parent company is domiciled in a foreign country. In connection with SEPA, however, the SWIFT-MT format involves some disadvantages: Considerable implementation efforts on part of corporate customers caused by a great number of different country- and bank-specific variants due to limited standardisation Limited display of transaction data, since the SWIFT-MT character set can display a considerably lower number of characters than the UTF-8 character set used in SEPA More difficult automatic processing, since the detailed information on direct debits as well as on debtor and creditor in SEPA transactions can only be transported incompletely for reasons of space.

13 13 For this reason, the use of the camt.05x formats is recommended to allow for consistent processing with a high level of automation without loss of information. Given the above-listed disadvantages, reporting via MT94x in SEPA takes place as follows: MT940 account statements contain information on all entries posted to your account and MT942 electronic account reports contain information on all debit or credit entries posted to your account during the day. In addition to the mandatory fields, the MT940 and MT942 contain the optional field 86 that provides information to the account holder. UniCredit uses a substructure to provide detailed information for SEPA in structured form, as shown in section 7.1 on page 20. Beginning of entry date Entry date End of entry date Beginning of next day MT940 :20: :25: / :28C:28/2 :60M:D110727EUR16358,43 :61: D13,06NDDTFABCD EF // :86:105?00SEPA direct debit basic?100050?20eref+ete TestA 1.03 Standar?21dpreis Core 6?22MREF+M ?23CRED+DE98ZZZ ?24S VWZ+RI TestB 1.03 Standard?25preis Core 6?26ABWA+Test Joshua?30HYVEDEMM480? 31DE ?32EndToEnd Test Heute?34990 :61: D13,07NDDTCUSTR EF // :86:105?00SEPA direct debit basic?100050?20eref+ete TestA 1.03 Standar?21dpreis Core 7?22MREF+M ?23CRED+DE98ZZZ ?24S VWZ+RI TestA 1.03 Standard?25preis Core 7?26ABWA+Test Joshua?30HYVEDEMM480?3 1DE ?32Peter Smith, Test User?34990 :62F:D110727EUR16384,56 MT942 MT942 :20: :25: / :28C:90/2 :34F:EURD0, :20: :34F:EURC24200, :25: / :13D: :28C:90/2 :61: C24200,NMSCNONR :34F:EURD0, EF// :34F:EURC24200, MT942 :86:835?00AVAL?109999?20Import :13D: :20: LC?21Erledigung?22UnsereRef :61: C24200,NMSCNONR ?23Ihre Ref. TEX EF// :25: / :90D:0EUR0, :86:835?00AVAL?109999?20Import :28C:90/2 MT942 :90C:1EUR24200, LC?21Erledigung?22UnsereRef :34F:EURD0, :20:110728?23Ihre Ref. TEX :34F:EURC24200, :25: / :90D:0EUR0, :13D: :28C:90/2 :90C:1EUR24200, :61: C24200,NMSCNONR :34F:EURD0, EF// :34F:EURC24200, :86:835?00AVAL?109999?20Import :13D: LC?21Erledigung?22UnsereRef :61: C24200,NMSCNONR?23Ihre Ref. TEX :90D:0EUR0, :90C:1EUR24200, EF// :86:835?00AVAL?109999?20Import LC?21Erledigung?22UnsereRef ?23Ihre Ref. TEX :90D:0EUR0, :90C:1EUR24200, MT940 :20: :25: / :28C:28/2 :60M:D110727EUR16358,43 :61: D13,06NDDTFABCD EF // :86:105?00SEPA direct debit basic?100050?20eref+ete TestA 1.03 Standar?21dpreis Core 6?22MREF+M ?23CRED+DE98ZZZ ?24S VWZ+RI TestB 1.03 Standard?25preis Core 6?26ABWA+Test Joshua?30HYVEDEMM480? 31DE ?32EndToEnd Test Heute?34990 :61: D13,07NDDTCUSTR EF // :86:105?00SEPA direct debit basic?100050?20eref+ete TestA 1.03 Standar?21dpreis Core 7?22MREF+M ?23CRED+DE98ZZZ ?24S VWZ+RI TestA 1.03 Standard?25preis Core 7?26ABWA+Test Joshua?30HYVEDEMM480?3 1DE ?32Peter Smith, Test User?34990 :62F:D110727EUR16384,56 Customer

14 DTI DTAUS Information File The German DTI format (DTAUS Information File) for account information is optimally tailored to German DTAbased domestic payment transactions and is thus widespread. Although the DTI format can still be used in SEPA, this involves some considerable limitations, as is the case with the MT94x format: Incomplete display of account details, since IBAN and BIC of the SEPA transactions cannot be transferred 1 : 1 to the DTI fields for account number and bank code Limited display of transaction data, since the SWIFT-MT character set can display a considerably lower number of characters than the UTF-8 character set used in SEPA More difficult automatic processing, since the detailed information on direct debits as well as on debtor and creditor in SEPA transactions can only be transported incompletely for reasons of space For this reason, as is the case with the MT94x format, the use of the camt.05x formats is recommended to allow for automatic processing without loss of information. If you nevertheless decide to continue using DTI, the following applies to SEPA: All information on posted SEPA transactions (bulked posting of credit transfers, direct debits or bulked postings based on purpose codes as well as returns of credit transfers and direct debits prior to and after entry) can be provided electronically in a SEPA DTI file. At UniCredit, this data can be retrieved up to 29 times a day (every half-hour).

15 15 6. The reporting formats in practice The above-listed variants of account statements and status reports are illustrated on the basis of the example below. In this case, the consistent use of the ISO XML formats is assumed, i.e. the customer has submitted SEPA transactions in ISO XML pain.001 or pain.008 format and also receives camt.052/053/054 account information and pain.002 status reports in ISO XML format. This way, the cycle is closed without format changes, all information is transported completely throughout the financial chain and the reconciliation process is optimally prepared. SEPA transaction cycle SEPA Credit Transfer (pain.001) SEPA Direct Debit (pain.008) XML XML Customer Clearing XML UniCredit XML Status report (pain.002) / account information (camt.052/053/054) The following sections illustrate the submission and processing of orders of a corporate customer on the basis of an example. UniCredit configures the corporate customer s master data for order processing as follows: Submitted pain.001 and pain.008 files are posted as a bulked amount. Rejects are confirmed via pain.002. Rejects are posted as a bulk via camt.053 according to the gross principle, i.e. one bulked entry per file and one reversed entry as a bulked amount per rejected transactions per file. Additional detailed information on the batched transactions is provided via camt.054 (break up collection into single transactions).

16 16 The corporate customer as the originator On the submission date The corporate customer submits two order files to the bank on the submission date, with the second submission consisting of two logical files (Payment Information PI-B1 and PI-B2). Corporate customer Submitted file A Group Header GH-A + Payment Information PI-A1 ++ Transactions: +++ #1 +++ #2 Submitted file B +++ #3 Group Header GH-B +++ #4 + Payment Information PI-B1 ++ TTransactions: +++ #1 +++ #2 +++ #3 +++ #4 + Payment Information PI-B2 ++ Transactions: +++ #1 +++ #2 +++ #3 +++ #4 Bank Under certain circumstances, the total file can be rejected by the bank on the submission date. In order to enable the corporate customer to determine the error situation merely by analysing the returned transactions, UniCredit lists all submitted transactions in pain.002, i. e. both the rejected transactions with the pertinent reason code and the correct transactions, which are assigned the reason code ED05 correct transaction within total file rejection and are not processed further because of the rejection of the total file. In the case of total rejection, the file is not posted either. Further examples of this error processing are provided above in section 5.2 on page 10. The following sections only deal with the rejection of individual transactions, instead of the case of total rejection. pain.002 for logical file PI-A1 Corporate customer Original Group Header GH-A Original Payment Information PI-A1 + Transactions: ++ #1 ED05 ++ #2 ED05 ++ #3 AC01 ++ #4 AM05 pain.002 for logical file PI-B1 Original Group Header GH-B Original Payment Information PI-B1 + Transactions: ++ #1 RC01 ++ #2 MS03 ++ #3 ED05 ++ #4 ED05 pain.002 for logical file PI-B2 Original Group Header GH-B Original Payment Information PI-B2 + Transactions: ++ #1 ED05 ++ #2 AC01 ++ #3 FF01 ++ #4 ED05 Bank

17 17 If the order files contain individual incorrect transactions, these will be rejected by the bank via pain.002 per logical file directly on the submission date prior to entry, i. e. prior to the execution date of SCT and prior to the due date of SDD. The rejected transactions are assigned an appropriate reason code, e.g. AC01 for incorrect account number. The correct transactions are processed further by the bank. pain.002 for logical file PI-A1 Corporate customer Original Group Header GH-A Original Payment Information PI-A1 + Transactions: ++ #3 AC01 pain.002 for logical file PI-B1 ++ #4 AM05 Original Group Header GH-B Original Payment Information PI-B1 + Transactions: ++ #1 RC01 pain.002 for logical file PI-B2 ++ #2 MS03 Original Group Header GH-B Original Payment Information PI-B2 + Transactions: ++ #2 AC01 ++ #3 FF01 Bank After the submission date but prior to the entry date, i.e. prior to the due date of SDD Hereinafter it is assumed that the order files were accepted and only individual transactions of the submission were rejected. In the case of direct debit submissions, it may occur due to the presentation period of up to 14 days that direct debits are rejected after the submission date but prior to the entry date, i.e. the due date of the direct debit, for example because the debtor requests refund of the direct debit prior to the due date. The corporate customer is informed about this fact via pain.002, including a list of the respective transactions and the pertinent reason code SL01 specific service, positive/negative list of debtor. pain.002 for logical file PI-A1 Corporate customer Original Group Header GH-A Original Payment Information PI-A1 + Transactions: ++ #1 -> SL01 Debtor Debtor Bank bank

18 18 On the entry date, i.e. execution date of SCT and due date of SDD On the entry date, the file amounts are posted via a camt.053 account statement and the rejected transactions are reversed as a bulked amount per submitted file. camt.053 on the entry date Corporate customer Entry for submission of PI-A1 as a bulked amount #1+#2+#3+ Entry for rejection from PI-A1 as a bulked amount #1+#3+#4 Entry for submission of PI-B1 as a bulked amount #1+#2+#3+ Entry for rejection from PI-B1 as a bulked amount #1+#2 Entry for submission of PI-B2 as a bulked amount #1+#2+#3+ Entry for rejection from PI-B2 as a bulked amount #2+#3 Bank In addition, the details of the rejected transactions are provided in a camt.054 batched transaction notification. camt.054 for rejects Corporate customer Rejects from A Entry for #1 (SL01) from PI-A1 Entry for #3 (AC01) from PI-A1 Entry für #4 (AM05) from PI-A1 Rejects from B Entry for #1 (RC01) from PI-B1 Entry for #2 (MS03) from PI-B1 Entry for #2 (AC01) from PI-B2 Entry for #3 (FF01) from PI-B2 Bank As a rule, all transactions are consolidated in a camt.054; however, several camt.054 messages are created under the following circumstances: Separate camt.054 messages are created for submitted SCT, SDD CORE, SDD COR1, SDD B2B and SCC. If several outgoing payment runs are configured in the master data, this may lead to several corresponding camt.054 messages. Rejects prior to entry and returns after entry are provided in separate camt.054 messages.

19 19 After the entry date Rejects of the submitted files after the entry date are recorded in a camt.053 account statement as well as a camt.054 batched transaction notification on the entry date of the respective reject, e.g. if the debtor requests refund after a direct debit is posted, this is listed in camt.053 and camt.054 with the reason code MD06 refund request by debtor. camt.053 on the entry date + X Entry for incoming payments as a bulked amount, including individual items RETURN #2 (MD06) from PI-A11 camt.053 on the entry date + X Corporate customer Entry X Entry Y Entry für RETURN #2 (MD06) aus PI-A1 Entry Z Bank The corporate customer as the beneficiary If the corporate customer is at the receiving end, the interaction between batched transactions in the camt.053 account statement and the camt.054 batched transaction notification applies analogously; however, this is much easier to illustrate, since the pain.002 need not be taken into account: Ordering customer camt.053 (account statement) <Entry 1> <bulked postings> <Entry 2> <Entry > Ordering customer Ordering customer <?XML> Bank Recipient camt.054 (bulk details) <bulked transaction 1> <bulked transaction 2> <bulked transaction >

20 20 7. Appendix 7.1. Description of technical formats camt.052/053/054 Account information UniCredit provides you with account information in the international ISO standard, which is based on the XML (EXtensible Markup Language) syntax. The XML format is a globally valid standard for the reproduction of data in a hierarchical structure. The internationally standardised UTF-8 encoding is used as an extensive character set with a great number of country-specific mutated vowels, which is also shown in the XML header: <?xml version="1.0" encoding="utf-8"?>. The German Banking Industry Committee (DK) additionally gives German financial institutions mandatory field allocation rules, which are entirely compatible with ISO The camt.052, camt.053 and camt.054 messages provided by UniCredit comply with these DK rules set out in Appendix 3 of the specification of remote data transfer between customer and bank according to the DFÜ Agreement Specification of Data Formats. In addition, UniCredit messages fulfil CGI (Common Global Implementation) Initiative requirements, which aim to define a globally uniform implementation standard for ISO messages. UniCredit currently produces the following versions of the camt.052, camt.053 and camt.054 account information formats: ISO message For Version Replaces camt.052 Account reports during the day camt MT942 camt.053 Account statements camt MT940 camt.054 Batched transaction notifications camt DTI The technical formats are described in greater detail in our Reporting, camt formats brochure, which you can obtain from your Cash Management & Banking Specialist upon request pain.002 Status/error file Along with a pain.002 status/error file in the ISO XML format, you will receive concise feedback on the submitted transactions, including a statement of the type of the error in the case of incorrect transactions. In pain.002 too, the internationally standardised UTF-8 encoding is used as an extensive character set with a great number of country-specific mutated vowels, which is also shown in the XML header: <?xml version="1.0" encoding="utf-8"?>.

21 21 Since the pain.002 is structured in such a way that all data of the original submission is retained, clear matching with the original transaction is ensured on the basis of the original reference numbers. Group Header (1..1) pain.002 Original Group Information and Status (1..1) Original Payment Information and Status (1..n) Transaction Information and Status (1..n) Original Transaction Reference (1..1) The most important technical XML fields for the pain.002 for SEPA Credit Transfer (SCT) and SEPA Direct Debit (SDD) are listed in the table below. Field name Description pain Entries as per DFÜ Agreement 2.8 GrpHdr GroupHeader Absenderdaten 1 x pro pain.002 OrgnlGrp InfAndSts MsgId (MessageId) CreDtTm (CreationDateTime) SCT: DbtrAgt SDD: CdtrAgt (ServicingDebtor/CreditorAgent) OriginalGroupInformation AndStatus OrgnlMsgId (OriginalMessageId) OrgnlMsgNmId (OriginalMessageNameId) OrgnlNbOfTxs (OriginalNumberOfTransactions) OrgnlCtrlSum (OriginalControlSum) GrpSts (GroupStatus) StsRsnInf-Orgtr (StatusReasonInfoOriginator) StsRsnInf-Rsn-Cd (StatusReasonInfoCode) Bank reference number per file Mandatory field Max. 35 characters UniCredit: 3rd position F = return prior to entry, 3rd position I = return after entry Date/time of file creation Mandatory field ISO date BIC of account-holding bank Mandatory field 8 or 11 digits and status of the original physical file (Group Header level) Original reference number of customer submission 1 x per pain.002 Original XML file type SCT: pain.001 SDD: pain.008 Original number of all single transactions Original control sum of submission in EUR Status at file level Originator of return Return reason A status has to be indicated at either GrpHdr, OrgnlPmtInfAndSts or TxInfAndSts level Only in combination with GrpSts. Optional, either Nm with name or Id-OrgId-BICOrBEI with BIC has to be indicated Return reasons according to separate document on business transaction and return codes* RJCT (reject) UniCredit: Status only at transaction level. If the file is rejected, all transactions will be returned. Name (max. 70 characters) for returns initiated by customer or BIC for returns initiated by bank.

22 22 Field name Description pain Entries as per DFÜ Agreement 2.8 OrgnlPmt InfAndSts TxInfAndSts OriginalPayment InformationAndStatus OrgnlPmtInfId (OriginalPaymentInfoId) OrgnlNbOfTxs (OriginalNumberOfTransactions) OrgnlCtrlSum (OriginalControlSum) PmtInfSts (PaymentInfoStatus) StsRsnInf-Orgtr (StatusReasonInfoOriginator) StsRsnInf-Rsn-Cd (StatusReasonInfoCode) TransactionInformation AndStatus StsId (StatusId) OrgnlInstrId (OriginalInstructionId) OrgnlEndToEndId (OriginalEndToEndId) TxSts (TransactionStatus) StsRsnInf-Orgtr (StatusReasonInfo Originator) StsRsnInf-Rsn-Cd (StatusReasonInfoCode) and status of the original logical file(s) (PaymentInformation level) Original reference of submission Original number of all single transactions Original control sum of the logical file in EUR Status at logical file level Originator of return Return reason Reference numbers and status of the original transaction(s) (TransactionInformation level) Number depending on original data A status has to be indicated at either GrpHdr, OrgnlPmtInfAndSts or TxInfAndSts level Only in combination with PmtInfSts. Optional, either Nm with name or Id-OrgId-BICOrBEI with BIC has to be indicated Return reasons according to separate document on business transaction and return codes* Number depending on original data Section optional if GrpSts is filled RJCT (reject) UniCredit: Status only at transaction level. If the file is rejected, all transactions will be returned. Name (max. 70 characters) for returns initiated by customer or BIC for returns initiated by bank. Section optional if PmtInfSts is filled Bank reference of return Optional Max. 35 characters Original technical reference between ordering party and bank Original customer reference Status at transaction level Originator of return Return reason A status has to be indicated at either GrpHdr, OrgnlPmtInfAndSts or TxInfAndSts level Only in combination with TxSts. Optional, either Nm with name or Id-OrgId-BICOrBEI with BIC has to be indicated Return reasons according to separate document on business transaction and return codes* OrgnlTxRef OriginalTransactionReference of the original transaction 1x per TransactionInformation- AndStatus InstrAmt (InstructedAmount) SCT: ReqdExctnDt (RequestedExecutionDate) SDD: ReqdColltnDt (RequestedCollectionDate) Only SDD: CdtrSchmeId-Id-PrvtId-OthrId-Id (CreditorIdentification) Only SCT: InstrPrty (InstructedPriority) SvcLvl (ServiceLevel) Original amount and currency code Originally requested execution date (SCT)/ due date (SDD) Only SDD: Original creditor identification RJCT (Reject) UniCredit: Status only at transaction level. If the file is rejected, all transactions will be returned. Name (max. 70 characters) for returns initiated by customer or BIC for returns initiated by bank. UniCredit: ED05 for correct transaction within total file rejection. As a rule, only one return reason is indicated. Only SCT: Original execution priority Only SCT: HIGH or NORM Original ServiceLevel SEPA

23 23 Field name Description pain Entries as per DFÜ Agreement 2.8 Only SDD: LclInstrm-Cd (LocalInstrumentCode) Only SDD: SeqTp (SequenceType) CtgyPurp (CategoryPurpose) PmtMtd (PaymentMethod) Only SDD: Mndtld (MandateId) Only SDD: DtOfSgntr (DateOfSignature) Only SDD: AmdmntInd (AmendmentIndicator) Only SDD: OrgnlMndtId (OriginalMandateId) Only SDD: OrgnlCdtrSchmeId-Nm (OriginalCreditorName) Only SDD: OrgnlCdtrSchmeId-Id- PrvtId-OthrId-Id (OriginalCreditorIdentification) Only SDD: OrgnlDbtrAcct-IBAN (OriginalDebtorIBAN) Only SDD: OrgnlDbtrAgt-Id (OrignalDebtorAgentId) Only SDD: ElctrncSgntr (ElectronicSignature) RmtInf (RemittanceInfo) UltmtDbtr (UltimateDebtor) Dbtr-Nm (DebtorName) Dbtr-PstlAdr-Ctry (DebtorCountry) Dbtr-PstlAdr-AdrLine (DebtorAddress) DbtrAcct-IBAN (DebtorAccountIBAN) DbtrAgt-BIC (DebtorAgentBIC) CdtrAgt-BIC (CreditorAgentBIC) Cdtr-Nm (CreditorName) Cdtr-PstlAdr-Ctry (CreditorCountry) Cdtr-PstlAdr-AdrLine (CreditorAddress) CdtrAcct-IBAN (CreditorAccountIBAN) UltmtCdtr (UltimateCreditor) Only SDD: Original direct debit type: CORE or B2B Only SDD: Original sequence: first, recurrent, one-off or final direct debit Original category purpose of the file Original payment instrument: Credit Transfer (SCT) / Direct Debit (SDD) Only SDD: Original mandate reference Only SDD: Original date on which the mandate was signed Only SDD: Original identifier whether the mandate data has been amended Only SDD: Original reference of the former mandate, if changed Only SDD: Original former creditor name, if changed Only SDD: Original former creditor identification, if changed Only SDD: Original former IBAN of debtor if the IBAN has changed Only SDD: CORE, COR1 or B2B Only SDD: FRST, RCUR, OOFF or FNAL SCT: TRF SDD: DD Only SDD: true if changed, otherwise false or field not listed Only SDD: Original former debtor bank Only SDD: SMNDA Only SDD: Original electronic mandate emandate signature Original remittance information (unstructured or structured) Original debtor if other than the account holder Original name of debtor Original country of the address of debtor Original address of debtor Original IBAN of debtor Original BIC of debtor bank or Id in the case of IBAN-Only Original BIC of creditor bank or Id in the case of IBAN-Only Original name of creditor Original country of creditor Original address of creditor Original IBAN of creditor Original ultimate creditor, if other than the account holder Max. 140 characters * Please do not hesitate to contact your Cash Management & ebanking Specialist if your are interested in getting our Business transaction and return codes brochure.

24 MT940, MT942 Account information The SWIFT messages MT940 for account statements and MT942 for interim transaction reports also allow for retrieving account information. UniCredit provides these message types in conformity with Appendix 3 of the specification of remote data transfer between customer and bank according to the DFÜ Agreement Specification of Data Formats. Despite being used internationally, the SWIFT-MT character set, compared to the extensive UTF-8 character set, only offers a very limited number of characters consisting of the digits 0 9, the letters a z and A Z, the special characters / -? : ( )., ' + as well as the blank character. In SEPA transactions with characters outside the SWIFT MT character set, some characters are thus converted, which makes automatic processing more difficult. Although the SWIFT structures in MT940 and MT942 remain unchanged in SEPA, the contents of fields 61 and 86 have been amended. The mandatory field 61 has been amended as follows: Structure of field 61 Content Remarks 61/7 (Customer reference) From SCT or SDD: payment information identification if allocated on submission, otherwise bulk message ID 61/9 (Further information) For SDD returns: Entry of the original amount as OCMT (original amount) and CHGS (total amount of fees and interest compensation, if applicable) If longer than 16 digits: KREF+ and total content of field 86 If empty: NONREF

25 25 In addition to the mandatory fields, the MT940 and MT942 contain the optional field 86 that provides information to the account holder. UniCredit uses a substructure to provide detailed information for SEPA in structured form, as shown below. A three-digit business transaction code in combination with the corresponding posting text is provided for identifying the type of the underlying transaction. Structure of field 86 for SEPA transactions Position or field key Designation Length / Format*, to date The first 3 digits Length / Format*, new Remarks Business transaction code 3n No change Specific BTCs will be assigned for SEPA (1xx)?00 Posting text 27a No change Specific posting texts will be assigned for SEPA?10 Primary note no. 10x?20?29 Remittance information 10 x 27x No change The SEPA attributes present in the transaction are depicted via identifiers: EREF+[end-to-end reference] KREF+[customer reference] MREF+[mandate reference] CRED+[creditor identifier] or DEBT+[originator s identification code] SVWZ+[SEPA remittance information] ABWA+[different originator] ABWE+[different beneficiary] Every identifier must be placed at the beginning of a subfield (e.g.?21), content may be continued in the subsequent subfield without the identifier having to be repeated. In cases of return SVWZ+[SEPA-REJECT or RUECKUEBERWEISUNG (returned credit transfer) or RUECKLASTSCHRIFT (returned direct debit) and return reason in plain text]?30 Bank code of originator/beneficiary?31 Account number of originator/beneficiary?32?33 Name of originator/beneficiary 12n 12x 24n 34x IBAN instead of account number 2 x 27x No change SEPA length 70; cut to 54 (2 x 27)?34 Text key extension 3n No change Use of a mapping table for conversion of the four-digit SEPA return code into a three-digit code?60?63 Remittance information 4 x 27x No change If applicable, continuation of?20?29 * n = numerical, a = alphabetical, x = alphanumerical