ZV Formate en

Payment transactions
Formats
Updated Version with amendments from 21 November 2021
September 2021
Content
Contents 11 Reporting overview 56
11.1 Reporting (bank – customer) 56
1 ISO 20022 data formats 4
11.2 Posting of SEPA files 57
2 Relation between customer and bank formats

12 International payment formats 59
(ISO 20022) 5
12.1 The country-specific formats 59
3 SEPA customer formats 6 12.2 The European SEPA basic format EPC 60
12.3 CGI-MP – Common Global Implementation Market Practice
4 Amendments in November 2021 9 Initiative61
12.4 Specification in comparison to CGI-MP, EPC and DK 63
5 Identification of message types 12
13 Same-day urgent credit transfers
6 Customer file structure: Extensible Mark-up
in euro via pain.001 67
Language – XML 17
14 Cross-border credit transfers (SWIFT gpi) 69
7 SEPA Credit Transfer (SCT) 19
14.1 Current Version pain.001.001.03 69
7.1 SEPA instant payments with pain.001.001.09 22
14.2 New Version for 2022 (pain.001.001.09)
8 Example of a customer file 23 (Cross-border credit transfers) 72
9 SEPA Direct Debit (SDD) 24 15 Electronic recall request/camt.055 75
10 Usual payment information 28

10.1 Remittance information 28
10.2 Purpose Code 32
10.3 Category Purpose 34
10.4 Special service for salary payments 34
10.5 The five parties to a transaction message 35
10.6 Name, address 37
10.7 IBAN, BIC 39
10.8 Creditor Identifier (CI) 42
10.9 Identification numbers (OrgId/PrvtId) 43
10.10 Ultimate/Reference Party/On Behalf 44
10.11 Mandate amendment 45
10.12 Direct debit sequence 47
10.13 Characters and mutated vowels (umlauts) 49
10.14 Competing fields – XOR 51
10.15 Reference numbers and how to use them 52
Text is highlighted this way to quickly show you where the amendments have occurred.
2
The following brochure contains important details about Please consider the information provided in this brochure
the technical specifications and the different payment as recommendations. It is based on the the SEPA Rulebooks
transaction formats. issued by the EPC as well as the country-specific bodies.
The brochure also describes XML formats for international
payments.
3
1 ISO 20022 data formats
Data formats
SEPA data formats are based on ISO Standard 20022/UNIFI (Universal Financial Industry Message Scheme: www.iso20022.org)
for XML.
• XML is an open standard
• Arbitrary field content
• Character set is UTF-8, specified in XML header <?xml version="1.0" encoding="UTF-8"?>
The implementation guidelines (Inter-banking-Transactions) were released by the European Payments Council (EPC) in
September 2006 and are further developed on an annual basis
• As an XML-based format, ISO 20022 provides the foundation for modern global payment transactions and offers a vast
spectrum of choices; hence, appropriate flexibility
• SEPA is the first application of consistent ISO 20022 processing in the payment transactions process as far as all SEPA
products are concerned. The entire process chain, including account statements, is already XML-ISO 20022-based in the
SEPA environment
<CdtTrfTxInf>
    <PmtId>
        <EndToEndId>OriginatorID1234</EndToEndId>
    </PmtId>
    <Amt>
        <InstdAmt Ccy=“EUR“>1234.56</InstdAmt>
    </Amt>
    <CdtrAgt>
        <FinInstnId>
            <BIC>SPUEDE2UXXX</BIC>
        </FinInstnId>
    </CdtrAgt>
    <Cdtr>
        <Nm>Creditor Name</Nm>
    </Cdtr>
    <CdtrAcct>
        <Id>
            <IBAN>DE21500500009876543210</IBAN>
        </Id>
    </CdtrAcct>
    <RmtInf>
        <Ustrd>Unstructured Remittance Information</Ustrd>
    </RmtInf>
</CdtTrfTxInf>
The pain-format (payment initiation) has been defined for the customer-bank space.
4
2 Relation between customer
and bank formats
(ISO 20022)
Customers submit the pain format for payment transaction files to banks. In inter-bank relationships, the payments are
subsequently exchanged between the banks using the pacs format. As an option, the customer is provided with the camt
format to document account postings. As an option, errors/rejects may also be provided to the customer by the bank as a file
in the pain format.
Submission and Reporting
Payment order Error information
pain = payment initiation pain = payment initiation error messages

Payment initiation for • Positive and negative status information (pain.002)
• Credit Transfers (pain.001)
Customer • Direct Debits (pain.008)
pacs (payment clearing & settlement) pacs = payment clearing & settlement error messages
Clearing for • Error message/status (pacs.002)
• Credit Transfers (pacs.008)
• Direct Debits (pacs.003)
Bank
camt (cash management)

(as an option, also as MT940)
Account information
• Notification (camt.052)
Customer
• Statement of account (camt.053)
• DTI (camt.054)
Customer information
5
3 SEPA customer formats
Format evolution
What will change about the SEPA order data?
Outlook
Every year in November, a new SEPA Rulebook comes into force that provides the basis for the continuous updates to the latest
requirements. The German Banking Industry Committee transfers the necessary updates into Annex 3 to the DFÜ Agreement
(DFÜ: Remote-Data Transfer Agreement in the German Bank association DK), which means that you may possibly also have to
make updates to the formats and processes. 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.
However, the respective formats do have to be used to be able to utilise the new functions.
The currently discussed updates can be followed on the Internet:
• Changes in Annex 3 to the DFÜ Agreement planned by the German Banking Industry Committee:
• https://www.ebics.de/de/datenformate/gueltige-version
• Updates to be discussed by the European Payments Council (EPC) that issues the SEPA Rulebook:
• www.europeanpaymentscouncil.eu/index.cfm/sepa-credit-transfer/sct-consultations
• www.europeanpaymentscouncil.eu/index.cfm/sepa-direct-debit/sdd-consultations
November 2021 (DFÜ Agreement Appendix 3 – Version 3.5)

• New ISO versions (pain.001.09 and camt.05N) for instant payments
• Conversion to new reporting formats to ISO 20022 Version 2019 (camt.53.001.08, camt.053.001.008, camt.054.001.08)
• Adjustments and changes to the business transaction codes (BTC)
November 2020 (DFÜ Agreement Appendix 3 – Version 3.4, see Chapter 4 for further details)
• No format changes
• Announcement of pain.001 for international payments (Substitute for DTAZV)
• Decommission of MT940 and MT942 until 2025
November 2019 (DFÜ Agreement Appendix 3 – Version 3.3, see Chapter 4 for further details)
• Introduction of specific BTCs for SEPA Instant credit transfers
• Credit notification for instant credit transfers
• IBAN-Only rule in the case of non-EEA/EU countries
• Statement of address in camt.029
November 2018 (DFÜ (remote data transfer) Appendix 3 – Version 3.2, see Chapter 4 for further details)
• New credit transfer recall reasons for camt.055
• Extension of the electronic recall period for camt.055 to 13 months
• Minor adjustments to the DK business transaction codes (BTCs) and to the ISO 20022 Bank Transaction Codes Domain/
Family/Subfamily
• Specification of DK rulebook for bank fee message camt.086
• Reporting: uniform terminology for posting texts under the Payment Accounts Act (ZKG)
• Uniform naming conventions for standard DK formats in a zip container
• New order type BKA for the pdf account statement
• Deactivation of acceptance of DTE – Data Medium Urgent – in DTAUS format
• Elimination of old order types (XAZ, XTZ, XTX, XDZ, XDX)
• Introduction of instant payments
November 2017 (DFÜ Agreement Appendix 3 – Version 3.1)

• New DK format schemes, but with the same ISO namespace
• Direct debit sequence can be mixed within a bulk
• Extension of B2B Direct Debit return period to 3 days
• Electronic customer payment cancellation request via camt.055 and response via camt.029
• Positive status information on the submitted payment via pain.002
• Purpose codes INTC and CORT for urgent payments (CCU)
• Real-time credit transfers (instant payments) with individual BTCs
• Cancellation of old cheque BTCs
6
• Definition of camt pagination
• Cash-back payments for card payments
• Cancellation of old order types (DTI, DTE, CD1, C1C, EUE)
26 June 2017 (Regulation (EU) 2015/847 on Transfer of Funds)

• Direct debits outside the EU/EEA must be submitted with the debtor’s address
November 2016 (DFÜ Agreement Annex 3 – Version 3.0)

• New DK formats with standardised ISO Name space: pain.001.001.03, pain.008.001.02, pain.002.001.03
• Mandate reference may now also contain spaces (but not recommended)
• The characters “/” and “//” may only be used with limitations
• Change in the mandate change indicator due to IBAN-Only
• The shorter presentation period of COR1 (D-1) now applies to CORE
• COR1 is converted into CORE
• Simplified direct debit sequence for FIRST direct debits which can now be presented as recurrent

• New purpose codes and BTCs
• Reporting: substantiation of R-transactions and depiction of cheques

• Amendments of account statements, see brochure “Reporting” for more details
• Integration of SCC (SEPA Cards Clearing)
• Optional extension in file names of XML files in ZIP files

• Format versions: pain.001.003.03, pain.008.003.02, pain.002.003.03
• Shorter presentation period COR1
• IBAN-Only
• Urgent credit transfer as pain.001 with URGP service level

• Return code AC13 if the debtor is a consumer and FF05 if a direct debit with shorter presentation period COR1 (D-1) is not
possible
November 2011
No new formats

• Total fields (amount, item & reference) on the bulk level (PaymentInformation)
• Restructuring of the reject pain.002-message to accommodate customer requirements
• Structured feedback on return fees in MT940/MT942/DTI
• Return code FOCR due to SCT-recall after settlement (recall)
• Optional: purpose of payment donation (purpose code = CHAR)
• Optional: verification numbers adequate CreditorReference on transfer receipts

• Start SEPA Direct Debit CORE & SEPA Direct Debit Business-to-Business (B2B)
• Grouping standard homogenised – MIXED only in compliance with European Payments Council (EPC) requirements
• Optional: PurposeCodes standardised (more than 100 purpose codes) e. g. salary, employee/employer sponsored deferred
savings plans, public contribution accounts
• Optional: additional fields for the entry of third party names: ultimate creditor/debtor
• Optional: definition of formats for XML statement reporting (camt.052, camt.053, camt.054)
7
• No changes to the format. No content-related format changes, although grouping and containers have been taken into
account: pain.001.001.02, pain.001.001.02.grp, pain.001.001.02.con, pain.002.001.02.ct, pain.002.001.02.ct.con
January 2008 (DFÜ Agreement Annex 3 – Version 2.2)

• Start SEPA Credit Transfer
• Format versions: pain 001.001.02, 002.001.02.ct
8
4 Amendments in
November 2021
On 21st November 2021, a new DFÜ Agreement Appendix 3, version 3.5, will be introduced, which will include the following
important changes (published on https://www.ebics.de/de/datenformate/gueltige-version):
New ISO 20022 standard: Introduction of new camt versions

The reporting formats in the interbank area, i.e. all camt.05x messages (camt.052, camt.053, camt.054 and C5N), change from
ISO version 2009 to the new ISO version 2019. This changes from version 02 to version 08 (e.g. camt.052.001.02 becomes
camt.052.001.08).
camt.052.001.02 → camt.052.001.08
camt.053.001.02 → camt.053.001.08
camt.054.001.02 → camt.054.001.08
If the account statements are only managed globally in UC eBanking, the switch from MT messages to camt messages has no
further effects.
However, if UC eBanking Prime/Global is used including import/export to your own backend system, the new ISO version must
be supported by the backend system. The same applies if a separate EBICS client and backend system are used.
Therefore it is recommended to switch to the new ISO version.
From November 2021, camt Version 08 will be the leading system setting in the UniCredit systems. When the camt messages
are commissioned, the new camt version 08 is automatically stored.
With the introduction of the new camt version, from November 2022 for the international payments it is possible to supply the
structured address and structured remittance information with up to 9,000 characters. Third-party bank statements will also
have to be processed in the new camt version in the future, so the switch is also an advantage in this regard.
New business transaction and return codes

From November 2021, some changes will be made to the BTCs.
In the medium term, the business transaction codes (BTC) will lose their meaning and will be replaced by the domain, family
and subfamily. To be able to differentiate the products more clearly, there have been changes to these three codes (Domain/
Family/Subfamily). The transaction can then be assigned or identified based on this.
Updates:
• The business transaction code 088 “Urgent credit transfer” (PMNT/RCFT/SDVA) is available
• The business transaction code 188 “SEPA Instant Credit Transfer (bulk)” (OMNT/IRCT/ESCT) is available in connection with
Instant Payments
• The business transaction code 401 “Foreign exchange spot transaction” (Credit/Debit) is deleted and replaced by the
business transaction codes
• 411 “Foreign exchange buying” (Debit) (FORX/SPOT/OTHR) and
• 412 “Foreign exchange selling” (Credit) (FORX/SPOT/OTHR) replaced
• The business transaction code 402 “Foreign exchange future transaction” (credit / debit) is deleted and replaced by the
business transaction codes
• 413 “ Foreign exchange future buy” (Debit) (FORX/FWRD/OTHR) and
• 414 “ Foreign exchange future sell” (Credit) (FORX/FWRD/OTHR) replaced
• The business transaction code 803 “ Safe custody fee” (Credit/Debit) is deleted and replaced by the business transaction codes
• 321 “Safe custody fee” (Debit) (SECU/CUST/CHRG) and
• 321 “Rufund safe custody fee” (Credit) (SECU/CUST/CHRG) replaced
9
• The business transaction code 072 “Bill of exchange” (Credit) is deleted and replaced by the business transaction code
217 “BILL” Bill of exchange (export) (PMNT/ DRFT/STAM)
• The business transaction code 073 “Bill of exchange” (debit) is deleted and replaced by the business transaction code 216
“BILL” Bill of exchange (import) (PMNT/DRFT/STAM)
Cross boarder payments receive differentiated sub-families:

• The following codes are added to the business transaction code 201 (PMNT/ICDT/XBCT)
• “Payment order abroad” (Debit) (PMNT/ICDT/XBCT)
• “Abroad salary payment order” (Debit) (PMT/ CDT/XBSA). Is currently not used by UniCredit Bank AG
• “Return of incoming payment” (Credit) (PMT/RCDT/XRTN). Is currently not used by UniCredit Bank AG
• Business transaction codes 202 (PMNT/RCDT/XBCT)
• “Incoming payments abroad” (Credit) (PMT/RCDT/XBCT)
• “Incoming payment abroad salary” (Credit) (PMT/RCDT/BSA). Is currently not used by UniCredit Bank AG
• “Re-credit AZV payment” (Credit) (PMT/ICDT/XRTN). Is currently not used by UniCredit Bank AG
• New family: Business transaction codes 818 “DEBIT” (PMNT/MDOP/OTHR)
• New family: Business transaction codes 819 “CREDIT” (PMNT/MCOP/OTHR)
• New sub-family: Business transaction codes 117 “Standing order (execution)” (Debit) (PMNT/ICDT/STDO)
• New family: Business transaction codes 167 “SEPA Credit transfer (Credit)” (PMNT/RCDT/ESCT)
• New family: Business transaction codes 833 “Balance correction” (Credit/Debit) (CAMT/CAPL/OTHR)
• New Family: Business transaction code 112 “Payment order for account” (PMNT/ICHQ/ESCT)
• New Family: Business transaction code 159 “SEPA return”, “SEPA reject” (PMNT/ICDT/RRTN)
• New Sub-Family: Business transaction code 829 Debit “SAVINGS FROM SALARY” (LDAS/FTDP/DPST)
Changes to the domain for business code 809:

• New domain: Business transaction codes 809 “LEND FEE” (Credit) (TRAD/MCOP/COMM)
• New domain: Business transaction codes 809 “LEND FEE” (Debit) (TRAD/MDOP/COMM)
• New domain: Business transaction codes 809 “GUARCOMM.” (Credit) (TRAD/MCOP/COMM)
• New domain: Business transaction codes 809 “GUARCOMM.” (Debit) (TRAD/MDOP/COMM)
• New domain: Business transaction codes 809 “Documentary credit commiss.” (Credit) (TRAD/MCOP/COMM)
• New domain: Business transaction codes 809 “Documentary credit commiss.” (Debit) (TRAD/MDOP/COMM)
Further details and changes on the business transaction codes and other changes can be found in the customer brochure
„Business transaction and return codes“.
New version pain.001 for Instant Payments

From November 2021 the version V09 can be used for submitting Instant Payments specifying ExecutionDateTime (execution
date with time). The new definition of pain.001.001.09 was included in DK Annex 3.5 of the DFÜ Agreement (valid version -
EBICS) and the differences in element names of V09 compared to the previous version were described.
The introduction of the new format (pain.001.001.09) opens new possibilities:

• Scheduling up to 15 days in the future
• Execution, specifying the date and time
The main differences between version 09 compared to version 03 are that some fields have been renamed:
• The element <BICOrBEI> from V03 was consistently renamed to <AnyBIC> in V09
• The element <BIC> from V03 was renamed consistently to <BICFI> in V09
Specification for the submission of international transfer order in

pain.001 (valid from 11/2022)
The Deutsche Kreditwirtschaft specifies further occupancy rules based on the original ISO20022 schema pain.001.001.09.
The message is used to electronically instruct credit transfers in individual/foreign payment transactions and of (same day)
express transfers in EURO by the payer to the payer’s payment service provider (ZDL) is used. The foreign credit transfers
have the EBICS order type AXZ.
10
The DTAZV format will no longer be used as DK standard by November 2025. The new format based on ISO Standard
20022can be offered optionally by payment service
Outlook on format evolution

The ISO 20022 XML format has increasingly found its way into payment transactions and account statements. Gaps are
currently being closed with the planned changes in the field of urgent and international payments. To that effect, XML is
planned to be introduced in 2022 as the standard for Target2 and SWIFT international payment transactions. MT103/MT202
will be replaced by pacs.008 and pacs.009. In the customer-to-bank format, DTAZV and MT101 via pain.001 will be offered
in the DFU Appendix 3 as early as 2022.
UniCredit has already accepted the cgi-MP pain.001.001.03 for international groups, but it had to be converted back to
MT103 at interbank level, involving data loss. With effect from November 2021, these format inconsistencies will be
eliminated, making it possible to forward all XML data. Furthermore, the reporting formats at interbank level will also be
changed from MT940, MT950 and MT900/MT910 to camt.053.001.08 and camt.054.001.08. Likewise, the MT940 bank-to-
customer statement will be successively replaced. DTI was removed from the standard as early as 2018. MT940/MT942 will
no longer be developed further and will be removed from the standard in 2025 at the latest.
Abolition of MT messages
As mentioned in the DK specification, all MT94x messages (MT900/MT910, MT940 and MT942) will be removed from
the DK standard by 2025 at the latest. The DK standard is therefore no longer being adapted today. Because of this it is
recommended to use the camt.05x formats or to switch to them.
We recommend that our customers start migrating from MT94x to camt.05x at an early stage. The bank will provide the
MT94x and camt.05x messages in parallel to make it easier for customers to switch. From the beginning of 2022, the two
reporting messages will be provided in parallel.
11
5 Identification of
message types
How can you identify the type of message and the version?
Structure of an XML message designation:

pain.001.003.03
• Business Area PaymentInitiation
• Message Definition CustomerCreditTransferInitiation
• Variant Die Deutsche Kreditwirtschaft (German Banking Sector) 2015
• Version V3 ISO Status 2009
ISO Name Version As of Supported by UniCredit

Rulebook
pain Payment Initiation
pain.001 CustomerCredit Transfer (SCT)
TransferInitiation
pain.001.001.09 DK Version 3.7 for SEPA and urgent payments planned for 2023 Planned
pain.001.001.09 DK Version 3.5 for instant credit transfers 2021
pain.001.001.09 DK Version 3.4 for international payment transac- planned for 2022 Planned
tions
pain.001.001.08 DK Version 3.2 with execution time SCTinst 2018 Not supported
pain.001.001.03 DK Version 3.3 für SCTinst 2018 Recommended for Instant
(CR-FS-17-08, GBIC_3.XSD) Payments
pain.001.001.03 Current DK version 3.2 – 3.4 2018 – 2020 Recommended<?>
pain.001.001.03 Previous DK version 3.1 2017 Recommended1
pain.001.001.03 Previous DK version 3.0 2016 Accepted1
pain.001.003.03 Old DK version 2.7 – 2.9 2013 – 2015 Will be disabled in 11/2022
pain.001.002.03 Old DK version 2.5 – 2.6 2010 – 2012 Disabled in 04/2020
pain.001.002.02 Old DK version 2.4 2009 Disabled on 19/11/2017
pain.001.001.02.grp -.con Old DK version 2.3 2008 Disabled on 19/11/2017
pain.001.001.05 ISO version 2/2015 Not supported
pain.001.001.03 EPC Version with ExtendedRemittanceInfo 2019 Not supported
pain.001.001.03 Current EPC Version; Current CGI-MP-Version; 2010 – 2020 Recommended for
ISO version 2010 international customers1
pain.001.001.02 ISO version 1/2009 2008 – 2010 Not recommended
pain.008 CustomerDirect Direct debit
DebitInitiation
pain.008.001.08 DK Version 3.7 for SEPA planned for 2023 Planned
pain.008.002.04 Current DK version for SEPA Cards TA 7.1 – 7.2 2015 – 2020 Only for SCC
pain.008.001.02 Current DK version 3.1 – 3.4 2017 – 2020 Recommended1
pain.008.001.02 Previous DK version 3.0 2016 Accepted1
pain.008.003.02 Old DK version 2.7 – 2.9 2013 – 2015 Will be disabled in 11/2022
pain.008.002.02 Old DK version 2.5 – 2.6 2010 – 2012 Will be disabled on 16/11/2019
12
ISO Name Version As of Supported by UniCredit
Rulebook
pain.008.001.02 Current EPC version; Current CGI-MP version; 2010 – 2020 Recommended for
ISO version 2010 international customers1
pain.002 PaymentInitiation Status Reject/Status message
pain.002.001.10 DK Version 3.6 international payments in planned for 2022 Planned
planning
pain.002.001.03 Current DK Version 3.1 – 3.4 2017 – 2020 Supported depending on submission
pain.002.001.03 Previous DK Version 3.0 2016 Supported depending on submission
pain.002.003.03 Old DK version 2.7 – 2.9 2013 – 2015 Will be disabled on 11/2022
pain.002.002.03 Old DK version 2.5 – 2.6 2010 – 2012 Disabled in 04/2020
pain.002.001.03 Current EPC version; Current CGI-MP version; 2010 – 2020 Supported depending on submission
ISO version 2010
pain.002.001.02 Old EPC version rulebook ISO version 1/2009 2009 Not supported
pain.007 CustomerPayment SCC-Reversal
Reversal
pain.007.002.04 Current DK version for SEPA Cards TA 7. – 7.2 2015 – 2019 Only for SCC
camt Cash Management
camt.052 BankToCustomer Intraday advice MT942 successor
AccountReport
camt.052.001.08 ISO version 2019 DK Version 3.5 From 11/2021
camt.052.001.04 ISO version 1/2015 Not supported
camt.052.001.02 Current DK version 2.4 – 3.4 2009 – 2020 Old version. Will be disabled in
ISO version 4/2009 2025
camt.053 BankToCustomer Account statement MT940 successor
Statement
camt.054 BankToCustomer Bulk DTI file number successor
DebitCredit Notification
camt.055 CustomerPayment Recall request
Cancellation Request
camt.055.001.05 Current DK Version 3.1 – 3.4 2017 – 2020 From 11/2017
ISO version 2/2016
camt.055.001.04 Previous version UniCredit 2014 As of March 2016
ISO version 3/2015
camt.029 ResolutionOf Response to camt.055 recall
Investigation
camt.029.001.06 Current DK version 3.1 – 3.4 2017 – 2020 As of December 2016
ISO version 2/2016
camt.086 BankServices Billing Formerly TWIST BSB
Statement
camt.086.001.01 ISO version 5/2013 2013 – 2017 Accepted
camt.086.001.02 Current DK Version 3.2 – 3.4 2018 – 2020 Recommended
13
Initiation of a SEPA Credit Transfer – customer-to-bank space
The following types of orders are available through the transfer channels (EBICS/HBCI or FinTS):
SEPA Credit Transfer Order Types – DK format

Name space/Scheme Credit transfer 3.5 (November 2021)
EBICS-mixed urn:iso:std:iso:20022:tech:xsd:pain.001.001.03 CCT
pain.001.001.03
EBICS-XML-Instant CIP (instant payments)
urn:iso:std:iso:20022:tech:xsd:pain.001.001.03 pain.001.001.03
urn:iso:std:iso:20022:tech:xsd:pain.001.001.09 pain.001.001.09
EBICS mixed special process (In the event of urn:iso:std:iso:20022:tech:xsd:pain.001.001.03 XCT
approval via distributed electronic signature, pain.001.001.03
transaction details at your bank are suppressed,
which is particularly relevant in the case of
salary files)
EBICS XML container urn:conxml:xsd:container.nnn.001.02 CCC
(+urn:iso:std:iso:20022:tech:xs- pain.001.001.03
d:pain.001.001.03)
EBICS status message urn:iso:std:iso:20022:tech:xsd:pain.002.001.03 CRZ (zip file) or
CRC (XML container) or
CIZ (Instant)
pain.002.001.03
HBCI bulk – HKCCM, HKCME
HBCI Instant payments – HKIPZ
EBICS-Rückruf urn:iso:std:iso:20022:tech:xsd:camt.055.001.05 C55
camt.055.001.05
Information on the status of the payment
cancellation request is provided via
camt.029.001.06
UniCredit still accepts and delivers older versions of the DFÜ Agreement:
• DFÜ Agreement Annex 3.0 - 3.4 (2016 - 2020) : pain.001.001.03 or pain.002.001.03
• DFÜ Agreement Annex 2.7 – 2.9 (2013 – 2015): pain.001.003.03 or pain.002.003.03
Credit Transfer with XML pain.001

Product Identification2 Clearing/Cut-off time Batch entry (bulk/single posting)3
SEPA Credit Transfer SEPA order types SEPA XML clearing, 12.15 pm on the same day, by Individual: BatchBooking = true/
(SCT) Servicelevel = SEPA 5 pm on the previous day false
InstructedPriority = NORM/HIGH
XML Euro Urgent Order types: CCU, XEU, XCU TARGET2 MT103, by 4.00 pm on the same day BatchBooking = true/false
Servicelevel = URGP
Instant payment Order type CIP Within 20 seconds 7/24/365 Always single entries
ServiceLevel = SEPA
LocalInstrumentCode = INST
XML Cross-Border Order type XEK, XCU, XC2 Bank clearing MT103, cross-border payment cut- Always single entry
Payment Foreign currency off time depending on the currency
EUR without EU/EEA BIC/IBAN
Service requires customer administration

2
14
Initiation of a SEPA Direct Debit – customer format
The following types of orders are available through the transfer channels (EBICS/HBCI or FinTS):
SEPA Direct Debit Order Types

Name space/Scheme SDD CORE 3.5 (November 2021) SDD B2B 3.5 (November 2021)
EBICS mixed urn:iso:std:iso:20022:tech:xsd:pain.008.001.02 CDD CDB
pain.008.001.02 pain.008.001.02
EBICS XML urn:conxml:xsd:container.nnn.001.02 CDC C2C
container (+urn:iso:std:iso:20022:tech:xs- pain.008.001.02 pain.008.001.02
d:pain.008.001.02)
EBICS status urn:iso:std:iso:20022:tech:xsd:pain.002.001.03 CDZ (zip file) or CDZ (zip file) or
message CBC (XML container) CBC (XML container)
pain.002.001.03 pain.002.001.03
HBCI bulk – HKDME HKBME
EBICS recall urn:iso:std:iso:20022:tech:xsd:camt.055.001.05 C55 C55
camt.055.001.05 camt.055.001.05
Information on the status of the pay- Information on the status of the pay-
ment cancellation request is provided ment cancellation request is provided
via camt.029.001.06 via camt.029.001.06
UniCredit still accepts and delivers older versions of the DFÜ Agreement:
• DFÜ Agreement Annex 3.0 - 3.4 (2016 - 2020) : pain.008.001.02 or pain.002.001.03
• DFÜ Agreement Annex 2.7 – 2.9 (2013 – 2015): pain.008.003.02 or pain.002.003.03
Further information on pain.002 and the return reasons is provided in our brochures “Reporting” and “Business transaction
and return codes”. Since April 2015, transactions for SEPA Cards Clearing (SCC) can be transmitted using the ISO 20022
message types pain.008.002.04 (submission) and pain.007.002.04 (reversal) and the pertinent order types. You can find further
information about SCC in the document “SEPA-Datenaustausch per DFÜ mit Service-Rechenzentren (SRZ) und Netzbetreibern
über EBICS”. You can obtain all the information from your Cash Management & eBanking Specialist upon request.
15
Comparison of versions with namespace
SEPA Credit Transfer
Namespace Version Header-Sum ServiceLevel IBAN-Only
• Sum euro in Msg
• Sum euro in PaymInf
• Number of Trx in PaymInf
pain.001.002.03 DK 2.6 (2012) was disabled in 04/2020 Optional SEPA no
pain.001.003.03 DK 2.7 – 2.9 (2013 – 2015) Optional SEPA/URGP yes
DK 3.0 (2016) Optional SEPA/URGP yes
ab DK 3.1 (2017) Mandatory fields SEPA/URGP yes
EPC (2007 – 2012) Optional SEPA no
pain.001.001.03 EPC (2013 – 2015) Optional SEPA yes
EPC (2016) Optional SEPA yes
EPC (since 2017) Mandatory fields SEPA yes
CGI (since 2016) Defined bilaterally SEPA/URGP/SDVA/NURG yes
SEPA Direct Debit

Namespace Version Header-Sum SMNDA PaymentType IBAN-Only
• Sum euro in Msg • only with mandate • ServiceLevel SEPA
• Sum euro in PaymInf amendment • LocalInstrument CORE/B2B
• Number of Trx in PaymInf • Sequenz FRST/RCUR/OOF/FNAL
DK 2.6 (2012) Only Header/PaymInf

Field group
pain.008.002.02 was disabled Optional • Only 1 sequence per bulk possible no
DebtorAgent
in 04/2020 • LocalInstrument CORE/B2B
Only Header/PaymInf
DK 2.7 – 2.9 Field group
pain.008.003.02 Optional • Only 1 sequence per bulk possible yes
(2013 – 2015) DebtorAgent
• LocalInstrument: CORE/COR1/B2B
Only Header/PaymInf
DK 3.0 Field group
pain.008.001.02 Optional • Only 1 sequence per bulk possible yes
(2016) DebtorAccount
• LocalInstrument: CORE/B2B
Header/PaymInf or at transaction
ab DK 3.1 Field group level
Mandatory fields yes
(2017) DebtorAccount • Mixed sequence per bulk
Only Header/PaymInf
EPC Field group
Optional • Only 1 sequence per bulk possible no
(2007 – 2012) DebtorAgent
Only Header/PaymInf
EPC Feldgruppe Debt-
Optional • Only 1 sequence per bulk possible yes
(2013 – 2015) or-Agent
Only Header/PaymInf
EPC Feldgruppe Debtor-Ac-
Optional • Only 1 sequence per bulk possible yes
(2016) count
EPC Field group level
Mandatory fields yes
(since 2017) DebtorAccount • Mixed sequence per bulk
Field group
CGI level
Defined bilaterally Debtor-Account and/ yes
(since 2016) • Mixed sequence per bulk
or DebtorAgent
16
6 Customer file structure:
Extensible Mark-up
Language – XML
XML Container
• Only for German DK formats
• Optional
GroupHeader
• This block must be included and exists once
• It contains elements, such as the message ID, creation date and time
PaymentInformation (bulk level)
• This block must appear at least once and is repeatable
• It contains elements that pertain to the transaction’s origins, e. g. the presenter or payment type information or several
transaction information blocks
• Logical bulk level for the posting of the presenter (consolidated)
TransactionInformation
• This block must appear at least once per payment information and is repeatable
• Among other things, it contains elements that refer to
• the payment beneficiary for credit transfers
• the debtor in conjunction with direct debits
• Contains the amount and remittance information
Order Type Containers and File Structure with GroupHeader, PaymentInformation and TransactionInformation
DK XML-Container: EBICS-order type CCC EBICS-Auftragsart CCT (mixed)

pain.001, GroupHeader, InitiatingParty Company name-1
PaymentInformation – Debtor: Account-1
TransactionInfo TransactionInfo TransactionInfo
TransactionInfo TransactionInfo TransactionInfo Creditor/EUR Creditor/EUR Creditor/EUR
Creditor/EUR Creditor/EUR Creditor/EUR

TransactionInfo TransactionInfo
TransactionInfo TransactionInfo Creditor/EUR Creditor/EUR
Creditor/EUR Creditor/EUR
pain.001, GroupHeader, InitiatingParty Company name-1 EBICS-Auftragsart CCT (mixed)

TransactionInfo
Creditor/EUR TransactionInfo
Creditor/EUR
17
Grouping of files and which ones can be delivered in mixed transactions?
SEPA files are submitted as bulks, so that files have to be created

• For each physical file (XML container or GroupHeader) divided by
• Product (SCT, SCTInst, SDD CORE, SDD B2B, CT-Urgent) XML-Scheme, <PmtInfId>, <SvcLvl> and <LclInstrm>), given that a
separate transmission order type has to be used for each delivery
• For each logical bulk (PaymentInformation), in particular also divided by
• IBAN of ordering party
• Due date <ReqdColltnDt> or execution date <ReqdExctnDt>
• Differentiation between SCT and SCT-Preferred (same day clearing) <InstrPrty>
• Bulk/single posting of the submission <BtchBookg>
• Number of transactions or file size limits, see below1
• The following can be placed into one logical bulk together:
• Direct debits: various recipients or debtors
• Different amounts <Amt>
• RemittanceInformation <RmtInf>, PurposeCodes <Purp>, End-to-End references <EndToEndId>
• Differing mandate information for direct debits
• From November 2017: direct debit sequence (First, Recurrent, Final, OneOff) <SeqTp>
• Instant Payments:
• An individual physical file (GroupHeader) must be delivered for each transaction
Checks for duplicate file processing

