0 - EBA STEP2 MPEDD Interface Specification v20091102 - Updated 091127 Clean Version

STEP2 – Multi Purpose Direct Debits
Core Service and B2B Service
Interface Specifications
Compliant with
Core Rulebook 3.3

B2B Rulebook 1.2
This document is confidential within the institutions which have received them from
EBA CLEARING
Version: 27th November 2009

STEP2 – M-PEDD
27th November 2009
STEP2 SEPA Debit Services Interface Specifications
HISTORY OF MODIFICATIONS
Version 2.3:
• Version number aligned with EPC rulebook V 2.3

• Updated introductory remarks
• Clarified DRR and MSR sections (2.3.8)
• Removed redundant paragraph in section 3.1
• Added Iso Date and Time in Table 4-1
• Section A.4 replaced person by entity
• Format for File Reference is 16!c for all files
• No space character allowed in any MsgId
• Clarified validation rule for Interbank Settlement Date in pacs 003
• Clarified use of LocalIsntrument (AOS)
• Removed mention of BE04 error code (not SEPA)
• Added SL01 error code
• Corrected SWIFTNet paramaters in appendix H
• Corrected date format in section 3.6.4
th
Version 20091102 - 24 October 2008
• Inserted Reports Mapping Table

• Removed EURO1 references
• Clarified B02 error code in appendix E
• Clarifified validation on SEPA country code in IBAN
• Removed word Credeuro in the document for legal reasons
• Corrected column order “admission profile” and “status” in the routing table
• Format for sender's file reference is aligned on format in reports (16!c) and not 35x.
• Clarified names of error code XT81 (Only SEPA core fields are allowed) and XT82 (DMF
Related Error)
• Added SL01 error code (Specific Service offered by Debtor Bank ) at bulk level.
• Aligned transaction level error code MD02 with the schema
• Format for Proprietary Id is aligned on format in schemas (35x) and is not 4!a2!a2!c[3!c]
• Corrected appendix J.8 to refer to IDF Error Code (IdfErrCd) and not File Reject Reason
(FileRjctRsn)
• Corrected tag TxtInfAndSt<StsRsnInf<Cd into TxtInfAndSt<StsRsnInf<StsRsn<Cd
• Corrected tag TxtInfAndSt<StsRsnInf<Prtry into TxtInfAndSt<StsRsnInf<StsRsn<Prtry
• Added error code XD75 and XT77 in appendix F error code list
• Corrected ruleBook reference for original settlement amount changed into AT-06 and
reference for Compensation Amount to R6.
• Added updates for EPC rulebooks.
• Removed Data compression.
th
Version 20091102 - 10 February 2009
List of corrections detailed in the “Errata” document.
th
Version 20091102 - 17 April 2009
List of corrections detailed in the “Errata” document. V2.0
rd
Version 20091102 - 03 September 2009
List of corrections detailed in the “Errata” document. V2.3
th
Version 20091102 - 27 November 2009
DRR header description corrected
STEP2 CS BIC in Report files header corrected
ED05 reason code in pacs.002S2
Duplicate Checks for file
More details on PSR generation - par. F.1, F.1.3 F.1.5
Clarifications on RTF fields - par. H.6 H.7
Version 20091102 (Core RB3.3 and B2B 1.2) 2 of 176
STEP2 – M-PEDD
27th November 2009
Clarifications on MSR sending to participant . Par. 2.3.8.2

STEP2 – M-PEDD
27th November 2009
INTRODUCTORY REMARKS
The STEP2 SEPA Direct Debit Interface specifications are designed to be read in conjunction with the
MPEDD Functional Description that describes the general processing overview of the service. Part of the
specifications documentation includes the XML Technical Validation Subset (TVS) a tool that allows banks to
generate ISO and rulebook compliant XML instructions.
These specifications are considered complete according to the version of the Implementation Guidelines
th
versions dated 26 June 2008. Furthermore it is anticipated that the EPC will publish their own TVS
(Technical Validation Subset) and that all industry bodies must be in line.
The STEP2 Multi Purpose Direct Debit Services will support Core/B2B and Basic SEPA Direct Debits. These
consist only of the fields shaded yellow in this document. In using this service banks will agree to only use
the yellow shaded fields. As the rulebook develops, and communities request other services that go beyond
the core/B2B and basic service STEP2 may use these fields to support other services.

STEP2 – M-PEDD
27th November 2009
REFERENCES
The following documents provide additional information on the STEP2 Debit Services.
Title Issued By
[1] STEP2 MPEDD Functional Description EBA CLEARING
[2] SEPA CORE Direct Debit Scheme Rulebook EPC
[3] SEPA CORE Direct Debit Scheme Interbank implementation Guidelines EPC
[4] SEPA B2B Direct Debit Scheme Rulebook EPC
[5] SEPA B2B Direct Debit Scheme Interbank Implementation Guidelines EPC
[6] ISO2002 Specifications ISO

STEP2 – M-PEDD
27th November 2009
CONTENTS
1. INTRODUCTION ................................................................................................................... 15
1.1 SEPA Direct Debit requirements .................................................................................... 15
1.2 STEP2 Core and B2B Services ....................................................................................... 15
1.3 Glossary ....................................................................................................................... 16
2. THE STEP2 SYSTEM ............................................................................................................ 19
2.1 Overview ....................................................................................................................... 19
2.2 Connecting to STEP2 as a Direct Participant .................................................................. 21
2.2.1 Connecting to STEP2 via a STEP2-enabled payment system ........................................22
2.3 STEP2 MPEDD Filetypes ................................................................................................ 23
2.3.1 Input Debit File (IDF) ..................................................................................................23
2.3.2 Debit Validation File (DVF) ..........................................................................................23
2.3.3 Debit Notification File (DNF) ........................................................................................23
2.3.4 Pre-Settlement Report (PSR) ......................................................................................23
2.3.5 Response to Settlement File (RSF) ..............................................................................24
2.3.6 Settled Debit File (SDF) ..............................................................................................24
2.3.7 Cancelled Debit File (CDF)..........................................................................................25
2.3.8 Reconciliation and statistical reports ............................................................................25
2.3.8.1 Daily Reconciliation Report (DRR) .................................................................25
2.3.8.2 Monthly Statistical Report (MSR) ...................................................................25
2.3.8.3 Multilateral Balancing Payments Report (MBP) ..............................................25
2.3.8.4 Routing table file Report (RTF) ......................................................................25
3. STEP2 FILE EXCHANGE FUNDAMENTALS ........................................................................... 26
3.1 Sending and Validation windows ................................................................................... 26
3.2 File exchange security ................................................................................................... 26
3.3 Push mode .................................................................................................................... 26
3.4 File formats, naming conventions, and format versioning .............................................. 26
3.4.1 File Naming Conventions ............................................................................................26
3.4.1.1 Network File Names .....................................................................................27
3.4.1.2 Sender’s File Reference (SFR)......................................................................28
3.5 File format and bulks ..................................................................................................... 29
3.6 XML Schemas ............................................................................................................... 29
3.7 Validation of Input Debit Files ........................................................................................ 30
3.8 STEP2 Message Routing ............................................................................................... 30
3.8.1 Indirect Participant routing ...........................................................................................30
3.9 Retransmission of output files ....................................................................................... 31
3.10 Sample File, message and bulks diagrams ..................................................................... 32
4. HOW TO USE THE APPENDICES .......................................................................................... 34
APPENDIX A FILES, BULKS AND MESSAGES........................................................................... 35
A.1 STEP2 MPEDD BULK TYPES ......................................................................................... 35
A.1.1 IDF Bulk messages .....................................................................................................35
A.1.2 DVF Bulk messages .....................................................................................................35
A.1.3 DNF Bulk messages ....................................................................................................35
A.1.4 RSF Bulk messages .....................................................................................................35
A.1.5 SDF Bulk messages .....................................................................................................36
A.1.6 CDF Bulk messages .....................................................................................................36
A.1.7 IDF Multiple Bulks and restrictions ...............................................................................36
A.2 File Content Encoding .................................................................................................. 36
A.3 Usage of Instructed and Instructing Agents ............................................................... 37
STEP2 – M-PEDD
27th November 2009
A.4 Duplicate Checking ...................................................................................................... 38

A.5 BIC Validation .............................................................................................................. 40
A.5.1 R-Messages ................................................................................................................40
A.6 Creditor Scheme Identification format ........................................................................ 41
A.7 Message ID .................................................................................................................. 41
A.8 Validation process of R-messages against direct debits ............................................. 42
A.9 Validation of Original Message Id................................................................................ 44
A.10 Bulking R-messages ................................................................................................ 44
A.11 Bulk Rejection actions............................................................................................. 44
A.12 R-Message conflicts ................................................................................................ 45
APPENDIX B TABLE STEP2 FILE HEADERS ............................................................................. 46
B.1 Input Debit File STEP2 File Header .............................................................................. 46
B.2 Debit Validation File STEP2 File Header ...................................................................... 46
B.3 Debit Notification File STEP2 File Header .................................................................... 47
B.4 Response to Settlement File STEP2 File Header .......................................................... 48
B.5 Settled Debit File (SDF) STEP2 File Header ................................................................. 48
B.6 Cancelled Debits File (CDF) STEP2 File Header ........................................................... 48
APPENDIX C STEP2 USAGE OF XML MESSAGES ..................................................................... 50
C.1 STEP2 Usage of PACS.003: Financial Institution to Financial Institution Customer
Direct Debit .................................................................................................................. 50
C.1.1 PACS.003 (Debit Collection) used in IDF and DNF – Group Header.................................50
C.1.2 PACS.003 (Debit Collection) used in IDF and DNF –Individual Debit Instruction
IDF/Notification in DNF ...............................................................................................52
C.2 STEP2 usage of PACS.006 (Payment Cancellation Request) ....................................... 62
C.2.1 STEP2 usage of PACS.006 (Payment Cancellation Request) in IDF and DNF – Bulk
Header .......................................................................................................................62
C.2.2 STEP2 usage of PACS.006 (Payment Cancellation Request) in IDF and DNF – Original
Group Information ......................................................................................................62
C.2.3 STEP2 usage of PACS.006 (Payment Cancellation Request) in IDF and DNF –Individual
Debit Cancellation Instruction ......................................................................................63
C.3 STEP2 Usage of pacs.002S2 (Payment Status) in DVF/RSF/CDF................................ 70
C.3.1 STEP2 Usage of pacs.002S2 (Payment Status) in DVF/RSF/CDF – Bulk Header ...............70
C.3.2 STEP2 Usage of pacs.002S2 (Payment Status) in DVF/RSF/CDF - Original Group
Information And Status ...............................................................................................71
C.3.3 STEP2 Usage of pacs.002S2 (Payment Status) in DVF/RSF/CDF - Individual Reject
Instruction..................................................................................................................73
C.4 STEP2 Usage of pacs.002 (Payment Status) in IDF AND DNF ..................................... 76
This is a Payment Status sent by a bank to reject a Direct Debit (IDF) and then forwarded by
STEP2 to the counterparty (DNF). ...............................................................................76
C.4.1 STEP2 Usage of pacs.002.001.02 (Payment Status) in IDF AND DNF – Bulk Header ........76
C.4.2 STEP2 Usage of pacs.002.001.02 (Payment Status) in IDF AND DNF - Original Group
Information And Status Header....................................................................................77
C.4.3 STEP2 Usage of pacs.002.001.02 (Payment Status) in IDF AND DNF - Individual Reject
Instruction..................................................................................................................78
C.5 STEP2 Usage of pacs.004 (Return) .............................................................................. 85
C.5.1 STEP2 Usage of pacs.004 (Return) in IDF and SDF– Bulk Header ..................................85
C.5.2 STEP2 Usage of pacs.004 (Return) in IDF and SDF - Transaction Information ................86
C.6 STEP2 Usage of XML pacs.007 (Payment Reversal) .................................................... 94
C.6.1 STEP2 Usage of pacs.007 (Reversal) in IDF and SDF – Bulk Header ...............................94
C.6.2 STEP2 Usage of pacs.007 (Reversal) in IDF and SDF– Original Group Information
Header .......................................................................................................................95
C.6.3 STEP2 Usage of pacs.007 (Reversal) in IDF and SDF– Transaction Information .............96

STEP2 – M-PEDD
27th November 2009
APPENDIX D ADDITIONAL IDF FILE VALIDATION ..................................................................... 103

D.1 IDF Naming & Structure Validation Process ................................................................ 103
APPENDIX E ADDITIONAL IDF BULK VALIDATION ................................................................... 109
E.1 Bulks Naming & Structure Validation Process ............................................................. 109
APPENDIX F REPORTS ............................................................................................................ 116
F.1 PSR Pre Settlement Report .......................................................................................... 116
F.1.1 PSR Record Table Index ..............................................................................................116
F.1.2 PSR Header ................................................................................................................117
F.1.3 PSR Debit Settlement Transaction Header ....................................................................117
F.1.4 PSR Debit Party ..........................................................................................................118
F.1.5 PSR Credit Settlement Transaction Header ...................................................................119
F.1.6 PSR Credit Party .........................................................................................................120
4.1.1 PSR Liquidity Position Header .....................................................................................121
4.1.2 PSR Liquidity Position Body ........................................................................................122
4.1.3 PSR Liquidity Position Trailer .......................................................................................123
4.1.4 PSR FileTrailer ............................................................................................................123
F.2 DRR File Report ........................................................................................................... 124
F.2.1 DRR Record Table Index .............................................................................................124
F.2.2 DRR header ................................................................................................................125
F.2.3 DRR files/bulks/messages sent ....................................................................................126
F.2.4 DRR Direct Debit bulks sent ........................................................................................129
F.2.5 DRR Req for Canc bulks sent ......................................................................................130
F.2.6 DRR Rejects bulks sent ..............................................................................................131
F.2.7 DRR Reversals bulks sent ..........................................................................................132
F.2.8 DRR Refunds/Returns bulks sent .................................................................................133
F.2.9 DRR Returns of Reversals bulks sent ..........................................................................133
F.2.10 DRR DNFs received ...................................................................................................135
F.2.11 DRR - RSFs received .................................................................................................137
F.2.12 DRR - RSFs Debit Direct debit ....................................................................................138
F.2.13 DRR -RSFs Credit Direct debit ....................................................................................139
F.2.14 DRR - SDFs received header ......................................................................................139
F.2.15 DSRB - SDFs Return/Reversal received ......................................................................140
F.2.16 DSSH - CDFs received header ....................................................................................141
F.2.17 DSSB - CDFs Refunds/Return/Reversal received .........................................................141
F.2.18 DRR Debit Party settlement Transactions header .........................................................142
F.2.19 DRR Credit Party settlement transactions received .......................................................145
F.2.20 DRR trailer .................................................................................................................146
F.3 Monthly Statistics Report (MSR) .................................................................................... 147
F.3.1 MSR Record Table Index ............................................................................................147
F.3.2 MSR header ...............................................................................................................148
F.3.3 MSR body: statistics on Transactions sent ...................................................................149
F.3.4 MSR body: statistics on Transactions received .............................................................151
F.3.5 MSR trailer .................................................................................................................153
F.4 Multilateral Balancing Payments .................................................................................... 154
F.4.1 General Header row (1-1) ...........................................................................................154
F.4.2 Sent DD Header row (1- 1) ..........................................................................................154
F.4.3 Sent DD Detail row (1- N)............................................................................................154
F.4.4 Received DD Header row (1- 1) ...................................................................................155
F.4.5 Received DD Detail row (1- N).....................................................................................155
APPENDIX G STEP2 SWIFTNET CONNECTIVITY ....................................................................... 156
G.1 STEP2 SWIFTNet security infrastructure ........................................................................ 156
G.2 STEP2 SWIFTNet Services ............................................................................................. 157
G.3 Information on STEP2 DNs, Request Types and End Points ........................................... 157
G.4 STEP2 SWIFTNET Service Parameters Table .................................................................. 158

STEP2 – M-PEDD
27th November 2009
G.5 SWIFTNet v6.0 and v6.1 ................................................................................................. 159

G.6 Webstations URLs ......................................................................................................... 160
APPENDIX H SERVICE ROUTING TABLE .................................................................................. 161
H.1 The Routing Tables ....................................................................................................... 161
H.2 How to read the table ..................................................................................................... 161
H.3 Status used in the Routing Table ................................................................................... 162
H.4 Admission Profile .......................................................................................................... 162
H.5 Debit Type Allowed ....................................................................................................... 163
H.6 Direct Participant Routing Table .................................................................................... 164
H.6.1 Header row ................................................................................................................164
H.6.2 Search Criteria header row 1 .......................................................................................164
H.6.4 Search criteria ............................................................................................................164
H.6.5 Results header row 1 ..................................................................................................165
H.6.7 Results row ................................................................................................................166
H.7 Indirect Participant Routing Table .................................................................................. 167
H.7.1 Header row ................................................................................................................167
H.7.4 Search Criteria results ................................................................................................167
H.7.7 Results row ................................................................................................................168
APPENDIX I ERROR CODE REFERENCE LIST .......................................................................... 169
I.1 File Level Codes ............................................................................................................ 169
I.2 Bulk Error codes ........................................................................................................... 171
I.3 Transaction level Error Codes ....................................................................................... 174

STEP2 – M-PEDD
27th November 2009
INDEX OF FIGURES
Figure 2-1: Bulk types in IDF file sent to STEP2 __________________________________________ 20
Figure 2-2: Bulk types in DNF file sent by STEP2 _________________________________________ 21
Figure 2-3: Bulk types in DVF file sent by STEP2 _________________________________________ 21
Figure 2-4: Bulk types in RSF file sent by STEP2 _________________________________________ 21
Figure 2-5: Bulk types in SDF file sent by STEP2 _________________________________________ 21
Figure 2-6: Bulk types in CDF file sent by STEP2 _________________________________________ 21
Figure 2-7: Connection via a STEP2-enable payment system _______________________________ 22
Figure 3-1: Settlement of Bulks ________________________________________________________ 32

STEP2 – M-PEDD
27th November 2009
INDEX OF TABLES
Table 2-1 Connection via a STEP2-enable payment system ________________________________ 22

Table 4-1 Appendices Usage _________________________________________________________ 34
Table 4-2 Usage of Instructing and Instructed Agent _______________________________________ 37
Table 4-3 - Duplicate Check __________________________________________________________ 38
Table 4-4 SEPA Direct Debit Implementation Guidelines ___________________________________ 41
Table 4-5 IDF STEP2 File Header Elements _____________________________________________ 46
Table 4-6 DVF STEP2 File Header Elements ____________________________________________ 47
Table 4-7 Debit Notification File STEP2 File Header Elements ______________________________ 48
Table 4-8 Response to Settlement File STEP2 File Header Elements _________________________ 48
Table 4-9 Settled Debits File STEP2 File Header Elements _________________________________ 48
Table 4-10 Cancelled Debits File STEP2 File Header Elements _____________________________ 49
Table 4-11 PACS.003 (Debit Collection) used in IDF and DNF – Group Header _________________ 51
Table 4-12 PACS.003 (Debit Collection) used in IDF and DNF – Individual Debit Instruction _______ 61
Table 4-13 STEP2 usage of PACS.006 (Payment Status) in IDF and DNF – Bulk Header_________ 62
Table 4-14 STEP2 usage of PACS.006 (Payment Cancellation Request) in IDF and DNF – Original Group
Information ________________________________________________________________________ 63
Table 4-15 STEP2 usage of PACS.006 (Payment Cancellation Request) in IDF and DNF –Individual Debit
Cancellation Instruction ______________________________________________________________ 69
Table 4-16 STEP2 Usage of pacs.002 (Payment Status) in DVF/RSF/CDF – Bulk Header ________ 70
Table 4-17 STEP2 Usage of pacs.002S2 (Payment Status) in DVF/RSF/CDF - Original Group Information
And Status ________________________________________________________________________ 72
Table 4-18 STEP2 Usage of pacs.002S2 (Payment Status) in DVF/RSF/CDF - Individual Reject Instruction
_________________________________________________________________________________ 75
Table 4-19 STEP2 Usage of pacs.002.001.02 (Payment Status) in IDF AND DNF – Bulk Header __ 76
Table 4-20 STEP2 Usage of pacs.002.001.02 (Payment Status) in IDF AND DNF - Original Group
Information and Status Header ________________________________________________________ 77
Table 4-21 STEP2 Usage of pacs.002.001.02 (Payment Status) in IDF and DNF - Individual Reject
Instruction ________________________________________________________________________ 84
Table 4-22 STEP2 Usage of pacs.004 (Return) in IDF and SDF– Bulk Header__________________ 86
Table 4-23 STEP2 Usage of pacs.004 (Return) in IDF and SDF/CDF - Transaction Information IDF 93
Table 4-24 STEP2 Usage of pacs.007 (Reversal) in IDF and SDF– Bulk Header ________________ 95
Table 4-25 STEP2 Usage of pacs.007 (Reversal) in IDF and SDF– Original Group Information Header95
Table 4-26 STEP2 Usage of pacs.007 (Reversal) in IDF and SDF– Transaction Information _____ 102
Table 4-27 IDF Naming & Structure Validation __________________________________________ 108
Table 4-28 PSR Header ____________________________________________________________ 117
Table 4-29 PSR Debit Settlement Transaction Header ____________________________________ 117
Table 4-30 PSR Debit Settlement Transaction Header – field contents _______________________ 118
Table 4-31 PSR Debit Party _________________________________________________________ 118
Table 4-32 PSR Debit Party – field contents ____________________________________________ 119
Table 4-33 PSR Debit Party trailer ____________________________________________________ 119
Table 4-34 PSR Credit Settlement Transaction Header ___________________________________ 119
Table 4-35 PSR Credit Settlement Transaction Header – field contents ______________________ 120
Table 4-36 PSR Credit Party _________________________________________________________ 120
Table 4-37 PSR Credit Party – field contents ____________________________________________ 121
Table 4-38 PSR Credit Party trailer ___________________________________________________ 121
Table 4-39 PSR Liquidity Position Header – field contents _________________________________ 122
Table 4-40 PSR Liquidity Position Body – field contents ___________________________________ 123
Table 4-41 PSR trailer ______________________________________________________________ 123
Table 4-42 DRR Record Table Index __________________________________________________ 124
Table 4-43 DRR header ____________________________________________________________ 125
Table 4-44 DRR files/bulk/messages sent header ________________________________________ 126
Table 4-45 DRR files/bulk/messages sent header – field contents ___________________________ 128
Table 4-46 DRR Direct Debit bulks sent body ___________________________________________ 129
STEP2 – M-PEDD
27th November 2009
Table 4-47 DRR Direct Debit bulks body – field contents __________________________________ 129
Table 4-48 DRR Req for Canc bulks sent body __________________________________________ 130
Table 4-49 DRR Req for Canc bulks body – field contents _________________________________ 130
Table 4-50 DRR Rejects bulks sent body _______________________________________________ 131
Table 4-51 DRR Rejects bulks body – field contents ______________________________________ 131
Table 4-52 DRR Reversal bulks sent body _____________________________________________ 132
Table 4-53 DRR Reversals bulks body – field contents ____________________________________ 132
Table 4-54 DRR Refunds/Returns bulks sent body _______________________________________ 133
Table 4-55 DRR Refunds/Returns bulks body – field contents ______________________________ 133
Table 4-56 DRR Returns of Reversals bulks sent body ___________________________________ 134
Table 4-57 DRR Returns of Reversals bulks body – field contents __________________________ 134
Table 4-58 DRR files sent trailer ______________________________________________________ 134
Table 4-59 DRR files received header _________________________________________________ 135
Table 4-60 DRR files received header – field contents ____________________________________ 136
Table 4-61 DRR DDs received body __________________________________________________ 136
Table 4-62 DRR DDs received body – field contents______________________________________ 136
Table 4-63 DRR Req for Canc received body ___________________________________________ 136
Table 4-64 DRR Req for Canc received body – field contents ______________________________ 137
Table 4-65 DRR Rejects received body ________________________________________________ 137
Table 4-66 DRR Rejects received body – field contents ___________________________________ 137
Table 4-67 DRR files sent trailer ______________________________________________________ 137
Table 4-68 DRR RSFs received header ________________________________________________ 138
Table 4-69 DRR RSFs received header – field contents ___________________________________ 138
Table 4-70 DRR RSFs Debit Direct Debit ______________________________________________ 138
Table 4-71 DRR RSFs Debit Direct Debits – field contents ________________________________ 139
Table 4-72 DRR RSFs Credit Direct Debit ______________________________________________ 139
Table 4-73 DRR RSFs Credit Direct Debit – field contents _________________________________ 139
Table 4-74 DRR RSFs received Trailer ________________________________________________ 139
Table 4-75 DRR SDFs received header ________________________________________________ 140
Table 4-76 DRR SDFs received header – field contents ___________________________________ 140
Table 4-77 DRR SDFs Refunds/Return/Reversal received _________________________________ 140
Table 4-78 DRR SDFs Return/Reversal received – field contents ___________________________ 141
Table 4-79 DRR SDFs received Trailer ________________________________________________ 141
Table 4-80 DRR CDFs received header ________________________________________________ 141
Table 4-81 DRR CDFs received header – field contents ___________________________________ 141
Table 4-82 DRR CDFs Return/Reversal received ________________________________________ 142
Table 4-83 DRR CDFs Refunds/Return/Reversal received – field contents ____________________ 142
Table 4-84 DRR SDFs received Trailer ________________________________________________ 142
Table 4-85 DRR Debit Party settlement Direct Debits header_______________________________ 142
Table 4-86 DRR Debit Party settlement Transactions header – field contents __________________ 143
Table 4-87 DRR Debit Party settlement Direct Debits body ________________________________ 143
Table 4-88 DRR Debit Party settlement Transactions body – field contents ___________________ 144
Table 4-89 DRR Debit Party settlement Transactions trailer ________________________________ 144
Table 4-90 DRR s Credit Party settlement Transactions header ____________________________ 145
Table 4-91 DRR Credit Party settlement Direct Debits header – field contents _________________ 145
Table 4-92 DRR Credit Party settlement Transactions body ________________________________ 146
Table 4-93 DRR Credit Party settlement Transactions body – field contents ___________________ 146
Table 4-94 DRR Credit Party settlement Transactions trailer _______________________________ 146
Table 4-95 DRR trailer _____________________________________________________________ 146
Table 4-96 MSR Record Table Index __________________________________________________ 147
Table 4-97 MSR header ____________________________________________________________ 148
Table 4-98 MSR Transactions sent header _____________________________________________ 150
Table 4-99 MSR DDs sent body ______________________________________________________ 150
Table 4-100 MSR Req for Canc sent body ______________________________________________ 150
Table 4-101 MSR Rejects sent body __________________________________________________ 150
Table 4-102 MSR Reversals sent body ________________________________________________ 150
Table 4-103 MSR Refunds/Returns sent body ___________________________________________ 151
Table 4-104 MSR Returns of reversals sent body ________________________________________ 151
STEP2 – M-PEDD
27th November 2009
Table 4-105 MSR transactions sent trailer ______________________________________________ 151

Table 4-106 MSR Transactions received header _________________________________________ 152
Table 4-107 MSR DDs received body _________________________________________________ 152
Table 4-108 MSR Req for Cancellation received body ____________________________________ 152
Table 4-109 MSR Rejects received body _______________________________________________ 152
Table 4-110 MSR Reversals received body _____________________________________________ 152
Table 4-111 MSR Refunds/Returns received body _______________________________________ 153
Table 4-112 MSR Returns of Reversals received body ____________________________________ 153
Table 4-113 MSR transactions received trailer __________________________________________ 153
Table 4-114 MSR trailer ____________________________________________________________ 153

STEP2 – M-PEDD
27th November 2009
1. INTRODUCTION
The document is based on the work of the 59 STEP2 M-PEDD underwriting banks. It contains the details on
theInterfaces between participants and the STEP2 Debit Services. It presents a technical overview of the
interface to the STEP2 direct debit processing system that will be developed by EBA CLEARING.
Although it can be read in isolation, to fully understand this document the reader should be familiar with the
concepts and rules defined in the SEPA Core Direct Debit Scheme Rulebook, the SEPA Business to
Business Direct Debit Scheme Rulebook and related documentation.
The technical details expressed in this document follow the business requirements present in the STEP2
MPEDD Business Function Requirements document. The Interface specification describes at a technical
level the exchange of data between the Banks and STEP2, allowing the banks to develop their internal
systems to support the data exchange.
This document includes all the specifications required to build a participant system, but excludes additional
reporting and browser based capabilities. This document and the provided XML schemas are intended for
banks to use in building their own back offices interfaces to STEP2.
1.1 SEPA Direct Debit requirements
The EPC SEPA Direct Debit Implementation Guidelines contain recommendations for using the ISO20022
fields for SEPA Direct Debits. By taking all the fields within the rulebook, and all the Mandatory fields within
the ISO20022 messages they have created a “SEPA Data Set” – a list of fields with a status, format and
specific validation rules.
The STEP2 implementation of the ISO 20022 contains all the fields within the SEPA Data Set and follows
their recommendation on formats and validation where possible. In some cases additional fields that are not
in the SEPA data set have been added where a strong business need has been identified.
1.2 STEP2 Core and B2B Services

The EPC has created two separate schemes: a Core scheme and the B2B scheme. Participants may be a
member of either or both schemes. The processing rules and data elements between schemes are similar,
although the timings differ. Data exchanged in the interbank space is identified and segregated by the use of
codes: Core for the core scheme and B2B for the Business to Business Scheme.
STEP2 supports two services (Core and B2B) to support the two schemes. Participants may be a member of
either or both services.
This document describes the specification for the Core interface and for the B2B interface.
These interfaces are the same in terms of
File formats
Data formats and XML schemas
Most validation rules
They differ in terms of
Processing times each day
The timetable over a series of days
Some service specific validation rules.
This document applies equally to Core and B2B Debits and related R-Messages unless specified separately.

STEP2 – M-PEDD
27th November 2009
1.3 Glossary
Term Description
Automated Clearing House. PE-ACH is therefore a Pan-European
ACH
ACH.
A sender or receiver of files, bulks and messages within the STEP2
Debit Service. It is used when describing the technical aspect of
the service rather than the business aspect.
Creditor Agent: This is the party which originates the Direct
Debit transaction.
Debtor Agent. This is the party which is the final receiver of the
Agent
transaction.
Instructing Agent: This is the Direct Participant sending the
transaction to the STEP2 Debit Service.
Instructed Agent: This is the Direct Participant receiving the
transaction from the STEP2 Debit Service.
According to the EPC Rulebook: “If the disputed Collection is not
Authorized /
covered by a valid Mandate, the transaction is considered to be an
unauthorized debit
unauthorised transaction” (sect 4.4).
B2B Business-to-Business
B2C Business-to-Consumer
Bank Identifier Code. The worldwide unique identifier for a Bank.
BIC STEP2 SDD will use at least the eight-character BIC and up to an
11-character BIC to route debits.
Each set of data sent from one Bank to another is settled
Bilateral Gross separately. In other words, the R-Messages are not offset against
Settlement the debits, and debits from one side are not offset by debits from
the other.
A logical collection of Debit Messages or R-Messages. A bulk may
Bulk only contain Debit Messages or R-Messages due to be settled on a
single Interbank Settlement Date.
Cancelled Debits File. This file is sent to the bank sending post-
CDF settlement R-messages to the STEP2 Debit Service, only in the
case where settlement failure has occurred.
Creditor The individual or organization initiating a Direct Debit Message.
Creditor Bank The Bank where the Creditor’s account is held
Clearing And Settlement Mechanism – a general term for an ACH.
CSM
STEP2 is a Pan-European CSM.
This that the Debtor is Debited.Normally the same as the Due Date
Debit Date (except if that is a weekend) or the Interbank Settlement
Date(except if that is a local bank holiday)
A Debit Instruction in the context of this document is a message
that is sent from a Creditor via his Creditor Bank and possibly a
Direct Participant intermediary, to a Debtor, via the Clearing And
Debit Instruction
Settlement Mechanism, possibly a Direct Participant on the Debtor
side, and the Debtor Bank. The effect of a Debit Instruction is to
cause a Debtor’s account to be debited.
A Debit Related instruction is any message that is sent from a
Creditor Bank to a Debtor Bank, or from a Debtor Bank to a
Debit-Related Creditor Bank, which is part of the defined set of messages for the
instruction System, but is not a Debit instruction. Examples of these include R-
Messages (q.v.) and may in the future also include separate
mandate-related instructions.
The individual or organization whose Bank account is debited via a
Debtor
Direct Debit.
Debtor Bank The Bank where the Debtor’s account is held.

STEP2 – M-PEDD
27th November 2009
This term refers to Mandates. A ‘dematerialised’ mandate is a set

