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 institutio ns which have received them from EBA CLEARING

Version: 27 th November 2009

STEP2 – M-PEDD

27th November 2009

STEP2 SEPA Debit Services Interface Specifications

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

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

Version 20091102 - 24 th 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.

Version 20091102 - 10 th February 2009

� List of corrections detailed in the “Errata” document. Version 20091102 - 17 th April 2009

� List of corrections detailed in the “Errata” document. V2.0 Version 20091102 - 03 rd September 2009

� List of corrections detailed in the “Errata” document. V2.3 Version 20091102 - 27 th 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

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 versions dated 26th 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 versio ning .............................................. 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 Poi nts ........................................... 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

ACH Automated Clearing House. PE-ACH is therefore a Pan-European ACH.

Agent

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 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.

Authorized / unauthorized debit

According to the EPC Rulebook: “If the disputed Collection is not covered by a valid Mandate, the transaction is considered to be an unauthorised transaction” (sect 4.4).

B2B Business-to-Business B2C Business-to-Consumer

BIC Bank Identifier Code. The worldwide unique identifier for a Bank. STEP2 SDD will use at least the eight-character BIC and up to an 11-character BIC to route debits.

Bilateral Gross Settlement

Each set of data sent from one Bank to another is settled separately. In other words, the R-Messages are not offset against the debits, and debits from one side are not offset by debits from the other.

Bulk A logical collection of Debit Messages or R-Messages. A bulk may only contain Debit Messages or R-Messages due to be settled on a single Interbank Settlement Date.

CDF Cancelled Debits File. This file is sent to the bank sending post-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

CSM Clearing And Settlement Mechanism – a general term for an ACH. STEP2 is a Pan-European CSM.

Debit Date This that the Debtor is Debited.Normally the same as the Due Date (except if that is a weekend) or the Interbank Settlement Date(except if that is a local bank holiday)

Debit Instruction

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 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.

Debit-Related instruction

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 Creditor Bank, which is part of the defined set of messages for the 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.

Debtor The individual or organization whose Bank account is debited via a Direct Debit.

Debtor Bank The Bank where the Debtor’s account is held.

STEP2 – M-PEDD

27th November 2009



Dematerialised This term refers to Mandates. A ‘dematerialised’ mandate is a set of data that makes up a mandate, whether it was originally paper-based or not. The dataset is defined in the EPC Rulebook.

Direct Participant A Direct Participant is a Bank who is a member of STEP2 and transmits and receives data directly to and from the STEP2 Debit Service.

DPWS Direct Participant Workstation. The operator interface between a Direct Participant and STEP2 SDD.

Due Date The date the Creditor asks for the money to be collected.

EPC

European Payments Council. The EPC produces a Rulebook which defines the functions that any SEPA Direct Debit service must provide. The current version of the EPC Rulebook is 2.3.

File A file is a technical term for a ‘wrapper’ that contains one of or more Bulks. Files and their definitions and naming conventions are covered in the Interface Specification.

Indirect Participant

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 Debit Service. Instead, it transmits data to and receives data from a Direct Participant with which it has an agreement.

Interbank Settlement Date

The date the funds move between banks.Normally the same as Due Date, but can be different if the Due Date is a non–TARGET day.

ISO20022

A standard defining the Universal Financial Industry message scheme (abbreviated to UNIFI), which provides the financial 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

Refusal

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 Bank prior to inter-bank Settlement, results in the Debtor Bank rejecting the associated Debit Message using the format of a Reject.

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 unacceptable to the Debtor Bank. It is accompanied by a Reason Code indicating the reason for rejection.

Request for Cancellation

An R-Message (q.v.) which is sent by the Creditor Bank in advance of settlement to cancel a previously sent transaction.

Request for Refund A Request for Refund is an R-Message (q.v.) which is initiated by the Debtor for reimbursement of a Direct Debit under the terms agreed by Debtors with their Debtor Bank.

Return A Return is an R-Message (q.v.) which is initiated by the Debtor Bank after inter-bank Settlement, because it is unable to process the Debit Message.

Reversal A Reversal is an R-Message (q.v.) which is initiated by the Creditor after the clearing and Settlement to reimburse the Debtor with the full or partial amount of the erroneous Debit Message.

R-Message

A R-Message is a message sent by one of the four parties to the transaction (Creditor, Creditor Bank, Debtor Bank, Debtor) which has the effect of diverting the Direct Debt Instruction to which it refers from its normal course of execution.

RSF Results of Settlement File. This file is sent to both sides of the transaction. It lists details of both successful and failed settlement of Debit messages.

STEP2 – M-PEDD

27th November 2009



SDF Settled Debits File. This file is sent to the sending bank and lists details of successfully settled post-settlement R-Messages.

SEPA Single Euro Payment Area

STEP2 STEP2 is the first pan-European automated clearing house (PE-ACH) for bulk payments in euro.

SWIFTNet The IP (Internet Protocol) -based messaging platform provided by SWIFT.

TARGET

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 mechanism (EPM). TARGET Days (see below) are the days on which the TARGET system operates.

TARGET Day

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,

� Good Friday (Catholic/Protestant),

� Easter Monday (Catholic/Protestant),

� 1 May (Labour Day),

� Christmas Day and

� 26 December.

Unknown Bank

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 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.

XML

Extensible Markup Language. An open standard for exchanging structured documents and data over the Internet that was 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 According to the scheme

File Type XML Message used

XML Message Description

Bank to MPEDD

Debit Request Request for Cancellation Reject Refusal Return Request for Refund (Core only) Reversal

Input Debit File (IDF) pacs.003 pacs.006 pacs.002 pacs.002 pacs.004 pacs.004 pacs.007

FI to FI Customer Direct Debit Request for Cancellation Payment Status Report Payment Status Report Payment Return Payment Return Payment Reversal

MPEDD To Sending Bank

Confirmation / Rejection of messages received

Debit Validation File (DVF)

pacs.002S2 Payment Status Report

MPEDD To Receiving Bank

Debit Request Request for Cancellation Reject Refusal

Debit Notification File (DNF)

pacs.003 pacs.006 pacs.002 pacs.002

FI to FI Customer Direct Debit Request for Cancellation Payment Status Report Payment Status Report

MPEDD to both sending and receiving bank

Confirmation of Settled Debits Notification of Cancelled Debits

Results of Settlement File (RSF)

pacs.002S2 pacs.002S2

Payment Status Report Payment Status Report

MPEDD to receiving Bank

Return Request for Refund

Settled Debit File (SDF)

pacs.004 pacs.004

Payment Return Payment Refund

STEP2 – M-PEDD

27th November 2009



Sender Business Level message According to the scheme

File Type XML Message used

XML Message Description

(Core only) Reversal

pacs.007

Payment Reversal

MPEDD to sending Bank

Notification of failed settlement for Return Refund Reversal

Cancelled Debit File (CDF)

pacs.002S2 Payment Status Report

MPEDD to all banks

Machine Readable Report Pre-Settlement Report (PSR)

- -

MPEDD to all banks

Machine Readable Report Daily Reconciliation Report (DRR)

- -

MPEDD to all banks

Machine Readable Report Monthly Statistical Report (MSR)

- -

MPEDD to all banks

Comma Separated Values Multilateral Balancing Payments Report (MBP)

- -

MPEDD to all banks

Comma Separated Values Routing table file Report (RTF)

- -

This is shown diagrammatically in figures 2.1 to 2.6 below.

STEP2 DebitService

IDFBULK 1: Debit collections (pacs.003.001.01)

BULK 3: Rejects (pacs.002.001.02)

BULK 4: Reversals (pacs.007.001.01)

BULK 2: Requests for Cancellation (pacs.006.001.01)

BULK 5: Returns/Refunds (pacs.004.001.01)

$

Bank

€

BULK 6: Return Reversal (pacs.004.001.01Rev)

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

STEP2 DebitService

DNF

BULK 1: Debit collections (pacs.003.001.01)

BULK 3: Rejects (pacs.002.001.02)

BULK 2: Requests for Cancellation (pacs.006.001.01)

$

Bank

€

STEP2 – M-PEDD

27th November 2009



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

STEP2 DebitService

DVFBULK 3: Rejects (pacs.002.001.02S2)

$

Bank

€

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

STEP2 DebitService

RSFBULK 3: Status (pacs.002.001.02S2)

$

Bank

€

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

STEP2 DebitService

SDF

BULK 4: Reversals (pacs.007.001.01)

BULK 5: Returns/Refunds (pacs.004.001.01)

$

Bank

€

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

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.

Figure 2-7: Connection via a STEP2-enable payment s ystem

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 syste m

STEP2 Central System

Network1,7

1,2,3,4,7

Direct ParticipantPayment System(s)

1,7

1,2,3,4,7

WebstationInterface 5 6

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 ve rsioning

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: • No leading spaces are allowed; • No internal spaces are allowed; • Trailing spaces are ignored; and • 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

€

Bank A

€

Bank B

€€€

€€€€

Bank C

STEP2 Debit

Service

IDF

BULK 1: Debits for Banks B and C

BULK 2: Debits for Bank B

BULK 3: Debits for Bank C

STEP2 Debit

Service

STEP2 Debit

Service

DNFBULK 4: Debits from Bank A

DNFBULK 5: Debits from Bank A

1

2a

2b

€

Bank A

€

Bank B

€€€

€€€€

Bank C

STEP2 Debit

Service

RSF

BULK 1: Settled Debits for Banks B, C

BULK 2: Settled Debits for Bank B

BULK 3: Settled Debits for Bank C

STEP2 Debit

Service

STEP2 Debit

Service

RSFBULK 4: Settled Debits from Bank A

RSFBULK 5: Settled Debits from Bank A

3a

3b

3c

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

XML Element The ISO20022 XML tag name used to identify the field. Where the field is nested under other tags, this nesting is shown.

Format

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) 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

Status

Whether the field is M - Mandatory O - Optional 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.

Validation rules This column details the validation that will be performed on the field. 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. a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + 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 Individual Transaction Not Present

DVF

DVF Field Level Status Instructing Agent Group Header Not Present Individual Transaction Not Present Instructed Agent Group Header Not Present Individual Transaction Not Present

DNF and SDF

Fields Level Status Instructing Agent Group Header Not Present Individual Transaction Mandatory Instructed Agent Group Header Mandatory Individual Transaction Not Present

RSF (Sent to Instructed Agent)

Field Level Status Instructing Agent Group Header Not Present Individual Transaction Not Present Instructed Agent Group Header Mandatory Individual Transaction Not Present

RSF (Sent to Instructing Agent)

Field Level Status Instructing Agent Group Header Mandatory Individual Transaction Not Present Instructed Agent Group Header Not Present Individual Transaction Not Present

CDF

Field Level Status Instructing Agent Group Header Mandatory Individual Transaction Not Present Instructed Agent Group Header Not Present 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.

Service Message Type

Reference Number Bank ID Date

Files Core/B2B - File Reference Sender -

IDF Bulks Core/B2B - Msg ID Instructing

Agent -

STEP2 generate

Bulks Core/B2B - Msg ID STEP2 BIC -

Debit Request Core/B2B pacs.003 Transaction ID

Creditor Bank

Interbank Settlement

Date STEP2 Reject

Core/B2B pacs.002 Status ID STEP2 BIC Processing

Date

Bank Reject Core/B2B pacs.002 Status ID Original Debtor Agent

Processing Date

STEP2 Cancellation

Core/B2B pacs.002 Status ID STEP2 BIC Processing

Date

Request for Cancellation

Core/B2B pacs.006 Cancellation ID Original Creditor Agent

Processing Date

Return / Refund

Core/B2B (only

Return) pacs.004 Return ID

Original Debtor Agent


Date

Reversal Core/B2B pacs.007 Reversal ID Original Creditor 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:

• No leading spaces are allowed; • No internal spaces are allowed; • Trailing spaces are ignored; and • 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 de bits

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 C ancellation 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 Rever sal 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

M Sending Institution SndgInst 4!a2!a2!c The BIC of the Direct Participant sending the file.

M Receiving Institution RcvgInst 4!a2!a2!c The STEP2 CS BIC code.

M File Reference FileRef 16!c The Direct Participant reference of the IDF.

M Service Identifier SrvcId 3!a Must be “COR” for Core or “B2B” for B2B (Error code R17)

M Test Code TstCode 1!a Must be always “T” or “P”, depending on the environment used

M File Type FType 3!a Must be always “IDF”

M File Date and Time FDtTm ISODateTime The file creation Date and Time

M Number of PACS.003 Debit Requests bulks NumDDBlk 8n The total number of debit requests bulks

M Number of PACS.006 Requests for Cancellation bulks

NumRFCBlk 8n The total number of requests for cancellation bulks

M Number of PACS.002 Reject bulks NumREJBlk 8n The total number of rejects bulks

M Number of PACS.007 Reversals bulks NumRVSBlk 8n The total number of reversals bulks

M Number of PACS.004 Returns/Refunds bulks NumRFRBlk 8n The total number of return/refund

requests bulks

M Number of PACS.004.002 Return of Reversal bulks

NumRRVBlk 8n The total number of return reversals bulks. Must be set to zero.

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.


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

M Receiving Institution RcvgInst 4!a2!a2!c The BIC of the Direct Participant

sending the file.

M Service Identifier SrvcId 3!a

The STEP2 3 characters service identifier “COR” for Core or “B2B” for B2B.

M Test Code TstCode 1!a 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

M File Date And Time FileDtTm ISO Date

The Date & Time in which this file was generated by STEP2 CS

STEP2 – M-PEDD

27th November 2009




C Original IDF Reference OrigFRef 16!c

The Original IDF Reference; in circumstances where it has not been possible to gather this information Original IDF Reference will not be present.

M Original IDF File Name OrigFName 32x The Original IDF Network file Name.

C Original Date And Time OrigDtTm ISO Date

In circumstances where it has not been possible to gather this information OrigDtTm will not be present. In DVFs that contain rejected transactions the contents are duplicated in the CreationDate element in the Header (which contains information from the original IDF).

M IDF Error Code IdfErrCd 3!c

The IDF error code showing whether the IDF was Accepted or Rejected. The Rejected error code shows the Rejection reason. See Appendix D

M File Business Date FileBusDt ISO Date

The business date in which this file was created by the STEP2 central system.

M File Cycle Number FileCycleNo 2!n The cycle in which this file was

created by the STEP2 central system.

Table 4-6 DVF STEP2 File Header Elements

B.3 Debit Notification File STEP2 File Header



M Receiving Institution RcvgInst 4!a2!a2!c The BIC of the Direct Participant receiving

the file.

M Service Identifier SrvcId 3!a Must be “COR” for Core or “B2B” for B2B

M Test Code TstCode 1!a 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

M File Business Date FileBusDt ISODate

The business date when this file was created

M Routing Indicator RoutingInd 3!a

The routing Indicator DIR: Direct Participant File IND: Indirect Participant File ALL: Both

M File Cycle Number FileCycleNo 2!n The cycle in which this file was created by

the STEP2 central system.