To prevent the duplicate processing of files, UniCredit checks the logical bulks (PaymentInformation) based on the following
principles:
• IBAN for presenter
• Time frame: 15 target days
• Total amount in EUR
• Determined number of items
• Product (SEPA Credit Transfer, Instant Payment, SEPA Direct Debit CORE, SEPA Direct Debit B2B)
• Control sum consisting of the check digits (digit 3 and 4) and the country-specific last six digits of the payee’s IBAN
DE12120300001004411540 12 + 411540 = 411552
FR7630004002380002110111495 76 + 111495 = 111571
BE84390095817059 84 + 817059 = 817143
Control sum = 1340266
• Payment reference ID only on submission via data processing service centres
1 DTAUS, the current payment format, uses much smaller file sizes than the XML file format. Without a header, a DTAUS transaction may have up to 622 bytes, while a SEPA transaction may contain up
to 2,100 bytes, plus header information. In order to receive files that can still be processed (file transfer, mapping, validation, error research, etc.) it is recommended not to use bulks of excessive size. A
maximum of 100,000 transactions per file is recommended (up to 210 MB)
18
7 SEPA Credit Transfer (SCT)
Basic characteristics
• Presenter and beneficiary accounts are both being maintained in the SEPA zone (the account holder may also be domiciled
outside of this zone)
• The transaction currency is always EUR
• Use of IBAN
• Remittance information is limited to 140 characters
• Purpose codes are possible as an option
• Use of on-behalf/ultimate optionally possible
• Reference options available
Instant Payments characteristics

• Initiation of instant payments like the present SEPA orders
• Individual transactions – like urgent payments
• Permanent availability 24/7/365
• Average execution time < 5 sec
• Current maximum limit EUR 15,000
• Initiated payments with amount > 15.000 EUR will be rejected by submission (EBICS error, no pain.002, no URGENT
processing), separate rules apply for amount pilot customers
• Amount limit for credits since July 2020 by 100.000 EUR
• Payments that cannot be executed as instant payments (Amount > EUR 15.000) will be rejected
• Payments that cannot be executed as instant payments (banks non-instant-ready) are executed as XML Urgent/urgent
credit transfer (see chapter 14). Only applies if no bulk booking has been commissioned.
• The DK scheme is pain.001.001.03 by means of the DK XSD name pain.001.001.03_GBIC_3
• Submission using the EBICS order type CIP
• LocalInstrument must be filled with “INST”
• The general conditions for the HVB instant payments bulks submission (bulk submission):
• Up to 100 transactions per bulk can be submitted.
• Each file can only contain 1 bulk (Bulk on payment information level).
• The files can be submitted for immediate execution. In addition, future execution days and times are possible up to 15
days in advance.
• Before the execution date is reached, the entire bulk order can be revoked. (Agreement on the submission and execution of
SEPA instant payments by means of bulk orders)
• When submitting bulk (collectors), the booking is made in accordance with the execution indicator Single/Bulk in the
pain.001
• If Single is given as the indicator, each individual payment is posted and displayed in the account statement
• If bulk is specified, the booking is made in one sum
• The response (positive or negative status of the payment) is sent via pain.002 using the CIZ order type at the time of
availability.
Important functional XML fields for SEPA Credit Transfer

Field Names Description Entry For more details
pain.001.001.03 DFÜ-Agreement Annex 3 – Version 3.5 see Page
GrpHdr GroupHeader Sender data 1 x per logical file 14 f.
MsgId Submitter reference number Mandatory (unique) Max. 35 characters 45 f. , 48 ff.
(Message-Id) for each file
CreDtTm Date/time file was created Mandatory ISO date
(CreationDateTime)
NbOfTxs Number of all single trans- Mandatory For credit transfers:
(NumberOfTransactions) actions unlimited; for instant
payments: one trans-
action
CtrlSum Amount submitted in EUR Mandatory Unlimited
(ControlSum) for cross-checking
InitgPty-Nm Name of the initiating party Mandatory Max. 70 characters 35 f.
(InitiatingPartyName) (may be different from
name of ordering party)
19
InitgPty-Nm-Id-OrgId/PrvtId Identification DK not recommended Various 43
(InitiatingPartyOrganisa- Only to be filled out if
tion-Id/Private-ID) submitted by data pro-
cessing service centres or
network operators.
PmtInf PaymentInformation Debtor data Any frequency possible, 17 f.
max. recommended 100
PmtInfId Bulk reference Mandatory Max. 35 characters 49 f., 52 ff.
(PaymentInformation-ID)
PmtMtd Payment method: credit Mandatory “TRF”
(PaymentMethod) transfer
BtchBookg Presenter booking bulk/ Optional, administrat- “false” – single posting 57 f.
(BatchBooking) sinlge ed in the master data “true” – bulk posting
system
NbOfTxs Total number of all single Mandatory Unlimited
(NumberOfTransactions) transactions
CtrlSum Cross-checking logical bulk Mandatory Unlimited
(ControlSum) amount in EUR
InstrPrty Priority of execution “high” Optional, administrat- “HIGH” – SCT Preferred 51
(InstructionPriority) or “norm” ed in the master data “NORM” – SCT Normal,
system<?> not relevant for instant
payments
SvcLvl-Cd Service scheme Mandatory field if the For payment “SEPA”, 51, 67
(ServiceLevelCode) higher-level “Payment “URGP”,
Type Information” field for instant payment
is used, otherwise only “SEPA”
recommended
(see footnote 4)
LclInstrm-Cd Type of credit transfer: Mandatory field for „INST“
(LocalInstrumentCode) SEPA-INST instant payment instant payments;
not permitted for other
types of credit transfer
CtgyPurp Bulk payment type/ Optional, administered For salary payment on 34, 51
(CategoryPurpose) Category Purpose in master data the same day “SALA”
(see footnote 4);
not permitted for other
types of credit transfer
ReqdExctnDt Desired settlement date Mandatory field; ISO date
(RequestedExecutionDate) for instant payments:
execution date is the
current day
Dbtr-Nm Name debtor, may have Mandatory Max. 70 characters 35
(DebtorName) been replaced with account
holder name by the bank
Dbtr-PstlAdr-Ctry Country of debtor’s address Optional Country code 37, 38
(DebtorCountry) ISO 3166,
DE for Germany
Dbtr-PstlAdr-AdrLine Address of the debtor, may Optional Max. 140 characters 37, 38
(DebtorAddress) have been replaced with
account holder name by
the bank
Dbtr-Id-OrgId/PrvtId Identification DK not recommended Miscellaneous 43, 52 ff.
(DebtorOrganisation-Id/Pri-
vate-ID)
DbtrAcct-IBAN IBAN of the debtor Mandatory Max. 34 characters 39 ff., 49 f.
(DebtorIBAN)
DbtrAcct-Ccy Debtor account currency Optional Currency code
(DebtorAccountCurrency)
DbtrAgt-BIC BIC/SWIFT code of the Optionally IBAN-Only 8 or 11 digits 36, 49 f.
(DebtorAgentBIC) debtor
DbtrAgt-Othr-Id IBAN-Only ID Only if using IBAN-Only „NOTPROVIDED“ 39
(DebtorAgentId)
20
UltmtDbtr Debtor that is not identical Optional Max. 70 characters 35 f., 44, 51
(UltimateDebtorName) with the account holder.
Sole purpose is to provide
information.
UltmtDbtr-Id-OrgId-Othr Ultimate submitter debit Optional, only for product Max. 34 characters 39 ff., 44, 49 f.
(UltimateDebtor-IBAN) IBAN “Ultimate ordering party”
ChrgBr (ChargeBearer) Charging always shared Recommended „SLEV“ 51
CdtTrf CreditTransfer TransactionsInformation Any frequency possible, For instant pay- 17 f.
TxInf TransactionInformation max. recommended ments: max. 10,000
100,000
InstrId Technical reference be- Optional, if completed: Max. 35 characters 49 f., 52 ff.
(Instruction-ID) tween submitter and bank unique
EndToEndId Reference to be passed on Mandatory (has to be Max. 35 characters 49 f., 52 ff.
(End2End-ID) to the beneficiary definitive, if not: “NOT-
PROVIDED”)
InstdAmt Amount and currency code Mandatory Only euros per-
(InstructedAmount) mitted, max. EUR
999,999,999.99,
instant payments:
max. EUR 15,000.00
UltmtDbtr Different debtor Optional. Not to be en- Max. 70 characters 35 f., 44, 51
(UltimateDebtor) tered if information has
already been entered on
the PmtInf level
UltmtDbtr-Id-OrgId/PrvtId Identification DK not recommended Miscellaneous 43, 51, 52 ff.
(UltimateDebtorOrganisa-
tion-Id/Private-ID)
CdtrAgt-BIC BIC/SWIFT code of benefi- Optionally IBAN-Only 8 or 11 digits 36, 49 f.
(CreditorAgentBIC) ciary’s bank
Cdtr-Nm Name of the beneficiary Mandatory Max. 70 characters 35 f.
(CreditorName)
Cdtr-PstlAdr-Ctry Country of beneficiary’s Recommended for Country code ISO 3166, 37, 38
(CreditorCountry) address cross-border payments DE for Germany
Cdtr-PstlAdr-AdrLine Address of the beneficiary Provision of address Max. 2 × 70 characters 37, 38
(CreditorAddress) details recommended for
cross-border payments
Cdtr-Id-OrgId/PrvtId Identification DK not recommended Miscellaneous 43
(CreditorOrganisation-Id/Pri-
vate-ID)
CdtrAcct-IBAN IBAN of the beneficiary Mandatory Max. 34 characters
(CreditorIBAN)
UltmtCdtr Different final beneficiary. Optional Max. 70 characters 31 f., 40,
(UltimateCreditorName) Provided for information 47
only.
UltmtCdtr-Id-OrgId/PrvtId Identification DK not recommended Miscellaneous 43, 51, 52 ff.
(UltimateCreditorOrganisa-
tion-Id/Private-ID)
Purp Type of payment (text code), Optional ISO 20022 28
(Purpose) e. g. SALA (Salary) in the “ExternalPurpose-
case of salary payment<?> Code-List”
Ustrd-RmtInf Unstructured remittance Recommended Max. 140 characters 24, 47
(UnstructuredRemittanceInfo) information
Strd-CdtrRefInf- Structured remittance To be used only if the „SCOR“ 28, 47
CdtrRefTp-Cd information for creditor remittance information is
(StructuredCreditor reference not unstructured
Reference-Code)
Strd-CdtrRefInf-Tp-Issr Structured remittance Optional Max. 35 28
information for issuer
21
Strd-CdtrRefInf-CdtrRef Structured remittance To be used only if the Max. 35 characters 28, 47
(StructuredCreditor information Part 2 remittance information is
Reference) CreditorReference: Check not unstructured
digits adequate creditor “RF” + check digits +
reference reference (ISO 11649)
Strictly technical fields or fields that are possible in Germany but not recommended by the banks have not been listed
(e. g. OrgId, other structured remittance information). Details and the specifics on all fields can be found in the DFÜ Agreement
Annex 3 in “Specification of the Data Formats.”
7.1 SEPA instant payments with pain.001.001.09

Version V09 from November 2021 can be used for submitting an instant payment stating ExecutionDateTime (execution date
with time). The new definition of pain.001.001.09 was included in DK Annex 3.5 of the EDI Agreement (valid version – EBICS)
and the differences in element names of V09 compared to the previous version were described.
The main differences between version 09 compared to version 03 are that some fields have been renamed:
• The element <BICOrBEI> from V03 was consistently renamed to <AnyBIC>
• The element <BIC> from V03 was consistently renamed to <BICFI> in V09
22
8 Example of a customer file
GroupHeader Description
<?xml version="1.0" encoding="UTF-8"?>
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.001.001.03" • XML scheme and XSD location
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:iso:std:iso:20022:tech:xsd:
pain.001.001.03 pain.001.001.03.xsd">
    <CstmrCdtTrfInitn>
        <GrpHdr>
            <MsgId>20161118-105506</MsgId> • GroupHeader
            <CreDtTm>2016-11-18T10:55:06</CreDtTm> • MessageID – unique reference of the file
            <NbOfTxs>1</NbOfTxs> • Creation – Date/Time
            <CtrlSum>1234.56</CtrlSum> • Number of transactions
            <InitgPty> • Grand total across all logical files
                <Nm>MEIER PAYMENT MUENCHEN</Nm>
            </InitgPty> • Name initating party e. g. data processing service centre
        </GrpHdr>
PaymentInformation – logical file Description

        <PmtInf>
            <PmtInfId>PAYMENT-20160318-105506</PmtInfId> • PaymentInfID – definitive reference of the logical bulk
            <PmtMtd>TRF</PmtMtd> • Payment method:transfer
            <BtchBookg>true</BtchBookg> • Batch booking – true/false – bulk/single transaction
            <NbOfTxs>1</NbOfTxs> • Number of items
            <CtrlSum>1234.56</CtrlSum> • Total amount in EUR
            <PmtTpInf> • Priority NORM/HIGH (SCT-Preferred)
                <InstrPrty>NORM</InstrPrty>
                <SvcLvl>
                    <Cd>SEPA</Cd> • “ServiceLevel” “SEPA”
                </SvcLvl>
            </PmtTpInf>
            <ReqdExctnDt>2016-11-19</ReqdExctnDt> • Execution date
            <Dbtr>
                <Nm>MEIER CORNELIA MUENCHEN</Nm> • Debtor name (if applicable, with address)
            </Dbtr>
            <DbtrAcct>
                <Id>
                    <IBAN>DE67700202700064535072</IBAN> • Debtor IBAN
                </Id>
            </DbtrAcct>
            <DbtrAgt>
                <FinInstnId>
                    <BIC>HYVEDEMMXXX</BIC> • BIC of the originator bank
                </FinInstnId>
            </DbtrAgt>
            <UltmtDbtr>
                <Nm>MEIER GEHALTSABTEILUNG</Nm> • Ultimate debtor name
            </UltmtDbtr>
            <ChrgBr>SLEV</ChrgBr> • SLEV = Share
CreditTransferTransactionInformation – individual transaction Description

            <CdtTrfTxInf>
                <PmtId>
                    <EndToEndId>OriginatorID1234 • E nd2End-Id – Payment reference from ordering debtor’s
                                </EndToEndId> perspective
                </PmtId>
                <Amt>
                    <InstdAmt Ccy="EUR">1234.56</InstdAmt> • Amount in EUR
                </Amt>
                <CdtrAgt>
                    <FinInstnId>
                        <BIC>SPUEDE2UXXX</BIC> • Creditor – BIC of beneficiary bank
                    </FinInstnId>
                </CdtrAgt>
                <Cdtr>
                    <Nm>Creditor Name</Nm> • Creditor name
                </Cdtr>
                <CdtrAcct>
                    <Id>
                        <IBAN>DE21500500009876543210</IBAN> • Creditor IBAN
                    </Id>
                </CdtrAcct>
                <Purp>
                    <Cd>PENS</Cd> • P urpose – text code for payment
                </Purp> see ISO 20022 external code list
                <RmtInf>
                    <Ustrd>Unstructured Remittance Information</Ustrd> • Remittance Information 140 characteres
                </RmtInf>
            </CdtTrfTxInf>
        </PmtInf>
    </CstmrCdtTrfInitn>