Dematerialised of data that makes up a mandate, whether it was originally paper-
based or not. The dataset is defined in the EPC Rulebook.
A Direct Participant is a Bank who is a member of STEP2 and
Direct Participant transmits and receives data directly to and from the STEP2 Debit
Service.
Direct Participant Workstation. The operator interface between a
DPWS
Direct Participant and STEP2 SDD.
Due Date The date the Creditor asks for the money to be collected.
European Payments Council. The EPC produces a Rulebook which
defines the functions that any SEPA Direct Debit service must
EPC
provide.
The current version of the EPC Rulebook is 2.3.
A file is a technical term for a ‘wrapper’ that contains one of or
File more Bulks. Files and their definitions and naming conventions are
covered in the Interface Specification.
An Indirect Participant is a Bank who is not a member of STEP2
and does not transmit or receive data directly to or from the STEP2
Indirect Participant
Debit Service. Instead, it transmits data to and receives data from a
Direct Participant with which it has an agreement.
The date the funds move between banks.Normally the same as
Interbank Settlement
Due Date, but can be different if the Due Date is a non–TARGET
Date
day.
A standard defining the Universal Financial Industry message
scheme (abbreviated to UNIFI), which provides the financial
ISO20022
industry with a common platform for the development of messages
in a standardized XML syntax.
MBP Multilateral Balancing Payments
MPEDD Multipurpose Pan-European Direct Debit
MSR Monthly Statistics Report
PSR Pre-Settlement Report
A Refusal is an R-Message (q.v.) initiated by the Debtor before
Settlement, for any reason, requesting the Debtor Bank not to pay
a Direct Debit Message. This Refusal, when handled by the Debtor
Refusal
Bank prior to inter-bank Settlement, results in the Debtor Bank
rejecting the associated Debit Message using the format of a
Reject.
A Reject is an R-Message (q.v.) which is sent by the Debtor Bank
in advance of settlement and indicates that the message was
Reject
unacceptable to the Debtor Bank. It is accompanied by a Reason
Code indicating the reason for rejection.
Request for An R-Message (q.v.) which is sent by the Creditor Bank in advance
Cancellation of settlement to cancel a previously sent transaction.
A Request for Refund is an R-Message (q.v.) which is initiated by
Request for Refund the Debtor for reimbursement of a Direct Debit under the terms
agreed by Debtors with their Debtor Bank.
A Return is an R-Message (q.v.) which is initiated by the Debtor
Return Bank after inter-bank Settlement, because it is unable to process
the Debit Message.
A Reversal is an R-Message (q.v.) which is initiated by the Creditor
Reversal after the clearing and Settlement to reimburse the Debtor with the
full or partial amount of the erroneous Debit Message.
A R-Message is a message sent by one of the four parties to the
transaction (Creditor, Creditor Bank, Debtor Bank, Debtor) which
R-Message
has the effect of diverting the Direct Debt Instruction to which it
refers from its normal course of execution.
Results of Settlement File. This file is sent to both sides of the
RSF transaction. It lists details of both successful and failed settlement
of Debit messages.

STEP2 – M-PEDD
27th November 2009
Settled Debits File. This file is sent to the sending bank and lists
SDF
details of successfully settled post-settlement R-Messages.
SEPA Single Euro Payment Area
STEP2 is the first pan-European automated clearing house (PE-
STEP2
ACH) for bulk payments in euro.
The IP (Internet Protocol) -based messaging platform provided by
SWIFTNet
SWIFT.
Trans-European Automated Real-time Gross settlement Express
Transfer system. A payment system comprising 15 national real-
time gross settlement (RTGS) systems and the ECB payment
TARGET
mechanism (EPM).
TARGET Days (see below) are the days on which the TARGET
system operates.
A TARGET Day is a day on which the TARGET2 Settlement
mechanism operates. An Interbank Settlement can only take place
on a TARGET day.
Saturdays and Sundays are Non-TARGET days (also known as
TARGET holidays). In addition the following days are TARGET
holidays:
New Year's Day,
TARGET Day
Good Friday (Catholic/Protestant),
Easter Monday (Catholic/Protestant),
1 May (Labour Day),
Christmas Day and
26 December.
A Bank that is neither a Direct nor an Indirect Participant, but has a
valid BIC. While this concept has meaning and is used for the
Unknown Bank Credit Transfer service, it has a less easily defined meaning for
Direct Debits. For this reason ‘Unknown Banks’ will be referred to
as ‘non-Participant Banks’ in this document.
Extensible Markup Language. An open standard for exchanging
structured documents and data over the Internet that was
XML
introduced by the World Wide Web Consortium (W3C) in
November 1996.
XCT The STEP2 Cross border Credit Transfer service
Term Description

STEP2 – M-PEDD
27th November 2009
2. THE STEP2 SYSTEM
2.1 Overview
All transaction processing information exchanged between the STEP2 central system and a Direct
Participant is performed via files transmitted across a secure network. The formats of the various files are
specified in the appendices of this document. Information that is presented to the STEP2 central system in a
file that does not strictly match the specified format is rejected. Similarly, the STEP2 central system delivers
information to Direct Participants in files that are strictly formatted in accordance with this published
specification.
The formatting of payment instructions within files is service specific. STEP2 supports debit requests in XML
format, as per the proposed ISO20022 Payments Standards from SWIFT. The validation rules for these
formats are also specified in the appendices of this document.
The business level messages in the SEPA MPEDD, do not match one to one with the ISO20022 XML
Message, so some XML message are used for more than one purpse, e.g. the pacs.002 Payment Status
message, is used by STEP2 to reject messages, by STEP2 to give information about the success or failure
of settlement, and as interbank message to reject or refuse Debits.
Sender Business Level message File Type XML XML Message

According to the Message Description
scheme used
Bank to Debit Request Input Debit File (IDF) pacs.003 FI to FI Customer
MPEDD Direct Debit
Request for Cancellation pacs.006 Request for
Cancellation
Reject pacs.002 Payment Status
Refusal Report
pacs.002 Payment Status
Report
Return pacs.004
Request for Refund (Core pacs.004
only) pacs.007 Payment Return
Reversal Payment Return
Payment Reversal
MPEDD To Confirmation / Rejection of Debit Validation File pacs.002S2 Payment Status

Sending Bank messages received (DVF) Report
MPEDD To Debit Request Debit Notification File pacs.003 FI to FI Customer
Receiving Bank Request for Cancellation (DNF) Direct Debit
Reject pacs.006 Request for
Refusal Cancellation
Report
Report
MPEDD to both Confirmation of Settled Results of Settlement pacs.002S2 Payment Status
sending and Debits File (RSF) Report
receiving bank Notification of Cancelled
Debits pacs.002S2
Payment Status
Report
MPEDD to Return Settled Debit File pacs.004 Payment Return
receiving Bank Request for Refund (SDF) pacs.004 Payment Refund

STEP2 – M-PEDD
27th November 2009
Sender Business Level message File Type XML XML Message

According to the Message Description
scheme used
(Core only)
Reversal pacs.007 Payment Reversal
MPEDD to Notification of failed Cancelled Debit File pacs.002S2 Payment Status

sending Bank settlement for (CDF) Report
Return
Refund
Reversal
MPEDD to all Machine Readable Report Pre-Settlement Report - -

banks (PSR)
MPEDD to all Machine Readable Report Daily Reconciliation - -
banks Report (DRR)
MPEDD to all Machine Readable Report Monthly Statistical - -
banks Report (MSR)
MPEDD to all Comma Separated Values Multilateral Balancing - -
banks Payments Report
(MBP)
MPEDD to all Comma Separated Values Routing table file - -
banks Report (RTF)
This is shown diagrammatically in figures 2.1 to 2.6 below.
IDF
BULK 1: Debit collections (pacs.003.001.01)
BULK 2: Requests for Cancellation (pacs.006.001.01)

€$
BULK 3: Rejects (pacs.002.001.02)
BULK 4: Reversals (pacs.007.001.01)

Bank
BULK 5: Returns/Refunds (pacs.004.001.01) STEP2 Debit

Service
BULK 6: Return Reversal (pacs.004.001.01Rev)
Figure 2-1: Bulk types in IDF file sent to STEP2
DNF
BULK 1: Debit collections (pacs.003.001.01)
€$
BULK 2: Requests for Cancellation (pacs.006.001.01)
BULK 3: Rejects (pacs.002.001.02) Bank
STEP2 Debit
Service

STEP2 – M-PEDD
27th November 2009
Figure 2-2: Bulk types in DNF file sent by STEP2
DVF €$
BULK 3: Rejects (pacs.002.001.02S2)
Bank
STEP2 Debit
Service
Figure 2-3: Bulk types in DVF file sent by STEP2
RSF €$
BULK 3: Status (pacs.002.001.02S2)
Bank
STEP2 Debit
Service
Figure 2-4: Bulk types in RSF file sent by STEP2
SDF
€$
BULK 4: Reversals (pacs.007.001.01)
BULK 5: Returns/Refunds (pacs.004.001.01)

Bank
STEP2 Debit BULK 6: Return Reversal (pacs.004.001.01Rev)

Service
Figure 2-5: Bulk types in SDF file sent by STEP2
Figure 2-6: Bulk types in CDF file sent by STEP2
2.2 Connecting to STEP2 as a Direct Participant

Direct participants connect to STEP2 as shown in Figure 2-7 and explained below.
• STEP2 receives payment instructions for processing from Direct Participants and transmits
processed payment instructions to Direct Participants in bulk files; and
• In addition, all reporting and reconciliation information is transmitted to Direct Participants in files or
reported via an Internet-browser based enquiry terminal.
The STEP2 system expects all files it receives to be strictly formatted in accordance with the STEP2 file
specifications laid out in this document. All files transmitted by the STEP2 system are similarly formatted in
accordance with these standards. To maximise the possible degree of STP, all files are designed to be easily
readable by machines.
Banks that join the service must be able to send and receive structured files in the STEP2 standard.

STEP2 – M-PEDD
27th November 2009
Direct participants must understand the options open to them for the routing of their transactions within each
service.
STEP2 provides facilities for the automatic routing of transactions

• Directly – where the Debtor bank is a Direct Participant;
• Indirectly – where the Debtor bank is an Indirect Participant; or for some services.
Routing via sender nominated intermediaries is not supported.
2.2.1 Connecting to STEP2 via a STEP2-enabled payment system

Direct participants may choose to modify their existing, internal payment systems to communicate direct with
STEP2.
Webstation
Interface 5 6
1,7 1,7
Network
1,2,3,4,7 1,2,3,4,7
Direct Participant STEP2 Central System
Payment System(s)
Figure 2-7: Connection via a STEP2-enable payment system
For this architectural option, the information flows that must be managed by the Direct Participant’s payment
system(s) and the sections of this document in which these topics are discussed are laid out in the
Appendices.
Flow Description
1 Transmission of files of transactions to the STEP2 central system and the reception of
information from the STEP2 central system on the success of validation of those files.
2 Transmission of processed transactions from the STEP2 central system to the Direct
Participant.
3 Transmission of exception messages from the STEP2 central system to the Direct
Participant.
4 Transmission of reconciliation information (daily and monthly) from the STEP2 central
system to the Direct Participant.
5 Execution of enquiries on the central system and the delivery of browser-based reports on
online data held within the central system.
6 Internal routing of received transactions within the STEP2 central system.
7 Recovery of information from the STEP2 central system in the event of data loss at the
Direct Participant.
All Interfaces to supported networks.
Table 2-1 Connection via a STEP2-enable payment system

STEP2 – M-PEDD
27th November 2009
2.3 STEP2 MPEDD Filetypes
2.3.1 Input Debit File (IDF)

Direct Participant’s systems must transmit transactions to the central system in Input Debit Files (IDF). Each
IDF must have a unique Sender’s File Reference (SFR). The precise format required for an IDF is specified
in the appendices.
Direct participants need not transmit IDFs to the central system for every settlement cycle. However, a
configurable maximum number of IDFs per Direct Participant per settlement cycle is enforced by the STEP2
central system.
Immediately upon receipt of an IDF by the STEP2 central system the network returns an acknowledgement
of receipt (ACK) to the Direct Participant’s system; receipt of this acknowledgement signals to the Direct
Participant that the file has been received and will be processed further.
2.3.2 Debit Validation File (DVF)

Irrespective of the result of validation, one and only one Debit Validation File (DVF) is returned per
transmitted IDF to the sending Direct Participant indicating the success or otherwise of the validation
process. The structure of a DVF is described in Appendix B and C and the range and meaning of errors
codes are defined in Appendix D for XML format DVFs.
Direct participants which receive a DVF indicating complete acceptance of the file do not need to take any
further action for settlement until reconciliation information is received.
Direct participants receiving DVFs that indicate complete rejection or partial acceptance of a file should
consult the details of the DVF, correct the error(s), and retransmit the entire file or the erroneous debit
instructions only, as appropriate.
Note that DVFs indicating complete acceptance do not contain any specific rejected transactions. DVFs
indicating partial acceptance of an IDF will contain specific rejected transactions. DVFs indicating complete
rejection of an IDF may contain specific rejected debit instructions only if all the debits have been rejected;
under these circumstances, the rejected transactions in the DVF give the user information to enable
diagnosis of the problem.
2.3.3 Debit Notification File (DNF)

Accepted pre-settlement transactions will be delivered to the relevant counterparty Direct Participant in a
DNF, at the end of the input phase in a window specified during the daily cycle. The structure of a DNF and
the contents are defined in appendix B and C.
Direct participants receiving a DNF are notified of all the DDs and R-messages received during a business
date, for which they are the counterparty.
Direct Participants receiving DNFs can therefore either:
• Accept the DDs. In this case, no further action is required, i.e. the transactions will be settled
automatically at the Interbank settlement date; or
• Reject one or many DDs. In this case they must send a pacs.002.001.02 to the STEP2 CS
within the allowed date range, to perform the DDs rejection operation, preventing the settlement
of the DDs.
2.3.4 Pre-Settlement Report (PSR)

A report of the accepted transactions (DDs and R-messages) amounts, which are going to be settled in the
current settlement cycle, is delivered to the relevant Direct Participants in one PSR, at the end of the input
phase in a window specified during the daily cycle. The structure of a PSR and the contents are defined in
appendix F.1

STEP2 – M-PEDD
27th November 2009
Direct participants receiving a PSR are notified of all the DDs and R-messages, for which they are debit
and/or credit party; this report, could provide information for liquidity optimisation, as the Banks could check
in advance the credit and debit amounts that will be operated shortly in TARGET2 accounts.
No further action is therefore required at STEP2 level by the PSR receiving DPs.
2.3.5 Response to Settlement File (RSF)

The Response to Settlement File will include the DDs which have been sent to the settlement system for the
relevant business date and is delivered to the relevant Direct Participants, at the end of the settlement phase
in a window specified during the daily cycle. The structure of the RSF header is defined in B.4.
Direct participants receive a RSF notifying them of all the DD for which they are the debtor instructed or
creditor instructing parties (either debtor or creditor DPs). The DDs that have been successfully settled or not
by the settlement mechanism will not contain full details of the original instruction but will contain the
minimum set of data that allows an unambiguous identification (eg. transaction reference, interbank
settlement date, etc).
2.3.6 Settled Debit File (SDF)

The Settled Debit File will include the post-settlement R-messages which have been sent and settled in the
settlement system for the current business date and is delivered to the relevant Direct Participants at the end
of the settlement phase (after settlement). This file delivery is done in a window specified during the daily
cycle. The structure of a SDF and its contents are defined in appendix B and C.
Direct participants receive a SDF notifying them of all the R-messages for which they are the instructed
agent. Post-Settlement R-messages will include all the details of the transaction when delivered in an SDF.
The number of SDFs to be received by a DP is configurable as a participant configuration parameter from 1

to 2 as follows:
• 1 SDF which includes all the transactions; or
• 2 SDFs which include the transactions split per the DP and per all the related IPs.

STEP2 – M-PEDD
27th November 2009
2.3.7 Cancelled Debit File (CDF)

The Cancelled Debit File will include Reject messages concerning the post-settlement R-messages which
have failed settlement in the settlement mechanism for the relevant business date and is delivered to the
relevant Direct Participant, at the end of the settlement phase in a window specified during the daily cycle.
The structure of a CDF and the contents are defined in Appendix B and C.
CDF are sent to all participants that sent post-settlement R-messages that then failed to settle. R-messages
that have been cancelled by the settlement mechanism will include the minimum set of data that allows an
unambiguous identification as described in section C.3.3.
2.3.8 Reconciliation and statistical reports

Following transmission of settlement results, information to assist reconciliation is forwarded by STEP2 to
Direct Participants. There are two forms of reconciliation information.
1. Daily reconciliation information; and
2. Optional monthly statistics information.
These reports are service specific, e.g. one report per service will be made available.
2.3.8.1 Daily Reconciliation Report (DRR)

The Daily Reconciliation Report includes the data to allow Participant reconciliation in terms of transactions
sent and received and in terms of amounts debited and credited for the relevant business date. This file is
sent by the central system at the end of the output phase in a window specified during the daily cycle. The
structure of a DRR and the contents are defined in section F.2.
2.3.8.2 Monthly Statistical Report (MSR)

Monthly reconciliation information can be provided in the form of statistics on monthly usage of STEP2.
Transmission of this information is optional and Direct Participants should request that the STEP2 deliver it
to them if they wish to receive it. This information will be transmitted in the last Target day of each month
following the opening of the processing for first Target day of the next month.
This report’s contents may be used, for example, for billing purposes, as the Banks receive the total of
transactions exchanged and settled on monthly basis.
The structure of an MSR and the contents are defined in section F.3.
2.3.8.3 Multilateral Balancing Payments Report (MBP)

In accordance with the requirements of the EPC CSM Framework, STEP2 will provide a counting service for
the direct debit service therefore; STEP2 shall create and maintain a count of transactions report between
each pair of Creditor and Debtor Agents.
2.3.8.4 Routing table file Report (RTF)

The STEP2 Directory of Participants and the related routing information will be delivered to Direct
Participants via FileAct each time the routing table has been updated.
See Appendix H for format details.

STEP2 – M-PEDD
27th November 2009
3. STEP2 FILE EXCHANGE FUNDAMENTALS
3.1 Sending and Validation windows

STEP2 is operational on all TARGET days. On non-target days, STEP2 processing ceases at midnight at
the end of the previous TARGET day and recommences at midnight at the beginning of the next TARGET
day. However, the service will only validate received files and send responses during real-time validation
windows. Outside of these times, received files are subject to ‘deferred validation’, meaning that STEP2 will
validate and send responses once the service re-opens.
Details on the Settlement Cycle and precise timings are documented as parameters within the Functional
Overview document.
3.2 File exchange security

Files exchanged between Direct Participants and the STEP2 central system are secured (digitally signed) by
features of the network within the STEP2 central system and on Direct Participants’ premises to ensure the
authenticity and integrity of the files exchanged. Files that are received by the STEP2 central system whose
security credentials are found to be in less than perfect order are immediately rejected and no further
processing is performed.
3.3 Push mode

The secure network utilised by STEP2 consists of a command channel and a file transport channel. When
connected via SWIFTNet, Direct Participants may request that the STEP2 central system deliver files to
them in “push” mode.
In push mode, the central system asks the bank system over the command channel if it may transmit a file to
it. Assuming that the answer is positive, the central system then transmits the file. If the answer is negative or
no answer is received then the STEP2 central system will wait for a configurable time before retrying. If no
positive answer is received within a configurable number of attempts the STEP2 central system logs this as
an error and attempts to retransmit the information for a set number of retries. Further retries must be part of
a manual intervention.
The STEP2 central system requires that Direct Participant’s systems deliver files to it only in push mode.
3.4 File formats, naming conventions, and format versioning

STEP2 MPEDD files are based on XML standards and made of different levels of Headers as well as
messages of different types. Each file has a specific STEP2 Header (STEP2 standard) and is made of a
body of messages grouped into ‘bulks’, according to the proposed ISO 20022 standards.
The body will contain standard SWIFT message formats wherever possible so that standard software tools
can be used to parse and generate the files. EBA CLEARING is dedicated to the use of widespread
international standards. Where the application demands deviations from these standards these will be kept
to a minimum and clearly highlighted in the content and validation rules given in the appendices.
From time to time as additional services are introduced it may be necessary to modify the ISO file
specifications to support additional functionality. In order to insulate existing STEP2 participants from the
details of these changes until absolutely necessary STEP2 will examine the file name of the physical file and
take this as an indication of the format contained within it. This method gives EBA CLEARING the flexibility
to manage standards with the minimum of disruption to participants.
3.4.1 File Naming Conventions

STEP2 MPEDD service uses a set of naming rules for files that is similar to the one in place for the MPEDD
service.
STEP2 – M-PEDD
27th November 2009
3.4.1.1 Network File Names

The Network File Name is the identifier of the file as it is transferred over SWIFTNet.
STEP2 network filenames structures are as follows:
EEVVSSSBBBBBBBBX…X.Z
The meaning of these fields is as follows:
• EE must be S2 (STEP2);
• VV is the format version (02 = XML for files, fixed format for reports);
• SSS is the three character service identifier, “COR” for Core and “B2B” for B2B;
• BBBBBBBB is the BIC(8) of the Direct Participant;
• X…X (optional) is up to 15 characters for use by the Direct Participant; and
• Z indicates the type of the file, where:
I = IDF;
V = DVF;
N = DNF;
S = SDF;
R = RSF;
C = CDF;
P = PSR;
T = RTF;
B = MBP;
D = DRR; and
M = MSR.

STEP2 – M-PEDD
27th November 2009
All Direct Participants sending files to the STEP2 central system must adopt this convention. The X…X field
is not validated; however, network filenames must be unique during the processing of any value date,
otherwise they are rejected.
The STEP2 central system generates files with X…X fields as follows:
YYMMDDHHMMSSNNN, where:
• YYMMDDHHMMSS, which is the file creation date and time, and

• NNN, which is an incremental number starting from 000 that is reset to 000 every time DD (date)
changes (this number is global for all files sent by CS and not specific to a single DP).
Note that in the case of STEP2 generated files, the BIC part of the Filename (BBBBBBBB) is the BIC of the
Direct Participant (and not the STEP2 BIC).
The following standards apply to filenames:
• No leading spaces are allowed;

• No internal spaces are allowed;
• Trailing spaces are ignored; and
• Alpha characters are case insensitive, e.g. “filename” is the same as “FILENAME” and “Filename”.
3.4.1.2 Sender’s File Reference (SFR)

The Sender’s File Reference is a unique identifier that is carried in the header of the file. Banks are free to
use any reference as long as they comply with the following standards to Sender’s File References:

• Alpha characters are case insensitive, e.g. “reference” is the same as “REFERENCE” and
“Reference”.
The STEP2 central system generates SFRs of a specific format. When generating SFRs in their own
systems, Direct Participants must avoid clashes with this name-space. The format is:
ASSSYYMMDDNNNNNN, where:
A indicates the type of file:
• I – Input Debit File (IDF);

• V – Debit Validation File (DVF);
• P – Pre Settlement Report (PSR)
• N – Debit Notification File (DNF);
• S – Settled Debit File (SDF);
• C – Cancelled Debit File (CDF);
• R – Results Settlement File (RSF);
• T – Routing Table File (RTF);
• B – Multilateral Balancing Payments (MBP);
• D – Daily Reconciliation Report (DRR); and
• M – Monthly Statistics Report (MSR).
SSS is the three-character service identifier, “COR” for Core and “B2B” for B2B.
YYMMDD is the date of the generation of the file; and
NNNNNNNN is an incremental number that will restart from 00000001 every time DD, above, changes (this
number is global for all files sent by CS and not specific to a single DP).
The SFR of a file rejected in its entirety may be reused to resend the file. However, once a file has been
accepted in whole or part the SFR is registered within the STEP2 central system. Therefore, in order to
retransmit corrected transactions from a partially rejected file a new unique SFR is required.

STEP2 – M-PEDD
27th November 2009
3.5 File format and bulks

Input Debit Files (IDF), Debit Validation Files (DVF) and Debit Notification Files (DNF) are made of
messages bulks. These bulks must follow certain rules and guidelines to form a valid file to be processed by
STEP2 or the Participating banks.
• Bulks are always made of a header;

• Bulks can only contain a single type of message (ex: DD instructions, Refund, Reversals, etc);
• Bulks always have a unique identifier (MessageID);
• Transactions in a DD bulk must all have the same Interbank Settlement Date;
• Multiple bulks with same Settlement Date can be present in a single file; and
• Within a file containing different types of messages, bulks follow a specific order.
Bulks must be sorted in a file according to the XML in a particular order:
1. Debit Instructions;
2. Requests for Cancellation;
3. Rejects;
4. Reversals;
5. Refunds/Returns; and
For post-settlement R-messages, the Settlement Date is usually the date of the next available processing
cycle. For example, Refund messages sent on a date are expected to be settled on the following settlement
cycle. The rules of forming bulks according to the Interbank Settlement Date also apply to R-messages
bulks. As such, post-settlement R-messages will all be grouped in the same bulk, according to their type, as
they share the same Interbank Settlement Date. Pre-Settlement R-messages do not have an Interbank
Settlement Date and hence they must all be grouped into the same bulk (ie. one bulk for Requests for
Cancellation and one bulk for Rejects).
Example: Three Refund requests are sent on a specific day concerning original messages sent over a period
of two weeks with different original settlement dates. Because they are post-settlement R-messages, they
will all be grouped in the same bulk (Refund) as their own Settlement Date is the following settlement cycle.
There will be a total maximum number of bulks per files (all types of bulks, to be determined, see Appendix A
of Overview document).
3.6 XML Schemas

The STEP2 SDD service uses XML schemas to define the files and messages exchanged between the
Central System and the Participants. XML schemas define:
• Data fields to be used;

• Status (optional, mandatory, recurring, “Either/Or”);
• Formats of the information they contain; and
• Content – in some cases (e.g. code lists) the permitted codes are carried within the schema.
XML schemas can be distributed and quickly integrated into XML applications (an XML Parser) to
automatically generate validation code. This means that the STEP2 Central system and all bank’s
participant systems can perform validation using the same schema, to verify messages being
exchanged. This can be happen without the need to write long, linear validation programs, each one
based on the bank’s own interpretation of the standard.
All the XML validation on STEP2 SDD will be performed using the STEP2 SDD schemas. Direct
Participants will be expected to validate outgoing messages against these STEP2 SDD schemas and
not, for example, the ISO schemas.
It should also be noted as a feature of XML parsing that Schema errors that are found will cause the
rejection of an entire file sent to STEP2. As the bank has the opportunity to verify the entire file using the
same schema before sending to STEP2 this should in reality never happen.

STEP2 – M-PEDD
27th November 2009
The STEP2 schemas are a variant of the ISO 20022 schemas. They have been created by:
• Taking the original schemas

• Removing all the fields that STEP2 does not accept
• Where necessary changing the status of Optional fields to Mandatory or Conditional
Note: in the few cases where the Format differs between the ISO standard and the STEP2 standard the
schema has NOT been changed. In this case an additional check will be performed through a coded
check.
3.7 Validation of Input Debit Files

Once received by the STEP2 central system, IDFs are validated during STEP2 validation time window.
Banks can send input files at any time to the central system but validation will only occur during the validation
time window.
The file validation process has five phases:
1. The security-context (correspondence between BIC and Distinguished Name) and network file name
are checked;
2. Structural integrity verification, during which the basic structure and content of the IDF is verified
against the schemas;
3. Duplicate removal, during which the IDF’s details are compared against the details of files already
held by the STEP2 central system; and
4. Transaction validation, during which the individual transactions contained within the IDF are
validated against the validation rules specific to their format, including routing tables.
The precise details of the validation checks performed are defined in the appendices of this document.
If an IDF does not have perfect structural integrity or is found to be a duplicate, then it is rejected in its
entirety and no further validation or processing is performed on the file or any of the transactions that it
contains.
Errors discovered within transactions result in the erroneous payment instruction(s) being rejected and the
remaining valid transactions being carried forward for processing (this is referred to as “partial acceptance”).
However, a configurable ceiling (System Parameter) is placed on the maximum number of consecutive
transaction errors that will be tolerated at the beginning of a single bulk by the STEP2 central system. Once
the number of transaction errors discovered within a single bulk exceeds this ceiling the bulk is assumed to
be completely faulty and is rejected in its entirety and no further validation or processing is performed on the
bulk or any of the remaining transactions within it.
3.8 STEP2 Message Routing

STEP2 Central System will route all the valid messages it receives to the counterparty according to its
routing tables. This counterparty is referred to as the Instructed Agent.
For Debit Request, Requests for Cancellation and Reversals, the Instructed Agent is found using the Debtor
Agent BIC (creditor side).
For Rejections and Returns/Refunds, the Instructed Agent is found using the Original Creditor Agent BIC
contained in the copy of the original Debit instruction being Rejected/Refunded/Returned (debtor side).
3.8.1 Indirect Participant routing

The Routing of Debits & Post-Settlement R-messages is a step of validation process which establishes the
DP to be debited for this instruction.

STEP2 – M-PEDD
27th November 2009
The routing process for message originated from the Creditor side acts as follows:
1. Direct Participant Validation (BIC8)

STEP2 will check the first eight characters of the BIC against the Direct Participants list. If a match is
found, the transaction is routed to that Direct Participant. All BIC 11s that match with the first 8
characters of a Direct Participant BIC are valid. It is not possible to exclude individual branches. If a
matching for the Debtor Agent BIC(8) of the instruction being routed, is found within this table then:
• Transaction Routing is set to “DIR”,
• Instructed Agent is stored and equals the Debtor Agent of the transaction; otherwise
2. Indirect Participant Validation (BIC11)
If the previous validation was not successful, STEP2 will check the BIC11 against the Indirect
Participants list for an exact (BIC11) match. If a match is found, the transaction will be routed to the
corresponding Direct and then:
• Transaction Routing = “IND”,
• Instructed Agent = the Direct Participant associated through the Indirect Participant routing table
with the Indirect Participant identified in the Debtor Bank field of the transaction being routed;
otherwise
Note that a if a branch code is supplied in the Debtor Agent BIC(11) but the first 8 characters of this BIC
match a Direct Participant BIC(8) then test 1, above, will succeed and the transaction will be routed to the
matching Direct Participant.
3. Indirect Participant Validation (BIC8+XXX)

If there is still no match, STEP2 will check for a BIC8+XXX entry in the Indirect Participants list to match
the first eight characters of the BIC. If a match is found, the transaction will be routed to the
corresponding Direct Participant. The message may contain a BIC8 or a BIC11.
Please note that a BIC8 can be matched against this rule. For example, a Debtor Agent BIC8 could not
be present in the Direct Participant list but could match a BIC8+XXX rule in the Indirect Participant list.
4. No Match
The Debtor Bank is not known to the system, therefore:
• The transaction is rejected with error code PY01.
The routing process for message originated from the Debtor side is similar but will use the Creditor Agent
BIC instead of the Debtor Agent BIC.
3.9 Retransmission of output files

When requested, the STEP2 central system can re-transmit files to Direct Participants via operational
control. Files that are lost by a Direct Participant can therefore be recovered.
Such retransmission is manually initiated on the STEP2 central system following a request from a Direct
Participant. The mechanism of re-transmission is identical to that used for transmission of all files.

STEP2 – M-PEDD
27th November 2009
3.10 Sample File, message and bulks diagrams
1 IDF
€ BULK 1: Debits for Banks B and C
BULK 2: Debits for Bank B
Bank A
BULK 3: Debits for Bank C STEP2 Debit
Service
2a €
DNF
BULK 4: Debits from Bank A
STEP2 Debit Bank B

Service
2b €
DNF
BULK 5: Debits from Bank A
Bank C
STEP2 Debit
Service
3a RSF
€ BULK 1: Settled Debits for Banks B, C
BULK 2: Settled Debits for Bank B
BULK 3: Settled Debits for Bank C
Bank A STEP2 Debit
Service
3b €
RSF
BULK 4: Settled Debits from Bank A
STEP2 Debit Bank B

Service
3c €
RSF
BULK 5: Settled Debits from Bank A
Bank C
STEP2 Debit
Service
Figure 3-1: Settlement of Bulks

STEP2 – M-PEDD
27th November 2009
1. Bank A sends three bulks to STEP2. Bulk #1 contains a mix of debits for Banks B and C; Bulk #2
contains debits for Bank B only, and Bulk #3 contains debits for Bank C only.
2. STEP2 creates DNF files:

a. One DNF file with one bulk is created for Bank B; and
b. One DNF file with one bulk is created for Bank C.
3. After settlement, STEP2 creates RSF files:

a. 3 bulks corresponding to the 3 bulks received from Bank A;
b. 1 bulk corresponding to the single bulk sent to Bank B; and
c. 1 bulk corresponding to the single bulk sent to Bank C.

STEP2 – M-PEDD
27th November 2009
4. HOW TO USE THE APPENDICES

The data elements used in the STEP2 messages described in Appendix C. They are based on the
ISO20022 standards but do not allow all fields and options available within the ISO20022 standard.
Table Heading Description