M Number of PACS.003 Debit Requests bulks

NumDDBlk 8n The total number of debit requests bulks notified in this file

M

Number of PACS.006 Requests for Cancellation bulks

NumRFCBlk 8n The total number of requests for cancellation bulks notified in this file

M Number of PACS.002

NumREJBlk 8n The total number of rejections bulks notified

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



M Receiving Institution RcvgInst 4!a2!a2!c The BIC of the Direct Participant

receiving the file.

M Service Identifier SrvcId 3!a

The STEP2 3 characters service 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



M File Business Date FileBusDt ISO Date

The business date in which this file was created by the STEP2 central system.

M File Cycle Number FileCycleNo 2!n The cycle in which this file was

created by the STEP2 central system.

Table 4-8 Response to Settlement File STEP2 File He ader Elements

B.5 Settled Debit File (SDF) STEP2 File Header



M Receiving Institution RcvgInst 4!a2!a2!c The BIC of the Direct Participant receiving the file.

M Service Identifier SrvcId 3!a Must be “COR” for Core or “B2B” for B2B.

M Test Code TstCode 1!a Equals always to “T” or “P”, depending 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.



M File Business Date FileBusDt ISO Date The business date in which this file was created by the STEP2 central system.

M File Cycle Number FileCycleNo 2!n The cycle in which this file was created by the STEP2 central system.

Table 4-9 Settled Debits File STEP2 File Header Ele ments

B.6 Cancelled Debits File (CDF) STEP2 File Header



STEP2 – M-PEDD

27th November 2009




M Receiving Institution RcvgInst 4!a2!a2!c The BIC of the Direct Participant sending the file.

M Service Identifier SrvcId 3!a Must be “COR” for Core or “B2B” for 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.

M File Business Date FileBusDt ISO Date The business date in which this file was created by the STEP2 central system.

M File Cycle Number FileCycleNo 2!n The cycle in which this file was created 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 +MsgId

35x M NA IDF:The DP’s bulk reference • 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 +CreDtTm

ISODate &Time

M NA The date & time in which this bulk was created by the DP.

GrpHdr +NbOfTxs

15n M NA The number of transactions included in this bulk. • 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 +TtlIntrBkSttlmAmt

18d&3!a M NA The total amount of transactions inside this bulk. • 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 +IntrBkSttlmDt

ISODate M AT-26 The business date in which the transactions inside this bulk must be settled in the relevant settlement mechanism.

• Must be a Target Date and in the allowed range : Error code B15

GrpHdr +SttlmInf ++SttlmMtd

4!a M NA Information on settlement method. • Only the value “CLRG” is supported: schema validation.

STEP2 – M-PEDD

27th November 2009



XML Element Format Status Rule Book Ref Validation Rules

GrpHdr +SttlmInf ++ClrSys +++Prtry

3!a M NA The Identifier of the the Clearing System. Proprietary identification of the Clearing System. Value is ‘ST2’. Error code B16.

GrpHdr +InstgAgt ++FinInstnId +++BIC

4!a2!a2!c

C NA Used only in IDF: error code B10 The DP originating this bulk. Must equal SndgInst element in IDF and must not contain a branch code: error code B10.

GrpHdr +InstdAgt ++FinInstnId +++BIC

4!a2!a2!c

C NA Used only in DNF: error code B11 The DP receiving this bulk.

• Equal RcvgInst element in DNF

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 Ref Validation Rules

DrctDbtTxInf +PmtId ++InstrId

35x O NA

The Instruction Id. This identification cannot include leading, trailing or internal spaces. (schema validation)

DrctDbtTxInf +PmtId ++EndToEndId

35x M AT-10 The End to End Id. • In the case it is not available, the value must be NOTPROVIDED. This is not

validated by STEP2. DrctDbtTxInf +PmtId ++TxId

35x M AT-43 The Transaction Id: • Uniqueness is checked under the rules for duplicate checking: error code AM05. • This identification cannot include leading, trailing or internal spaces. (schema

validation) DrctDbtTxInf +PmtTpInf ++SvcLvl +++Cd

4!a M AT-20 The Service Level:

• Must be “SEPA”: (schema validation)

DrctDbtTxInf +PmtTpInf ++LclInstrm +++Cd

35x M NA The indication of the scheme or service:

• Values allowed are found in the Product Table, CORE or B2B, depending on the relevant service: error code XT33

DrctDbtTxInf +PmtTpInf ++SeqTp

4!a M AT-21 • Accepted values are FRST, OOFF, RCUR, FNAL • If “Amendment Indicator” is “TRUE” and Original Debtor Agent is set to “SMNDA” to

indicate same mandate with new Debtor Agent, this field must indicate “FRST”: error code XD75.

DrctDbtTxInf +PmtTpInf ++CtgyPurp

4!a O AT-59 The category purpose.

STEP2 – M-PEDD

27th November 2009




DrctDbtTxInf +IntrBkSttlmAmt Attribute

18d 3!a

M M

AT-06 The amount of this transaction. • 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)

• 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 +InstdAmt Attribute

18d 3!a

O

NA • The Instructed Amount

DrctDbtTxInf +XchgRate

11d O NA • The Exchange rate of the Direct Debit.

DrctDbtTxInf +ChrgBr

4!a M NA • Only SLEV is allowed: (schema validation)

DrctDbtTxInf +ChrgsInf ++ChrgsAmt Attribute

18d 3!a

O C

NA • The Charges Amount

DrctDbtTxInf +ChrgsInf ++ChrgsPty +++FinInstnId ++++BIC

4!a2!a2!c[3!c] O NA

• The Charges Party

DrctDbtTxInf +ReqdColltnDt

ISO DATE M AT-11 • Must be greater than or equal to First Submission Date; • 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




DrctDbtTxInf +DrctDbtTx ++MndtRltdInf +++MndtId

35x M AT-01 The unique MandateID • Leading and trailing spaces inside the MndtId field are not significant and are

removed before storing the Mandate Identifier content in the CS Database.

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 +DrctDbtTx ++MndtRltdInf +++DtOfSgntr

ISO DATE M AT-25 • The Date of Signature of the Mandate • Not checked by STEP2 Central System

DrctDbtTxInf +DrctDbtTx ++MndtRltdInf +++AmdmntInd

Boolean O NA • If is set to “true” at least one of the following 6 fields must be present: error code XT13;

• If is set to “false” none of the following 6 fields must be present: error code XT13.

DrctDbtTxInf +DrctDbtTx ++MndtRltdInf +++AmdmntInfDtls ++++OrgnlMndtId

35x C AT-19 • Conditional on Amendment Indicator (see above): error code XT13.

DrctDbtTxInf +DrctDbtTx ++MndtRltdInf +++AmdmntInfDtls ++++OrgnlCdtrSchmeId +++++Nm

70x C AT-03 • Conditional on Amendment Indicator (see above): error code XT13

STEP2 – M-PEDD

27th November 2009



DrctDbtTxInf +DrctDbtTx ++MndtRltdInf +++AmdmntInfDtls ++++OrgnlCdtrSchmeId +++++Id ++++++PrvtId +++++++OthrId ++++++++Id

35x C AT-18

• Conditional on Amendment Indicator (see above): error code XT13

DrctDbtTxInf +DrctDbtTx ++MndtRltdInf +++AmdmntInfDtls ++++OrgnlCdtrSchmeId +++++Id ++++++PrvtId +++++++OthrId ++++++++IdTp

35x C AT-18

• Conditional on Amendment Indicator (see above): error code XT13; • Used only if OrgnlCdtrSchmeId is used; and • Must be SEPA: (schema validation)

DrctDbtTxInf +DrctDbtTx ++MndtRltdInf +++AmdmntInfDtls ++++OrgnlDbtrAcct +++++Id ++++++IBAN

2!a2!n30x C NA

• Conditional on Amendment Indicator (see above): error code XT13

DrctDbtTxInf +DrctDbtTx ++MndtRltdInf +++AmdmntInfDtls ++++OrgnlDbtrAgt +++++FinInstId ++++++PrtryId +++++++Id

35x C NA • Conditional on Amendment Indicator (see above): error code XT13; • Must equal “SMNDA” (error code XT13); • To be used with a FRST indicator in the sequence type if SMNDA is used. Error

code XT33.

STEP2 – M-PEDD

27th November 2009



DrctDbtTxInf +DrctDbtTx ++MndtRltdInf +++ElctrncSgntr

1025x O AT-16 AT-17 AT-60

Placeholder for Electronic Signature (AT-16 Placeholder for the Electronic Signature Data, if applicable) (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 +DrctDbtTx ++CdtrSchmeId +++Id ++++PrvtId +++++OthrId ++++++Id

35x M AT-02 • Validated as per format detailed in A.6: Error code XT33. • Note that usage of PrivateId/OtherId applies both for organisations and institutions

(as per EPC DD Implementation Guidelines recommendations)

DrctDbtTxInf +DrctDbtTx ++CdtrSchmeId +++Id ++++PrvtId +++++OthrId ++++++IdTp

35x M NA

• Must be “SEPA”: (schema validation)

DrctDbtTxInf +Cdtr ++Nm

70x M AT-03 • The Name of the Creditor

DrctDbtTxInf +Cdtr ++PstlAdr +++AdrLine

70x O AT-05

• Address line can have a maximum of two occurrences: (schema validation)

DrctDbtTxInf +Cdtr ++PstlAdr +++Ctry

2!a C AT-05 • Country of the Creditor address. • Must be a valid country code according to ISO3166. Error code: XT73 • Mandatory if Address Line is used (schema validation)

STEP2 – M-PEDD

27th November 2009



DrctDbtTxInf +Cdtr ++CtryOfRes

2!a O NA • The Creditor Country of Residence. • Must be a valid country code according to ISO3166. Error code: XT73

DrctDbtTxInf +CdtrAcct ++Id +++IBAN

2!a2!n30x M AT-04 • First two characters must be a valid country code according to ISO3166. Error code: XT73

• First two characters must be a valid SEPA country code • Must pass validation using ISO 13616: error code XD19.

DrctDbtTxInf +CdtrAgt ++FinInstId +++BIC

4!a2!a2!c[3!c] M AT-12 • Must be an active DP or IP: error code PY01; and • Indirect Participant must be configured in Central System as being associated to a

Direct Participant which is equal to the Instructing Agent : error code PY01; and • The Creditor Agent must be allowed to send DD as per service configuration: error

code XT80 DrctDbtTxInf +UltmtCdtr ++Nm

70x O AT-38 • The Ultimate Creditor Name

DrctDbtTxInf +UltmtCdtr ++PstlAdr +++AdrLine

70x O NA Address line can have a maximum of two occurrences. (schema validation)

DrctDbtTxInf +UltmtCdtr ++PstlAdr +++Ctry

2!a C NA Country of the Ultimate Creditor

DrctDbtTxInf +UltmtCdtr ++Id +++OrgId

See Schemas C AT-39 The identification of the Ultimate Creditor: Organisation Id. Cannot be used at the same time as Id/PrvtId (below) (schema validation) All of the ISO options are available (see ISO document or schema).

DrctDbtTxInf +UltmtCdtr ++Id +++PrvtId

See Schemas C AT-39 The identification of the Ultimate Creditor: Private Id. Cannot be used at the same time as Id/OrgId (above) (schema validation) All of the ISO options are available (see ISO document or schema).

DrctDbtTxInf +UltmtCdtr ++CtryOfRes

2!a O NA The Country of Residence of the Ultimate Creditor.

STEP2 – M-PEDD

27th November 2009



DrctDbtTxInf +InstgAgt ++FinInstnId +++BIC

4!a2!a2!c C NA • The DP originating this Direct Debit • Used in DNF only: error code XT13

DrctDbtTxInf +Dbtr ++Nm

70x M AT-14 • The Name of the Debtor.

DrctDbtTxInf +Dbtr ++PstlAdr +++AdrLine

70x O AT-09

• Address line can have a maximum of two occurrences: (schema validation)

DrctDbtTxInf +Dbtr ++PstlAdr +++Ctry

2!a C AT-09 • Country of the Debtor address. • Must be a valid country code according to ISO3166. Error code : XT73 • Mandatory if Address Line is used (schema validation)

DrctDbtTxInf +Dbtr ++Id +++OrgId

See Schemas C

AT-27

The identification of the Debtor : Organisation ID If used, cannot be used at the same time as Id/PrvtId (below) (schema validation) All of the ISO options are available (see ISO document or schema)

DrctDbtTxInf +Dbtr ++Id +++PrvtId

See Schemas C

AT-27

The identification of the Debtor: Private ID. If used, cannot be used at the same time as Id/OrgId (above) (schema validation). All of the ISO options are available (see ISO document or schema)

DrctDbtTxInf +Dbtr ++CtryOfRes

2!a O NA • If present the country must be valid according to ISO 3166: error code XT73.

DrctDbtTxInf +DbtrAcct ++Id +++IBAN

2!a2!n30x M AT-07 • Must pass validation using ISO 13616: error code XD19; and • First two characters must be a valid SEPA country code • First two characters must be valid according to ISO 3166: error code XT73.

DrctDbtTxInf +DbtrAgt ++FinInstnId +++BIC

4!a2!a2!c[3!c] M AT-13 • Must be an active DP or IP: error code PY01; and • The Debtor Agent must be allowed to receive DD as per service configuration: error

code XT79

DrctDbtTxInf +UltmtDbtr ++Nm

70x O AT-15 • The Ultimate Debtor Name

STEP2 – M-PEDD

27th November 2009



DrctDbtTxInf +UltmtDbtr ++PstlAdr +++AdrLine

70x O NA • Address line can have a maximum of two occurrences. (schema validation)

DrctDbtTxInf +UltmtDbtr ++PstlAdr +++Ctry

2!a C NA • Country of the Ultimate Debtor

DrctDbtTxInf +UltmtDbtr ++Id +++OrgId

See Schemas C AT-37 The identification of the Ultimate Debtor: Organisation Id. Cannot be used at the same time as Id/PrvtId (below) (schema validation) All of the ISO options are available (see ISO document or schema).

DrctDbtTxInf +UltmtDbtr ++Id +++PrvtId

See Schemas C AT-37 The identification of the Ultimate Debtor: Private Id. Cannot be used at the same time as Id/OrgId (above) (schema validation) All of the ISO options are available (see ISO document or schema).

DrctDbtTxInf +UltmtDbtr ++CtryOfRes

2!a O NA The Country of Residence of the Ultimate Debtor.

DrctDbtTxInf +Purp ++Cd

35x O AT-58 The Purpose of the transaction Cannot be used at the same time as Proprietary (below) (schema validation) Codes are based on external list definition. This is not checked by STEP2.

DrctDbtTxInf +Purp ++Prtry

35x O AT-58 The Purpose of the transaction (Proprietary) Cannot be used at the same time as Code (above) (schema validation) NOTE: STEP2 CS will not validate and/or reject this white field

DrctDbtTxInf +RgltryRptg ++DbtCdtRptgInd

4!a O NA • Part of the Regulatory Reporting

DrctDbtTxInf +RgltryRptg ++Authrty +++AuthrtyNm

70x O NA

• Part of the Regulatory Reporting

DrctDbtTxInf +RgltryRptg ++Authrty +++AuthrtyCtry

2!a O NA

• Must be a valid country code according to ISO3166. Error code : XT73

STEP2 – M-PEDD

27th November 2009



DrctDbtTxInf +RgltryRptg ++RgltryDtls +++Cd

3x O NA


DrctDbtTxInf +RgltryRptg ++RgltryDtls +++Amt

3!a18d O NA


DrctDbtTxInf +RgltryRptg ++RgltryDtls +++Inf

35x O NA


DrctDbtTxInf +RltdRmtInf

See schema O NA • The related remittance information • See XML Schema for exact description of fields available.

DrctDbtTxInf +RmtInf ++Ustrd Or ++Strd

140x O AT-22 Structured or Unstructured Remittance Information. Only Structured or Unstructured can be used (Schema validation) Structured remittance information Maximum of 10 occurrences of this field. (schema validation). First occurrence is Yellow and optional. Subsequent occurrences are white and reserved for future use. Error code: XT13. Unstructured remittance information Maximum of 10 occurrences of this field. (schema validation). First occurrence is Yellow and optional. Subsequent occurrences are white and reserved for future use. Error code: XT13. 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 +RmtInf ++Strd +++ RfrdDocInf

See schema O NA Referred Document Information NOTE: STEP2 CS will not validate and/or reject this white field

DrctDbtTxInf +RmtInf ++Strd +++ RfrdDocRltdDt

See schema O NA Referred Document Date NOTE: STEP2 CS will not validate and/or reject this white field

STEP2 – M-PEDD

27th November 2009



DrctDbtTxInf +RmtInf ++Strd +++RfrdDocAmt

See schema O NA Referred Document Amount NOTE: STEP2 CS will not validate and/or reject this white field

DrctDbtTxInf +RmtInf ++Strd +++ CdtrRefInf

See schema O NA Creditor Related Information

DrctDbtTxInf +RmtInf ++Strd +++Invcr

See schema O NA Invoicer NOTE: STEP2 CS will not validate and/or reject this white field

DrctDbtTxInf +RmtInf ++Strd +++Invcee

See schema O NA Invoicee NOTE: STEP2 CS will not validate and/or reject this white field

DrctDbtTxInf +RmtInf ++Strd +++AddtlRmtInf

See schema O NA Referred Document Amount NOTE: STEP2 CS will not validate and/or reject this white field

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 Requ est)

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 +MsgId