</Document>
23
9 SEPA Direct Debit (SDD)
Basic characteristics
• SEPA Direct Debit CORE (SDD CORE)
• Similar to former Collection Authorisation Procedure (Einzugsermächtigung)
• SEPA Direct Debit Business-to-Business (SDD B2B)
• Similar to former Debit Order Procedure (Abbuchungsauftrag)
• For the purpose of validation, the mandate must also on hand at the debtor’s bank
• Provision of the Creditor Identifier (assigned by the German Federal Bank)
• Provision of mandate information (mandate-ID and mandate signature date)
• Provision of process relevant information (submission sequence, due date with respective presentation periods)
• Use of IBAN/BIC
• Remittance information limited to 140 characters
• Payment purposes (PurposeCodes) are possible as an option
• Use of on-behalf/ultimate possible
• Referencing options
• Cross-border use in the SEPA zone
Important functional XML fields for SEPA Direct Debit

Field names Description Entries Content of the More
pain.008.001.02 DFÜ Agreement Annex 3 – Version 3.5 paper-based details
mandate on page
GrpHdr GroupHeader Sender data 1 × per logical file 14 f.
MsgId Submitter reference num- Mandatory (unique) Max. 35 45 f. ,
(Message-Id) ber for each file characters 48 ff.
CreDtTm Date/time file was created Mandatory ISO-Date
(CreationDateTime)
NbOfTxs Total number of individual Mandatory Unlimited
(NumberOfTransactions) transactions
CtrlSum Amount submitted in EUR Mandatory Unlimited
(ControlSum) for cross-checking
InitgPty-Nm Name of the initiater/sub- Mandatory Max. 70 33 f.
(InitiatingPartyName) mitter (may be different characters
from the creditor)
InitgPty-Nm-Id-OrgId/PrvtId Identification DK not recommended Miscellaneous 39
(InitiatingPartyOrganisa- Only to be filled out
tion-Id/Private-ID) if submitted by data
processing service
centres or network
operators.
PmtInf PaymentInformation Payment recipient data Permitted in any 14 f.
frequency, max 100
recommended.
PmtInfId Bulk reference Mandatory Max. 35 45 f
(PaymentInformation-ID) characters 48 ff.
PmtMtd Payment method: direct Mandatory “DD”
(PaymentMethod) debit
BtchBookg Presenter/creditor booking Optional, adminis- “rue” – bulk 53 f.
(BatchBooking) bulk/single transaction trated in the master posting
data system “false” –single
posting
NbOfTxs Total number of single Mandatory Unlimited
(NumberOfTransactions transactions
CtrlSum Cross-checking logical Mandatory Unlimited
(ControlSum) bulk amount in EUR
SvcLvl-Cd Service scheme Mandatory<?> “SEPA” 47
(ServiceLevelCode)
24
mandate on page
LclInstrm-Cd Direct Debit CORE or Mandatory “CORE” or “B2B” 43,
(LocalInstrumentCode) Direct Debit B2B (cannot be mixed 47
within GrpHdr)
(see footnote 6)
SeqTp Sequence: first, recurrent, Mandatory (“FRST”), “RCUR”, Mandatory 43 ff.
(SequenceType) OneOff or final direct debit (see footnote 6) “OOFF” or “FNAL” (recurring or
one-time)
CtgyPurp Bulk category purpose Optional 30,
(CategoryPurpose) (see footnote 6) 47
ReqdColltnDt Direct debit due date Mandatory ISO Date 43
(RequestedCollectionDate) (date to be posted to the
debtor’s account)
Cdtr-Nm Name of the creditor, may Mandatory Max. 70 Mandatory 31 f.
(CreditorName) have been replaced with characters
account holder name by
the bank
Cdtr-PstlAdr-Ctry Country of creditor’s Optional Country code Mandatory 33
(CreditorCountry) address ISO 3166,
DE for Germany
Cdtr-PstlAdr-AdrLine Address of the creditor, Optional Max. 2 × 70 Mandatory 33
(CreditorAddress) may have been replaced characters
with account holder name
by the bank
CdtrAcct-IBAN IBAN of the creditor Mandatory Max. 34 35 ff.,
(CreditorIBAN) characters 45 f.
CdtrAcct-Ccy Account currency: has to Optional “EUR”
(CreditorAccountCurrency) be EUR
CdtrAgt-BIC BIC/SWIFT code of the Optionally IBAN 8 or 11 digits 37,
(CreditorBIC) creditor 45 f.
CtrAgt-Othr-Id IBAN-Only ID Only if using IB- “NOTPROVIDED” 36
(CreditorAgentId) AN-Only
UltmtCdtr Creditor that is not Optional Max. 70 charac- Optional 31 f.,
(UltimateCreditor) identical with the account ters 40,
holder. For information 47
only.
UltmtCdtr-Id-OrgId-Othr Ultimate creditor IBAN Optional, only if the Max. 34 charac- 35 ff.,
(UltimateCreditorIBAN) product is “Ultimate ters 40,
ordering party” 45 f.
UltmtCdtr-Id-OrgId/PrvtId Identification DK not recommend- Miscellaneous 39,
(UltimateCreditorOrganisa- ed 47,
tion-Id/Private-ID) 48 ff.
ChrgBr Charging always shared Recommended “SLEV” 47
(ChargeBearer)
CdtrSchmeId-Id-PrvtId-Oth- Creditor identification. Mandatory, either on Max. 35 Mandatory 38,
rId-Id Clear identification char- the PmtInf level or characters 41 ff.,
(CreditorIdentification) acteristic of the creditor on the transaction 47
(per legal entity) level – always the
same
DbtTrf DirectDebit Transactions informa- Permitted in any 14 f.
TxInf TransactionInformation tion frequency, max
100,000 recom-
mended.
InstrId Technical reference be- Optional, if complet- Max. 35 45 f.,
(Instruction-ID) tween submitter and bank ed: unique characters 48 ff.
EndToEndId Reference, to be passed Mandatory (if used, Max. 35 45 f.,
(End2End-ID) on to the debtor otherwise: “NOT- characters 48 ff.
PROVIDED”)
InstdAmt Amount and currency Mandatory EUR permitted
(InstructedAmount) code only, max. EUR
999,999,999.99
25
mandate on page
MndtId Unique mandate reference Mandatory Max. 35 Can be sup- 45 f. ,
(MandateID) characters plied later 48 ff.
DtOfSgntr Date, on which the man- Mandatory ISO date Mandate, in
(DateOfSignature) date was signed paper-man-
dates also
location
where it was
signed and
signature
AmdmntInd Indicates whether the Mandatory Amendment = 43 ff.
(AmendmentIndicator) mandate was amended “true” Standard =
“false”
OrgnlMndtId Reference of the original Only if the mandate Max. 35 characters 43 ff.,
(OriginalMandateID) mandate if the mandate has changed 45 f.,
reference (MndtId) has (AmdmntInd = “true”) 48 ff.
changed
OrgnlCdtrSchmeId-Nm Original creditor name if Only in the event of a Max. 70 characters 43 ff.
(OriginalCreditorName) the creditor of the payment mandate change
has changed (AmdmntInd = true)
Orgnl- Original creditor iden- Only in the event of a Max. 35 characters 38,
CdtrSchmeId-Id-PrvtId-Oth- tification if the creditor mandate change 43 ff.
rId-Id identification has changed (AmdmntInd = true) 48 ff.
(OriginalCreditorIdentification) (CdtrSchmeId)
OrgnlDbtrAcct-IBAN Original IBAN of the debtor Only in the event of a Max. 34 characters 35 ff.,
(OriginalDebtorIBAN) if the IBAN has changed mandate change 43 ff.,
(AmdmntInd = true), 45 ff.
not together with
SMNDA or
OrgnlDbtr-BIC
OrgnlDbtrAcct-Id-Othr-Id Original debtor IBAN and/or Only in the event of a Identifier “SMNDA” 43 ff.,
(OriginalDebtorAccount-Oth- debtor bank has changed mandate change (Same Mandate 44
erId) (AmdmntInd = true), New Debtor Agent)
not together with
OrgnlDbtrAcct-IBAN
or OrgnlDbtr-BIC
OrgnlDbtrAgt-FinInstnId-BIC Original debtor BIC if BIC Only in the event of 8 or 11 digits 45 ff.
(OriginalDebtorAgent-BIC) has changed but IBAN has a mandate change
remained the same (AmdmntInd = true),
not together with
OrgnlDbtrAcct-IBAN
or SMNDA
ElctrncSgntr Electronic mandate eMan- Optional. Not for pa- Max. 1.025 charac-
(ElectronicSignature) date – electronic signature per-based mandates ters; relevant with
eMandate at future
date
CdtrSchmeId-Id-PrvtId-Oth- Creditor identification. Mandatory, either on Max. 35 characters 38,
rId-Id Unique identification prop- the PmtInf level or on 43 ff.,
(CreditorIdentification) erty of the creditor of the the transaction level, 47
payment (per legal entity) always the same.
UltmtCdtr Name of a different Optional. Nor if Max. 70 characters 31 f.,
(UltimateCreditorName) creditor already entered in the 40,
PmtInf level 47
UltmtCdtr-Id-OrgId/PrvtId Identification DK not recommended Miscellaneous 35,
(UltimateCreditorOrganisa- 40,
DbtrAgt-BIC BIC/SWIFT code of the Optional 8 or 11 digits Optional 36,
(DebtorAgentBIC) debtor bank Additionally at 45 f.
UniCredit:
NOTPROVIDED”,
“NOTAVAIL”
26
mandate on page
DbtrAgt-Othr-Id IBAN-Only ID Optional when using “NOTPROVIDED” 36
(DebtorAgentId) IBAN-Only
Dbtr-Nm Name of the debtor Mandatory<?> Max. 70 31 f.
(DebtorName) characters
Dbtr-PstlAdr-Ctry Country of debtor’s Optional: Rec- Country code Optional 33
(DebtorCountry) address ommended for ISO 3166, DE for
cross-border direct Germany
debits
Dbtr-PstlAdr-AdrLine Address of the debtor Optional: Max. 2 × 70 Optional 33
(DebtorAddress) Provision of debtor’s characters
address recommend-
ed for cross-border
payments
Mandatory:
for direct debits
outside the EU
Dbtr-Id-OrgId/PrvtId Identification DK not recommend- Miscellaneous 39,
(DebtorOrganisation-Id/Pri- ed 48 ff.
vate-ID)
DbtrAcct-IBAN IBAN of the debtor Mandatory Max. 34 Mandatory 35 ff.,
(DebtorIBAN) characters 45 f.
UltmtDbtr Name of the different Optional Max. 70 Optional 31 f.,
(UltimateDebtor) debtor. For information characters 40,
only. 47
UltmtDbtr-Id-OrgId/PrvtId Identification DK not recommend- Miscellaneous 39,
(UltimateDebtorOrganisa- ed 47
Purp Type of payment (text Optional ISO 20022 28
(Purpose) code). Not all codes are “ExternalPurpose-
provided in account state- Code-List”
ment MT940/942<?>
Ustrd-RmtInf Unstructured remittance Recommended Max. 140 Optional 24,
(Unstructured information characters (contract 47
RemittanceInfo) number and
description)
Strd-CdtrRefInf-CdtrRefTp-Cd Structured remittance DK not recommend- “SCOR” 25,
(StructuredCreditor information ed 47
Reference-Code)
Strd-CdtrRefInf-Cdtr Structured remittance DK not recommend- Max. 35 25,
Ref(StructuredCreditor information Part 2 ed characters 47
Reference)
27
10 Usual payment information
10.1 Remittance information
10.1.1 Unstructured remittance information <RmtInf><Ustrd>
• 140 characters are provided for the remittance information in SEPA.
• In addition to the unstructured remittance information, however, a structured purpose <Purp> and specifics about the
parties involved (address and identification numbers) as well as the End-to-End refence with 35 characters can be added in
SEPA.
<RmtInf>
12345678901234567890123456789012345678901234567890123456789012345678901
    <Ustrd>
234567890123456789012345678901234567890123456789012345678901234567890
    </Ustrd>
</RmtInf>
10.1.2 Structuring through code words defined by EACT in unstructured

remittance information
The ordering party may include references, e. g. invoice number of the transaction, in the remittance information, so that the
beneficiary can easily allocate the incoming payment and clear open items.
In order for this to take place automatically in the ideal case, the European Association of Corporate Treasurers (EACT, eact.eu)
has defined code words and format rules. The complete list of code words and format rules can be seen on the EACT website at
eact.eu/Core/Documents/Wordpress_Old/docs/EACT_Standard_for_Remittance_Info.pdf through the Working Group 8 (SEPA
Documents).
Examples of use in accordance with the EACT Standard:
<RmtInf>
    <Ustrd>/RFB/123456789012345678901</Ustrd>
</RmtInf>
(RFB = Reference for Beneficiary)
The payment transaction is related to the business transaction with the reference 123456789012345678901.
<RmtInf>
    <Ustrd>/RFS/RF98123456789012345678901</Ustrd>
</RmtInf>
(RFS = Reference secured with check digits)
The payment transaction also refers to the business transaction with the reference 123456789012345678901, with the
reference being indicated this time as a reference secured with check digits in accordance with ISO 11649, see also the sections
on structured remittance information on the next page.
28
<RmtInf>
/CNR/876543/DOC/894584334/DOC/894584335/ 54.67/ 20141128</Ustrd>
    <Ustrd>
</RmtInf>
(CNR = Customer Number, DOC = Document reference)
/CNR/876543/ indicates the customer number 876543

/DOC/894584334 refers to the invoice number 894584334
/DOC/894584335/ 54.67/ 20141128 is a so-called compound element containing additional data, separated by slash and
space, in this case the invoice number 894584335 dated 28/11/2014, with only the amount of 54.67 being contained.
10.1.3 Employee savings’ plans (VL benefits)

• In the case of employee savings plans (VL benefits), the “XXJ/contract number” is presented here, whereby XX is replaced
either by 00 or by the percentage rate of the savings bonus, and the letter J represents the last figure of the benefit year.
The name of the VL benefit recipient can be saved in the “Ultimate Creditor” data element, if required. CBFF (Capital Building
Fringe Fortune) can also be set as the PurposeCode. The purpose code CBFR can be applied for capital building fringe fortune
for retirement.
<Purp>
    <Cd>CBFF</Cd>
</Purp>
<RmtInf>
    <Ustrd>003/ABC123456</Ustrd>
</RmtInf>
10.1.4 Structured RemittanceInformation <RmtInf> <Strd>

Structured creditor reference <CdtrRefInf>
• Forms with check digits adequate remittance information are also available for SEPA, just like they are in the form of BZÜ-
receipts for domestic payments. In SEPA they are called creditor references in compliance with ISO 11649, starting with
identifiers “RF” followed by 21 alpha-numerical digits. Modulus 97 is used to compute the creditor reference.
• In SEPA, structured remittance information are permitted only with code word SCOR.
• If the check digit is not correct, the reference is transferred to an unstructured remittance information.
• The structure is principally not provided in the paper-based and electronic account statement MT940; all it reflects is the
content without tags, e. g. “SCOR RF98123456789012345678901.” In the new camt.05x, the structure will be forwarded.
• The purpose code IVPT (InvoicePayment) can be allocated for structured remittance information bearing a check digit
adequate reference number.
<RmtInf>
    <Strd>
        <CdtrRefInf>
            <Tp>
                <CdOrPrtry>
                    <Cd>SCOR</Cd>
                </CdOrPrtry>
            </Tp>
            <Ref>RF98123456789
012345678901</Ref>
        </CdtrRefInf>
    </Strd>
</RmtInf>
29
10.1.5 Outlook 2021/2022
Structured Remittance Information
The new ISO Version 2019 offers additional structured data. The previous unstructured remittance information will be extended
by the structured remittance information, which can include up to 9.000 characters when fully filled and contains a wide range
of information on payments. From 2022 on the structured remittance information will be offered by UniCredit.
In the future, the following elements will be available in the structured remittance information:
• Referred Document Info (based on invoices or contracts)
• Referred Document Amount (Amout given in the referred document)
• Tax Remittance (Tax information i.e. tax number)
• Creditor Reference Info (structured reference number)
• Invoicer
• Invoicee
• Garnishment Remittance
• Additional Remittance (3 x 140 characters)
Structured Remittance
Invoicer
Referred Document Info Referred Document Tax Remittance Name Adr Id
Amount
Type Date Number TaxCreditor
Remittance Adm Zone
Amount Due Invoicee
Tax-Id Regist-Id Ref Number
Name Adr Id
Amount Discount
Line Details
Debtor Method
Garnishment Remittance
Id-Type/Number/Date Amount Credit Note Tax-Id Regist-Id
Tax Amount
Type Ref Date
Amount Due
Amount Credit Tax Ultimate Debtor Date
Garnishee Amount
Amount Credit Note Tax-Id Regist-Id Sequence Name
Adjustmend Amount Adr
Insurance
Amount Discount Garnish Admin
Remitted Amount Record
Name Adr Employee
Amount Credit Tax Type Status Rate Category
Forms Period Certification Tax Amount

Adjustmend Amount
Creditor Reference Info Tax Amount Additl Info Addtional Remittance
Remitted Amount
3 x 140
Type Number Period Amount
<Strd>
    <RfrdDocInf> Referred Document
        <Tp>
            <CdOrPrtry>
                <Cd>CINV</Cd> Document type (here Commercial invoice)
            </CdOrPrtry>
        </Tp>
        <Nb>3521264364</Nb> Document number
    </RfrdDocInf>
    <CdtrRefInf> Creditor Reference
        <Tp>
            <CdOrPrtry>
                <Cd>SCOR</Cd>
            </CdOrPrtry>
            <Issr>BEuthority</Issr>
        </Tp>
            <Ref>RF12345678901234567890123456</Ref>
30
<Strd>
    <RfrdDocInf>
        <Tp>
            <CdOrPrtry>
                <Cd>CINV</Cd>
            </CdOrPrtry>
        </Tp>
        <Nb>369258147</Nb> Invoice Number
        <RltdDt>2019-04-15</RltdDt> Invoice date
    <RfrdDocAmt>
        <DuePyblAmt Ccy=“EUR“>143567.54</DuePyblAmt> Invoice Amount
        <TaxAmt>
            <Tp>
                <Cd>STAT</Cd>
            <Tp>
        <Amt Ccy=“EUR“>24649.46</Amt> State tax amount
    </TaxAmt>
    <Amt Ccy=“EUR“>147896.76</RmtdAmt>
<RfrdDocAmt>
<Strd>
        <Nb>987654321</Nb>
    <RfrdDocAmt>
        <DuePyblAmt Ccy=“EUR“>247.34</DuePyblAmt>
        <DscntApldAmt>
            <Tp>
                <Cd>TMDS</Cd>
            </Tp>
            <Amt Ccy=“EUR“>24.73</Amt>
        <//DscntApldAmt>
        <TaxAmt>
            <Tp>
                <Cd>STAT</Cd>
            </Tp>
            <Amt Ccy=“EUR“>44.46</Amt>
        <RmtdAmt Ccy=“EUR“>267.13</RmtdAmt> Referred Amount
    </RfrdDocAmt>
    <AddtlRmtInf>Advise Mr Mustermann</AddtlRmtInf> Additional Information
...
...
<Strd>
        <Nb>987654321</Nb>
    <Invcr> Invoicer
        <Nm>Mustermann GmbH</Nm>
        <Id>
            <Orgld>
                <Othr>
                    <Id>FR1234567890</Id>
                </Othr>
            </Orgld>
        </Id>
    </Invcr>
    <Invcee> Invoicee
        <Nm>Maier GmbH</Nm>
        <Id>
            <Orgld>
                <AnyBIC>BANKDEFFXXX</AnyBIC>
            </Orgld>
        </Id>
    </Invcee>
...
31
10.1.6 Extended Remittance Info
The Extended Remittance Information (ERI) option introduced by the EPC in the 2019 Rulebook is currently not supported
by UniCredit. The ERI offers structured remittance information with up to 999 × 280 characters. Since the XML format is
planned to be introduced for urgent and SWIFT payment transactions in 2021, resulting in a different structure of the structured
remittance information with up to 9,000 characters, the introduction of ERI should be put off for the time being.
10.2 Purpose Code

• The structured payment purpose information for each payment, e. g. donation or salary, is reflected by the purpose code in SEPA.
• The purpose code is principally sent to the recipient bank and its end recipient
• It may result in different business transaction codes (BTC) in the electronic account statement
• All payment purposes are listed in iso20022.org/external_code_list.page under tab “11-Purpose”.
<CdtTrfTxInf>
…
    <Purp>
        <Cd>PENS</Cd>
    </Purp>
</CdtTrfTxInf>
Purpose Code statement Definition Special BTC at the electronic statement of accounts
ACCT Cash Pooling
AGRT Agriculture
AIRB Air transportation
BECH Benefits for children
BENE Unemployment benefits BTC Credit 156, BTC Instant Credit Transfer 163
BONU Bonus payment BTC Credit 153, BTC Instant Credit Transfer 157
BUSB Bus transportation
CASH Cash management
CBFF Savings benefits BTC Credit 154, BTC Instant Credit Transfer 161
CBFR Capital building fringe fortune for retirement BTC Credit 155, BTC Instant Credit Transfer 162
CBLK Card Payment Bulk
CCRD Credit Card Payment
CDBL Credit card billing statement
CDCB Card payment POS cashback BTC Credit 198, Debit 106
CDCD ATM cash withdrawal BTC Debit 106
CDCS ATM cash withdrawal with surcharging BTC Debit 106
CDDP Card payment POS maximum authorisation BTC Credit 198, Debit 106
CDQC Quasi-cash card payment, e. g. coupons
CFEE Cancellation
CGDD Card-generated direct debit (ELV) BTC Debit 107
CHAR Charity – donation BTC Debit 119, Credit 169, BTC Instant Credit Transfer 165
CMDT Commodities
COMC Commercial payment
COMM Commission payment
CORT Trade Settlement Payment
COST General costs
CSLP Contributions to social security
DNTS Dental services
ECPG E-commerce payment with guarantee (PayDirekt) BTC Debit 084
32
ECPR E-commerce payment return BTC Debit 116, Credit 155
ECPU E-commerce payment without guarantee
ELEC Electric bill
ENRG Energy
EPAY E-Commerce Payment
ESTX Estate tax
ETUP E-purse top up BTC Debit 106
FEES Fees
FOCL Fee collection e-purse BTC Debit 106
GASB Gas bill
GDDS Goods purchases/sale
GOVT Payment to/from the government BTC Credit 156, BTC Instant Credit Transfer 163
HLTC Healthcare services
HLTI Health insurance
IDCP Card payment POS BTC Credit 198, Debit 106
INPC Automotive insurance
INSM Instalment payment plan
INSU Insurance
INTC Intra-company transfer
INTE Interest
INTX Income tax
IVPT Reference in acc. with ISO 11649 BTC Credit 167, BTC Instant Credit Transfer 164
LBRI Professional liability insurance
LICF Licensing fees
LIFI Life insurance
LOAN Loan payment
LOAR Loan Repayment
MDCS Medical services
MP2B Mobile Payment at the POS
MP2P Mobile P2P Payment
MTUP Mobile top up BTC Debit 106
NWCM Network communications
OTHR Other
PAYR Payroll disbursement BTC Credit 153, BTC Instant Credit Transfer 157
PENS Pension and retirement benefits disbursement BTC Credit 153, BTC Instant Credit Transfer 157
PHON Telephone
PPTI Property/home owner’s insurance
RINP Recurring transfer order/Standing order BTC Credit 152
RLWY Railway transportation
SALA Salary disbursement BTC Credit 153, BTC Instant Credit Transfer 157
SAVG Savings payment
SCVE General services
SPSP Salary or pension payment for more than 1 month or BTC Credit 153, BTC Instant Credit Transfer 157
delayed payment
SSBE Social security benefits BTC Credits 156, BTC Instant Credit Transfer 163
STDY Studies and education
SUPP Supplier payment
TAXS Tax payment
TELI According to telephone order
33
TRAD Trade transaction
VATX Value added tax
WEBI According to online order placed
WTER Water
Please find further information in our brochures “Reporting” and “Business transaction and return codes”, which you can obtain
from your Cash Management & eBanking Specialist upon request.
10.3 Category Purpose

• The category purpose is an instruction the submitter gives to the paying bank
• The orders/files are subject to special processing, e. g. subject to prioritization or special terms
• The above applies to a file or each payment
• A bilateral usage agreement with the bank is required
• Currently, UniCredit only uses “SALA” (same day salary payments) on the bulk level.
• Card payments in SEPA Cards Clearing are identified by the category purpose “IDCP” (guaranteed card payment) or “CBLK”
(card bulk clearing) or “FCOL” (fee collection).
• PayDirekt payments are assigned the category purpose “EPAY”
<PmtInfId>
…
    <PmtTpInf>
    …
        <CtgyPurp>
            <Cd>SALA</Cd>
        </CtgyPurp>
    </PmtTpInf>
…
</PmtInfId>
10.4 Special service for salary payments

Many companies want to ensure their employees receive their salary payments on time. We offer a special solution so that
you do not have to split the salary data files yourself and separate them by recipient at UniCredit or third-party banks within
SEPA. If the files are submitted after 12.15 pm and contain the Category Purpose = “SALA” (at PaymentInformation level) in
addition to the Instructed Priority = “HIGH”, the bulk is parked and not executed until the next day – recipients at third-party
banks and UniCredit recipients thus receive the payments on the same day.
34
10.5 The five parties to a transaction message
The presenter and the recipient appear on different levels of a SEPA order or file submission. Fields Ultimate can be used to
enter an additional different presenter and payment recipient.
Example of a SEPA Credit Transfer
GroupHeader
Initiating Party (submitter) Name (70 digits)
Address (country code plus 2 × 70 digits)*
PaymentInformation – bulk level Organisation identification

Debtor (debtor) Person identification
IBAN (debtor) * The provision of an address for the initiating
party and for the Ultimates is not possible
BIC (debtor)
UltimateDebtor
Transaction
Creditor (beneficiary/recipient)
IBAN (beneficiary/recipient)
BIC (beneficiary/recipient)
Required information
UltimateCreditor Optional
35
Example International Credit Transfer
GroupHeader
Initiating Party (Submitter) Name (140 Stellen)
Structured Addresse*
PaymentInformation – Dateiebene Organisationsidentifikation

Debtor (Ordering party) Personenidentifikation
IBAN (Ordering party)
Other-Id *Structured address see Chapter 10.7.1
Debtor Agent (PSD ordering party)
BICFI Other-Id LEI Branch Id
BIC (Ordering party)
UltimateDebtor
Charges Account Agent
Transaction
Creditor (Beneficiary)
IBAN (Ordering party) Other-Id
Creditor Agent (PSD of Beneficiary)
BICFI Other-Id LEI Branch Id
BIC (Ordering party)
UltimateCreditor
Invoicer
Garnishee
Intermediary1 Agent
Intermediary2 Agent
Intermediary3 Agent
Mandatory
Optional
36
Example of a SEPA Direct Debit
GroupHeader
Initiating Party (submitter) Name (70 digits)
Address (country code plus 2× 70 digits)*
PaymentInformation – bulk level Organisation number**

Creditor Person identification number**
Gläubiger-ID (creditor) * A
ddress for the initiating party and for the Ultimates not
possible; address mandatory for payments outside the EU
** OrgId & PrvtId not possible for the creditor
IBAN (creditor)
IBAN (ceditor)
UltimateCreditor
Transaction
Debtor
IBAN (debtor)
BIC (debtor)
Required information
UltimateDebtor Optional
10.6 Name, address

• Five possible parties are involved in a transaction message (debtor, creditor, initiating party, ultimate creditor and ultimate
debtor).
• The respective party name <Nm> is always provided using up to 70 characters.
• As an option, it is also possible to provide addresses <PstlAdr>. The country code <Ctry> plus two times 70 characters from
the unstructured address <AdrLine> must be used.
• The originator’s name and address (for cross-border payments) must be provided correctly pursuant to Regulation (EU)
2015/847 on Transfer of Funds (effective 26 June 2017). UniCredit automatically enters the master account data.
• In addition to the name, the address of the recipient (beneficiary for SCT or debtor for SDD) should always be provided at
least for cross-border payments in order to avoid any inquiries, for example as part of checks against sanctions lists.
• The debtor’s address must be indicated when submitting direct debits outside the EU/EEA (Regulation (EU) 2015/847 on
Transfer of Funds). At present, this concerns the following countries: Norway (NO), Iceand (IS), Liechtenstein (LI), Vatican City
(VA), Andorra (AD), Switzerland (CH), Monaco (MC), San Marino (SM), Jersey (JE), Guernsey (GG), Isle of Man (IM), St. Pierre
and Miquelon (PM) as well as Great Britain (GB/GI).
...
<Nm>ABC Handels GmbH</Nm>
<PstlAdr>
    <Ctry>DE</Ctry>
    <AdrLine>Zentrale1, Dorfstrasse 23/2</AdrLine>
    <AdrLine>80995 Muenchen / Bogenhausen</AdrLine>
</PstlAdr>
...
• Outlook for 2021: In the future, the structured address fields such as place <TwnNm> and street <StrNm> will become
mandatory in urgent and international payment transactions. The structured address fields will also become mandatory for
the ultimate parties.
37
10.6.1 Outlook structured address
Outlook: In the case of urgent payments (from 2022) and international payments (from 2022), the structured address fields
such as town <TwnNm> and street <StrNm> must be filled in the future, as well as the country <Ctry>. The structured address
fields for the ultimates are also mandatory.
Unstructured address line fields can still be used temporarily until 2025. Structured addresses for payments will be required
from 2025 at the latest.
For the previous unstructured fields, it will be necessary to transfer them to the structured address fields in the future, especially
in the case of international addresses whose structure differs from the European structure. For example, the house number is
in front of the street, not after the street name as in Europe.
For this reason, it is advisable to gradually adapt and structure all customer inventories (accounts receivable/accounts payable)
at an early stage in order to avoid incorrect transfer of the address fields.
The following elements will be available in the structured address in future (max. 699 characters):
Name XML-Tag Occ. Format Description

Department <Dept> [0..1] Max70Text Department
SubDepartment <SubDept> [0..1] Max70Text Sub Department
StreetName <StrtNm> [0..1] Max70Text Street name
BuildingNumber <BldgNb> [0..1] Max16Text Building Number
BuildingName <BldgNm> [0..1] Max35Text Building Name
Floor <Flr> [0..1] Max70Text Floor
PostBox <PstBx> [0..1] Max16Text Post Box
Room <Room> [0..1] Max70Text Room
PostCode <PstCd> [0..1] Max16Text Post Code
TownName <TwnNm> [1..1] Max35Text Town Name
TownLocationName <TwnLctnNm> [0..1] Max35Text Specific place name within a
town/city
DistrictName <DstrctNm> [0..1] Max35Text Subdivision within a region
CountrySubDivision <CtrySubDvsn> [0..1] Max35Text Region
Country <Ctry> [1..1] Max2Text Country code consisting of 2 capital
letters, e.g. B. DE for Germany
Unstructured address – Old ISO-Version
...
<PstlAdr>
    <AdrLine>Zentrale1, Dorfstrasse 23/2</AdrLine>
    <AdrLine>80995 Muenchen / Bogenhausen</AdrLine>
</PstlAdr>
...
Structured addres – New ISO-Version
...
<PstlAdr>
    <Dept>Zentrale1</Dept>
    <StrtNm>Dorfstrasse</StrtNm>
    <BldgNb>23</BldgNb>
    <Flr>2</Flr>
    <PstCd>80995</PstCd>
    <TwnNm>Muenchen</TwnNm>
    <TwnLctnNm>Bogenhausen</TwnLctnNm>
</PstlAdr>
...
38
10.7 IBAN, BIC
10.7.1 IBAN
• The International Bank Account Number – IBAN is the definitive identification criteria for beneficiaries and debtors of
payments. In the SEPA payment zone, the IBAN will completely supersede the domestic account number for SEPA orders.
<Id>
    <IBAN>DE40700202700012345678</IBAN>
</Id>
• Its structure is defined by ISO 13616-1:2007. The IBAN begins with two letters, which identify the country.
Two check digits follow. These two check digits are calculated pursuant to ISO 7064 in modulus 97-10 across the entire
IBAN. The next numbers identify a bank/account. Depending on the country, this bank/account identification has a different
structure and a distinct number of digits. Consequently, the IBAN may span 15 to 31 digits and may not only contain the
numeric values, but also alphanumerical values besides the country code.
• In Germany, the first 8 digits after the two check digits reflect the bank code (German Bankleitzahl), while the following
10 digits identify the numeric account number, so that the total length of the German IBAN is 22 digits. Many banks have
the capability to verify the correctness of the account number based on the last digit of the account number and they use
this final digit as a check digit. The required calculation modulus each individual bank requires can be determined from the
Routing Code Directory of the German Federal Bank based on the bank code.
Bank routing code: 8 digits

DE: Germany
DE40700202700012345678
Check digits: 2 digits Account number: 10 digits
• A simple determination of the check digits based on the bank code and account number does frequently result in the misrouting
of payments in Germany, since the following special circumstances have to be taken into account:
• Some banking institutions fail to complete the IBAN account number field with zeros from left to right if the account
number has less than 10 digits, but insert the zeros after the account number
• In particular after consolidations and mergers of bank branches, numerous customers continue to use their old bank
codes, although they have already been provided with a new bank code along with their IBAN
• For this reason, an IBAN calculation should always be conducted by the bank that manages the account, or in Germany by
the German company Bank-Verlag, or by processes that take specific institutional particularities into account as published
by the Bundesbank
Examples of specific institutional particularities when calculating the IBAN

• The IBAN calculation converts charity and pseudo accounts into genuine account numbers, e. g.: Bank code 70150000 and
account 70000 is converted in IBAN into account 18180018, in other words DE64 7015 0000 0018 1800 18
• Accounts are filled up with zeros to 10 digits at the rear instead of at the front, e. g.: Bank code 26580070 and account
7325022 becomes IBAN DE32 2658 0070 0732 5022 00
• The bank code is exchanged, e. g.: Bank code 30020500 and account 40033086 is converted in IBAN into account
DE02 5002 0200 0040 0330 86
39
IBAN examples for other countries
The document swift.com/sites/default/files/resources/iban_registry.pdf lists all nationally agreed IBAN formats, with an
extract included here:
Austria (20-digit): LLPPBBBBBKKKKKKKKKKK

Example: AT611904300234573201
LL Country identifier: AT Letters
PP Check digits 2-digit Numbers
BBB… Austrian bank code 5-digit Numbersh
KKK… Account number 11-digit Numbers
Switzerland (21-digit): LLPPBBBBBKKKKKKKKKKKK

Example: CH9300762011623852957
LL Country identifier: CH Letters
BBB… Swiss bank code 5-digit Numbers
Italy (27-digit): LLPPNBBBBBCCCCCKKKKKKKKKKKK

Example: IT60X0542811101000000123456
LL Country identifier: IT Letters
N Control Internal Number (CIN) 1-digit Alpha-numeric
BBB… Associazione Bancaria Italiana (ABI) 5-digit Numbers
CCC… Codice di Avviamento Bancario (CAB) 5-digit Numbers
10.7.2 IBAN-Only
Since 1 February 2016, statement of the BIC has no longer been mandatory within the SEPA area.
SCT pain.001.001.03 SDD pain.008.001.02

… …
<DbtrAgt> <CdtrAgt>
    <FinInstnId>     <FinInstnId>
        <Othr>         <Othr>
            <Id>NOTPROVIDED</Id>             <Id>NOTPROVIDED</Id>
        </Othr>         </Othr>
    </FinInstnId>     </FinInstnId>
</DbtrAgt> </CdtrAgt>
… …
<CdtrAgt> CdtrAgt kann komplett entfallen <DbtrAgt>
    <FinInstnId>     <FinInstnId>
        <BIC>SPUCDC2UXX</BIC>         <Othr>
    </FinInstnId>             <Id>NOTPROVIDED</Id>
</CdtrAgt>         </Othr>
    </FinInstnId>
</DbtrAgt>
…
In the case of the Payment Status Report pain.002, IBAN-Only is taken into consideration as follows: In the case of credit
transfers, the DebtorAgent contains UniCredit’s BIC, and the CreditorAgent remains as it was delivered. In the case of direct
debits, this applies analogously for CreditorAgent and DebtorAgent.
40
10.7.3 Payments without IBAN
For non SEPA payments it is possible to submit them without IBAN. The IBAN is mandatory for SEPA and urgent payments.
However, an identification other than the IBAN may only be used if no IBAN exists or is known. If this is the case, another
identification characteristic of the account must be provided. This can be done either with the proxy <Prxy> as substitute of the
account or with another identification of the account <Othr><Id>. A Proxy (e.g. mobile phone number, e-Mail address etc.) can
only be used if this has been agreed with all participating banks. Currently there is no usable directory for proxies in Germany.
<CdtrAcct>
    <Id>
        <Othr><Id>123456789</Id></Othr>
    </Id>
</CdtrAcct>
10.7.4 Bank Identifier Code (BIC)

The Bank Identifier Code (BIC) serves as unique identification of a payment service provider. For SEPA payments, only the use of
the BIC is permitted, while for international payments, other identifiers may also be used. However, it is strongly recommended
to use the BIC.
The Creditor Agent can also be uniquely assigned with other characteristics instead of the BIC. An alternative to specifying the
BIC is the use of the Clearing System Member Identification <ClrSysMmbId>, which enables the assignment of a member within
a Clearing system or the LEI <LEI>, the Legal Entity Identifier. On top of that, a payment service provider can also be assigned
with other identification characteristics <Othr> or the branch of the payment service provider can be assigned with the Branch
Identification <BrnchId>.
Example Credit Transfer pain.001 without BIC
<CdtrAgt>
<FinInstnId>
    <ClrSysMmbId>700202070</ClrSysMmbId>
    <LEI>2ZCNRR8UK830BTEK2170</LEI>
    <Nm>UniCredit Bank AG</Nm>
    <PstlAdr>
        <PstCd>80995</PstCd>
        <TwnNm>Muenchen</TwnNm>
        <Ctry>DE</Ctry>
    </PstlAdr>
</FinInstnId>
</CdtrAgt>
41
10.8 Creditor Identifier (CI)
• SEPA Direct Debit initiators have to have a definitive identification number. In Germany, the length is 18 and it can be
obtained from the German Federal Bank for each legal entity under www.glaeubiger-id.bundesbank.de
Format: LLPPZZZ0NNNNNNNNNN
LL Country code
PP Check digits computed in compliance with ISO 13616 (equivalent to the IBAN check digits)
ZZZ Creditor’s business sector identification, to be awarded randomly in order to prevent overlaps in mandate
references. In the standard version, enter value ZZZ (The sector identification is not part of the cross-checking
calculation.)
NNN… National identification up to 28 characters (in Germany 11 digits incl. leading 0)
<CdtrSchmeId>
    <Id>
        <PrvtId>
            <Othr>
                <Id>DE12ZZZ01234567890</Id>
                <SchmeNm>
                    <Prtry>SEPA</Prtry>
                </SchmeNm>
            </Othr>
        </PrvtId>
    </Id>
</CdtrSchmeId>
• As far as possible, the Creditor Identifier should be stated at the PaymentInformation level, and not repeated for each
transaction
• The check digit calculation ignores the Creditor’s business sector identification
• If a different Creditor’s business sector identification is utilised at the collection, it must be stated on the mandate
• For information on the formats and contact centres for creditor identifiers in other countries, please go to
https://www.europeanpaymentscouncil.eu/document-library/clarification-paper/creditor-identifier-overview
42
10.9 Identification numbers (OrgId/PrvtId)
• An identification number can be provided along with the name as an option. In Germany (DFÜ Agreement Annex 3), entries
into these fields are not recommended, given that consistency, e. g. in MT940 is not ascertained. However, in some
countries or for certain payments, e. g. tax payments, this information is required. In some cases, the international CGI-MP
format also requires these identification numbers. Besides the identification number, it is also possible to provide data, e. g.
the issuing government agency <Issr>. For same it is possible to provide either an organisation’s or a person’s number.
• OrganisationIdentification <OrgId>, e. g. company identification number (COID), customer number (CUST), tax identification
number (TXID), employer number (EMPL), BIC/BEI, DUNS, etc. Download on iso20022.org/external_code_list.page the
“External Code Sets spreadsheet” and see under tab “9-OrganisationIdentification”
Example (an identification number or a business entity code)

<Id>
    <OrgId>
        <Othr>
            <Id>181/815/08155</Id>
            <SchmeNm>
                <Cd>TXID</Cd>
            </SchmeNm>
            <Issr>Finanzamt Muenchen IV</Issr>
        </Othr>
    </OrgId>
</Id>
<Id>
    <OrgId>
        <BICOrBEI>KUNDDEMM123</BICOrBEI>
    </OrgId>
</Id>
• PrivateIdentification <PrvtId>, e. g. birth date/place, social security number (SOSE), passport number (CCPT), tax
identification number (TXID), customer number (CUST), driver’s license number (DRLC), employee identification number
(EMPL), etc. Download on iso20022.org/external_code_list.page the “External Code Sets spreadsheet” and see tab
“10-PersonIdentifcation”
Example (either date of birth/place of birth OR a number)

<Id>
    <PrvtId>
        <DtAndPlcOfBirth>
            <BirthDt>1980-11-07</BirthDt>
            <PrvcOfBirth>Bayern</PrvcOfBirth>
            <CityOfBirth>Muenchen</CityOfBirth>
            <CtryOfBirth>DE</CtryOfBirth>
        </DtAndPlcOfBirth>
    </PrvtId>
</Id>
<Id>
    <PrvtId>
        <Othr>
            <Id>RA 123445123</Id>
            <SchmeNm>
                <Cd>CCPT</Cd>
            </SchmeNm>
            <Issr>Stadt Ulm</Issr>
        </Othr>
    </PrvtId>
</Id>
43
10.10 Ultimate/Reference Party/On Behalf
• Besides the ordering party, it is possible to provide name fields for a deviating ordering party – the “Ultimate.” It is also
possible to enter an ultimate beneficiary for the recipient or to provide an ultimate debtor along with the transaction.
• The deviating ordering party can be provided either on the bulk level (PaymentInformation) or on the transaction level. The
use on the bulk level is recommended in this case.
• If an ultimate is used in conjunction with a SEPA Direct Debit, this ultimate must also be indicated on the mandate.
• To ensure debt eliminating credit of payments when paying via direct debit, a third party account is required at the payment
beneficiary’s end.
• The ultimate fields are for information only and will be interpreted as additional remittance information.
• From 2022: A structured address must also be stated for the ultimate parties in urgent and SWIFT international payments.
• Not every bank offers the sharing of this additional information with the recipient through all channels. In particular on the
paper-based account statement, such information is printed out only in some cases at this time. The provision of data in the
remittance information section does in any event allow for an indication with the final beneficiary or debtor.
• In MT940 the ultimate information is passed on in field 86/sub-field ?20-?29 or if space is not available, in subfield ?60-?63:
• ABWA + [different payment initiator (CT) or creditor of the payment (DD)].
• ABWE + [different payment beneficary (CT) or debtor of the payment (DD)].
Example transfer childcare benefits

<Dbtr>
    <Nm>Firma AG</Nm>
</Dbtr>
<Cdtr>
    <Nm>Mutter Meier</Nm>
</Cdtr>
<UltmtDbtr>
    <Nm>Kindergeld-Abteilung</Nm>
</UltmtDbtr>
<UltmtCdtr>
    <Nm>Kind Meier</Nm>
</UltmtCdtr>
Example Direct Debit of mobile bill

<Cdtr>
    <Nm>Mobile Phone AG</Nm>
</Cdtr>
<Dbtr>
    <Nm>Mutter Meier</Nm>
</Dbtr>
<UltmtDbtr>
    <Nm>Kind Meier</Nm>
</UltmtDbtr>
Different account for returns

It is also possible to use the ultimate fields to provide information about a different account for returns. The submitter and
debit account is entered into the field group UltimateDebtorId for transfers or UltimateCreditorId for direct debits. Any account
that deviates from the former that is used for the posting of potential returns is subsequently entered into the normal debtor
or creditor fields. A special agreement with UniCredit is required for such arrangements. For more information on the “ultimate
ordering party” product, please contact your Cash Management & eBanking Specialist.
44
On behalf Payments über Payment Factory
If a holding company makes payments for various companies that are part of a group of companies (Payment Factory) it
is important – especially for SEPA Direct Debits, mandates and Creditor Identifiers – to consider who is required to enter
into mandates with which Creditor Identifier and which accounts will be used to transact the payments so that all of the
requirements on the ordering party and with regard to debt eliminating payments are met.
• Basic presumption: delivery and billing transactions are handled by Supplier Co.
• The creditor is the Payment-Factoring-Co. The account managing function will have to make certain that the inbound funds
are posted to a third party account (escrow account for the Supplier Co.). A declaration of assumption of liability by the
Payment-Factoring-Co is required for returned direct debits.
• The Payment-Factoring-Co submits the direct debits. The Creditor Identifier (CI) of the Payment-Factoring-Co is saved along
with the submitter account and verified when submissions are made. If a credit is posted to an account of the Payment-
Factoring-Co the CI of the Payment-Factoring-Co will have to be on record. A company has to have a CI to submit direct
debits, i. e. the Payment-Factoring-Co cannot use the CI of the Supplier Co. to make submissions.
• The following information must be provided on the mandate: The creditor is the Payment-Factoring-Co;
the CI of the Payment-Factoring-Co as the Creditor Reference Party becomes the Supplier Co. and its CI is provided as the
Creditor Reference ID.
• Thanks to the fact that the account number is linked to the CI, the mandate with the Creditor Supplier Co. and the CI of the
Supplier Co. can only be used for credits to the Supplier Co. account.
Direct debit
<Cdtr>
    <Nm>Zahlungsabwicklungsfirma</Nm>
</Cdtr>
<Dbtr>
    <Nm>Meier</Nm>
</Dbtr>
<UltmtCdtr>
    <Nm>Lieferfirma</Nm>
</UltmtCdtr>
10.11 Mandate amendment

• It is not necessary to obtain a new mandate every time the mandate is modified. The mandate is sent along with the next
SEPA Direct Debit due
• The following fields are designated for this reason in pain.008:
• Creditor driven changes
• Alteration of the mandate number e. g. because a new system for mandates is being implemented
• Provision of the new mandate reference <MndtId> and the old mandate reference <OrgnlMndtId>
• Change of the creditor name, e. g. due to corporate mergers. In these cases, a new Creditor Identifier is usually required
as well
• Provision of the new Creditor Identifier <CdtrSchmeId> and the old Creditor Identifier <OrgnlCdtrSchmeId> <Id> as
well as the
• New creditor name <Cdtr> and the old creditor name <OrgnlCdtrSchmeId><Nm>
• Changes at the debtor’s end
• Change of the debtor account information
• Provision of a new IBAN <DbtrAcct> and an old IBAN <OrgnlDbtrAcct> (only if the new and the old IBAN is with the
same bank)
• If the debtor switches banks, only the SMNDA (SameMandateNewDebtorAccount) is assigned without providing the old
banking details. Since the version as of November 2016, the original BIC can be provided as an alternative. Due to the
introduction of IBAN-Only, however, the creditor is often unable to recognise whether the bank has also changed along
with the IBAN, which is why the DK recommends that only the SMNDA (in the OrgnlDbtrAcct element group) is entered as
the direct debit format instead of the old IBAN and the old BIC in the event of a change in the account details. Any special
sequences need no longer be observed. Since November 2016, direct debits can be presented with the RCUR sequence.
• If the address is changed (e. g. as a result of moving address), or the debtor name is changed (e. g. as a result of
marriage) or if the creditor’s banking details are changed, obtaining a new mandate is not required. Special direct debit
mark-ups are not required in such cases. If the debtor’s identity changes (e. g. as a result of switch of tenant), a new
mandate must be obtained, however.
45
Mandate amendment process
1 2
Customer (Debtor) Written notification about Supplier (Creditor)
changed IBAN/BIC
Archiving of the mandate amendment
Pre-Notification with
changed mandate data
4 8 3 5
Mandate amendments
Collection of the direct Submission of the next* direct debit with
B2B – Mandate Debtor IBAN attached mandate amendments
debit with attached
order or debtor pro- (old/new or SMNDA)
mandate amend- * If a direct debit with a mandate amendment is
filing with changed Debtor BIC (old/new) rejected (pain.002), the subsequent debit will once again
ments (old/new)
mandate data Creditor Identifier (CI) (old/new) have to be performed with a mandate amendment.
Creditor name (old/new)
Mandate ID (old/new)
6
Direct debit with attached man-

Debtor bank date amendments (old/new)
7
Checking of the B2B direct debit for a valid

mandate order Check debtor profiling (e. g.
blocking)
• Other requirements to be met:

• If the direct debit containing mandate amendments is rejected prior to settlement (information e. g. with pain.002), the
following direct debit will have to include these mandate amendments as well
• Mandate amendments provided in the direct debit do not automatically result in changes to the instructions at the debtor
bank. The debtor may for instance be required to actively amend the SEPA Direct Debit B2B mandates submitted to the
bank. The same also applies to mandate blocking lists (negative lists) that have been filed with the bank or to explicitly
permitted debits (positive lists) of SEPA Direct Debit CORE. They may have to be adapted to include the amendments
made to the mandate. Hence, in order to prevent unnecessary returns, it is advisable to notify the debtor of any changes
early-on (e. g. through a highlighted pre-notification)
• Archive all mandate amendments and related orders to ensure that you will have complete documentation to prevent a
direct debit from being returned because of lack of authorisation when mandates are requested
• When does a new mandate have to be obtained?

• If more than 36 months have passed since the last automatic debit charge was made
• If a direct debit is returned citing “NoMandate” – MD01 as the return code
• The last direct debit was made with sequence type FNAL-Final or OOFF – OneOff (and was not rejected)
• The debtor must revoke its mandate to the creditor
• After satisfaction of the drawn contract, if the mandate was issued with a special reference to a contract (contract
mandate)
• After a change of debtor (e. g. switch of tenant)
46
<MndtRltdInf>
    <MndtId>555544</MndtId> Current mandate reference and signature date
    <DtOfSgntr>2012-11-12</DtOfSgntr>
    <AmdmntInd>true</AmdmntInd> Indicates mandate amendment to be delivered along with the submission
    <AmdmntInfDtls>
        <OrgnlMndtId>444444</OrgnlMndtId> Previous mandate reference
        <OrgnlCdtrSchmeId>
            <Nm>Versicherungs AG</Nm> Old creditor name
            <Id>
                <PrvtId>
                    <Othr>
                        <Id>DE12ZZZ01234567890</Id> Old Creditor Identifier
                        <SchmeNm>
                            <Prtry>SEPA</Prtry>
                        </SchmeNm>
                    </Othr>
                </PrvtId>
            </Id>
        </OrgnlCdtrSchmeId>
        <OrgnlDbtrAcct>
            <Id>
                <IBAN>DE40700202700012345678</IBAN> Option 1: Old debtor IBAN
                <Othr> (only if identical debtor bank)
                    <Id>SMNDA</Id> Option 2 (recommended): Identification of new debtor bank
                </Othr> and/or debtor IBAN with “SMNDA”
            </Id>
        </OrgnlDbtrAcct>
        <OrgnlDbtrAgt>
            <FinInstnId>
                <BIC>HYVEDEMMXXX</BIC> Option 3: Old debtor BIC
            </FinInstnId>
        </OrgnlDbtrAgt>
    </AmdmntInfDtls>
</MndtRltdInf>
Options 1, 2 or 3 cannot be combined with each other. Only one option is permitted.
10.12 Direct debit sequence

• There are two different SEPA (CORE/B2B) direct debit mandates:
• For RECURRING direct debits
• For ONE-TIME direct debits: The respective category is indicated on the mandate. Other deciding factors for the sequence
are whether a mandate has been previously used or will also be used in the future
• The direct debit has to be executed in the correct direct debit sequence. With effect from November 2017, the sequence
<SeqTp> can also be mixed in a bulk at transaction level
• Types of direct debit sequences <SeqTp>:
• First direct debit of a RECURRING direct debit “FRST” (First) or “RCUR”, as recommended since November 2016
• Subsequent direct debit of a RECURRING direct debit “RCUR” (Recurrent)
• Final direct debit of a RECURRING direct debit “FNAL” (Final)
<SeqTp>RCUR</SeqTp>
• ONE-TIME direct debit “OOFF” (OneOff)

• Only for SEPA Cards Clearing: “RPRE” (Represented)
47
Overview of cut-off dates per direct debit product for all sequences with examples
Cut-off based on the sequence All sequences
Direct debit (CORE) Rule Submission, Debtor Bank, Due Date -x D-1
Cut-off UniCredit D-1, 12 p.m.
Cut-off UniCredit Example: Wed 20 November 2019 Tue 19 November 2019, 12 p.m.
Direct debit (B2B) Rule Submission, Debtor Bank, Due Date -x D-1
Cut-off UniCredit D-1, 12 p.m.
Cut-off UniCredit Example: Wed 20 November 2019 Tue 19 November 2019, 12 p.m.
In force since November 2016:

• For Direct Debit CORE, the D-1 submission deadline will apply for all sequences
• The “FRST” (first) sequence can optionally be used, whilst the “RCUR” (recurrent) sequence can be applied for the initial
submission.
Please observe any deviating cut-off times that may have been agreed upon. The cut-off times in effect at the HBV can be found
at hypovereinsbank.de/hvb/footer/geschaeftsbedingungen-konditionen/terms-conditions
Calculation fundamentals:
• In inter-bank clearing, target days are used for the presentation period (D-1), i. e. Monday – Friday excluding target holidays
(1 January, Good Friday, Easter Monday, 1 May, 25 and 26 December)
• If due date coincides with a weekend day or target holiday, the debtor bank may defer the debit value date to the next
possible bank business day
• The pre-notification rule (minimum of 14 days) is based on calendar days
• Direct debit returns (return D +3 for B2B and D +5 for CORE) are subject to target days
• Bank business days are used to calculate cut-off dates
Special rules for the direct debit sequence

• If the direct debit is rejected prior to settlement (reject/refusal/cancellation via pain.002), the direct debit will be treated as if
it had never arrived and the original sequence will have to be used for the subsequent direct debit. The original presentation
period (D-5/D-2/D-1) will also have to be complied with in such cases.
• If the direct debit is returned after settlement (return/refund), the direct debit will be considered received. For the subsequent
direct debit, the next sequence will have to be used or the mandate will be considered expired if it is a OneOff or final direct
debit. After return of a Final or OneOff, another Final or OneOff can be sent, but not after a Refund (EPC Clarification Paper
November 2017).
• If a mandate amendment to a new debtor bank “SMNDA – SameMandateNewDebitorAccount” is made, the direct debit sequence
can be identified as “RCUR”.
• The first and recurrent direct debit should not have the same due date.
• Since 21 November 2016, the “RCUR” sequence can also be used for first direct debits instead of the “FRST” sequence. The use
of the “RCUR” sequence is also recommended for the first direct debit, because the “RCUR” sequence can again be used as a
standard for recurrent direct debits after direct debit returns before settlement.
48
Which direct debit sequence has to be used for the subsequent debit if the direct debit was returned/rejected and when do
mandate amendments have to be repeated?
Current collection Return/reject of the current collection Subsequent collection
FRST – First No return RCUR – Recurrent<?>
FRST – First Prior to settlement (pain.002) FRST – First
FRST – First After settlement RCUR – Recurrent (see footnote 9)
RCUR – Recurrent or First No return RCUR – Recurrent (see footnote 9)
RCUR – Recurrent or First Prior to settlement (pain.002) RCUR – Recurrent (see footnote 9)
RCUR – Recurrentor First After settlement RCUR – Recurrent (see footnote 9)
FNAL – Final No return No subsequent collection
FNAL – Final Prior to settlement (pain.002) FNAL – final
FNAL – Final After settlement (Return) FNAL – final
FNAL – Final After settlement (Refund) New mandate required
OOFF – OneOff No return No subsequent collection
OOFF – OneOff Prior to settlement (pain.002) OOFF – OneOff
OOFF – OneOff After settlement (Return) OOFF – OneOff
OOFF – OneOff After settlement (Refund) New mandate required
10.13 Characters and mutated vowels (umlauts)

It is possible to use in SEPA with UTF-8 a comprehensive range of characters as well as numerous country-specific mutated
vowels (umlauts), which is also specified in the XML header:
<?xml version="1.0" encoding="UTF-8"?>
All banks within the SEPA are obliged to support at least a limited set of characters:
• Digits 0 through 9
• Letters A through Z and a through z
• Special characters : ? , – ( + . ) / and spaces
The EPC and DK meanwhile recommend supporting country-specific mutated vowels and special characters in order to
facilitate their introduction and acceptance. Banks that are unable to process such special characters and mutated vowels can
replace them with similar characters in line with the EPC’s recommendation, or otherwise by a space or point, if required. The
EPC has published the following general information about characters: europeanpaymentscouncil.eu/knowledge_bank_detail.
cfm?documents_id=332
The character set defined above is possible in all name, address and remittance information fields. In the case of some fields
in the various formats, as well as in the case of special characters, restrictions exist that are summarised in the table below.
Especially in the case of some special characters, the XML standard requires masking characters: for example, the “Fa. O’Hart &
Co -> Fr. Meier” purpose designation is set in XML as follows: Fa. O'Hart & Co -> Fr. Meier
Practical experience in showing that the following errors can arise when managing data:
• Erroneous characters in the case of IBAN or BIC can result in file rejection::
• Risk of confusion in the case of the following letters and digits: letter “O” and digit “0” or letter “I” and digit “1” or letter
“S” and digit “5”
• If the BIC contains digits instead of letters in the first 6 places, such as BEV0DEBBXXX with the digit “0” instead of
BEVODEBBXXX with the letters “O” for the Berliner Volksbank
• The IBAN includes digits instead of letters in the first two places (e. g. N0 instead of NO for Norway) or letters instead of
digits in spaces 3 and 4 (e. g. I0 instead of 10 as check digits)
• In the case of the IBAN, the paper format is utilised with four-blocks separated by spaces, instead of the electronic format
without spaces
• BIC or IBAN contain lowercase letters or even special characters
• Correct BIC structure (scheme check):
• BIC should contain only 8 or 11 digits
• Special characters, mutated vowels (umlauts) all lowercase letters not permitted
• Digits 1 – 6: uppercase letters
• Digit 7: uppercase letters or digits (excluding digits 0 through 1)
49
• Digit 8: digits or uppercase letters (excluding letter O)
• Digits 9 – 11 (if used): uppercase letters and/or digits
• Erroneous characters and references such as the message reference, payment information reference, instruction reference,
end-to-end reference or mandate reference can result in the file being rejected; please also refer to the table below with the
permitted characters
• Erroneously transferred characters in the case of references (e. g. in the case of confusing digits and letters as described above)
can result in it being impossible to allocate a payment transaction to a business transaction, thereby necessitating costly
subsequent processing. In particular, the important mandate reference should be structured so that misunderstandings are
avoided in customer communication. In other words, preferentially no initial zeros should be included, and special characters
should be deployed on only a limited basis
Supported characters in payment transactions

Description Charac- pain DK pain DK pain Reference Mandate MT940 DTAUS DTAZV MT101
ter 2.6 since 2.7 EPC numbers10 reference (DK)
Digits 0 – 9 × × × × × × × × ×
Uppercase letters A – Z × × × × × × × × ×
Lowercase letters a – z × × × × × 11
× – – ×
Space Space × × × ×12 ×13 × × × ×
Question mark ? × × × × × – – – ×
Ampersand & – ×14 ×14 – – – × × –
Pointed brackets <> – – ×14
– – – – – –
Rounded brackets, apostro-
()': × × ×14 × × × – – ×
phe, colon
Further special characters of
the SEPA basic character set:
/-.,+ × × × × × × × × ×
forward slash, minus sign,
point, comma, plus sign
Additional characters from
the German DTA character
*$% – ×15 ×16 – – – × × –
set: star, dollar sign, percent-
age sign
German mutated vowels
(umlauts) (uppercase let- ÄÖÜß – ×15 ×16 – – – × – –
ters), ß ligature
German mutated vowels
äöü – ×15 ×16 – – – – – –
(umlauts) (lowercase letters)
Additional UTF-8 characters
recommended for SEPA,
including: German charac-
ters as listed above plus
exclamation mark, quotation
!"#;=
marks, hash sign, semi-co-
@[]\_ – – ×14, 16 – – – – – –
lon, equation sign, at symbol,
|~§€…
square brackets, back slash,
underscore, vertical slash,
tilde/swung dash, paragraph
sign, Euro currency symbol
and others
10
Relates to message reference <MsgId>, payment information reference <PmtInfId>, end-to-end reference <EndToEndId> and instruction reference <InstrId>
11
Treated as uppercase letters
12
In previous DK formats, spaces were not permitted in the case of the message reference <MsgId>. EPC and DK permit spaces from Version 2.5
13
It is urgently recommended that spaces should not be used in the mandate reference. Spaces (e. g. printing in blocks of 4 digits) should not be used in paper-based mandates either
14
In line with EPC, the following characters must be masked: “&” = “&” , “<” = “<”, “>” = “>”, quotation marks ( “ ) = “"”, apostrophe ( ‘ ) = “'”
15
Characters can be converted by banks: Ä/Ö/Ü/ä/ö/ü → AE/OE/UE/ae/oe/ue or A/O/U/a/o/u; ß → “ss” or “s”; */$/% → “.” (point)
16
EPC recommends support without conversion
50
In addition to the use of special characters (EPC document: EPC230-15), a limitation in the use of slashes will be introduced.
Reference numbers and identifiers must not begin or end with “/”. Furthermore, the use of double slashes “//” is not permitted.
This concerns the following fields:
• Message-Id
• PaymentInf-Id
• End-to-End-Id as well as
• OrgId and PrivId in the element groups
• InitiatingParty
• Debtor
• UltimateDebtor
• Creditor
• UltimateCreditor
10.14 Competing fields – XOR

Frequent field entry errors occur with fields that appear multiple times on different levels or that are subject to conditions. Only
limited cross-checks of those are conducted by the XML schema definition (XSD).
• Some fields appear on both, the bulk level (PaymentInformation) and the transaction level, e. g.
XML field PaymentInformation level Transaction level Mandatory/optional
CreditorIdentification Recommended Alternatively Mandatory for SDD
(only SDD)
ChargeBearer Recommended Alternatively Mandatory, “SLEV”
UltimateDebtor (SCT) Variant 1 (required for UniCredit Variant 2 Optional
UltimateCreditor (SDD) product SEPA ultimate ordering
party)
PaymentTypeInfor- Recommended Alternatively Mandatory field
mation
InstructedPriority (only Optional Not permitted by DK at transaction level Optional (“NORM”, “HIGH”)
SCT)
ServiceLevelCode Recommended Alternatively Mandatory (“SEPA”, “URGP”)
(but must not be mixed within a file)
LocalInstrumentCode Recommended Alternatively Mandatory („CORE“, „B2B“,
(only SDD or Instant) (but must not be mixed within a file) „CARD“ or „INST“)
CategoryPurpose Recommended (required for Alternatively Optional
UniCredit’s SEPA salary payment
product)
• For some fields, either one or the other may be used. It is not possible to make entries into both field groups. The XSD of the
DK does perform a cross-check, while the XSD for EPC formats will not find any errors in such scenarios
• The remittance information entry may either be structured <Strd> OR unstructured <Ustrd>. It is not possible to use the
two simultaneously
• Organisational-ID <OrgId> versus Private-ID <PrvtId>. Only one of the two element groups is permitted
• If a Private ID is used, it is also only possible to use either one Identification <Id> in combination with the
issuer <Issr> and type of Identification <SchmeNm><Cd> OR one date of birth in combination with the place of birth
<DtAndPlcOfBirth>
51
10.15 Reference numbers and how to use them
Which reference numbers do exist in payment transactions and where are they assigned?
XML field Description File/transaction level Use
Submission
Message-ID Unique technical reference of the file by the file author GroupHeader SCT, SDD
<MsgId>
DTI file number UniCredit bulk reference
OriginalMessage-ID Original reference of the logical file in the event of file reject or GroupHeader camt.055
<OrgnlMsgId> camt.055
PaymentInformation-ID Reference of the logical bulk (collector reference) PaymentInformation SCT, SDD
<PmtInfId>
OriginalPaymentInformation-ID Original reference of the logical bulk in the event of bulk reject or PaymentInformation camt.055
<OrgnlPmtInfId> camt.055
File number UniCredit Unique bulk number assigned by UniCredit PaymentInformation –
Transaction reference UniCredit Unique UniCredit reference for the single transaction Transaction SCT, SDD
CreditorIdentification Unique CreditorIdentification (issued by the German Federal Bank) PaymentInformation SDD
<CdtrSchmeId> oder Transaction
OriginalCreditorIdentification The original creditor identification is only used in the event of a Transaction SDD
<OrgnlCdtrSchmeID> mandate amendment
Instruction-ID <InstrId> Technical point-to-point reference. Transaction reference is not Transaction SCT, SDD
passed on.
OriginalInstruction-ID Original point-to-point reference in the event of reject or camt.055 Transaction camt.055
<OrgnlInstrId>
End2End-ID Functional ordering party reference – is forwarded to the recipient Transaction SCT, SDD
<EndToEndId>
OriginalEnd2End-ID Original ordering party reference in the event of reject or camt.055 Transaction camt.055
<OrgnlEndToEndId>
Transaction-ID Unique transaction number assigned by the first banking institution Transaction –
<TxId> involved
StructuredCreditorReference Structured reference number in structured remittance information Transaction SCT, SDD
<CdtrRefInf> field
Mandate-ID Unique mandate reference in combination with CreditorIdentifica- Transaction SDD,
<MndtId> tion camt.055
OriginalMandate-ID Only required for mandate amendments as the original mandate Transaction SDD
<OrgnlMndtId> reference
Organisation-ID Identification number of an organisation (BIC, BEI, tax identification PaymentInformation –
<OrgId> <?> number, customer number, etc., see ISO 20022 External code list) or transaction
Personal-ID Identification number of a natural person (date of birth/place, PaymentInformation –
<PrvtId> 18 social security number, passport number, tax identification number, or transaction
customer number, etc.; see ISO External code list)
Case-Id Customer reference for the recall File camt.055
<Case><Id>
Resolved Case Id Reference in camt.029 to Case-Id of camt.055 PaymentInformation –
<RslvdCase><Id> or transaction
Assignment Unique camt.055 file reference Header camt.055
<Assgnmt>
Status Id Bank reference for the return Transaction –
<StatusId>
InstructionForCreditorAgent Unique End-To-End Transaction Reference (UETR) by the ordering Transaction pain.001
<InstrForCdtrAgt><InstrInf> party or the first-involved financial institution for cross-border Cross border
payments (SWIFT gpi)
UETR <UETR> Unique reference number for Urgent- and international payments Transaction pain.001
CrossBorder
17
Not recommended for use in Germany, supplement for InitiatingParty, Debtor, Creditor, UltimateDebtor, UltimateCreditor
52
Depiction of reference numbers in payment transactions via MT940/942/camt and pain.0022
XML field Reporting pain.002 Reporting MT940/942 Reporting camt.052/camt.053
Message-ID pain.002 – –
<MsgId>
DTI file number – <AddtlInfInd><MsgId>
OriginalMessage-ID pain.002 – –
<OrgnlMsgId>
PaymentInformation-ID If longer than 16 characters: <NtryDtls><Btch><PmtInfId>
<PmtInfId> 86 with Identifier REF <NtryDtls><TxDtls><Refs><PmtInfId>
If shorter: :61/7: (only initiator entry)
OriginalPaymentInformation-ID pain.002, camt.029 – –
<OrgnlPmtInfId>
File number UniCredit – :61/9: –
Transaction reference UniCredit – :61/8: <NtryDtls><TxDtls><Refs>
<AcctSvcrRef> bzw. <NtryDtls><Tx-
Dtls><Refs><ClrSysRef>
CreditorIdentification – :86: with identifier CRED+ <NtryDtls><TxDtls> <RltdP-
<CdtrSchmeId> ties><Cdtr><Id><PrvtId><Othr><Id>
OriginalCreditorIdentification – – –
<OrgnlCdtrSchmeID>
Instruction-ID – – –
<InstrId>
OriginalInstruction-ID pain.002, camt.029 – –
<OrgnlInstrId>
End2End-ID – :86: with identifier EREF+ <NtryDtls><TxDtls><Refs>
<EndToEndId> <EndToEndId>
OriginalEnd2End-ID pain.002, camt.029 – –
<OrgnlEndToEndId>
Transaction-ID – – <NtryDtls><TxDtls><Refs><TxId>
<TxId>
StructuredCreditorReference pain.002 Part of a structured remittance Part of the structured remittance
<CdtrRefInf> (however, without tags) information
Mandate-ID pain.002 :86: with identifier MREF+ <NtryDtls><TxDtls><Refs><MndtId>
<MndtId>
OriginalMandate-ID – – –
<OrgnlMndtId>
Organisation-ID – – –
<OrgId>
Personal-ID – Only for Creditor Identification (see Only for Creditor Identification (see
<PrvtId> above) above)
Case-Id – – –
<Case><Id>
Resolved Case Id camt.029 – –
<RslvdCase><Id>
Assignment camt.029 – –
<Assgnmt><Id>
Status-Id pain.002 – –
<StsId>
InstructionForCreditorAgent pain.002 gpi – <AddtlRmtInf>UETR/…
<InstrForCdtrAgt><InstrInf> From ISO Version Tag <UETR>
From ISO Version 2019 Tag <UETR>
53
End-to-end reference <EndToEndId>
• The end-to-end reference, which may contain up to 35 digits, has to be assigned by the submitter.
It is forwarded to the final recipient and will also be returned to the submitter in the event of returns
• If the submitter does not provide this reference, the bank makes the entry “NOTPROVIDED”
• Forwarding in MT940: field 86/sub-field ?20-?29: EREF + [end-to-end reference] of if space is not available in sub-field ?60-?63
• For SCC card payments, the reference number is structured as follows: nnnnnnnnkkkkkkTTMMYYhhmmssXXXXXXXXX
• n = 8-digit terminal ID (the first 3 digits show the certified electronic cash network provider)
• k = 6-digit serial number
• Date/Time
• X = optional number
<EndToEndId>12345678901234567890123456789012345</EndToEndId>
Mandate reference <MndtId>

• The mandate number is unambiguous on the pan-European level when used in combination with the Creditor Identifier (CI)
• The mandate number, which has up to 35 digits, must be clearly assigned by the submitter (creditor) for SEPA Direct Debit
• The mandate number allows the debtor to coordinate any instructions with the debtor bank (e. g. to block direct debits or limit
the amounts for direct debits and to archive automatic debit withdrawal authorisations in the B2B mandate)
• It is forwarded to the debtor by way of:
• Pre-notification (recommended)
• A mandatory field in the SEPA Direct Debit <MdtId>
• Signature mandate (however, retroactive completion is also possible)
• Direct debit returns
• Electronic account statement MT940 (field 86/sub-field ?20-?29: MREF + [mandate reference]) or if space is not
available, in sub-field ?60-?63
• If the mandate number changes, the change can be executed through the standardised mandate amendment (see chapter
“Mandate amendment”)
• The mandate reference has the following valid characters:
• Digits 0 – 9
• Upper-case letters A – Z
• Lower-case letters a – z (but treated as upper-case letters)
• Special characters ? ( ) ' : / - . , +
• Spaces
• We recommend that spaces should not be used in the mandate reference, either in direct debiting or in paper-based
mandates (e. g. no blocks of 4 digits). Since spaces are now valid characters, different reactions may occur during the
validation of filed mandates or mandate instructions when submitting the direct debit to the debtor bank
<MndtId>555544</MndtId>
Unique End-To-End Transaction Reference (UETR)

• In the case of cross-border payments (SWIFT gpi), the unique end-to-end transaction reference is assigned either by the
initiating party or by UniCredit.
• This reference has a length of 36 characters, consisting of a 32-byte hexadecimal number separated by hyphens based on
the Universally Unique Identifier (UUID), and is divided into five groups.
• The reference number is structured as follows: xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx
• x = hexadecimal lowercase letters
• y = 8, 9, a or b
pain.001:
<InstrForCdtrAgt>
    <InstrInf>UETR/eb6305c9-1f7f-49de-aed0-16487c27b42d</InstrInf>
</InstrForCdtrAgt>
pain.002 / camt.053:
<Strd>
    <AddtlRmtInf>UETR/eb6305c9-1f7f-49de-aed0-16487c27b42d</AddtlRmtInf>
</Strd>
54
Valid with the new ISO Version from 2021/2022:
pain.001.001.09:
<Pmtld>
    ...
    <UETR>eb6305c9-1f7f-49de-aed0-16487c27b42d</UETR>
    ...
pain.002.001.10:
<Pmtld>
    ...
    <OrgnlUETR>eb6305c9-1f7f-49de-aed0-16487c27b42d</OrgnlUETR>
    ...
camt.053.001.08:
<Pmtld>
    ...
    <UETR>eb6305c9-1f7f-49de-aed0-16487c27b42d</UETR>
    ...
55
11 Reporting overview
11.1 Reporting (bank – customer)
Which bank-customer format is to be used for which reason? In the table below you will find an overview of the possible
variants of electronic account information related to account statements, advices, consolidated postings, and error information.
Further information on the listed variants MT940, MT942, DTI, camt.05x, pain.002 as well as on return reasons and business
transaction codes is provided in the documents “Reporting” and “Business transaction and return codes”, which you can obtain
from your Cash Management & eBanking Specialist upon request.
Format Recommended for Options Restrictions/ Format Possible preparation

to be complied with time
MT940 Electronic account statement Not all SEPA fields are MT940 End of day
– legacy systems passed on. Posting day
Will be disabled in
2025
MT942 Intraday advices – legacy Not all SEPA fields are MT942 1/2 hourly
systems passed on. Posting day
Will be disabled in
2025
camt.053 Electronic account statement camt.053.001.02 End of posting day
camt.053.001.08
camt.052 Electronic payment advice camt.052.001.02 ½ hourly posting
camt.053.001.08 between 7.20 a.m. –
8.20 p.m. posting day
camt.054 Electronic processing of • Electronic information camt.054.001.02 ½ hourly posting
(C54) batched incoming trans concerning the submit- camt.053.001.08 between 5.00 a.m. –
actions and returns ted SEPA bulk 9.00 p.m. posting day
• As of June 2013
optionally also for direct
debits rejects prior to
settlement
camt.054 Real-time shop systems Incoming instant credit Not yet real-time in the camt.054.001.02 1/2 hourly, daily 24/7
(C5N) transfers introduction phase camt.053.001.08
camt.086 Electronic services bill camt.086.001.02 Monthly or quarterly
reporting depending on cus-
tomer’s choice
pain.002 Positive and negative status Each status code can be No direct debit return DK: Shortly after error is
information at bulk and selected individually. fees reported pain.002.001.03 detected or status is
transaction level to quickly Options: pain.002.003.03 reached
track the status of submitted • SEPA Credit Transfer pain.002.002.03
payment orders • SEPA Direct Debit daily, 24/7
• International payment EPC:
transaction (gpi) pain.002.001.03
• SEPA Instant Credit
Transfer
camt.029 Mandatory for camt.055 camt.029.001.06 Shortly after availa-
electronic payment cancella- bility of a response to
tion requests the payment cancel-
lation request
BKA Electronic account statement PDF End of posting day
Your Cash Management & eBanking specialist will be happy to provide you further detailed information on the possible
configurations of preparation times upon request.
56
11.2 Posting of SEPA files
Posting of the file (bulk/single transaction)
What is the process for account posting of submitter bulks?
The default account setting for submissions that comprise more than one item is the bulk posting. If so requested by the
customer, it is also possible to post all payments individually to the account, or the account may be administrated in such a
manner that a choice can be made for each individual file, whether it is to be treated as a bulk (e. g. payroll files) or whether it
will be treated as a single posting on the account statement. You do have the option to select the bulked or single posting option
for each posting in the submitted SEPA file; bulked posting is not offered for international payment transactions (identifier
“BatchBooking”):
<PmtInfId>
…
    <BtchBookg>true</BtchBookg>
…
</PmtInfId>
BatchBooking = “true” (bulked posting)

Entry/Value Descritpion Balance/Posting
Your prior balance EUR 90,000.00+
17.11. SEPA-ÜBERWEISUNGSDATEI 10.00-

17.11. DATEI CTD171114KMVE000012    POSTEN    2
ZAHLUNGSREFERENZ payInf-1234
Your current balance EUR 89,990.00+
BatchBooking = “false” (single transaction posting)

Entry/Value Descritpion Balance/Posting
Your prior balance EUR 90,000.00+

17.11. DATEI CTD171114KMVE000012
ZAHLUNGSREFERENZ CTD171114K MVE00001200000001
Firma Hans Mustermann, GmbH u Co
Muster-Verwendungszweck 123 für Rechnung 471111111111111
Warensendung vom 12.11.2014. Vielen Dank für die prompte
Lieferung
KUNDENREFERENZ end-2-end ID 1231223

17.11. DATEI CTD171114KMVE000012
ZAHLUNGSREFERENZ CTD171114K MVE00001200000002
Firma Markus Maier GmbH
Muster-Verwendungszweck 342 für Rechnung 471111111111112
KUNDENREFERENZ end-2-end ID 1231224
Your current balance EUR 89,990.00+
To make sure that field “BatchBooking” is taken into account during processing, please make respective advance arrangements
with your bank’s Cash Management & eBanking Specialist.
57
Submitter – gross principle
The submitter posting is executed in compliance with the gross principle, i. e. if individual transfers are rejected (e. g. because
of two incorrect BICs in a bulk comprising 10 transactions), the debit to the submitter account will be made for the total
amount provided in the bulk for the 10 transactions. The erroneous two transactions are credited to the submitter in return
to compensate for the debit (upon request, this posting may be made as a bulked amount or as single transaction postings).
The information about the error details is sent immediately via an paper-based/faxed error log – and – if requested – through
electronic status information “pain.002.” The posting of submissions and erroneous transactions is always executed on the
booking day, which is particularly relevant for direct debits with e. g. 6 days of presentation period. The posted erroneous
transactions are made available to you on the booking day via MT940 or camt.053/camt.054.
Submitter – net principle

The net principle (the erroneous transactions are not posted at all) is applied only if the entire bulk is rejected. The information
about the error details in this case is also provided via paper-based/faxed error log and – if requested – also via the electronic
status information “pain.002.”
How is the recipient posting on the account made?

It is also possible to bulk a large number of credit transfers or direct debits to the account in one total amount in SEPA. The item
details can be provided to you in an electronic file for further processing in such cases
• camt.054 (C54): in this case, the incoming SEPA transactions are collected. This enables you to use the comprehensive SEPA-
XML format fields also for further processing
• Equivalent transactions (e. g. credit transfer orders received, direct debit returns) can be collected in the recipient account
and posted as a bulked amount
• The handling of account dispositions is more comfortable
• The bulk details are efficiently handled in a separate customer process
Recipient posting
camt.053 (account statement)

<Entry 1>
    <bulked postings>
<Entry 2>
Ordering customer <Entry …>
<?XML>
Ordering customer Bank Recipient
camt.054 (bulk details)

<bulked transaction 1>
<bulked transaction 2>
Ordering customer <bulked transaction …>
58
12 International payment
formats
12.1 The country-specific formats
• The country-specific sub-sets are based on ISO 20022
• They will usually be accepted by all domestic banks
• The formats do have detailed cross-checking procedures in addition to XSD schemes to ensure correct SEPA field entries
• Naturally, SEPA transactions can also be processed across the whole of Europe using the country subsets
If you do not want to restrict your submission of SEPA files (only) to Germany, the ISO 20022 XML format offers various options.
You can also use the international formats based on ISO 20022 if you do not want to use the customer-bank formats specifically
for each individual country.
Examples of country-specific variants (multi-banking standards).
Germany – DK
For further details or information about the technical fields, please follow this link: Appendix 3 of the Specification for Remote Data Transfer Between
Customer and Bank According to the DFÜ Agreement Version 3.5 of 21st November 2021.
• https://www.ebics.de/de/datenformate/gueltige-version
For further information on the final description of the formats, please refer to:
• Deutsche Kreditwirtschaft (DK – German Banking Industry Committee): ebics.de Annexes to Chapter 2 “SEPA Payment
Transactions” of Appendix 3
• XML schemes for SEPA: ebics.de
Austria – STUZZA:
• stuzza.at/de/download/mbs-multi-bank-standard.html
Italy – CBI:
• cbi-org.eu/Engine/RAServePG.php/P/255010010407/T/Technical-Standards
59
12.2 The European SEPA basic format EPC
The special requirements listed below will have to be observed when using the SEPA EPC format:
• It defines only the actual SEPA products:
• SEPA Credit Transfer
• SEPA Instant Credit Transfer
• SEPA Direct Debit CORE
• SEPA Direct Debit B2B
• For each variant of the format, it will have to be verified whether the submitter bank will accept it
Differences between EPC and the German DK format:

• The functional description of the EPC format can be derived from the EPC-Implementation Rules (Customer-to-Bank
Implementation Guidelines) at www.europeanpaymentscouncil.eu. Individual EPC-XSDs were published. Individual XSDs
differentiated at the EPC are available for every product (SCT, CORE and B2B):
• SEPA Credit Transfer
• pain.001.001.09 (Instant payments)
• pain.001.001.03 (only ServiceLevel “SEPA”, no urgent payment possible “URGP”“)
• pain.002.001.03 (for SCT)
• SEPA Direct Debit CORE
• pain.008.001.02 (only LocalInstrumentCode “CORE”)
• pain.002.001.03 (only LocalInstrumentCode “CORE”)
• SEPA Direct Debit B2B
• pain.008.001.02 (only LocalInstrumentCode “B2B”)
• pain.002.001.03 (only LocalInstrumentCode “B2B”)
• Credit Notification
• camt.052.001.08
• camt.053.001.08
• camt.054.001.08
• Just like the DK format, EPC is based on ISO 20022; only fields within the scope of the SEPA spectrum are being used.
• The XSDs published by the EPC are not that strict in checking the individual reference numbers for a valid character set,
which may lead to problems during the further processing.
• Container variants are not possible.
• There are only minimal differences between the function format description or field entries between EPC and DK.
60
12.3 CGI-MP – Common Global Implementation Market Practice
Initiative
The objectives of this initiative are:
• The definition of a mutual global standard
• Based on ISO 20022 Payment Messages
• For the customer-bank interface
• For all payment transaction products.
The core topics are:

• Identical batch structures for all types of payments at all banks around the world (creation of a multi-banking standard, but
only in the customer-bank environment)
• Finding the optimum format for the future planning of globally engaged groups who want to convert their domestic payment
transactions and their international payment transactions to XML
• CGI-MP also defines the formats for SWIFT gpi
• It is possible to provide information on all currencies; however bi-lateral arrangements would have to be made with each
bank
• CGI-MP-XML is based on ISO 20022 XML without any restrictions, but does take into account the national requirements and/
or requirements of a community (e. g. SEPA)
• Forum for banks and banking associations, corporates, alliances and retailers who continue to further develop this standard
(current participants: 110 corporates and 50 banks (among them UniCredit)
• swift.com/cgi
• However, the CGI-MP format is extremely complex and is currently suitable only for individual key accounts since:
• Only a few banks currently accept the format
• The diverse fields (more than 500 usable ISO fields) are reduced to fewer than 150 fields in the inter-banking transactions
and therefore provide only limited information to the recipients of payments
• Bi-lateral agreements with banks are required for about 20 % of the field entries
• Bi-lateral agreements considering code words is also required with banks or payment recipients
• The name-space/header is different from the one used in the DK format:
• SCT: pain.001.001.03
• SDD: pain.008.001.02
• Status information: pain.002.001.03
• Currently it is planned to switch to the new ISO Version pain.001.001.09 or pain.002.001.10 as well as for account
statements to camt.053.001.008
• Container variants are not possible
• There is a significant difference between the function format description or field entries between CGI-MP and DK
61
Graphic overview ISO 20022 payment formats
ISO 20022-XSD
SO 20022 (Basic Standard)
CGI-MP
EPC-XSD
EPC
DK STUZZA CBI
Country-specific variants-XSD Country Sub-sets
Brief comparison of the DK/EPC/CGI-MP formats

Target Products German DK Format European EPC Format International CGI-MP Format
Remittance information Unstructured remittance infor- Unstructured remittance infor- Unstructured remittance infor-
mation or part of the structured mation or part of the structured mation 700 characters and vast
remittance information, max. 140 remittance information, max. 140 variations of structured remittance
characters characters information
Address Information Unstructured address lines Unstructured address lines Structured and unstructured
(2 × 70 characters) (2 × 70 characters) address lines
(up to 7 × 70 characters)
Organisational and personal IDs Optional In some cases required In some cases required
Inter-bank consistency of the Yes, warranted, given that all DK Yes, warranted, since the EPC No, only EPC fields and EPC max-
information (e. g. address infor- fields were developed on the basis format is being applied in SEPA imum limits for field entries are
mation, remittance information, of the EPC format. inter-banking transactions. passed through to the end.
IDs) for SEPA payments. Will the
information be received by the
recipient bank?
Bank availability All German banks European banks Primarily the 50 CGI-MP banks
Banking standard German multi-banking standard Acceptance to be coordinated with More than 20 % of the fields have
the bank to be agreed upon bi-laterally
Verification scheme (XSD) Yes, own system available yes, EPC scheme available Only ISO 20022
62
Which format is the practical one for you to use?
Procedure/decision-making criteria:
• Define the products you are planning to implement (SEPA, international payment transaction, urgent payments, account
statements, …) or which payment transaction products you would like to start with.
• Next, define, which special information you would like to transport along with the payment.
• Will the unstructured remittance information be sufficient for you or will you also need to use the structured remittance
information?
• Do you have to send through “Ultimates” or are you making “on behalf” payments?
• Are you planning to use the special Organisational IDs or Private IDs?
• In any event, we recommend that you utilise the standard fields regardless of the format:
• Unstructured address lines
• Take maximum entries into account: Address (2 × 70), Name (70), Remittance information (140)
• Start on the basis of the EPC fields or inter-banking throughput capability (EPC and DK both ensure this happens)
• To determine the technical format, the following are also important factors:
• Bank availability. Does your bank accept this format? (UniCredit accepts DK, and since 2012 also EPC and CGI-MP formats)
12.4 Specification in comparison to CGI-MP, EPC and DK

General observations
The main differences relating to the XML fields are listed. UniCredit’s implementation of CGI (CGI UC) is also referenced in
addition to CGI-MP, EPC and DK. In CGI UC, certain mandatory CGI-MP fields are optionally accepted so that customers can
submit their transactions without difficulty in the intricate CGI-MP format. CGI-MP is the most comprehensive format, i. e.
numerous additional fields are available that neither EPC nor DK offer. At the same time, it should be remembered that, where
SEPA Germany is concerned, there is a possibility that these might not be forwarded during the interbank clearing process and
therefore that the information may not reach the recipient.
Main differences – SEPA Germany credit transfers

Field (group) CGI- CGI- EPC DK Inter- Remarks
MP* UC 1.1 3.3 bank
/GroupHeader/…
Authorisation/… O I I – – e. g. User-ID
InitiatingParty/Identification/… R R O O –
/PaymentInformation/…
PaymentTypeInformation/InstructionPriority O O O O – Additional cross-checks are in place
between the PaymentInformation
…/ServiceLevel R R O R x
and TransactionInformation levels.
…/LocalInstrument O I O O x ServiceLevel when using SEPA only
“SEPA“, otherwise “URGP” or “SDVA”
…/CategoryPurpose O O O O S
also possible.
LocalInstrument “INST” in the case of
instant payment
Debtor/Name R R R R x
…/Id/OrgId, …/Id/Prvt O O O O x
…/PostalAddress/Country R O O O x
…/PostalAddress/AddressLine O O O O x CGI: up to 7 × 70; Rest: 2 × 70
…/PostalAddress: Department, SubDepartment, StreetName, O O I – – CGI-UC: only StreetName, PostCode,
BuildingNumber, PostCode, TownName, CountrySubDivision TownName
…/CountryOfResidence O I I – –
…/ContactDetails/… O I I – –
DebtorAccount/Identification/IBAN O R R R x
…/Currency R O O O x
…/Identification/Other: Identification, SchemeName/Code, O I I – –
SchemeName/ Proprietary, Issuer
…/Type: Code, Proprietary
DebtorAgent/FinancialInstitutionIdentification/BIC O O O O x EPC,DK: IBAN-Only with
NOTPROVIDED in DebtorAgent/
FinancialInstitutionIdentification/
Other/Identification
…/PostalAddress/Country R I I – –
*cgi-MP related to pain.001.001.03 and not related on the newly planned ISO-Version
63
MP* UC 1.1 3.3 bank
…/FinancialInstitutionIdentification: O I I – –
ClearingSystemMemberIdentification/…,
…/BranchIdentification/Identification
UltimateDebtor/Name R O O O S
…/Id/OrgId, …/Id/Prvt O O O O S
…/PostalAddress, CountryOfResidence, ContactDetails O I I – –
ChargesAccount/… O I I – –
/CreditTransferTransactionInformation/…
PaymentTypeInformation/InstructionPriority O I I – – Additional cross-checks are in place
…/ServiceLevel R R O O x
and TransactionInformation levels
…/LocalInstrument R I O – x
…/CategoryPurpose O I O O S
Amount/InstructedAmount O O R R x EUR only in the case of SEPA
…/EquivalentAmount O O – – – For euro-equivalent payments (not
SEPA)
…/ExchangeRateInformation O I – – –
IntermediaryAgent1/… O O I – – BIC correspondent bank (not SEPA)
CreditorAgent/FinancialInstitutionIdentification/BIC O O O O x EPC, DK: optionally with IBAN-Only
…/PostalAddress/Country R O I – –
…/FinancialInstitutionIdentification: Name, O I I – –
CreditorAgentAccount/… O I I – –
Creditor/Name R R R R x
…/PostalAddress/Country R O O O x
…/PostalAddress/AddressLine O O O O x CGI: up to 7 × 70; rest: 2 × 70
…/PostalAddress: Department, SubDepartment, StreetName, O O I – – CGI-UC only StreetName, PostCode,
CreditorAccount/Identification/IBAN O R R R x
…/Currency O I I – x
…/Other/Id O O I – – National bank account number (not
applicable for SEPA)
…/Type: Code, Proprietary O I I – –
…/Name
UltimateCreditor/Name R O O O S
…/PostalAddress, CountryOfResidence O I I – –
InstructionForCreditorAgent/InstrInf O O I – – UETR for SWIFT gpi
InstructionForDebtorAgent/… O O I – – For currency compensation
(SDVA only) or fax notifications
(not for SEPA)
RegulatoryReporting/…, O I I – –
Tax/…, RelatedRemittanceInformation/…
RemittanceInformation/Unstructured O O O O x 1 × 140 characters
…/Structured/CreditorReferenceInformation/… O O O O x 1 × 140 characters, tags included
…/Structured: For about 25 tags beside O I I – –
CreditorReferenceInformation
Legend: R=Required, O = Optional, I = Ignored, but accepted, x = Transferred in SEPA interbank clearing, S = Transferred only in
SEPA interbank clearing
64
Main differences – Direct Debit SEPA Germany
MP UC 1.1 3.2 banken
/GroupHeader/…
Authorisation/… O I I – – e. g. User-ID
InitiatingParty/Identification/… R R O O –
/PaymentInformation/…
…/ServiceLevel R R R R S
…/LocalInstrument O R R R S
Creditor/Name R R R R S
…/PostalAddress/Country R O O O S
…/PostalAddress/AddressLine O O O O S CGI: up to 7 × 70; rest: 2 × 70
…/ContactDetails/… O I I – –
CreditorAccount/Identification/IBAN O R O O S
…/Currency R O O O S
CreditorAgent/FinancialInstitutionIdentification/BIC O O O O S EPC,DK: IBAN-Only with
NOTPROVIDED in CreditorAgent/
…/PostalAddress/Country R I I – –
ChargesAccount/… O I I – –
CreditorSchemeIdentification/Identification/PrivateIdentifi- O O O O S Includes creditor ID. Cross-checks
cation/Other: Identification, SchemeName/Proprietary between PaymentInformation and
…/: Name, Identification/OrganisationIdentification O I I – –
/DirectDebitTransactionInformation/…
…/ServiceLevel R R R R S
…/LocalInstrument O R R R S
DirectDebitTransaction/… O O O O S CGI has approx. 30 additional option-
Enthält Mandatsdaten inkl. Änderungen al tags compared with the rest
CreditorSchemeIdentification/Identification/PrivateIdentifi- O O O O S Includes creditor ID. Cross-checks
cation/Other: Identification, SchemeName/Proprietary between PaymentInformation and
…/: Name, Identification/OrganisationIdentification O I I – –
IntermediaryAgent1/… O I I – –
65
MP UC 1.1 3.2 banken
DebtorAgent/FinancialInstitutionIdentification/BIC O O O O S EPC, DK: IBAN-Only with
NOTPROVIDED in DebtorAgent/
…/PostalAddress/Country R O I – S
Debtor/Name R R R R S
…/PostalAddress/Country R O O O S
…/PostalAddress/AddressLine O O O O S CGI: up to 7 × 70; rest: 2 × 70
DebtorAccount/Identification/IBAN O R R R S
…/Currency R I I – –
…/Name
…/PostalAddress, CountryOfResidence O I I – –
RegulatoryReporting/…, Tax/…, RelatedRemittanceInforma- O I I – –
tion/…
RemittanceInformation/Unstructured O O O O S 1 × 140 characters
…/Structured/CreditorReferenceInformation/… O O O O S 1 × 140 characters, tags included
…/Structured: For about 25 tags beside O I I – –
CreditorReferenceInformation
66
13 Same-day urgent credit
transfers in euro via pain.001
Since Version 2.7 of the DFÜ-Agreement, same-day urgent credit transfers can also be submitted in the EUR currency (within
Germany or cross-border to all EU/EMS countries) using the ISO 20022-Format pain.001 with the EBICS order type CCU.
Format change to ISO2019 with pain.001.001.09 is planned for November 2023.
Since urgent credit transfers are generally processed as individual payments, utilisation at transaction level is recommended for
particular fields instead of at bulk level in PaymentInformation, as is usual in SEPA bulk transactions. Also in the case of urgent
credit transfers, UniCredit facilitates the utilisation of IBAN-Only in the case of EUR transactions in the SEPA zone without
special instructions (for field entries please refer to chapter “IBAN/IBAN-Only”).
Important functional XML fields for pain.002 SEPA Direct Debit

Field name Description pain.001.001.03 Entries
GrpHdr GroupHeader Sender Data 1 × per logical file
MsgId Initiating party reference Mandatory (to be unique) Max. 35 characters
(Message-Id) number per file
CreDtTm Date/time when a file is created Mandatory ISO date
(CreationDateTime)
NbOfTxs Number of individual trans Mandatory Unlimited
(NumberOfTransactions) actions
CtrlSum Control sum in euro of sub Recommended Unlimited
(ControlSum) mission
InitgPty Initiating party Mandatory Name of the initiating party (may be
(InitiatingParty) different from name of ordering party)
PmtInf PaymentInformation Data about ordering party As often as wished
possible, although
100 maximum
recommended
PmtInfId Reference of submission Mandatory Max. 35 characters
PmtMtd Payment instrument: Credit Mandatory “TRF” – Credit Transfer
(PaymentMethod) Transfer
BtchBookg Presenter booking, bulk/single Optional „true“ – bulk posting
(BatchBooking) „false“ – single posting
NbOfTxs Number of individual trans Optional Unlimited
CtrlSum Controlling sum in euro of the Optional Unlimited
(ControlSum) logical bulk
SvcLvl-Cd Service scheme Mandatory “URGP” – Urgent Payment
(ServiceLevelCode)
CtgyPurp Payment type of bulk Optional “INTC” – Intra Company Payment
(CategoryPurpose) “CORT” – Trade Settlement Payment.
Mapped in field 23e upon conversion into
MT103 (all other codes are ignored)
ReqdExctnDt Requested execution date Mandatory ISO date, maximum 60 days in future.
(RequestedExecutionDate) Date in the past is set to the next possible
working day
Dbtr-Nm Name of debtor; the bank over- Mandatory Max. 70 characters
(DebtorName) writes this with the account
holder’s master data
Dbtr-PstlAdr-Ctry Country of the debtor’s address Optional Country code ISO3166, DE for Germany
(DebtorCountry)
Dbtr-PstlAdr-AdrLine Address of debtor; the bank Optional Max. 2 × 70 characters
(DebtorAddress) over-writes this with the account
holder’s master data
67
Field name Description pain.001.001.03 Entries
DbtrAcct-IBAN Debtor’s IBAN Mandatory Max. 34 characters
(DebtorIBAN)
DbtrAcct-Ccy Currency of the debtor’s account Optional “EUR” currency code
(DebtorAccountCurrency)
DbtrAgt-BIC Debtor’s BIC/SWIFT Code Optional throughout 8 or 11 digits HYVEDEMM(XXX)
(DebtorAgentBIC) SEPA area
DbtrAgt-Othr-Id IBAN-Only ID Only if using IBAN-Only “NOTPROVIDED”
(DebtorAgentId)
UltmtDbtr Different Ordering party Not allowed Field in pain.001.001.03 for Urgent
(UltimateDebtor) payments not usable
ChrgBr Charge bearer Optional Recommended at CdtTrfTxInf level.
(ChargeBearer) “SLEV” – shared charges
If not filled, then the default value is always
shared charge. Instructions here valid for
all transactions
CdtTrf CreditTransfer- Transaction information As often as wished
TxInf TransactionInformation possible, although
10,000 maximum
recommended
InstrId Technical reference between Recommended if filled: to Max. 35 characters
(Instruction-ID) initiating party and bank be unique
EndToEndId Reference to be passed on to the Mandatory (has to be Max. 35 characters. Transferred to the
(End2End-ID) beneficiary through the purpose unique, otherwise first line of the remittance information of
code “NOTPROVIDED”) the target format<?>. No mapping occurs if
“NOTPROVIDED” is in this field.
InstdAmt Amount and currency identifier Mandatory Amount and currency code,
(InstructedAmount) max. 999,999,999.99
ChrgBr Charge bearer Recommended “SLEV” – shared charges
(ChargeBearer) If not filled, then the default value is always
shared charges
UlmtCdtr Different beneficiary Not allowed Field in pain.001.001.03 for Urgent
(UltimateCreditor) payments not usable
CdtrAgt-BIC BIC/SWIFT Code of beneficiary Optional throughout 8 or 11 digits. Also possible at UniCredit:
(CreditorAgentBIC) bank SEPA area “NOTPROVIDED” or “NOTAVAIL”
Cdtr-Nm Beneficiary name Mandatory Max. 70 characters. Composed of the Ctry
(CreditorName) and AdrLine fields, and shortened to 140
characters in the target format.
Cdtr-PstlAdr-Ctry Beneficiary country Mandatory Country code ISO3166.
(CreditorCountry) See also Cdtr-Nm
Cdtr-PstlAdr-AdrLine Beneficiary address Optional, recommend- Max. 2 × 70 characters
(CreditorAddress) ed for cross-border See also Cdtr-Nm
payments
CdtrAcct-IBAN IBAN of the beneficiary Mandatory Max. 34 characters
(CreditorAccount)
Purp (Purpose) Type of payment Optional “INTC” – Intra Company Payment
“CORT” – Trade Settlement Payment
Mapped in field 23e upon conversion into
MT103 (all other codes are ignored)
Ustrd-RmtInf Unstructured remittance Recommended Together with EndToEndIdentification, a
(UnstructuredRemit- information maximum of 140 characters are trans-
tance-Info) ferred to target format (see footnote 18).
Strd-RmtInf Structured remittance Only if no unstructured Together with EndToEndIdentification, a
(StructuredRemittance-Info) information remittance information maximum of 140 content excluding XML
tags are transferred to target format
(see footnote 18).
68
14 Cross-border credit
transfers (SWIFT gpi)
The SWIFT “global payment innovation” initiative – SWIFT gpi for short – is the new standard for executing same-day cross-
border payments.
Key features
• Same-day execution of cross-border payments
• Use of a unique end-to-end reference number (UETR)
• Traceability of outgoing payments in the interbank process in real time
• Heightened fee and exchange rate transparency
• Better data quality through unchanged mandatory disclosure of the remittance information in full
• Stop and recall possibilities
14.1 Current Version pain.001.001.03

Important technical XML fields for SWIFT gpi
Field name Description pain.001.001.03 Entry CGI-MP/SWIFT gpi
GrpHdr GroupHeader Sender data 1 × per logical file
MsgId Initiating Party Message Mandatory field (unique) Max. 35 characters
(Message-Id) Identifier per file
CreDtTm Date/time of file creation Mandatory field ISO date
(CreationDateTime)
NbOfTxs Number of individual trans Mandatory field Unlimited
CtrlSum Control sum for presentation Optional Unlimited
(ControlSum) (without currency code)
InitgPty Initiating party Optional Name of initiating party (may differ from
(InitiatingParty) the name of the ordering party)
PmtInf PaymentInformation Ordering party data Any number of times
possible, max. 100
recommended
PmtInfId Reference for the presentations Mandatory Max. 27 characters
PmtMtd Payment instrument: credit Mandatory „TRF“ – Credit Transfer
(PaymentMethod) transfer
NbOfTxs Number of individual trans Optional Unlimited
CtrlSum Control sum of the logical file Optional Unlimited
PmtTpInf-SvcLvl-Cd Service scheme Optional “SDVA” or “URGP”
(ServiceLevelCode) May not be completed if <PmtMtd> is
assigned “CHK”.
It is recommended to fill <SvcLvl-Cd>
on the individual transaction level
<CdTrfxInf>
PmtTpInf-CtgyPurp File payment type Optional “INTC” – Intra Company Payment
(CategoryPurpose) “CORT” – Trade Settlement Payment
Mapped to field 23e if converted to MT103
(all other codes are ignored). It is recom-
mended to fill <CtgyPurp> on the individual
transaction level <CdTrfxInf>
ReqdExctnDt Requested execution date Mandatory field ISO date, max. 15 days in the future. Dates
(RequestedExecutionDate) in the past are set to the next possible
working day
69
Dbtr-Nm Name of the ordering party – Mandatory field Max. 70 characters
(DebtorName) overwritten by the bank with the
account holder’s master data
Dbtr-PstlAdr Address of the ordering party Optional Max. 70 characters
(DebtorPostalAddress) overwritten by the bank with the
account holder‘s master data
Dbtr-Id (OrgId & PrivId) Number of identification of Optional See chapter 10.09
ordering party
DbtrAcct-Id-IBAN IBAN of ordering party Mandatory field Max. 34 characters
(DebtorIBAN)
DbtrAcct-Ccy Currency used for ordering Optional Currency code
(DebtorAccountCurrency) party’s account
DbtrAgt-FinInstnId-BIC BIC/SWIFT code of the ordering Mandatory field HYVEDEMMXXX
(DebtorAgentBIC) party
ChrgBr Fee allocation Optional “SHAR” – fee sharing
(ChargeBearer) “DEBT” – charges and expenses borne by
the ordering party
“CRED” – charges and expenses borne by
creditor
If empty, the default
value is always fee sharing.
Instructions here apply to all transactions.
It is recommended to fill <ChrgBr> on the
individual transaction level <CdTrfxInf>.
CdtTrf CreditTransfer- Transaction information Any number of times
TxInf TransactionInformation possible, max. 10,000
recommended
InstrId Optional
(Instruction-ID)
EndToEndId Mandatory field Max. 35 characters.
(End2End-ID) Transferred to the first line of the remit-
tance information of the target format.<?>
If this field states “NOTPROVIDED”,
no mapping takes place.
PmtTpInf-SvcLvl-Cd Service scheme Mandatory field “SDVA” or “URGP”
(ServiceLevelCode) May not be completed if “CHK” has been
entered under <PmtMtd>.
It is recommended to fill <SvcLvl-Cd> on
the individual transaction level
<CdTrfxInf>.
PmtTpInf-CtgyPurp-Cd File payment type Optional “INTC” – Intra Company Payment
(CategoryPurpose Code) “CORT” – Trade Settlement Payment
Mapped to field 23e if converted to MT103
(all other codes are ignored). It is recom-
mended to fill <CtgyPurp> on the individual
transaction level <CdTrfxInf>.
Amt-InstdAmt Amount and currency code Recommended Amount and currency code,
(InstructedAmount) max. 99,999,999.99
Amt-Equivalent Amount and currency code Mandatory field if Amount and currency code,
Amount-Amount <InstdAmt> is not filled max. 99,999,999.99
(Amt)
Amt-EquivalentA- Currency code, different from the Mandatory field if Currency code
mount-CurrenyOfTransfer currency used for the ordering <InstdAmt> is not filled
(CcyOfTrf) party’s account
70
ChrgBr Fee allocation Optional “SHAR” – fee sharing
(ChargeBearer) “DEBT” – charges and expenses borne by
ordering party
“CRED” – charges and expenses borne by
creditor
If empty, the default
value is fee sharing.
Instructions here apply to all transactions.
It is recommended to fill <ChrgBr> on the
CdtrAgt-FinInstnId-BIC BIC/SWIFT code of the Recommended 8 or 11 characters
(CreditorAgentBIC) beneficiary’s bank
CdtrAgt-MmbId Member ID of the beneficiary’s Optional If completed, the field <Name> also has to
(CreditorAgentMemberIn- bank be completed
dentification)
CdtrAgt-Nm Name of the beneficiary’s bank Mandatory if Max. 35 characters
(CreditorAgentName) <CdtrAgt>-<BIC> is not
filled
CdtrAgt-Ctry Country of the beneficiary’s bank Mandatory if Country code ISO 3166; DE for Germany
(CreditorAgentCountry) <CdtrAgt>-<BIC> is not
filled
Cdtr-Nm Name of beneficiary Mandatory field Max. 70 characters, comprised of the fol-
(CreditorName) lowing fields Cdtr-Nm and Cdtr-PstlAdr,
shortened to 140 characters in the target
format
Cdtr-PstlAdr-Ctry Country of beneficiary’s address Mandatory field Country code ISO 3166; DE for Germany
(CreditorCountry)
Cdtr-PstlAdr-AdrLine Address of the beneficiary Optional Max. 2 × 70 characters (alternatively,
(CreditorAdress) structured address lines such as StrNM and
TwnNm can be used, 140 characters total).
Field is imported into T10b
CdtrAcct-IBAN IBAN of the beneficiary Mandatory field if <IBAN> Max. 34 characters
(CreditorIBAN) is not filled
CdtrAcct-Id Identification of the beneficiary Mandatory field if <IBAN> Max. 34 characters
(CreditorId) is not filled
InstrForCdtrAgt-InstrInf UETR for gpi Optional 36-character UETR based on the Univer-
(InstructionForCreditor- sally Unique Identifier (UUID) standard.
AgentInstractionInform- Structured as per RFC 4122 Version 4
ation)
InstrForDbtrAgt Instruction for value date and Optional Max. 25 characters
(InstructionForDebtor fax If the field CdtTrfTxInf/IntrmyAgt1/
Agent) FinInstnId/BIC has been completed, 14
characters may be assigned with the
following values:
• Value date “S/H DD.MM.YY”
• Fax “FAX NO. 12345”
RmtInfUstrd Unstructured remittance Optional Max. 140 characters
(RemittanceInformation instruction The first 35 characters are for end-to-end
Unstructured) information
RmtInfStrd Structured remittance infor- Optional Max. 140 characters
(RemittanceInformation mation Only if no unstructured The first 35 characters are for end-to-end
Structured) remittance instructions information.
provided Structured data is imported without ele-
ment names with a space in between
71
14.2 New Version for 2022 (pain.001.001.09)
(Cross-border credit transfers)
Fiel Name Description pain.001.001.09 Entry DFÜ-Agreement Annex 3 – Version 3.5
GrpHdr GroupHeader Sender Data 1 x per logical file
MsgId Initiating party reference num- Mandatory (to be unique) Max. 35 characters
(Message-ID) ber per file
CreDtTm Date/time when a file is created Mandatory ISO DateTime
(CreationDateTime)
Always specify local time plus time zone
difference (UTC) (Germany: +01:00 (CET) or
+ 02:00 (CEST = summer time)).
NbOfTxs Number of individual transac- Mandatory Max. 35 numeric characters
(NumberOfTransactions) tions
CtrlSum Control sum of submission Recommended Decimal number, max. 3 decimal places
InitgPty Initiating party Mandatory Name of the initiating party (may be differ-
(InitiatingParty) ent from name of ordering party)
PmtInf PaymentInformation Ordering party data Any number of times
possible, max. 100
recommended
PmntInfId Reference for the presentation Mandatory Max. 35 characters
PmtMtd Payment instrument: Credit Mandatory “TRF” – Credit Transfer
(PaymentMethod) Transfer or cheque “CHK” – Cheque
BtchBookg Bulk/single booking Optional Initially only „false“ possible for single
(BatchBooking) bookings
NbOfTxs Number of individual transac- Optional Max. 35 numeric characters
(NumberOfTransactions) tions
CtrlSum Control sum of submission Mandatory Unlimited
ReqdExctnDt Requested execution date Mandatory ISO-Date, max. 15 days in the future. Dates
(RequestedExecutionDate) in the past are set to the next possible
working day. Specification with execution
time ReqdExctnDt-DtTm (DataTime) is not
filled.
Dbtr-Nm Name of the ordering party – Mandatory Max. 140 characters
(DebtorName) overwritten by the bank with the
account holder’s master data
Dbtr-PstlAdr Address of the ordering party, Optional Recommended to fill at least TwnNm and
(DebtorPostalAddress) overwritten by the bank with the Ctry
account holder’s master data Always to be submitted if cheque is used
Dbtr-Id Debtor Identification Optional See Chapter 10.09
(DebtorIdentification)
DbtrAcct-Id-IBAN IBAN of ordering party Mandatory Max. 34 characters
(DebtorAccountIBAN)
DbtrAcct-Ccy Currency used for ordering Optional
(DebtorAccountCurrency) party’s account
DbtrAgt-FinInstnId-BICFI BIC/SWIFT-Code of the ordering Mandatory HYVEDEMMXXX further identifiers see
(DebtorAgentBIC) party Chapter 10.8.2
UltmtDbtr-Nm Name of different ordering party Optional Max. 140 characters
(UltimateDebtorName)
UltmtDbtr-PstlAdr Adresse of different ordering Mandatory, if UltmtDb- Structured Address see Chapter 10.7.1. Rec-
(UltimateDebtorPostal party tr-Nm is used ommended to fill at least TwnNm and Ctry
Address)
UltmtDbtr-Id Identification of different order- Optional See Chapter 10.09
(UltimateDebtor-Id) ing party
CdtTrf– CreditTransfer-Transac- Transactions-Information Any number of times
TxInf tionInformation possible, max. 10.000
recommended
PmtId-InstrId Unique transaction reference of Optional Max. 35 characters
(PayentIdentification- payer for his credit institution
Instruction-Id)
72
Fiel Name Description pain.001.001.09 Entry DFÜ-Agreement Annex 3 – Version 3.5
PmtId-EndToEndId Unique transaction reference Mandatory Max. 35 characters Transferred to the first
(PaymentIdentification- of payer line of the remittance information of the
End2End-Id) target format19. If this field states “NOT-
PROVIDED“, no mapping takes place.
PmtId-UETR Unique transaction reference Optional See Chapter 10.15
(PaymentIdentification-
UETR)
PmtTpInf-InstrPrty Payment priority Optional „HIGH“ or „NORM“ – not used
(InstructionPriority)
PmtTpInf-Svclvl-Cd Service-Scheme Mandatory „SDVA“ – SameDayValue „URGP“ – Urgent-
(ServieLevelCode) Payment in Euro
„NURG“ – NonUrgent (Normal) It is recom-
mended to fill <ScLvl-Cd> on the individual
transaction level <CdTrfxInf>.
PmtTpInf-CtgyPurp-Cd File payment type CategoryPurpose is op- e.g „CORT“ – Trade Settlement Payment
(CategoryPurposeCode) tional, Code is mandatory oder „INTC“ – Intra company payment It
is recommended ti fill <CtgyPurp> on the
Amt-InstdAmt-Ccy Instructed amount and currency Recommended Amount and currency code, max.
(InstructedAmount) code 99.999.999,99 e.g. 100 USD
Amt-EqytAmt-Ccy Equivalent amount in currency Mandatory field if Amount and currency code, max.
(EquivalentAmount) of ordering party’s account <InstdAmt> is not filled 99.999.999,99 e.g. 88,24 EUR
Amt-EqvtAmt-CcyOfTrf Currency code, different from Mandatory field if Currency code e.g. USD
(EquivalentAmount- the currency used for the order- <InstdAmt> is not filled
CurrencyOfTransfer) ing party’s account
ChrgBr Fee allocation Mandatory „SHAR“ – fee sharing
(ChargeBearer) „DEBT“ – charges and expenses borne by
ordering party
„CRED“ – charges and expenses borne
by creditor If empty, the default value is
fee sharing. Instructions here apply to all
transactions.
ChequeInstruction Details of the issue of a cheque Optional This element group may only be used in
(ChqInstr) the case of cheques, i.e. PaymentMethod
= CHK.
IntermediaryAgent1 First intermediate bank Optional This element group may be used subject to
(IntrmyAgt1) bilateral agreement between the customer
and the bank, but only the <BICFI> element
is permitted. In the case of check payments
(i.e. PaymentMethod CHK), information is
generally not permitted.
IntermediaryAgent2 Second intermediate bank Optional This element group may be used subject to
(IntrmyAgt2) bilateral agreement between the customer
and the bank, but only the <BICFI> element
is permitted. In the case of an occupancy,
IntertermediaryAgent1 must also be
available. In the case of check payments
(i.e. PaymentMethod CHK), information is
generally not permitted.
CdtrAgt-FinInstId-BICFI BIC/SWIFT-Code of the benefi- Recommended 8 or. 11 characters Further Identifier see
(CreditorAgentBICFI) ciary’s bank Chapter 10.7.2
Cdtr-Nm Name of beneficiary Mandatory Max. 140 characters
(CreditorName)
Cdtr-PstlAdr Address of beneficiary Optional Recommended to fill at least TwnNm and
(CreditorPostalAddress) Ctry , see Chapter 10.6.1
Cdtr-Id Identification of beneficiary Optional See Chapter 10.9
(Creditor-Id)
CdtrAcct-Id-IBAN IBAN of the beneficiary Mandatory, if <Id> is not Max. 34 characters
(CreditorIBAN) filled
CdtrAcct-Id-Othr-Id Local account Mandatory, if IBAN is not See Chapter 10.7.1
(CreditorAccountOtherId) filled
UltmtCdtr-Nm Name of different beneficiary Optional Max. 140 characters
(UltimateCreditorName)
73
Field Name Discription pain.001.001.09 Entry CGI-MP/SWIFT gpi
UltmtCdtr-PstlAdr Addresse of different beneficiary Mandatory, if Ult- Structured address required: at least Twn-
(UltimateCreditorPostal- mtCdtr-Nm is used Nm and Ctry should be filled
Address)
UltmtCdtr-Id Identification of different Optional See Chapter 10.09
(UltimateCreditor-Id) beneficiary
InstrForCdtrAgt-InstrInf Instruction key Optional Max. 2x140 characters, instuction key with
(InstructionForCreditor- instructions CHQB with cheque numbers,
AgentInstraction Infor- HOLD payments, PHOB-TELB notify by
mation) telephone
InstrForDbtrAgt Indication for value date and fax Optional Max. 25 characters.
(InstructionFor- If the field CdtTrfTxInf/IntrmyAgt1/ FinIn-
DebtorAgent) stnId/BIC is filled, 14 characters may be
assigned with the following values:
• Valuta „S/H DD.MM.YY“
• Fax „FAX-NR 12345“
Purp-Cd File payment type Recommended ISO 20022 „ExternalPurposeCode-Liste“
(PurposeCode)
RgltryRptg Optional For certain recipient countries only
(RegulatoryReporting) (max. 10 x)
RmtInfUstrd Unstructured Remittance Optional Max. 140 Zeichen
(RemittanceInformation- Information
Unstructured)
RmtInfStrd Structured Remittance Optional; Only if not Max. 9.000 characters structured content.
(RemittanceInformation- Informatinon structured remittance See chapter 10.1.5
Structured) instructions provided
74
15 Electronic recall request/
camt.055
Under SEPA, camt.055 in ISO 20022 format has been defined New recall
for customer-initiated electronic recalls. The electronic recall
replaces the form customers previously faxed to the bank. A
recall process can already be invoked at the interbank level recall camt.055
using either camt.056 (Recall/Request for Cancellation) or
pacs.007 (Reversal). The electronic recall is solely intended
for STP processes. Entire bulks (PaymentInformation) or
specific transactions pertaining to a specific bulk can be
revoked. SEPA Direct Debit (SDD) SEPA Credit Transfer
pain.008 (SCT) pain.001
Call-back by fax
SCT files submitted using pain.001 can be revoked using

camt.055 up until they undergo interbank clearing. After
they have been cleared and up to 13 months days following
the entry, an automated recall request can be submitted to
the beneficiary’s bank or the beneficiary. In this case, the
beneficiary is required to consent to the recall.
SDD files submitted using pain.008 may be reversed

using camt.055 up until the due date. The amount will
automatically be credited back to the original debtor up to
five days following the due date (reversal).
• Cutoff time camt.055 SCT:

Execution date + 13 months, 5 p.m.
• Cutoff time camt.055 SDD:

Due date + 5 target days, 7 a.m.
75
Customer recall – camt.055: SCT
1a 2a 3a 4a 5a 6a
-10 Target days Submission Approval Debit entry Clearing Credit entry +10 Target days
pain.001 pacs.008
camt.055 can be Interbank:

sent to bank prior Beneficiary’s
camt.056/camt.029
to payment consent required
bzw. pacs.004-FOCR
Customer recall – camt.055: SDD
1b 2b 3b 4b 5b 6b
-10 Target days Submission Approval Clearing Credit and debit entries + 5 Target days
pain.008 pacs.003
camt.055 can be Interbank: Adjusting entry

sent to bank prior camt.056/ pacs.007
to payment Reversal
76
The time of submission is of importance for processing and tracking a camt.055:
Time of Status Action Customer camt.029
process
1a/b 6a/b The bank receives a recall request The camt.055 is held for up to ten target days. If The customer is given the interme-
(camt.055), but is unable to find a corre- the corresponding transfer (pain.001) or direct diate status UWFW.
sponding transfer (pain.001) or direct debit debit (pain.008) does not arrive within this time, The customer is given the negative
(pain.008) for the defined period. the camt.055 will be deactivated and notification status RJCR with the reason code
sent to the customer. NOOR.
2a/b The bank receives a camt.055 prior to the As soon as the pain.001 or pain.008 arrives, the Before arrival of the pain.001/008,
pertinent pain.001/ pain.008 (the recall file in question or the corresponding transaction the customer is given the
request arrives before the actual payment is rejected. intermediate status UWFW.
authorisation). The pertinent pain.001 or After arrival of the referenced file,
pain.008 is subsequently submitted within the customer is given the positive
a pre-defined period. status CNCL.
3a/b The bank can clearly assign the camt.055 The file or transaction is rejected. The customer is given the positive
it receives to a pain.001/pain.008 on the status CNCL.
basis of the references. The payment has
been forwarded as part of the interbank
clearing process but has yet to be
forwarded to an external bank.
4a The transfer has already been forwarded to The bank sends a request for cancellation to Depending on the response, the
the interbank clearing. the beneficiary bank. Depending on what the customer is given a positive or
beneficiary or beneficiary bank decides, either the negative status CNCL or RJCR with
transfer will be returned (pacs.004) or a negative the reason code from the negative
answer (camt.029). answer of the beneficiary bank.
4b The bank has already forwarded the The bank sends a request for cancellation to the In the case of direct debit, the cus-
assigned pain.008 to the interbank clearing clearing house or external bank (camt.056). The tomer is always given the positive
but the final entry has yet to be generated payment is rejected to the presenter. status CNCL.
on the beneficiary’s side.
5a The transfer has already been credited to The bank sends a camt.056 request for Depending on the response, the
the beneficiary’s account. The beneficiary’s cancellation to the beneficiary bank. Depending customer is given a positive or
consent is required. on what the beneficiary decides, either the negative status CNCL or RJCR with
transfer will be returned (pacs.004) or a negative the reason code from the negative
answer (camt.029). answer of the beneficiary bank.
5b The direct debit amount has already been The bank debits the amount from the creditor’s In the case of direct debit, the cus-
debited from the debtor’s account. account and sends a corrected credit note/rever- tomer is always given the positive
sal to the debtor’s bank. In turn, this bank will status CNCL.
arrange for the direct debit to be refunded.
6a/b After expiry of the cut-off date, the bank The bank rejects the camt.055. The customer After expiry of the waiting period,
will receive a camt.055 to ensure that the must attempt to organise the recall through the customer is given the negative
automated processing of recalls can be alternative means status RJCR with the reason code
performed to a uniform standard. During • Credit transfer (pain.001): NOOR.
the valid period, no assignable pain.001/ instruct a complaint or consulting with the
pain.008 will be found. beneficiary
• Direct debit (pain.008):
by credit transfer (pain.001)
Response to your recall request

A Bank-Customer-Message, camt.029, is planned for camt.055 according to ISO20022. If the Bank can identify the reference
file/transaction, one will receive a positive camt.029 immediately or within 10 bank working days before forwarding to the
beneficiary bank. After 10 bank working days, the recall will be set inactive and a negative camt.029 will be provided. A
camt.029, based on SCT recall request after booking by the beneficiary or the beneficiary’s bank, is done within the framework
of processes described in the SEPA Rulebooks.
77
Important notes on processing
• When requests are made to recall a direct debit (camt.055), the bank reserves the right to adjust the entry even if the
recipient bank has already adjusted the payment itself. Where recall procedures are concerned, it is not possible for the bank
to check in advance whether the debtor bank has already returned the payment.
• In the event that direct debits are reversed after their due date, the presenter will arrange for the payment to be credited
back to the debtor’s account using camt.055 (recall).
• If the debtor has already arranged for the payment to be returned, there is a possibility that two debit transactions will
be posted on the presenter’s account (one through the recall and one through the return). Although banks strive to avoid
this situation occurring by performing various checks, the possibility of a double debit entry occurring cannot be ruled
out. Requests for an electronic recall are always processed by the bank within ten target days. If the payment referenced in
camt.055 is not immediately traced, the bank assumes that the camt.055 was received prior to payment and withholds the
recall request for ten target days. After ten days, the recall request is deactivated and the customer notified.
In order to automatically process the camt.055 (STP), the original file must be clearly identified in the camt.055. Additional
fields, such as the mandate signature date or the address, which, whilst permissible under the ISO scheme (XSD) but not offered
by banks, are ignored when mapping. If the same identification criteria repeatedly find files or corresponding transactions, either
the file or the transaction is recalled depending on which is the easiest to recall. A transaction recall recalls one transaction at
the most even if the criteria are given for several transactions. If two transactions of the same type are recalled, two camt.055
transactions are equally needed. The same applies if files are recalled.
The following fields are of relevance to the mapping process:

File recall (recall on the PaymentInf level)
pain message camt.055 Mapping
Message-Id OrgnlMsgId Mandatory
Message type CT/DD OrgnlMsgNmId „pain.001“ oder „pain.008“ Pflicht
PaymentInf-Id OrgnlPmtInfId Mandatory
IBAN of ordering party (SDD creditor, SCT debtor) Undrlyg/OrgnlPmtInfAndCxl/Case/Pty/Id/OrgId/Othr/Id Mandatory
Number of transactions in PaymentInf NbOfTxs
Mandatory20
Amount in PaymentInf CtrlSum
20
Optional fields in original message; if used in the original message, these must also be specified in the camt.055 for mapping purposes
78
Transaction recall
pain-Nachricht camt.055 Mapping SCT Mapping SDD
Message-Id OrgnlMsgId Mandatory
Message type CT/DD OrgnlMsgNmId “pain.001” mandatory “pain.008” mandatory
PaymentInf-Id OrgnlPmtInfId Mandatory
IBAN of ordering party Undrlyg/OrgnlPmtInfAndCxl/Case/Pty/Id/OrgId/
Mandatory
(SDD creditor, SCT debtor) Othr/Id
Number of transactions in PaymentInf NbOfTxs
Mandatory21
Amount in PaymentInf CtrlSum
Transaktionsdetails SCT SDD
Amount stated in transaction OrgnlInstdAmt Mandatory
Instruction-Id OrgnlInstrId Mandatory21
End-to-End Id OrgnlEndToEndId Mandatory
Mandate-Id MndtId – Mandatory
Contra account (CT creditor) CdtrAcct-IBAN Mandatory –
Contra account (SDD debtor) DbtrAcct-IBAN – Mandatory
Execution date OrgnlReqdExctnDt Mandatory –
Due date OrgnlReqdColltnDt – Mandatory
Remittance information Ustrd bzw. Strd Not recommended. If specified, then 1:1 mapping
Reasons for recall

The following reasons can be used for prompting a recall:
• DUPL – Duplicate Payment
• TECH – Technical Problem
• CUST – Customer Decision
The following reasons can be applied for recalling credit transfers:

• AC03 – Incorrect recipient IBAN
• AM09 – Incorrect amount
• CUST – Other customer reasons
• The reason for the recall can be specified in the field AdditionalInformation
The previous reasons TECH/DUPL will be converted to CUST.
If no reason for the recall is used, the standard CUST is assigned.
Limitations of electronic recall requests

Electronic recall requests using camt.055 can only be made for orders in SEPA files. Paper-based transfers or urgent transfers as
well as SEPA Cards Clearing payments cannot currently be recalled using camt.055. At present, only camt.055 is accepted via
the EBICS channel or via SWIFTNet FileAct.
Type of order and XSD of camt.055

• Format version: camt.055.001.05
• XSD ISO 20022: iso20022.org
• EBICS order type: C55
21
Optional fields in original message; if used in the original message, these must also be specified in the camt.055 for mapping purposes
79
Important format specification camt.055
Field name Entries Description
Assgnmt + Assignment [1..1]
++ Identification [1..1] Message reference for the recall message
<Id>
++ Assigner [1..1]
<Assgnr>
+++ Party [1..1]
<Pty>
++++ Name [0..1] Presenter of the recall
<Nm> (mandatory)
++++ Identification [0..1]
<Id>
+++++ OrganisationIdentification [1..1] or
<OrgId> PrvtId
++++++ Other [0..*]
<Othr>
+++++++ Identification [1..1] e. g. Customer ID
<Id> (optional field group)
++ Assignee [1..1]
<Assgne>
+++ Agent [1..1]
<Agt>
++++ FinancialInstitutionIdentification [1..1]
<FinInstnId>
+++++ BICFI [0..1] BIC of the commissioned submitter bank
<BICFI>
++ CreationDateTime [1..1] Date/time that the recall message was drafted
<CreDtTm>
Undrlyg + Underlying [0..*] Only 1 occurrence permissible,
i. e. DK cardinality is [1..1]
++ OriginalPaymentInformationAndCancellation [0..*] Recall data on the PaymentInf level
<OrgnlPmtInfAndCxl> (mandatory group)
May only be used once per message according to DK
+++ Case [0..1] Account holder data
<Case> (mandatory group)
++++ Identification [1..1] Recall reference
<Id> (mandatory)
++++ Creator [1..1]
<Cretr>
+++++ Party [1..1]
<Pty>
++++++ Name [0..1] Account holder presenter
<Nm>
++++++ Identification [0..1] Mandatory group due to IBAN
<Id>
+++++++ OrganisationIdentification [1..1] or
<OrgId> PrvtId
++++++++ AnyBIC [0..1]
<AnyBIC>
++++++++ Other [0..*]
<Othr>
+++++++++ Identification [1..1] IBAN of account holder for mapping
<Id> (mandatory)
+++ OriginalPaymentInformationIdentification [1..1] Original payment information Id for mapping
<OrgnlPmtInfId> (mandatory)
+++ OriginalGroupInformation [0..1] Reference to original message
<OrgnlGrpInf> (mandatory group)
++++ OriginalMessageIdentification [1..1] Original message Id for mapping
<OrgnlMsgId> (mandatory)
80
++++ OriginalMessageNameIdentification [1..1] Original message type to distinguish between CT
<OrgnlMsgNmId> or SDD for mapping
• pain.001
• pain.008 oder
• optionally: use version number pain.001.003.03
(version number not for mapping)
+++ NumberOfTransactions [0..1] Original number of transactions in the logical file
<NbOfTxs> (bulk);
mandatory if used in the original message
+++ ControlSum [0..1] Original sum in the logical file (bulk);
<CtrlSum> mandatory if used in original message
+++ PaymentInformationCancellation [0..1] Mandatory
<PmtInfCxl> • true: recall entire payment information bulk
(= logical file) (no transaction details)
• false: recall specific transactions (transaction
details mandatory)
+++ CancellationReasonInformation [0..1] Only when <PmtInfCxl> true; if not specified, stand-
<CxlRsnInf> ard “CUST” for SDD or “TECH” for SCT
++++ Reason [0..1]
<Rsn>
+++++ Code [1..1] • SDD code: CUST, TECH or DUPL
<Cd> or • SCT code: CUST or Prtry – AC03 or AM09
<Prtry>
+++++ AdditionalInformation <AddtlInf> [0..1] Additional recall status information
If transaction recalled:
+++ TransactionInformation [0..*] only false in the case of <PmtInfCxl>
<TxInf>
++++ OriginalInstructionIdentification [0..1] Original instruction Id
<OrgnlInstrId> (mandatory if used in original message)
++++ OriginalEndToEndIdentification [0..1] Original end-to-end reference
<OrgnlEndToEndId> (mandatory for mapping)
++++ OriginalInstructedAmount [0..1] Original sum
<OrgnlInstdAmt> (mandatory for transaction recall)
++++ OriginalRequestedExecutionDate [0..1] Original execution date in the case of SCT
<OrgnlReqdExctnDt> (mandatory for mapping)
++++ OriginalRequestedCollectionDate [0..1] Original execution date in the case of SDD
<OrgnlReqdColltnDt> (mandatory for mapping)
++++ CancellationReasonInformation [0..*] If not specified, standard “CUST” for SDD or “TECH”
<CxlRsnInf> for SCT
+++++ Reason [0..1]
<Rsn>
++++++ Code [1..1] • SDD code: CUST, TECH or DUPL
<Cd> or • SCT dode: CUSTor Prtry – AC03 or AM09
<Prtry>
++++ OriginalTransactionReference [0..1]
<OrgnlTxRef>
+++++ MandateRelatedInformation <MndtRltdInf> [0..1]
++++++ MandateIdentification <MndtId> [0..1] Original mandate reference (in the case of SDD,
mandatory for transaction recall)
+++++ RemittanceInformation <RmtInf> [0..1]
++++++ Unstructured [0..1] No more than 140 digits; if specified, then
<Ustrd> mapping
++++++ Structured [0..1] Structured remittance information; if specified,
<Strd> then mapping
+++++++ CreditorReferenceInformation [0..1]
<CdtrRefInf>
++++++++ Type [0..1]
<Tp>
+++++++++ CodeOrProprietary [1..1]
<CdOrPrtry>
81
++++++++++ Code [1..1] SCOR code (only to be completed if structured
<Cd> remittance information is used)
+++++++++ Issuer [0..1] Issuer
<Issr>
++++++++ Reference [0..1] Structured remittance information
<Ref>
+++++ Debtor [0..1] Original debtor
<Dbtr> (only SDD)
++++++ Name [0..1] Debtor name of original SDD transaction
<Nm>
+++++ DebtorAccount [0..1] Contra account for SDD
<DbtrAcct>
++++++ Identification [1..1]
<Id>
+++++++ IBAN [1..1] IBAN contra account (in the case of SDD, manda-
<IBAN> tory for transaction recall)
+++++ Creditor [0..1] Original Creditor (only SCT)
<Cdtr>
++++++ Name [0..1] Creditor name of original SCT transaction
<Nm>
+++++ CreditorAccount [0..1] Contra account for SCT
<CdtrAcct>
++++++ Identification [1..1]
<Id>
+++++++ IBAN [1..1] IBAN contra account (in the case of SCT,
<IBAN> mandatory for transaction recall)
82
Example of file recall
<Assgnmt>
    <Id>Recall-Nachricht-1234</Id>
    <Assgnr>
        <Pty>
            <Nm>Müller AG</Nm>
        </Pty>
    </Assgnr>
    <Assgne>
        <Agt>
                <BICFI>HYVEDEMMXXX</BICFI>
        </Agt>
    </Assgne>
    <CreDtTm>2015-11T10:01:12</CreDtTm>
</Assgnmt>
<Undrlyg>
    <OrgnlPmtInfAndCxl>
        <Case>
            <Id>Recall-Referenz-1234556</Id>
            <Cretr>
                <Pty>
                    <Id>
                        <OrgId>
                            <Othr>
                                <Id>DE2140700202700012345678</Id>
                            </Othr>
                        </OrgId>
                    </Id>
                </Pty>
            </Cretr>
        </Case>
        <OrgnlPmtInfId>SCT-Bulk123</OrgnlPmtInfId>
        <OrgnlGrpInf>
            <OrgnlMsgId>SCT-Message987</OrgnlMsgId>
            <OrgnlMsgNmId>pain.001</OrgnlMsgNmId>
        </OrgnlGrpInf>
        <NbOfTxs>100</NbOfTxs>
        <CtrlSum>100.12</CtrlSum>
        <PmtInfCxl>true</PmtInfCxl>
        <CxlRsnInf>
            <Rsn>
                <Cd>CUST</Cd>
            </Rsn>
        </CxlRsnInf>
    </OrgnlPmtInfAndCxl>
</Undrlyg>
83
Example of transaction recall
<Assgnmt>
    <Id>Recall-Nachricht-1234</Id>
    <Assgnr>
        <Pty>
            <Nm>Müller AG</Nm>
        </Pty>
    </Assgnr>
    <Assgne>
        <Agt>
                <BICFI>HYVEDEMMXXX</BICFI>
        </Agt>
    </Assgne>
    <CreDtTm>2015-11T10:01:12</CreDtTm>
</Assgnmt>
<Undrlyg>
    <OrgnlPmtInfAndCxl>
        <Case>
            <Id>Recall-Referenz-1234556</Id>
            <Cretr>
                <Pty>
                    <Id>
                        <OrgId>
                            <Othr>
                                <Id>DE2140700202700012345678</Id>
                            </Othr>
                        </OrgId>
                    </Id>
                </Pty>
            </Cretr>
        </Case>
        <OrgnlPmtInfId>SCT-Bulk123</OrgnlPmtInfId>
        <OrgnlGrpInf>
            <OrgnlMsgId>SCT-Message987</OrgnlMsgId>
            <OrgnlMsgNmId>pain.001</OrgnlMsgNmId>
        </OrgnlGrpInf>
        <NbOfTxs>100</NbOfTxs>
        <CtrlSum>100.12</CtrlSum>
        <PmtInfCxl>false</PmtInfCxl>
        <TxInf>
            <OrgnlInstrId>1234567890</OrgnlInstrId>
            <OrgnlEndToEndId>OriginatorID1234</OrgniEndToEndId>
            <OrgnlInstdAmt Ccy=“EUR“>1234.56</OrgnlInstdAmt>
            <CxlRsnInf>
                <Rsn>
                    <Cd>CUST</Cd>
                </Rsn>
            </CxlRsnInf>
        </TxInf>
    </OrgnlPmtInfAndCxl>
</Undrlyg>
84
Disclaimer are a Qualified Investor for the purposes of the directive or any relevant
This publication is presented to you by: implementing legislation of a European Economic Area (“EEA”) Member
State which has implemented the Prospectus Directive and it must not be
UniCredit Bank AG, Arabellastr. 12, 81925 Munich, GERMANY
given to any person who is not a Qualified Investor. By being in receipt of
The information in this publication is based on carefully selected sources this publication you undertake that you will only offer or sell the securities
believed to be reliable. However we do not make any representation as to described in this publication in circumstances which do not require the
its accuracy or completeness. Any opinions herein reflect our judgement at production of a prospectus under Article 3 of the Prospectus Directive or
the date hereof and are subject to change without notice. Any investments any relevant implementing legislation of an EEA Member State which has
presented in this report may be unsuitable for the investor depending implemented the Prospectus Directive.
on his or her specific investment objectives and financial position. Any
Note to US Residents:
reports provided herein are provided for general information purposes
only and cannot substitute the obtaining of independent financial advice. The information provided herein or contained in any report provided
Private investors should obtain the advice of their banker/broker about any herein is intended solely for institutional clients of Corporate & Investment
investments concerned prior to making them. Nothing in this publication is Banking of UniCredit acting through UniCredit Bank AG, New York Branch
intended to create contractual obligations. Corporate & Investment Banking and UniCredit Capital Markets LLC (together “UniCredit”) in the United
of UniCredit consists of UniCredit Bank AG, Munich, UniCredit Bank Austria States, and may not be used or relied upon by any other person for any
AG, Vienna, UniCredit S.p.A., Rome and other members of the UniCredit. purpose. It does not constitute a solicitation to buy or an offer to sell any
UniCredit Bank AG is regulated by the German Financial Supervisory securities under the Securities Act of 1933, as amended, or under any other
Authority (BaFin), UniCredit Bank Austria AG is regulated by the Austrian US federal or state securities laws, rules or regulations. Investments in
Financial Market Authority (FMA) and UniCredit S.p.A. is regulated by both securities discussed herein may be unsuitable for investors, depending on
the Banca d‘Italia and the Commissione Nazionale per le Società e la Borsa their specific investment objectives, risk tolerance and financial position.
(CONSOB). In jurisdictions where UniCredit is not registered or licensed to trade in
Note to UK Residents: securities, commodities or other financial products, any transaction may
be effected only in accordance with applicable laws and legislation, which
In the United Kingdom, this publication is being communicated on a
may vary from jurisdiction to jurisdiction and may require that a transaction
confidential basis only to clients of Corporate & Investment Banking of
be made in accordance with applicable exemptions from registration or
UniCredit Group (acting through UniCredit Bank AG, London Branch) who
licensing requirements.
(i) have professional experience in matters relating to investments being
investment professionals as defined in Article 19(5) of the Financial Services All information contained herein is based on carefully selected sources
and Markets Act 2000 (Financial Promotion) Order 2005 (“FPO”); and/or believed to be reliable, but UniCredit makes no representations as to its
(ii) are falling within Article 49(2) (a) – (d) (“high net worth companies, accuracy or completeness. Any opinions contained herein reflect UniCredit‘s
unincorporated associations etc.”) of the FPO (or, to the extent that this judgement as of the original date of publication, without regard to the date
publication relates to an unregulated collective scheme, to professional on which you may receive such information, and are subject to change
investors as defined in Article 14(5) of the Financial Services and Markets without notice.
Act 2000 (Promotion of Collective Investment Schemes) (Exemptions) UniCredit may have issued other reports that are inconsistent with, and
Order 2001 and/or (iii) to whom it may be lawful to communicate it, other reach different conclusions from, the information presented in any report
than private investors (all such persons being referred to as “Relevant provided herein. Those reports reflect the different assumptions, views and
Persons”). This publication is only directed at Relevant Persons and any analytical methods of the analysts who prepared them. Past performance
investment or investment activity to which this publication relates is only should not be taken as an indication or guarantee of further performance,
available to Relevant Persons or will be engaged in only with Relevant and no representation or warranty, express or implied, is made regarding
Persons. Solicitations resulting from this publication will only be responded future performance.
to if the person concerned is a Relevant Person. Other persons should not UniCredit and/or any other entity of Corporate & Investment Banking of
rely or act upon this publication or any of its contents. UniCredit may from time to time, with respect to any securities discussed
The information provided herein (including any report set out herein) herein: (i) take a long or short position and buy or sell such securities; (ii) act
does not constitute a solicitation to buy or an offer to sell any securities. as investment and/or commercial bankers for issuers of such securities; (iii)
The information in this publication is based on carefully selected sources be represented on the board of such issuers; (iv) engage in “market-making”
believed to be reliable but we do not make any representation as to its of such securities; and (v) act as a paid consultant or adviser to any issuer.
accuracy or completeness. Any opinions herein reflect our judgement at the The information contained in any report provided herein may include
date hereof and are subject to change without notice. forward-looking statements within the meaning of US federal securities
We and/or any other entity of Corporate & Investment Banking of UniCredit laws that are subject to risks and uncertainties. Factors that could cause
may from time to time with respect to securities mentioned in this a company‘s actual results and financial condition to differ from its
publication (i) take a long or short position and buy or sell such securities; expectations include, without limitation: Political uncertainty, changes
(ii) act as investment bankers and/or commercial bankers for issuers of such in economic conditions that adversely affect the level of demand for the
securities; (iii) be represented on the board of any issuers of such securities; company‘s products or services, changes in foreign exchange markets,
(iv) engage in “market making” of such securities; (v) have a consulting changes in international and domestic financial markets, competitive
relationship with any issuer. Any investments discussed or recommended environments and other factors relating to the foregoing. All forward-
in any report provided herein may be unsuitable for investors depending on looking statements contained in this report are qualified in their entirety by
their specific investment objectives and financial position. Any information this cautionary statement.
provided herein is provided for general information purposes only and
cannot substitute the obtaining of independent financial advice.
UniCredit Bank AG, Munich
UniCredit Bank AG, London Branch is regulated by the Financial Services
as of August, 2021
Authority for the conduct of business in the UK as well as by BaFIN, Germany.
Notwithstanding the above, if this publication relates to securities subject
to the Prospectus Directive (2005) it is sent to you on the basis that you
85
Effective 11.2020
UniCredit Bank AG
Global Transaction Banking
Arabellastraße 12
81925 München
E-Mail
[email protected]
International Business Dossiers

https://dossiers.hypovereinsbank.de/
international-business.html
Internet
gtb.unicredit.eu
Alle Angaben beruhen auf der bei Drucklegung geltenden Gesetzes- und Rechtslage.

ZV Formate en

Uploaded by

Copyright:

Available Formats

ZV Formate en

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ZV Formate en

Uploaded by

Copyright:

Available Formats

Payment transactions

2 Relation between customer and bank formats

9 SEPA Direct Debit (SDD) 24 15 Electronic recall request/camt.055 75

10 Usual payment information 28

Submission and Reporting

Payment order Error information

pain = payment initiation pain = payment initiation error messages

camt (cash management)

November 2021 (DFÜ Agreement Appendix 3 – Version 3.5)

November 2017 (DFÜ Agreement Appendix 3 – Version 3.1)

26 June 2017 (Regulation (EU) 2015/847 on Transfer of Funds)

November 2016 (DFÜ Agreement Annex 3 – Version 3.0)

November 2015 (DFÜ Agreement Annex 3 – Version 2.9)

November 2014 (DFÜ Agreement Annex 3 – Version 2.8)

November 2013 (DFÜ Agreement Annex 3 – Version 2.7)

November 2012 (DFÜ Agreement Annex 3 – Version 2.6)

November 2010 (DFÜ Agreement Annex 3 – Version 2.5)

November 2009 (DFÜ Agreement Annex 3 – Version 2.4)

January 2008 (DFÜ Agreement Annex 3 – Version 2.2)

New ISO 20022 standard: Introduction of new camt versions

Therefore it is recommended to switch to the new ISO version.

New business transaction and return codes

Cross boarder payments receive differentiated sub-families:

Changes to the domain for business code 809:

New version pain.001 for Instant Payments

The introduction of the new format (pain.001.001.09) opens new possibilities:

Specification for the submission of international transfer order in

Outlook on format evolution

Structure of an XML message designation:

ISO Name Version As of Supported by UniCredit

pain.001.001.09 DK Version 3.5 for instant credit transfers 2021

SEPA Credit Transfer Order Types – DK format

Credit Transfer with XML pain.001

Service requires customer administration

SEPA Direct Debit Order Types

SEPA Direct Debit

DK 2.6 (2012) Only Header/PaymInf

DK XML-Container: EBICS-order type CCC EBICS-Auftragsart CCT (mixed)

PaymentInformation – Debtor: Account-2

pain.001, GroupHeader, InitiatingParty Company name-1 EBICS-Auftragsart CCT (mixed)

SEPA files are submitted as bulks, so that files have to be created

Checks for duplicate file processing

• Payment reference ID only on submission via data processing service centres

Instant Payments characteristics

Important functional XML fields for SEPA Credit Transfer

7.1 SEPA instant payments with pain.001.001.09

PaymentInformation – logical file Description

CreditTransferTransactionInformation – individual transaction Description

Important functional XML fields for SEPA Direct Debit

10.1.2 Structuring through code words defined by EACT in unstructured

Examples of use in accordance with the EACT Standard:

(RFB = Reference for Beneficiary)

(RFS = Reference secured with check digits)

(CNR = Customer Number, DOC = Document reference)

/CNR/876543/ indicates the customer number 876543

10.1.3 Employee savings’ plans (VL benefits)

10.1.4 Structured RemittanceInformation <RmtInf> <Strd>

Forms Period Certification Tax Amount

10.2 Purpose Code

9 SEPA Direct Debit (SDD) 24 15 Electronic recall request/camt.055 75

10 Usual payment information 28

Your prior balance EUR 90,000.00+

17.11. SEPA-ÜBERWEISUNGSDATEI 10.00-

Your current balance EUR 89,990.00+

Your prior balance EUR 90,000.00+

17.11. SEPA-ÜBERWEISUNGSDATEI 5.00-

17.11. SEPA-ÜBERWEISUNGSDATEI 5.00-

Your current balance EUR 89,990.00+