The ISO20022 XML tag name used to identify the field. Where the
XML Element
field is nested under other tags, this nesting is shown.
The format of the field that is expected
4a - Four alpha characters (capital)
4n - Four digits
4x – Four characters (as defined in appendix A.2)
Format 4c – Four alphanumerical characters (capital letters)
4!a – Must be four alpha characters (and no less than four) in
capital
[3x] – Three optional characters
ISODate – YYYY-MM-DD
ISODateTime - YYYY-MM-DDThh:mm:ss
Whether the field is
M - Mandatory
O - Optional
Status C – Conditional further text will specify whether this field is
conditional on other fields being present.
If a field does not exist in the table, it cannot be used (i.e. a
message will be rejected if it is contained in the Input file, even if
the field exists in the full ISO20022 standard.
Rule Book reference Where the Data element exists in the SEPA Core and B2B Direct
Debit Rulebook, as cross-reference has been given.
This column details the validation that will be performed on the field.
Validation rules The first check is Schema Validation, and then subsequent checks
are performed as stated in the content of the fields.
Table 4-1 Appendices Usage
The fields have been defined by taking the ISO 20022 schema as a superset, the SEPA Core and B2B
Direct Debit rulebook (including the Implementation guidelines) as a subset and adding the fields
requested by the Banks designing the STEP2 MPEDD service.
The fields required by the SEPA Rulebook and Implementation guidelines are identified in yellow.

STEP2 – M-PEDD
27th November 2009
APPENDIX A FILES, BULKS AND MESSAGES

A.1 STEP2 MPEDD BULK TYPES
A.1.1 IDF Bulk messages
The Input Debit File may contain multiple bulks. The number is set by the bank, but is subject to a maximum
threshold. Each bulk will contain the same:
• Message Type, and

• Interbank Settlement Date.
A.1.2 DVF Bulk messages

For each Bulk received by STEP2, one Bulk Payment Status message is returned. An IDF containing 20
Bulks, will be answered by one and one only Debit Validation File containing exactly 20 Bulk Payment Status
Messages.
Each Bulk Payment Status Message will include the number and value of individual transactions received,
individual transactions accepted and individual transactions rejected.
The DVF sent to the sender of the IDF contains one bulk for every bulk received from that sender.
The Payment Status Bulk will contain zero or more transactions, one for each message from the original bulk
that failed validation.
In the case where the received bulk itself has failed validation, e.g. the total number of transaction in the bulk
header, does not equal the number of transactions in the body, then there will be a bulk rejection code, and
the individual transactions will not be separately listed.
A.1.3 DNF Bulk messages

The messages and bulks sent to the receiving Direct Participants are grouped by Interbank Settlement Date,
but there is not a one to relationship between the Bulk messages received by STEP2 and the Bulk messages
sent by STEP2.
Only pacs.003 (Debit requests), pacs.002 (Rejections), and pacs.006 (Request for cancellation) are
forwarded in a DNF.
A.1.4 RSF Bulk messages

The RSF file contains Payment Status messages relating to Debit Requests. RSFs are sent to both the
original sender and the original receiver of the Debit Requests.
The RSF sent to the sender of the Debit Request contains one bulk for every bulk received from that sender.
Each bulk contains:
• The number and value of the Debit requests from the original bulk that were received, validated, and
not subsequently rejected;
• The number and value of all Debit requests from the original bulk that were settled
• The number and value of all Debit requests from the original bulk that failed settlement.
The Payment Status Bulk will contain zero or more transactions, one for each Debit request from the original
bulk that failed settlement.
The RSF sent to the receiver of the Debit Request contains one bulk for every bulk sent to that sender. Each
bulk contains:

STEP2 – M-PEDD
27th November 2009
• The number and value of the Debit requests from the original bulk that were sent, and not
subsequently rejected;
• The number and value of all Debit requests from the original bulk that were settled
• The number and value of all Debit requests from the original bulk that failed settlement.
The Payment Status Bulk will contain zero or more transactions, one for each Debit request from the original
bulk that failed settlement.
A.1.5 SDF Bulk messages

The Settled Debits File contains post-settlement R messages that have been successfully settled by STEP2
and which are being delivered for the first time to the receiving direct participant.
The messages and bulks sent to the receiving Direct Participants are grouped by Interbank Settlement Date,
but there is not a one to relationship between the Bulk messages received by STEP2 and the Bulk messages
sent by STEP2.
Only pacs.004 (Returns/Refunds) and pacs.007 (Reversals) are forwarded in an SDF.
A.1.6 CDF Bulk messages

The messages in the CDF are status messages to inform the sender of a pacs.004 (Return/Refund) or
pacs.007 (Reversal) that the message has failed settlement.
The CDF sent to the sender of the Return/Reversal/Refund contains one bulk for every bulk received from
that sender with individual Payment Status Report messages for each original message.
Each Bulk contains:
• The number and value of the Return or Reversal requests from the original bulk that were sent to
TARGET2 for settlement;
• The number and value of all Returns or Reversal from the original bulk that failed settlement.
A.1.7 IDF Multiple Bulks and restrictions

Multiple bulks of the same type are allowed in the IDF file.
Bulks must be grouped by value date (Interbank Settlement Date). This implies having multiple bulks in the
same IDF file. However, banks are free to add other sorting conditions to bulks as long as the value date
condition is met. For example, a bank could sort debit instruction bulks by value date and debtor banks.
A.2 File Content Encoding

As per the SEPA Implementation Guidelines, STEP2 supports messages with the UTF-8 character set.
However, banks are required only to support the Latin character set.
abcdefghijklmnopqrstuvwxyz
ABCDEFGHIJKLMNOPQRSTUVWXYZ
0123456789
/-?:().,'+
Space
They can choose to receive transactions with non-Latin characters if this is subject to bilateral or multilateral
agreements amongst themselves. This will not be checked or controlled by STEP2.

STEP2 – M-PEDD
27th November 2009
A.3 Usage of Instructed and Instructing Agents

In the XML schema’s the Instructing Agent appears at both the Group Header and the Individual transaction
level. The rules for using these are described as follows.
IDF
IDF Field Level Status
Instructing Agent Group Header Mandatory
Individual Transaction Not Present
Instructed Agent Group Header Not Present
DVF
DVF Field Level Status
Instructing Agent Group Header Not Present
DNF and SDF

Fields Level Status
Individual Transaction Mandatory
Instructed Agent Group Header Mandatory
RSF (Sent to Instructed Agent)
Field Level Status

Instructed Agent Group Header Mandatory
RSF (Sent to Instructing Agent)
Field Level Status

CDF
Field Level Status

Individual Transaction Not present
Table 4-2 Usage of Instructing and Instructed Agent

STEP2 – M-PEDD
27th November 2009
A.4 Duplicate Checking

Every transaction must be uniquely identified within the system in order
i) to stop duplication of data,
ii) to find unambiguously one and one only data item when searching or matching.
In STEP2 the duplicate check is done by combining a set of fields to form a unique key. These fields are:
• The service
• The message type
• The reference of the item
• The identity of the entity that created the reference
And sometimes
• A business date
The business date is used when it is not certain that the reference created will be unique over time or not.
The following table gives the duplicate checking criteria for different files, bulks and transactions.
Message Reference
Service Bank ID Date
Type Number
Files Core/B2B - File Reference Sender -
Instructing
IDF Bulks Core/B2B - Msg ID -
Agent
STEP2
generate Core/B2B - Msg ID STEP2 BIC -
Bulks
Interbank
Debit Creditor
Core/B2B pacs.003 Transaction ID Settlement
Request Bank
Date
STEP2 Processing
Core/B2B pacs.002 Status ID STEP2 BIC
Reject Date
Original
Processing
Bank Reject Core/B2B pacs.002 Status ID Debtor
Date
Agent
STEP2 Processing
Core/B2B pacs.002 Status ID STEP2 BIC
Cancellation Date
Original
Request for Processing
Core/B2B pacs.006 Cancellation ID Creditor
Cancellation Date
Agent
Core/B2B Original Interbank
Return /
(only pacs.004 Return ID Debtor Settlement
Refund
Return) Agent Date
Original Interbank
Reversal Core/B2B pacs.007 Reversal ID Creditor Settlement
Agent Date
Table 4-3 - Duplicate Check
In each case:
• Service is taken from the header of the file;

• Message Type is taken from the MessageName xml tag of the iso message and;
• When checking for uniqueness, Identification fields are converted to upper-case characters.
Note that the Processing Date is the actual date on which the data is being received and processed by the
Central System (pre-settlement R-message do not have a Settlement Date).
During recovery scenarios, it is possible that the network will send and resend the same file to ensure
delivery. It is important that the application behind the network is able to detect if file received, is the same

STEP2 – M-PEDD
27th November 2009
file based on the duplicate checking criteria defined in Table 4-3. This includes the situation where a resend
occurs on a different day to the day on which the file was originally sent.
STEP2 is network independent application, and so it does not systematically use ‘Possible Duplicate’ flags to
warn a participant if a file is resent. In some circumstances, a possible duplicate flag may be automatically
set by the network middleware component, but the duplicate checking criteria defined in Table 4-3 take
precedence over the network based flag that may or may not be set.

STEP2 – M-PEDD
27th November 2009
A.5 BIC Validation

STEP2 checks the destination BIC against the Routing Table. In the case of a Request for Refund,
considerable time may have elapsed between the settlement of a Debit Message and the Request for
Refund, especially in the case of an unauthorized transaction.
The STEP2 Routing Table will contain, for all BICs that have changed or merged, the values of both the old
BIC and the new BIC. If the destination BIC has changed, the R-Message is therefore routed to the correct
BIC. Note that this lookup will not apply to Debit Messages, which should be submitted with the correct BIC
in the first place.
If the Indirect Participant leaves the system, STEP2 will allow the Indirect Participant to be registered with an
R-message-only status so that the refund period can be met. The Direct Participant is responsible for
instructing EBA CLEARING how to provision their Indirect Participant. The Indirect Participant, as a scheme
adherent is responsible for ensuring they meet their Rulebook commitments
The status R-ONLY means that a Participant is no more able to send or receive Direct Debits, but it is still
able to send and receive post settlement R-Messages. Direct Debits will be rejected when the Settlement
Date of the pacs.003 is greater or equal to the Initial Date of the new Status. Any pacs.003 received and
successfully validated by Step2 CS for/from the DP/IP before the status change will be normally processed,
settled and delivered to the counterpart.
The new R-ONLY status will be managed by the validation process as follows.
For the Creditor Bank BIC and the Debtor Bank BIC STEP2 will check that:
the BIC exists in the Routing Table
the status is Enabled
the Interbank settlement Date of the collection is between the Initiation Date and the End Date
the BIC has subscribed to the correct service (B2B or Core)
The STEP2 Debit Service will check the BIC when the message is received (say on D-14) but not again
when it is forwarded (say on D-2). It will be the responsibility of the Receiving Direct Participant to manage
any issues if BICs change between the time they are sent by the Sending Direct Participant and the time
they are received by the Receiving Direct Participant.
The type of rejection will depend on which participant is in R-ONLY status related to pacs.003:
Participant Rejection Type Reason Code

Creditor Agent of pacs.003 Tx Single DD Tx Rejection XT80
Debtor Agent pacs.003 Tx Single DD Tx Rejection XT79
A.5.1 R-Messages
For the Original Creditor Bank BIC and the Original Debtor Bank BIC STEP2 will check that:
the BIC exists in the Routing Table
the status is Enabled or “R-Message-Only”
the Interbank settlement Date of the r-message is between the Initiation Date and the End Date
the BIC has subscribed to the correct service (B2B or Core)

STEP2 – M-PEDD
27th November 2009
A.6 Creditor Scheme Identification format

The Creditor is identified by an identifier as defined below. The creditor can be a legal entity, or an
association that is not a legal entity, or a person.
This identifier must be stable over time, to enable the Debtor and the Debtor Bank to comeback to the
Creditor for Refunds and complaints, and to check the existence of a valid
Mandate at the presentation of Collections by the Creditor.
The Creditor identifier has the attributes defined in the Rulebook under AT-02.
The STEP2 CS performs the format content according to the ISO 7064 and is detailed as follows:
• Positions 1 and 2 contain the ISO country code;

• Positions 3 and 4 contain the check digits;
• Positions 5 to 7 contain the Creditor Business Code. When the Creditor Business Code isnot used, then the
value is set to ‘ZZZ’ and;
• Positions 8 up to 35 contain the country-specific identifier.
Note: the calculation of the check digit requires the following preliminary steps:
• Disregard positions 5 to 7;
• Take the country-specific part, positions 8 to 35, and delete all non-alphanumeric characters;
• Add the ISO country code and ‘00’ to the right-hand end;
• Convert letters to digits in accordance with the conversion table below and;
• Apply the check character system MOD 97-10 (see ISO 7064).
A = 10 G = 16 M = 22 S = 28 Y = 34
B = 11 H = 17 N = 23 T = 29 Z = 35
C = 12 I = 18 O = 24 U = 30
D = 13 J = 19 P = 25 V = 31
E = 14 K = 20 Q = 26 W = 32
F = 15 L = 21 R = 27 X = 33
Table 4-4 SEPA Direct Debit Implementation Guidelines
A.7 Message ID
The Message Id is a unique identifier that is carried in the header of the bulk. Banks are free to use any
reference as long as they comply with the following standards to Message ID:

• Alpha characters are case insensitive, e.g. “reference” is the same as “REFERENCE” and
“Reference”.
The STEP2 central system generates Message ID of the output bulks. The format is:
ASSSYYMMDDNNNNNNNNNNNNNNNNNNNNNNNNN where:
A indicates the type of file:
• V – Debit Validation File (DVF);
• N – Debit Notification File (DNF);
• S – Settled Debit File (SDF);

STEP2 – M-PEDD
27th November 2009
• C – Cancelled Debit File (CDF);
• R – Results Settlement File (RSF);
SSS is the three-character service identifier, “COR” for Core and “B2B” for B2B;
YYMMDD is the date of the generation of the bulk;
NNNNNNNNNNNNNNNNNNNNNNNNN is an internal unique reference number
The Message ID of a bulk rejected in its entirety may be reused to resend the file. However, once a bulk has
been accepted in whole or part the Message ID is registered within the STEP2 central system. Therefore, in
order to retransmit corrected transactions from a partially rejected bulk a new unique Message ID is required.
A.8 Validation process of R-messages against direct debits

All transactions have certain key fields that uniquely identify them. These are generally the Interbank
settlement Date, the transaction ID, Service (B2B or Core) and the Creditor Agent of the Debit Colllection..
The key fields of the message create a unique key that can be used to find a particular message. R
messages carry with them, the unique key of the Debit collection to which they relate. STEP2 can find the
original Debit Collection to which an R message relates, if that Debit message has already passed through
STEP2, and as long as it has not been archived. This is known as ‘matching’. n.b. matching an R message
to an original transaction, simply means that a Debit collection with the correct Key fields was found. It does
not imply that STEP2 has cross checked that all the amounts, account numbers, remittance information or
other data are the same.
STEP2 hold three months data on line. After this time, the data is archived. Matches will only be successful if
the R message arrives within 3 months of the Settlement of the Original Debit.
The validation of R-messages against a direct debit will be done as follow:
The validation of R-messages against a direct debit will be performed as follow:
Pre-settlement R-messages: Reject and Request for Cancellation

The R-message will be validated against the schema, the security checks and the basic business rules.
If the R-message is not rejected,
Then the R-message will be matched against the Debit Collection
A successful match is where the Original Debit Collection is found using the following fields:
• Service (B2B or Core)

• Interbank settlement Date
• Transaction ID
• Creditor Agent of the Debit Collection
If there’s a match (no match error code XT74)
The Original Interbank Settlement Amount (in the R-message) should be the same as the Interbank
Settlement Amount (in the Matched Debit Collection) (error code XT77)
If yes,
The status of the initial Debit collection must be different than rejected or cancelled (error code XT75)
STEP2 – M-PEDD
27th November 2009
If yes the validation is successful.
Post-Settlement R messages: Return/Refund and Reversal

The R-message will be validated against the schema, the security checks and the basic business rules.
If the R-message is not rejected,
Then the R-message will be matched against the Debit Collection
A successful match is where the Original Debit Collection is found using the following fields:
• Service (B2B or Core)

• Interbank settlement Date,
• Transaction ID
• Creditor Agent of the Debit Collection
If there’s a match => Go to paragraph below: Post-Settlement R messages (Matched)

If there’s no match => Go to the paragraph below: Post-Settlement R messages (Unmatched)
Post-Settlement R messages (Matched)

The system will verify the following:
A. That the status of the Debit collection must be different reversed, returned or refunded? (error code
XT75)
B. Is the Original Interbank Settlement Amount (in the R-message) the same as the Interbank Settlement
Amount (in the Matched Debit Collection?) (error code XT77)
C. (For Refunds and returns) In the message, is the Returned Interbank Settlement Amt equal to the
Original Interbank Settlement Amount + Compensation Amount? (error code XT78)
If the answers to all the above questions are ‘Yes’ then the message is processed.
If any of the above is ‘No’ the message is rejected.
Post-Settlement R messages (Unmatched)

The system will verify the following:
A. Is the Returned Interbank Settlement Amt (in the message) equal to the Original Interbank Settlement
Amt (in the message) + the Compensation Amount (in the message)? (error code XT78)
B. Is the Reversed Interbank Settlement Amount (in the message) equal to the Original Interbank
Settlement Amt (in the message)?
If the answers to the above questions are ‘Yes’ then the message is processed.
If any of the above is ‘No’ the message is rejected.
If a match is not found and the post-settlement R message is accepted it will be settled and delivered to the
bank. In the SDF files delivered to the recipient Bank, for the pacs.004 and pacs.007 of unmatched DDs the
field OrgnlGrpInf/OrgnlMsgId are generated by STEP2 CS with the following naming convention:
“UNMATCHED”.

STEP2 – M-PEDD
27th November 2009
A.9 Validation of Original Message Id
Following ISO rules a set of Debit transactions must be using the same number of R messages as the set
arrived in, except for the return. If 20 different Direct Debits are sent in 20 different pacs.003 (with 20
different MsgIDs) then following number of R messages are needed.
Pacs.004 – 1 Return message can contain 20 Return transactions
Pacs.006 – 20 Cancellation messages needed.
Pacs.007 – 20 Reversal messages needed.Reversal.
Pacs.002 – 20 Rejection messages needed.
If the sending bank ignores the ISO rule and sends to STEP2 then the following can apply.
Pacs.004 – 1 Return message can contain 20 Return transactions.
Pacs.006 – 1 Cancellation message needed containing 20 Cancellation transactions.
Pacs.007 – 1 Reversal message needed containing 20 Reversal transactions.
Pacs.002 – 1 Rejection message needed containing 20 Reject transactions
STEP2 does not validate that the Original Message ID in the R message, is the Message ID that was
originally used in the original PACS.003.
Note, that in no case does the choice of the sending bank, affect how the receiving bank will process the
message, as STEP2 will rebulk the transactions.
A.10 Bulking R-messages

STEP2 Sending to banks
STEP2 will create a new bulk for each Original Message ID for pacs.006, pacs.002 and pacs.007 as the ISO
standard only allows one ‘Original Message ID’ per bulk for these messages. The pacs.004 allows multiple
Message ID’s for each bulk. This if further explained below.
Pre-settlement R-messages in a DNF will be created as follows:

Pacs.006 – 1 Cancellation message (bulk) will be created for each Cancellation request that is delivered to
the bank where the original pacs.003 Debit collection was delivered in a different bulk. For example, If debits
collections were delivered in 5 pacs.003 messages, there will be 5 pacs.006 messages.
Pacs.002 – 1 Rejection message (bulk) will be created for each Rejection message that is delivered to the
bank where the original pacs.003 Debit collection was delivered in a different bulk. For example, If 5 debit
collections were delivered in 5 pacs.003 messages, there will be 5 pacs.002 messages.
Post-settlement R messages in an SDF will be created as follows:

Pacs.007 (matched) – 1 Reversal message (bulk) will be created for each Reversal message that is
delivered to the bank where the original pacs.003 Debit collection was delivered in a different bulk. For
example, If 5 debit collections were delivered in 5 pacs.003 messages, there will be 5 pacs.007 messages,
assuming all the Reversal matched.
Pacs.007 (unmatched) – Where Reversal messages do not match with the original transaction they will all be
mixed together in a pacs.007 with an original message ID showing they were unmatched.
Pacs.004 – 1 There will be one pacs.004 message created for all Debit Collections Returned or Refunded,
as the Original Message ID is stored with each transaction.
Pacs.004 – 1. There will be one pacs.004 message created for all Reversals Returns. The Original message
ID will be the one sent by the bank in the IDF.
A.11 Bulk Rejection actions

STEP2 – M-PEDD
27th November 2009
In point to point scenarios, ISO20022 allows banks to instructions such as ‘Reject all the pacs.003
instructions that I received in Bulk number 5’. This is known as Bulk rejection functionality. In the same way
Bulk Cancellation, Bulk Return functionality can be imagined.
In a CSM environment this does not make sense as the central system splits up the bulks that are received,
so there is never a need to reject all the messages that were received.
STEP2 CS does not allow the possibility to send R-Messages in order to perform a relevant action on the
entire original DD bulk. The R-message bulk must always include the single transaction related to the original
DD that is to be rejected / cancelled / returned etc.
A.12 R-Message conflicts
It may happen that both parties of the transaction become aware that a Direct Debit needs to be cancelled or
rejected at the same time. For example, the Creditor Bank may send a Request for Cancellation and the
Debtor Bank may send a Reject for the same debit, prior to settlement. In this case the STEP2 SDD will
process the first message received according to the timestamp of the message, and reject the second
message, since they have the same effect and only one action needs to be performed.
In the same way, if a Reversal message and a Refund or Return message (post-settlement messages) have
been received for the same original debit, the first message received according to its timestamp is
processed. Second and subsequent messages are rejected.

STEP2 – M-PEDD
27th November 2009
APPENDIX B TABLE STEP2 FILE HEADERS

B.1 Input Debit File STEP2 File Header
Status Field Name XML Element Format Notes

The BIC of the Direct Participant
M Sending Institution SndgInst 4!a2!a2!c
sending the file.
M Receiving Institution RcvgInst 4!a2!a2!c The STEP2 CS BIC code.
The Direct Participant reference of the
M File Reference FileRef 16!c
IDF.
Must be “COR” for Core or “B2B” for
M Service Identifier SrvcId 3!a
B2B (Error code R17)
Must be always “T” or “P”, depending on
M Test Code TstCode 1!a
the environment used
M File Type FType 3!a Must be always “IDF”
ISODateTi
M File Date and Time FDtTm The file creation Date and Time
me
Number of PACS.003
M NumDDBlk 8n The total number of debit requests bulks
Debit Requests bulks
Number of PACS.006
The total number of requests for
M Requests for NumRFCBlk 8n
cancellation bulks
Cancellation bulks
Number of PACS.002
M NumREJBlk 8n The total number of rejects bulks
Reject bulks
Number of PACS.007
M NumRVSBlk 8n The total number of reversals bulks
Reversals bulks
Number of PACS.004 The total number of return/refund
M NumRFRBlk 8n
Returns/Refunds bulks requests bulks
Number of
The total number of return reversals
M PACS.004.002 NumRRVBlk 8n
bulks. Must be set to zero.
Return of Reversal bulks
Table 4-5 IDF STEP2 File Header Elements
B.2 Debit Validation File STEP2 File Header

The DVF uses the PACS.002 to inform the bank about the status of messages sent in an IDF.

Sending
M SndgInst 4!a2!a2!c The STEP2 CS BIC code.
Institution
Receiving The BIC of the Direct Participant
M RcvgInst 4!a2!a2!c
Institution sending the file.
The STEP2 3 characters service
Service
M
Identifier
SrvcId 3!a identifier “COR” for Core or “B2B” for
B2B.
Equals always to “T” or “P”, depending
on the environment used
M File Type FType 3!a Equals always to “DVF”.
M File Reference FileRef 16!c The STEP2 reference of the DVF
File Date And The Date & Time in which this file was
M
Time
FileDtTm ISO Date generated by STEP2 CS

STEP2 – M-PEDD
27th November 2009

The Original IDF Reference; in
circumstances where it has not been
Original IDF
C
Reference
OrigFRef 16!c possible to gather this information
Original IDF Reference will not be
present.
Original IDF File
M
Name
OrigFName 32x The Original IDF Network file Name.
In circumstances where it has not

been possible to gather this
information OrigDtTm will not be
present.
Original Date
C
And Time
OrigDtTm ISO Date In DVFs that contain rejected
transactions the contents are
duplicated in the CreationDate
element in the Header (which contains
information from the original IDF).
The IDF error code showing whether
the IDF was Accepted or Rejected.
M IDF Error Code IdfErrCd 3!c The Rejected error code shows the
Rejection reason. See Appendix D
The business date in which this file
File Business
M FileBusDt ISO Date was created by the STEP2 central
Date
system.
File Cycle The cycle in which this file was
M FileCycleNo 2!n
Number created by the STEP2 central system.
Table 4-6 DVF STEP2 File Header Elements
B.3 Debit Notification File STEP2 File Header

Sending
Institution
Receiving The BIC of the Direct Participant receiving
Institution the file.
M Service Identifier SrvcId 3!a Must be “COR” for Core or “B2B” for B2B
Must be always “T” or “P”, depending on the
environment used
M File Type FType 3!a Must be always “DNF”.
M File Reference FileRef 16!c The DNF file reference
File Business The business date when this file was
M FileBusDt ISODate
Date created
The routing Indicator
Routing DIR: Direct Participant File
M RoutingInd 3!a
Indicator IND: Indirect Participant File
ALL: Both
File Cycle The cycle in which this file was created by
M FileCycleNo 2!n
Number the STEP2 central system.
Number of
The total number of debit requests bulks
M PACS.003 Debit NumDDBlk 8n
notified in this file
Requests bulks
Number of
PACS.006
The total number of requests for
M Requests for NumRFCBlk 8n
cancellation bulks notified in this file
Cancellation
bulks
M Number of NumREJBlk 8n The total number of rejections bulks notified

PACS.002
STEP2 – M-PEDD
27th November 2009
Rejections bulks in this file

Table 4-7 Debit Notification File STEP2 File Header Elements
B.4 Response to Settlement File STEP2 File Header

Sending
Institution
Receiving The BIC of the Direct Participant
Institution receiving the file.
The STEP2 3 characters service
Service
M
Identifier
SrvcId 3!a identifier “COR” for Core or “B2B” for
B2B
M File Type FType 3!a Equals always to “RSF”.
M File Reference FileRef 16!c The STEP2 reference of the File
Routing DIR: Direct Participant File
M RoutingInd 3!a
Indicator IND: Indirect Participant File
ALL: Both
The business date in which this file
File Business
M FileBusDt ISO Date was created by the STEP2 central
Date
system.
File Cycle The cycle in which this file was
M FileCycleNo 2!n
Number created by the STEP2 central system.
Table 4-8 Response to Settlement File STEP2 File Header Elements
B.5 Settled Debit File (SDF) STEP2 File Header

M Sending Institution SndgInst 4!a2!a2!c The STEP2 CS BIC code.
M Receiving Institution RcvgInst 4!a2!a2!c
receiving the file.
B2B.
on the environment used.
M File Type Ftype 3!a Equals always to “SDF”.
M File Reference FileRef 16!c Must be the STEP2 reference of the file.
DIR: Direct Participant File
M Routing Indicator RoutingInd 3!a
IND: Indirect Participant File
ALL: Both
The business date in which this file was
M File Business Date FileBusDt ISO Date
created by the STEP2 central system.
The cycle in which this file was created
M File Cycle Number FileCycleNo 2!n
by the STEP2 central system.
Table 4-9 Settled Debits File STEP2 File Header Elements
B.6 Cancelled Debits File (CDF) STEP2 File Header

M Sending Institution SndgInst 4!a2!a2!c The STEP2 CS BIC code.

STEP2 – M-PEDD
27th November 2009

M Receiving Institution RcvgInst 4!a2!a2!c
sending the file.
B2B
M File Type FType 3!a Equals always to “CDF”.
M File Reference FileRef 16!c Must be the STEP2 reference of the file.
The business date in which this file was
M File Business Date FileBusDt ISO Date
created by the STEP2 central system.
The cycle in which this file was created
M File Cycle Number FileCycleNo 2!n
by the STEP2 central system.
Table 4-10 Cancelled Debits File STEP2 File Header Elements

STEP2 – M-PEDD
27th November 2009
APPENDIX C STEP2 USAGE OF XML MESSAGES

C.1 STEP2 Usage of PACS.003: Financial Institution to Financial Institution Customer Direct Debit
C.1.1 PACS.003 (Debit Collection) used in IDF and DNF – Group Header
XML Element Format Status Rule Book Ref Validation Rules

GrpHdr 35x M NA IDF:The DP’s bulk reference
+MsgId • Uniqueness is checked for IDF: error code B14.
DNF: STEP2’s bulk reference.
The identification cannot include leading, trailing or internal spaces (schema validation)
GrpHdr ISODate M NA The date & time in which this bulk was created by the DP.
+CreDtTm &Time
GrpHdr 15n M NA The number of transactions included in this bulk.
+NbOfTxs • Schema validation;
• Must not be greater than the Maximum Number Of Transaction parameter: error code
B02; and
• Must be the total number of transactions included in this bulk: error code B03.
GrpHdr 18d&3!a M NA The total amount of transactions inside this bulk.
+TtlIntrBkSttlmAmt • Values are supported with up to 15 digits in the integer part and up to 2 fraction digits
(schema validation)
• Currency attribute is always “EUR” (schema validation)
• Must equal the sum of individual transactions inside the bulk: error code B05.
• Amount must be greater than zero (error code B13)
GrpHdr ISODate M AT-26 The business date in which the transactions inside this bulk must be settled in the relevant
+IntrBkSttlmDt settlement mechanism.
• Must be a Target Date and in the allowed range : Error code B15
GrpHdr 4!a M NA Information on settlement method.
+SttlmInf • Only the value “CLRG” is supported: schema validation.
++SttlmMtd

STEP2 – M-PEDD
27th November 2009
XML Element Format Status Rule Book Ref Validation Rules

GrpHdr 3!a M NA The Identifier of the the Clearing System.
+SttlmInf
++ClrSys Proprietary identification of the Clearing System.
+++Prtry Value is ‘ST2’. Error code B16.
GrpHdr 4!a2!a2! C NA Used only in IDF: error code B10
+InstgAgt c The DP originating this bulk.
++FinInstnId Must equal SndgInst element in IDF and must not contain a branch code: error code B10.
+++BIC
GrpHdr 4!a2!a2! C NA Used only in DNF: error code B11
+InstdAgt c The DP receiving this bulk.
++FinInstnId • Equal RcvgInst element in DNF
+++BIC
Table 4-11 PACS.003 (Debit Collection) used in IDF and DNF – Group Header

STEP2 – M-PEDD
27th November 2009
C.1.2 PACS.003 (Debit Collection) used in IDF and DNF –Individual Debit Instruction IDF/Notification in DNF
XML Acronym Format Status Rule Book
Validation Rules
Ref
DrctDbtTxInf 35x O NA
The Instruction Id.
+PmtId
This identification cannot include leading, trailing or internal spaces. (schema validation)
++InstrId
DrctDbtTxInf 35x M AT-10 The End to End Id.
+PmtId • In the case it is not available, the value must be NOTPROVIDED. This is not
++EndToEndId validated by STEP2.
DrctDbtTxInf 35x M AT-43 The Transaction Id:
+PmtId • Uniqueness is checked under the rules for duplicate checking: error code AM05.
++TxId
• This identification cannot include leading, trailing or internal spaces. (schema
validation)
DrctDbtTxInf 4!a M AT-20
+PmtTpInf The Service Level:
++SvcLvl • Must be “SEPA”: (schema validation)
+++Cd
DrctDbtTxInf 35x M NA
+PmtTpInf The indication of the scheme or service:
++LclInstrm • Values allowed are found in the Product Table, CORE or B2B, depending on the relevant
+++Cd service: error code XT33
DrctDbtTxInf 4!a M AT-21 • Accepted values are FRST, OOFF, RCUR, FNAL
+PmtTpInf
• If “Amendment Indicator” is “TRUE” and Original Debtor Agent is set to “SMNDA” to
++SeqTp
indicate same mandate with new Debtor Agent, this field must indicate “FRST”:
error code XD75.
DrctDbtTxInf 4!a O AT-59
+PmtTpInf The category purpose.
++CtgyPurp

STEP2 – M-PEDD
27th November 2009

Validation Rules
Ref
DrctDbtTxInf M AT-06 The amount of this transaction.
+IntrBkSttlmAmt 18d M • The Currency attribute must be “EUR”: (schema validation)
Attribute 3!a
• The number of digits following the decimal point in Interbank Settlement Amount
must not exceed the maximum number allowed for the EUR currency: (schema
validation)
• Must not be zero: error code AM01
• Must not exceed the Maximum Amount per Debit Product parameter: error code
AM02;
Possible usage for amending existing mandates and Creditor/Debtor Mandate Flow when
standards are available.
DrctDbtTxInf 18d O NA
+InstdAmt 3!a • The Instructed Amount
Attribute
DrctDbtTxInf 11d O NA
• The Exchange rate of the Direct Debit.
+XchgRate
DrctDbtTxInf 4!a M NA
• Only SLEV is allowed: (schema validation)
+ChrgBr
DrctDbtTxInf
+ChrgsInf 18d O NA
• The Charges Amount
++ChrgsAmt 3!a C
Attribute
DrctDbtTxInf 4!a2!a2!c[3!c] O NA
+ChrgsInf
++ChrgsPty • The Charges Party
+++FinInstnId
++++BIC
DrctDbtTxInf ISO DATE M AT-11 • Must be greater than or equal to First Submission Date;
+ReqdColltnDt
• Must be less than or equal to Last Submission Date;
• Must be equal to the “Interbank Settlement Date” or between one business (Target)
day and the following
Error code: DT01