35x M IDF:The DP’s bulk reference • 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 +CreDtTm

ISODate &Time

M The date & time in which this bulk was created by the DP.

GrpHdr +NbOfTxs

15n M The number of transactions included in this bulk. • 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 +CtrlSum

18d M • Values are supported with up to 15 digits in the integer part and up to 2 fraction digits (schema validation)

• Must equal the sum of individual transactions inside the bulk: error code B07. GrpHdr +GrpCxl

See Step2 usage rule

column

M The Identifier of Group Cancellation. Must be set to false (Schema validation)


4!a2!a2!c C The DP originating this bulk. • Must equal SndgInst element in IDF and must not contain a branch code: error code B10.

Only used in IDF: error code B10


4!a2!a2!c C The DP receiving the bulk.

Used only in DNF: error code B11

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



XML Element Format Status STEP2 Usage Rules

OrgnlGrpInf +OrgnlMsgId

35x M The MessageId of the original bulk. In the case of DNF, the MessageID is the one generated by the CS for the Original DD bulk in the original DNF.

OrgnlGrpInf +OrgnlMsgNmId

35x M The type of XML message bulk to be cancelled. • Must always equal to pacs.003* (use of wildcard in validation): (schema validation)

Table 4-14 STEP2 usage of PACS.006 (Payment Cancell ation Request) in IDF and DNF – Original Group Info rmation

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 +CxlId

35x M The Cancellation Id: • Uniqueness is checked under the rules for duplicate: error code AM05. • This identification cannot include leading, trailing or internal spaces.

(schema validation) TxInf +OrgnlInstrId

35x O The Original instruction Id if available.

TxInf +OrgnlEndToEndId

35x M The Original End to End Id

TxInf +OrgnlTxId

35x M The Original Transaction Id. • 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



XML Acronym Format Status Validation Rules TxInf +OrgnlIntrBkSttlmAmt Attribute

18d 3!a

M C

The original Interbank Settlement Amount.

• 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 +InstgAgt ++FinInstnId +++BIC

4!a2!a2!c

C

The DP responsible for this Request for Cancellation Used only in DNF: error code XT13

TxInf +CxlRsnInf ++CxlOrgtr +++Nm

70x C The party originating the request for cancellation (customer). If the single transaction is cancelled, then this parent (CxlRsnInf) must be used: error code XT13 Cannot be used at the same time as Originator/BIC (see below) (schema validation)

TxInf +CxlRsnInf ++CxlOrgtr +++Id ++++OrgId +++++BIC

4!a2!a2!c[3!c] C The party originating the request for cancellation (bank). If the single transaction is cancelled, then this parent (CxlRsnInf) must be used: error code XT13 Cannot be used at the same time as Originator/Name (see above) (schema validation)

TxInf +CxlRsnInf ++CxlRsn +++Cd

4!a C The Request for Cancellation Reason Code. (ISO20022 code) • Must be used with a valid code: (schema validation)

Cannot be used at the same time as Prtry (see below) (schema validation)

TxInf +CxlRsnInf ++CxlRsn +++Prtry

35x C The Request for Cancellation Reason Code. (STEP2 code) • Format validation, four alphanumerical characters as described in the

transaction error code appendix, error code XT33. Cannot be used at the same time as Code (see above) (schema validation)

STEP2 – M-PEDD

27th November 2009



XML Acronym Format Status Validation Rules TxInf +OrgnlTxRef ++IntrBkSttlmDt

ISO DATE M • The original Interbank Settlement Date. • Must be the same date as the date of the original transaction in the CS

repository. Error code : XT74 TxInf +OrgnlTxRef ++ReqdColltnDt

ISO DATE M The original Requested Collection Date.

TxInf +OrgnlTxRef ++CdtrSchmeId +++Id ++++PrvtId +++++OthrId ++++++Id

35x M The Creditor Scheme Identification

TxInf +OrgnlTxRef ++CdtrSchmeId +++Id ++++PrvtId +++++OthrId ++++++IdTp

35x M The Creditor Scheme Identification type.

TxInf +OrgnlTxRef ++PmtTpInf +++SvcLvl ++++Cd

4!a M

The Service Level Code. • Must be “SEPA”: (schema validation)

TxInf +OrgnlTxRef ++PmtTpInf +++LclInstrm ++++Cd

35x M The indication of the scheme or service: Values allowed are found in the Product Table, CORE or B2B, depending on the relevant service: error code XT33

TxInf +OrgnlTxRef ++PmtTpInf +++SeqTp

4!a M

The Sequence Type of the Direct Debit.

TxInf +OrgnlTxRef ++PmtTpInf +++CtgyPurp

4!a O

The category purpose.

STEP2 – M-PEDD

27th November 2009



XML Acronym Format Status Validation Rules TxInf +OrgnlTxRef ++MndtRltdInf

See Section C.1.2

M The Mandate Related Information. All fields present in the original debit message are supported.

TxInf +OrgnlTxRef ++RmtInf +++Ustrd Or +++Strd

140x C Structured or Unstructured Remittance Information. Only Structured or Unstructured can be used (Schema validation) Structured remittance information Maximum of 10 occurrences of this field. (schema validation). First occurrence is Yellow and optional. Subsequent occurrences are white and reserved for future use. Error code: XT13. Unstructured remittance information Maximum of 10 occurrences of this field. (schema validation). First occurrence is Yellow and optional. Subsequent occurrences are white and reserved for future use. Error code: XT13. 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 +OrgnlTxRef ++UltmtDbtr +++Nm

70x O

The Ultimate Debtor Name.

TxInf +OrgnlTxRef ++UltmtDbtr +++PstlAdr ++++AdrLine

70x O Address line can have a maximum of two occurrences. (schema validation)

TxInf +OrgnlTxRef ++UltmtDbtr +++PstlAdr ++++Ctry

2!a C Country of the Ultimate Debtor

TxInf +OrgnlTxRef ++UltmtDbtr +++Id ++++OrgId

See Schemas C The identification of the Ultimate Debtor: Organisation Id. Cannot be used at the same time as Id/PrvtId (below) (schema validation) All of the ISO options are available (see ISO document or schema).

STEP2 – M-PEDD

27th November 2009



XML Acronym Format Status Validation Rules TxInf +OrgnlTxRef ++UltmtDbtr +++Id ++++PrvtId

See Schemas C The identification of the Ultimate Debtor: Private Id. Cannot be used at the same time as Id/OrgId (above) (schema validation) All of the ISO options are available (see ISO document or schema).

TxInf +OrgnlTxRef ++UltmtDbtr +++CtryOfRes

2!a O The Country of Residence of the Ultimate Debtor.

TxInf +OrgnlTxRef ++Dbtr +++Nm

70x

M

The Debtor Name.

TxInf +OrgnlTxRef ++Dbtr +++PstlAdr ++++AdrLine

70x O

The Debtor Postal Address Lines. Up to two occurrences are supported.

TxInf +OrgnlTxRef ++Dbtr +++PstlAdr ++++Ctry

2!a O

The Debtor Country.

TxInf +OrgnlTxRef ++Dbtr +++Id ++++OrgId

See Schemas C The identification of the Debtor: Organisation Id Cannot be used at the same time as Id/PrvtId (below) (schema validation) All of the ISO options are available (see ISO document or XML Schemas)

TxInf +OrgnlTxRef ++Dbtr +++Id ++++PrvtId

See Schemas C The identification of the Debtor: Private Id Cannot be used at the same time as Id/OrgId (above) (schema validation) All of the ISO options are available (see ISO document or XML Schemas)

TxInf +OrgnlTxRef ++Dbtr +++CtryOfRes

2!a O

The Debtor Country of Residence

STEP2 – M-PEDD

27th November 2009



XML Acronym Format Status Validation Rules TxInf +OrgnlTxRef ++DbtrAcct +++Id ++++IBAN

2!a2!n30x M

The Debtor Account

TxInf +OrgnlTxRef ++DbtrAgt +++FinInstnId ++++BIC

4!a2!a2!c[3!c] M

The Debtor Agent

TxInf +OrgnlTxRef ++CdtrAgt +++FinInstnId ++++BIC

4!a2!a2!c[3!c] M

The Creditor Agent Must be present in the CS repository: Error Code XT74

TxInf +OrgnlTxRef ++Cdtr +++Nm

70x M

The Creditor Name

TxInf +OrgnlTxRef ++Cdtr +++PstlAdr ++++AdrLine

70x O

The Creditor Postal Address Lines. Up to two occurrences are supported.

TxInf +OrgnlTxRef ++Cdtr +++PstlAdr ++++Ctry

2!a O

The Creditor Country.

TxInf +OrgnlTxRef ++Cdtr +++CtryOfRes

2!a O

The Credtior Country of Residence

TxInf +OrgnlTxRef ++CdtrAcct +++Id ++++IBAN

2!a2!n30x M

The Creditor Account

STEP2 – M-PEDD

27th November 2009



XML Acronym Format Status Validation Rules TxInf +OrgnlTxRef ++UltmtCdtr +++Nm

70x O

The Ultimate Creditor Name.

TxInf +OrgnlTxRef ++UltmtCdtr +++PstlAdr ++++AdrLine

70x O

Address line can have a maximum of two occurrences. (schema validation)

TxInf +OrgnlTxRef ++UltmtCdtr +++PstlAdr ++++Ctry

2!a C

Country of the Ultimate Creditor

TxInf +OrgnlTxRef ++UltmtCdtr +++Id ++++OrgId

See Schemas C The identification of the Ultimate Creditor: Organisation Id. Cannot be used at the same time as Id/PrvtId (below) (schema validation) All of the ISO options are available (see ISO document or schema).

TxInf +OrgnlTxRef ++UltmtCdtr +++Id ++++PrvtId

See Schemas C The identification of the Ultimate Creditor: Private Id. Cannot be used at the same time as Id/OrgId (above) (schema validation) All of the ISO options are available (see ISO document or schema).

TxInf +OrgnlTxRef ++UltmtCdtr +++CtryOfRes

2!a O

The Country of Residence of the Ultimate Creditor.

Table 4-15 STEP2 usage of PACS.006 (Payment Cancell ation Request) in IDF and DNF –Individual Debit Can cellation 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

XML Element Format Status STEP2 Usage Rules

GrpHdr +MsgId

35x M The STEP2 CS bulk reference.

GrpHdr +CreDtTm

ISODate &Time

M The date & Time in which this bulk was created by the STEP2 CS.


4!a2!a2!c[3!c]

C The Instructing Agent BIC for this bulk • Not used in DVF • Present in CDF • Present in RSF sent to original Instructing Agent for this bulk


4!a2!a2!c[3!c]

C The Instructed Agent BIC for this bulk • Not used in DVF • Not used in CDF • 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

XML Element Format Status STEP2 Usage Rules OrgnlGrpInfAndSts +OrgnlMsgId

35x M The MessageId of the original bulk

OrgnlGrpInfAndSts +OrgnlMsgNmId

35x M The type of XML message to be rejected. 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

OrgnlGrpInfAndSts +OrgnlNbOfTxs

15n M DVF: The total number of transactions received within the original bulk1 RSF/CDF: The total number of transactions sent for settlement.

OrgnlGrpInfAndSts +OrgnlCtrlSum

18d M For DVF: The amount of the original bulk in euro2 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 +GrpSts

4!a M The status of this bulk; values allowed are: 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 +StsRsnInf ++StsOrgtr +++Id ++++OrgId +++++BIC

4!a2!a2!c M The STEP2 CS BIC.

OrgnlGrpInfAndSts +StsRsnInf ++StsRsn +++Cd

4!a C The indication of the error code of the bulk. Code is defined as per ISO20022. Cannot be used with StsRsn Prtry (see below) If GroupStatus is Rejected: contains bulk rejection reason code ED05 for RSF only.

OrgnlGrpInfAndSts +StsRsnInf ++StsRsn +++Prtry

35x C The indication of the error code of the bulk. Code is STEP2 Specific (proprietary) Cannot be used with StsRsn Code (see above)

• 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



XML Element Format Status STEP2 Usage Rules OrgnlGrpInfAndSts +NbOfTxsPerSts ++DtldNbOfTxs

15n C The number of transactions per this status (Accepted) in the bulk. Present if Group Status is PART.

OrgnlGrpInfAndSts +NbOfTxsPerSts ++DtldSts

4!a C The status of the transactions (Accepted) Present if Group Status is PART.

OrgnlGrpInfAndSts +NbOfTxsPerSts ++DtldCtrlSum

18d C The Value of the transactions per this status (Accepted) in the bulk. Present if Group Status is PART.

OrgnlGrpInfAndSts +NbOfTxsPerSts ++DtldNbOfTxs

15n C The number of transactions per this status (Rejected) in the bulk. Present if Group Status is PART.

OrgnlGrpInfAndSts +NbOfTxsPerSts ++DtldSts

4!a C The status of the transactions (Rejected) Present if Group Status is PART.

OrgnlGrpInfAndSts +NbOfTxsPerSts ++DtldCtrlSum

18d C The Value of the transactions per this status (Rejected) in the bulk. Present if Group Status is PART.

Table 4-17 STEP2 Usage of pacs.002S2 (Payment Statu s) 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 +StsId

35x M The Status Report message Identification (generated by the Central System).

TxInfAndSts +OrgnlInstrId

35x O The Instruction ID of the original DD; populated only if it was present in the original DD. Not used in CDF.

TxInfAndSts +OrgnlEndToEndId

35x M The End to End Id of the original DD

TxInfAndSts +OrgnlTxId

35x M The Id of the original transaction (Id is specific to the original message type) Rule for CDF

• In case of a Return/Refund, the ReturnID is used In case of a Reversal, the ReversalID is used.

TxInfAndSts +TxSts

4!a M The status of this transaction; only value allowed is: “RJCT”= rejected

TxInfAndSts +StsRsnInf ++StsOrgtr +++Id ++++OrgId +++++BIC

4!a2!a2!c[3!c] M The STEP2 CS system BIC.

TxInfAndSts +StsRsnInf ++StsRsn +++Cd

4!a C The indication of the error code for the transaction (ISO20022 codes) RSF/CDF: ED05 for cancellation in TARGET2 Cannot be used at the same time as Proprietary (see below).

STEP2 – M-PEDD

27th November 2009



XML Acronym Format Status STEP2 Usage Rules TxInfAndSts +StsRsnInf ++StsRsn +++Prtry

35x C The indication of the error code for the transaction (STEP2 specific) If the error code is XT13 or XT33, this Prtry will be formatted as such: [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 +InstgAgt ++FinInstnId +++BIC

4!a2!a2!c[3!c] C The Instructing Agent BIC for this message. • Not used in DVF or CDF • Present in RSF sent to Original Instructed Agent

TxInfAndSts +InstdAgt ++FinInstnId +++BIC

4!a2!a2!c[3!c] C The Instructed Agent BIC for this message. • Not used in DVF • Present in CDF • Present in RSF sent to Original Instructing Agent

TxInfAndSts +OrgnlTxRef ++IntrBkSttlmAmt Attribute

18d 3!a

M

C

The Amount of the original transaction. Depending on the type of the original message, this can either be referred to 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 +OrgnlTxRef ++IntrBkSttlmDt

ISODate M The Original Interbank Settlement Date For transactions without an Interbank Settlement Date (ie. Pre-settlement R-message), this field is populated with the business date on which the original transaction was processed.

STEP2 – M-PEDD

27th November 2009



XML Acronym Format Status STEP2 Usage Rules TxInfAndSts +OrgnlTxRef ++CdtrAgt +++FinInstnId ++++BIC

4!a2!a2!c[3!c] M The Original Creditor Agent

Table 4-18 STEP2 Usage of pacs.002S2 (Payment Statu s) in DVF/RSF/CDF - Individual Reject Instruction

STEP2 – M-PEDD

27th November 2009



C.4 STEP2 Usage of pacs.002 (Payment Status) in IDF AN D 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 +MsgId

35x M IDF:The DP’s bulk reference • 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 +CreDtTm

ISODate &Time



4!a2!a2!c

C

The DP originating this bulk. • Must equal SndgInst element in IDF and must not contain a branch code: error code B10.

Only used in an IDF: error code B10


4!a2!a2!c

C

The DP receiving this bulk.

Only used in a DNF: error code B11

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

Ref Validation Rules

OrgnlGrpInfAndSts +OrgnlMsgId

35x M NA

The MessageId of the original bulk In the case of DNF, the MessageID is the one generated by the Bank for the Original DD bulk in the original IDF.

OrgnlGrpInfAndSts +OrgnlMsgNmId

35x M NA The type of XML message bulk to be rejected. • Must always equal to pacs.003* (use of wildcard in validation): (schema validation).

OrgnlGrpInfAndSts +GrpSts

See Validation

rules

M R1 The status of the original bulk. Values can be:

• 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. XML Acronym Format Status Rule Book

Ref Validation Rules

TxInfAndSts +StsId

35x M R5 The Payment Status Id: • Uniqueness is checked: error code AM05. • This identification cannot include leading, trailing or internal spaces.

(schema validation). TxInfAndSts +OrgnlInstrId

35x O NA The original Instruction Id.

TxInfAndSts +OrgnlEndToEndId

35x M NA The original End to End Id.

TxInfAndSts +OrgnlTxId

35x M NA The original transaction Id.

• 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 +TxSts

See validation rules

M R1 The status of this transaction. • The only value allowed is: “RJCT” = rejected: (schema validation).

TxInfAndSts +StsRsnInf ++StsOrgtr +++Nm

70x C R2 The customer originating this transaction. • Can be used only in presence of TxInfAndSts +StsRsnInf ++StsRsn

+++Cd equal to MS02. Error code XT13 if this is not met. • Indicates a customer Refusal.

Cannot be used at the same time as BIC (see below) (schema validation).

TxInfAndSts +StsRsnInf ++StsOrgtr +++Id ++++OrgId +++++BIC

4!a2!c2!a[3!c] C R2 The party originating this transaction.

• Indicates a Bank Reject. Cannot be used at the same time as Name (see above) (schema validation).

STEP2 – M-PEDD

27th November 2009




TxInfAndSts +StsRsnInf ++StsRsn +++Cd

4!a C NA The Reject/Refusal Reason Code (ISO20022) • Used only if a single transaction is rejected: error code XT33; Must be used with a valid code: (schema validation).

Cannot be used at the same time as Proprietary (below) (schema validation).

TxInfAndSts +StsRsnInf ++StsRsn +++Prtry

35x C NA The Reject/Refusal Reason Code (STEP2) • Used only if a single transaction is rejected: error code XT33; • Format validation, four alphanumerical characters as described in

the transaction error code appendix, error code XT33 Cannot be used at the same time as Code (above) (schema validation).

TxInfAndSts +InstgAgt ++FinInstnId +++BIC

4!a2!a2!c C NA The original DP sending this transaction to the CS. Only used in DNF: error code XT13

TxInfAndSts +OrgnlTxRef ++IntrBkSttlmAmt

18d 3!a

M C

NA The original Interbank Settlement Amount.

• 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 +OrgnlTxRef ++IntrBkSttlmDt

ISO DATE M NA The original Interbank Settlement Date. • Must be the same date as the date of the original transaction in the

CS repository. Error code : XT74 TxInfAndSts +OrgnlTxRef ++ReqdColltnDt

ISO DATE M NA The original Requested Collection Date.

STEP2 – M-PEDD

27th November 2009




TxInfAndSts +OrgnlTxRef ++CdtrSchmeId +++Id ++++PrvtId +++++OthrId ++++++Id

35x

M

NA The Creditor Scheme Identification.

TxInfAndSts +OrgnlTxRef ++CdtrSchmeId +++Id ++++PrvtId +++++OthrId ++++++IdTp

35x M NA The Creditor Scheme Identification type.

TxInfAndSts +OrgnlTxRef ++PmtTpInf +++SvcLvl ++++Cd

4!a M NA The Service Level Code. Must be “SEPA”: (schema validation)

TxInfAndSts +OrgnlTxRef ++PmtTpInf +++LclInstrm ++++Cd

35x M NA The indication of the scheme or service: Values allowed are found in the Product Table, CORE or B2B, depending on the relevant service: error code XT33

TxInfAndSts +OrgnlTxRef ++PmtTpInf +++SeqTp

4!a M NA The Sequence Type of the Direct Debit.

TxInfAndSts +OrgnlTxRef ++PmtTpInf +++CtgyPurp

4!a O NA


TxInfAndSts +OrgnlTxRef ++MndtRltdInf

See Section C.1.2 M NA The Mandate Related Information. All fields present in the original debit message are supported.

STEP2 – M-PEDD

27th November 2009




TxInfAndSts +OrgnlTxRef ++RmtInf +++Ustrd Or +++Strd

140x C NA Structured or Unstructured Remittance Information. Only Structured or Unstructured can be used (Schema validation) Structured remittance information Maximum of 10 occurrences of this field. (schema validation). First occurrence is Yellow and optional. Subsequent occurrences are white and reserved for future use. Error code: XT13. Unstructured remittance information Maximum of 10 occurrences of this field. (schema validation). First occurrence is Yellow and optional. Subsequent occurrences are white and reserved for future use. Error code: XT13. 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.

TxInfAndSts +OrgnlTxRef ++UltmtDbtr +++Nm

70x O NA The Ultimate Debtor Name.

TxInfAndSts +OrgnlTxRef ++UltmtDbtr +++PstlAdr ++++AdrLine


TxInfAndSts +OrgnlTxRef ++UltmtDbtr +++PstlAdr ++++Ctry

2!a C NA Country of the Ultimate Debtor

TxInfAndSts +OrgnlTxRef ++UltmtDbtr +++Id ++++OrgId

See Schemas C NA The identification of the Ultimate Debtor: Organisation Id. Cannot be used at the same time as Id/PrvtId (below) (schema validation) All of the ISO options are available (see ISO document or schema).

STEP2 – M-PEDD

27th November 2009




TxInfAndSts +OrgnlTxRef ++UltmtDbtr +++Id ++++PrvtId

See Schemas C NA The identification of the Ultimate Debtor: Private Id. Cannot be used at the same time as Id/OrgId (above) (schema validation) All of the ISO options are available (see ISO document or schema).

TxInfAndSts +OrgnlTxRef ++UltmtDbtr +++CtryOfRes


TxInfAndSts +OrgnlTxRef ++Dbtr +++Nm

70x

M NA The Debtor Name.

TxInfAndSts +OrgnlTxRef ++Dbtr +++PstlAdr ++++AdrLine

70x O NA The Debtor Postal Address Lines. Up to two occurrences are supported.

TxInfAndSts +OrgnlTxRef ++Dbtr +++PstlAdr ++++Ctry

2!a O NA The Debtor Country.

TxInfAndSts +OrgnlTxRef ++Dbtr +++Id ++++OrgId

See Schemas O

NA

The identification of the Debtor: Organisation Id Cannot be used at the same time as Id/PrvtId (below) (schema validation) All of the ISO options are available (see ISO document or XML Schemas)

TxInfAndSts +OrgnlTxRef ++Dbtr +++Id ++++PrvtId

See Schemas O

NA

The identification of the Debtor: Private Id Cannot be used at the same time as Id/OrgId (above) (schema validation) All of the ISO options are available (see ISO document or XML Schemas)

TxInfAndSts +OrgnlTxRef ++Dbtr +++CtryOfRes

2!a O NA The Debtor Country of Residence

STEP2 – M-PEDD

27th November 2009




TxInfAndSts +OrgnlTxRef ++DbtrAcct +++Id ++++IBAN

2!a2!n30x M NA The Debtor Account

TxInfAndSts +OrgnlTxRef ++DbtrAgt +++FinInstnId ++++BIC

4!a2!a2!c[3!c] M NA The Debtor Agent

TxInfAndSts +OrgnlTxRef ++CdtrAgt +++FinInstnId ++++BIC

4!a2!a2!c[3!c] M NA The Creditor Agent Must be present in the CS repository: Error Code XT74

TxInfAndSts +OrgnlTxRef ++Cdtr +++Nm

70x M NA The Creditor Name

TxInfAndSts +OrgnlTxRef ++Cdtr +++PstlAdr +++AdrLine

70x O NA The Creditor Postal Address Lines. Up to two occurrences are supported.

TxInfAndSts +OrgnlTxRef ++Cdtr +++PstlAdr +++Ctry

2!a O NA The Creditor Country.

TxInfAndSts +OrgnlTxRef ++Cdtr +++CtryOfRes

2!a O NA The Credtior Country of Residence

STEP2 – M-PEDD

27th November 2009




TxInfAndSts +OrgnlTxRef ++CdtrAcct +++Id ++++IBAN

2!a2!n30x M NA The Creditor Account

TxInfAndSts +OrgnlTxRef ++UltmtCdtr +++Nm

70x O NA The Ultimate Creditor Name.

TxInfAndSts +OrgnlTxRef ++UltmtCdtr +++PstlAdr ++++AdrLine


TxInfAndSts +OrgnlTxRef ++UltmtCdtr +++PstlAdr ++++Ctry

2!a C NA Country of the Ultimate Creditor

TxInfAndSts +OrgnlTxRef ++UltmtCdtr +++Id ++++OrgId

See Schemas C NA The identification of the Ultimate Creditor: Organisation Id. Cannot be used at the same time as Id/PrvtId (below) (schema validation) All of the ISO options are available (see ISO document or schema).

TxInfAndSts +OrgnlTxRef ++UltmtCdtr +++Id ++++PrvtId

See Schemas C NA The identification of the Ultimate Creditor: private Id. Cannot be used at the same time as Id/OrgId (above) (schema validation) All of the ISO options are available (see ISO document or schema).

TxInfAndSts +OrgnlTxRef ++UltmtCdtr +++CtryOfRes

2!a O NA The Country of Residence of the Ultimate Creditor.

Table 4-21 STEP2 Usage of pacs.002.001.02 (Payment Status) in IDF and DNF - Individual Reject Instruct ion

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

XML Element Format Status Validation Rules GrpHdr +MsgId

35x M The bulk reference of the generating party. • Uniqueness is checked: error code B14. • For SDF, MsgId is generated by STEP2.

The identification cannot include leading, trailing or internal spaces (schema validation) GrpHdr +CreDtTm

ISO Date & Time


GrpHdr +NbOfTxs

15n M The number of transactions included in this bulk. • 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 +TtlRtrdIntrBkSttlmAmt Attribute

18d 3!a

M M

The Value of the transactions included in this bulk. • Values are supported with up to 15 digits in the integer part and up to 2 fraction digits: (schema validation). • 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).


ISODate M The business date in which the transactions inside this bulk must be settled in the relevant settlement mechanism. • 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 +SttlmInf ++SttlmMtd

4!a M Information on settlement method. Only the value “CLRG” is supported: Schema validation

STEP2 – M-PEDD

27th November 2009



XML Element Format Status Validation Rules GrpHdr +SttlmInf ++ClrSys +++Prtry

3!a M The Identifier of the the Clearing System. Proprietary identification of the Clearing System. Value is ‘ST2’. Error code B16.


4!a2!a2!c

C

The DP originating this bulk. • Must equal SndgInst element in IDF and must not contain a branch code: error code B10.

Used only in IDF. error code B10


4!a2!a2!c C The DP receiving this bulk. Used only in SDF. error code B11

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 Book Ref

STEP2 Usage Rules and Validation

TxInf +RtrId