STEP2 – M-PEDD
27th November 2009

Validation Rules
Ref
DrctDbtTxInf 35x M AT-01 The unique MandateID
+DrctDbtTx • Leading and trailing spaces inside the MndtId field are not significant and are
++MndtRltdInf removed before storing the Mandate Identifier content in the CS Database.
+++MndtId
For Debit Product requiring Mandate DB checking:
• Must not be present in the Mandate Repository if SeqTp equals first or one-off:
MD01
• Must be present in the Mandate Repository if SeqTp equals recurring or final: MD01
DrctDbtTxInf ISO DATE M AT-25
+DrctDbtTx
• The Date of Signature of the Mandate
++MndtRltdInf
+++DtOfSgntr • Not checked by STEP2 Central System
DrctDbtTxInf Boolean O NA • If is set to “true” at least one of the following 6 fields must be present: error code
+DrctDbtTx XT13;
++MndtRltdInf
+++AmdmntInd • If is set to “false” none of the following 6 fields must be present: error code XT13.
DrctDbtTxInf 35x C AT-19
+DrctDbtTx
++MndtRltdInf
+++AmdmntInfDtls • Conditional on Amendment Indicator (see above): error code XT13.
++++OrgnlMndtId
+DrctDbtTx
++MndtRltdInf
• Conditional on Amendment Indicator (see above): error code XT13
+++AmdmntInfDtls
++++OrgnlCdtrSchmeId
+++++Nm

STEP2 – M-PEDD
27th November 2009

+DrctDbtTx
++MndtRltdInf
+++AmdmntInfDtls
+++++Id • Conditional on Amendment Indicator (see above): error code XT13
++++++PrvtId
+++++++OthrId
++++++++Id
+DrctDbtTx
++MndtRltdInf
+++AmdmntInfDtls • Conditional on Amendment Indicator (see above): error code XT13;
+++++Id • Used only if OrgnlCdtrSchmeId is used; and
++++++PrvtId • Must be SEPA: (schema validation)
+++++++OthrId
++++++++IdTp
DrctDbtTxInf 2!a2!n30x C NA
+DrctDbtTx
++MndtRltdInf
+++AmdmntInfDtls
++++OrgnlDbtrAcct • Conditional on Amendment Indicator (see above): error code XT13
+++++Id
++++++IBAN
DrctDbtTxInf 35x C NA
+DrctDbtTx
++MndtRltdInf • Conditional on Amendment Indicator (see above): error code XT13;
+++AmdmntInfDtls
++++OrgnlDbtrAgt • Must equal “SMNDA” (error code XT13);
+++++FinInstId • To be used with a FRST indicator in the sequence type if SMNDA is used. Error
++++++PrtryId code XT33.
+++++++Id

STEP2 – M-PEDD
27th November 2009
DrctDbtTxInf 1025x O AT-16 Placeholder for Electronic Signature

+DrctDbtTx AT-17 (AT-16 Placeholder for the Electronic Signature
++MndtRltdInf AT-60 Data, if applicable)
+++ElctrncSgntr
(AT-17 Type of Mandate (paper, e-Mandate)
(AT-60 Reference of the validation made by the
Debtor Bank (if present in DS-03))
Usage Rule: If the direct debit is based on an electronic mandate, this data element must
contain AT-60 which is the reference to the Mandate Acceptance report made by the Debtor
Bank.
Usage Rule: This element is not to be used if the
mandate is a paper mandate.
DrctDbtTxInf 35x M AT-02
+DrctDbtTx • Validated as per format detailed in A.6: Error code XT33.
++CdtrSchmeId
+++Id • Note that usage of PrivateId/OtherId applies both for organisations and institutions
++++PrvtId (as per EPC DD Implementation Guidelines recommendations)
+++++OthrId
++++++Id
DrctDbtTxInf 35x M NA
+DrctDbtTx
++CdtrSchmeId
+++Id • Must be “SEPA”: (schema validation)
++++PrvtId
+++++OthrId
++++++IdTp
+Cdtr • The Name of the Creditor
++Nm
DrctDbtTxInf 70x O AT-05
+Cdtr
• Address line can have a maximum of two occurrences: (schema validation)
++PstlAdr
+++AdrLine
DrctDbtTxInf 2!a C AT-05 • Country of the Creditor address.
+Cdtr
• Must be a valid country code according to ISO3166. Error code: XT73
++PstlAdr
+++Ctry • Mandatory if Address Line is used (schema validation)

STEP2 – M-PEDD
27th November 2009
DrctDbtTxInf 2!a O NA • The Creditor Country of Residence.

+Cdtr
++CtryOfRes • Must be a valid country code according to ISO3166. Error code: XT73
DrctDbtTxInf 2!a2!n30x M AT-04 • First two characters must be a valid country code according to ISO3166. Error
+CdtrAcct code: XT73
++Id
• First two characters must be a valid SEPA country code
+++IBAN
• Must pass validation using ISO 13616: error code XD19.
DrctDbtTxInf 4!a2!a2!c[3!c] M AT-12 • Must be an active DP or IP: error code PY01; and
+CdtrAgt
• Indirect Participant must be configured in Central System as being associated to a
++FinInstId
Direct Participant which is equal to the Instructing Agent : error code PY01; and
+++BIC
• The Creditor Agent must be allowed to send DD as per service configuration: error
code XT80
+UltmtCdtr • The Ultimate Creditor Name
++Nm
DrctDbtTxInf 70x O NA Address line can have a maximum of two occurrences. (schema validation)
+UltmtCdtr
++PstlAdr
+++AdrLine
DrctDbtTxInf 2!a C NA Country of the Ultimate Creditor
+UltmtCdtr
++PstlAdr
+++Ctry
DrctDbtTxInf See Schemas C AT-39 The identification of the Ultimate Creditor: Organisation Id.
+UltmtCdtr Cannot be used at the same time as Id/PrvtId (below) (schema validation)
++Id All of the ISO options are available (see ISO document or schema).
+++OrgId
DrctDbtTxInf See Schemas C AT-39 The identification of the Ultimate Creditor: Private Id.
+UltmtCdtr Cannot be used at the same time as Id/OrgId (above) (schema validation)
+++PrvtId
DrctDbtTxInf 2!a O NA The Country of Residence of the Ultimate Creditor.
+UltmtCdtr
++CtryOfRes

STEP2 – M-PEDD
27th November 2009
DrctDbtTxInf 4!a2!a2!c C NA • The DP originating this Direct Debit

+InstgAgt • Used in DNF only: error code XT13
++FinInstnId
+++BIC
+Dbtr • The Name of the Debtor.
++Nm
+Dbtr
• Address line can have a maximum of two occurrences: (schema validation)
++PstlAdr
+++AdrLine
DrctDbtTxInf 2!a C AT-09 • Country of the Debtor address.
+Dbtr
• Must be a valid country code according to ISO3166. Error code : XT73
++PstlAdr
+++Ctry • Mandatory if Address Line is used (schema validation)
DrctDbtTxInf See Schemas C The identification of the Debtor : Organisation ID
+Dbtr
AT-27
++Id If used, cannot be used at the same time as Id/PrvtId (below) (schema validation)
+++OrgId All of the ISO options are available (see ISO document or schema)
DrctDbtTxInf See Schemas C The identification of the Debtor: Private ID.
+Dbtr
AT-27
++Id If used, cannot be used at the same time as Id/OrgId (above) (schema validation).
+++PrvtId All of the ISO options are available (see ISO document or schema)
DrctDbtTxInf 2!a O NA
+Dbtr
++CtryOfRes • If present the country must be valid according to ISO 3166: error code XT73.
DrctDbtTxInf 2!a2!n30x M AT-07 • Must pass validation using ISO 13616: error code XD19; and
+DbtrAcct
• First two characters must be a valid SEPA country code
++Id
+++IBAN • First two characters must be valid according to ISO 3166: error code XT73.
DrctDbtTxInf 4!a2!a2!c[3!c] M AT-13 • Must be an active DP or IP: error code PY01; and
+DbtrAgt
++FinInstnId • The Debtor Agent must be allowed to receive DD as per service configuration: error
+++BIC code XT79
+UltmtDbtr • The Ultimate Debtor Name
++Nm
STEP2 – M-PEDD
27th November 2009
DrctDbtTxInf 70x O NA • Address line can have a maximum of two occurrences. (schema validation)
+UltmtDbtr
++PstlAdr
+++AdrLine
DrctDbtTxInf 2!a C NA • Country of the Ultimate Debtor
+UltmtDbtr
++PstlAdr
+++Ctry
DrctDbtTxInf See Schemas C AT-37 The identification of the Ultimate Debtor: Organisation Id.
+UltmtDbtr Cannot be used at the same time as Id/PrvtId (below) (schema validation)
+++OrgId
DrctDbtTxInf See Schemas C AT-37 The identification of the Ultimate Debtor: Private Id.
+UltmtDbtr Cannot be used at the same time as Id/OrgId (above) (schema validation)
+++PrvtId
DrctDbtTxInf 2!a O NA The Country of Residence of the Ultimate Debtor.
+UltmtDbtr
++CtryOfRes
DrctDbtTxInf 35x O AT-58 The Purpose of the transaction
+Purp Cannot be used at the same time as Proprietary (below) (schema validation)
++Cd
Codes are based on external list definition. This is not checked by STEP2.
DrctDbtTxInf 35x O AT-58 The Purpose of the transaction (Proprietary)
+Purp Cannot be used at the same time as Code (above) (schema validation)
++Prtry
NOTE: STEP2 CS will not validate and/or reject this white field
+RgltryRptg • Part of the Regulatory Reporting
++DbtCdtRptgInd
+RgltryRptg
• Part of the Regulatory Reporting
++Authrty
+++AuthrtyNm
+RgltryRptg
• Must be a valid country code according to ISO3166. Error code : XT73
++Authrty
+++AuthrtyCtry

STEP2 – M-PEDD
27th November 2009
+RgltryRptg
++RgltryDtls
+++Cd
DrctDbtTxInf 3!a18d O NA
+RgltryRptg
++RgltryDtls
+++Amt
+RgltryRptg
++RgltryDtls
+++Inf
DrctDbtTxInf See schema O NA • The related remittance information
+RltdRmtInf
• See XML Schema for exact description of fields available.
DrctDbtTxInf 140x O AT-22 Structured or Unstructured Remittance Information.
+RmtInf Only Structured or Unstructured can be used (Schema validation)
++Ustrd Structured remittance information
Maximum of 10 occurrences of this field. (schema validation).
Or First occurrence is Yellow and optional.
Subsequent occurrences are white and reserved for future use. Error code: XT13.
++Strd
Unstructured remittance information
First occurrence is Yellow and optional.
Format is 140x for entire data in each occurrence where the number of characters is
counted between the Strd tags (not inclusive). Error Code XT33.
DrctDbtTxInf See schema O NA
+RmtInf Referred Document Information
++Strd
+++ RfrdDocInf NOTE: STEP2 CS will not validate and/or reject this white field
DrctDbtTxInf See schema O NA Referred Document Date

+RmtInf
++Strd
+++ RfrdDocRltdDt

STEP2 – M-PEDD
27th November 2009
DrctDbtTxInf See schema O NA Referred Document Amount

+RmtInf
++Strd
+++RfrdDocAmt
DrctDbtTxInf See schema O NA Creditor Related Information
+RmtInf
++Strd
+++ CdtrRefInf
DrctDbtTxInf See schema O NA Invoicer
+RmtInf
++Strd
+++Invcr
DrctDbtTxInf See schema O NA Invoicee
+RmtInf
++Strd
+++Invcee
DrctDbtTxInf See schema O NA Referred Document Amount
+RmtInf
++Strd
+++AddtlRmtInf
Table 4-12 PACS.003 (Debit Collection) used in IDF and DNF – Individual Debit Instruction

STEP2 – M-PEDD
27th November 2009
C.2 STEP2 usage of PACS.006 (Payment Cancellation Request)

C.2.1 STEP2 usage of PACS.006 (Payment Cancellation Request) in IDF and DNF – Bulk Header
XML Element Format Status STEP2 Usage Rules
GrpHdr 35x M IDF:The DP’s bulk reference
DNF: STEP2’s bulk reference
GrpHdr ISODate M The date & time in which this bulk was created by the DP.
+CreDtTm &Time
GrpHdr 15n M The number of transactions included in this bulk.
+NbOfTxs • Must not be greater than the Maximum Number Of Transaction parameter: error code B02;
and
GrpHdr 18d M • Values are supported with up to 15 digits in the integer part and up to 2 fraction digits
+CtrlSum (schema validation)
• Must equal the sum of individual transactions inside the bulk: error code B07.
GrpHdr See Step2 M The Identifier of Group Cancellation.
+GrpCxl usage rule Must be set to false (Schema validation)
column
GrpHdr 4!a2!a2!c C The DP originating this bulk.
+InstgAgt • Must equal SndgInst element in IDF and must not contain a branch code: error code B10.
++FinInstnId
+++BIC Only used in IDF: error code B10
GrpHdr 4!a2!a2!c C The DP receiving the bulk.
+InstdAgt
Used only in DNF: error code B11
++FinInstnId
+++BIC
Table 4-13 STEP2 usage of PACS.006 (Payment Status) in IDF and DNF – Bulk Header
C.2.2 STEP2 usage of PACS.006 (Payment Cancellation Request) in IDF and DNF – Original Group Information

STEP2 – M-PEDD
27th November 2009

OrgnlGrpInf 35x M The MessageId of the original bulk.
+OrgnlMsgId In the case of DNF, the MessageID is the one generated by the CS for the Original DD bulk
in the original DNF.
OrgnlGrpInf 35x M The type of XML message bulk to be cancelled.
+OrgnlMsgNmId • Must always equal to pacs.003* (use of wildcard in validation): (schema validation)
Table 4-14 STEP2 usage of PACS.006 (Payment Cancellation Request) in IDF and DNF – Original Group Information
C.2.3 STEP2 usage of PACS.006 (Payment Cancellation Request) in IDF and DNF –Individual Debit Cancellation Instruction
Multiple occurrences of Individual Cancellation can be used.
Payment Cancellation Requests must be sent within the “Last Submission Date – Request for Cancellation” parameter.
Each message must match an existing Debit Request following the uniqueness and matching criteria provided.
XML Acronym Format Status Validation Rules

TxInf 35x M The Cancellation Id:
+CxlId • Uniqueness is checked under the rules for duplicate: error code AM05.
• This identification cannot include leading, trailing or internal spaces.
(schema validation)
TxInf 35x O The Original instruction Id if available.
+OrgnlInstrId
TxInf 35x M The Original End to End Id
+OrgnlEndToEndId
TxInf 35x M The Original Transaction Id.
+OrgnlTxId • Must be present in the CS Repository: error code XT74; and
• The status of the original transaction must not be “rejected by STEP2
CS”, “rejected by counterparty”, “settling”, “settled”, or “cancelled”: error
code XT75.

STEP2 – M-PEDD
27th November 2009

TxInf The original Interbank Settlement Amount.
+OrgnlIntrBkSttlmAmt 18d M
Attribute 3!a C • The Currency attribute must be “EUR”: (schema validation)and
• The number of digits following the decimal point in Interbank Settlement
Amount must not exceed the maximum number allowed for the EUR
currency: (schema validation)
Must be the same as the InterbankSettlementAmount for the original debit as

stored in the CS: error code XT77.
TxInf The DP responsible for this Request for Cancellation
+InstgAgt Used only in DNF: error code XT13
++FinInstnId 4!a2!a2!c C
+++BIC
TxInf 70x C The party originating the request for cancellation (customer).
+CxlRsnInf If the single transaction is cancelled, then this parent (CxlRsnInf) must be used:
++CxlOrgtr error code XT13
+++Nm
Cannot be used at the same time as Originator/BIC (see below) (schema
validation)
TxInf 4!a2!a2!c[3!c] C
+CxlRsnInf The party originating the request for cancellation (bank).
++CxlOrgtr If the single transaction is cancelled, then this parent (CxlRsnInf) must be used:
+++Id error code XT13
++++OrgId Cannot be used at the same time as Originator/Name (see above) (schema
+++++BIC validation)
TxInf 4!a C The Request for Cancellation Reason Code. (ISO20022 code)
+CxlRsnInf • Must be used with a valid code: (schema validation)
++CxlRsn
+++Cd Cannot be used at the same time as Prtry (see below) (schema validation)
TxInf 35x C The Request for Cancellation Reason Code. (STEP2 code)
+CxlRsnInf • Format validation, four alphanumerical characters as described in the
++CxlRsn transaction error code appendix, error code XT33.
+++Prtry
Cannot be used at the same time as Code (see above) (schema validation)

STEP2 – M-PEDD
27th November 2009

TxInf ISO DATE M • The original Interbank Settlement Date.
+OrgnlTxRef • Must be the same date as the date of the original transaction in the CS
++IntrBkSttlmDt repository. Error code : XT74
TxInf ISO DATE M
+OrgnlTxRef The original Requested Collection Date.
++ReqdColltnDt
TxInf 35x M The Creditor Scheme Identification
+OrgnlTxRef
++CdtrSchmeId
+++Id
++++PrvtId
+++++OthrId
++++++Id
TxInf 35x M The Creditor Scheme Identification type.
+OrgnlTxRef
++CdtrSchmeId
+++Id
++++PrvtId
+++++OthrId
++++++IdTp
TxInf 4!a M
+OrgnlTxRef The Service Level Code.
++PmtTpInf
+++SvcLvl • Must be “SEPA”: (schema validation)
++++Cd
TxInf 35x M
+OrgnlTxRef The indication of the scheme or service:
++PmtTpInf Values allowed are found in the Product Table, CORE or B2B, depending on the
+++LclInstrm relevant service: error code XT33
++++Cd
TxInf 4!a M
+OrgnlTxRef
The Sequence Type of the Direct Debit.
++PmtTpInf
+++SeqTp
TxInf 4!a O
+OrgnlTxRef
The category purpose.
++PmtTpInf
+++CtgyPurp
STEP2 – M-PEDD
27th November 2009

TxInf See Section M
The Mandate Related Information. All fields present in the original debit
+OrgnlTxRef C.1.2
message are supported.
++MndtRltdInf
TxInf 140x C Structured or Unstructured Remittance Information.
+OrgnlTxRef Only Structured or Unstructured can be used (Schema validation)
++RmtInf Structured remittance information
+++Ustrd Maximum of 10 occurrences of this field. (schema validation).
Or Subsequent occurrences are white and reserved for future use. Error code:
+++Strd XT13.

Subsequent occurrences are white and reserved for future use. Error code:
XT13.
TxInf 70x O
+OrgnlTxRef
The Ultimate Debtor Name.
++UltmtDbtr
+++Nm
TxInf 70x O Address line can have a maximum of two occurrences. (schema validation)
+OrgnlTxRef
++UltmtDbtr
+++PstlAdr
++++AdrLine
TxInf 2!a C Country of the Ultimate Debtor
+OrgnlTxRef
++UltmtDbtr
+++PstlAdr
++++Ctry
TxInf See Schemas C The identification of the Ultimate Debtor: Organisation Id.
+OrgnlTxRef Cannot be used at the same time as Id/PrvtId (below) (schema validation)
++UltmtDbtr All of the ISO options are available (see ISO document or schema).
+++Id
++++OrgId

STEP2 – M-PEDD
27th November 2009

TxInf See Schemas C The identification of the Ultimate Debtor: Private Id.
+OrgnlTxRef Cannot be used at the same time as Id/OrgId (above) (schema validation)
+++Id
++++PrvtId
TxInf 2!a O The Country of Residence of the Ultimate Debtor.
+OrgnlTxRef
++UltmtDbtr
+++CtryOfRes
TxInf M
+OrgnlTxRef 70x
The Debtor Name.
++Dbtr
+++Nm
TxInf 70x O
+OrgnlTxRef The Debtor Postal Address Lines.
++Dbtr
+++PstlAdr Up to two occurrences are supported.
++++AdrLine
TxInf 2!a O
+OrgnlTxRef
++Dbtr The Debtor Country.
+++PstlAdr
++++Ctry
TxInf See Schemas C The identification of the Debtor: Organisation Id
+OrgnlTxRef
++Dbtr
+++Id Cannot be used at the same time as Id/PrvtId (below) (schema validation)
++++OrgId All of the ISO options are available (see ISO document or XML Schemas)
TxInf See Schemas C The identification of the Debtor: Private Id
+OrgnlTxRef
++Dbtr
+++Id Cannot be used at the same time as Id/OrgId (above) (schema validation)
++++PrvtId All of the ISO options are available (see ISO document or XML Schemas)
TxInf 2!a O
+OrgnlTxRef
The Debtor Country of Residence
++Dbtr
+++CtryOfRes

STEP2 – M-PEDD
27th November 2009

TxInf 2!a2!n30x M
+OrgnlTxRef
++DbtrAcct The Debtor Account
+++Id
++++IBAN
TxInf 4!a2!a2!c[3!c] M
+OrgnlTxRef
++DbtrAgt The Debtor Agent
+++FinInstnId
++++BIC
TxInf 4!a2!a2!c[3!c] M
+OrgnlTxRef The Creditor Agent
++CdtrAgt
+++FinInstnId Must be present in the CS repository: Error Code XT74
++++BIC
TxInf 70x M
+OrgnlTxRef
The Creditor Name
++Cdtr
+++Nm
TxInf 70x O
+OrgnlTxRef The Creditor Postal Address Lines.
++Cdtr
++++AdrLine
TxInf 2!a O
+OrgnlTxRef
++Cdtr The Creditor Country.
+++PstlAdr
++++Ctry
TxInf 2!a O
+OrgnlTxRef
The Credtior Country of Residence
++Cdtr
+++CtryOfRes
TxInf 2!a2!n30x M
+OrgnlTxRef
++CdtrAcct The Creditor Account
+++Id
++++IBAN
STEP2 – M-PEDD
27th November 2009

TxInf 70x O
+OrgnlTxRef
The Ultimate Creditor Name.
++UltmtCdtr
+++Nm
TxInf 70x O
+OrgnlTxRef
++UltmtCdtr Address line can have a maximum of two occurrences. (schema validation)
+++PstlAdr
++++AdrLine
TxInf 2!a C
+OrgnlTxRef
++UltmtCdtr Country of the Ultimate Creditor
+++PstlAdr
++++Ctry
TxInf See Schemas C
+OrgnlTxRef The identification of the Ultimate Creditor: Organisation Id.
++UltmtCdtr Cannot be used at the same time as Id/PrvtId (below) (schema validation)
+++Id All of the ISO options are available (see ISO document or schema).
++++OrgId
TxInf See Schemas C
+OrgnlTxRef The identification of the Ultimate Creditor: Private Id.
++UltmtCdtr Cannot be used at the same time as Id/OrgId (above) (schema validation)
++++PrvtId
TxInf 2!a O
+OrgnlTxRef
The Country of Residence of the Ultimate Creditor.
++UltmtCdtr
+++CtryOfRes
Table 4-15 STEP2 usage of PACS.006 (Payment Cancellation Request) in IDF and DNF –Individual Debit Cancellation Instruction

STEP2 – M-PEDD
27th November 2009
C.3 STEP2 Usage of pacs.002S2 (Payment Status) in DVF/RSF/CDF
This is a Payment Status sent by STEP2 to inform a bank of rejected Direct Debits or R-messages (at validation or at settlement level).
C.3.1 STEP2 Usage of pacs.002S2 (Payment Status) in DVF/RSF/CDF – Bulk Header

GrpHdr 35x M The STEP2 CS bulk reference.
+MsgId
GrpHdr ISODate M The date & Time in which this bulk was created by the STEP2 CS.
+CreDtTm &Time
GrpHdr 4!a2!a2!c[ C The Instructing Agent BIC for this bulk
+InstgAgt 3!c] • Not used in DVF
++FinInstnId • Present in CDF
+++BIC • Present in RSF sent to original Instructing Agent for this bulk
GrpHdr 4!a2!a2!c[ C The Instructed Agent BIC for this bulk
+InstdAgt 3!c] • Not used in DVF
++FinInstnId • Not used in CDF
+++BIC • Present in RSF sent to original Instructed Agent for this bulk
Table 4-16 STEP2 Usage of pacs.002 (Payment Status) in DVF/RSF/CDF – Bulk Header

STEP2 – M-PEDD
27th November 2009
C.3.2 STEP2 Usage of pacs.002S2 (Payment Status) in DVF/RSF/CDF - Original Group Information And Status

OrgnlGrpInfAndSts 35x M The MessageId of the original bulk
+OrgnlMsgId
OrgnlGrpInfAndSts 35x M The type of XML message to be rejected.

+OrgnlMsgNmId DVF: pacs.002.001.02, pacs.003.001.01, pacs.004.001.01, pacs.006.001.01, pacs.007.001.01
RSF: pacs.003.001.01
CDF: pacs.004.001.01, pacs.007.001.01
1
OrgnlGrpInfAndSts 15n M DVF: The total number of transactions received within the original bulk
+OrgnlNbOfTxs RSF/CDF: The total number of transactions sent for settlement.
2
OrgnlGrpInfAndSts 18d M For DVF: The amount of the original bulk in euro
+OrgnlCtrlSum For RSF: The Amount of the valid transactions within the original bulk sent for settlement
For CDF: The Amount of the valid transactions within the original bulk sent and cancelled at
settlement
OrgnlGrpInfAndSts 4!a M The status of this bulk; values allowed are:
+GrpSts DVF: “ACCP”= accepted, “PART” = partially accepted or “RJCT” = rejected
RSF: “ACSC”= accepted (settlement confirmed), “PART” = partially settled or “RJCT” = rejected
CDF: “PART” = partially accepted or “RJCT” = rejected
OrgnlGrpInfAndSts 4!a2!a2!c M
+StsRsnInf The STEP2 CS BIC.
++StsOrgtr
+++Id
++++OrgId
+++++BIC
OrgnlGrpInfAndSts 4!a C The indication of the error code of the bulk. Code is defined as per ISO20022.
+StsRsnInf
++StsRsn Cannot be used with StsRsn Prtry (see below)
+++Cd If GroupStatus is Rejected: contains bulk rejection reason code ED05 for RSF only.
OrgnlGrpInfAndSts 35x C The indication of the error code of the bulk. Code is STEP2 Specific (proprietary)
+StsRsnInf Cannot be used with StsRsn Code (see above)
++StsRsn
+++Prtry • If GroupStatus is Accepted: B00
• If GroupStatus is Partially Accepted: B01
• If GroupStatus is Rejected: contains bulk rejection reason code.
1
In case of B23 is the number of the rejected transactions
2
In case of B23 is the amount of the rejected transactions
STEP2 – M-PEDD
27th November 2009

OrgnlGrpInfAndSts 15n C
The number of transactions per this status (Accepted) in the bulk.
+NbOfTxsPerSts
Present if Group Status is PART.
++DtldNbOfTxs
OrgnlGrpInfAndSts 4!a C
The status of the transactions (Accepted)
+NbOfTxsPerSts
++DtldSts
OrgnlGrpInfAndSts 18d C
The Value of the transactions per this status (Accepted) in the bulk.
+NbOfTxsPerSts
++DtldCtrlSum
OrgnlGrpInfAndSts 15n C
The number of transactions per this status (Rejected) in the bulk.
+NbOfTxsPerSts
++DtldNbOfTxs
OrgnlGrpInfAndSts 4!a C
The status of the transactions (Rejected)
+NbOfTxsPerSts
++ Present if Group Status is PART.
DtldSts
OrgnlGrpInfAndSts 18d C
The Value of the transactions per this status (Rejected) in the bulk.
+NbOfTxsPerSts
++DtldCtrlSum
Table 4-17 STEP2 Usage of pacs.002S2 (Payment Status) in DVF/RSF/CDF - Original Group Information And Status

STEP2 – M-PEDD
27th November 2009
C.3.3 STEP2 Usage of pacs.002S2 (Payment Status) in DVF/RSF/CDF - Individual Reject Instruction
This part of the message is only present if there are any transactions rejected inside the bulk as described below.
XML Acronym Format Status STEP2 Usage Rules

TxInfAndSts 35x M
The Status Report message Identification (generated by the Central System).
+StsId
TxInfAndSts 35x O The Instruction ID of the original DD; populated only if it was present in the
+OrgnlInstrId original DD.
Not used in CDF.
TxInfAndSts 35x M
The End to End Id of the original DD
+OrgnlEndToEndId
TxInfAndSts 35x M The Id of the original transaction (Id is specific to the original message type)
+OrgnlTxId Rule for CDF
• In case of a Return/Refund, the ReturnID is used
In case of a Reversal, the ReversalID is used.
TxInfAndSts 4!a M
The status of this transaction; only value allowed is: “RJCT”= rejected
+TxSts
TxInfAndSts 4!a2!a2!c[3!c] M The STEP2 CS system BIC.
+StsRsnInf
++StsOrgtr
+++Id
++++OrgId
+++++BIC
TxInfAndSts 4!a C The indication of the error code for the transaction (ISO20022 codes)
+StsRsnInf
++StsRsn RSF/CDF: ED05 for cancellation in TARGET2
+++Cd
Cannot be used at the same time as Proprietary (see below).

STEP2 – M-PEDD
27th November 2009

TxInfAndSts 35x C The indication of the error code for the transaction (STEP2 specific)
+StsRsnInf
++StsRsn If the error code is XT13 or XT33, this Prtry will be formatted as such:
+++Prtry
[CODE][1 blank character][Offending XML tag]
Where:
CODE: XT13 or XT33

Offending XML tag: The first leaf + 1 blank character + the last leaf of the
offending tag
Cannot be used at the same time as Code (see above).
TxInfAndSts 4!a2!a2!c[3!c] C The Instructing Agent BIC for this message.
+InstgAgt • Not used in DVF or CDF
++FinInstnId • Present in RSF sent to Original Instructed Agent
+++BIC
TxInfAndSts 4!a2!a2!c[3!c] C The Instructed Agent BIC for this message.
+InstdAgt • Not used in DVF
++FinInstnId • Present in CDF
+++BIC • Present in RSF sent to Original Instructing Agent
TxInfAndSts 18d The Amount of the original transaction.
+OrgnlTxRef 3!a M
++IntrBkSttlmAmt Depending on the type of the original message, this can either be referred to
Attribute C as:
Direct Debit : InterbankSettlementAmount

Request for Cancellation : the Interbank Settlement Amount of the original DD
Reject : the Interbank Settlement Amount of the original DD
Reversal : ReversedInterbankSettlementAmount
Return/Refund : ReturnedInterbankSettlementAmount
TxInfAndSts ISODate M The Original Interbank Settlement Date
+OrgnlTxRef For transactions without an Interbank Settlement Date (ie. Pre-settlement R-
++IntrBkSttlmDt message), this field is populated with the business date on which the original
transaction was processed.

STEP2 – M-PEDD
27th November 2009

TxInfAndSts 4!a2!a2!c[3!c] M The Original Creditor Agent
+OrgnlTxRef
++CdtrAgt
+++FinInstnId
++++BIC
Table 4-18 STEP2 Usage of pacs.002S2 (Payment Status) in DVF/RSF/CDF - Individual Reject Instruction

STEP2 – M-PEDD
27th November 2009
C.4 STEP2 Usage of pacs.002 (Payment Status) in IDF AND DNF

This is a Payment Status sent by a bank to reject a Direct Debit (IDF) and then forwarded by STEP2 to the counterparty (DNF).
This 002 message reflects a Reject (by a bank) and a Refusal (by customer)
The combination of the Message Name (002.001.02) and the StatusOriginator: Name shows that the message is a Refusal.
The combination of the Message Name (002.001.02) and the StatusOriginator: ID: BIC shows that the message is a Reject.
C.4.1 STEP2 Usage of pacs.002.001.02 (Payment Status) in IDF AND DNF – Bulk Header
XML Element Format Status Validation Rules

GrpHdr 35x M IDF:The DP’s bulk reference
DNF: STEP2’s bulk reference
GrpHdr ISODate M The date & time in which this bulk was created by the DP.
+CreDtTm &Time
GrpHdr The DP originating this bulk.
+InstgAgt
• Must equal SndgInst element in IDF and must not contain a branch code: error code B10.
+++BIC Only used in an IDF: error code B10
GrpHdr The DP receiving this bulk.
+InstdAgt
Only used in a DNF: error code B11
+++BIC
Table 4-19 STEP2 Usage of pacs.002.001.02 (Payment Status) in IDF AND DNF – Bulk Header

STEP2 – M-PEDD
27th November 2009
C.4.2 STEP2 Usage of pacs.002.001.02 (Payment Status) in IDF AND DNF - Original Group Information And Status Header
XML Element Format Status Rule Book Validation Rules

Ref
OrgnlGrpInfAndSts 35x M The MessageId of the original bulk
+OrgnlMsgId NA In the case of DNF, the MessageID is the one generated by the Bank for the Original DD bulk in the original
IDF.
OrgnlGrpInfAndSts 35x M NA The type of XML message bulk to be rejected.
+OrgnlMsgNmId
• Must always equal to pacs.003* (use of wildcard in validation): (schema validation).
OrgnlGrpInfAndSts See M R1 The status of the original bulk.
+GrpSts Validation Values can be:
rules • Must be PART: Partially Accepted (schema validation)
Table 4-20 STEP2 Usage of pacs.002.001.02 (Payment Status) in IDF AND DNF - Original Group Information and Status Header

STEP2 – M-PEDD
27th November 2009
C.4.3 STEP2 Usage of pacs.002.001.02 (Payment Status) in IDF AND DNF - Individual Reject Instruction
This part of the message is only present if there are any transactions rejected inside the bulk as described below.
Each message must match an existing Debit Request following the uniqueness and matching criteria provided.
Each message must be sent within the configured time period for type of message.

Validation Rules
Ref
TxInfAndSts 35x M R5 The Payment Status Id:
+StsId • Uniqueness is checked: error code AM05.
• This identification cannot include leading, trailing or internal spaces.
(schema validation).
TxInfAndSts 35x O NA
The original Instruction Id.
+OrgnlInstrId
TxInfAndSts 35x M NA
The original End to End Id.
+OrgnlEndToEndId
TxInfAndSts 35x M NA The original transaction Id.
+OrgnlTxId
• Must be present in the CS Repository: error code XT74; and
• The status of the original transaction must not be “rejected by
STEP2 CS”, “rejected by counterparty”, “settling, “settled” or
“cancelled”: error code XT75.
TxInfAndSts See validation M R1 The status of this transaction.
+TxSts rules • The only value allowed is: “RJCT” = rejected: (schema validation).
TxInfAndSts 70x C R2 The customer originating this transaction.
+StsRsnInf • Can be used only in presence of TxInfAndSts +StsRsnInf ++StsRsn
++StsOrgtr +++Cd equal to MS02. Error code XT13 if this is not met.
+++Nm • Indicates a customer Refusal.
Cannot be used at the same time as BIC (see below) (schema validation).
TxInfAndSts 4!a2!c2!a[3!c] C R2
+StsRsnInf The party originating this transaction.
++StsOrgtr • Indicates a Bank Reject.
+++Id Cannot be used at the same time as Name (see above) (schema
++++OrgId validation).
+++++BIC

STEP2 – M-PEDD
27th November 2009

Validation Rules
Ref
TxInfAndSts 4!a C NA The Reject/Refusal Reason Code (ISO20022)
+StsRsnInf • Used only if a single transaction is rejected: error code XT33;
++StsRsn Must be used with a valid code: (schema validation).
+++Cd Cannot be used at the same time as Proprietary (below) (schema
validation).
TxInfAndSts 35x C NA The Reject/Refusal Reason Code (STEP2)
+StsRsnInf • Used only if a single transaction is rejected: error code XT33;
++StsRsn • Format validation, four alphanumerical characters as described in
+++Prtry the transaction error code appendix, error code XT33
Cannot be used at the same time as Code (above) (schema validation).

TxInfAndSts 4!a2!a2!c C NA The original DP sending this transaction to the CS.
+InstgAgt
++FinInstnId
Only used in DNF: error code XT13
+++BIC
TxInfAndSts 18d M NA The original Interbank Settlement Amount.
+OrgnlTxRef 3!a C
++IntrBkSttlmAmt • The Currency attribute must be “EUR”: (schema validation).and
• The number of digits following the decimal point in Interbank
Settlement Amount must not exceed the maximum number allowed
for the EUR currency: (schema validation).
Must be the same as the InterbankSettlementAmount for the original

debit as stored in the CS : error code XT77.
TxInfAndSts ISO DATE M NA The original Interbank Settlement Date.
+OrgnlTxRef • Must be the same date as the date of the original transaction in the
++IntrBkSttlmDt CS repository. Error code : XT74
TxInfAndSts ISO DATE M NA The original Requested Collection Date.
+OrgnlTxRef
++ReqdColltnDt

STEP2 – M-PEDD
27th November 2009

Validation Rules
Ref
TxInfAndSts NA The Creditor Scheme Identification.
+OrgnlTxRef 35x M
++CdtrSchmeId
+++Id
++++PrvtId
+++++OthrId
++++++Id
TxInfAndSts 35x M NA The Creditor Scheme Identification type.
+OrgnlTxRef
++CdtrSchmeId
+++Id
++++PrvtId
+++++OthrId
++++++IdTp
TxInfAndSts 4!a M NA The Service Level Code.
+OrgnlTxRef Must be “SEPA”: (schema validation)
++PmtTpInf
+++SvcLvl
++++Cd
TxInfAndSts 35x M NA
++PmtTpInf Values allowed are found in the Product Table, CORE or B2B, depending
+++LclInstrm on the relevant service: error code XT33
++++Cd
TxInfAndSts 4!a M NA The Sequence Type of the Direct Debit.
+OrgnlTxRef
++PmtTpInf
+++SeqTp
TxInfAndSts 4!a O NA
+OrgnlTxRef
++PmtTpInf
+++CtgyPurp
TxInfAndSts See Section C.1.2 M NA The Mandate Related Information. All fields present in the original debit
+OrgnlTxRef message are supported.
++MndtRltdInf

STEP2 – M-PEDD
27th November 2009

Validation Rules
Ref
TxInfAndSts 140x C NA Structured or Unstructured Remittance Information.
Or Subsequent occurrences are white and reserved for future use. Error code:
+++Strd XT13.

Subsequent occurrences are white and reserved for future use. Error code:
XT13.
TxInfAndSts 70x O NA The Ultimate Debtor Name.
+OrgnlTxRef
++UltmtDbtr
+++Nm
TxInfAndSts 70x O NA Address line can have a maximum of two occurrences. (schema validation)
+OrgnlTxRef
++UltmtDbtr
+++PstlAdr
++++AdrLine
TxInfAndSts 2!a C NA Country of the Ultimate Debtor
+OrgnlTxRef
++UltmtDbtr
+++PstlAdr
++++Ctry
TxInfAndSts See Schemas C NA The identification of the Ultimate Debtor: Organisation Id.
+++Id
++++OrgId

STEP2 – M-PEDD
27th November 2009

Validation Rules
Ref
TxInfAndSts See Schemas C NA The identification of the Ultimate Debtor: Private Id.
+++Id
++++PrvtId
TxInfAndSts 2!a O NA The Country of Residence of the Ultimate Debtor.
+OrgnlTxRef
++UltmtDbtr
+++CtryOfRes
TxInfAndSts M NA The Debtor Name.
+OrgnlTxRef 70x
++Dbtr
+++Nm
TxInfAndSts 70x O NA The Debtor Postal Address Lines.
+OrgnlTxRef Up to two occurrences are supported.
++Dbtr
+++PstlAdr
++++AdrLine
TxInfAndSts 2!a O NA The Debtor Country.
+OrgnlTxRef
++Dbtr
+++PstlAdr
++++Ctry
TxInfAndSts See Schemas O The identification of the Debtor: Organisation Id
+OrgnlTxRef
++Dbtr NA
Cannot be used at the same time as Id/PrvtId (below) (schema validation)
+++Id
TxInfAndSts See Schemas O The identification of the Debtor: Private Id
+OrgnlTxRef
++Dbtr NA
Cannot be used at the same time as Id/OrgId (above) (schema validation)
+++Id
TxInfAndSts 2!a O NA The Debtor Country of Residence
+OrgnlTxRef
++Dbtr
+++CtryOfRes
STEP2 – M-PEDD
27th November 2009

Validation Rules
Ref
TxInfAndSts 2!a2!n30x M NA The Debtor Account
+OrgnlTxRef
++DbtrAcct
+++Id
++++IBAN
TxInfAndSts 4!a2!a2!c[3!c] M NA The Debtor Agent
+OrgnlTxRef
++DbtrAgt
+++FinInstnId
++++BIC
TxInfAndSts 4!a2!a2!c[3!c] M NA The Creditor Agent
+OrgnlTxRef Must be present in the CS repository: Error Code XT74
++CdtrAgt
+++FinInstnId
++++BIC
TxInfAndSts 70x M NA The Creditor Name
+OrgnlTxRef
++Cdtr
+++Nm
TxInfAndSts 70x O NA The Creditor Postal Address Lines.
+OrgnlTxRef Up to two occurrences are supported.
++Cdtr
+++PstlAdr
+++AdrLine
TxInfAndSts 2!a O NA The Creditor Country.
+OrgnlTxRef
++Cdtr
+++PstlAdr
+++Ctry
TxInfAndSts 2!a O NA The Credtior Country of Residence
+OrgnlTxRef
++Cdtr
+++CtryOfRes

STEP2 – M-PEDD
27th November 2009

Validation Rules
Ref
TxInfAndSts 2!a2!n30x M NA The Creditor Account
+OrgnlTxRef
++CdtrAcct
+++Id
++++IBAN
TxInfAndSts 70x O NA The Ultimate Creditor Name.
+OrgnlTxRef
++UltmtCdtr
+++Nm
TxInfAndSts 70x O NA Address line can have a maximum of two occurrences. (schema validation)
+OrgnlTxRef
++UltmtCdtr
+++PstlAdr
++++AdrLine
TxInfAndSts 2!a C NA Country of the Ultimate Creditor
+OrgnlTxRef
++UltmtCdtr
+++PstlAdr
++++Ctry
TxInfAndSts See Schemas C NA The identification of the Ultimate Creditor: Organisation Id.
++UltmtCdtr
All of the ISO options are available (see ISO document or schema).
+++Id
++++OrgId
TxInfAndSts See Schemas C NA The identification of the Ultimate Creditor: private Id.
++UltmtCdtr
All of the ISO options are available (see ISO document or schema).
+++Id
++++PrvtId
TxInfAndSts 2!a O NA The Country of Residence of the Ultimate Creditor.
+OrgnlTxRef
++UltmtCdtr
+++CtryOfRes
Table 4-21 STEP2 Usage of pacs.002.001.02 (Payment Status) in IDF and DNF - Individual Reject Instruction

STEP2 – M-PEDD
27th November 2009
C.5 STEP2 Usage of pacs.004 (Return)
This 004 message reflects a Return (by a bank) and a Request for Refund (by customer)
The combination of the Message Name (004.001.01) and the StatusOriginator: Name shows that the message is a Refund.
The combination of the Message Name (004.001.01) and the StatusOriginator: ID: BIC shows that the message is a Return.
C.5.1 STEP2 Usage of pacs.004 (Return) in IDF and SDF– Bulk Header
GrpHdr 35x M The bulk reference of the generating party.
+MsgId • Uniqueness is checked: error code B14.
• For SDF, MsgId is generated by STEP2.
GrpHdr ISO Date M The date & time in which this bulk was created by the DP.
+CreDtTm & Time
+NbOfTxs • Must not be greater than the Maximum Number Of Transaction parameter: error code B02; and
GrpHdr 18d M The Value of the transactions included in this bulk.
+TtlRtrdIntrBkSttlm 3!a M
Amt
• Values are supported with up to 15 digits in the integer part and up to 2 fraction digits: (schema validation).
Attribute • Currency attribute must be always “EUR” (schema validation).
• Must equal the sum of individual transactions RtrdIntrBkSttlmAmt fields inside the bulk: error code B05.
• Maximum value is 999 999 999 999 999.99 euros (schema validation).
GrpHdr ISODate M The business date in which the transactions inside this bulk must be settled in the relevant settlement mechanism.
+IntrBkSttlmDt • Must be a Target Date : Error code B15
• Cannot be present at transaction level as per ISO usage rule.
• Date must be valid according to message type (Refund/Return) business rule (see Business Function
Description document). Error Code B15.
GrpHdr 4!a M Information on settlement method.
+SttlmInf
++SttlmMtd
Only the value “CLRG” is supported: Schema validation

STEP2 – M-PEDD
27th November 2009

GrpHdr 3!a M The Identifier of the the Clearing System.
+SttlmInf
GrpHdr 4!a2!a2!c The DP originating this bulk.
+InstgAgt • Must equal SndgInst element in IDF and must not contain a branch code: error code B10.
++FinInstnId C
+++BIC Used only in IDF. error code B10
GrpHdr 4!a2!a2!c C The DP receiving this bulk.
+InstdAgt Used only in SDF. error code B11
++FinInstnId
+++BIC
Table 4-22 STEP2 Usage of pacs.004 (Return) in IDF and SDF– Bulk Header
C.5.2 STEP2 Usage of pacs.004 (Return) in IDF and SDF - Transaction Information
Each IDF message must be sent within the configured time period for type of message.
XML Element Format Status Rule STEP2 Usage Rules and Validation
Book Ref
TxInf 35x M R5 The Return Id:
+RtrId • Uniqueness is checked: error code AM05.
• This identification cannot include leading, trailing or internal spaces. (schema validation).
TxInf 35x M NA The MessageID of the bulk containing the original DD.
+OrgnlGrpInf In the case of IDF where (the pacs.004) is sent by the bank to STEP2, the MessageId is normally the
++OrgnlMsgId one generated by STEP2 for the Original DD bulk (pacs.003) in the original DNF.(not validated)
In case of the SDF(pacs.004 sent to bank)

If the Return or refund was matched to the original debit the MessageId is the Original Message ID
received from the bank.
If the Return or refund was not matched to the original debit the MessageId is set to the value
“UNMATCHED”.
TxInf 35x M NA The type of XML message bulk to be returned/refunded.
+OrgnlGrpInf
++OrgnlMsgNmId
Must always equal to pacs.003* (use of wildcard in validation)(schema validation)
STEP2 – M-PEDD
27th November 2009
Book Ref
TxInf 35x O NA
The original InstructionId
+OrgnlInstrId
TxInf 35x M NA
+OrgnlEndToEndId
The original End to End Id
TxInf 35x M NA The original Transaction Id.
+OrgnlTxId
• If the original Direct Debit is found in the CS repository, then the status of the original transaction
must be “settled”: error code XT75.
(see also Business Function Document for details on Unauthorised Transactions)
TxInf 18d M AT-06 The original Interbank Settlement Amount.
+OrgnlIntrBkSttlmA M
mt
Attribute
3!a • The Currency attribute must be “EUR”: (schema validation).
• The number of digits following the decimal point in Interbank Settlement Amount must not
exceed the maximum number allowed for the EUR currency: (schema validation).
TxInf 18d M NA The amount of this transaction (return).
+RtrdIntrBkSttlmA 3!a M
mt
Attribute • The Currency attribute must be “EUR”: (schema validation).
• Amount must be 0.01 or more and 999 999 999 999 999.99 or less: error code AM02
• The returned Interbank Settlement Amt must be equal to the original Interbank Settlement Amount +
Compensation amount (error code XT78)
TxInf R6 The Returned/Refunded Compensation amount of the refunded transaction;
+CompstnAmt 18d O
3!a C • The Currency attribute must be “EUR”: (schema validation).
• Only applies to refunds indicated by presence of Name in Return originator:
• Present only if Returned Interbank Settlement Amount is different than the Original Settlement
Amount.

STEP2 – M-PEDD
27th November 2009
Book Ref
TxInf 4!a O NA
The Charge Bearer Information. If used, Value must be SLEV. (schema validation)
+ChrgBr
TxInf 18d O NA
+ChrgsInf 3!a C
• Only one occurrence is allowed: error code (schema validation)
++ChrgsAmt
Attribute
TxInf O NA • Only one occurrence is allowed: error code (schema validation)
+ChrgsInf 4!a2!a2!c[
++ChrgsPty 3!c]
+++FinInstnId
++++BIC
TxInf 4!a2!a2!c C NA The DP originating this Return.
+InstgAgt
++FinInstnId
Used only in SDF. error code XT13
+++BIC
TxInf 70x C R2 The customer originating this transaction.
+RtrRsnInf Cannot be used at the same time as Originator BIC (below) (schema validation).
++RtrnOrgtr Cannot be used for the B2B service; error code XT13
+++Nm
TxInf C R2 The party originating this transaction.
+RtrRsnInf
++RtrOrgtr Cannot be used at the same time as Originator Name (above) (schema validation).
+++Id 4!a2!a2!c[
++++OrgId 3!c]
+++++BIC
TxInf 4!a C NA The Return/Refund Reason Code (ISO20022)
+RtrRsnInf Must be used with a valid code: (schema validation).
++RtrRsn
+++Cd Cannot be used at the same time as Proprietary (below) (schema validation).
TxInf 35x C NA The Return/Refund Reason Code (STEP2)
+RtrRsnInf Format validation, four alphanumerical characters as described in the transaction error code appendix,,
++RtrRsn error code XT33.
+++Prtry
Cannot be used at the same time as Code (above) (schema validation).
TxInf ISO M NA The Original Interbank Settlement Date.
+OrgnlTxRef DATE
++IntrBkSttlmDt
STEP2 – M-PEDD
27th November 2009
Book Ref
TxInf ISO M NA The Original Requested Collection date.
+OrgnlTxRef DATE
++ReqdColltnDt
TxInf NA The Creditor Scheme Identification.
+OrgnlTxRef 35x M
++CdtrSchmeId
+++Id
++++PrvtId
+++++OthrId
++++++Id
TxInf 35x M NA The Creditor Scheme Identification type.
+OrgnlTxRef
++CdtrSchmeId
+++Id
++++PrvtId
+++++OthrId
++++++IdTp
TxInf 4!a M NA
+OrgnlTxRef
++PmtTpInf The Service Level Code.
+++SvcLvl
++++Cd
TxInf 35x M NA
++PmtTpInf Values allowed are found in the Product Table, CORE or B2B, depending on the relevant service: error
+++LclInstrm code XT33
++++Cd
TxInf 4!a M NA
+OrgnlTxRef
++PmtTpInf
+++SeqTp
TxInf 4!a O NA
+OrgnlTxRef
++PmtTpInf
+++CtgyPurp

STEP2 – M-PEDD
27th November 2009
Book Ref
TxInf See M NA
+OrgnlTxRef Section The Mandate Related Information. All fields present in the original debit message are supported.
++MndtRltdInf C.1.2
TxInf 140x C NA Structured or Unstructured Remittance Information.
++Ustrd Maximum of 10 occurrences of this field. (schema validation).
Or Subsequent occurrences are white and reserved for future use. Error code: XT13.
+++ Strd
Format is 140x for entire data in each occurrence where the number of characters is counted between the Strd tags
(not inclusive). Error Code XT33.
TxInf 70x O NA The Ultimate Debtor Name.
+OrgnlTxRef
++UltmtDbtr
+++Nm
TxInf 70x O NA • Address line can have a maximum of two occurrences. (schema validation)
+OrgnlTxRef
++UltmtDbtr
+++PstlAdr
++++AdrLine
TxInf 2!a C NA • Country of the Ultimate Debtor
+OrgnlTxRef
++UltmtDbtr
+++PstlAdr
++++Ctry
TxInf See C NA The identification of the Ultimate Debtor: Organisation Id.
+OrgnlTxRef Schemas Cannot be used at the same time as Id/PrvtId (below) (schema validation)
+++Id
++++OrgId

STEP2 – M-PEDD
27th November 2009
Book Ref
TxInf See C NA The identification of the Ultimate Debtor: Private Id.
+OrgnlTxRef Schemas Cannot be used at the same time as Id/OrgId (above) (schema validation)
+++Id
++++PrvtId
TxInf 2!a O NA The Country of Residence of the Ultimate Debtor.
+OrgnlTxRef
++UltmtDbtr
+++CtryOfRes
TxInf M NA
+OrgnlTxRef 70x
The Debtor Name.
++Dbtr
+++Nm
TxInf 70x O NA
++Dbtr
++++AdrLine
TxInf 2!a O NA
+OrgnlTxRef
+++PstlAdr
++++Ctry
TxInf See O The identification of the Debtor: Organisation Id
+OrgnlTxRef Schemas
++Dbtr NA
+++Id
TxInf See O The identification of the Debtor: Private Id
+OrgnlTxRef Schemas
++Dbtr NA
+++Id
TxInf 2!a O NA
+OrgnlTxRef
++Dbtr
+++CtryOfRes
STEP2 – M-PEDD
27th November 2009
Book Ref
TxInf 2!a2!n30x M NA
+OrgnlTxRef
+++Id
++++IBAN
TxInf 4!a2!a2!c[ M NA
+OrgnlTxRef 3!c]
+++FinInstnId
++++BIC
TxInf 4!a2!a2!c[ M NA
+OrgnlTxRef 3!c] The Creditor Agent
++CdtrAgt
+++FinInstnId Must be present in the CS repository: Error code PY01
++++BIC
TxInf 70x M NA
+OrgnlTxRef
The Creditor Name
++Cdtr
+++Nm
TxInf 70x O NA
++Cdtr
++++AdrLine
TxInf 2!a O NA
+OrgnlTxRef
+++PstlAdr
++++Ctry
TxInf 2!a O NA
+OrgnlTxRef
The Credtior Country of Residence
++Cdtr
+++CtryOfRes

STEP2 – M-PEDD
27th November 2009
Book Ref
+OrgnlTxRef
+++Id
++++IBAN
TxInf 70x O NA
+OrgnlTxRef
++UltmtCdtr
+++Nm
TxInf 70x O NA
+OrgnlTxRef
+++PstlAdr
++++AdrLine
TxInf 2!a C NA
+OrgnlTxRef
+++PstlAdr
++++Ctry
TxInf See C NA
+OrgnlTxRef Schemas The identification of the Ultimate Creditor: Organisation Id.
++++OrgId
TxInf See C NA
+OrgnlTxRef Schemas The identification of the Ultimate Creditor: Private Id.
++UltmtCdtr Cannot be used at the same time as Id/OrgId (above) (schema validation)
++++PrvtId
TxInf 2!a O NA
+OrgnlTxRef
++UltmtCdtr
+++CtryOfRes
Table 4-23 STEP2 Usage of pacs.004 (Return) in IDF and SDF/CDF - Transaction Information IDF

STEP2 – M-PEDD
27th November 2009
C.6 STEP2 Usage of XML pacs.007 (Payment Reversal)
C.6.1 STEP2 Usage of pacs.007 (Reversal) in IDF and SDF – Bulk Header
GrpHdr 35x M The bulk reference. of the generating party.
+MsgId • Uniqueness is checked: error code B14.
• For SDF, MsgId is generated by STEP2.
GrpHdr ISODate& M The date & time in which this bulk was created by the DP
+CreDtTm Time
+NbOfTxs • Must not be greater than the Maximum Number Of Transaction parameter: error code B02; and
GrpHdr See M The status of this bulk.
+GrpRvsl validation Only FALSE is allowed (Schema Validation)
rules
GrpHdr 18d M The Value of the transactions included in this bulk.
+TtlRvsdIntrBkSttlm M • Values are supported with up to 15 digits in the integer part and up to 2 fraction digits: (schema validation)
Amt 3!a • Currency attribute must be always “EUR”: (schema validation); and
Attribute • Must equal the sum of individual transactions RvsdIntrBkSttlmAmt fields inside the bulk: error code B05.
• Amount must be 0.01 or more (error code B13) and 999 999 999 999 999.99 or less (schema validation).
GrpHdr ISODate M The business date in which the transactions inside this bulk must be settled in the relevant settlement mechanism.
+IntrBkSttlmDt • Must be a Target Date and in the allowed range: Error code B15
• Cannot be present at transaction level as per ISO usage rule.
GrpHdr 4!a M Information on settlement method.
+SttlmInf
++SttlmMtd Only the value “CLRG” is supported: (schema validation)
GrpHdr 3!a M The Identifier of the the Clearing System.
+SttlmInf

STEP2 – M-PEDD
27th November 2009

GrpHdr 4!a2!a2!c C The DP originating this bulk.
+InstgAgt • Format Validation; and
++FinInstnId • Must equal SndgInst element in IDF and must not contain a branch code: error code B10.
+++BIC Used only in IDF. error code B10
GrpHdr 4!a2!a2!c C The DP receiving this bulk.
+InstdAgt Used only in SDF. error code B11
++FinInstnId
+++BIC
Table 4-24 STEP2 Usage of pacs.007 (Reversal) in IDF and SDF– Bulk Header
C.6.2 STEP2 Usage of pacs.007 (Reversal) in IDF and SDF– Original Group Information Header
XML Element Format Status Rule Book Ref STEP2 Usage Rules
OrgnlGrpInf 35x M NA The MessageID of the bulk containing the original DD.
+OrgnlMsgId In the case of IDF where (the pacs.007) is sent by the bank to STEP2, the MessageId is
normally the one generated by Bank for the Original DD bulk (pacs.003) in the original
IDF.(not validated)
In case of the SDF(pacs.007 sent to bank)

If the Reversal was matched to the original debit the MessageId is the Original Message ID
generated by CS in the DNF file for the original pacs.003.
If the Reversal was not matched to the original debit the MessageId is set to the value “UNMATCHED”.
OrgnlGrpInf 35x M NA The type of XML message bulk to be rejected.
+OrgnlMsgNmId • Must always equal to pacs.003* (use of wildcard in validation): (schema validation)
Table 4-25 STEP2 Usage of pacs.007 (Reversal) in IDF and SDF– Original Group Information Header

STEP2 – M-PEDD
27th November 2009
C.6.3 STEP2 Usage of pacs.007 (Reversal) in IDF and SDF– Transaction Information
Each message must be sent within the configured time period for type of message.
XML Element Format Status Rule Validation Rules

Book Ref
TxInf 35x M NA The Reversal Id:
+RvslId • Uniqueness is checked: error code AM05.
• This identification cannot include leading, trailing or internal spaces. (schema validation)
TxInf 35x O NA
The original Instruction Id.
+OrgnlInstrId
TxInf 35x M NA The original End To End Id.
+OrgnlEndToEndI
d
TxInf 35x M NA The original transaction Id.
+OrgnlTxId • If the original Direct Debit is found in the CS repository, then the status of the original
transaction must be “settled”: error code XT75.
TxInf NA The original Interbank Settlement Amount.
+OrgnlIntrBkSttlm 18d M
Amt 3!a C • The Currency attribute must be “EUR”: (schema validation)
Attribute • The number of digits following the decimal point in Interbank Settlement Amount must
not exceed the maximum number allowed for the EUR currency: (schema validation)
TxInf 18d M NA The amount of this transaction.
+RvsdIntrBkSttlm 3!a M • The Currency attribute must be “EUR”: (schema validation)
Amt
Attribute • The number of digits following the decimal point in Interbank Settlement Amount must
TxInf 18d O NA The Reversed Instructed Amount.
+RvsdInstdAmt • The Currency attribute must be “EUR”: (schema validation)
Attribute 3!a
• The number of digits following the decimal point in Interbank Settlement Amount must
TxInf 11d O NA The Exchange Rate of the Reversal
+XchgRate
TxInf 4!a O NA • The Charge Bearer Information,
+ChrgBr • If used, Value must be SLEV. (schema validation)

STEP2 – M-PEDD
27th November 2009

Book Ref
TxInf 18d O
+ChrgsInf 3!a C NA
• Only one occurrence is allowed: (schema validation)
++ChrgsAmt
Attribute
TxInf 4!a2!a2!c[3!c] O NA • Only one occurrence is allowed: (schema validation)
+ChrgsInf
++ChrgsPty
+++FinInstnId
++++BIC
TxInf 4!a2!a2!c C NA The DP originating this Reversal
+InstgAgt Used only in SDF. error code XT13
++FinInstnId
+++BIC
TxInf 70x C R2 The customer originating this Reversal.
+RvslRsnInf
++RvslOrgtr Cannot be used at the same time as BIC (see below) (schema validation)
+++Nm
TxInf 4!a2!a2!c[3!c] C R2 The Bank originating this Reversal.
+RvslRsnInf
++RvslOrgtr Cannot be used at the same time as Name (see above) (schema validation)
+++Id
++++OrgId
+++++BIC
TxInf 4!a C NA The Reason Code of the Reversal (ISO20022)
+RvslRsnInf • Must be used a valid code (schema validation)
++RvslRsn
+++Cd Cannot be used at the same time as Proprietary (see below) (schema validation)
TxInf 35x C NA The Reason Code of the Reversal (STEP2):
+RvslRsnInf
++RvslRsn • Format validation, four alphanumerical characters as described in the transaction error
+++Prtry code appendix, error code XT33.
Cannot be used at the same time as Code (see above) (schema validation)
TxInf ISO DATE M NA The Original Interbank Settlement Date.
+OrgnlTxRef
++IntrBkSttlmDt

STEP2 – M-PEDD
27th November 2009

Book Ref
TxInf ISO DATE M NA The Original Requested Collection date.
+OrgnlTxRef
++ReqdColltnDt
TxInf 35x M NA The Creditor Scheme Identification.
+OrgnlTxRef
++CdtrSchmeId
+++Id
++++PrvtId
+++++OthrId
++++++Id
TxInf 35x M NA The Creditor Scheme Identification type.
+OrgnlTxRef
++CdtrSchmeId
+++Id
++++PrvtId
+++++OthrId
++++++IdTp
TxInf 4!a M NA
+OrgnlTxRef
++PmtTpInf The Service Level Code. Must = “SEPA”
+++SvcLvl
++++Cd
TxInf 35x M NA
++PmtTpInf Values allowed are found in the Product Table, CORE or B2B, depending on the relevant
+++LclInstrm service: error code XT33
++++Cd
TxInf 4!a M NA
+OrgnlTxRef
++PmtTpInf
+++SeqTp
TxInf 4!a O NA
+OrgnlTxRef
++PmtTpInf
+++CtgyPurp

STEP2 – M-PEDD
27th November 2009

Book Ref
TxInf See Section M NA
+OrgnlTxRef C.1.2 The Mandate Related Information. All fields present in the original debit message are supported.
++MndtRltdInf
TxInf 140x C NA Structured or Unstructured Remittance Information.
Or Subsequent occurrences are white and reserved for future use. Error code: XT13.
+++Strd Unstructured remittance information

Format is 140x for entire data in each occurrence where the number of characters is counted between the
Strd tags (not inclusive). Error Code XT33.
TxInf 70x O NA The Ultimate Debtor Name.
+OrgnlTxRef
++UltmtDbtr
+++Nm
TxInf 70x O NA • Address line can have a maximum of two occurrences. (schema validation)
+OrgnlTxRef
++UltmtDbtr
+++PstlAdr
++++AdrLine
TxInf 2!a C NA • Country of the Ultimate Debtor
+OrgnlTxRef
++UltmtDbtr
+++PstlAdr
++++Ctry
TxInf See Schemas C NA The identification of the Ultimate Debtor: Organisation Id.
+++Id
++++OrgId

STEP2 – M-PEDD
27th November 2009

Book Ref
TxInf See Schemas C NA The identification of the Ultimate Debtor: Organisation Id.
+++Id
++++PrvtId
TxInf 2!a O NA The Country of Residence of the Ultimate Debtor.
+OrgnlTxRef
++UltmtDbtr
+++CtryOfRes
TxInf M NA
+OrgnlTxRef 70x
The Debtor Name.
++Dbtr
+++Nm
TxInf 70x O NA
++Dbtr
++++AdrLine
TxInf 2!a O NA
+OrgnlTxRef
+++PstlAdr
++++Ctry
TxInf See Schemas O The identification of the Debtor: Organisation Id
+OrgnlTxRef
++Dbtr NA
+++Id
TxInf See Schemas O The identification of the Debtor: Private Id
+OrgnlTxRef
++Dbtr NA
+++Id
TxInf 2!a O NA
+OrgnlTxRef
++Dbtr
+++CtryOfRes
STEP2 – M-PEDD
27th November 2009

Book Ref
TxInf M NA
+OrgnlTxRef
+++Id
++++IBAN 2!a2!n30x
TxInf M NA
+OrgnlTxRef
+++FinInstnId
++++BIC 4!a2!a2!c[3!c]
TxInf M NA
+OrgnlTxRef The Creditor Agent
++CdtrAgt
+++FinInstnId Must be present in the CS repository: Error Code PY01
++++BIC 4!a2!a2!c[3!c]
TxInf 70x M NA
+OrgnlTxRef
The Creditor Name
++Cdtr
+++Nm
TxInf 70x O NA
++Cdtr
++++AdrLine
TxInf 2!a O NA
+OrgnlTxRef
+++PstlAdr
++++Ctry
TxInf 2!a O NA
+OrgnlTxRef
The Creditor Country of Residence
++Cdtr
+++CtryOfRes

STEP2 – M-PEDD
27th November 2009

Book Ref
+OrgnlTxRef
+++Id
++++IBAN
TxInf 70x O NA
+OrgnlTxRef
++UltmtCdtr
+++Nm
TxInf 70x O NA
+OrgnlTxRef
+++PstlAdr
++++AdrLine
TxInf 2!a C NA
+OrgnlTxRef
+++PstlAdr
++++Ctry
TxInf See Schemas C NA
++++OrgId
TxInf See Schemas C NA
++++PrvtId
TxInf 2!a O NA
+OrgnlTxRef
++UltmtCdtr
+++CtryOfRes
Table 4-26 STEP2 Usage of pacs.007 (Reversal) in IDF and SDF– Transaction Information

STEP2 – M-PEDD
27th November 2009
APPENDIX D ADDITIONAL IDF FILE VALIDATION

D.1 IDF Naming & Structure Validation Process
Processing Error report

The STEP2 service identifier (“COR” for The CS cannot generate a DVF because:
Core or “B2B” for B2B) associated with the • It is not possible to associate a destination network address to which to send the file.
network address (from the Request Type
Resolution must involve a phone call to Customer Support and manual management.
network parameter) must be one of the
configured services.
The sending address must be present in the
STEP2 Central System addressing table for
the specified STEP2 service identifier.
If the number of rejected transactions is The CS generates a DVF as follows:
equal to 0, then the file is completely • The IDF is totally accepted;
accepted.
The reported IdfErrCd at the level of IDF is:
• A00: the IDF is totally accepted.
If the number of rejected transactions is The CS generates a DVF as follows:

different from 0, and there are some • The IDF is partially accepted ;
transaction accepted then the file is partially The IdfErrCd equals:
accepted.
• A01: the file is partially accepted.
The file has been sent during non-Target The CS generates a DVF as follows:
days. • The IDF is totally rejected;
• In a DVF OrigFRef and OrigDtTm will not be present (for DVF matching, only the Original File
Name field is meaningful); and
• The transactions contained in the IDF have not been validated, and therefore:
• The DVF will not contain any rejected transaction, and
• In a DVF OrgnlGrpInfAndSts will not be present.
The IdfErrCd equals:
• R01: the IDF has been received during non-Target days.

STEP2 – M-PEDD
27th November 2009

The network file name is compared against The CS generates a DVF as follows:
the valid naming convention being accepted. • The IDF is totally rejected;
This check is divided into several checks: • The following DVF fields are filled using the information derived from the network header:
• The network file name must begin with • SrvcId,
the fixed value according to the naming
• RcvgInst (the DP), and
convention;
• OrigFName.
• The Service Identifier contained in the
network file name must be equal to the • In a DVF, OrigFRef and OrigDtTm will not be present (for DVF matching, only the Original File
one associated with the network Name field is meaningful); and
address; • The transactions contained in the IDF have not been validated, and therefore:
• The DP BIC contained in the network file The DVF will not contain any rejected transaction, andIn a DVF, GrpHdr, OrgnlGrpInfAndSts and
name must be equal to the one TxInf will not be present
associated with the network address (as
derived from the STEP2 Central System IdfErrCd equals:
addressing table);
• R02: the beginning of the network file name is not compliant,
• The format version contained in the
network file name is checked against the • R03: the service identifier is not compliant,
legal values; and • R04: the DP BIC is not compliant,
• The file type contained in the network file • R06: the format version is not compliant, or
name must be "I” • R07: the file type is not compliant.
The parser will validate the received file The CS generates a DVF as follows:
against the IDF XML schema. • The IDF is totally rejected;
If the file does not comply with the schema • OrigFRef and OrigDtTm will not be present (for DVF matching, only the Original File Name field is
then it is rejected as garbage. meaningful); and
• The DVF will not contain any rejected transaction, andIn a DVF, GrpHdr OrgnlGrpInfAndSts
and TxInf will not be present
The IdfErrCd equals:
• R10: IDF does not comply with schema; the file is garbage.

STEP2 – M-PEDD
27th November 2009

The following fields are compared against The CS generates a DVF as follows:
the record of accepted files held online: • The IDF is totally rejected;
• ServiceId; • The payment instructions contained in the IDF have not been validated, and therefore:
• SngInst; • The DVF will not contain any rejected transactionIn a DVF, GrpHdr OrgnlGrpInfAndSts and
• FileReference. TxInf will not be present
If a match is found for these fields between The IdfErrCd equals:
the file being validated and a file held online • R13: the IDF is a duplicate.
then the file is rejected as a duplicate.
The contents of the IDF header fields are The CS generates a DVF as follows:
checked against the configured set of legal • The IDF is totally rejected;
values.
• SndgInst must equal the BIC associated
• The DVF will not contain any rejected transactions,
with the network address;
• In a DVF, GrpHdr OrgnlGrpInfAndSts and TxInf will not be present
• RcvgInst must equal the configured
STEP2 central system BIC; and The possible IdfErrCd are:
• TstCode must equal the configured • R11: incorrect SndgInst.
system value. • R12: incorrect RcvgInst.
If any check fails then the file is rejected. • R14: incorrect TstCode.

STEP2 – M-PEDD
27th November 2009

The format (syntax and character set) and The CS generates a DVF as follows:
presence of those file- and header-level • The IDF is totally rejected;
elements not verified by schema validation is
• OrigFRef and OrigDtTm will not be present (for DVF matching, only the OrigFName field is
checked.
meaningful); and
Specifically, it is verified that:
• The format of SndgInst must be
4!a2!a2!c (e.g. must not contain a branch
code); • In a DVF, GrpHdr OrgnlGrpInfAndSts and TxInf will not be present
• The format of RcvgInst must be The possible IdfErrCd are:
4!a2!a2!c (e.g. must not contain a branch • R15: incorrect SndgInst format;
code); • R16: incorrect RcvgInst format.
If any of these tests fail then the file is
rejected as garbage.
The Service Identifier present in the Network The CS generates a DVF as follows:
File Name is compared to the Service • The IDF is totally rejected;
Identifier inside the IDF File Header.
The possible IdfErrCd are:
• R17: incorrect Service Identifier
The Direct Debit bulks within the file are The CS generates a DVF as follows:
counted and the total is compared against • The IDF is totally rejected;
NumDDBlk.
• The DVF will not contain any rejected payment instructions; and
If the numbers are different then the file is
rejected.
R18: the number of DD bulks within the IDF does not match the value declared at the IDF level.
The Request for Cancellation bulks within The CS generates a DVF as follows:
the file are counted and the total is • The IDF is totally rejected;
compared against NumRFCBlk.
rejected.

STEP2 – M-PEDD
27th November 2009

R19: the number of RFC bulks within the IDF does not match the value declared at the IDF level.
The Refund/Return bulks within the file are The CS generates a DVF as follows:
NumRFRBlk.
rejected.
R20: the number of REF/RET bulks within the IDF does not match the value declared at the IDF level.
The Reject bulks within the file are counted The CS generates a DVF as follows:
and the total is compared against • The IDF is totally rejected;
NumREJBlk.
rejected.
R21: the number of REJ bulks within the IDF does not match the value declared at the IDF level.
The Reversal bulks within the file are The CS generates a DVF as follows:
NUMRVSBlk.
rejected.
R22: the number of REV bulks within the IDF does not match the value declared at the IDF level.
After the completion of IDF content The CS generates a DVF as follows:
validation, the number of processed bulk is
compared with the number of rejected bulks. • The IDF is totally rejected;
If they are equal, the IDF is totally rejected. • In a DVF, OrigFRef and OrigDtTm will be present (for DVF matching, only the Original File
Name field is meaningful); and
• The bulks contained in the IDF have been validated, and therefore:
The DVF will contain the rejected bulks, and

STEP2 – M-PEDD
27th November 2009

The StsRsnInf Prtry field will contain the error code.
R23: The IDF has been rejected because each bulk inside was rejected by the STEP2 CS
The number of files already accepted The CS generates a DVF as follows:
for this settlement cycle from this Direct
Participant is compared against the • The IDF is totally rejected;
maximum number of files accepted per • In a DVF, OrigFRef and OrigDtTm will be present (for DVF matching, only the Original File
settlement cycle. If the maximum has Name field is meaningful); and
already been accepted then this file is • The bulks contained in the IDF have not been validated
rejected.
R24: The IDF has been rejected because the maximum number of valid IDF for that date has been
reached
Table 4-27 IDF Naming & Structure Validation

STEP2 – M-PEDD
27th November 2009
APPENDIX E ADDITIONAL IDF BULK VALIDATION

E.1 Bulks Naming & Structure Validation Process
Error /Reason Code Processing Error report
B00: the bulk is totally accepted. IDF: The CS generates a DVF as follows:
After the bulk content validation • The bulk is totally accepted;
completion, the number of rejected • All the transactions have been validated; and
transactions is checked.
• All the transactions have succeeded the validation of the Interbank Settled Amount, and
If the number of rejected transaction is therefore:
equal to 0 and the number of accepted
In the DVF OrgnlGrpInfAndSts will all be present and contain meaningful values.
transaction is greater than 0, then the bulk
is totally accepted.
RSF: Reason code field is used in bulk header.
This code is used to inform the receiver of
the settlement status of the original bulk.
B01: the bulk is partially accepted. After the bulk content validation The CS generates a DVF as follows:
completion, the number of rejected • The bulk is partially accepted;
transactions is checked.
• The DVF contains all the rejected transactions;
If the number of rejected transaction is
• All the transactions have been validated (but not accepted); and
greater than 0 and the number of
accepted transaction is greater than 0, • All the transactions have succeeded the validation of the Interbank Settled Amount, and
then the bulk is partially accepted. therefore:
In a DVF OrgnlGrpInfAndSts will all be present and contain meaningful values.
RSF: Reason code field is used in bulk header.
This code is used to inform the receiver of
the settlement status of the original bulk.

STEP2 – M-PEDD
27th November 2009

B02: the maximum number of NbOfTxs/NbOfTxsPerSts is compared The CS generates a DVF as follows:
transactions within one bulk is against the maximum number of • The bulk is totally rejected;
exceeded. transactions supported in one bulk.
• The transactions contained in the bulk have not been validated, and therefore:
If there is a greater number of transactions
• The DVF will not contain any rejected transactions,
in the bulk than what is allowed for the
service, the bulk is rejected. The StsRsnInf Prtry field will contain the error code.
B03: the number of transactions The transactions within the bulk are The CS generates a DVF as follows:
within the bulk does not match the counted and the total is compared against • The bulk is totally rejected;
value declared in the GrpHdr/ NbOfTxs/NbOfTxsPerSts.
• The DVF will not contain any rejected transactions; and
OrgnlGrpInfAndSts. If the numbers are different then the bulk
• The transactions contained in the bulk have not been validated, but:
is rejected.
B04: Not used NA NA

STEP2 – M-PEDD
27th November 2009

B05: TtlIntrBkSttlmAmt, After the completion of pacs.003, The CS generates an bulk as follows:
TtlRvsdIntrBkSttlmAmt or pacs.004 or pacs.007 Bulk content • The bulk is totally rejected;
TtlRtrdIntrBkSttlmAmt is incorrect. validation, the number of processed
• The DVF will not contain any rejected transaction
transactions and the number of
transactions with a valid "Interbank Settled The StsRsnInf Prtry field will contain the error code.
Amount",”Returned Settlement amount”
or “Reversed Settlement Amount” are
checked.
If these numbers are equal, then the sum

of the “Interbank Settled Amount”
",”Returned Settlement amount” or
“Reversed Settlement Amount” from every
transaction is verified against
TtlIntrBkSttlmAmt, TtlRvsdIntrBkSttlmAmt
or TtlRtrdIntrBkSttlmAmt. If the calculated
sum is different from that indicated in the
bulk this is rejected.
In the case of a Bulk Reversal, the

TtlRvsdIntrBkSttlmAmt is NOT checked as
there will be no individual Reversal
message in the bulk.
In the case of Direct Debits used for DMF,

a zero amount is possible.
B06: Not used NA NA

STEP2 – M-PEDD
27th November 2009

B07: DtldCtrlSum/CtrlSum is After the completion of pacs.006 Bulk The CS generates an bulk as follows:
incorrect. content validation, the number of • The bulk is totally rejected;
processed transactions and the number of
• The DVF will not contain any rejected transaction
transactions with a valid
"TransactionReference/Interbank The StsRsnInf Prtry field will contain the error code.
Settlement Amount" are checked.
If these numbers are equal, then the sum
of the “TransactionRefence/Interbank
Settled Amount” from every transaction is
verified against ControlSum. If the
calculated sum is different from that
indicated in the bulk this is rejected.
In the case of a Bulk Cancellation, the
Control Sum is NOT checked as there will
be no individual Request for Cancellation
in the bulk.
B08: the maximum number of valid The number of bulks already accepted for The CS generates a DVF as follows:
bulks has already been received in this settlement cycle from this Direct • The bulk is totally rejected;
this settlement cycle. Participant is compared against the
maximum number of bulks accepted per
settlement cycle. If the maximum have • The DVF will not contain any rejected transactions
already been accepted then this bulk is The StsRsnInf Prtry field will contain the error code.
rejected.
B09: the bulk is totally rejected After the completion of bulk content The CS generates a DVF as follows:
because all transactions within it validation, the number of processed • The bulk is totally rejected;
have been rejected. transactions is compared with the number
• The DVF contains all rejected transactions;
of rejected transactions. If they are equal,
the bulk is totally rejected. • All the transactions have been validated;
• All the transactions have succeeded the validation of the Interbank Settled Amount,

B10: the bulk is totally rejected Instructing Agent must be present at the The CS generates a DVF as follows:
because InstructingAgent must be group header level in an IDF and have the • The bulk is totally rejected;
present at the group header level in format 4!a2!a2!c (e.g. must not contain a
an IDF. branch code).
• The DVF will not contain any rejected transactions

STEP2 – M-PEDD
27th November 2009
B11: the bulk is totally rejected Instructed Agent must not be present at The CS generates a DVF as follows:
because InstructedAgent must not be the group header level in a IDF. • The bulk is totally rejected;
present at group header level in an
IDF.
• The StsRsnInf Prtry field will contain the error code.
B12: Not used NA NA
B13: the bulk is totally rejected The Total amount must be equal or The CS generates a DVF as follows:
because amount is zero greater than 0.01. • The bulk is totally rejected;
• In a DVF, OrigFRef and OrigDtTm will not be present (for DVF matching, only the Original
File Name field is meaningful); and
B14: the bulk is totally rejected The Message Id must be unique The CS generates a DVF as follows:
because MsgId is duplicated. • The bulk is totally rejected;
B15: the bulk is totally rejected IntrBkSttlmDt must be present at the The CS generates a DVF as follows:
because IntrBkSttlmDt is not present group level (applicable only to pacs.003, • The bulk is totally rejected;
or is not in the allowed range. pacs.004 and pacs.007) and must be
within the allowed range .
B16: the bulk is totally rejected ClrSys should equal to "ST2" The CS generates a DVF as follows:
because of incorrect usage of ClrSys • The bulk is totally rejected;
B19: Not used NA NA
B20: Not used NA NA

STEP2 – M-PEDD
27th November 2009

B23: the bulk is totally rejected The number of consecutive rejected The CS generates a DVF as follows:
because too many consecutive transactions found at the beginning of
rejected transactions the bulk must not exceed the CS • The bulk is totally rejected;
parameter "maximum number of • The transactions contained in the bulk have not been validated, and therefore:
errors in the bulk" • The DVF will not contain any rejected transactions

B24: Not used

STEP2 – M-PEDD
27th November 2009

STEP2 – M-PEDD
27th November 2009
APPENDIX F REPORTS
F.1 PSR Pre Settlement Report
The PSR file is generated and sent to the Direct Participant if and only if the participant has sent
or received at least one transaction (DD or R-Msg) for the relevant settlement date and cycle. In
the case no transaction was exchanged for the settlement date and cycle being processed, the
PSR file is not generated for the Direct Participant.
In the case that the sum of figures for a specific settlement date and cycle will result in a zero
value, the PSR file is generated with the relevant records with the values set to zero. This
situation could occur when DD are cancelled / rejected with pre-settlement R-Messages.
F.1.1 PSR Record Table Index
TAG Multiplicity Definition Trailer

Record
HPSR 1-1 PSR Header
PDBH 1-1 PSR Debit Settlement Transaction Header
PDBB 0-n PSR Debit Party
1-1 PDBT
PCRH 1 -1 PSR Credit Settlement Transaction Header
PCRB 0-n PSR Credit Party
1-1 PCRT
PLPH 0 -1 PSR Liquidity Position Header
PLPB 0-n PSR Liquidity Position Body
0 -1 PSR Liquidity Position Trailer PLPT
TPSR

STEP2 – M-PEDD
27th November 2009
F.1.2 PSR Header

Status Field Name Format Value Position
M Record Type 4x “HPSR” 0
“COR” for Core or
M Service Identifier 3x 4
“B2B” for B2B
M File Type 3x "PSR" 7
EBA STEP2 CS
M Sending Institution 4!a2!a2!c 10
BIC
M Sender’s File Reference 16!c 18
*
M Date And Time 6!n6!n 34
M Test Code 1x "P" / "T" 46
M Receiving Institution 4!a2!a2!c 47
M Settlement Cycle 2n 55
M Interbank Settlement Date 6n 57
M Total Number Records 6n 63
Table 4-28 PSR Header
*CET (CEST in the summer).
F.1.3 PSR Debit Settlement Transaction Header

M Record Type 4x “PDBH” 0
M Total Number of DDs received 15n 4
M Total Value of DDs received 18d 19
M Total Number of Reversals sent 15n 37
M Total Value of Reversals sent 18d 52
M Total Number of Refunds/Returns received 15n 70
M Total Value of Refunds/Returns received 18d 85
M Field reserved for future use 15n 103
M Field reserved for future use 18d 118
M Total settlement amount debited 18d 136
Table 4-29 PSR Debit Settlement Transaction Header
Each PSR File contains one and only one Debit Settlement Transaction Header. The PSR is
generated and sent only if the DP has sent or received at least one transaction.. The Direct
Participant receiving this PSR is the debit party. The contents of the fields in each such record
are as follows:

STEP2 – M-PEDD
27th November 2009
Field Name Contents

The number of DDs received from the DP for the processing of this interbank
Total Number of DDs received settlement date during the specific settlement cycle
The value of DDs received from the DP for the processing of this interbank
Total Value of DDs received settlement date during the specific settlement cycle
The number of Reversals sent by the DP for the processing of this interbank
Total Number of Reversals sent settlement date during the specific settlement cycle
The value of Reversals sent by the DP for the processing of this interbank
Total Value of Reversals sent settlement date during the specific settlement cycle
Total Number of Refunds/Returns The number of Returns/Refunds received by the DP for the processing of this
received interbank settlement date during the specific settlement cycle
Total Value of Refunds/Returns The value of Returns/Refunds received by the DP for the processing of this
Field reserved for future use Field reserved for future use
The value of the total amount debited to the DP for the processing of this
Total settlement amount debited interbank settlement date during the specific settlement cycle
Table 4-30 PSR Debit Settlement Transaction Header – field contents
F.1.4 PSR Debit Party

M Record Type 4x "PDBB" 0
M Interbank Settlement Date 6!n 4
M Credit Party DP BIC 4!a2!a2!c 10
M Credit Party Settlement BIC 4!a2!a2!c3!c 18
M Value of DDs received 18d 29
M Value of Reversals sent 18d 47
Value of Refunds/Returns
M 18d 65
received
Total Settlement Amount
M 18d 101
Debited
Table 4-31 PSR Debit Party
The PSR Debit Party contains one record for each settlement instruction generated by the STEP2
central system during the processing of the value date to which this PSR relates (if no settlement
instructions were sent then no records will be present or coud have the figures set to zero) where
the Direct Participant receiving this PSR is the debit party. The contents of the fields in each such
record are as follows:

STEP2 – M-PEDD
27th November 2009
Field Name Contents

The STEP2 settlement cycle during which this settlement instruction was
Settlement Cycle
generated.
The Interbank Settlement Date during which this settlement instruction was
Interbank Settlement Date
generated.
The BIC of the Direct Participant who was the credit party of these
Credit Party DP BIC
transactions.
The BIC used by the Direct Participant identified in Credit Party Settlement
Credit Party Settlement BIC
BIC, above, for settlement in TARGET2.
Value of DDs received The value of the above Number DDs received.
Value of Reversals sent The value of the above Number Reversals sent.
Value of Refunds/Returns The value of the above Number Refunds/Returns received.
received
Settlement Amount The amount of transactions included in this body.

Table 4-32 PSR Debit Party – field contents

M Record Type 4x "PDBT” 0
Table 4-33 PSR Debit Party trailer
F.1.5 PSR Credit Settlement Transaction Header

M Record Type 4x “PCRH” 0
M Total Number of DDs sent 15n 4
M Total Value of DDs sent 18d 19
M Total Number of Reversals received 15n 37
M Total Value of Reversals received 18d 52
M Total Number of Refunds/Returns sent 15n 70
M Total Value of Refunds/Returns sent 18d 85
M Total settlement amount credited 18d 136
Table 4-34 PSR Credit Settlement Transaction Header
The PSR Credit Settlement Transaction Header contains one single record for each PSR file
generated by the STEP2 central system during the processing of the value date to which this
PSR relates. The PSR is generated and sent only if the DP has sent or received at least one
transaction. The Direct Participant receiving this PSR is the credit party. The contents of the fields
in each such record are as follows:

STEP2 – M-PEDD
27th November 2009
Field Name Contents

The number of DDs sent from the DP for the processing of this interbank
Total Number of DDs sent settlement date during the specific settlement cycle
The value of DDs sent from the DP for the processing of this interbank
Total Value of DDs sent settlement date during the specific settlement cycle
Total Number of Reversals The number of Reversals received by the DP for the processing of this
The value of Reversals received by the DP for the processing of this interbank
Total Value of Reversals received settlement date during the specific settlement cycle
Total Number of Refunds/Returns The number of Returns/Refunds sent by the DP for the processing of this
sent interbank settlement date during the specific settlement cycle
Total Value of Refunds/Returns The value of Returns/Refunds sent by the DP for the processing of this
sent interbank settlement date during the specific settlement cycle
The value of the total amount credited to the DP for the processing of this
Total settlement amount credited interbank settlement date during the specific settlement cycle
Table 4-35 PSR Credit Settlement Transaction Header – field contents
F.1.6 PSR Credit Party

M Record Type 4x "PCRB" 0
M Debit Party DP BIC 4!a2!a2!c 10
M Debit Party Settlement BIC 4!a2!a2!c3!c 18
M Value of DDs sent 18d 29
M Value of Reversals received 18d 47
M 18d 65
sent
M Settlement Amount 18d 101
Table 4-36 PSR Credit Party
The PSR Credit Party contains one record for each settlement instruction generated by the
STEP2 central system during the processing of the value date to which this PSR relates (if no
settlement instructions were sent then no records will be present or coud have the figures set to
zero) where the Direct Participant receiving this PSR was the credit party. The contents of the
fields in each such record are as follows:

STEP2 – M-PEDD
27th November 2009
Field Name Contents

generated
The BIC of the Direct Participant who was the debit party of this settlement
Debit Party DP BIC
instruction.
The BIC used by the Direct Participant identified in Debit Party Settlement
Debit Party Settlement BIC
BIC, above, for settlement in TARGET2.
Value of DDs sent The value of the above Number DDs sent.
Value of Reversals received The value of the above Number Reversals received.
Value of Refunds/Returns The value of the above Number Refunds/Returns sent.
sent
Settlement Amount The amount of the transactions included in this body

Table 4-37 PSR Credit Party – field contents

M Record Type 4x "PCRT” 0
Table 4-38 PSR Credit Party trailer
4.1.1 PSR Liquidity Position Header

M Record Type 4x "PLPH" 0
M Total value of DDs sent 18d 4
M Total value of Return sent 18d 22
M Total value of Reversal received 18d 40
M DP owes IP 18d 58
M Total value of DD Received 18d 76
M Total value of Return received 18d 94
M Total value of Reversal sent 18d 112
M IP owes DP 18d 130
M Net Position of DP vs. all IP 18d 148
Each PSR File contains one and only one Liquidity Position Header. The PSR is generated and
sent only if the DP has sent or received at least one transaction. The contents of the fields in
each such record are as follows:

STEP2 – M-PEDD
27th November 2009
Field Name Contents

The value of DDs sent by the DP for the processing of this interbank
The value of Returns sent by the DP for the processing of this interbank
Total Value of Returns sent settlement date during the specific settlement cycle
The value of Reversal received from the DP for the processing of this
Total Value of Reversal received interbank settlement date during the specific settlement cycle
DP Owes IP The amount that the DP owes to the IPs
Total value of DD Received
settlement date during the specific settlement cycle
The value of Returns received from the DP for the processing of this interbank
Total value of Return received settlement date during the specific settlement cycle
The value of Reversal sent by the DP for the processing of this interbank
Total value of Reversal sent
IP owes DP The amount that the IP owes to the DP
Net Position of DP vs. all IP The net position of the Direct Participant vs. all Indirect Participants
Table 4-39 PSR Liquidity Position Header – field contents
4.1.2 PSR Liquidity Position Body

M Record Type 4x “PLPB” 0
M Indirect Participant BIC 4!a2!a2!c3!c 4
M Total value of DDs sent 18d 15
M Total value of Return sent 18d 33
M Total value of Reversal received 18d 51
M DP owes IP 18d 69
M Total value of DDs received 18d 87
M Total value of Return received 18d 105
M Total value of Reversal sent 18d 123
M IP owes DP 18d 141
M Net Position of DP vs. IP 18d 159
Each PSR File contains one Liquidity Position Body for each Indirect Participant that had sent or
received transactions. The contents of the fields in each such record are as follows:

STEP2 – M-PEDD
27th November 2009
Field Name Contents

Indirect Participant The Indirect Participant BIC to which the data is related
The value of DDs sent by the DP for the processing of this interbank
The value of Returns sent by the DP for the processing of this interbank
Total Value of Returns sent settlement date during the specific settlement cycle
The value of Reversal received from the DP for the processing of this
Total Value of Reversal received interbank settlement date during the specific settlement cycle
DP Owes IP The amount that the DP owes to the IPs
Total value of DD Received
The value of Returns received from the DP for the processing of this interbank
Total value of Return received settlement date during the specific settlement cycle
The value of Reversal sent by the DP for the processing of this interbank
Total value of Reversal sent
IP owes DP The amount that the IP owes to the DP
Net Position of DP vs. all IP The net position of the Direct Participant vs. all Indirect Participants
Table 4-40 PSR Liquidity Position Body – field contents
4.1.3 PSR Liquidity Position Trailer

M Record Type 4x "PLPT” 0
4.1.4 PSR FileTrailer

M Record Type 4x "TPSR” 0
Table 4-41 PSR trailer

STEP2 – M-PEDD
27th November 2009
F.2 DRR File Report

F.2.1 DRR Record Table Index
TAG Multiplicity Definition Trailer Record
HDRR 1-1 DRR Header
DFTH 1-1 DRR File/Bulk/Transaction sent header
DDSB 0-n DRR Direct Debit bulks sent
DCSB 0-n DRR Req for Canc bulks sent
DJSB 0-n DRR Rejects bulks sent
DVSB 0-n DRR Reversals bulks sent
DFSB 0-n DRR Refunds/Returns bulks sent
DTSB 0-n DRR Return of reversal bulks sent
1-1 DFTT
DNRH 1-1 DRR DNFs received header
DDRB 0-1 DRR DDs received body
DCRB 0-1 DRR Req for Canc received body
DJRB 0-1 DRR Rejects received body
1-1 DDRT
DRRH 1-1 DRR RSFs received header
DRRB 0-1 RSFs Debit Direct debit
DRSB 0-1 RSFs Credit Direct debit
1-1 DRRT
DSRH 1-1 DRR SDFs received header
DSRB 0-1 SDFs Return/Reversal received
1-1 DSRT
DSSH 1-1 DRR CDFs received header
DSSB 0-1 CDFs Return/Reversal received
1-1 DSST
DPTH 1-1 Debit party settlement Transactions header
DPTB 0-n Debit party settlement Direct debit body
1-1 DPTT
Credit Party settlement transactions
DCTH 1-1 received
DRR Credit Party settlement Transactions
DCTB 0-n body
1-1 DCTT
1-1 TDRR
Table 4-42 DRR Record Table Index

STEP2 – M-PEDD
27th November 2009
F.2.2 DRR header

M Record Type 4x “HDRR” 0
“COR” for Core
M Service Identifier 3x or “B2B” for 4
B2B
M File Type 3x "DRR" 7
EBA STEP2 CS
M Sending Institution 4!a2!a2!c 10
BIC
*
Table 4-43 DRR header
*CET (CEST in the summer).
The DRR includes data related to:
• Files/bulks/transactions exchanged in that specific business date, independtly from their

Interbank settlement date; and
• Transactions settled in that specific business date, independtly from their exchange date.

STEP2 – M-PEDD
27th November 2009
F.2.3 DRR files/bulks/messages sent

M Record Type 4x "DFTH" 0
M Number IDF Sent 4n 4
M Number IDF Rejected 4n 8
M Number Bulks Sent 4n 12
M Number Bulks Rejected 4n 16
M Number DD Bulks Sent 4n 20
M Number DD Bulks Rejected 4n 24
M Number Req for Canc Bulks Sent 4n 28
Number Req for Canc Bulks
M 4n 32
Rejected
M Number Rejects Bulks Sent 4n 36
M Number Rejects Bulks Rejected 4n 40
Number Refunds/Returns Bulks
M 4n 44
Sent
Number Refunds/Returns Bulks
M 4n 48
Rejected
M Number Reversal Bulks Sent 4n 52
M Number Reversal Bulks Rejected 4n 56
M Number Direct Debit Sent 15n 68
M Number Direct Debit Rejected 15n 83
M Number Req for Canc Sent 15n 98
M Number Req for Canc Rejected 15n 113
M Number Rejects Sent 15n 128
M Number Rejects Rejected 15n 143
M Number Refunds/Returns Sent 15n 158
Number Refunds/Returns
M 15n 173
Rejected
M Number Reversals Sent 15n 188
M Number Reversals Rejected 15n 203
M Value Direct Debit Sent 18d 248
M Value Direct Debit Rejected 18d 266
M Value Req for Canc Sent 18d 284
M Value Req for Canc Rejected 18d 302
M Value Rejects Sent 18d 320
M Value Rejects Rejected 18d 338
M Value Refunds/Returns Sent 18d 356
M Value Refunds/Returns Rejected 18d 374
M Value Reversals Sent 18d 392
M Value Reversals Rejected 18d 410
Table 4-44 DRR files/bulk/messages sent header

STEP2 – M-PEDD
27th November 2009
Each DRR contains one and only one DRR files sent header record. The contents of the fields in
this record are as follows:
Field Name Contents

The number of times an IDF was received by the STEP2 central system from
this Direct Participant.
Number IDF Sent
Rejected files that are re-sent (with the same or a different SFR) are counted
once for each time they are received by the STEP2 central system.
The number of DVFs indicating complete rejection of a file that were
transmitted by the STEP2 central system to this Direct Participant.
Number IDF Rejected
IDFs for which the STEP2 central system transmits a DVF with the following
codes in the File Reject Reason of the DVF header are included in this field:
The total number of bulks received by the STEP2 central system from this
Direct Participant.
Number Bulks Sent
Rejected bulks that are re-sent (with the same or a different reference) are
counted once for each time they are received by the STEP2 central system.
The number of the bulks completely rejected by the STEP2 central system to
Number Bulks Rejected
The total number of DDs bulks received by the STEP2 central system from
Number DDs Bulks Sent
The number of DDs bulks completely rejected by the STEP2 central system to
Number DDs Bulks Rejected
Number Req for Canc Bulks The total number of Request for Cancellation Bulks received by the STEP2
Sent central system from this Direct Participant
Number Req for Canc Bulks The number of the Requests for Cancellation bulks completely rejected by the
Rejected STEP2 central system to this Direct Participant.
The total number of Rejects bulks received by the STEP2 central system from
Number Rejects Bulks Sent
Number Rejects Bulks The number of the Rejects bulks completely rejected by the STEP2 central
Rejected system to this Direct Participant.
Number Refunds/Returns The total number of Refunds/Returns bulks received by the STEP2 central
Bulks Sent system from this Direct Participant.
Number Refunds/Returns The number of the Refunds/Returns bulks completely rejected by the STEP2
Bulks Rejected central system to this Direct Participant.
The total number of Reversals bulks received by the STEP2 central system
Number Reversals Bulks Sent
from this Direct Participant.
Number Reversals Bulks The number of the Reversals bulks completely rejected by the STEP2 central
Rejected system to this Direct Participant.
The number of Debit Requests received in IDFs from this Direct Participant by
Number Direct Debit Sent the STEP2 central system where the IDF was completely or partially
accepted.
The number of Debit Requests that were rejected from partially accepted IDFs
Number Direct Debit Rejected
received from this Direct Participant.
The number of Req for Canc received in IDFs from this Direct Participant by
Number Req for Canc Sent the STEP2 central system where the IDF was completely or partially
accepted.

STEP2 – M-PEDD
27th November 2009
Field Name Contents

Number Req for Canc The number of Req for Canc that were rejected from partially accepted IDFs
Rejected received from this Direct Participant.
The number of Rejects received in IDFs from this Direct Participant by the
Number Rejects Sent
STEP2 central system where the IDF was completely or partially accepted.
The number of Rejects that were rejected from partially accepted IDFs
Number Rejects Rejected
The number of Refunds/Returns received in IDFs from this Direct Participant
by the STEP2 central system where the IDF was completely or partially
Sent
accepted.
Number Refunds/Returns The number of Refunds/Returns that were rejected from partially accepted
Rejected IDFs received from this Direct Participant.
The number of Reversals received in IDFs from this Direct Participant by the
Number Reversals Sent
The number of Reversals that were rejected from partially accepted IDFs
Number Reversals Rejected
The Value of Debit Requests received in IDFs from this Direct Participant by
Value Direct Debit Sent the STEP2 central system where the IDF was completely or partially
accepted.
The Value of Debit Requests that were rejected from partially accepted IDFs
Value Direct Debit Rejected
The Value of Req for Canc received in IDFs from this Direct Participant by the
Value Req for Canc Sent
The Value of Req for Canc that were rejected from partially accepted IDFs
Value Req for Canc Rejected
The Value of Rejects received in IDFs from this Direct Participant by the
Value Rejects Sent
The Value of Rejects that were rejected from partially accepted IDFs received
Value Rejects Rejected
from this Direct Participant.
The Value of Refunds/Returns received in IDFs from this Direct Participant by
Value Refunds/Returns Sent the STEP2 central system where the IDF was completely or partially
accepted.
Value Refunds/Returns The Value of Refunds/Returns that were rejected from partially accepted IDFs
Rejected received from this Direct Participant.
The Value of Reversals received in IDFs from this Direct Participant by the
Value Reversals Sent
The Value of Reversals that were rejected from partially accepted IDFs
Value Reversals Rejected
Table 4-45 DRR files/bulk/messages sent header – field contents

STEP2 – M-PEDD
27th November 2009
F.2.4 DRR Direct Debit bulks sent

M Record Type 4x "DDSB" 0
M Sender's Reference 35x 4
M Number Direct Debit Sent 15n 39
Number Direct Debit
M 15n 54
Rejected
Table 4-46 DRR Direct Debit bulks sent body
The DRR Direct Debit bulks sent body contains one record for each bulk that was totally or
partially accepted by the STEP2 central system from the Direct Participant receiving the DRR
during the processing of the Interbank Settlement Date to which the DRR relates (if no bulks were
sent or all bulks sent were totally rejected then no records will be present). The contents of the
Field Name Contents

Sender's Reference The Reference of the bulk for which the information in this record relates.
The number of Direct Debit received by the STEP2 central system in this bulk.
Number Direct Debit Sent The contents of this field will equal the contents of the Total Number Of
Transactions field in the header of this bulk.
The number of Direct Debit from this bulk that were rejected by the STEP2
central system.
Number Direct Debit
Rejected A DVF containing these Direct Debit will have been transmitted to the Direct
Participant and the contents of this field will equal the contents of the Total
Number Rejected field in the header of that DVF.
The value of the Direct Debit received by the STEP2 central system in this
bulk.
Value Direct Debit Sent
The contents of this field will equal the contents of the Sum Of Amounts field
in the header of this bulk.
The value of the Direct Debit from this bulk that were rejected by the STEP2
central system.
Value Direct Debit Rejected A DVF containing these Direct Debits will have been transmitted to the Direct
Value Rejected field in the header of that DVF.
Table 4-47 DRR Direct Debit bulks body – field contents

STEP2 – M-PEDD
27th November 2009
F.2.5 DRR Req for Canc bulks sent

M Record Type 4x "DCSB" 0
M Number Req for Canc Sent 15n 39
Number Req for Canc
M 15n 54
Rejected
Table 4-48 DRR Req for Canc bulks sent body
The DRR Req for Canc bulks sent body contains one record for each bulk that was totally or
Field Name Contents

The number of Req for Canc received by the STEP2 central system in this
bulk.
Number Req for Canc Sent
The contents of this field will equal the contents of the Total Number Of
The number of Req for Canc from this bulk that were rejected by the STEP2
central system.
Number Req for Canc
Rejected A DVF containing these Req for Canc will have been transmitted to the Direct
The value of the Req for Canc received by the STEP2 central system in this
bulk.
Value Req for Canc Sent
The value of the Req for Canc from this bulk that were rejected by the STEP2
central system.
Value Req for Canc Rejected A DVF containing these Req for Canc will have been transmitted to the Direct
Table 4-49 DRR Req for Canc bulks body – field contents

STEP2 – M-PEDD
27th November 2009
F.2.6 DRR Rejects bulks sent

M Record Type 4x "DJSB" 0
Table 4-50 DRR Rejects bulks sent body
The DRR Rejects bulks sent body contains one record for each bulk that was totally or partially
accepted by the STEP2 central system from the Direct Participant receiving the DRR during the
processing of the Interbank Settlement Date to which the DRR relates (if no bulks were sent or all
bulks sent were totally rejected then no records will be present). The contents of the fields in each
such record are as follows:
Field Name Contents

The number of Rejects received by the STEP2 central system in this bulk.
Number Rejects Sent The contents of this field will equal the contents of the Total Number Of
The number of Rejects from this bulk that were rejected by the STEP2 central
system.
Number Rejects Rejected A DVF containing these Rejects will have been transmitted to the Direct
The value of the Rejects received by the STEP2 central system in this bulk.
Value Rejects Sent The contents of this field will equal the contents of the Sum Of Amounts field
The value of the Rejects from this bulk that were rejected by the STEP2
central system.
Value Rejects Rejected A DVF containing these Rejects will have been transmitted to the Direct
Table 4-51 DRR Rejects bulks body – field contents

STEP2 – M-PEDD
27th November 2009
F.2.7 DRR Reversals bulks sent

M Record Type 4x "DVSB" 0
Table 4-52 DRR Reversal bulks sent body
The DRR Reversals bulks sent body contains one record for each bulk that was totally or partially
accepted by the STEP2 central system from the Direct Participant receiving the DRR during the
processing of the Interbank Settlement Date to which the DRR relates (if no bulks were sent or all
bulks sent were totally rejected then no records will be present). The contents of the fields in each
such record are as follows:
Field Name Contents

The number of Reversals received by the STEP2 central system in this bulk.
Number Reversals Sent The contents of this field will equal the contents of the Total Number Of
The number of Reversals from this bulk that were rejected by the STEP2
central system.
Number Reversals Rejected A DVF containing these Reversals will have been transmitted to the Direct
The value of the Reversals received by the STEP2 central system in this bulk.
Value Reversals Sent The contents of this field will equal the contents of the Sum Of Amounts field
The value of the Reversals from this bulk that were rejected by the STEP2
central system.
Value Reversals Rejected A DVF containing these Reversals will have been transmitted to the Direct
Table 4-53 DRR Reversals bulks body – field contents

STEP2 – M-PEDD
27th November 2009
F.2.8 DRR Refunds/Returns bulks sent

M Record Type 4x "DFSB" 0
M 15n 39
Sent
M 15n 54
Rejected
Value Refunds/Returns
M 18d 87
Rejected
Table 4-54 DRR Refunds/Returns bulks sent body
The DRR Refunds/Returns bulks sent body contains one record for each bulk that was totally or
Field Name Contents

The number of Refunds/Returns received by the STEP2 central system in this
Number Refunds/Returns bulk.
Sent The contents of this field will equal the contents of the Total Number Of
The number of Refunds/Returns from this bulk that were rejected by the
STEP2 central system.
Rejected A DVF containing these Refunds/Returns will have been transmitted to the
Direct Participant and the contents of this field will equal the contents of the
Total Number Rejected field in the header of that DVF.
The value of the Refunds/Returns received by the STEP2 central system in
this bulk.
Value Refunds/Returns Sent
The value of the Refunds/Returns from this bulk that were rejected by the
Value Refunds/Returns
Rejected A DVF containing these Refunds/Returns will have been transmitted to the
Direct Participant and the contents of this field will equal the contents of the
Total Value Rejected field in the header of that DVF.
Table 4-55 DRR Refunds/Returns bulks body – field contents
F.2.9 DRR Returns of Reversals bulks sent

NOTE: The following section was reserved for data related only to the Return of Reversals. Since
the use of these messages will be inhibited in the system, this section will never appear in the
DRR files gernerated.

STEP2 – M-PEDD
27th November 2009

M Record Type 4x " DTSB " 0
Number Returns of Reversals
M 15n 39
Sent
M 15n 54
Rejected
Value Returns of Reversals
M 18d 69
Sent
M 18d 87
Rejected
Table 4-56 DRR Returns of Reversals bulks sent body
The DRR Returns of Reversals bulks sent body contains one record for each bulk that was totally
or partially accepted by the STEP2 central system from the Direct Participant receiving the DRR
Field Name Contents

The number of Returns of Reversals received by the STEP2 central system in
Number Returns of Reversals this bulk.
Sent The contents of this field will equal the contents of the Total Number Of
The number of Returns of Reversals from this bulk that were rejected by the
Rejected A DVF containing these Returns of Reversals will have been transmitted to
the Direct Participant and the contents of this field will equal the contents of
the Total Number Rejected field in the header of that DVF.
The value of the Returns of Reversals received by the STEP2 central system
Value Returns of Reversals in this bulk.
Sent The contents of this field will equal the contents of the Sum Of Amounts field
The value of the Returns of Reversals from this bulk that were rejected by the
Rejected A DVF containing these Returns of Reversals will have been transmitted to
the Direct Participant and the contents of this field will equal the contents of
the Total Value Rejected field in the header of that DVF.
Table 4-57 DRR Returns of Reversals bulks body – field contents

M Record Type 4x "DFTT” 0
Table 4-58 DRR files sent trailer

STEP2 – M-PEDD
27th November 2009
F.2.10 DRR DNFs received

M Record Type 4x "DNRH" 0
M Number DNFs Received 4n 4
Number DDs Bulks 4n
M 8
Received
Number Req for Canc Bulks 4n
M 12
Received
Number Rejects Bulks 4n
M 16
Received
Number Direct Debits 15n
M 20
Received
Number Req for Canc 15n
M 35
Received
M Number Rejects Received 15n 50
M Value Direct Debit received 18d 65
Value Req for Canc 18d
M 83
received
M Value Rejects received 18d 101
Table 4-59 DRR files received header
Each DRR contains one and only one DRR files received header record. The contents of the
fields in this record are as follows:
Field Name Contents

The number of DNFs generated by the STEP2 central system for this Direct
Number DNFs Received
Participant during the processing of this Interbank Settlement Date.
The number of DDs bulks generated by the STEP2 central system for this
Number DDs bulks Received
Direct Participant during the processing of this Interbank Settlement Date.
The number of Req for Canc bulks generated by the STEP2 central system
Number Req for Canc bulks
for this Direct Participant during the processing of this Interbank Settlement
Received
Date.
Number Rejects bulks The number of Rejects bulks generated by the STEP2 central system for this
Received Direct Participant during the processing of this Interbank Settlement Date.
The number of debit requests in DNFs generated by the STEP2 central
Number DDs Received system for this Direct Participant during the processing of this Interbank
Settlement Date
The number of Req for Canc in DNFs generated by the STEP2 central system
Number Req for Canc
for this Direct Participant during the processing of this Interbank Settlement
Received
Date
The number of Rejects in DNFs generated by the STEP2 central system for
Number Rejects Received
this Direct Participant during the processing of this Interbank Settlement Date
The value of debit requests in DNFs generated by the STEP2 central system
Value Direct Debit received for this Direct Participant during the processing of this Interbank Settlement
Date
The value of Req for Canc in DNFs generated by the STEP2 central system
Value Req for Canc received for this Direct Participant during the processing of this Interbank Settlement
Date
The value of Rejects in DNFs generated by the STEP2 central system for this
Value Rejects received
Direct Participant during the processing of this Interbank Settlement Date

STEP2 – M-PEDD
27th November 2009
Table 4-60 DRR files received header – field contents
Field Name Format Value Position

M Record Type 4x "DDRB" 0
M Number DDs Direct 15n 4
M Number DDs Indirect 15n 19
M Value DDs Direct 18d 34
M Value DDs Indirect 18d 52
Table 4-61 DRR DDs received body
The DRR files received body contains one record for each bulk type that was sent to the Direct
Participant receiving the DRR by the STEP2 central system during the processing of the
Interbank Settlement Date to which the DRR relates (if no bulks were sent then no records will be
present). The contents of the fields in each such record are as follows:
Field Name Contents

The number of DDs for which this Direct Participant is receiving the
Number DDs Direct
transactions as the receiving bank.
The number of DDs for which this Direct Participant is receiving the
Number DDs Indirect
transactions on behalf of an in Direct Participant as the receiving bank.
Value DDs Direct The value of the DDs identified in Number DDs Direct, above.
Value DDs Indirect The value of the DDs identified in Number DDs Indirect, above.
Table 4-62 DRR DDs received body – field contents

M Record Type 4x "DCRB" 0
M 4
Direct
M 19
Indirect
M Value Req for Canc Direct 18d 34
M Value Req for Canc Indirect 18d 52
Table 4-63 DRR Req for Canc received body
Field Name Contents

The number of Req for Canc for which this Direct Participant is receiving the
Number Req for Canc Direct
The number of Req for Canc for which this Direct Participant is receiving the
Number Req for Canc Indirect

STEP2 – M-PEDD
27th November 2009
Field Name Contents

The value of the Req for Canc identified in Number Req for Canc Direct,
Value Req for Canc Direct
above.
The value of the Req for Canc identified in Number Req for Canc Indirect,
Value Req for Canc Indirect
above.
Table 4-64 DRR Req for Canc received body – field contents

M Record Type 4x "DJRB" 0
M Number Rejects Direct 15n 4
M Number Rejects Indirect 15n 19
M Value Rejects Direct 18d 34
M Value Rejects Indirect 18d 52
Table 4-65 DRR Rejects received body
Field Name Contents

The number of Rejects for which this Direct Participant is receiving the
Number Rejects Direct
The number of Rejects for which this Direct Participant is receiving the
Number Rejects Indirect
Value Rejects Direct The value of the Rejects identified in Number Refunds/Returns Direct, above.
The value of the Rejects identified in Number Refunds/Returns Indirect,
Value Rejects Indirect
above.
Table 4-66 DRR Rejects received body – field contents

M Record Type 4x "DDRT” 0
Table 4-67 DRR files sent trailer
F.2.11 DRR - RSFs received

:

M Record Type 4x "DRRH" 0

STEP2 – M-PEDD
27th November 2009

M Number RSFs Received 6n 4
M Number RSFs Debit Bulks Received 6n 10
M Number RSFs Credit Bulks Received 6n 16
M Number Direct Debits credit 15n 22
M Number Direct Debits debit 15n 37
M Value Direct Debits credit 18d 52
M Value Direct Debits debit 18d 70
Table 4-68 DRR RSFs received header
Each DRR contains one and only one DRR RSFs files received header record. The contents of
the fields in this record are as follows:
Field Name Contents

Number RSFs Received The number of RSFs generated by the STEP2 central system for this Direct
Number RSFs Debit Bulks The number of RSFs debit bulks generated by the STEP2 central system for
Received this Direct Participant during the processing of this Interbank Settlement Date.
Number RSFs Credit Bulks The number of RSFs Credit bulks generated by the STEP2 central system for
Received this Direct Participant during the processing of this Interbank Settlement Date.
Number debit Direct Debits The number of Direct Debits Received in RSFs generated by the STEP2
central system for this Direct Participant during the processing of this
Number credit Direct Debits The number of Direct Debits sent in RSFs generated by the STEP2 central
system for this Direct Participant during the processing of this Interbank
Settlement Date
Value Direct Debit debit The value of Direct Debits Received in RSFs generated by the STEP2 central
Settlement Date
Value Direct Debits credit The value of Direct Debits sent in RSFs generated by the STEP2 central
Settlement Date
Table 4-69 DRR RSFs received header – field contents
F.2.12 DRR - RSFs Debit Direct debit

:

M Record Type 4x "DRRB" 0
M Number Debit Direct Debits settled 15n 4
M Number Debit Direct Debits Cancelled 15n 19
M Value Debit Direct Debits settled 18d 34
M Value Debit Direct Debits Cancelled 18d 52
Table 4-70 DRR RSFs Debit Direct Debit
Each DRR contains one and only one DRR RSFs Debit Direct debit record. The contents of the

STEP2 – M-PEDD
27th November 2009
Field Name Contents

Number Debit Direct Debit The number of Debit DDs settled for this Direct Participant during the
settled processing of this Interbank Settlement Date.
Number Debit Direct Debit The number of Debit DDs cancelled for this Direct Participant during the
Cancelled processing of this Interbank Settlement Date.
Value Debit Direct Debit The value of Debit DDs settled for this Direct Participant during the processing
settled of this Interbank Settlement Date.
Value Debit Direct Debit The value of Debit DDs cancelled for this Direct Participant during the
Table 4-71 DRR RSFs Debit Direct Debits – field contents
F.2.13 DRR -RSFs Credit Direct debit

M Record Type 4x "DRSB" 0
M Number Credit Direct Debits settled 15n 4
Number Credit Direct Debits 15n
M 19
Cancelled
M Value Credit Direct Debits settled 18d 34
M Value Credit Direct Debits Cancelled 18d 52
Table 4-72 DRR RSFs Credit Direct Debit
Each DRR contains one and only one DRR RSFs Credit Direct debit record. The contents of the
Field Name Contents

Number Credit Direct Debits The number of Direct Debits sent settled for this Direct Participant during the
Number Credit Direct Debits The number of Direct Debits sent cancelled for this Direct Participant during
Cancelled the processing of this Interbank Settlement Date.
Value Credit Direct Debits The value of Direct Debits sent settled for this Direct Participant during the
Value Credit Direct Debits The value of Direct Debits sent cancelled for this Direct Participant during the
Table 4-73 DRR RSFs Credit Direct Debit – field contents

M Record Type 4x "DRRT” 0
Table 4-74 DRR RSFs received Trailer
F.2.14 DRR - SDFs received header

:

STEP2 – M-PEDD
27th November 2009

M Record Type 4x "DSRH" 0
M Number SDFs Received 6n 4
Number SDFs Refunds/Returns Bulks 6n
M 10
Received
Number SDFs Reversal Bulks 6n
M 16
Received
M Reserved for future use 6n 22
Table 4-75 DRR SDFs received header
Each DRR contains one and only one DRR SDFs files received header record. The contents of
Field Name Contents

Number SDFs Received The number of SDFs generated by the STEP2 central system for this Direct
Number SDFs The number of SDFs Refunds/Returns bulks generated by the STEP2 central
Refunds/Returns Bulks system for this Direct Participant during the processing of this Interbank
Received Settlement Date.
Number SDFs Reversal Bulks The number of SDFs Reversal bulks generated by the STEP2 central system
Received for this Direct Participant during the processing of this Interbank Settlement
Date.
Reserved for future use Reserved for future use
Table 4-76 DRR SDFs received header – field contents
F.2.15 DSRB - SDFs Return/Reversal received

:

M Record Type 4x "DSRB" 0
M Number Refunds/Returns received 15n 4
M Value Refunds/Returns received 18d 19
M Number Reversal received 15n 37
M Value Reversal received 18d 52
M Reserved for future use 18d 85
Table 4-77 DRR SDFs Refunds/Return/Reversal received
Each DRR contains one and only one DRR files SDF return/reversal record. The contents of the
Field Name Contents

Number Refunds/Returns The number of Refunds/Return settled receive for this Direct Participant
received during the processing of this Interbank Settlement Date.
Value Refunds/Returns The value of Refunds/Return settled receive for this Direct Participant during
received the processing of this Interbank Settlement Date.

STEP2 – M-PEDD
27th November 2009
Field Name Contents

Number Reversal received The number of Reversal settled receive for this Direct Participant during the
processing of this Interbank Settlement Date.
Value Reversal received The value of Reversal settled receive for this Direct Participant during the
Table 4-78 DRR SDFs Return/Reversal received – field contents

M Record Type 4x "DSRT” 0
Table 4-79 DRR SDFs received Trailer
F.2.16 DSSH - CDFs received header

:

M Record Type 4x "DSSH" 0
M Number CDFs Received 6n 4
Number CDFs Refunds/Returns Bulks 6n
M 10
Received
Number CDFs Reversal Bulks 6n
M 16
Received
Table 4-80 DRR CDFs received header
Each DRR contains one and only one DRR CDFs files received header record. The contents of
Field Name Contents

Number CDFs Received The number of CDFs generated by the STEP2 central system for this Direct
Number CDFs The number of CDFs Refunds/Returns bulks generated by the STEP2 central
Refunds/Returns Bulks system for this Direct Participant during the processing of this Interbank
Received Settlement Date.
Number CDFs Reversal Bulks The number of CDFs Reversal bulks generated by the STEP2 central system
Received for this Direct Participant during the processing of this Interbank Settlement
Date.
Table 4-81 DRR CDFs received header – field contents
F.2.17 DSSB - CDFs Refunds/Return/Reversal received

:

STEP2 – M-PEDD
27th November 2009

M Record Type 4x "DSSB" 0
M Number Refunds/Returns received 15n 4
M Value Refunds/Returns received 18d 19
M Number Reversal received 15n 34
M Value Reversal received 18d 52
Table 4-82 DRR CDFs Return/Reversal received
Each DRR contains one and only one DRR files CDF return/reversal record. The contents of the
Field Name Contents

Number Refunds/Returns The number of Refunds/Returns cancelled receive for this Direct Participant
Value Refunds/Returns The value of Refunds/Returns cancelled receive for this Direct Participant
Number Reversal received The number of Reversal cancelled receive for this Direct Participant during the
Value Reversal received The value of Reversal cancelled receive for this Direct Participant during the
Table 4-83 DRR CDFs Refunds/Return/Reversal received – field contents

M Record Type 4x "DSST” 0
Table 4-84 DRR SDFs received Trailer
F.2.18 DRR Debit Party settlement Transactions header

M Record Type 4x "DPTH" 0
Number Debit Instructions 6n
M 4
sent
Number Debit Instructions 6n
M 10
Cancelled
M Value Debit Instructions sent 18d 16
Value Debit Instructions 18d
M 33
Cancelled
Table 4-85 DRR Debit Party settlement Direct Debits header
Each DRR contains one and only one DRR Debit Party settlement Transactions header record.
The contents of the fields in this record are as follows:

STEP2 – M-PEDD
27th November 2009
Field Name Contents

The number of settlement instructions sent to the external settlement
mechanism by the STEP2 central system during the processing of the
Number Debit Instructions Interbank Settlement Date to which this DRR refers where the Direct
sent Participant receiving this DRR was the debit party. The DRR settlement
transactions sent body will contain one record for each such settlement
instruction.
Number Debit Instructions The number of settlement instructions identified in Number Debit Instructions,
Cancelled above, that were cancelled by the external settlement mechanism.
The value of the settlement instructions identified in Number Debit
Value Debit Instructions sent
Instructions, above.
Value Debit Instructions The value of the settlement instructions identified in Number Debit Instructions
Cancelled Cancelled, above.
Table 4-86 DRR Debit Party settlement Transactions header – field contents

M Record Type 4x "DPTB" 0
M Settlement Reference 16x 4
M Credit Party DP BIC 4!a2!a2!c 28
M Credit Party Settlement BIC 4!a2!a2!c3!c 36
M Number DDs received 15n 47
M Number Reversals sent 15n 62
Number Refund/Returns
M 15n 77
received
M Value of DDs received 18d 107
M Value of Reversals sent 18d 125
M 18d 143
received
M Total Settlement Amount 18d 179
M Settlement Result* 4x 197
Table 4-87 DRR Debit Party settlement Direct Debits body
The DRR Debit Party settlement Transactions body contains one record for each settlement
instruction generated by the STEP2 central system during the processing of the Interbank
Settlement Date to which this DRR relates (if no settlement instructions were sent then no
records will be present) where the Direct Participant receiving this DRR is the debit party. The
contents of the fields in each such record are as follows:

STEP2 – M-PEDD
27th November 2009
Field Name Contents

Settlement Reference The unique STEP2 generated reference for this settlement instruction.
Settlement Cycle
generated.
generated.
The BIC of the Direct Participant who was the credit party of this settlement
Credit Party DP BIC
instruction.
The BIC used by the Direct Participant identified in Credit Party Settlement
Credit Party Settlement BIC
BIC, above, in the Multilateral Netting Module for settlement in TARGET2.
Number DDs received The number of DDs included in this settlement instruction.
Number Reversals sent The number of Reversals included in this settlement instruction.
Number Refunds/Returns The number of Refunds/Returns included in this settlement instruction.
received
Value of DDs received The value of the above Number DDs received.
Value of Reversals sent The value of the above Number Reversals sent.
Value of Refunds/Returns The value of the above Number Refunds/Returns received.
received
Settlement Amount The amount of this settlement instruction.
The result of TARGET2 processing of this settlement instruction, e.g.:
• “STLD”, indicating that the settlement instruction was successfully
Settlement Result*
processed, or
• “CANC”, indicating that the settlement instruction was cancelled.
Table 4-88 DRR Debit Party settlement Transactions body – field contents

M Record Type 4x "DPTT” 0
Table 4-89 DRR Debit Party settlement Transactions trailer

STEP2 – M-PEDD
27th November 2009
F.2.19 DRR Credit Party settlement transactions received

M Record Type 4x "DCTH" 0
M Number Credit Instructions 6n 4
Number Credit Instructions
M 6n 10
Cancelled
M Value Credit Instructions 18d 16
Value Credit Instructions
M 18d 34
Cancelled
Table 4-90 DRR s Credit Party settlement Transactions header
Each DRR contains one and only one DRR settlement Credit Party settlement Direct Debits
header record. The contents of the fields in this record are as follows:
Field Name Contents

Number Credit Instructions The number of settlement instructions generated by the STEP2 central
system during the processing of the Interbank Settlement Date to which this
DRR refers where the Direct Participant receiving this DRR was the credit
party. The DRR settlement transactions received body will contain one record
for each such settlement instruction.
Number Credit Instructions The number of settlement instructions identified in Number Credit Instruct,
Cancelled above, cancelled by the external settlement mechanism.
Value Credit Instructions The value of the settlement instructions identified in Number Credit Instruct,
above.
Value Credit Instructions The value of the settlement instructions identified in Number Credit Instruct
Cancelled Cancelled, above.
Table 4-91 DRR Credit Party settlement Direct Debits header – field contents

M Record Type 4x "DCTB" 0
M Settlement Reference 16x 4
M Debit Party DP BIC 4!a2!a2!c 28
M Debit Party Settlement BIC 4!a2!a2!c3!c 36
M Number DDs sent 15n 47
M Number Reversals received 15n 62
M 15n 77
sent
M Value of DDs sent 18d 107
M Value of Reversals received 18d 125
M 18d 143
sent
M Total Settlement Amount 18d 179
M Settlement Result* 4x 197

STEP2 – M-PEDD
27th November 2009
Table 4-92 DRR Credit Party settlement Transactions body
The DRR settlement Direct Debits received body contains one record for each settlement
instruction generated by the STEP2 central system during the processing of the Interbank
Settlement Date to which this DRR relates (if no settlement instructions were sent then no
records will be present) where the Direct Participant receiving this DRR was the credit party. The
contents of the fields in each such record are as follows:
Field Name Contents
Settlement Reference The unique STEP2 generated reference for this settlement instruction.
Settlement Cycle
generated.
generated.
The BIC of the Direct Participant who was the debit party of this settlement
Debit Party DP BIC
instruction.
The BIC used by the Direct Participant identified in Debit Party Settlement
Debit Party Settlement BIC
BIC, above, in the Multilateral Netting Module for settlement in TARGET2.
Number DDs sent The number of DDs included in this settlement instruction.
Number Reversals received The number of Reversals included in this settlement instruction.
Number Refunds/Returns The number of Refunds/Returns included in this settlement instruction.
sent
Value of DDs sent The value of the above Number DDs sent.
Value of Reversals received The value of the above Number Reversals received.
Value of Refunds/Returns The value of the above Number Refunds/Returns sent.
sent
Settlement Amount The amount of this settlement instruction.
The result of TARGET2 processing of this settlement instruction, e.g.:
• “STLD”, indicating that the settlement instruction was successfully
Settlement Result*
processed, or
• “CANC”, indicating that the settlement instruction was cancelled.
Table 4-93 DRR Credit Party settlement Transactions body – field contents

M Record Type 4x "DCTT” 0
Table 4-94 DRR Credit Party settlement Transactions trailer
F.2.20 DRR trailer

M Record Type 4x "TDRR” 0
Table 4-95 DRR trailer

STEP2 – M-PEDD
27th November 2009
F.3 Monthly Statistics Report (MSR)

The monthly statistics report gives Direct Participants detailed information with which they can:
• Calculate and justify the fees from counterparties for STEP2 services rendered to the
counterparty by the Direct Participant; and
• Reconcile the fees being requested by counterparties for STEP2 services delivered by the
counterparty to the Direct Participant.
F.3.1 MSR Record Table Index

TAG Multiplicity Definition Trailer
Record
HMSR 1-1 MSR Header
MTXH 1-1 MSR transactions sent header
MDSB 0-n MSR DDs sent body
MCSB 0-n MSR Req for Canc sent body
MJSB 0-n MSR Rejects sent body
MVSB 0-n MSR Reversals sent body
MFSB 0-n MSR Refunds/Returns sent body
MRSB 0-n MSR Return of reversal
1-1 MTXT
MTRH 1-1 MSR Direct Debits received header
MDRB 0-n MSR DDs received body
0-n MSR Req for Cancellation received
MCRB body
MJRB 0-n MSR Rejects received body
MVRB 0-n MSR Reversals received body
MFRB 0-n MSR Refunds/Returns received body
1-1 MTRT
1-1 TMSR
Table 4-96 MSR Record Table Index

STEP2 – M-PEDD
27th November 2009
F.3.2 MSR header

M Record Type 4x “HMSR” 0
M Service Identifier 3x “COR” for Core 4
or “B2B” for B2B
M File Type 3x "MSR" 7
M Sending Institution 4!a2!a2!c EBA STEP2 CS 10
BIC
*
%
M Reference Date 6!n 55
Table 4-97 MSR header
* CET (CEST in the summer).
% Reference Date is in YYMMDD format.

STEP2 – M-PEDD
27th November 2009
F.3.3 MSR body: statistics on Transactions sent

M Record Type 4x "MTXH" 0
M Number DDs Sent 15n 4
M Number DDs Rejected 15n 19
M Number DDs Cancelled 15n 34
M Number DDs Settled 15n 49
M Number Req for Cancellation 15n 64
Sent
Rejected
M Number Reversals Cancelled 15n 154
M Number Reversals Settled 15n 169
M Number Refunds/Returns 15n 184
Sent
Rejected
Cancelled
Settled
M Value Direct Debit Cancelled 18d 340
M Value Direct Debit Settled 18d 358
M Value Reversals Cencelled 18d 484
M Value Reversals Settled 18d 502
M Value Refunds/Returns 18d 538
Rejected
Cancelled
Settled

STEP2 – M-PEDD
27th November 2009
Table 4-98 MSR Transactions sent header

M Record Type 4x "MDSB" 0
M Receiving Participant 4!a2!a2!c 4
M Number DDs Accepted 15n 12
M Number DDs Cancelled 15n 27
M Number DDs Settled 15n 42
M Value DDs Accepted 18d 57
M Value DDs Cancelled 18d 75
M Value DDs Settled 18d 93
Table 4-99 MSR DDs sent body

M Record Type 4x "MCSB" 0
M Number Req for Canc 15n 12
Accepted
M Value Req for Canc 18d 27
Accepted
Table 4-100 MSR Req for Canc sent body

M Record Type 4x "MJSB" 0
M Number Rejects Accepted 15n 12
M Value Rejects Accepted 18d 27
Table 4-101 MSR Rejects sent body

M Record Type 4x "MVSB" 0
M Number Reversals Accepted 15n 12
M Number Reversals 15n 27
Cancelled
M Number Reversals Settled 15n 42
M Value Reversals Accepted 18d 57
M Value Reversals Cancelled 18d 75
M Value Reversals Settled 18d 93
Table 4-102 MSR Reversals sent body

M Record Type 4x "MFSB" 0

STEP2 – M-PEDD
27th November 2009

Accepted
Cancelled
Settled
Accepted
Cancelled
Settled
Table 4-103 MSR Refunds/Returns sent body

M Record Type 4x "MRSB" 0
M Number Returns of Reversals 15n 12
Accepted
Cancelled
Settled
M Value Returns of Reversals 18d 57
Accepted
Cancelled
Settled
Table 4-104 MSR Returns of reversals sent body

M Record Type 4x "MTXT” 0
Table 4-105 MSR transactions sent trailer
F.3.4 MSR body: statistics on Transactions received

M Record Type 4x "MTRH" 0
M Number DDs Received 15n 4
Received
M Number Reversals Received 15n 49
Received

STEP2 – M-PEDD
27th November 2009
M Value DDs Received 18d 94

M Value Req for Cancellation 18d 112
Received
M Value Rejects Received 18d 130
M Value Reversals Received 18d 148
M Value Refunds/Return 18d 166
Received
Table 4-106 MSR Transactions received header

M Record Type 4x "MDRB" 0
M Sending Participant 4!a2!a2!c 4
M Number DDs Received 15n 12
M Value DDs Received 18d 27
Table 4-107 MSR DDs received body

M Record Type 4x "MCRB" 0
Received
M Value Req for Cancellation 18d 27
Received
Table 4-108 MSR Req for Cancellation received body

M Record Type 4x "MJRB" 0
M Value Rejects Received 18d 27
Table 4-109 MSR Rejects received body

M Record Type 4x "MVRB" 0
M Number Reversals Received 15n 12
M Value Reversals Received 18d 27
Table 4-110 MSR Reversals received body

M Record Type 4x "MFRB" 0
Received

STEP2 – M-PEDD
27th November 2009

Received
Table 4-111 MSR Refunds/Returns received body

M Record Type 4x "MRRB" 0
Received
Received
Table 4-112 MSR Returns of Reversals received body

M Record Type 4x "MTRT” 0
Table 4-113 MSR transactions received trailer
F.3.5 MSR trailer

M Record Type 4x "TMSR” 0
Table 4-114 MSR trailer

STEP2 – M-PEDD
27th November 2009
F.4 Multilateral Balancing Payments

The MBP contains only settled and cancelled transactions. The DDs taken into account are the
ones with the month of the field “ReqdColltnDt” equal to the one for which the report is being
created.
The MBP Report file is an ascii text file in .csv format. Fields are separated by the “;” character
and records are separated by <CRLF>.
A different MBP Report File is generated for each Direct Participant. Counters will be calculated
in a multilateral basis for the DD exchanged and settled/cancelled in the referred month between
the DP receiving the report and it’s IP and the rest of the system.
The MBP file will be generated at the opening of the second TARGET day and delivered to each
Direct Participant
F.4.1 General Header row (1-1)

Field name Format Size Description
File Title Text 10x MBP Report
Service Text 3x The identifier of the service
Month of Reference Text 7x MM-YYYY (Month-Year)
Credit records Number 9n Number of detail rows for credit party
Debit records Number 9n Number of detail rows for debit party
F.4.2 Sent DD Header row (1- 1)

Field name Format Size Occ Value
See Value 1
Creditor Bank Text “Creditor Bank”
column
See Value 1
Debtor Bank Text “Debtor Bank”
column
See Value 1
Number of DD Number The number of DD
column
F.4.3 Sent DD Detail row (1- N)

Field name Format Size Occ Description
Creditor Bank BIC 11 Text 11x 1 The BIC 11 of the Creditor Bank
Debtor Bank BIC 11 Text 11x 1 The BIC 11 of the Debtor Bank
1 The number of DD sent and settled for the
Number of DD Number 9n
pair of Banks for the product

STEP2 – M-PEDD
27th November 2009
F.4.4 Received DD Header row (1- 1)
Field name Format Size Occ Value

See Value 1
Creditor Bank BIC 11 Text “Creditor Bank”
column
See Value 1
Debtor Bank BIC 11 Text “Debtor Bank”
column
See Value 1
Number of DD Number The number of DD
column
F.4.5 Received DD Detail row (1- N)

Field name Format Size Occ Description
Debtor Bank BIC 11 Text 11x 1 The BIC 11 of the Debtor Bank
Creditor Bank BIC 11 Text 11x 1 The BIC 11 of the Creditor Bank
1 The number of DD received and settled for
Number of DD Number 9n
the pair of Banks for the product

STEP2 – M-PEDD
27th November 2009
APPENDIX G STEP2 SWIFTNET CONNECTIVITY
STEP2 supports data transfer by different secure networks.
G.1 STEP2 SWIFTNet security infrastructure

STEP2 SWIFTNet infrastructure is built on the three layers of SWIFTNet, Network, messaging
and application layers.
Network Layer
A TCP/IP network uses IP packet authentication to provide Integrity of data transmission and
Authentication of sender. M-CPE, SWIFT Point of Presence (POP) protecting against external
attacks, authenticating between devices, filtering based on IP addresses, and including firewalls,
access control and physical security. Participants can connect via different dial up or leased line
options according to SWIFT policy.
Messaging Layer
Based around the SWIFTNet Link (SNL) the security protects against external attacks,
authenticates and encrypts between the Participant’s SNL and SWIFT, and between SWIFT and
STEP2 uses SNL PKI certificates for authentication. Each SNL is separately registered with
SWIFT with a unique SNL-ID and IP address.
Application Layer
EBA CLEARING as a SWIFT Market Infrastructure has created SWIFTNet services for
participants of STEP2.
STEP2 SWIFNet Pre-requisites
In order to connect to STEP2 over SWIFTNet you must have a SWIFTNet connection and
subscribe to
• FileAct (for File exchange); and to
• Interact and Browse (for Browser based reporting).
The nature of the SWIFTNet connection (e.g. via SNL or SWIFT Alliance Gateway) is up to the
3
bank but it must support the SWIFTNet service as shown below .
At least one SWIFT Alliance Webstation (SAB) is required to provide the direct enquiries on the
STEP2 Central System. The STEP2 application on the SAB uses InterAct for logging on to
STEP2, and then uses Browse. The application can, if required, be run on a SAB, which is also
used for other SWIFTNet banking applications.
3
File Sending via the SWIFT Alliance Webstation is not supported as this does not support
Delivery notifications.

STEP2 – M-PEDD
27th November 2009
G.2 STEP2 SWIFTNet Services

EBA CLEARING as a SWIFT Market Infrastructure has created two SWIFTNet services for
participants of STEP2.
The SWIFTNet services provide:
• A closed user group of participating institutions;

• User authentication, with PKI certificates – where users can be people or banking
applications;
• File level request type authentication and routing; where institutions can be permitted to
exchange some file types but not others.
• A mapping between application layer distinguished names (held by STEP2) with
messaging layer SNL ID’s held by SWIFT. This allows a participant to change to Disaster
Recovery mode with SWIFT, while making no change to their STEP2 profile.
• Non Repudiation Support for files and Interact messages. SWIFT maintains a copy of
certain file details for later query resolution. Delivery notifications are mandatory for files
sent across the service, to mark the transaction as complete.
• Reverse Billing. Banks are able to take financial responsibility for the files they receive
across the SWIFTNet network from the STEP2 services.
The STEP2 services do not use Store and Forward or SWIFT Message Validation (MVAL)
services.
Two services exist, a Pilot Service (eba.step2!pu1) and a Live Service (eba.step2) to which Direct
Participants must subscribe.
In order to join the STEP2 SWIFTNet services a bank must complete a SWIFTNet Messaging
Services Subscription Form (MSSF). This is agreed between EBA CLEARING, the participant
and SWIFT and the provisioned.
G.3 Information on STEP2 DNs, Request Types and End Points

Banks must enable Non-Repudiation Support for request and response of the negotiation, and
enable Non-Repudiation Support for request and response of the delivery notification. In this
case, the delivery notification must contain the digest of the received file. SwInt:RequestCrypto
element must be set "TRUE. For response messages, the SwInt:ResponseCrypto element must
be set "TRUE".
In addition:
- the DN to be used to exchange files with the STEP2 Central System is segregated by
service
- cn=cor-central,cn=serv,o=ebapfrpp,o=swift related to the Step2cormemb CUG category
for the Core service
cn=b2b-central,cn=serv,o=ebapfrpp,o=swift related to the Step2b2bmemb CUG category
for the B2B service
• the Request Type to be used to send files to the CS is "pacs.xxx.b2b.r.idf" and/or
"pacs.xxx.cor.r.idf"
• the Request Type to be specified to receive the Delivery Notification from the CS is
“xsys.xxx.delnotif”,
• the "eba.step2" service uses the Non-Repudiation Support for FileAct (this implies the
Delivery Notification usage).

STEP2 – M-PEDD
27th November 2009
The EndPoint is the name as the EndPoint configured in SNL (stand-alone or in the SAG) for your
application. This is normally entered on the MSS form as e.g. cn=step2corl,cn=eba (which is the
same as eba_step2corl for the SNL/SAG configuration) for the live system, and
cn=step2cor,cn=eba (which is the same as eba_step2cor) for pilot testing. However, if you are
sharing SAG with another STEP2 implementation then you may need to assign a different access
point to one of the applications. It is suggested that you add one extra letter to ‘eba’ (e.g. ‘ebax’),
since the size of this field is severely limited, and can only contain two cn’s.
G.4 STEP2 SWIFTNET Service Parameters Table

Service Parameters
SWIFTNet message Services
FileAct Y For File Sending
CUG Category
step2b2bmemb Direct participant as an entity exchanging files with
the B2B service
step2cormemb Direct participant as an entity exchanging files with
the Core service
Request types
pacs.xxx.b2b. or
pacs.xxx.cor.
r.idf Bank requests sending IDF to STEP2
s.dvf STEP2 requests sending DVF to Bank
s.dnf STEP2 requests sending DNF to Bank
s.psr STEP2 requests sending PSR to Bank
s.sdf STEP2 requests sending SDF to Bank
s.rsf STEP2 requests sending RSF to Bank
s.cdf STEP2 requests sending CDF to Bank
s.drr STEP2 requests sending DRR to Bank
s.msr STEP2 requests sending MSR to Bank
s.mbp STEP2 requests sending MBP to Bank
s.rtf STEP2 requests sending RTF to Bank
s.any STEP2 requests sending any file to Bank
Request for delivery notification Bank to STEP2, and
xsys.xxx.delnotif
STEP2 to bank.
Other configuration
RBAC control used N STEP2 uses RBAC
SWIFT maintains a copy of the file for later query
Non-Repudiation Support for resolution. Delivery notifications are mandatory for
Y
FileAct files sent across the service, to mark the transaction
as complete.
Store and Forward for Interact N STEP2 does not use SWIFT Store and Forward
Message Validation N STEP2 does not use SWIFT Message Validation
The Direct Participant will pay for the transmission of
transaction files they send to STEP2 and for the
Centralised Billing N
transmission of transaction files they receive from
STEP2.

STEP2 – M-PEDD
27th November 2009
G.5 SWIFTNet v6.0 and v6.1

The enhanced SWIFTNet FileAct Header will include the following changes:
From SWIFTNet 6.0
1. The FileInfo field in the FileAct header must now be formatted in a specific way:
<FileInfo>SwCompression=[value]</FileInfo>
Where the SwCompression value must be equal to “None”
From SWIFTNet 6.1
2. The new field “Total Number of Transactions” (TtlNbOfTxs) will be present and will contain the
number of transactions in files containing pacs messages.
Banks must populate this field in order to get SWIFTNet Bulk Pricing

STEP2 – M-PEDD
27th November 2009
G.6 Webstations URLs

CORE SERVICE
Environment URL
PILOT https://ebastep2.te.sia.it:1443/SEPADirectDebit/
LIVE https://ebastep2.sia.it:1443/SEPADirectDebit/
DR https://ebastep2-dr.sia.it:1443/SEPADirectDebit/
SIANet URLs
Environment IP address
PILOT https://193.178.206.23:1443/SEPADirectDebit/
LIVE https://193.178.206.71:1443/SEPADirectDebit/
DR https://193.178.205.71:1443/SEPADirectDebit/
SIANet IP addresses
Environment URL
PILOT https://eba-step2-pilot.swiftnet.sipn.swift.com/SEPADirectDebit/
LIVE https://eba-step2.swiftnet.sipn.swift.com/SEPADirectDebit/
DR https://eba-step2-dr.swiftnet.sipn.swift.com/SEPADirectDebit/
SWIFTNet URLs
B2B SERVICE
Environment URL
PILOT https://ebastep2.te.sia.it:1443/SEPADirectDebitB2B/
LIVE https://ebastep2.sia.it:1443/SEPADirectDebitB2B/
DR https://ebastep2-dr.sia.it:1443/SEPADirectDebitB2B/
SIANet URLs
Environment IP address
PILOT https://193.178.206.23:1443/SEPADirectDebitB2B/
LIVE https://193.178.206.71:1443/SEPADirectDebitB2B/
DR https://193.178.205.71:1443/SEPADirectDebitB2B/
SIANet IP addresses
Environment URL
PILOT https://eba-step2-pilot.swiftnet.sipn.swift.com/SEPADirectDebitB2B/
LIVE https://eba-step2.swiftnet.sipn.swift.com/SEPADirectDebitB2B/
DR https://eba-step2-dr.swiftnet.sipn.swift.com/SEPADirectDebitB2B/
SWIFTNet URLs

STEP2 – M-PEDD
27th November 2009
APPENDIX H SERVICE ROUTING TABLE
H.1 The Routing Tables
The Routing Table is available in two different parts: containing for Direct Participants and one
containing Indirect Participants. It can be downloaded directly from the Central System through
the use of the Direct Participant Web Station (DPWS).
A FileAct delivery is available with the following Network File Name convention:
The STEP2 Routing Tables will be distributed as an RTF (Routing Table File) file to all Direct
Participants. The extension of the RTF file is T.
The RTF naming convention will be as follow EEVVSSSBBBBBBBBYYMMDDHHMMSSPNN.Z:
EE Will be S2;
VV Will be 02;
SSS Service Identifier (COR or B2B);
BBBBBBBB The Direct Participant BIC (8);
YYMMDD The Creation Date;
HHMMSS The Creation Time;
P Routing Table Type (“D“ – Direct Participant or “I“ – Indirect
Participant);
NN Incremental number; and
Z The file type. Value T for RTF.
H.2 How to read the table
Each entry is one line in either the Direct or Indirect Participant table. By default, all of the entries
with a future End date will be present. For entries where the bank did not specificy an end date at
the time of registration, the value is always 31/12/9999.
A user can specify some search criteria to list entries according to specific conditions. The search
criteria refer to the options available on the DPWS to display the elements specified by the
operator.
A user can Download the entire routing table by clicking the Download button.
A user can download a subset of the routing table by using the search criteria on the DPWS as
follows.
The “DATE FROM” condition will return all of the entries in the table with Init Date greater
than or equal to the inserted value.

STEP2 – M-PEDD
27th November 2009
The “DATE TO” condition will return all of the entries in the table with End Date earlier than
or equal to the inserted value.
BIC, NAME and STATUS are self-explanatory. They can also be used as search criteria. A
full description of how to use this functionality will be in cluded in the DPWS User Manual.
H.3 Status used in the Routing Table

ENABLED status
The Participant is active in the system and can send and receive transactions as long as they
meet the following conditions:
- have a settlement date equal or greater than the Init Date

- have a settlement date equal or before the End Init Date
- are within the conditions of payment warehousing.
SUSPENDED status
The Participant is in suspended mode and can no longer send or receive any transaction.
Warehoused payments from or to this Participant will still be sent to the settlement mechanism on
the settlement date if they have been previously sent..
Suspended is a temporary status used for emergency conditions. A participant will never normally
see this status,
R-ONLY Participants
The status R-ONLY means that a Participant is no more able to send or receive Direct Debits, but
it is still able to send and receive R-Messages. Direct Debits will be rejected when the Settlement
Date of the pacs.003 is greater or equal to the Initial Date of the new Status. Any pacs.003
received and successfully validated by Step2 CS for/from the DP/IP before the status change will
be normally processed, settled and delivered to the counterpart.
A note on removal of banks in the directory.

At the end of the day, after the End Date has been reached, the status of the bank in the table is
updated to “DELETED”. These records are NOT included in the routing table that the bank
downloads.
H.4 Admission Profile

The Admisstion Profile can be one of the following values:
“CAD”: The Bank is both Debtor and Creditor Agent and can send AND receive Direct Debit
“CRD”: The Bank is a Creditor Agent only and can only send Direct Debit.The creditor bank
should never be able to receive a Request for cancellation or Reversal”.
“DEB”: The Bank is a Debtor Agent only and can only receive Direct Debit.The debtor bank
should never be able to receive a Refund/Return or a Reject/Refusal”.

STEP2 – M-PEDD
27th November 2009
Note: the functionality for the admission profile “CRD” is present in the system, but not available
for subscription by the participant.
H.5 Debit Type Allowed

This three characters code is for future use in the case of pre-defined AOS service usage. Note
that a blank Debit Type allowed is used for the default SEPA CORE and B2B service.
It refers to the Local Instrument Code field for Debit Collection and R-Messages.

STEP2 – M-PEDD
27th November 2009
H.6 Direct Participant Routing Table

H.6.1 Header row
“SDD Core” or “SDD B2B “ DIRECT
File Title Text 42x
PARTICIPANT ROUTING TABLE
H.6.2 Search Criteria header row 1

Row name Text 15x SEARCH CRITERIA

Header 2 col. A Text 3x BIC
Header 2 col. B Text 4x NAME
Header 2 col. C Text 9x DATE FROM
Header 2 col. D Text 7x DATE TO
Header 2 col. F Text 6x STATUS
Header 2 col. G Text 16x MATCHING RECORDS
H.6.4 Search criteria

BIC BIC (8) 8x BIC used in search criteria
Name Text 50x Bank Name used in search criteria
Date From YYYYMMDD 8x Date From used in search criteria
Date To YYYYMMDD 8x Date To used in search criteria
Status Text 9x Status used in search criteria
Matching Records Integer 4n Number of records returned in search

STEP2 – M-PEDD
27th November 2009
H.6.5 Results header row 1

Row name Text 7 RESULTS

Header 2 col. A Text 3 BIC
Header 2 col. B Text 4 NAME
Header 2 col. C Text 9 INIT DATE
Header 2 col. D Text 8 END DATE
Header 2 col. F Text 14 SETTLEMENT BIC
Header 2 col. H Text 6 STATUS
Header 2, col. G Text 17 ADMISSION PROFILE
Header 2, col. I Text 18 DEBIT TYPE ALLOWED

STEP2 – M-PEDD
27th November 2009
H.6.7 Results row

DP BIC BIC (8) 8x BIC(8) format.
DP Name Text 50x Bank name. Free format.
Init Date YYYYMMDD 8x Date from which BIC is valid.
End date YYYYMMDD 8x Date up to which BIC is valid
Settlement BIC BIC (11) 11x The BIC used for settlement of the IP data.
ENABLED, SUSPENDED, R-ONLY,
Status Text 9x
DISABLED
“DEB”or “CAD”. Whether a bank is a debtor

Admission Profile Text 3x
bank only or both Creditor and Debtor.
The Debit Type Allowed column may repeat
up to 10 times for each successive product
Debit Type Allowed Text 3c that the BIC may use. Format is 3
alphanumeric, e.g. 001,002,003, ABC etc
The Debit Type Allowed column may repeat up to 10 times for each successive product that the
BIC may use. Format is 3 alphanumeric, e.g. 001,002,003, ABC etc

STEP2 – M-PEDD
27th November 2009
H.7 Indirect Participant Routing Table

H.7.1 Header row
“SDD Core” or “SDD B2B “ INDIRECT
File Title Text 42x
PARTICIPANT ROUTING TABLE

Row name Text 15x SEARCH CRITERIA

Header 2 col. A Text 6x IP BIC
Header 2 col. B Text 7x IP NAME
Header 2 col. C Text 9x DATE FROM
Header 2 col. D Text 7x DATE TO
Header 2 col. E Text 6x DP BIC
Header 2 col. F Text 6x STATUS
Header 2 col. G Text 16x MATCHING RECORDS
H.7.4 Search Criteria results

BIC(11) format. Ending in XXX is
IP BIC BIC (11) 11x
permissible.
IP Name Text 50x Bank name. Free format.
Date From YYYYMMDD 8x Date from which BIC is valid.
Date To YYYYMMDD 8x Date up to which BIC is valid
The BIC of the associated Direct
DP BIC BIC (8) 8x
Participant.
Status Text 9x Status used in search criteria
Matching Records Integer 4n No. of Search Results rows returned

Row name Text 7x RESULTS

STEP2 – M-PEDD
27th November 2009

Header 2 col. A Text 6x IP BIC
Header 2 col. B Text 7x IP NAME
Header 2 col. C Text 9x INIT DATE
Header 2 col. D Text 8x END DATE
Header 2 col. E Text 6x DP BIC
Header 2 col. F Text 17x DP SETTLEMENT BIC
Header 2 col. H Text 6x STATUS
Header 2 col. G Text 17x ADMISSION PROFILE
Header 2 col. I Text 18x DEBIT TYPE ALLOWED
H.7.7 Results row

BIC(11) format. Ending in XXX is
IP BIC BIC (11) 11x
permissible.
IP Name Text 50x Bank name. Free format.
Init Date YYYYMMDD 8x Date from which BIC is valid.
End date YYYYMMDD 8x Date up to which BIC is valid
The BIC of the associated Direct
DP BIC BIC (8) 8x
Participant.
The BIC used for settlement of the IP data.
DP Settlement BIC BIC (11) 11x The DP settlement bic of an IP will have as
value ‘—‘ only if the DP is not active.
Status Text 9x ENABLED, R-ONLY, DISABLED
“DEB” or “CAD”. Whether a bank is a debtor
Admission Profile Text 3x
bank only or both Creditor and Debtor.
A 3-character code indicating the product(s)
Debit Type Allowed Text 3c
available to this participant
The Debit Type Allowed column may repeat up to 10 times for each successive product that the
BIC may use. Format is 3 alphanumeric, e.g. 001,002,003, ABC etc.

STEP2 – M-PEDD
27th November 2009
APPENDIX I ERROR CODE REFERENCE LIST
I.1 File Level Codes
File error codes are always used in the DVF header as part of the File Reject Reason (IdfErrCd)
field.
Code Description
A00 IDF totally accepted
A01 IDF partially accepted
R01 IDF received on non-Target day
R02 Network file name not compliant
R03 Unknown Service identifier
R04 Direct Participant BIC mismatch (network address)
R06 Invalid file name format
R07 Invalid file extension
R10 Schema validation failed
R11 Invalid Sending Institution
R12 Invalid Receiving Institution
R13 Duplicate IDF
R14 Invalid Test Code
R15 Invalid Sending Institution BIC format
R16 Invalid Receiving Institution BIC format.
R17 Invalid Service Identifier in File Header
R18 Direct Debit bulk number mismatch
R19 Request for Cancellation bulk number mismatch
R20 Returns bulk number mismatch
R21 Rejects bulk number mismatch
R22 Reversals bulk number mismatch
R23 All bulks rejected
R24 Maximum number of IDF received

STEP2 – M-PEDD
27 November 2009
I.2 Bulk Error codes
Bulk error codes are always used in the group header of a message as part of either the Code or Proprietary field.
Code Description Type Pacs006 Pacs002 Pacs007 Pacs004 Pacs002S2

RequestedByCustom
CUST ISO X
er
DUPL DuplicatePayment ISO X
AGNT IncorrectAgent ISO X
CURR IncorrectCurrency ISO X
UPAY UnduePayment ISO X
SUSP SuspiciousPayment ISO X
IncorrectAccountNum
AC01 ISO X
ber
ClosedAccountNumb
AC04 ISO X
er
AC06 BlockedAccount ISO X
AG01 TransactionForbidden ISO X
InvalidBankOperation
AG02 ISO X
Code
AM04 InsufficientFunds ISO X
AM05 Duplication ISO X X
ED05 SettlementFailed ISO X
MD01 NoMandate ISO X
MissingMandatoryInfo
MD02 ISO X
rmationOnMandate
InvalidFileFormatFor
MD03 OtherReasonThanGro ISO X
upingIndicator
EndCustomerDeceas
MD07 ISO X
ed

STEP2 – M-PEDD
27 November 2009

NotSpecifiedReasonA
MS03 ISO X
gentGenerated
BankIdentifierIncorrec
RC01 ISO X
t
RR01 Regulatory Reason PRTRY X
Specific Service
SL01 offered by Debtor PRTRY X X
Bank
NotSpecificedReason
PRTRY X
MS02 CustomerGenerated
NotSpecifiedReasonA
PRTRY X
MS03 gentGenerated
B00 Bulk totally accepted PRTRY X
Bulk partially
B01 PRTRY X
accepted
Maximum number of
B02 transactions in a bulk PRTRY X
exceeded
Number of
B03 transactions PRTRY X
mismatch
Total amount
B05 PRTRY X
mismatch
Control Sum
B07 PRTRY X
mismatch
Maximum number of
B08 bulks in a file PRTRY X
exceeded
All transactions
B09 PRTRY X
rejected
Instructing Agent
B10 PRTRY X
mismatch
Invalid use of
B11 PRTRY X
Instructed Agent
Zero Settlement
B13 PRTRY X
Amount
STEP2 – M-PEDD
27 November 2009

B14 Duplicate MessageID PRTRY X
Invalid Settlement
B15 PRTRY X
Date
Invalid Settlement Info
B16 PRTRY X
details
Too many
B23 consecutive rejected PRTRY X
transactions

STEP2 – M-PEDD
27 November 2009
I.3 Transaction level Error Codes
Transaction error codes are always used at the transaction level as part of either Code or Proprietary field.
Pacs002S2
Pacs006
Pacs002
Pacs007
Pacs004
Code Description Type
CUST RequestedByCustomer ISO X

DUPL DuplicatePayment ISO X
AGNT IncorrectAgent ISO X
CURR IncorrectCurrency ISO X
UPAY UnduePayment ISO X
SUSP SuspiciousPayment ISO X
AC01 IncorrectAccountNumber ISO X X
AC04 ClosedAccountNumber ISO X X
AC06 BlockedAccount ISO X X
AG01 TransactionForbidden ISO X X
AG02 InvalidBankOperationCode ISO X X
AM01 ZeroAmount ISO X
AM02 NotAllowedAmount ISO X
AM04 Insufficient Funds ISO X X
AM05 Duplication ISO X X X X

STEP2 – M-PEDD
27 November 2009
Pacs002S2
Pacs006
Pacs002
Pacs007
Pacs004
InvalidDate
This error code is also set when the settlement date is not consistent with the Direct Debit product configuration for
the following configuration parameters:
DD Earliest submission date
DT01 ISO X
DD Latest date for first or one-off
DD Latest date for recurring or final
Latest date for Reversal
Latest date for Returns
Latest date for Refund (auth /notauth)
ED05 SettlementFailed ISO X
MD01 NoMandate ISO X X X
MD02 MissingMandatoryInformationMandate ISO X X
MD03 InvalidFileFormatForOtherReasonThanGroupingIndicator ISO X X
MD06 RefundRequestByEndCustomer ISO X
MD07 EndCustomerDeceased ISO X X
MS02 NotSpecifiedReasonCustomerGenerated ISO X X
MS03 NotSpecifiedReasonAgentGenerated ISO X X
RC01 BankIdentifierIncorrect ISO X X
MS02 NotSpecifiedReasonCustomerGenerated PRTRY X
MS03 NotSpecifiedReasonAgentGenerated PRTRY X
RR01 NotSpecifiedReasonCustomerGenerated - Code used by banks to indicate a Return for Regulatory Reason PRTRY X X
SL01 Specific Service offered by Debtor Bank PRTRY X X
Unknown BIC in routing table - If the creditor agent is not an IP of the instructing agent or if DP/IP is not present in
PY01 PRTRY X
the routing table
XD19 Invalid IBAN format - An IBAN in the transaction has failed the ISO 13616 PRTRY X
Sequence Type Mismatch - If “Amendment Indicator” is “TRUE” and Original Debtor Agent is set to “SMNDA” to
XD75 PRTRY X
indicate same mandate with new Debtor Agent, the field DrctDbtTxInf < PmtTpInf< SeqTp must indicate “FRST”:
STEP2 – M-PEDD
27 November 2009
Pacs002S2
Pacs006
Pacs002
Pacs007
Pacs004
Unsupported XML field

The transaction contains at least one unsupported field;
XT13 At least one mandatory field is not present the transaction PRTRY X
The offending XML tag is present with the error code (if available).
Invalid data format - The content of at least one XML element is not in the required format.
XT33 PRTRY X
The offending XML tag is present with the error code
XT73 Invalid country code - The two characters for country code are not a valid ISO3166 country code PRTRY X
XT74 Invalid original transaction status, action required PRTRY X
XT75 Invalid original transaction status, action not required PRTRY X
XT77 The Interbank Settlement Amount is not the same as the original debit PRTRY X
XT78 Check on compensation amount in refunds failed PRTRY X
Debtor Agent not allowed to receive DD - If the admission profile does not admit the sending of a DD or Participant in
XT79 PRTRY X
R-ONLY status.
Creditor Agent not allowed to send DD - The Creditor Agent is not allowed to send Direct Debit as per the
XT80 PRTRY X
information available in the Routing Table
Only SEPA Core fields are allowed - A XML field present in the XML schemas but not permitted in the SDD services
XT81 PRTRY X
was used without prior agreement

0 - EBA STEP2 MPEDD Interface Specification v20091102 - Updated 091127 Clean Version

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

0 - EBA STEP2 MPEDD Interface Specification v20091102 - Updated 091127 Clean Version

Transféré par

Droits d'auteur :

Formats disponibles

STEP2 – Multi Purpose Direct Debits

Core Service and B2B Service

Core Rulebook 3.3

Version: 27th November 2009

• Version number aligned with EPC rulebook V 2.3

• Inserted Reports Mapping Table

Clarifications on MSR sending to participant . Par. 2.3.8.2

Version 20091102 (Core RB3.3 and B2B 1.2) 3 of 176

Version 20091102 (Core RB3.3 and B2B 1.2) 4 of 176

Version 20091102 (Core RB3.3 and B2B 1.2) 5 of 176

A.4 Duplicate Checking ...................................................................................................... 38

Version 20091102 (Core RB3.3 and B2B 1.2) 7 of 176

APPENDIX D ADDITIONAL IDF FILE VALIDATION ..................................................................... 103

Version 20091102 (Core RB3.3 and B2B 1.2) 8 of 176

G.5 SWIFTNet v6.0 and v6.1 ................................................................................................. 159

Version 20091102 (Core RB3.3 and B2B 1.2) 9 of 176

Version 20091102 (Core RB3.3 and B2B 1.2) 10 of 176

Table 2-1 Connection via a STEP2-enable payment system ________________________________ 22

Table 4-105 MSR transactions sent trailer ______________________________________________ 151

Version 20091102 (Core RB3.3 and B2B 1.2) 13 of 176

1.1 SEPA Direct Debit requirements

1.2 STEP2 Core and B2B Services

Version 20091102 (Core RB3.3 and B2B 1.2) 15 of 176

Version 20091102 (Core RB3.3 and B2B 1.2) 16 of 176

This term refers to Mandates. A ‘dematerialised’ mandate is a set

Version 20091102 (Core RB3.3 and B2B 1.2) 17 of 176

Version 20091102 (Core RB3.3 and B2B 1.2) 18 of 176

2. THE STEP2 SYSTEM

Sender Business Level message File Type XML XML Message

MPEDD To Confirmation / Rejection of Debit Validation File pacs.002S2 Payment Status

Version 20091102 (Core RB3.3 and B2B 1.2) 19 of 176

Sender Business Level message File Type XML XML Message

MPEDD to Notification of failed Cancelled Debit File pacs.002S2 Payment Status

MPEDD to all Machine Readable Report Pre-Settlement Report - -

This is shown diagrammatically in figures 2.1 to 2.6 below.

BULK 2: Requests for Cancellation (pacs.006.001.01)

BULK 4: Reversals (pacs.007.001.01)

BULK 5: Returns/Refunds (pacs.004.001.01) STEP2 Debit

Figure 2-1: Bulk types in IDF file sent to STEP2

BULK 3: Rejects (pacs.002.001.02) Bank

Version 20091102 (Core RB3.3 and B2B 1.2) 20 of 176

Figure 2-2: Bulk types in DNF file sent by STEP2

Figure 2-3: Bulk types in DVF file sent by STEP2

Figure 2-4: Bulk types in RSF file sent by STEP2

BULK 5: Returns/Refunds (pacs.004.001.01)

STEP2 Debit BULK 6: Return Reversal (pacs.004.001.01Rev)

Figure 2-5: Bulk types in SDF file sent by STEP2

Figure 2-6: Bulk types in CDF file sent by STEP2

2.2 Connecting to STEP2 as a Direct Participant

Version 20091102 (Core RB3.3 and B2B 1.2) 21 of 176

STEP2 provides facilities for the automatic routing of transactions

Routing via sender nominated intermediaries is not supported.

2.2.1 Connecting to STEP2 via a STEP2-enabled payment system

Figure 2-7: Connection via a STEP2-enable payment system

Version 20091102 (Core RB3.3 and B2B 1.2) 22 of 176

2.3 STEP2 MPEDD Filetypes

2.3.1 Input Debit File (IDF)

2.3.2 Debit Validation File (DVF)

2.3.3 Debit Notification File (DNF)

Direct Participants receiving DNFs can therefore either:

2.3.4 Pre-Settlement Report (PSR)

Version 20091102 (Core RB3.3 and B2B 1.2) 23 of 176