35x M R5 The Return Id: • Uniqueness is checked: error code AM05. • This identification cannot include leading, trailing or internal spaces. (schema validation).

TxInf +OrgnlGrpInf ++OrgnlMsgId

35x M NA The MessageID of the bulk containing the original DD. In the case of IDF where (the pacs.004) is sent by the bank to STEP2, the MessageId is normally the 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 +OrgnlGrpInf ++OrgnlMsgNmId

35x M NA The type of XML message bulk to be returned/refunded. Must always equal to pacs.003* (use of wildcard in validation)(schema validation)

STEP2 – M-PEDD

27th November 2009





TxInf +OrgnlInstrId

35x O NA The original InstructionId


35x M NA The original End to End Id

TxInf +OrgnlTxId

35x M NA The original Transaction Id.

• 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 +OrgnlIntrBkSttlmA

mt Attribute

18d

3!a

M M

AT-06 The original Interbank Settlement Amount.

• 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 +RtrdIntrBkSttlmAmt Attribute

18d 3!a

M M

NA The amount of this transaction (return). • 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). • 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 +CompstnAmt

18d 3!a

O C

R6 The Returned/Refunded Compensation amount of the refunded transaction; • 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). • 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





TxInf +ChrgBr

4!a O NA The Charge Bearer Information. If used, Value must be SLEV. (schema validation)

TxInf +ChrgsInf ++ChrgsAmt Attribute

18d 3!a

O C

NA

• Only one occurrence is allowed: error code (schema validation)

TxInf +ChrgsInf ++ChrgsPty +++FinInstnId ++++BIC

4!a2!a2!c[

3!c]

O NA • Only one occurrence is allowed: error code (schema validation)


4!a2!a2!c C NA The DP originating this Return. Used only in SDF. error code XT13

TxInf +RtrRsnInf ++RtrnOrgtr +++Nm

70x C R2 The customer originating this transaction. Cannot be used at the same time as Originator BIC (below) (schema validation). Cannot be used for the B2B service; error code XT13

TxInf +RtrRsnInf ++RtrOrgtr +++Id ++++OrgId +++++BIC

4!a2!a2!c[3!c]

C R2 The party originating this transaction. Cannot be used at the same time as Originator Name (above) (schema validation).

TxInf +RtrRsnInf ++RtrRsn +++Cd

4!a C NA The Return/Refund Reason Code (ISO20022) Must be used with a valid code: (schema validation). Cannot be used at the same time as Proprietary (below) (schema validation).

TxInf +RtrRsnInf ++RtrRsn +++Prtry

35x C NA The Return/Refund Reason Code (STEP2) Format validation, four alphanumerical characters as described in the transaction error code appendix,, error code XT33. Cannot be used at the same time as Code (above) (schema validation).

TxInf +OrgnlTxRef ++IntrBkSttlmDt

ISO DATE

M NA The Original Interbank Settlement Date.

STEP2 – M-PEDD

27th November 2009





TxInf +OrgnlTxRef ++ReqdColltnDt

ISO DATE

M NA The Original Requested Collection date.


35x

M

NA The Creditor Scheme Identification.




4!a M NA

The Service Level Code.




4!a M NA



4!a O NA


STEP2 – M-PEDD

27th November 2009





TxInf +OrgnlTxRef ++MndtRltdInf

See Section C.1.2

M NA The Mandate Related Information. All fields present in the original debit message are supported.

TxInf +OrgnlTxRef ++RmtInf ++Ustrd Or +++ Strd









See Schemas

C NA The identification of the Ultimate Debtor: Organisation Id. Cannot be used at the same time as Id/PrvtId (below) (schema validation) All of the ISO options are available (see ISO document or schema).

STEP2 – M-PEDD

27th November 2009





TxInf +OrgnlTxRef ++UltmtDbtr +++Id ++++PrvtId

See Schemas

C NA The identification of the Ultimate Debtor: Private Id. Cannot be used at the same time as Id/OrgId (above) (schema validation) All of the ISO options are available (see ISO document or schema).




70x

M NA

The Debtor Name.




2!a O NA

The Debtor Country.


See Schemas

O

NA



See Schemas

O

NA



2!a O NA


STEP2 – M-PEDD

27th November 2009





TxInf +OrgnlTxRef ++DbtrAcct +++Id ++++IBAN

2!a2!n30x M NA

The Debtor Account


4!a2!a2!c[3!c]

M NA

The Debtor Agent


4!a2!a2!c[3!c]

M NA The Creditor Agent Must be present in the CS repository: Error code PY01


70x M NA

The Creditor Name




2!a O NA



2!a O NA

The Credtior Country of Residence

STEP2 – M-PEDD

27th November 2009






2!a2!n30x M NA


TxInf +OrgnlTxRef ++UltmtCdtr +++Nm

70x O NA



70x O NA



2!a C NA



See Schemas

C NA The identification of the Ultimate Creditor: Organisation Id. Cannot be used at the same time as Id/PrvtId (below) (schema validation) All of the ISO options are available (see ISO document or schema).


See Schemas

C NA The identification of the Ultimate Creditor: Private Id. Cannot be used at the same time as Id/OrgId (above) (schema validation) All of the ISO options are available (see ISO document or schema).


2!a O NA


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 +MsgId

35x M The bulk reference. of the generating party. • Uniqueness is checked: error code B14. • For SDF, MsgId is generated by STEP2.

The identification cannot include leading, trailing or internal spaces (schema validation)

GrpHdr +CreDtTm

ISODate& Time

M The date & time in which this bulk was created by the DP

GrpHdr +NbOfTxs

15n M The number of transactions included in this bulk. • 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 +GrpRvsl

See validation

rules

M The status of this bulk. Only FALSE is allowed (Schema Validation)

GrpHdr +TtlRvsdIntrBkSttlmAmt Attribute

18d

3!a

M M

The Value of the transactions included in this bulk. • Values are supported with up to 15 digits in the integer part and up to 2 fraction digits: (schema validation)

• Currency attribute must be always “EUR”: (schema validation); and • 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).


ISODate M The business date in which the transactions inside this bulk must be settled in the relevant settlement mechanism. • 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 +SttlmInf ++SttlmMtd

4!a M Information on settlement method.

Only the value “CLRG” is supported: (schema validation)

GrpHdr +SttlmInf ++ClrSys +++Prtry

3!a M The Identifier of the the Clearing System. Proprietary identification of the Clearing System. Value is ‘ST2’. Error code B16.

STEP2 – M-PEDD

27th November 2009





4!a2!a2!c C The DP originating this bulk. • Format Validation; and • Must equal SndgInst element in IDF and must not contain a branch code: error code B10.

Used only in IDF. error code B10


4!a2!a2!c C The DP receiving this bulk. Used only in SDF. error code B11

Table 4-24 STEP2 Usage of pacs.007 (Reversal) in ID F 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 +OrgnlMsgId

35x M NA The MessageID of the bulk containing the original DD. 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 +OrgnlMsgNmId

35x M NA The type of XML message bulk to be rejected. • Must always equal to pacs.003* (use of wildcard in validation): (schema validation)

Table 4-25 STEP2 Usage of pacs.007 (Reversal) in ID F 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

Book Ref Validation Rules

TxInf +RvslId

35x M NA The Reversal Id: • Uniqueness is checked: error code AM05. • This identification cannot include leading, trailing or internal spaces. (schema validation)

TxInf +OrgnlInstrId

35x O NA The original Instruction Id.


35x M NA The original End To End Id.

TxInf +OrgnlTxId

35x M NA The original transaction Id. • 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 +OrgnlIntrBkSttlmAmt Attribute

18d 3!a

M C

NA The original Interbank Settlement Amount.

• 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 +RvsdIntrBkSttlmAmt Attribute

18d 3!a

M M

NA The amount of this transaction. • 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 +RvsdInstdAmt Attribute

18d

3!a

O NA The Reversed Instructed Amount. • 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 +XchgRate

11d O NA The Exchange Rate of the Reversal

TxInf +ChrgBr

4!a O NA • The Charge Bearer Information, • If used, Value must be SLEV. (schema validation)

STEP2 – M-PEDD

27th November 2009




Validation Rules

TxInf +ChrgsInf ++ChrgsAmt Attribute

18d 3!a

O C

NA • Only one occurrence is allowed: (schema validation)

TxInf +ChrgsInf ++ChrgsPty +++FinInstnId ++++BIC

4!a2!a2!c[3!c] O NA • Only one occurrence is allowed: (schema validation)


4!a2!a2!c C NA The DP originating this Reversal Used only in SDF. error code XT13

TxInf +RvslRsnInf ++RvslOrgtr +++Nm

70x C R2 The customer originating this Reversal. Cannot be used at the same time as BIC (see below) (schema validation)

TxInf +RvslRsnInf ++RvslOrgtr +++Id ++++OrgId +++++BIC

4!a2!a2!c[3!c] C R2 The Bank originating this Reversal. Cannot be used at the same time as Name (see above) (schema validation)

TxInf +RvslRsnInf ++RvslRsn +++Cd

4!a C NA The Reason Code of the Reversal (ISO20022) • Must be used a valid code (schema validation)

Cannot be used at the same time as Proprietary (see below) (schema validation)

TxInf +RvslRsnInf ++RvslRsn +++Prtry

35x C NA The Reason Code of the Reversal (STEP2):

• Format validation, four alphanumerical characters as described in the transaction error code appendix, error code XT33.

Cannot be used at the same time as Code (see above) (schema validation) TxInf +OrgnlTxRef ++IntrBkSttlmDt

ISO DATE M NA The Original Interbank Settlement Date.

STEP2 – M-PEDD

27th November 2009




Validation Rules

TxInf +OrgnlTxRef ++ReqdColltnDt

ISO DATE M NA The Original Requested Collection date.


35x M NA The Creditor Scheme Identification.




4!a M NA

The Service Level Code. Must = “SEPA”




4!a M NA



4!a O NA


STEP2 – M-PEDD

27th November 2009




Validation Rules

TxInf +OrgnlTxRef ++MndtRltdInf

See Section C.1.2

M NA The Mandate Related Information. All fields present in the original debit message are supported.

TxInf +OrgnlTxRef ++RmtInf +++Ustrd Or +++Strd










STEP2 – M-PEDD

27th November 2009




Validation Rules

TxInf +OrgnlTxRef ++UltmtDbtr +++Id ++++PrvtId





70x

M NA

The Debtor Name.




2!a O NA

The Debtor Country.


See Schemas O

NA



See Schemas O

NA



2!a O NA


STEP2 – M-PEDD

27th November 2009




Validation Rules

TxInf +OrgnlTxRef ++DbtrAcct +++Id ++++IBAN

2!a2!n30x

M NA

The Debtor Account


4!a2!a2!c[3!c]

M NA

The Debtor Agent


4!a2!a2!c[3!c]

M NA The Creditor Agent Must be present in the CS repository: Error Code PY01


70x M NA

The Creditor Name




2!a O NA



2!a O NA

The Creditor Country of Residence

STEP2 – M-PEDD

27th November 2009




Validation Rules


2!a2!n30x M NA


TxInf +OrgnlTxRef ++UltmtCdtr +++Nm

70x O NA



70x O NA



2!a C NA







2!a O NA


Table 4-26 STEP2 Usage of pacs.007 (Reversal) in ID F 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 Core or “B2B” for B2B) associated with the network address (from the Request Type 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.

The CS cannot generate a DVF because: • It is not possible to associate a destination network address to which to send the file. Resolution must involve a phone call to Customer Support and manual management.

If the number of rejected transactions is equal to 0, then the file is completely accepted.

The CS generates a DVF as follows: • The IDF is totally accepted; The reported IdfErrCd at the level of IDF is:

• A00: the IDF is totally accepted.

If the number of rejected transactions is different from 0, and there are some transaction accepted then the file is partially accepted.

The CS generates a DVF as follows: • The IDF is partially accepted ; The IdfErrCd equals: • A01: the file is partially accepted.

The file has been sent during non-Target days.

The CS generates a DVF as follows:

• 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 valid naming convention being accepted. This check is divided into several checks:

• The network file name must begin with the fixed value according to the naming convention;

• The Service Identifier contained in the network file name must be equal to the one associated with the network address;

• The DP BIC contained in the network file name must be equal to the one associated with the network address (as derived from the STEP2 Central System addressing table);

• The format version contained in the network file name is checked against the legal values; and

• The file type contained in the network file name must be "I”

The CS generates a DVF as follows: • The IDF is totally rejected; • The following DVF fields are filled using the information derived from the network header:

• SrvcId, • RcvgInst (the DP), and

• OrigFName.

• 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, andIn a DVF, GrpHdr, OrgnlGrpInfAndSts and TxInf will not be present IdfErrCd equals: • R02: the beginning of the network file name is not compliant, • R03: the service identifier is not compliant, • R04: the DP BIC is not compliant, • R06: the format version is not compliant, or

• R07: the file type is not compliant.

The parser will validate the received file against the IDF XML schema. If the file does not comply with the schema then it is rejected as garbage.

The CS generates a DVF as follows: • The IDF is totally rejected;

• 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, 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 record of accepted files held online: • ServiceId; • SngInst; • FileReference. If a match is found for these fields between the file being validated and a file held online then the file is rejected as a duplicate.

The CS generates a DVF as follows: • The IDF is totally rejected; • The payment instructions contained in the IDF have not been validated, and therefore:

• The DVF will not contain any rejected transactionIn a DVF, GrpHdr OrgnlGrpInfAndSts and TxInf will not be present

The IdfErrCd equals: • R13: the IDF is a duplicate.

The contents of the IDF header fields are checked against the configured set of legal values.

• SndgInst must equal the BIC associated with the network address;

• RcvgInst must equal the configured STEP2 central system BIC; and

• TstCode must equal the configured system value.

If any check fails then the file is rejected.


• The IDF is totally rejected; • The transactions contained in the IDF have not been validated, and therefore:

• The DVF will not contain any rejected transactions, • In a DVF, GrpHdr OrgnlGrpInfAndSts and TxInf will not be present

The possible IdfErrCd are: • R11: incorrect SndgInst. • R12: incorrect RcvgInst.

• R14: incorrect TstCode.

STEP2 – M-PEDD

27th November 2009




The format (syntax and character set) and presence of those file- and header-level elements not verified by schema validation is checked. Specifically, it is verified that:

• The format of SndgInst must be 4!a2!a2!c (e.g. must not contain a branch code);

• The format of RcvgInst must be 4!a2!a2!c (e.g. must not contain a branch code);

If any of these tests fail then the file is rejected as garbage.

The CS generates a DVF as follows: • The IDF is totally rejected;

• OrigFRef and OrigDtTm will not be present (for DVF matching, only the OrigFName 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, GrpHdr OrgnlGrpInfAndSts and TxInf will not be present

The possible IdfErrCd are: • R15: incorrect SndgInst format; • R16: incorrect RcvgInst format.

The Service Identifier present in the Network File Name is compared to the Service Identifier inside the IDF File Header.

The CS generates a DVF as follows: • The IDF is totally rejected; • The transactions contained in the IDF have not been validated, and therefore:

• The DVF will not contain any rejected transaction, and

• In a DVF, GrpHdr OrgnlGrpInfAndSts and TxInf will not be present The possible IdfErrCd are: • R17: incorrect Service Identifier

The Direct Debit bulks within the file are counted and the total is compared against NumDDBlk. If the numbers are different then the file is rejected.

The CS generates a DVF as follows: • The IDF is totally rejected; • The DVF will not contain any rejected payment instructions; 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, GrpHdr OrgnlGrpInfAndSts and TxInf will not be present

The possible IdfErrCd are: 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 file are counted and the total is compared against NumRFCBlk. If the numbers are different then the file is rejected.


• The DVF will not contain any rejected transaction, and

STEP2 – M-PEDD

27th November 2009



Processing Error report • In a DVF, GrpHdr OrgnlGrpInfAndSts and TxInf will not be present

The possible IdfErrCd are: 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 counted and the total is compared against NumRFRBlk. If the numbers are different then the file is rejected.



The possible IdfErrCd are: 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 and the total is compared against NumREJBlk. If the numbers are different then the file is rejected.



The possible IdfErrCd are: 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 counted and the total is compared against NUMRVSBlk. If the numbers are different then the file is rejected.



The possible IdfErrCd are: 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 validation, the number of processed bulk is compared with the number of rejected bulks. If they are equal, the IDF is totally rejected.


• 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



Processing Error report � 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 for this settlement cycle from this Direct Participant is compared against the maximum number of files accepted per settlement cycle. If the maximum has already been accepted then this file is rejected.


• 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 not been validated

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: After the bulk content validation completion, the number of rejected transactions is checked. If the number of rejected transaction is equal to 0 and the number of accepted transaction is greater than 0, then the bulk is totally accepted.

The CS generates a DVF as follows: • The bulk is totally accepted; • All the transactions have been validated; and • All the transactions have succeeded the validation of the Interbank Settled Amount, and

therefore: In the DVF OrgnlGrpInfAndSts will all be present and contain meaningful values.

RSF: This code is used to inform the receiver of the settlement status of the original bulk.

Reason code field is used in bulk header.

B01: the bulk is partially accepted. After the bulk content validation completion, the number of rejected transactions is checked. If the number of rejected transaction is greater than 0 and the number of accepted transaction is greater than 0, then the bulk is partially accepted.

The CS generates a DVF as follows: • The bulk is partially accepted; • The DVF contains all the rejected transactions;

• All the transactions have been validated (but not accepted); and

• All the transactions have succeeded the validation of the Interbank Settled Amount, and therefore: In a DVF OrgnlGrpInfAndSts will all be present and contain meaningful values.

RSF: This code is used to inform the receiver of the settlement status of the original bulk.

Reason code field is used in bulk header.

STEP2 – M-PEDD

27th November 2009




B02: the maximum number of transactions within one bulk is exceeded.

NbOfTxs/NbOfTxsPerSts is compared against the maximum number of transactions supported in one bulk. If there is a greater number of transactions in the bulk than what is allowed for the service, the bulk is rejected.

The CS generates a DVF as follows: • The bulk is totally rejected;

• The transactions contained in the bulk have not been validated, and therefore: • The DVF will not contain any rejected transactions,

The StsRsnInf Prtry field will contain the error code.

B03: the number of transactions within the bulk does not match the value declared in the GrpHdr/ OrgnlGrpInfAndSts.

The transactions within the bulk are counted and the total is compared against NbOfTxs/NbOfTxsPerSts. If the numbers are different then the bulk is rejected.

The CS generates a DVF as follows: • The bulk is totally rejected; • The DVF will not contain any rejected transactions; and • The transactions contained in the bulk have not been validated, but: The StsRsnInf Prtry field will contain the error code.

B04: Not used NA NA

STEP2 – M-PEDD

27th November 2009



Error /Reason Code Processing Error report B05: TtlIntrBkSttlmAmt, TtlRvsdIntrBkSttlmAmt or TtlRtrdIntrBkSttlmAmt is incorrect.

After the completion of pacs.003, pacs.004 or pacs.007 Bulk content validation, the number of processed transactions and the number of transactions with a valid "Interbank Settled 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.

The CS generates an bulk as follows: • The bulk is totally rejected;

• The DVF will not contain any rejected transaction The StsRsnInf Prtry field will contain the error code.

B06: Not used NA NA

STEP2 – M-PEDD

27th November 2009




B07: DtldCtrlSum/ CtrlSum is incorrect.

After the completion of pacs.006 Bulk content validation, the number of processed transactions and the number of transactions with a valid "TransactionReference/Interbank 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.

The CS generates an bulk as follows: • The bulk is totally rejected;

• The DVF will not contain any rejected transaction The StsRsnInf Prtry field will contain the error code.

B08: the maximum number of valid bulks has already been received in this settlement cycle.

The number of bulks already accepted for this settlement cycle from this Direct Participant is compared against the maximum number of bulks accepted per settlement cycle. If the maximum have already been accepted then this bulk is rejected.

The CS generates a DVF as follows: • The bulk is totally rejected; • The transactions contained in the bulk have not been validated, and therefore:

• The DVF will not contain any rejected transactions The StsRsnInf Prtry field will contain the error code.

B09: the bulk is totally rejected because all transactions within it have been rejected.

After the completion of bulk content validation, the number of processed transactions is compared with the number of rejected transactions. If they are equal, the bulk is totally rejected.

The CS generates a DVF as follows: • The bulk is totally rejected; • The DVF contains all rejected transactions; • All the transactions have been validated; • All the transactions have succeeded the validation of the Interbank Settled Amount, The StsRsnInf Prtry field will contain the error code.

B10: the bulk is totally rejected because InstructingAgent must be present at the group header level in an IDF.

Instructing Agent must be present at the group header level in an IDF and have the format 4!a2!a2!c (e.g. must not contain a branch code).


• The transactions contained in the bulk have not been validated, and therefore: • The DVF will not contain any rejected transactions


STEP2 – M-PEDD

27th November 2009




B11: the bulk is totally rejected because InstructedAgent must not be present at group header level in an IDF.

Instructed Agent must not be present at the group header level in a IDF.


• The DVF will not contain any rejected transactions • The StsRsnInf Prtry field will contain the error code.

B12: Not used NA NA

B13: the bulk is totally rejected because amount is zero

The Total amount must be equal or greater than 0.01.


• 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 bulk have not been validated, and therefore:


B14: the bulk is totally rejected because MsgId is duplicated.

The Message Id must be unique The CS generates a DVF as follows: • The bulk is totally rejected; • The transactions contained in the bulk have not been validated, and therefore:


B15: the bulk is totally rejected because IntrBkSttlmDt is not present or is not in the allowed range.

IntrBkSttlmDt must be present at the group level (applicable only to pacs.003, pacs.004 and pacs.007) and must be within the allowed range .



B16: the bulk is totally rejected because of incorrect usage of ClrSys

ClrSys should equal to "ST2" The CS generates a DVF as follows: • The bulk is totally rejected; • The transactions contained in the bulk have not been validated, and therefore:


B19: Not used NA NA

B20: Not used NA NA

STEP2 – M-PEDD

27th November 2009




B23: the bulk is totally rejected because too many consecutive rejected transactions

The number of consecutive rejected transactions found at the beginning of the bulk must not exceed the CS parameter "maximum number of errors in the bulk"


• The bulk is totally rejected; • The transactions contained in the bulk have not been validated, and therefore: • 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

M Service Identifier 3x “COR” for Core or “B2B” for B2B 4

M File Type 3x "PSR" 7

M Sending Institution 4!a2!a2!c EBA STEP2 CS BIC 10

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

Total Number of DDs received The number of DDs received from the DP for the processing of this interbank settlement date during the specific settlement cycle

Total Value of DDs received The value of DDs received from the DP for the processing of this interbank settlement date during the specific settlement cycle

Total Number of Reversals sent The number of Reversals sent by the DP for the processing of this interbank settlement date during the specific settlement cycle

Total Value of Reversals sent The value of Reversals sent by the DP for the processing of this interbank settlement date during the specific settlement cycle

Total Number of Refunds/Returns received

The number of Returns/Refunds received by the DP for the processing of this interbank settlement date during the specific settlement cycle

Total Value of Refunds/Returns received

The value of Returns/Refunds received by the DP for the processing of this interbank settlement date during the specific settlement cycle

Field reserved for future use Field reserved for future use


Total settlement amount debited The value of the total amount debited to the DP for the processing of this 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

M Value of Refunds/Returns received 18d 65

M Field reserved for future use 18d 83

M Total Settlement Amount Debited 18d 101

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

Settlement Cycle The STEP2 settlement cycle during which this settlement instruction was generated.

Interbank Settlement Date The Interbank Settlement Date during which this settlement instruction was generated.

Credit Party DP BIC The BIC of the Direct Participant who was the credit party of these transactions.

Credit Party Settlement BIC The BIC used by the Direct Participant identified in Credit Party Settlement 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 received

The value of the above Number Refunds/Returns 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 Field reserved for future use 15n 103 M Field reserved for future use 18d 118 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

Total Number of DDs sent The number of DDs sent from the DP for the processing of this interbank settlement date during the specific settlement cycle

Total Value of DDs sent The value of DDs sent from the DP for the processing of this interbank settlement date during the specific settlement cycle

Total Number of Reversals received

The number of Reversals received by the DP for the processing of this interbank settlement date during the specific settlement cycle

Total Value of Reversals received The value of Reversals received by the DP for the processing of this interbank settlement date during the specific settlement cycle

Total Number of Refunds/Returns sent

The number of Returns/Refunds sent by the DP for the processing of this interbank settlement date during the specific settlement cycle

Total Value of Refunds/Returns sent

The value of Returns/Refunds sent by the DP for the processing of this interbank settlement date during the specific settlement cycle



Total settlement amount credited The value of the total amount credited to the DP for the processing of this 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 Interbank Settlement Date 6!n 4 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 Value of Refunds/Returns sent 18d 65

M Field reserved for future use 18d 83 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

Interbank Settlement Date The Interbank Settlement Date during which this settlement instruction was generated

Debit Party DP BIC The BIC of the Direct Participant who was the debit party of this settlement instruction.

Debit Party Settlement BIC The BIC used by the Direct Participant identified in Debit Party Settlement 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 sent

The value of the above Number Refunds/Returns 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

Total Value of DDs sent The value of DDs sent by the DP for the processing of this interbank settlement date during the specific settlement cycle

Total Value of Returns sent The value of Returns sent by the DP for the processing of this interbank settlement date during the specific settlement cycle

Total Value of Reversal received The value of Reversal received from the DP for the processing of this 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 DDs received from the DP for the processing of this interbank settlement date during the specific settlement cycle

Total value of Return received The value of Returns received from the DP for the processing of this interbank settlement date during the specific settlement cycle

Total value of Reversal sent The value of Reversal sent by the DP for the processing of this interbank settlement date during the specific settlement cycle

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 co ntents

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

Total Value of DDs sent The value of DDs sent by the DP for the processing of this interbank settlement date during the specific settlement cycle

Total Value of Returns sent The value of Returns sent by the DP for the processing of this interbank settlement date during the specific settlement cycle

Total Value of Reversal received The value of Reversal received from the DP for the processing of this 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 DDs received from the DP for the processing of this interbank settlement date during the specific settlement cycle

Total value of Return received The value of Returns received from the DP for the processing of this interbank settlement date during the specific settlement cycle

Total value of Reversal sent The value of Reversal sent by the DP for the processing of this interbank settlement date during the specific settlement cycle

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 cont ents

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

DCTH 1-1 Credit Party settlement transactions received

DCTB 0-n DRR Credit Party settlement Transactions 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

M Service Identifier 3x “COR” for Core

or “B2B” for B2B

4

M File Type 3x "DRR" 7

M Sending Institution 4!a2!a2!c EBA STEP2 CS BIC 10

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 Interbank Settlement Date 6!n 55 M Total Number Records 6n 61

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

M Number Req for Canc Bulks Rejected 4n 32

M Number Rejects Bulks Sent 4n 36 M Number Rejects Bulks Rejected 4n 40

M Number Refunds/Returns Bulks Sent 4n 44

M Number Refunds/Returns Bulks Rejected 4n 48

M Number Reversal Bulks Sent 4n 52 M Number Reversal Bulks Rejected 4n 56 M Field reserved for future use 4n 60 M Field reserved for future use 4n 64 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

M Number Refunds/Returns Rejected 15n 173

M Number Reversals Sent 15n 188 M Number Reversals Rejected 15n 203 M Field reserved for future use 15n 218 M Field reserved for future use 15n 233 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 M Field reserved for future use 18d 428 M Field reserved for future use 18d 446

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

Number IDF Sent

The number of times an IDF was received by the STEP2 central system from this Direct Participant. 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.

Number IDF Rejected

The number of DVFs indicating complete rejection of a file that were transmitted by the STEP2 central system to this Direct Participant. 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:

Number Bulks Sent

The total number of bulks received by the STEP2 central system from this Direct Participant. 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.

Number Bulks Rejected The number of the bulks completely rejected by the STEP2 central system to this Direct Participant.

Number DDs Bulks Sent The total number of DDs bulks received by the STEP2 central system from this Direct Participant.

Number DDs Bulks Rejected The number of DDs bulks completely rejected by the STEP2 central system to this Direct Participant.

Number Req for Canc Bulks Sent

The total number of Request for Cancellation Bulks received by the STEP2 central system from this Direct Participant

Number Req for Canc Bulks Rejected

The number of the Requests for Cancellation bulks completely rejected by the STEP2 central system to this Direct Participant.

Number Rejects Bulks Sent The total number of Rejects bulks received by the STEP2 central system from this Direct Participant.

Number Rejects Bulks Rejected

The number of the Rejects bulks completely rejected by the STEP2 central system to this Direct Participant.

Number Refunds/Returns Bulks Sent

The total number of Refunds/Returns bulks received by the STEP2 central system from this Direct Participant.

Number Refunds/Returns Bulks Rejected

The number of the Refunds/Returns bulks completely rejected by the STEP2 central system to this Direct Participant.



Number Reversals Bulks Sent The total number of Reversals bulks received by the STEP2 central system from this Direct Participant.

Number Reversals Bulks Rejected

The number of the Reversals bulks completely rejected by the STEP2 central system to this Direct Participant.

Number Direct Debit Sent The number of Debit Requests received in IDFs from this Direct Participant by the STEP2 central system where the IDF was completely or partially accepted.

Number Direct Debit Rejected The number of Debit Requests that were rejected from partially accepted IDFs received from this Direct Participant.

Number Req for Canc Sent The number of Req for Canc received in IDFs from this Direct Participant by 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 Rejected

The number of Req for Canc that were rejected from partially accepted IDFs received from this Direct Participant.

Number Rejects Sent The number of Rejects received in IDFs from this Direct Participant by the STEP2 central system where the IDF was completely or partially accepted.

Number Rejects Rejected The number of Rejects that were rejected from partially accepted IDFs received from this Direct Participant.

Number Refunds/Returns Sent

The number of Refunds/Returns received in IDFs from this Direct Participant by the STEP2 central system where the IDF was completely or partially accepted.

Number Refunds/Returns Rejected

The number of Refunds/Returns that were rejected from partially accepted IDFs received from this Direct Participant.

Number Reversals Sent The number of Reversals received in IDFs from this Direct Participant by the STEP2 central system where the IDF was completely or partially accepted.

Number Reversals Rejected The number of Reversals that were rejected from partially accepted IDFs received from this Direct Participant.



Value Direct Debit Sent The Value of Debit Requests received in IDFs from this Direct Participant by the STEP2 central system where the IDF was completely or partially accepted.

Value Direct Debit Rejected The Value of Debit Requests that were rejected from partially accepted IDFs received from this Direct Participant.

Value Req for Canc Sent The Value of Req for Canc received in IDFs from this Direct Participant by the STEP2 central system where the IDF was completely or partially accepted.

Value Req for Canc Rejected The Value of Req for Canc that were rejected from partially accepted IDFs received from this Direct Participant.

Value Rejects Sent The Value of Rejects received in IDFs from this Direct Participant by the STEP2 central system where the IDF was completely or partially accepted.

Value Rejects Rejected The Value of Rejects that were rejected from partially accepted IDFs received from this Direct Participant.

Value Refunds/Returns Sent The Value of Refunds/Returns received in IDFs from this Direct Participant by the STEP2 central system where the IDF was completely or partially accepted.

Value Refunds/Returns Rejected

The Value of Refunds/Returns that were rejected from partially accepted IDFs received from this Direct Participant.

Value Reversals Sent The Value of Reversals received in IDFs from this Direct Participant by the STEP2 central system where the IDF was completely or partially accepted.

Value Reversals Rejected The Value of Reversals that were rejected from partially accepted IDFs received from this Direct Participant.



Table 4-45 DRR files/bulk/messages sent header – f ield 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

M Number Direct Debit Rejected

15n 54

M Value Direct Debit Sent 18d 69 M Value Direct Debit Rejected 18d 87

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 fields in each such record are as follows:

Field Name Contents

Sender's Reference The Reference of the bulk for which the information in this record relates.

Number Direct Debit Sent The number of Direct Debit received by the STEP2 central system in this bulk. The contents of this field will equal the contents of the Total Number Of Transactions field in the header of this bulk.

Number Direct Debit Rejected

The number of Direct Debit from this bulk that were rejected by the STEP2 central system. 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.

Value Direct Debit Sent

The value of the Direct Debit received by the STEP2 central system in this bulk. The contents of this field will equal the contents of the Sum Of Amounts field in the header of this bulk.

Value Direct Debit Rejected

The value of the Direct Debit from this bulk that were rejected by the STEP2 central system. A DVF containing these Direct Debits 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-47 DRR Direct Debit bulks body – field cont ents

STEP2 – M-PEDD

27th November 2009



F.2.5 DRR Req for Canc bulks sent


M Record Type 4x "DCSB" 0 M Sender's Reference 35x 4 M Number Req for Canc Sent 15n 39

M Number Req for Canc Rejected 15n 54

M Value Req for Canc Sent 18d 69 M Value Req for Canc Rejected 18d 87

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 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


Number Req for Canc Sent

The number of Req for Canc received by the STEP2 central system in this bulk. The contents of this field will equal the contents of the Total Number Of Transactions field in the header of this bulk.

Number Req for Canc Rejected

The number of Req for Canc from this bulk that were rejected by the STEP2 central system. A DVF containing these Req for Canc 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.

Value Req for Canc Sent

The value of the Req for Canc received by the STEP2 central system in this bulk. The contents of this field will equal the contents of the Sum Of Amounts field in the header of this bulk.

Value Req for Canc Rejected

The value of the Req for Canc from this bulk that were rejected by the STEP2 central system. A DVF containing these Req for Canc 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-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 M Sender's Reference 35x 4 M Number Rejects Sent 15n 39 M Number Rejects Rejected 15n 54 M Value Rejects Sent 18d 69 M Value Rejects Rejected 18d 87

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


Number Rejects Sent The number of Rejects received by the STEP2 central system in this bulk. The contents of this field will equal the contents of the Total Number Of Transactions field in the header of this bulk.

Number Rejects Rejected

The number of Rejects from this bulk that were rejected by the STEP2 central system. A DVF containing these Rejects 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.

Value Rejects Sent The value of the Rejects received by the STEP2 central system in this bulk. The contents of this field will equal the contents of the Sum Of Amounts field in the header of this bulk.

Value Rejects Rejected

The value of the Rejects from this bulk that were rejected by the STEP2 central system. A DVF containing these Rejects 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-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 M Sender's Reference 35x 4 M Number Reversals Sent 15n 39 M Number Reversals Rejected 15n 54 M Value Reversals Sent 18d 69 M Value Reversals Rejected 18d 87

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


Number Reversals Sent The number of Reversals received by the STEP2 central system in this bulk. The contents of this field will equal the contents of the Total Number Of Transactions field in the header of this bulk.

Number Reversals Rejected

The number of Reversals from this bulk that were rejected by the STEP2 central system. A DVF containing these 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.

Value Reversals Sent The value of the Reversals received by the STEP2 central system in this bulk. The contents of this field will equal the contents of the Sum Of Amounts field in the header of this bulk.

Value Reversals Rejected

The value of the Reversals from this bulk that were rejected by the STEP2 central system. A DVF containing these 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-53 DRR Reversals bulks body – field content s

STEP2 – M-PEDD

27th November 2009



F.2.8 DRR Refunds/Returns bulks sent


M Record Type 4x "DFSB" 0 M Sender's Reference 35x 4

M Number Refunds/Returns Sent 15n 39

M Number Refunds/Returns Rejected 15n 54

M Value Refunds/Returns Sent 18d 69

M Value Refunds/Returns Rejected 18d 87

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 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


Number Refunds/Returns Sent

The number of Refunds/Returns received by the STEP2 central system in this bulk. The contents of this field will equal the contents of the Total Number Of Transactions field in the header of this bulk.

Number Refunds/Returns Rejected

The number of Refunds/Returns from this bulk that were rejected by the STEP2 central system. 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.

Value Refunds/Returns Sent

The value of the Refunds/Returns received by the STEP2 central system in this bulk. The contents of this field will equal the contents of the Sum Of Amounts field in the header of this bulk.

Value Refunds/Returns Rejected

The value of the Refunds/Returns from this bulk that were rejected by the STEP2 central system. 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 M Sender's Reference 35x 4

M Number Returns of Reversals Sent 15n 39

M Number Returns of Reversals Rejected 15n 54

M Value Returns of Reversals Sent 18d 69

M Value Returns of Reversals Rejected 18d 87

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 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


Number Returns of Reversals Sent

The number of Returns of Reversals received by the STEP2 central system in this bulk. The contents of this field will equal the contents of the Total Number Of Transactions field in the header of this bulk.

Number Returns of Reversals Rejected

The number of Returns of Reversals from this bulk that were rejected by the STEP2 central system. 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.

Value Returns of Reversals Sent

The value of the Returns of Reversals received by the STEP2 central system in this bulk. The contents of this field will equal the contents of the Sum Of Amounts field in the header of this bulk.

Value Returns of Reversals Rejected

The value of the Returns of Reversals from this bulk that were rejected by the STEP2 central system. 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 – fi eld contents

Status Field Name Format Value Position 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

M Number DDs Bulks Received

4n 8

M Number Req for Canc Bulks Received

4n 12

M Number Rejects Bulks Received

4n 16

M Number Direct Debits Received

15n 20

M Number Req for Canc Received

15n 35

M Number Rejects Received 15n 50 M Value Direct Debit received 18d 65

M Value Req for Canc received

18d 83

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

Number DNFs Received The number of DNFs generated by the STEP2 central system for this Direct Participant during the processing of this Interbank Settlement Date.

Number DDs bulks Received The number of DDs bulks generated by the STEP2 central system for this Direct Participant during the processing of this Interbank Settlement Date.

Number Req for Canc bulks Received

The number of Req for Canc bulks generated by the STEP2 central system for this Direct Participant during the processing of this Interbank Settlement Date.

Number Rejects bulks Received

The number of Rejects bulks generated by the STEP2 central system for this Direct Participant during the processing of this Interbank Settlement Date.

Number DDs Received The number of debit requests in DNFs generated by the STEP2 central system for this Direct Participant during the processing of this Interbank Settlement Date

Number Req for Canc Received

The number of Req for Canc in DNFs generated by the STEP2 central system for this Direct Participant during the processing of this Interbank Settlement Date

Number Rejects Received The number of Rejects in DNFs generated by the STEP2 central system for this Direct Participant during the processing of this Interbank Settlement Date

Value Direct Debit received The value of debit requests in DNFs generated by the STEP2 central system for this Direct Participant during the processing of this Interbank Settlement Date

Value Req for Canc received The value of Req for Canc in DNFs generated by the STEP2 central system for this Direct Participant during the processing of this Interbank Settlement Date

Value Rejects received The value of Rejects in DNFs generated by the STEP2 central system for this Direct Participant during the processing of this Interbank Settlement Date

STEP2 – M-PEDD

27th November 2009



Table 4-60 DRR files received header – field conten ts

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

Number DDs Direct The number of DDs for which this Direct Participant is receiving the transactions as the receiving bank.

Number DDs Indirect The number of DDs for which this Direct Participant is receiving the 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 Number Req for Canc Direct

15n 4

M Number Req for Canc Indirect

15n 19

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

Number Req for Canc Direct The number of Req for Canc for which this Direct Participant is receiving the transactions as the receiving bank.

Number Req for Canc Indirect The number of Req for Canc for which this Direct Participant is receiving the transactions on behalf of an in Direct Participant as the receiving bank.

STEP2 – M-PEDD

27th November 2009



Field Name Contents

Value Req for Canc Direct The value of the Req for Canc identified in Number Req for Canc Direct, above.

Value Req for Canc Indirect The value of the Req for Canc identified in Number 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

Number Rejects Direct The number of Rejects for which this Direct Participant is receiving the transactions as the receiving bank.

Number Rejects Indirect The number of Rejects for which this Direct Participant is receiving the transactions on behalf of an in Direct Participant as the receiving bank.

Value Rejects Direct The value of the Rejects identified in Number Refunds/Returns Direct, above.

Value Rejects Indirect The value of the Rejects identified in Number Refunds/Returns 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

Participant during the processing of this Interbank Settlement Date. Number RSFs Debit Bulks Received

The number of RSFs debit bulks generated by the STEP2 central system for this Direct Participant during the processing of this Interbank Settlement Date.

Number RSFs Credit Bulks Received

The number of RSFs Credit bulks generated by the STEP2 central system for 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 Interbank Settlement Date

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 system for this Direct Participant during the processing of this Interbank Settlement Date

Value Direct Debits credit The value of Direct Debits sent in RSFs generated by the STEP2 central system for this Direct Participant during the processing of this Interbank Settlement Date

Table 4-69 DRR RSFs received header – field content s

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 fields in this record are as follows:

STEP2 – M-PEDD

27th November 2009



Field Name Contents Number Debit Direct Debit settled

The number of Debit DDs settled for this Direct Participant during the processing of this Interbank Settlement Date.

Number Debit Direct Debit Cancelled

The number of Debit DDs cancelled for this Direct Participant during the processing of this Interbank Settlement Date.

Value Debit Direct Debit settled

The value of Debit DDs settled for this Direct Participant during the processing of this Interbank Settlement Date.

Value Debit Direct Debit Cancelled

The value of Debit DDs cancelled for this Direct Participant during the processing of this Interbank Settlement Date.

Table 4-71 DRR RSFs Debit Direct Debits – field co ntents

F.2.13 DRR -RSFs Credit Direct debit


M Record Type 4x "DRSB" 0 M Number Credit Direct Debits settled 15n 4

M Number Credit Direct Debits Cancelled

15n 19

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 fields in this record are as follows:

Field Name Contents

Number Credit Direct Debits settled

The number of Direct Debits sent settled for this Direct Participant during the processing of this Interbank Settlement Date.

Number Credit Direct Debits Cancelled

The number of Direct Debits sent cancelled for this Direct Participant during the processing of this Interbank Settlement Date.

Value Credit Direct Debits settled

The value of Direct Debits sent settled for this Direct Participant during the processing of this Interbank Settlement Date.

Value Credit Direct Debits Cancelled

The value of Direct Debits sent cancelled for this Direct Participant during the processing of this Interbank Settlement Date.

Table 4-73 DRR RSFs Credit Direct Debit – field con tents


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

M Number SDFs Refunds/Returns Bulks Received

6n 10

M Number SDFs Reversal Bulks Received

6n 16

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 the fields in this record are as follows:

Field Name Contents Number SDFs Received The number of SDFs generated by the STEP2 central system for this Direct

Participant during the processing of this Interbank Settlement Date. Number SDFs Refunds/Returns Bulks Received

The number of SDFs Refunds/Returns bulks generated by the STEP2 central system for this Direct Participant during the processing of this Interbank Settlement Date.

Number SDFs Reversal Bulks Received

The number of SDFs Reversal bulks generated by the STEP2 central system 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 content s

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 15n 70 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 fields in this record are as follows:

Field Name Contents Number Refunds/Returns received

The number of Refunds/Return settled receive for this Direct Participant during the processing of this Interbank Settlement Date.

Value Refunds/Returns received

The value of Refunds/Return settled receive for this Direct Participant during 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

processing of this Interbank Settlement Date. Reserved for future use Reserved for future use Reserved for future use Reserved for future use

Table 4-78 DRR SDFs Return/Reversal received – fiel d 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

M Number CDFs Refunds/Returns Bulks Received

6n 10

M Number CDFs Reversal Bulks Received

6n 16


Table 4-80 DRR CDFs received header

Each DRR contains one and only one DRR CDFs files received header record. The contents of the fields in this record are as follows:

Field Name Contents Number CDFs Received The number of CDFs generated by the STEP2 central system for this Direct

Participant during the processing of this Interbank Settlement Date. Number CDFs Refunds/Returns Bulks Received

The number of CDFs Refunds/Returns bulks generated by the STEP2 central system for this Direct Participant during the processing of this Interbank Settlement Date.

Number CDFs Reversal Bulks Received

The number of CDFs Reversal bulks generated by the STEP2 central system for this Direct Participant during the processing of this Interbank Settlement Date.


Table 4-81 DRR CDFs received header – field content s

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 M Reserved for future use 15n 60 M Reserved for future use 18d 75

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 fields in this record are as follows:

Field Name Contents Number Refunds/Returns received

The number of Refunds/Returns cancelled receive for this Direct Participant during the processing of this Interbank Settlement Date.

Value Refunds/Returns received

The value of Refunds/Returns cancelled receive for this Direct Participant during the processing of this Interbank Settlement Date.

Number Reversal received The number of Reversal cancelled receive for this Direct Participant during the processing of this Interbank Settlement Date.

Value Reversal received The value of Reversal cancelled receive for this Direct Participant during the processing of this Interbank Settlement Date.

Reserved for future use Reserved for future use Reserved for future use Reserved for future use

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

M Number Debit Instructions sent

6n 4

M Number Debit Instructions Cancelled

6n 10

M Value Debit Instructions sent 18d 16

M Value Debit Instructions Cancelled

18d 33

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

Number Debit Instructions sent

The number of settlement instructions sent to the external settlement mechanism 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 debit party. The DRR settlement transactions sent body will contain one record for each such settlement instruction.

Number Debit Instructions Cancelled

The number of settlement instructions identified in Number Debit Instructions, above, that were cancelled by the external settlement mechanism.

Value Debit Instructions sent The value of the settlement instructions identified in Number Debit Instructions, above.

Value Debit Instructions Cancelled

The value of the settlement instructions identified in Number Debit Instructions 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 Settlement Cycle 2n 20 M Interbank Settlement Date 6!n 22 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

M Number Refund/Returns received 15n 77

M Reserved for future use 15n 92 M Value of DDs received 18d 107 M Value of Reversals sent 18d 125

M Value of Refunds/Returns received 18d 143

M Reserved for future use 18d 161 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.



Credit Party DP BIC The BIC of the Direct Participant who was the credit party of this settlement instruction.

Credit Party Settlement BIC The BIC used by the Direct Participant identified in Credit Party Settlement 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 received

The number of Refunds/Returns included in this settlement instruction.


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 received

The value of the above Number Refunds/Returns received.


Settlement Amount The amount of this settlement instruction.

Settlement Result*

The result of TARGET2 processing of this settlement instruction, e.g.:

• “STLD”, indicating that the settlement instruction was successfully processed, or

• “CANC”, indicating that the settlement instruction was cancelled.

Table 4-88 DRR Debit Party settlement Transactions body – field contents

Status Field Name Format Value Position 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

M Number Credit Instructions Cancelled 6n 10

M Value Credit Instructions 18d 16

M Value Credit Instructions Cancelled 18d 34

Table 4-90 DRR s Credit Party settlement Transactio ns 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 Cancelled

The number of settlement instructions identified in Number Credit Instruct, 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 Cancelled

The value of the settlement instructions identified in Number Credit Instruct Cancelled, above.

Table 4-91 DRR Credit Party settlement Direct Debit s header – field contents


M Record Type 4x "DCTB" 0 M Settlement Reference 16x 4 M Settlement Cycle 2n 20 M Interbank Settlement Date 6!n 22 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 Number Refunds/Returns sent 15n 77

M Reserved for future use 15n 92 M Value of DDs sent 18d 107 M Value of Reversals received 18d 125

M Value of Refunds/Returns sent 18d 143

M Reserved for future use 18d 161 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.



Debit Party DP BIC The BIC of the Direct Participant who was the debit party of this settlement instruction.

Debit Party Settlement BIC The BIC used by the Direct Participant identified in Debit Party Settlement 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 sent

The number of Refunds/Returns included in this settlement instruction.


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 sent

The value of the above Number Refunds/Returns sent.


Settlement Amount The amount of this settlement instruction.

Settlement Result*

The result of TARGET2 processing of this settlement instruction, e.g.:

• “STLD”, indicating that the settlement instruction was successfully processed, or

• “CANC”, indicating that the settlement instruction was cancelled.

Table 4-93 DRR Credit Party settlement Transactions body – field contents

Status Field Name Format Value Position 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

MCRB 0-n MSR Req for Cancellation received

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

Status Field Name Format Value Position M Record Type 4x “HMSR” 0 M Service Identifier 3x “COR” for Core

or “B2B” for B2B 4

M File Type 3x "MSR" 7 M Sending Institution 4!a2!a2!c EBA STEP2 CS

BIC 10

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 Reference Date% 6!n 55 M Total Number Records 6n 61

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

Status Field Name Format Value Position 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

Sent 15n 64

M Number Req for Cancellation Rejected

15n 79

M Number Rejects Sent 15n 94 M Number Rejects Rejected 15n 109 M Number Reversals Sent 15n 124 M Number Reversals Rejected 15n 139 M Number Reversals Cancelled 15n 154 M Number Reversals Settled 15n 169 M Number Refunds/Returns

Sent 15n 184

M Number Refunds/Returns Rejected

15n 199

M Number Refunds/Returns Cancelled

15n 214

M Number Refunds/Returns Settled

15n 229

M Reserved for future use 15n 244 M Reserved for future use 15n 259 M Reserved for future use 15n 274 M Reserved for future use 15n 289 M Value Direct Debit Sent 18d 304 M Value Direct Debit Rejected 18d 322 M Value Direct Debit Cancelled 18d 340 M Value Direct Debit Settled 18d 358 M Value Req for Canc Sent 18d 376 M Value Req for Canc Rejected 18d 394 M Value Rejects Sent 18d 412 M Value Rejects Rejected 18d 430 M Value Reversals Sent 18d 448 M Value Reversals Rejected 18d 466 M Value Reversals Cencelled 18d 484 M Value Reversals Settled 18d 502 M Value Refunds/Returns Sent 18d 520 M Value Refunds/Returns

Rejected 18d 538

M Value Refunds/Returns Cancelled

18d 556

M Value Refunds/Returns Settled

18d 574

M Reserved for future use 18d 592 M Reserved for future use 18d 610 M Reserved for future use 18d 628

STEP2 – M-PEDD

27th November 2009



M Reserved for future use 18d 646

Table 4-98 MSR Transactions sent header

Status Field Name Format Value Position 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

Status Field Name Format Value Position M Record Type 4x "MCSB" 0 M Receiving Participant 4!a2!a2!c 4 M Number Req for Canc

Accepted 15n 12

M Value Req for Canc Accepted

18d 27

Table 4-100 MSR Req for Canc sent body

Status Field Name Format Value Position M Record Type 4x "MJSB" 0 M Receiving Participant 4!a2!a2!c 4 M Number Rejects Accepted 15n 12 M Value Rejects Accepted 18d 27

Table 4-101 MSR Rejects sent body

Status Field Name Format Value Position M Record Type 4x "MVSB" 0 M Receiving Participant 4!a2!a2!c 4 M Number Reversals Accepted 15n 12 M Number Reversals

Cancelled 15n 27

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

Status Field Name Format Value Position M Record Type 4x "MFSB" 0

STEP2 – M-PEDD

27th November 2009



Status Field Name Format Value Position M Receiving Participant 4!a2!a2!c 4 M Number Refunds/Returns

Accepted 15n 12

M Number Refunds/Returns Cancelled

15n 27

M Number Refunds/Returns Settled

15n 42

M Value Refunds/Returns Accepted

18d 57

M Value Refunds/Returns Cancelled

18d 72

M Value Refunds/Returns Settled

18d 87

Table 4-103 MSR Refunds/Returns sent body

Status Field Name Format Value Position M Record Type 4x "MRSB" 0 M Receiving Participant 4!a2!a2!c 4 M Number Returns of Reversals

Accepted 15n 12

M Number Returns of Reversals Cancelled

15n 27

M Number Returns of Reversals Settled

15n 42

M Value Returns of Reversals Accepted

18d 57

M Value Returns of Reversals Cancelled

18d 72

M Value Returns of Reversals Settled

18d 87

Table 4-104 MSR Returns of reversals sent body

Status Field Name Format Value Position M Record Type 4x "MTXT” 0

Table 4-105 MSR transactions sent trailer

F.3.4 MSR body: statistics on Transactions received

Status Field Name Format Value Position M Record Type 4x "MTRH" 0 M Number DDs Received 15n 4 M Number Req for Cancellation

Received 15n 19

M Number Rejects Received 15n 34 M Number Reversals Received 15n 49 M Number Refunds/Returns

Received 15n 64


STEP2 – M-PEDD

27th November 2009



M Value DDs Received 18d 94 M Value Req for Cancellation

Received 18d 112

M Value Rejects Received 18d 130 M Value Reversals Received 18d 148 M Value Refunds/Return

Received 18d 166

M Reserved for future use 18d 184

Table 4-106 MSR Transactions received header

Status Field Name Format Value Position 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

Status Field Name Format Value Position M Record Type 4x "MCRB" 0 M Sending Participant 4!a2!a2!c 4 M Number Req for Cancellation

Received 15n 12

M Value Req for Cancellation Received

18d 27

Table 4-108 MSR Req for Cancellation received body

Status Field Name Format Value Position M Record Type 4x "MJRB" 0 M Sending Participant 4!a2!a2!c 4 M Number Rejects Received 15n 12 M Value Rejects Received 18d 27

Table 4-109 MSR Rejects received body

Status Field Name Format Value Position M Record Type 4x "MVRB" 0 M Sending Participant 4!a2!a2!c 4 M Number Reversals Received 15n 12 M Value Reversals Received 18d 27

Table 4-110 MSR Reversals received body

Status Field Name Format Value Position M Record Type 4x "MFRB" 0 M Sending Participant 4!a2!a2!c 4 M Number Refunds/Returns

Received 15n 12

STEP2 – M-PEDD

27th November 2009



M Value Refunds/Returns Received

18d 27

Table 4-111 MSR Refunds/Returns received body

Status Field Name Format Value Position M Record Type 4x "MRRB" 0 M Sending Participant 4!a2!a2!c 4 M Number Returns of Reversals

Received 15n 12

M Value Returns of Reversals Received

18d 27

Table 4-112 MSR Returns of Reversals received body

Status Field Name Format Value Position M Record Type 4x "MTRT” 0

Table 4-113 MSR transactions received trailer

F.3.5 MSR trailer

Status Field Name Format Value Position 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

Creditor Bank Text See Value column

1 “Creditor Bank”

Debtor Bank Text See Value

column 1

“Debtor Bank”

Number of DD Number See Value

column 1

The number of DD

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

Number of DD Number 9n 1 The number of DD sent and settled for the

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

Creditor Bank BIC 11 Text See Value

column 1

“Creditor Bank”

Debtor Bank BIC 11 Text See Value column

1 “Debtor Bank”

Number of DD Number See Value

column 1

The number of DD

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

Number of DD Number 9n 1 The number of DD received and settled for

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 bank but it must support the SWIFTNet service as shown below3. 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 Po ints

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

xsys.xxx.delnotif Request for delivery notification Bank to STEP2, and STEP2 to bank.

Other configuration RBAC control used N STEP2 uses RBAC

Non-Repudiation Support for FileAct Y

SWIFT maintains a copy of the file for later query resolution. Delivery notifications are mandatory for 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

Centralised Billing N

The Direct Participant will pay for the transmission of transaction files they send to STEP2 and for the 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


File Title Text 42x “SDD Core” or “SDD B2B “ DIRECT 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.

Status Text 9x ENABLED, SUSPENDED, R-ONLY, DISABLED

Admission Profile Text 3x “DEB”or “CAD”. Whether a bank is a debtor bank only or both Creditor and Debtor.

Debit Type Allowed Text 3c

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

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


File Title Text 42x “SDD Core” or “SDD B2B “ INDIRECT 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


IP BIC BIC (11) 11x BIC(11) format. Ending in XXX is 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

DP BIC BIC (8) 8x The BIC of the associated Direct 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


IP BIC BIC (11) 11x BIC(11) format. Ending in XXX is 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

DP BIC BIC (8) 8x The BIC of the associated Direct Participant.

DP Settlement BIC BIC (11) 11x The BIC used for settlement of the IP data. 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

Admission Profile Text 3x “DEB” or “CAD”. Whether a bank is a debtor bank only or both Creditor and Debtor.

Debit Type Allowed Text 3c A 3-character code indicating the product(s) 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

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

AC04 ClosedAccountNumber ISO X

AC06 BlockedAccount ISO X

AG01 TransactionForbidden ISO X

AG02 InvalidBankOperationCode

ISO X

AM04 InsufficientFunds ISO X

AM05 Duplication ISO X X

ED05 SettlementFailed ISO X

MD01 NoMandate ISO X

MD02 MissingMandatoryInformationOnMandate

ISO X

MD03 InvalidFileFormatForOtherReasonThanGroupingIndicator

ISO X

MD07 EndCustomerDeceased ISO X

STEP2 – M-PEDD

27 November 2009




MS03 NotSpecifiedReasonAgentGenerated ISO X

RC01 BankIdentifierIncorrect

ISO X

RR01 Regulatory Reason PRTRY X

SL01 Specific Service offered by Debtor Bank

PRTRY X X

MS02 NotSpecificedReasonCustomerGenerated

PRTRY X

MS03 NotSpecifiedReasonAgentGenerated

PRTRY X

B00 Bulk totally accepted PRTRY X

B01 Bulk partially accepted

PRTRY X

B02 Maximum number of transactions in a bulk exceeded

PRTRY X

B03 Number of transactions mismatch

PRTRY X

B05 Total amount mismatch

PRTRY X

B07 Control Sum mismatch

PRTRY X

B08 Maximum number of bulks in a file exceeded

PRTRY X

B09 All transactions rejected

PRTRY X

B10 Instructing Agent mismatch

PRTRY X

B11 Invalid use of Instructed Agent

PRTRY X

B13 Zero Settlement Amount

PRTRY X

STEP2 – M-PEDD

27 November 2009




B14 Duplicate MessageID PRTRY X

B15 Invalid Settlement Date PRTRY X

B16 Invalid Settlement Info details PRTRY X

B23 Too many consecutive rejected transactions

PRTRY X

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.

Code Description Type

Pac

s006

Pac

s002

Pac

s007

Pac

s004

Pac

s002

S2

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




Pac

s006

Pac

s002

Pac

s007

Pac

s004

Pac

s002

S2

DT01

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 � 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)

ISO X

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

PY01 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 the routing table

PRTRY X

XD19 Invalid IBAN format - An IBAN in the transaction has failed the ISO 13616 PRTRY X

XD75 Sequence Type Mismatch - If “Amendment Indicator” is “TRUE” and Original Debtor Agent is set to “SMNDA” to indicate same mandate with new Debtor Agent, the field DrctDbtTxInf < PmtTpInf< SeqTp must indicate “FRST”:

PRTRY X

STEP2 – M-PEDD

27 November 2009




Pac

s006

Pac

s002

Pac

s007

Pac

s004

Pac

s002

S2

XT13

Unsupported XML field � The transaction contains at least one unsupported field; � At least one mandatory field is not present the transaction

The offending XML tag is present with the error code (if available).

PRTRY X

XT33 Invalid data format - The content of at least one XML element is not in the required format. The offending XML tag is present with the error code

PRTRY X

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

XT79 Debtor Agent not allowed to receive DD - If the admission profile does not admit the sending of a DD or Participant in R-ONLY status.

PRTRY X

XT80 Creditor Agent not allowed to send DD - The Creditor Agent is not allowed to send Direct Debit as per the information available in the Routing Table PRTRY X

XT81 Only SEPA Core fields are allowed - A XML field present in the XML schemas but not permitted in the SDD services was used without prior agreement

PRTRY X

Documents

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