1_EBA STEP2 SCT Interface Specifications v20111121 - Updated 20110606 Clean

STEP2 – SEPA Credit Transfer Processing Service

Interface Specifications

This document is confidential within the institutions which have received them from EBA CLEARING.

Version: 20111121(RB5.0)

This document is compliant with version 5.0 of the EPC Rulebook.

STEP2 SEPA Credit Transfer Service

21/11/2011 Interface Specification

Version 20111121 (RB5.0) ii of 154

HISTORY OF MODIFICATIONS

Version Date Authored by Status

0.1 15/09/2006 Richard Liblanc Draft



1.1 26/01/2007 Richard Liblanc Draft sent to banks for approval

1.2 02/02/2007 Richard Liblanc Final

20070622 22/06/2007 Richard Liblanc Updated

20080128 28/01/2008 Richard Liblanc Final version for SEPA go live date

20080505 05/02/2008 Richard Liblanc Corrected version of v20080128

20081208 15/06/2008 Richard Liblanc First Draft for version 20081208

20081208 30/07/2008 Richard Liblanc Updated version for 20081208

20081208 08/12/2008 David Blanchemanche Final version of v20081208

20091001 01/10/2009 SIA-SSB Review for SWIFTNet 6.1 (Par. Error! Reference source not found./3.5.1)

20091204 14/12/2009 SIA-SSB Multiple Cycles changes (Par. 2.3.4/3.1/3.2 / I.3 / Appendix E)

Duplicate check (Par. A.4)

Max Amount (Par. C.1.2)

File split clarification (Par. 3.6 / 2.3.3)

MSR Generation (Par. 2.3.7.4)

20101101 05/02/2010 SIA-SSB First Draft for version 20101101

20101101 25/02/2010 SIA-SSB First review for version 20101101

20101101 10/03/2010 SIA-SSB Review due to errata list for version 20101101




20101101 04/06/2010 SIA-SSB Field “Issr” now Yellow

20101101

20111121

07/10/2010

25/03/2011

SIA-SSB

SIA-SSB

Review due to errata list for version 20101101

First Draft for version 20111121 – Rulebook 5.0

20111121 01/06/2011 SIA Review due to EPC Errata List (EPC 167-11)

Version 20081208 Changes

- Included changes related to Rulebook/Implementation Guidelines v3.2:

o Usage of Ultimate Debtor/Creditor Name and Identification fields o Usage of field Purpose in SEPA messages o Usage of field Category Purpose in SEPA messages o Check that Returned Interbank Settlement Amount is equal to Original Interbank Settlement

Amount in a pacs004 transaction o New SEPA reason codes for pacs004: AG02, MD03, RC01, and TM01 (see section I.3)

- Added extra occurrences to both Structured and Unstructured Remittance Information for AOS purpose - pacs004 and pacs006 messages updated according to the RB3.2 and AOS changes above - <RmtInf> and </RmtInf> tags are no longer counted against the 140 characters limit for Structured

Remittance Information. The 140 characters limit is for all characters between the <Strd> and </Strd> tags, not inclusive.

- Duplicate key for Return (pacs004) has changed from Instructing Agent to Original Creditor Agent - Clarified validation rules for IBAN fields in pacs008 messages



Version 20111121 (RB5.0) iii of 154

- Removed mentions of EURO1/STEP1 as settlement engine as STEP2 settlement is now performed in TARGET2

- Added details concerning the new file, Routing Table File (RTF), in particular its naming convention (see section 3.5 and H.5 )

- Added note about CCF only being sent after the last cycle of a business day (result of new feature for automated deferral of failed settlement instructions to next same-day settlement cycle) (see section 2.3.4)

- Added diagram and clarified text on the generation of MessageId by the Central System (section A.5) - Clarified format for field CdtTrfTxInf/Purp/Cd is 35x and not 4!a (see section C1.2) - Clarified use of error code AM01 (PACS 004) (see section I.3) - Clarified request type (pacs.xxx.sct.a.any) for routing table (see section G.1.3) - Added remarks on the format ISODateAndTime (see section 4) - Clarification on number of settlements files (SCF) (see section 2.3.3) - Clarified format for field SndgInst in CCF (see section B.4 and C.3.2)

Version 20080505 Changes - Removed word Credeuro in the document for legal reasons - Section A.5 on the format of the MessageId generated by STEP2 has been aligned with the current

behavior of the system. - Clarified bulk error codes usage in section D.2 - Corrected positions in table for MTSH record (section F.3.2) Version 20101101 Changes – Update 2010-02-05 - Included changes related to Rulebook/Implementation Guidelines v4.0 - Removed the pacs.006 message (See 2.1) - Added two new messages types : camt.056 and camt.029 (See 2.1) - Recall Procedure of a settled Credit Transfer (See 2.1) - SCF file content (See 2.3.3): added camt.056 and camt.029 messages - File Format and Bulks (See 3.6) - Duplicate Checking (See A.4) - Bulk level Error Codes (See I.2) - Transaction level Error Codes (See I.3) - DRR File structures: modified for new camt messages (See F.2.2/F.2.6) - MSR File structures: modified for new camt messages (See F.3.2/F.3.5) - Added explanation for Recall Procedure (See A.8) - Added explanation on CR/DB Agents in pacs.002S2 (See A.9) - Changes to the pacs.008 CT format (See C.1) - New camt.056 Payment Cancellation Request message format (See C.2) - New camt.029 Resolution of Investigation message format (See C.3) - Changes to the pacs.002S2 Reject format (See C.4) - Changes to the pacs.004 Return format (See C.5) Version 20101101 Changes – Update 2010-02-25

- Added the R21 Error code (See D.1 / I.1) - Added the label “** CW **” to identify which fields have the “Collapse Whitespaces” setting at Schema

level (See Appendix C) - Split output files based on network limit file size (See 3.6 / 2.3.3) - Changes to validation rules due to camt.056 message (See D.2) - Added new values for Payment Type Allowed in RTF files (See H.4) - Changes due to Errata List of 20100219 - Changes in the routing of transactions (See 3.10) - Added the Error code B12 (See D.2/I.2) Version 20101101 Changes – Update 2010-03-10



Version 20111121 (RB5.0) iv of 154

- Changed field name from BICorBEI to BICOrBEI ( See Appendix C). - Changed field name from SrvcID to SrvcId (See B.1) - Changed Error code for invalid ClrSys in camt.056 (See C.2.2) Version 20101101 Changes – Update 2010-03-26

- Changed validation rules for Reason field of camt.029 (See C.3.2). - Changes due to EPC Errata List (EPC041-10 V 0.3). (See C.1.2 / C.2.2 / C.5.2). - Changes due to Italian AOS for transferability (See C.1.2 / H.4). - Changes due to Errata List of 20100326 (See 2.1 / F.2.2 / H.6.7 / H.7.7 / 3.6). - Removed information from Appendix G.1.4 - Changes to DRR and MSR for PCR/ROI (See F.2.2/F.3.3) Version 20101101 Changes – Update 2010-04-02 - Added code “ARDT” in Reason field of camt.029 ( See I.3) - Changes due to Errata List of 20100326 (See F.2.2/F.3.2) Version 20101101 Changes – Update 2010-04-23

- Changes due to Errata List of 20100423 (See F.2.2) - Changes due to EPC Errata List of 2010408 (See C.5.2) Version 20101101 Changes – Update 2010-05-28

- Changes due to Errata List of 20100528 (See I.3/C.4/C.5.2) Version 20101101 Changes – Update 2010-06-04 - Field “Issr” under Structured Remittance Info is now yellow (See C.2.2/C.3.2/C.5.2) - Changed the name of the field “OrgnlIntrBkSttlmDt” in “IntrBkSttlmDt” for camt.029 (See C.3.2) Version 20101101 Changes – Update 2010-08-13 - Rulebook reference changed from AT-R3 to AT-R6 (See C.3.2) - Rulebook reference changed from AT-R3 to AT-R48 (See C.2.2) - Added error code XT81 at bulk level for CtrlSum in Camt.056 (See C.2.1/I.2) - Changed FinInstId with FinInstnId (See C.2.2/C.3.1/C.3.2) - Error code for subsequent Strd elements changed from XT13 to XT81 (See C.1.2/C.2.2/C.3.2/C.5.2) - Clarification on second bullet for RtrdIntrBkSttlmAmt (See C.5.2) - Removed wildcard from OrgnlMsgNmId in pacs.002S2 (See C.4.2) - Added attribute check for RtrdInstdAmt (See C.5.2) - Added error code XT33 in Charges Amount (See C.5.2) - Removed char ‘*’ from Report description (See Appendix F) Version 20101101 Changes – Update 2010-08-31

- Clarified format for the field (TxInf+RtrRsnInf++Rsn++++Cd) is 4!c and not 4!a (See C.5.2) - Clarification on the restriction of the usage of BICorBEI and OTHERS fields under OrgId (See C.1.2/C.5.2 Version 20101101 Changes – Update 2010-10-07

- Clarification regarding sending of camt.056 during settlement (See A.8) - Clarification regarding the Collapse Whitespaces option (See 4) - Clarification regarding the RTF format (See H.4)



Version 20111121 (RB5.0) v of 154

Version 20111121 Changes – Update 2011-03-25 - Changed the Rulebook version number to 5.0 - Added field ClrSys to Camt.029 Message (See C.3.2) - New PCF file (See 2.1/2.3.5/3.5.1/3.5.2/A.1.5/A.7/A.8/B.5/C.4) - Last settlement cycle of the day is optional (See 3.1/3.2) - Setting the settlement cycle (See A.10/C.1.1) Version 20111121– Update 2011-05-27

- Changes due to Errata List of 2011-05-27 (See 2.1/3.6/3.11/A.8/A.10/C.4.1/C.4.2/C.4.3/C.5.2D.1D.2/I.3) Version 20111121– Update 2011-06-01

- Changes due to the EPC Errata List of 2011-05-30 (See C.2.2)



Version 20111121 (RB5.0) vi of 154

CONTENT PAGE

1. INTRODUCTION .................................................................................................................. 11

1.1 Purpose and scope of Document ................................................................................. 11

1.2 References ................................................................................................................... 11

1.3 SEPA Credit Transfer Service Requirements ............................................................... 11

1.4 Glossary ....................................................................................................................... 12

1.5 XML Schema Versions .................................................................................................. 15

2. THE STEP2 SYSTEM ............................................................................................................ 16

2.1 Overview ...................................................................................................................... 16

2.2 Connecting to STEP2 as a Direct Participant ............................................................... 19

2.2.1 Connecting to STEP2 via a STEP2-enabled payment system .......................................... 19

2.3 STEP2 SCT File Types ................................................................................................... 20

2.3.1 Input Credit File (ICF) ................................................................................................. 20

2.3.2 Credit Validation File (CVF) .......................................................................................... 20

2.3.3 Settled Credit File (SCF) .............................................................................................. 21

2.3.4 Cancelled Credit File (CCF) .......................................................................................... 21

2.3.5 Payment Cancellation File (PCF) - Optional ................................................................... 21

2.3.6 Routing Table File (RTF) .............................................................................................. 21

2.3.7 Reports Files............................................................................................................... 22

2.3.7.1 Reception of reconciliation and statistical reports ............................................ 22

2.3.7.2 Cycle Reconciliation Report (CRR) .................................................................. 22

2.3.7.3 Daily Reconciliation Report (DRR) .................................................................. 22

2.3.7.4 Monthly Statistical Report (MSR) .................................................................... 22

3. STEP2 FILE EXCHANGE FUNDAMENTALS ........................................................................... 23

3.1 STEP2 SCT Timetable ................................................................................................... 23

3.2 STEP2 SCT Settlement Cycles ...................................................................................... 23

3.3 File exchange security ................................................................................................. 23

3.4 File formats, naming conventions, and format versioning .......................................... 25

3.5 File Naming Conventions ............................................................................................. 25

3.5.1 Network File Names .................................................................................................... 25

3.5.1.1 Routing Table File (RTF) FileName convention ................................................ 26

3.5.2 Sender’s File Reference (SFR) ...................................................................................... 26

3.6 File format and bulks ................................................................................................... 27

3.7 XML Schemas ............................................................................................................... 27

3.8 Validation of Input Credit Files .................................................................................... 28

3.9 BIC Validation .............................................................................................................. 28

3.10 STEP2 Message Routing .......................................................................................... 30

3.10.1 Routing process .......................................................................................................... 30

3.11 Retransmission of output files ................................................................................ 31

3.11.1 File Retransmission Requested via STEP2 CS ................................................................ 31

3.11.2 File Retransmission Requested via DPWS - SwiftNet ...................................................... 31

4. HOW TO USE THE APPENDICES .......................................................................................... 32

APPENDIX A FILE STRUCTURES AND DETAILS ....................................................................... 33

A.1 STEP2 SCT BULK TYPES ............................................................................................... 33

A.1.1 ICF Bulk messages .................................................................................................. 33

A.1.2 CVF Bulk messages .................................................................................................. 33



Version 20111121 (RB5.0) vii of 154

A.1.3 SCF Bulk messages .................................................................................................. 33

A.1.4 CCF Bulk messages .................................................................................................. 33

A.1.5 PCF Bulk messages .................................................................................................. 33

A.2 ICF Multiple Bulks and restrictions .............................................................................. 34

A.3 File Content Encoding .................................................................................................. 34

A.4 Duplicate Checking ...................................................................................................... 34

A.5 Message ID .................................................................................................................. 35

A.6 Schema validation ....................................................................................................... 36

A.7 Usage of Instructed and Instructing Agents ............................................................... 37

A.8 Recall Procedure .......................................................................................................... 38

A.9 Usage of Creditor/Debtor Agent in pacs.002S2 .......................................................... 39

A.10 Setting the Settlement Cycle .................................................................................. 39

APPENDIX B XML FILES HEADERS .......................................................................................... 41

B.1 INPUT CREDIT FILE (ICF) HEADER ............................................................................. 41

B.2 XML Credit Validation File (CVF) Header ..................................................................... 42

B.3 XML Settled Credit File (SCF) STEP2 File Header ........................................................ 43

B.4 XML Cancelled Credit File (CCF) STEP2 File Header .................................................... 44

B.5 XML Payment Cancellation File (PCF) STEP2 File Header ........................................... 44

APPENDIX C XML MESSAGE DEFINITIONS ............................................................................. 45

C.1 STEP2 Usage of Credit Transfers (pacs.008) ............................................................... 45

C.1.1 SCT Credit Transfer (pacs.008) Bulk Header .......................................................... 45

C.1.2 SCT Credit Transfer (pacs.008) Individual Transaction .......................................... 48

C.2 STEP2 usage of camt.056 (Payment Cancellation Request) ....................................... 61

C.2.1 SCT Payment Cancellation Request (camt.056) Bulk Header ................................. 61

C.2.2 SCT Payment Cancellation Request (camt.056) –Individual Credit Transfer

Cancellation Instruction .............................................................................................. 62

C.3 STEP2 Usage of camt.029 (Resolution of Investigation) ............................................ 73

C.3.1 SCT Resolution of Investigation (camt.029) Bulk Header ...................................... 73

C.3.2 SCT Resolution of Investigation (camt.029) Individual Transaction Information . 74

C.4 STEP2 Usage of pacs.002S2 (Payment Status) ........................................................... 85

C.4.1 SCT Reject (pacs.002S2) in CVF,CCF and PCF Bulk Header .................................... 85

C.4.2 SCT Reject (pacs.002S2) in CVF,CCF and PCF - Original Group Information And

Status ........................................................................................................................... 86

C.4.3 SCT Reject (pacs.002S2) in CVF,CCF and PCF – Individual Transaction ................ 88

C.5 STEP2 Usage of pacs.004 (Return) .............................................................................. 91

C.5.1 SCT Return (pacs.004) Bulk Header SCF & ICF ....................................................... 91

C.5.2 SCT Return (pacs.004) Individual Transaction ....................................................... 93

APPENDIX D FILE/BULK VALIDATION AND ERROR CODES ................................................... 108

D.1 ICF Naming & Structure Validation Process ................................................................ 108

D.2 Bulks Naming & Structure Validation Process ............................................................. 114

APPENDIX E TRANSACTION ERROR CODES ........................................................................... 120

APPENDIX F REPORT FILE DETAILS ....................................................................................... 121

F.1 CRR Cycle Settlement Report ...................................................................................... 121

F.1.1 CRR Header ............................................................................................................. 121

F.1.2 CRR Debit Party ....................................................................................................... 121

F.1.3 CRR Credit Party ..................................................................................................... 122



Version 20111121 (RB5.0) viii of 154

F.2 Daily Reconciliation Report (DRR) .............................................................................. 124

F.2.1 DRR header ............................................................................................................. 124

F.2.2 DRR files/bulks/transactions sent .......................................................................... 124

F.2.3 DRR settlement transactions sent .......................................................................... 136

F.2.4 DRR settlement transactions received .................................................................... 138

F.2.5 DRR trailer ............................................................................................................... 139

F.2.6 DRR Record table index .......................................................................................... 139

F.3 Monthly Statistics Report (MSR) ................................................................................. 140

F.3.1 MSR header ............................................................................................................. 140

F.3.2 MSR body: statistics on transactions sent .............................................................. 140

F.3.3 MSR body: statistics on transactions received ....................................................... 142

F.3.4 MSR trailer .............................................................................................................. 143

F.3.5 MSR Record table index .......................................................................................... 143

APPENDIX G INTERFACES TO SUPPORTED NETWORKS ......................................................... 144

APPENDIX H SCT ROUTING TABLE ......................................................................................... 145

H.1 The STEP2 SCT Routing Table ...................................................................................... 145

H.2 How to read the table .................................................................................................. 145

H.3 Status used in the Routing Table ................................................................................. 145

H.4 Payment Type Allowed ................................................................................................ 146

H.5 The Routing Table File (FileAct upload) ...................................................................... 146

H.6 SCT Direct Participant Routing Table .......................................................................... 147

H.6.1 Header row .............................................................................................................. 147

H.6.2 Search Criteria header row 1 .................................................................................. 147


H.6.4 Search criteria ......................................................................................................... 147

H.6.5 Results header row 1 .............................................................................................. 147


H.6.7 Results row ............................................................................................................. 148

H.7 SCT Indirect Participant Routing Table ....................................................................... 149

H.7.1 Header row .............................................................................................................. 149



H.7.4 Search Criteria results ............................................................................................. 149



H.7.7 Results row ............................................................................................................. 150

APPENDIX I ERROR CODE REFERENCE LIST .......................................................................... 151

I.1 File Level Codes ........................................................................................................... 151

I.2 Bulk Error codes ........................................................................................................... 152

I.3 Transaction level Error Codes ...................................................................................... 153



Version 20111121 (RB5.0) ix of 154

TABLE INDEX

Table 1-1 Glossary __________________________________________________________________ 14

Table 2-1 Connection via a STEP2-enabled payment system ________________________________ 20

Table 4-1 STEP2 XML definitions _______________________________________________________ 32

Table 4-2 STEP2 Duplicate Checking ___________________________________________________ 35

Table 4-3 Use of Instructing and Instructed Agent ________________________________________ 38

Table 4-4 - CR/DB Agent in pacs.002S2 _________________________________________________ 39

Table 4-5 Input Credit File (ICF) XML Header Elements ____________________________________ 41

Table 4-6 Credit Validation File (CVF) XML Header Elements ________________________________ 42

Table 4-7 Settled Credit File (SCF) STEP2 File Header ______________________________________ 43

Table 4-8 Cancelled Credit File (CCF) STEP2 File Header ___________________________________ 44

Table 4-9 Payment Cancellation File (PCF) STEP2 File Header _______________________________ 44

Table 4-9 SCT Credit Transfer (pacs008) Bulk Header _____________________________________ 47

Table 4-10 SCT Credit Transfer (pacs.008) Individual Transaction ____________________________ 60

Table 4-11 SCT Payment Cancellation Request (camt.056) Bulk Header _______________________ 62

Table 4-12 SCT Payment Cancellation Req (camt.056) – Individual Credit Transfer Cancellation Instruction _________________________________________________________________________________ 72

Table 4-13 – SCT Resolution of Investigation (camt.029) – Bulk Header _______________________ 73

Table 4-14 - SCT Resolution of Investigation (camt.029) - Individual Transaction Details _________ 84

Table 4-15 SCT Reject (pacs.002S2) in CVF, CCF and PCF Bulk Header ________________________ 85

Table 4-16 SCT Reject (pacs.002S2) in CVF, CCF and PCF - Original Group Information And Status _ 87

Table 4-17 SCT Reject (pacs.002S2) in CVF, CCF and PCF – Individual Transaction ______________ 90

Table 4-18 SCT Return (pacs.004) Bulk Header ___________________________________________ 92

Table 4-19 SCT Return (pacs.004) Individual Transaction__________________________________ 107

Table 4-20 ICF Naming & Structure Validation ___________________________________________ 113

Table 4-21 CRR Header _____________________________________________________________ 121

Table 4-22 CRR Debit Party __________________________________________________________ 121

Table 4-23 CRR Debit Party – field contents ____________________________________________ 122

Table 4-24 CRR Debit Party trailer ____________________________________________________ 122

Table 4-25 CRR Credit Party _________________________________________________________ 122

Table 4-26 CRR Credit Party – field contents ____________________________________________ 122

Table 4-27 CRR Credit Party trailer ____________________________________________________ 123

Table 4-28 CRR trailer ______________________________________________________________ 123

Table 4-29 DRR header _____________________________________________________________ 124

Table 4-30 DRR files/bulks/transactions sent header ______________________________________ 125

Table 4-31 DRR files/bulks/transactions sent header – field contents ________________________ 129

Table 4-32 DRR Credit Transfer bulks sent body _________________________________________ 129

Table 4-33 DRR Credit Transfer bulks sent body – field contents ____________________________ 130

Table 4-34 DRR Return bulks sent body ________________________________________________ 130

Table 4-35 DRR Return bulks sent body – field contents ___________________________________ 131

Table 4-36 DRR PCR bulks sent body __________________________________________________ 132

Table 4-37 DRR PCR bulks sent body – field contents _____________________________________ 132

Table 4-38 DRR ROI bulks sent body __________________________________________________ 133

Table 4-39 DRR ROI bulks sent body – field contents _____________________________________ 133

Table 4-40 DRR files/bulks/transactions sent trailer ______________________________________ 133

Table 4-41 DRR bulks received header _________________________________________________ 133

Table 4-42 DRR bulks received header – field contents ____________________________________ 134

Table 4-43 DRR Credit Transfer bulks received body ______________________________________ 134

Table 4-44 DRR Credit Transfer bulks received body – field contents ________________________ 135

Table 4-45 DRR Return bulks received body ____________________________________________ 135

Table 4-46 DRR Return bulks received body – field contents _______________________________ 135

Table 4-47 DRR PCR bulks received body_______________________________________________ 135



Version 20111121 (RB5.0) x of 154

Table 4-48 DRR PCR bulks received body – field contents _________________________________ 136

Table 4-49 DRR ROI bulks received body _______________________________________________ 136

Table 4-50 DRR ROI bulks received body – field contents__________________________________ 136

Table 4-51 DRR bulks received trailer __________________________________________________ 136

Table 4-52 DRR settlement transactions sent header _____________________________________ 136

Table 4-53 DRR settlement payments sent header – field contents __________________________ 137

Table 4-54 DRR transactions sent body ________________________________________________ 137

Table 4-55 DRR settlement payments sent body – field contents ____________________________ 137

Table 4-56 DRR settlement transactions sent trailer ______________________________________ 137

Table 4-57 DRR settlement payments received header ____________________________________ 138

Table 4-58 DRR settlement transactions received header – field contents _____________________ 138

Table 4-59 DRR settlement transactions received body ____________________________________ 138

Table 4-60 DRR settlement transactions sent body – field contents __________________________ 139

Table 4-61 DRR settlement transactions received trailer ___________________________________ 139

Table 4-62 DRR trailer ______________________________________________________________ 139

Table 4-63 MSR header _____________________________________________________________ 140

Table 4-64 MSR transactions sent header ______________________________________________ 141

Table 4-65 MSR Credit Transfers sent body _____________________________________________ 141

Table 4-66 MSR Returns sent body ____________________________________________________ 141

Table 4-67 MSR PCRs sent body ______________________________________________________ 141

Table 4-68 MSR ROIs sent body ______________________________________________________ 141

Table 4-69 MSR transactions sent trailer _______________________________________________ 141

Table 4-70 MSR transactions received header ___________________________________________ 142

Table 4-71 MSR Credit Transfers received body__________________________________________ 142

Table 4-72 MSR Returns received body ________________________________________________ 142

Table 4-73 MSR PCR received body ___________________________________________________ 142

Table 4-74 MSR ROI received body ___________________________________________________ 142

Table 4-75 MSR transactions received trailer ____________________________________________ 142

Table 4-76 MSR trailer ______________________________________________________________ 143



Version 20111121 (RB5.0) 11 of 154

1. INTRODUCTION

1.1 Purpose and scope of Document

This document is the Interface requirements for an EBA CLEARING STEP2 Credit Transfer service (SCT) compliant with the SEPA Credit Transfer Rulebook.

1.2 References

Document Number Title Issued By [1] EPC125-05 SEPA Credit Transfer Scheme Rulebook

Version 5.0 November 2010 EPC

[2] EPC115_06 SEPA Credit Transfer Scheme Implementation guidelines Version 5.0 November 2010

EPC

[3] EPC170-05 Framework for the Evolution of the Clearing and Settlement of Payments in SEPA – Including the Principles for SEPA Scheme Compliance and Re-statement of the PE-ACH Model (“PE-ACH/CSM Framework”).

EPC

[4] ISO 13616 IBAN: International Bank Account Number (Standard) ISO [5] SIG 203 IBAN Standard Implementation Guidelines ECBS [6] ISO 3166 Country Codes ISO [7] ISO 4217 Currency code List ISO [9] ISO 9362 Bank Identifier codes ISO [10] ISO 20022 Financial services – Universal Financial Industry message

scheme ISO

[11] EPC 190-05 SEPA Data Model EPC [12] A Glossary of Terms Used in Payments and Settlement

Systems

Bank for International Settlements

[13] The Interbank Convention on Payments EPC [14] The Cross-border Credit Transfer Convention EPC [15] EPC-0265/03 EPC Resolution on Receiver Capability EPC [16] EPC027-06 SEPA Credit Transfer Adherence Agreement EPC [17] EPC041-10 V 0.3 Errata Implementation Guidelines EPC [18] STEP2 Technical Configuration EBA CLEARING

1.3 SEPA Credit Transfer Service Requirements

The service is compatible with the SEPA Credit Transfer Scheme Rulebook and Implementation guidelines version 5.0(), using the ISO 20022 Standards.



Version 20111121 (RB5.0) 12 of 154

1.4 Glossary

The following terms are presented alphabetically. A bold word or phrase in the Meaning section indicates that the word or phrase is a term also explained within this glossary.

Term Meaning

ACL Access Control List. List of users or groups of users associated with an object (such as a file or database table) that controls the actions that can be performed on the object by the users or groups of users in the ACL.

Automatic Routing The process by which the Central System automatically chooses the Direct Participant who will be the Receiver of a payment instruction based on:

• The beneficiary bank (Creditor Agent) of the payment instruction, and

• The Direct Participant who is sending the payment instruction to STEP2 in an ICF.

Batch Reporting Time The time at which an External Settlement Mechanism is expected to transmit the results of settlement processing to the STEP2 Central System. Under normal circumstances, the batch reporting time is equal to the Settlement Cut-Off Time, but this may be changed by a Business Control Override or by the External Settlement Mechanism under exceptional circumstances.

Batch Settlement A group of Settlement Instructions transmitted to an External Settlement Mechanism in bulk in one message.

Batch Settlement Reference The unique reference number automatically associated with a Batch Settlement by the Central System.

BIC Bank Identification Code. SWIFT standard for identification of banks within payment instructions.

Bilateral Gross Settlement The process of calculating amounts to be settled whereby each party, A, pays every other party, B (where B does not equal A), the sum of the amounts of all payment instructions to be settled where the A is the debtor and the B is the creditor.

Business Control The function within EBA that controls the business operation of STEP2. Business Control Override Central System functions that may be used by Business Control to

change the times at which processing deadlines are enforced. Cancelled Credit File A STEP2-standard file of payment instructions that have been cancelled by

the relevant External Settlement Mechanism and are returned by the STEP2 Central System to the Direct Participant who was the Sender of the ICF in which the cancelled payment instructions were delivered to the Central System. CCFs are only transmitted in exceptional circumstances.

CCF See Cancelled Credit File. Central System Processing engine used to perform all STEP2 processing activities. CET Central European Time. CEST Central European Summer Time CICS Customer Information Control System. An IBM product that implements an

execution environment for transaction processing. Credit Validation File A STEP2-standard file transmitted by the Central System to the Direct

Participant in response to an ICF that contains information regarding the success or failure of the application of Validation Rules to that ICF.

CRR See Cycle Reconciliation Report CS Central System CVF See Credit Validation File Cycle Reconciliation Report Report transmitted to every Direct Participant by the Central System

following the completion of the last Settlement Cycle for a Settlement Date that includes summary information to assist reconciliation.

Daily Reconciliation Report Report transmitted daily to every Direct Participant by the Central System for a Settlement Date that includes summary information to assist reconciliation.

Dataset A names set of records stored or processed as a unit on the IBM OS/390 file system.



Version 20111121 (RB5.0) 13 of 154

Term Meaning

DB2 Relational database platform on IBM OS/390 systems. Direct Participant A bank that may directly transmit files to and directly receive files from the

Central System. DRR See Daily Reconciliation Report. External Settlement Mechanism

External processing system used by STEP2 to process the settlement obligations arising from its processing of bulk payment processing Services.

File Transfer Protocol International standard protocol for the exchange of files between two computers connected via a network.

FileAct A service of SWIFTNet for the secure transmission of files. FIN Secure global network operated by SWIFT. FTP See File Transfer Protocol. GMT Greenwich Mean Time. ICF See Input Credit File. Indirect Participant A bank known to the Central System that may receive files payment

instructions from the Central System via the services of a Direct Participant.

Input Credit File A STEP2-standard file that is used to transmit payment instructions for processing from Direct Participants to the Central System.

Instructed Agent SWIFT Bulk Payments Modeling Group equivalent of receiving bank. Definition:

“Clearing agent that is instructed by a previous clearing agent about a (file of) payment instruction(s)”

Instructing Agent SWIFT Bulk Payments Modeling Group equivalent of sending bank. Definition:

“Clearing agent that prepares the (file of) payment instructions and forwards it to the next party in the payment chain.”

Monthly Statistics Report Report can be (optionally) transmitted to a Direct Participant by the Central System following the completion of the last Settlement Cycle of the last Settlement Date for a calendar month that includes statistical information to assist charging.

MQ Series Queue-based transactional middleware supplied by IBM. MSR See Monthly Statistics Report. OFR See Original File Reference. Operational Control The function within SIA that controls the technical operation of STEP2. Original File Reference The Sender’s File Reference for an ICF when this ICF is referred to

within a related file, e.g. the Original File Reference in a CCF refers to the SFR of the ICF in which the Central System accepted the payment instructions cancelled within the CCF.

OS/390 Current operating system for IBM mainframe platforms. Payment Cancellation Request

An instruction sent by a Direct Participant to STEP2 to Cancel a previously sent Credit Transfer instruction or to initiate a Recall of Credit Transfer Procedure.

Push Mode Operating mode of STEP2’s secure networks whereby Direct Participants receive files unsolicited from the Central System.

PCR See Payment Cancellation Request PCF Payment Cancellation File – The file can be (optionally) transmitted to a

Direct Participant by the Central System following the completion of each Settlement Cycle reporting pre and post settlement cancellations

RACF Resource Access Control Facilities. The security server for the IBM mainframe platform.

Recall Procedure The Debtor Agent requires a Recall of a previously settled Credit Transfer sending a Payment Cancellation Request (camt.056) message to the Creditor Agent, which could answer positively with a Return (pacs.004) or negatively with a Resolution of Investigation (camt.029)

Receiver The receiver of a file is the Direct Participant to whom the Central System directly transmits the file (and whose BIC is the in the Receiving Institution field of the file header). The receiver of a payment instruction within a file is the receiver of the file within which the payment instruction is contained.

Resolution of Investigation Negative answer to a Recall of a credit transfer ROI See Resolution of Investigation



Version 20111121 (RB5.0) 14 of 154

Term Meaning

Routing The process of selecting a Receiver for a payment instruction. SCF See Settled Credit File. Security Support Provider Interface

Microsoft Windows 2000 component providing flexible support for different security mechanisms.

Sender The sender of a file is the Direct Participant from whom the Central System directly receives the file (and whose BIC is the in the Sending Institution field of the file header). The sender of a payment instruction within a file is the sender of the file within which the payment instruction is contained.

Sender’s File Reference Unique reference allocated to every STEP2-standard file. Sending Cut-Off Time The after which ICFs transmitted to the Central System will either be

rejected or processed in the following Settlement Cycle. Service A processing facility offered by STEP2, e.g. €-denominated, cross border

credit transfers. Service Identifier Three-character identifier used to uniquely identify each STEP2 Service, e.g.

“SCT”. Settled Credit File A STEP2-standard file of payment instructions that have been successfully

processed by the relevant External Settlement Mechanism and are transmitted by the Central System to the receiving Direct Participant.

Settlement BIC The BIC by which a Direct Participant is known in an External Settlement Mechanism.

Settlement Cut-Off Time The time at which the Central System expects responses to Settlement Instructions transmitted to an External Settlement Mechanism. Under normal circumstances, the Settlement Cut-Off Time is equal to the Batch Reporting Time.

Settlement Cycle One complete processing cycle for a Service beginning with the acceptance and validation of ICFs and concluding with the transmission of the resulting SCF and CRR (and possibly, under rare circumstances, CCFs). The final Settlement Cycle for a Settlement Date concludes with the additional transmission of DRRs to Direct Participants. The final Settlement Cycle for a Settlement Date on the last operating day of a calendar month concludes with the additional transmission of MSRs to Direct Participants who wish to receive them.

Settlement Date The date on which the value of a payment instruction must be debited from the account of the sending Direct Participant within the External Settlement Mechanism and credited to the account of the receiving Direct Participant in the External Settlement Mechanism.

Settlement Instruction An instruction sent by the Central System to External Settlement Mechanism to debit the account of one specified participant and credit the amount of another specified participant by a specified amount.

Settlement Instruction Reference

A unique reference allocated to each Settlement Instruction by the Central System.

Settlement Time The time at which the Central System transmits Batch Settlements to an External Settlement Mechanism.

SIA-SBB Società Interbancaria per l’Automazione S.p.A. The company that operates STEP2 on behalf of EBA.

SIANet Secure global IP network operated by SIA-SSB. SSPI See Security Support Provider Interface. SWIFTNet Secure global IP network operated by SWIFT. TARGET Trans-European Automated Real-time Gross settlement Express Transfer

system. The EU-wide system for the settlement of euro-denominated gross payments in euro.

Transaction Identification A unique reference number used to uniquely identify each payment instruction.

Validation Rules A set of rules enforce by the Central System on the structure and content of payment instructions and ICFs.

XML Extensible Mark-up Language. Language that is used to specify information exchange formats and in which the SWIFT Bulk Processing Modeling Group standards are written.

z/Series Hardware architecture for IBM mainframe computers.

Table 1-1 Glossary



Version 20111121 (RB5.0) 15 of 154

1.5 XML Schema Versions

This document is compatible with the following version of the XML Schemas: • camt.029.001.03 • camt.056.001.01 • pacs.002.001.03S2 • pacs.004.001.02 • pacs.008.001.02



Version 20111121 (RB5.0) 16 of 154

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 SCT supports Credit Transfers in XML format, as per the ISO20022 Payments Standards. The validation rules for these formats are also specified in the appendices of this document. The business level messages in the SEPA Credit Transfer service do not match one to one with the ISO20022 XML Messages, as some XML messages are used for more than one purpose, e.g. the pacs.002 Payment Status message. This message is used by STEP2 to reject messages and to give information about the failure of settlement.

Sender Business Level message

according to the Scheme

File Type XML

Message used

XML

Message Description

Bank to STEP2

Credit Transfer Payment Cancellation Request / Payment Recall Return / Positive Answer to CT Recall Negative Answer to a CT Recall

Input Credit File (ICF) pacs.008 camt.056 pacs.004 camt.029

FI to FI Customer Credit Transfer Payment Cancellation Request Payment Return Resolution of Investigation

STEP2 To Sending Bank

Confirmation / Rejection of messages received

Credit Validation File (CVF) pacs.002S2 Payment Status Report

STEP2 To Sending Bank

Settlement Cancellation Messages

Cancelled Credit File (CCF) pacs.002S2 Payment Status Report

STEP2 To Receiving Bank

Notification of Credit Transfer

Settled Credit File (SCF) pacs.008

FI to FI Customer Credit Transfer



Version 20111121 (RB5.0) 17 of 154

Sender Business Level message

according to the

Scheme

File Type XML

Message

used

XML

Message

Description

Return / Positive Answer to CT Recall Payment Recall Negative Answer to a CT Recall

pacs.004 camt.056 camt.029

Payment Return Payment Cancellation Request Resolution of Investigation

STEP2 To Direct Participants

Machine Readable Report Cycle Reconciliation Report (CRR)

NA NA


Payment Status Payment Cancellation File (PCF) Pacs.002S2 Payment Status Report


Machine Readable Report Daily Reconciliation Report (DRR)

NA NA


Machine Readable Report Monthly Statistical Report (MSR) NA NA


Routing Table Routing Table File (RTF) NA NA

Figure 2-1: SCT File types

This is shown diagrammatically in figures 2-2 to 2-5 below.

Figure 2-2: Bulk Types in ICF file sent to STEP2

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



Version 20111121 (RB5.0) 18 of 154

Figure 2-3

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

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

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



Version 20111121 (RB5.0) 19 of 154

2.2 Connecting to STEP2 as a Direct Participant

Direct participants connect to STEP2 as the following: � 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 (Direct Participant Web Station, or DPWS). 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. 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 originating/beneficiary bank is a Direct Participant; � Indirectly – where the originating/beneficiary 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 directly with STEP2. The architecture of this option is shown in Figure 2-7: Connection via a STEP2-enable payment system.

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

STEP2 Central System

Network1,7

1,2,3,4,7

Direct ParticipantPayment System(s)

1,7

1,2,3,4,7

WebstationInterface 5 6



Version 20111121 (RB5.0) 20 of 154

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-enabled payment system

2.3 STEP2 SCT File Types

2.3.1 Input Credit File (ICF)

Direct participant’s systems must transmit transactions to the central system in Input Credit Files (ICF). Each ICF must have a unique Sender’s File Reference (SFR). The precise format required for an ICF is specified in the Appendices. Direct participants need not transmit ICFs to the Central System for every settlement cycle. However, a configurable maximum number of ICFs per Direct Participant per settlement cycle is enforced by the STEP2 central system. Immediately upon receipt of an ICF by the STEP2 central system the network returns a network acknowledgement of receipt (ACK or Delivery Notification) 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 Credit Validation File (CVF)

Irrespective of the result of validation, one and only one Credit Validation File (CVF) is returned per transmitted ICF to the sending Direct Participant indicating the success or otherwise of the validation process. The structure of a CVF and the range and meaning of errors codes are defined in the Appendices. Direct participants which receive a CVF indicating complete acceptance of the file do not need to take any further action for settlement. Direct participants receiving CVFs that indicate complete rejection or partial acceptance of a file should consult the details of the CVF, correct the error(s) and retransmit the entire file, bulk or erroneous credit transfers instructions only, as appropriate. In case of complete rejection of an element (not partial acceptance), the same reference can be reused when resending the transaction, bulk or file as it has not been stored by the Central System. Note that CVFs indicating complete acceptance do not contain any specific rejected transactions. CVFs indicating partial acceptance of an ICF will contain specific rejected transactions. CVFs indicating complete rejection of an ICF may contain specific rejected credit transfer instructions only if all the credit



Version 20111121 (RB5.0) 21 of 154

transfers have been rejected individually; under these circumstances, the rejected transactions in the CVF give the user information to enable diagnosis of the problem.

2.3.3 Settled Credit File (SCF)

Settled transactions will be delivered to the relevant counterparty Direct Participant in a SCF after settlement of the transaction is completed. The structure of a SCF and the contents are defined in the Appendices. Direct participants receiving a SCF are notified of all the Credit Transfers and Returns that were successfully settled for the last settlement cycle for which they are the counterparty. The number of SCF to be received by a DP is configurable as a participant configuration parameter from 1 to 3 as follows:

1. One SCF if the direct participant wants to receive all its transactions in one file (transactions for the direct participant, transactions for its indirect participants, returns)

2. Two SCF if the direct participant wants to split in one side all the direct participant transactions (included direct participant returns) and in the other side indirect participants transactions (included indirect participants’ returns)

3. Three SCF if the direct participant wants to have in one hand all credit transactions from the direct participant and in the other hand all credit transactions from its indirect participants and in a third file all the returns received for the direct participant and its indirect participants.

SCF files may be split into several different files when service configuration limits are exceeded for: • number of bulks per file • the total number of transactions per bulk • the file exceeds the network limit for a file to be transmitted.

SCF Files will also be used to carry information regarding the Recall of a Settled Credit transfer. In this case an SCF file could also contain the following message types: camt.056 and camt.029. These messages are not relevant to settlement as they do not cause a money transfer between counterparts.

2.3.4 Cancelled Credit File (CCF)

Originating Direct Participants are notified of any cancelled instructions at settlement level via a CCF. The structure of a CCF and the contents are defined in the Appendices.

2.3.5 Payment Cancellation File (PCF) - Optional

The File is generated and sent to the Direct Participant only if the participant explicitly requires to receive the file. The file is sent after each settlement cycle if the Direct Participant has sent at least one PCR (camt.056) message in the previous validation window that precedes the current settlement cycle, otherwise the file will not be generated even if the DP is configured to receive it. The structure of a PCF and the contents are defined in the Appendices.

2.3.6 Routing Table File (RTF)

The routing table file consists of the Direct and Indirect Participant lists sent to all STEP2 Direct Participants to allow them to implement an automated handling of the information in their backoffice applications. These are a total of two files sent, one with the Direct Participant list and one for the Indirect Participant list.



Version 20111121 (RB5.0) 22 of 154

The RTF are sent monthly to the STEP2 Direct Participants according to a calendar published by EBA Clearing (see EBA Clearing website for details).

2.3.7 Reports Files

2.3.7.1 Reception of reconciliation and statistical reports

Following transmission of settlement results, information to assist reconciliation is forwarded by STEP2 to Direct Participants. There are three forms of reconciliation information.

1. Cycle reconciliation report; 2. Daily reconciliation information; and 3. Optional monthly statistics information. These reports are service specific, e.g. one report per service will be made available.

2.3.7.2 Cycle Reconciliation Report (CRR)

The Cycle Reconciliation Report will include the data to allow Participant reconciliation in terms of amounts debited and credited for the relevant settlement cycle. This file is sent by the Central System at the end of each settlement cycle in a window specified during the daily cycle. The structure of a CRR and the contents are defined in Appendix F.1

2.3.7.3 Daily Reconciliation Report (DRR)

The Daily Reconciliation Report will include 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 during the output phase in a window specified at the end of the daily cycles. The structure of a DRR and the contents are defined in Appendix F.2.

2.3.7.4 Monthly Statistical Report (MSR)

The Monthly Statistical Report will include the data to allow Participant statistical reconciliation in terms of transactions sent and received and in terms of amounts debited and credited. The file will be transmitted following the close of the last settlement cycle of the last Target day of each month, following the opening of the processing for first Target day of the next month. The structure of a MSR and the contents are defined in Appendix F.3. 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.



Version 20111121 (RB5.0) 23 of 154

3. STEP2 FILE EXCHANGE FUNDAMENTALS

3.1 STEP2 SCT Timetable

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 and during normal business (TARGET) days, received files are subject to ‘deferred validation’, meaning that STEP2 will validate and send responses once the service re-opens. The STEP2 Credit service will support payment warehousing that consists of credits and returns sent a number of days ahead of value date, the number of days dependent on the business requirement of the User Community. File cancellation or individual credit cancellation within a file, for those held in storage prior to the start of the relevant processing cycle will be available through the use of the ISO20022 Payment Cancellation Request (camt.056) message format. PCR message could also be used after settlement cycle of CT, in this case the message is forwarded to the counterpart (Creditor Bank) which can accept the Recall of the CR with a Return Message (pacs.004) or reject it with a Resolution of Investigation message (camt.029). The service consists of a number of processing and settlement cycles per day. They will have an Opening Time, after which files will be accepted to start up processing; included files received for the next processing cycle stored in secure environment and all the credits stored in the data warehousing with the same value date of the processing day. During the last settlement cycle of the day, after the sending cut-off, the system will start validating files for the next business date (target days only). This applies also in the case the last settlement cycle of the day is an optional settlement cycle.

3.2 STEP2 SCT Settlement Cycles

Details on the number of Settlement Cycles and precise timings will be documented as parameters within the Service Overview document. Settlement of validated transactions will occur in a specific settlement cycle in the day depending on Debtor and Creditor Agent configuration. Transactions will be settled in the first settlement cycle where both agents are configured to settle. During validation, if there are no more available cycles for both agents in the business date, the transaction will be rejected within the CVF file. After settlement cancellation, the transaction will be automatically resubmitted to the next available settlement cycle. If no more cycle are available for settlement of both debtor and creditor agents, the transaction will be cancelled within a CCF file sent to debtor agent. If the system is configured to have the last settlement cycle of the day as a mandatory cycle, the CCF files are always generated after this cycle, whereas if the last settlement cycle is optional the CCF files may be generated after different cycles depending on participant configurations regarding the settlement cycles.

3.3 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



Version 20111121 (RB5.0) 24 of 154

system whose security credentials are found to be in less than perfect order are immediately rejected and no further processing is performed.



Version 20111121 (RB5.0) 25 of 154

3.4 File formats, naming conventions, and format versioning

STEP2 SCT 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.5 File Naming Conventions

3.5.1 Network File Names

The Network File Name is the identifier of the file as it is transferred over the file exchange. 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 and text format for reports); SSS is the three character service identifier, SCT in this case; 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 = ICF; � V = CVF; � N = SCF; � C = CCF; � L = PCF; � R = CRR; � D = DRR � M = MSR � T = RTF

All Direct Participants sending files to the STEP2 central system must adopt this convention. The X…X field is not validated. The STEP2 central system generates files with X…X fields as follows: YYMMDDHHMMSSNNN, where: YYMMDDHHMMSS, which is the file creation date and time, and



Version 20111121 (RB5.0) 26 of 154

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.5.1.1 Routing Table File (RTF) FileName convention

In the case of the RTF, the first character of the incremental number (NNN) will be either: ‘D’ – to identify a Direct Participant Routing Table ‘I’ – to identify an Indirect Participant Routing Table

3.5.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 Credit File (ICF) • V – Credit Validation File (CVF) • N – Settled Credit File (SCF) • C – Cancelled Credit File (CCF) • L – Payment Cancellation File (PCF) • R – Cycle Reconciliation Report (CRR) • D – Daily Reconciliation Report (DRR) • M – Monthly Statistics Report (MSR) • T – Routing Table File (RTF)

SSS is the three-character service identifier, e.g. “SCT”;

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



Version 20111121 (RB5.0) 27 of 154

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.

3.6 File format and bulks

Input Credit Files (ICF), Credit Validation File (CVF), Settled Credit Files (SCF) and Payment Cancellation Files (PCF) 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 and one or many messages; • Bulks can only contain a single type of message (ex: Credit Transfers, Returns or Payment

Cancellation Request) • Bulks always have a unique identifier (Message Identifier); • Messages in a Credit Transfer 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 ICF file by Banks according to the XML Schema in a particular order:

1. Credit Transfers; 2. Payment Cancellation Request/Recall; 3. Returns/Positive Answer to Recall; 4. Resolution of Investigation/Negative Answer to Recall.

The order of bulks in files created by STEP2 CS is the one defined in the files XML Schema. There will be a total maximum number of bulks per files, both received and sent (all types of bulks, see STEP2 SEPA Credit Transfer Overview document). The maximum number of bulks per file as well as the total number of transactions per bulk (Credit Transfer and R-messages) are Central System parameters. STEP2 CS output files may be split into several different files when these limits are exceeded. Output files may also be split into several different files when the size of the file exceeds the network limit for a file to be transmitted. To calculate the file size, the size of every transaction inserted into the file is added considering a fixed hardcoded average value for the transaction size.

3.7 XML Schemas

The STEP2 SCT 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 banks’ participant systems can perform validation using the same schema, to verify messages being exchanged. This can 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 SCT will be performed using the STEP2 SCT schemas. Direct Participants will be expected to validate outgoing messages against these STEP2 SCT schemas and not, for example, the ISO schemas.



Version 20111121 (RB5.0) 28 of 154

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 (error code R10). 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. The STEP2 schemas are a variant of the ISO 20022 schemas. They have been created by:

• Taking the original ISO20022 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 though a coded check.

3.8 Validation of Input Credit Files

Once received by the STEP2 central system, ICFs are validated during STEP2 real time validation 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 (creation date & time and correct network identifiers) and network file name are checked;

2. Structural integrity verification, during which the basic structure and content of the ICF is verified against the schemas;

3. Duplicate removal, during which the ICF’s details are compared against the details of files already held by the STEP2 central system;

4. Bulk validation, during which the individual bulks contained within the ICF are validated against the validation rules for bulks; and

5. Transaction validation, during which the individual transactions contained within the ICF 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 ICF 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. If a bulk is found to be invalid, it is rejected in its entirety and no further validation or processing is performed on the bulk or any transaction 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 limit (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 limit, the bulk is assumed to be completely faulty and is rejected in its entirety and no further validation or processing is performed on it or any of the remaining transactions it contains.

3.9 BIC Validation



Version 20111121 (RB5.0) 29 of 154

STEP2 checks the destination BIC against the Routing Table. In the case of a Return, considerable time may have elapsed between the settlement of a Credit Transfer and the Refund. 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 Return is therefore routed to the correct BIC. Note that this lookup will not apply to Credit Transfers Messages, which should be submitted with the correct BIC in the first place.



Version 20111121 (RB5.0) 30 of 154

3.10 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 Credit Transfers, the Instructed Agent is found using the Creditor Agent BIC. For Returns, the Instructed Agent is found using the Original Debtor Agent BIC contained in the copy of the original Credit Transfer being returned.

3.10.1 Routing process

The Routing of Credit Transfers, Returns, Payments Cancellation Req and Resolution of Investigation messages is a step of validation process which establishes the DP to be credited for this instruction. The routing process for Credit Transfers and Payment Cancellation Requests (Debtor Side) acts as follows:

1. The Direct Participant routing table of the service being processed is consulted. If a matching for the Creditor 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 Creditor Agent of the transaction; otherwise

2. The Indirect Participant routing table of the service being processed is consulted. If a matching for the Creditor Agent BIC of the transaction being routed is found within this table then:

• Transaction Routing = “IND”,

• Instructed Agent = the Direct Participant associated through the Indirect Participant routing table with the Indirect Participant identified in the Creditor Agent field of the transaction being routed; otherwise

3. The Creditor Agent is not known to the system, therefore:

• The transaction is rejected.

Note that a if a branch code is supplied in the Creditor 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. The matching process will follow the SWIFT rules for matching BIC(11) with “XXX” as the last three characters. For example, if the Creditor Agent is a BIC(11) and no exact match at BIC(11) is found in the Indirect Participant table but a matching BIC(8) (or BIC(8)+”XXX”) is found then test 2, above, will succeed and the transaction will be routed to the Direct Participant serving the matched Indirect Participant. The routing process for transactions originated from the Creditor side (Returns and Resolution of Investigation) is similar but will use the Debtor Agent BIC from the original transaction instead of the Creditor Agent BIC.



Version 20111121 (RB5.0) 31 of 154

3.11 Retransmission of output files

3.11.1 File Retransmission Requested via STEP2 CS

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.

3.11.2 File Retransmission Requested via DPWS - SwiftNet

This functionality is limited to Participants that use SwiftNet to Send/Receive files to/from STEP2 CS. Participant operator connected to DPWS may require the retransmission of STEP2 output files. The operator must use a specific DPWS user enabled to use the Retransmission Function (new User Profile). The Retransmission request must be requesterd by one user and authorized by another user (Dual Control). The Participant requesting Re-Transmission of files is completely responsible for the correct processing of possible duplicate data in their system due to the re-transmission. STEP2 CS will always re-transmit the files with the same Network File Name, Internal Sender File Reference and Data Content. More details can be found in STEP2 DPWS User Manual.



Version 20111121 (RB5.0) 32 of 154

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 4c – Four alphanumerical characters, letters are uppercase 4x – Four characters (any supported character) 4!a – Must be four alpha characters (and no less than four) in capital [3x] – Three optional characters ISODate – YYYY-MM-DD ISODateAndTime1 - YYYY-MM-DDThh:mm:ss ** CW ** - this label indicate whether the field has the “Collapse Whitespaces” setting in the XML Schema. The “Collapse Whitespaces” option could allow in the XML message fields with an extended length since the calculation of the field length is performed after applying the Collapse option.

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 Credit Transfer 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 STEP2 XML definitions

The fields have been defined by taking the ISO 20022 schema as a superset, the SEPA Credit Transfer rulebook (including the Implementation guidelines) as a subset and adding the fields requested by the Banks designing the STEP2 SCT service. The fields required by the SEPA Rulebook and Implementation guidelines are identified in yellow.

1 The timezone (Thh:mm:ss) component is optional, as defined in the definition of the XML data type.



Version 20111121 (RB5.0) 33 of 154

APPENDIX A FILE STRUCTURES AND DETAILS

A.1 STEP2 SCT BULK TYPES

A.1.1 ICF Bulk messages

The Input Credit File may contain multiple bulks. The number is set by the bank subject to a maximum threshold. Each bulk will contain the same

• Message Type, and • Interbank Settlement Date.

A.1.2 CVF Bulk messages

For each Bulk received by STEP2, one Bulk Payment Status message is returned. An ICF containing 20 Bulks, will be answered by one and one only File Validation Report containing exactly 20 Bulk Payment Status Messages. The CVF sent to the sender of the ICF contains one bulk for every bulk received from that sender. Each bulk contains the total number and value of the messages from the original bulk that were sent and passed validation.

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 SCF 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 one relationship between the Bulk messages received by STEP2 and the Bulk messages sent by STEP2.

A.1.4 CCF Bulk messages

The CCF file contains bulks corresponding to the original Credit Transfer bulks in the ICF.

A.1.5 PCF Bulk messages

The PCF file contains bulks corresponding to the original Credit Transfer bulks in the ICF.



Version 20111121 (RB5.0) 34 of 154

A.2 ICF Multiple Bulks and restrictions

Multiple bulks of the same type are allowed in the ICF file. Bulks must be sorted by value date (Interbank Settlement Date). This implies having multiple bulks in the same ICF 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 Credit Transfer instruction bulks by value date and Creditor Agents. The maximum number of bulks per file as well as the total number of instructions (Credit Transfer and R-messages) are Central System parameters.

A.3 File Content Encoding

As per the SEPA Implementation Guidelines, STEP2 SCT supports 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 STEP SCT Central System.

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; and • The identity of the party that created the reference.



Version 20111121 (RB5.0) 35 of 154

The following table gives the duplicate checking criteria for different files, bulks and transactions.

Service Message Type Reference

Number

Bank ID Date

Files SCT - File Reference Sending Institution - ICF Bulks SCT - Msg ID Instructing Agent - STEP2 generated Bulks

SCT - Msg ID STEP2 BIC -

Credit Transfers

SCT FIToFICstmrCdtTrf (pacs.008)

Transaction ID Debtor Agent

Interbank Settlement Date

Payment Cancellation Request

SCT FIToFIPmtCxlReq (camt.056)

Cancellation ID Original Debtor Agent

Processing Date

STEP2 Reject SCT FIToFIPmtStsRptS2 (pacs.002S2)

Status ID STEP2 BIC Processing Date

Return SCT PmtRtr (pacs.004) Return ID Original Creditor Agent

Interbank Settlement Date

Result of Investigation

SCT RsltnOfInvstgtn (camt.029)

Cancellation Status ID

Original Creditor Agent

Processing Date

Table 4-2 STEP2 Duplicate Checking

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. Note that the Processing Date is the actual date on which the data is being received and processed by the Central System (Camt.* messages 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 file based on the duplicate checking criteria defined in Table 4-2. 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-2 take precedence over the network based flag that may or may not be set.

A.5 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, internal or trailing spaces are allowed;

• Alpha characters are case insensitive, e.g. “reference” is the same as “REFERENCE” and “Reference”.



Version 20111121 (RB5.0) 36 of 154

For Credit Transfers (pacs.008) sent to Direct Participants, the STEP2 Central System generates Message ID of the output bulks. The format is:

FFFFFFFFFFFFFFFFNNNNNNNNNNNNNNNNNNN

First 16 chars: the file reference in which the bulk is contained; Last 19 chars: a progressive number. FFFFFFFFFFFFFFFF is the File Reference generated by CS. The details on the File Reference naming scheme can be found in Section 3.6.2. NNNNNNNNNNNNNNN is an incremental number which restarts at 000000000000001 when a new file is generated.

The Message ID of a completely rejected bulk 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.

For Returns (pacs.004) sent to Direct Participants, STEP2 Central System uses the same Message ID generation method as for the Credit Transfers. However, the Original Message Id of a Return is always the one used by the bank originating the bulk of returns and is not replaced by the Message Id of the original Credit Transfer bulk.

Figure 4-1: STEP2 SCT Original Message Id in Returns

A.6 Schema validation

The content of some XML fields is validated at the schema level. For example, fields with required value as per Credit Transfer Implementation Guidelines (ex. “SEPA” or “CLRG”) are part of the schema validation. Moreover, fields with specific data format (ex. amounts) are also validated at schema level. When this schema validation fails, the error code is always R10 and the whole file will be rejected.

BANK1 BANK2

MessageID ABC

STEP2

MessageID XYZ

CT

OrgnlMsgID XYZ

RET

OrgnlMsgID XYZ RET

CT



Version 20111121 (RB5.0) 37 of 154

A.7 Usage of Instructed and Instructing Agents

In the XML schema the Instructing/Instructed Agent fields appears at both the Group Header and the Individual transaction level. The rules for using these are described as follows. ICF

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

Camt Messages Field Level Status

Assigner Group Header Mandatory Individual Transaction Not Present Assignee Group Header Mandatory Individual Transaction Not Present

CVF

Field Level Status

Instructing Agent Group Header Not Present Individual Transaction Not Present Instructed Agent Group Header Not Present Individual Transaction Not Present

SCF

Pacs Messages Field Level Status

Instructing Agent Group Header Not Present Individual Transaction Mandatory Instructed Agent Group Header Mandatory Individual Transaction Not Present

Camt Messages Field Level Status Assigner Group Header Mandatory Individual Transaction Mandatory Assignee Group Header Mandatory Individual Transaction Not Present

CCF

Field Level Status

Instructing Agent Group Header Mandatory Individual Transaction Not Present Instructed Agent Group Header Not Present Individual Transaction Mandatory



Version 20111121 (RB5.0) 38 of 154

PCF

Field Level Status

Instructing Agent Group Header Mandatory

Individual Transaction Not Present

Instructed Agent Group Header Not Present

Individual Transaction Mandatory

Table 4-3 Use of Instructing and Instructed Agent

A.8 Recall Procedure

A new Recall procedure is introduced with the SCT Rulebook version 4.0 in 2010. The message type “pacs.006” (Request For Cancellation) has been removed from the system (and also ISO Standards) and is substituted with the message type “camt.056” (Payment Cancellation Request) to cancel Credit Transfer not yet settled. When STEP2 CS receives a camt.056 message from bank, the following situations could occur in relation to the original Credit transfer (pacs.008): A. The CT has not been yet settled B. The sending cut-off for the settlement of the pacs.008 has already been reached but settlement is

still in progress C. The settlement of the pacs.008 is finished and the CT is settled D. The settlement of the pacs.008 is finished and the CT is cancelled � In case A: the camt.056 message will be processed as currently is done for the pacs.006. The original

credit transfer will be cancelled and not forwarded to settlement. The status of the original Credit Transfer will be changed in “RFC”.

� In case B: the camt.056 message will be forwarded to the counterpart regardless of the settlement result for the original Credit Transfer. The status of the original Credit Transfer won’t be changed. In the case the CT is cancelled by settlement and is not forwarded within SCF file, the counterpart may reject the recall message with a camt.029 with reason “NOOR” (Original Credit Transfer Never Received). The camt.056 will be included in the SCF file of the next settlement cycle, not in the one generated for the settlement cycle in progress.

� In case C: the camt.056 message will be forwarded to the counterpart. The status of the original Credit Transfer won’t be changed.

� In case D: the camt.056 message will be rejected to the sending bank within a CVF file. The status of the original Credit Transfer won’t be changed

EBA STEP2 CS do not perform any matching check with the original pacs.008/camt.056 when validating camt.029 or pacs.004 messages. Only Schema and format validation are performed on these messages by STEP2 CS. Consequently, no changing of status is performed on the original pacs.008/camt.056 message after processing the recall response. Debtor Bank must trigger the Recall Procedure (with camt.056) within 10 days from CT settlement as for EPC Rulebook requirement, and Beneficiary Bank has 10 more days to answer with camt.029 or pacs.004 message from the receipt of the camt.056. No checks are performed by STEP2 CS on the elapsed period for reception of the camt.056 or camt.029 message and these messages will always be accepted (after Schema and Format positive validation) and forwarded to the counterpart. The camt.056 and camt.029 messages can be sent by Banks to STEP2 CS within ICF files. These messages will be delivered by STEP2 CS to the counterpart Bank within SCF files in the first delivery of output files phase available (for camt.056 only after pacs.008 settlement).



Version 20111121 (RB5.0) 39 of 154

Each Direct Participant may (Optionally) require (Participant Configuration) the generation and transmission of the Payment Cancellation File (PCF). The file will contain a Payment Status Report (Pacs.002S2) for each Credit Transfer object of a Recall Procedure specifying if the original CT was processed as case A, B or C above. This will allow the DP to know if the PCR has cancelled the original CT before settlement or if the PCR was forwarded to the counterpart as the original CT was already settled. Specifically, in the Transaction Details (TxInfAndSts+StsRsnInf++Rsn+++Prtry) the following values will be set:

• “CANC” = the PCR was processed before the settlement of the original Credit Transfer. The original CT was not settled.

• “RCLL” = the PCR was processed after the settlement of the original Credit Transfer. The CT has been settled/cancelled and the Recall Request was forwarded to the Beneficiary Bank of the original CT.

A.9 Usage of Creditor/Debtor Agent in pacs.002S2

The table below, describe the rules applied by STEP2 CS to set the following fields in the pacs.002S2 message in CVF files: • FIToFIPmtStsRptS2/TxInfAndSts/OrgnlTxRef/DbtrAgt • FIToFIPmtStsRptS2/TxInfAndSts/OrgnlTxRef/CdtrAgt

Message fields Money transfer

Message Type Debtor Agent

Creditor Agent

Debtor

Bank

Creditor

Bank

CT Pacs.008 (ICF) BANK1 BANK2 BANK1 BANK2

REJ of CT Pacs.002S2 (CVF) BANK1 BANK2

PCR Camt.056 (ICF) BANK1 BANK2

REJ of PCR pacs.002S2 (CVF) BANK1 BANK2

ROI Camt.029 (ICF) BANK1 BANK2

REJ of ROI pacs.002S2 (CVF) BANK1 BANK2

RET Pacs.004 (ICF) BANK1 BANK2 BANK2 BANK1

REJ of RET pacs.002S2 (CVF) BANK1 BANK2

Table 4-4 - CR/DB Agent in pacs.002S2

A.10 Setting the Settlement Cycle

Direct Participants sending ICF files may require to settle Credit transfer Bulks (pacs.008) in a specific settlement cycle setting the settlement cycle number in the following field:

GrpHdr +SttlmInf ++ClrSys +++Prtry

The format checks on the field will admit the following options:

1- “ST2” : normal setting of the field. Does not require any specific settlement cycle 2- “ST2nn” : where “nn” is the required settlement cycle in numeric format starting from ‘00’ to ‘XX’

where XX is the maximum number of settlement cycles configured in the system minus 1. Any other format will not be accepted causing the entire bulk rejection (error code B16). The following other errors may be possible when setting a specific settlement cycle:



Version 20111121 (RB5.0) 40 of 154

� The required settlement cycle for payments not in warehouse has been already completed; In this case the bulk is rejected with error code “B16”.

� The required settlement cycle is currently being processed, therefore the sending cut-off has already expired. In this case the bulk is rejected with error code “B16”.

� The Debtor and Creditor Banks are not configured to settle in the required settlement cycle. In this case, the single payment will be submitted to the next available settlement cycle (of the same settlement date) to which both Participants are configured to settle. In the case a suitable settlement cycle can not be found, the single payment will be rejected with error code “XT85”.

Whether the settlement cycle is not specified, payments will be settled in the first settlement cycle available for the specified settlement date where both participants are configured to settle.



Version 20111121 (RB5.0) 41 of 154

APPENDIX B XML FILES HEADERS

B.1 INPUT CREDIT FILE (ICF) HEADER

The STEP2 schema SctIcfBlkCdtTrf specifies the ICF.

Status Field Name XML Element Format Notes

M Sending Institution SndgInst 4!a2!a2!c It must always be the BIC of the Direct Participant sending the file.

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

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

M Service Identifier SrvcId 3!a Must be SCT

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 “ICF”.

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

M Total Number of pacs.008 Bulks

NumCTBlk 8n The total number of Credit Transfers bulks contained in the ICF.

M Total Number of camt.056 Payment Cancellation Request bulks

NumPCRBlk 8n The total number of Payment Cancellation Requests bulks contained in the ICF.

M Total Number of pacs.004 Bulks

NumRFRBlk 8n The total number of Returns bulks contained in the ICF.

M Total Number of camt.029 Result of Investigation bulks

NumROIBlk 8n The total number of Resolution of Investigation bulks contained in the ICF.

Table 4-5 Input Credit File (ICF) XML Header Elements



Version 20111121 (RB5.0) 42 of 154

B.2 XML Credit Validation File (CVF) Header

The CVF is specified by the STEP2 schema SctCvfBlkCdtTrf.

Status Field Name XML Element Format Notes

M Sending Institution

SndgInst 4!a2!a2!c The STEP2 SCT CS BIC code.

M Receiving Institution

RcvgInst 4!a2!a2!c If rejected payment instructions are present then RcvgInst will equal the Instructing Agent element in the (SWIFT) Header (which contains information from the original ICF).

M Service Identifier SrvcId 3!a The STEP2 service identifier : SCT

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

M File Type Ftype 3!a Always “CVF”.

M File Reference FileRef 16!c The STEP2 reference of the CVF.

M File Date and Time FDtTm ISODateTime

The file creation Date and Time

O Original File Reference

OrigFRef 16c In circumstances where it has not been possible to gather this information OrigFRef will not be present.

M Original File Name OrigFName 32x Original ICF File Name.

O Original Date And Time

OrigDtTm ISO Date & Time

On circumstances where it has not been possible to gather this information OrigDtTm will not be present.

M File Reject Reason FileRjctRsn 3!c The ICF reject reason code. (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 Credit Validation File (CVF) XML Header Elements



Version 20111121 (RB5.0) 43 of 154

B.3 XML Settled Credit File (SCF) STEP2 File Header

The SCF is specified by the STEP2 schema SCTScfBlkCdtTrf.

Status Field Name XML

Element

Format Notes


SndgInst 4!a2!a2!c The STEP2 CS BIC code.


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



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

M File Reference FileRef 16!c The SCF file reference

M Routing Indicator

RoutingInd 3!a The routing Indicator

DIR: Direct Participant File

IND: Indirect Participant File

ALL: Both

RET: Return 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-7 Settled Credit File (SCF) STEP2 File Header



Version 20111121 (RB5.0) 44 of 154

B.4 XML Cancelled Credit File (CCF) STEP2 File Header

The CCF is specified by the STEP2 schema SCTCcfBlkCdtTrf.


Element

Format Notes


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

The STEP2 CS BIC code.





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

M File Reference FileRef 16!c The CCF file reference



M File Cycle Number

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

Table 4-8 Cancelled Credit File (CCF) STEP2 File Header

B.5 XML Payment Cancellation File (PCF) STEP2 File Header

The PCF is specified by the STEP2 schema SCTPcfBlkCdtTrf.


Element

Format Notes


SndgInst 4!a2!a2!c The STEP2 CS BIC code.





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

M File Reference FileRef 16!c The PCF file reference



M File Cycle Number

FileCycleNo 2!n The settlement cycle in which this file was created by the STEP2 central system.

Table 4-9 Payment Cancellation File (PCF) STEP2 File Header



Version 20111121 (RB5.0) 45 of 154

APPENDIX C XML MESSAGE DEFINITIONS

C.1 STEP2 Usage of Credit Transfers (pacs.008)

This is a Credit Transfer transaction either sent by a Direct Participant to STEP2 (ICF) or by STEP2 to a Direct Participant (SCF).

C.1.1 SCT Credit Transfer (pacs.008) Bulk Header

Index XML Tag Format Status Rulebook Ref

EPC SCT Implementation Guidelines - Usage rules

STEP2 Usage Rules and Validations

1.1 GrpHdr

+MsgId

35x M NA ICF: The DP’s bulk reference.

SCF: STEP2’s bulk reference.

• Uniqueness is checked for ICF bulks: error code B14; and

• This identification cannot include leading, trailing or internal spaces (schema validation).

1.2 GrpHdr

+CreDtTm

ISODate

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

DP.

1.4 GrpHdr

+NbOfTxs

15n M NA The number of transactions included in this bulk.

• Must not be greater than the Maximum Number Of Transactions parameter: error code B02; and

• Must be the total number of transactions included in this bulk: error code B03.



Version 20111121 (RB5.0) 46 of 154

Index XML Tag Format Status Rulebook

Ref

EPC SCT Implementation

Guidelines - Usage rules


1.6 GrpHdr

+TtlIntrBkSttlmAmt

Attribute

18d

EUR

M

M

NA Mandatory

• Only ‘EUR’ is allowed.

• Amount must be 0.01 or more and 999999999999999.99 or less.

• The fractional part has a maximum of two digits.

The total amount of transactions inside this bulk.

• Values are supported with up to 15 digits in the integer part a decimal point 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; and

• Amount must be greater than zero: error code B13.

1.7 GrpHdr

+IntrBkSttlmDt

ISO DATE M AT-42 Mandatory The business date in which the transactions inside this bulk must be settled in the relevant settlement mechanism.

• IntrBkSttlmDt must be in the allowed range: error code B15.

1.9 GrpHdr

+SttlmInf

++SttlmMtd

4!a M NA Only CLRG, INGA and INDA are allowed. Information on settlement method.

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

1.11 GrpHdr

+SttlmInf

++ClrSys

+++Prtry

35x M NA Proprietary identification of the Clearing System.

• Value must be ‘ST2’ or ‘ST2nn’ , where ‘nn’ is the required settlement cycle (Ref. A.10): error code B16.

• ‘nn’ must always be in numeric format with two digits : error code B16.

• The required settlement cycle must be a suitable settlement cycle (Sending Cut-Off not already reached): error code B16.



Version 20111121 (RB5.0) 47 of 154

Index XML Tag Format Status Rulebook

Ref


Guidelines - Usage rules


1.32 GrpHdr

+InstgAgt

++FinInstnId

+++BIC

4!a2!a2!c C NA Only BIC is allowed. The DP originating this bulk.

• Must be present in ICF: error code B10; and

• Must equal SndgInst element in ICF and must not contain a branch code: error code B10.

1.33 GrpHdr

+InstdAgt

++FinInstnId

+++BIC

4!a2!a2!c C NA Only BIC is allowed. The DP receiving this bulk.

• Used only in SCF: error code B11; and

• Equals Receiving Inst element in SCF: error code B11.

Table 4-10 SCT Credit Transfer (pacs008) Bulk Header



Version 20111121 (RB5.0) 48 of 154

C.1.2 SCT Credit Transfer (pacs.008) Individual Transaction

Index XML tag Format Status

Rulebook Ref

EPC SCT Implementation Guidelines - Usage rules

STEP2 Usage Rules and Validation Rules

2.2 CdtTrfTxInf

+PmtId

++InstrId

35x O NA The Instruction Id.


2.3 CdtTrfTxInf

+PmtId

++EndToEndId

35x

**CW**

M AT-41 A customer reference that must be passed on in the end-to-end chain. In the event that no reference was given, ‘NOTPROVIDED’ must be used.

The End to End Id.

•

2.4 CdtTrfTxInf

+PmtId

++TxId

35x M AT-43 Must contain a reference that is meaningful to the Originator’s Bank and is unique over time.

The Transaction Id.

• Uniqueness is checked under the rules for duplicate checking: error code AM05; and


2.10 CdtTrfTxInf

+PmtTpInf

++SvcLvl

++Cd

4!a M AT-40 Only ‘SEPA’ is allowed. The Identification Code of the Scheme

• Must be “SEPA” (schema validation).

2.13 CdtTrfTxInf

+PmtTpInf

++LclInstrm

+++Cd

35x

**CW**

C NA Only used if bilaterally agreed between the Debtor Bank and the Creditor Bank.

The transaction Local Instrument.

• Cannot be used at the same time as Prtry (below) (schema validation); and

• The value is based on an external list and is not checked by the CS.



Version 20111121 (RB5.0) 49 of 154


Rulebook

Ref


Guidelines - Usage rules STEP2 Usage Rules and Validation Rules

2.14 CdtTrfTxInf

+PmtTpInf

++LclInstrm

+++Prtry

35x C NA The transaction Local Instrument Proprietary.

• Cannot be used at the same time as Cd (above) (schema validation);

• The value is based on an external list and is not checked by the CS;


2.16 CdtTrfTxInf

+PmtTpInf

++CtgyPurp

+++Cd

4x

**CW**

C AT-45 Depending on the agreement between the Originator and the Originator Bank, ‘Category Purpose’ may be forwarded to the Beneficiary Bank.

The Category Purpose of the transaction (ISO 20022 Code values).


• This is not checked by the CS (schema validation).

2.17 CdtTrfTxInf

+PmtTpInf

++CtgyPurp

+++Prtry

35x

**CW**

C AT-45 The Category Purpose of the transaction Proprietary.

• Cannot be used at the same time as Cd (above) (schema validation); and




Version 20111121 (RB5.0) 50 of 154


Rulebook

Ref



2.18 CdtTrfTxInf

+IntrBkSttlmAmt

Attribute

18d

EUR

M

M

AT-04 • Only ‘EUR’ is allowed.



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 exceed the Maximum Amount: error code AM02 (currently set to € 999999999,99); and

• Must be greater than “0”: error code AM01.

2.19 CdtTrfTxInf

+IntrBkSttlmDt

ISO DATE

O NA The Interbank Settlement Date

2.29 CdtTrfTxInf

+AccptncDtTm

ISO Date O NA The Acceptance Date & Time.

2.31 CdtTrfTxInf

+InstdAmt

Attribute

18d

3!a

O

M

NA The Instructed Amount

2.32 CdtTrfTxInf

+XchgRate

11d O NA The Exchange rate of the Credit Transfer.

2.33 CdtTrfTxInf

+ChrgBr

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

The Charge Bearer

•

2.35 CdtTrfTxInf +ChrgsInf ++Amt

Attribute

18d

3!a

O

M

NA The Charges Amount.

• Only one occurrence is allowed (schema validation).



Version 20111121 (RB5.0) 51 of 154


Rulebook

Ref



2.36 CdtTrfTxInf +ChrgsInf ++Pty +++FinInstnId

++++BIC

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

O NA The Charges Party.


2.37 CdtTrfTxInf + PrvsInstgAgt ++ FinInstnId +++BIC

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

O NA The Previous Instructing Agent.

2.39 CdtTrfTxInf

+InstgAgt

++FinInstnId

+++BIC

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

C NA The DP originating this Credit Transfer.

• Used in SCF only: error code XT13.

2.47 CdtTrfTxInf

+UltmtDbtr

++Nm

70x

**CW**

O AT-08 ‘Name’ is limited to 70 characters in length.

The Name of the Originator Reference Party.

2.47 CdtTrfTxInf

+UltmtDbtr ++PstlAdr

+++Ctry

2!a C

NA

Country of the Ultimate Debtor address.

2.47 CdtTrfTxInf

+UltmtDbtr ++PstlAdr

+++AdrLine

70x

**CW**

O

NA

The Ultimate Debtor address.

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



Version 20111121 (RB5.0) 52 of 154


Rulebook

Ref



2.47 CdtTrfTxInf

+UltmtDbtr ++Id

+++OrgId

See Schema

C

AT-09

Either ‘BIC or BEI’ or one occurrence of ‘Other’ is allowed.

The identification of the Ultimate Debtor: Organisation Id.

• Cannot be used at the same time as Id/PrvtId (below) (schema validation);

• Only one occurrence of Othr is allowed (schema validation);

• All of the ISO options are available (see ISO document or schema).

• Either ‘BIC or BEI’ or one occurrence of ‘Other’ is allowed.

2.47 CdtTrfTxInf

+UltmtDbtr ++Id

+++PrvtId

See Schema

C

AT-09

Either ‘Date and Place of Birth’ or one occurrence of ‘Other’ is allowed.

The identification of the Ultimate Debtor: Private Id.

• Cannot be used at the same time as Id/OrgId (above) (schema validation);



2.47 CdtTrfTxInf

+UltmtDbtr

++CtryOfRes

2!a O

NA

The Country of Residence of the Ultimate Debtor.

2.49 CdtTrfTxInf

+Dbtr

++Nm

70x

**CW**

M AT-02 ‘Name’ is limited to 70 characters in length.

The Name of the Debtor.

2.49 CdtTrfTxInf

+Dbtr ++PstlAdr

+++Ctry

2!a O AT-03 Country of the Debtor address.

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



Version 20111121 (RB5.0) 53 of 154


Rulebook

Ref



2.49 CdtTrfTxInf

+Dbtr ++PstlAdr +++AdrLine

70x

**CW**

O AT-03 Only two occurrences are allowed. The Debtor address.

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

2.49 CdtTrfTxInf

+Dbtr

++Id

+++OrgId

See schema

C AT-10 Either ‘BIC or BEI’ or one occurrence of ‘Other’ is allowed.

The identification of the Debtor (Ordering identification code): Organisation ID.

• If used, cannot be used at the same time as Id/PrvtId (below) (schema validation);




2.49 CdtTrfTxInf

+Dbtr

++Id

+++PrvtId

See schema

C AT-10 Either ‘Date and Place of Birth’ or one occurrence of ‘Other’ is allowed.

The identification of the Debtor (Ordering identification code): Private ID.

• If used, cannot be used at the same time as Id/OrgId (above) (schema validation);



2.49 CdtTrfTxInf

+Dbtr

++CtryOfRes

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



Version 20111121 (RB5.0) 54 of 154


Rulebook

Ref



2.50 CdtTrfTxInf

+DbtrAcct ++Id

+++IBAN

2!a2!n30x

M AT-01 Only IBAN is allowed. The Debtor Account IBAN.

• First two characters must be valid according to ISO 3166 and correspond to country in SEPA: error code XT73;

• The third and the fourth characters must be digits: error code XT73; and

• The IBAN Check Digit is validated as per ISO13616: error code XD19.

2.51 CdtTrfTxInf

+DbtrAgt ++FinInstnId

+++BIC

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

M AT-06 Only BIC is allowed. The Debtor Agent BIC.

• Must be an active DP or IP: error code PY01.

2.53 CdtTrfTxInf

+CdtrAgt ++FinInstnId

+++BIC

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

M AT-23 Only BIC is allowed. • The Creditor Agent BIC.Must be an active DP or IP: error code PY01.

2.55 CdtTrfTxInf

+Cdtr ++Nm

70x

**CW**

M AT-21 ‘Name’ is limited to 70 characters in length.

The Name of the Creditor.

2.55 CdtTrfTxInf

+Cdtr ++PstlAdr

+++Ctry

2!a O AT-22 Country of the Creditor address.

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

2.55 CdtTrfTxInf

+Cdtr ++PstlAdr +++AdrLine

70x

**CW**

O AT-22 Only two occurrences are allowed. The Creditor address.

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



Version 20111121 (RB5.0) 55 of 154


Rulebook

Ref



2.55 CdtTrfTxInf

+Cdtr

++Id

+++OrgId

See schema


The identification of the Creditor (Beneficiary identification code): Organisation Id.





2.55 CdtTrfTxInf

+Cdtr

++Id

+++PrvtId

See schema


The identification of the Creditor (Beneficiary identification code): Private ID.




2.55 CdtTrfTxInf

+Cdtr

++CtryOfRes

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

2.56 CdtTrfTxInf

+CdtrAcct ++Id

+++IBAN

2!a2!n30x

M AT-20 Only IBAN is allowed. The Creditor Account IBAN.

• First two characters must be valid according to ISO 3166 and correspond to country in SEPA: error code XT73;

• The third and the fourth characters must be digits: error code XT73; and

• The IBAN Check Digit is validated as per ISO13616: error code XD19.



Version 20111121 (RB5.0) 56 of 154


Rulebook

Ref



2.57 CdtTrfTxInf

+UltmtCdtr

++Nm

70x

**CW**

O AT-28 ‘Name’ is limited to 70 characters in length.

The Name of the Beneficiary Reference Party.

2.57 CdtTrfTxInf

+UltmtCdtr ++PstlAdr

+++Ctry

2!a O NA Country of the Ultimate Creditor address.

2.57 CdtTrfTxInf

+UltmtCdtr ++PstlAdr

+++AdrLine

70x

**CW**

O NA The Ultimate Creditor Address.

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

2.57 CdtTrfTxInf

+UltmtCdtr ++Id

+++OrgId

See Schemas


The identification of the Ultimate Creditor: Organisation Id.





2.57 CdtTrfTxInf

+UltmtCdtr ++Id

+++PrvtId

See Schemas


The identification of the Ultimate Creditor: Private Id.


• A Only one occurrence of Othr is allowed (schema validation);

• ll of the ISO options are available (see ISO document or schema).



Version 20111121 (RB5.0) 57 of 154


Rulebook

Ref



2.57 CdtTrfTxInf

+UltmtCdtr

++CtryOfRes

2!a O NA

The Country of Residence of the Ultimate Creditor.

2.59 CdtTrfTxInf

+InstrForCdtrAgt

++Cd

4!a O NA The Instruction for Creditor Agent (ISO20022 code).


2.60 CdtTrfTxInf

+InstrForCdtrAgt

++InstrInf

140x

**CW**

O NA The Instruction for Creditor Agent.

2.65 CdtTrfTxInf

+Purp

++Cd

4x

**CW**

C AT-44 The Purpose of the transaction (ISO20022 Code).

• Cannot be used at the same time as Proprietary (below) (schema validation); and

• Codes are based on external list definition. This is not checked by STEP2.

2.66 CdtTrfTxInf

+Purp

++Prtry

35x

**CW**

C AT-44 The Purpose of the transaction (Proprietary).

• Cannot be used at the same time as Code (above) (schema validation).

2.67 CdtTrfTxInf

+RgltryRptg

See Schema

O NA The Regulatory Reporting.

• All ISO20022 fields are supported (schema validation).

2.68 CdtTrfTxInf

+RltdRmtInf

See Schema

O NA The Related Remittance Information.

• All ISO20022 fields are supported (schema validation).



Version 20111121 (RB5.0) 58 of 154


Rulebook

Ref



2.76 CdtTrfTxInf

+RmtInf

++Ustrd

140x

**CW**

C AT-05 • ‘Unstructured’ may carry structured remittance information, as agreed between the Originator and the Beneficiary.

• Only one occurrence of ‘Unstructured’ is allowed.

Unstructured Remittance Information.

• Either Unstructured or Structured Remittance Information can be used (schema validation);

• Maximum of 10 occurrences of this field. (schema validation);

• First occurrence is yellow and optional; and • Subsequent occurrences are white and reserved

for future use. Error code: XT13.

2.77 CdtTrfTxInf

+RmtInf

++Strd

140x C AT-05 • ‘Structured’ can be used, provided the tags and the data within the ‘Structured’ element do not exceed 140 characters in length.

• Only one occurrence of ‘Structured’ is allowed.

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: XT81; and • Format is 140x for entire data in each occurrence

where the number of characters is counted between the Structured tags (not inclusive). Error Code: XT33.

2.78 CdtTrfTxInf

+RmtInf

++Strd

+++RfrdDocInf

See Schema

O AT-05 Referred Document Information.

2.86 CdtTrfTxInf

+RmtInf

++Strd

+++RfrdDocAmt

See Schema

O AT-05 Referred Document Amount.



Version 20111121 (RB5.0) 59 of 154


Rulebook

Ref



2.100 CdtTrfTxInf

+RmtInf

++Strd

+++CdtrRefInf

++++Tp

+++++CdOrPrtry

++++++Cd

4!a O AT-05 When present, the Debtor Bank is not obliged to validate the reference information.

When used both ‘Type’ and ‘Reference’ must be present.

Creditor Reference Information Type Code.

• When used both ‘Type’ and ‘Reference’ must be present (schema validation); and

• Only “SCOR” is allowed (schema validation).

2.101 CdtTrfTxInf

+RmtInf

++Strd

+++CdtrRefInf

++++Tp

+++++CdOrPrtry

++++++Prtry

35x

**CW**

O AT-05 Creditor Reference Information Type Proprietary

• When used both ‘Type’ and ‘Reference’ must be present (schema validation).

2.102 CdtTrfTxInf

+RmtInf

++Strd

+++CdtrRefInf

++++Tp

+++++Issr

35x

**CW**

O AT-05 Creditor Reference Information Type Issuer.



Version 20111121 (RB5.0) 60 of 154


Rulebook

Ref



2.103 CdtTrfTxInf

+RmtInf

++Strd

+++CdtrRefInf

++++Ref

35x

**CW**

O AT-05 • If a Creditor Reference contains a check digit, the receiving bank is not required to validate this.

• If the receiving bank validates the check digit and if this validation fails, the bank may continue its processing and send the transaction to the next party in the chain

• RF Creditor Reference may be used (ISO 11649)

Creditor Reference Information Reference.


2.104 CdtTrfTxInf

+RmtInf

++Strd

+++Invcr

See Schema

O AT-05 Invoicer.

2.105 CdtTrfTxInf

+RmtInf

++Strd

+++Invcee

See Schema

O AT-05 Invoicee.

2.106 CdtTrfTxInf

+RmtInf

++Strd

+++AddtlRmtInf

140x

**CW**

O AT-05 Additional Remittance Information.

Table 4-11 SCT Credit Transfer (pacs.008) Individual Transaction



Version 20111121 (RB5.0) 61 of 154

C.2 STEP2 usage of camt.056 (Payment Cancellation Request)

This transaction can be present in the ICF and SCF files.

C.2.1 SCT Payment Cancellation Request (camt.056) Bulk Header

Index XML Element Format Status Rulebook

Ref


Guidelines – Usage Rules


1.1 Assgnmt +Id

35x M The Identifier of the assignment.

• ICF: The DP’s assignment reference;

• SCF: STEP2 CS’ assignment reference; and

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

1.2 Assgnmt +Assgnr ++Agt +++FinInstnId ++++BIC

4!a2!a2!c M Instructing Party

Limited to BIC to identify a bank or CSM or ‘Name’ to indicate the CSM when it has no BIC.

For ICF: the DP originating this assignment.


For SCF: the STEP2 CS BIC.

1.5 Assgnmt +Assgne ++Agt +++FinInstnId ++++BIC

4!a2!a2!c M Instructed Party

Limited to BIC to identify a bank or CSM or ‘Name’ to indicate the CSM when it has no BIC.

For SCF: the DP receiving this assignment.

For ICF: the STEP2 CS BIC. Error code B12.

1.8 Assgnmt +CreDtTm

ISODate &Time

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


Ref




3.1 CtrlData

+NbOfTxs

15n M The number of transactions included in this assignment.

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



Version 20111121 (RB5.0) 62 of 154

3.2 CtrlData +CtrlSum

18d O The control Sum. Error code XT81.

Table 4-12 SCT Payment Cancellation Request (camt.056) Bulk Header

C.2.2 SCT Payment Cancellation Request (camt.056) –Individual Credit Transfer Cancellation Instruction

Multiple occurrences of Individual Cancellation can be used. Each message must match an existing Credit Transfer following the uniqueness and matching criteria provided. No matching is performed for all the transaction fields, only the CT unique identification fields are matched. Index XML Acronym Format Status Rulebook

Ref EPC SCT Implementation Guidelines – Usage Rules

STEP2 Validation Rules

4.21 Undrlyg +TxInf

See below

M NA Mandatory The copy of the transaction to be requested for cancellation.

• At least one transaction must be present (schema validation).

4.22 Undrlyg +TxInf ++CxlId

35x M AT-R7 Mandatory This element must be transported up to the Creditor Agent.

The Cancellation Identification.

• Uniqueness is checked under the rules for duplicate checking. Error code AM05; and


4.30 Undrlyg +TxInf

++OrgnlGrpInf

+++OrgnlMsgId

35x M NA The Message Identifier of the original bulk.

• In the case of SCF, the Message Identifier is the one generated by the STEP2 CS for the Original CT bulk in the original SCF.



Version 20111121 (RB5.0) 63 of 154

Index XML Acronym Format Status Rulebook

Ref


Guidelines – Usage Rules STEP2 Validation Rules

4.31 Undrlyg +TxInf

++OrgnlGrpInf

+++OrgnlMsgNmId

35x M NA Only ‘pacs.008.001.02’ is allowed. The type of XML message bulk to be cancelled.

• Must always equal to pacs.008* (use of wildcard in validation) (schema validation).

4.33 Undrlyg +TxInf ++OrgnlInstrId

35x O NA The Original instruction Identifier.


4.34 Undrlyg +TxInf ++OrgnlEndToEndId

35x

** CW **

M AT-41 Mandatory The Original End to End Identifier.

4.35 Undrlyg +TxInf ++OrgnlTxId

35x M AT-43 Mandatory The Original Transaction Id.

• Must be present in the CS Repository as for being the Tx Id of the original credit transfer transaction (pacs.008). Error code XT74;

• The status of the original transaction must not be “rejected by STEP2 CS” or “cancelled”. Error code XT75.


4.37 Undrlyg +TxInf ++OrgnlIntrBkSttlmAmt Attribute

18d

3!a

M

AT-04 Mandatory • Only ‘EUR’ is allowed. • Amount must be 0.01 or more

and 999999999.99 or less. • The fractional part has a

maximum of two digits.

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

• Must be the same as the Interbank Settlement Amount for the original credit transfer transaction (pacs.008) as stored in the STEP2 CS: error code XT77.



Version 20111121 (RB5.0) 64 of 154


Ref



4.38 Undrlyg +TxInf ++OrgnlIntrBkSttlmDt

ISO DATE

M AT-42 Mandatory The original Interbank Settlement Date.

• Must be the same date as the date of the original credit transfer transaction (pacs.008) in the CS repository. Error code XT74.

4.39 Undrlyg +TxInf ++Assgnr +++FinInstnId ++++BIC

4!a2!a2!c C NA The DP originating this assignment.

• Only used in SCF. Error code XT13

4.42 Undrlyg +TxInf +CxlRsnInf ++Orgtr +++Nm

70x

** CW **

C R2 Limited to BIC for an Agent or

‘Name’ for a non-financial institution.

The party originating the request for cancellation (customer).

• Cannot be used at the same time as Originator/BICOrBEI (see below) (schema validation).

4.42 Undrlyg +TxInf ++CxlRsnInf +++Orgtr ++++Id +++++OrgId ++++++BICOrBEI

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

C AT-R2 Limited to BIC for an Agent or


The party originating the request for cancellation (bank).

• Cannot be used at the same time as Originator/Name (see above) (schema validation).

4.44 Undrlyg +TxInf ++CxlRsnInf +++Rsn ++++Cd

4!a C AT-48 The Payment Cancellation Request Reason Code (ISO20022 code).

• Must be used with a valid code (schema validation); and

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

4.45 Undrlyg +TxInf ++CxlRsnInf +++Rsn ++++Prtry

35x

** CW **

C AT-48 The Request for Cancellation Reason Code.

• Cannot be used at the same time as Code (see above) (schema validation).



Version 20111121 (RB5.0) 65 of 154


Ref



4.47 Undrlyg +TxInf ++OrgnlTxRef

M Mandatory

(an exact copy of all attributes of the initially sent DS-02 which is to be cancelled)

The message elements under ‘Original Transaction Reference’ must be populated with the same value as the message elements of the original instruction as defined within the following elements.

4.47 Undrlyg +TxInf ++OrgnlTxRef +++SttlmInf ++++SttlmMtd

4!a M NA The Settlement Method.

• Only “CLRG” is allowed (schema validation).

4.47 Undrlyg +TxInf ++OrgnlTxRef +++SttlmInf ++++ClrSys +++++Prtry


Value must be ‘ST2’: error code XT33.

4.47 Undrlyg +TxInf ++OrgnlTxRef +++PmtTpInf ++++SvcLvl +++++Cd

4!a M AT-40

The Service Level Code.


4.47 Undrlyg +TxInf ++OrgnlTxRef +++PmtTpInf ++++LclInstrm +++++Cd

35x

** CW **

C NA The indication of the scheme or service.

• The value is based on an external list and is not checked by EBA STEP2 CS; and

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



Version 20111121 (RB5.0) 66 of 154


Ref



4.47 Undrlyg +TxInf ++OrgnlTxRef +++PmtTpInf ++++LclInstrm +++++Prtry

35x C NA The indication of the scheme or service.

• The value is based on an external list and is not checked by EBA STEP2 CS;

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

• Cannot be used at the same time as Code above(schema validation).

4.47 Undrlyg +TxInf ++OrgnlTxRef +++PmtTpInf ++++CtgyPurp

See schema

O AT-45

The category purpose.

4.47 Undrlyg +TxInf +OrgnlTxRef ++RmtInf +++Ustrd

140x

** CW **

C AT-05 Unstructured Remittance Information.



• First occurrence is yellow and optional; and • Subsequent occurrences are white and reserved

for future use. Error code: XT81. 4.47 Undrlyg

+TxInf +OrgnlTxRef ++RmtInf +++Strd

140x C AT-05 Structured Remittance Information.



• First occurrence is yellow and optional; • Subsequent occurrences are white and reserved

for future use. Error code: XT13; and • Format is 140x for entire data in each occurrence

where the number of characters is counted between the Structured tags (not inclusive). Error Code: XT33.



Version 20111121 (RB5.0) 67 of 154


Ref



4.47 Undrlyg +TxInf ++OrgnlTxRef +++RmtInf ++++Strd +++++RfrdDocInf

See Schema


4.47 Undrlyg +TxInf ++OrgnlTxRef +++RmtInf ++++Strd +++++RfrdDocAmt

See Schema


Undrlyg +TxInf ++OrgnlTxRef +++RmtInf ++++Strd +++++CdtrRefInf ++++++Tp +++++++CdOrPrtry ++++++++Cd

4!a O AT-05 Creditor Reference Information Type Code.



Undrlyg +TxInf ++OrgnlTxRef +++RmtInf ++++Strd +++++CdtrRefInf ++++++Tp +++++++CdOrPrtry ++++++++Prtry

35x

** CW **





Version 20111121 (RB5.0) 68 of 154


Ref



Undrlyg +TxInf ++OrgnlTxRef +++RmtInf ++++Strd +++++CdtrRefInf ++++++Tp +++++++Issr

35x

** CW **


Undrlyg +TxInf ++OrgnlTxRef +++RmtInf ++++Strd +++++CdtrRefInf ++++++Ref

35x

** CW **

O AT-05 Creditor Reference Information Reference.


4.47 Undrlyg +TxInf ++OrgnlTxRef +++RmtInf ++++Strd +++++Invcr

See Schema

O AT-05 Invoicer.

4.47 Undrlyg +TxInf ++OrgnlTxRef +++RmtInf ++++Strd +++++Invcee

See Schema

O AT-05 Invoicee.

4.47 Undrlyg +TxInf ++OrgnlTxRef +++RmtInf ++++Strd +++++AddtlRmtInf

140x

** CW **




Version 20111121 (RB5.0) 69 of 154


Ref



4.47 Undrlyg +TxInf ++OrgnlTxRef +++UltmtDbtr

See schema

O AT-08 AT-09

The Ultimate Debtor.

• Not checked by STEP2 CS; and • All subfields present in the original Credit Transfer

message are supported (schema validation). 4.47 Undrlyg

+TxInf ++OrgnlTxRef +++Dbtr ++++Nm

70x

** CW **

M AT-02

The Debtor Name.

4.47 Undrlyg +TxInf ++OrgnlTxRef +++Dbtr ++++PstlAdr +++++Ctry

2!a O AT-03 The Debtor Country.

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

4.47 Undrlyg +TxInf ++OrgnlTxRef +++Dbtr ++++PstlAdr +++++AdrLine

70x

** CW **

O AT-03 The Debtor Postal Address Lines.

• Up to two occurrences are supported (schema validation).

4.47 Undrlyg +TxInf ++OrgnlTxRef +++Dbtr ++++Id +++++OrgId

See Schema

C AT-10 The identification of the Debtor: Organisation Id.



• All of the ISO options are available (see ISO document or XML Schema).



Version 20111121 (RB5.0) 70 of 154


Ref



4.47 Undrlyg +TxInf ++OrgnlTxRef +++Dbtr ++++Id +++++PrvtId

See Schema

C AT-10 The identification of the Debtor: Private Id.




4.47 Undrlyg +TxInf ++OrgnlTxRef +++Dbtr ++++CtryOfRes

2!a O NA

The Debtor Country of Residence.

4.47 Undrlyg +TxInf ++OrgnlTxRef +++DbtrAcct ++++Id +++++IBAN

2!a2!n30x

M AT-01

The Debtor Account.

4.47 Undrlyg +TxInf ++OrgnlTxRef +++DbtrAgt ++++FinInstnId +++++BIC

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

M AT-06 The Debtor Agent BIC.

• Must be present in the CS repository. Error Code XT74.

4.47 Undrlyg +TxInf ++OrgnlTxRef +++CdtrAgt ++++FinInstnId +++++BIC

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

M AT-23

The Creditor Agent.



Version 20111121 (RB5.0) 71 of 154


Ref



4.47 Undrlyg +TxInf ++OrgnlTxRef +++Cdtr ++++Nm

70x

** CW **

M AT-21

The Creditor Name.

4.47 Undrlyg +TxInf ++OrgnlTxRef +++Cdtr ++++PstlAdr +++++Ctry

2!a O AT-22 The Creditor Country.


4.47 Undrlyg +TxInf ++OrgnlTxRef +++Cdtr ++++PstlAdr +++++AdrLine

70x

** CW **

O AT-22 The Creditor Postal Address Lines.


4.47 Undrlyg +TxInf ++OrgnlTxRef +++Cdtr ++++Id +++++OrgId

See Schema

C AT-24 The identification of the Creditor: Organisation Id.




4.47 Undrlyg +TxInf ++OrgnlTxRef +++Cdtr ++++Id +++++PrvtId

See Schema

C AT-24 The identification of the Creditor: Private Id.






Version 20111121 (RB5.0) 72 of 154


Ref



4.47 Undrlyg +TxInf ++OrgnlTxRef +++Cdtr ++++CtryOfRes

2!a O NA

The Creditor Country of Residence.

4.47 Undrlyg +TxInf ++OrgnlTxRef +++CdtrAcct ++++Id +++++IBAN

2!a2!n30x

M AT-20

The Creditor Account.

4.47 Undrlyg +TxInf ++OrgnlTxRef +++UltmtCdtr

See schema

O AT-28 AT-29

The Ultimate Creditor.

• Not checked by STEP2 CS; and • All subfields present in the original Credit Transfer

message are supported (schema validation).

Table 4-13 SCT Payment Cancellation Req (camt.056) – Individual Credit Transfer Cancellation Instruction



Version 20111121 (RB5.0) 73 of 154

C.3 STEP2 Usage of camt.029 (Resolution of Investigation)

This transaction can be present in the ICF and SCF files.

C.3.1 SCT Resolution of Investigation (camt.029) Bulk Header

Index XML Element Format Status Rulebook Ref

EPC SCT Implementation Guidelines – Usage Rule


1.1 Assgnmt +Id

35x M The Identifier of the assignment.

• ICF: The DP’s assignment reference;

• SCF: STEP2 CS’ assignment reference; and

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

1.2 Assgnmt +Assgnr ++Agt +++FinInstnId ++++BIC

4!a2!a2!c M Instructing Party

Usage Rule: Limited to BIC to identify a bank or CSM or ‘Name’ to indicate the CSM when it has no BIC.

For ICF: the DP originating this assignment.


• For SCF: the STEP2 CS BIC.

1.5 Assgnmt +Assgne ++Agt +++FinInstnId ++++BIC

4!a2!a2!c M Instructed Party

Usage Rule: Limited to BIC to identify a bank or CSM or ‘Name’ to indicate the CSM when it has no BIC.

For SCF: the DP receiving this assignment.

• For ICF: the STEP2 CS BIC. Error code B12.

1.8 Assgnmt +CreDtTm

ISODate &Time

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


Ref


Guidelines – Usage Rule


3.1 Sts +Conf

4!a M Only RJCR is allowed. Confirmation of Resolution of Investigation.

• Only the value “RJCR” is allowed (schema validation).

Table 4-14 – SCT Resolution of Investigation (camt.029) – Bulk Header



Version 20111121 (RB5.0) 74 of 154

C.3.2 SCT Resolution of Investigation (camt.029) Individual Transaction Information

Multiple occurrences of Transaction Information can be used. No matching is performed towards the original CT (pacs.008) or the Payment Cancellation Request (camt.056). Index XML Acronym Format Status Rulebook

Ref


Guidelines – Usage Rules Validation Rules

4.72 CxlDtls +TxInfAndSts

See below

M See below Mandatory Transaction Information and Status.

• At least one transaction must be present (schema validation).

4.73 CxlDtls +TxInfAndSts ++CxlStsId

35x M NA The Cancellation Identification.

• Uniqueness is checked under the rules for duplicate checking. Error code AM05; and


4.81 CxlDtls

+TxInfAndSts

++OrgnlGrpInf

+++OrgnlMsgId

35x M NA The Message Identifier of the original bulk.

• For ICF the Message Identifier is the one generated by STEP2 CS for the Original CT bulk in the original SCF; and

• For SCF, the Message Identifier is the Original Message Identifier of the original bulk received from the bank.

4.82 CxlDtls

+TxInfAndSts

++OrgnlGrpInf

+++OrgnlMsgNmId

35x M NA Only ‘pacs.008.001.02’ is allowed. The type of XML message bulk to be cancelled.

• Must always equal to pacs.008* (use of wildcard in validation) (schema validation).

4.84 CxlDtls

+TxInfAndSts

++OrgnlInstrId

35x O NA The Original instruction Identifier of the pacs 008.



Version 20111121 (RB5.0) 75 of 154


Ref



4.85 CxlDtls

+TxInfAndSts

++OrgnlEndToEndId

35x

** CW **

M AT-41 Mandatory The Original End to End Identifier of the pacs 008.

4.86 CxlDtls

+TxInfAndSts

++OrgnlTxId

35x M AT-43 Mandatory

The Original Transaction Identifier of the pacs 008.

4.88 CxlDtls

+TxInfAndSts

++TxCxlSts

4!a M NA Only ‘RJCR’ is allowed Transaction Cancellation Status. • Only the value “RJCR” is allowed (schema validation).

4.90 CxlDtls +TxInfAndSts ++CxlStsRsnInf +++Orgtr ++++Nm

70x

** CW **

C NA Limited to BIC for an Agent or


The party originating the Resolution of Investigation (customer).

• Cannot be used at the same time as Originator/BICOrBEI (below) (schema validation).

4.90 CxlDtls

+TxInfAndSts

++CxlStsRsnInf +++Orgtr ++++Id +++++OrgId ++++++BICOrBEI

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

C AT-R2 Limited to BIC for an Agent or


The party originating the Resolution of Investigation (bank).

• Cannot be used at the same time as Originator/Name (above) (schema validation).

4.92 CxlDtls

+TxInfAndSts

++CxlStsRsnInf +++Rsn ++++Cd

4!a C AT-R6 Mandatory The Resolution of Investigation Reason Code.

• Must be used with a valid code (schema validation);

• Only ISO Codes can be used in this field : LEGL and CUST (schema validation); other values should be used with the “Prtry” field below;

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



Version 20111121 (RB5.0) 76 of 154


Ref



4.93 CxlDtls

+TxInfAndSts

++CxlStsRsnInf +++Rsn ++++Prtry

35x

** CW **

C AT-R6 The Resolution of Investigation Reason Code Proprietary.


4.94 CxlDtls

+TxInfAndSts

++CxlStsRsnInf +++AddtlInf

105x

** CW **

C NA • To be used only when code is ‘LEGL’ in order to precise the reason.

• Only two occurrences are allowed

The Resolution of Investigation Additional Information.

• To be used only when Reason Code is ‘LEGL’ in order to specify the reason. Error code XT13.; and

• Only two occurrences are allowed (schema validation).

4.101 CxlDtls

+TxInfAndSts

++Assgnr +++Agt ++++FinInstnId +++++BIC

4!a2!a2!c C NA The DP originating this assignment.

• Only used in SCF. Error code XT13.

4.107 CxlDtls

+TxInfAndSts

++OrgnlTxRef

See Schema

M NA Mandatory

(an exact copy of all attributes of the initially sent DS-02 which is to be cancelled)

The yellow shaded message elements under ‘Original Transaction Reference’ must be populated with the same value as the message elements of the original instruction as defined within the following elements.

•

• Not checked by STE2 CS

4.107 CxlDtls

+TxInfAndSts

++OrgnlTxRef

+++IntrBkSttlmDt

ISO DATE

M NA

The original Interbank Settlement Date.



Version 20111121 (RB5.0) 77 of 154


Ref



4.107 CxlDtls

+TxInfAndSts

++OrgnlTxRef +++SttlmInf ++++SttlmMtd

4!a M NA

The Settlement Method.

• Only “CLRG” is allowed (schema validation).

4.107 CxlDtls + TxInfAndSts ++OrgnlTxRef +++SttlmInf ++++ClrSys +++++Prtry


Value must be ‘ST2’: error code XT33.

4.107 CxlDtls +TxInfAndSts ++OrgnlTxRef +++PmtTpInf ++++SvcLvl +++++Cd

4!a M AT-40 The Service Level Code.


4.107 CxlDtls +TxInfAndSts ++OrgnlTxRef +++PmtTpInf ++++LclInstrm +++++Cd

35x

** CW **

C NA The indication of the scheme or service.

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

• The value is based on an external list and is not checked by STEP2 CS.

4.107 CxlDtls +TxInfAndSts ++OrgnlTxRef +++PmtTpInf ++++LclInstrm +++++Prtry

35x C NA The indication of the scheme or service.


• The value is based on an external list and is not checked by STEP2 CS;

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



Version 20111121 (RB5.0) 78 of 154


Ref



4.107 CxlDtls +TxInfAndSts ++OrgnlTxRef +++PmtTpInf ++++CtgyPurp

See schema

O AT-45

The category purpose.

4.107 CxlDtls +TxInfAndSts +OrgnlTxRef ++RmtInf +++Ustrd

140x

** CW **

C AT-05 Unstructured Remittance Information. • Either Unstructured or Structured Remittance

Information can be used (schema validation); • Maximum of 10 occurrences of this field.

(schema validation); • First occurrence is yellow and optional; and • Subsequent occurrences are white and

reserved for future use. Error code: XT81. 4.107 CxlDtls

+TxInfAndSts +OrgnlTxRef ++RmtInf +++Strd

140x C AT-05 Structured Remittance Information. • Either Unstructured or Structured Remittance

Information can be used (schema validation); • 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; and • Format is 140x for entire data in each

occurrence where the number of characters is counted between the Structured tags (not inclusive). Error Code: XT33.

4.107 CxlDtls +TxInfAndSts ++OrgnlTxRef +++RmtInf ++++Strd +++++RfrdDocInf

See Schema




Version 20111121 (RB5.0) 79 of 154


Ref



4.107 CxlDtls +TxInfAndSts ++OrgnlTxRef +++RmtInf ++++Strd +++++RfrdDocAmt

See Schema


4.107 CxlDtls +TxInfAndSts ++OrgnlTxRef +++RmtInf ++++Strd +++++CdtrRefInf ++++++Tp +++++++CdOrPrtry ++++++++Cd




4.107 CxlDtls +TxInfAndSts ++OrgnlTxRef +++RmtInf ++++Strd +++++CdtrRefInf ++++++Tp +++++++CdOrPrtry ++++++++Prtry

35x

** CW **



4.107 CxlDtls +TxInfAndSts ++OrgnlTxRef +++RmtInf ++++Strd +++++CdtrRefInf ++++++Tp +++++++Issr

35x

** CW **




Version 20111121 (RB5.0) 80 of 154


Ref



4.107 CxlDtls +TxInfAndSts ++OrgnlTxRef +++RmtInf ++++Strd +++++CdtrRefInf ++++++Ref

35x

** CW **



4.107 CxlDtls +TxInfAndSts ++OrgnlTxRef +++RmtInf ++++Strd +++++Invcr

See Schema

O AT-05 Invoicer.

4.107 CxlDtls +TxInfAndSts ++OrgnlTxRef +++RmtInf ++++Strd +++++Invcee

See Schema

O AT-05 Invoicee.

4.107 CxlDtls +TxInfAndSts ++OrgnlTxRef +++RmtInf ++++Strd +++++AddtlRmtInf

140x

** CW **


4.107 CxlDtls +TxInfAndSts ++OrgnlTxRef +++UltmtDbtr

See schema

O AT-08 AT-09

The Ultimate Debtor.

• Not checked by STEP2 CS; and • All subfields present in the original Credit

Transfer message are supported (schema validation).

4.107 CxlDtls +TxInfAndSts ++OrgnlTxRef +++Dbtr ++++Nm

70x

** CW **

M AT-02

The Debtor Name.



Version 20111121 (RB5.0) 81 of 154


Ref



4.107 CxlDtls +TxInfAndSts ++OrgnlTxRef +++Dbtr ++++PstlAdr +++++Ctry



4.107 CxlDtls +TxInfAndSts ++OrgnlTxRef +++Dbtr ++++PstlAdr +++++AdrLine

70x

** CW **



4.107 CxlDtls +TxInfAndSts ++OrgnlTxRef +++Dbtr ++++Id +++++OrgId

See Schema





4.107 CxlDtls +TxInfAndSts ++OrgnlTxRef +++Dbtr ++++Id +++++PrvtId

See Schema

C NA The identification of the Debtor: Private Id.




4.107 CxlDtls +TxInfAndSts ++OrgnlTxRef +++Dbtr ++++CtryOfRes

2!a O NA




Version 20111121 (RB5.0) 82 of 154


Ref



4.107 CxlDtls +TxInfAndSts ++OrgnlTxRef +++DbtrAcct ++++Id +++++IBAN

2!a2!n30x

M AT-01

The Debtor Account.

4.107 CxlDtls +TxInfAndSts ++OrgnlTxRef +++DbtrAgt ++++FinInstnId +++++BIC

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

M AT-06

The Debtor Agent BIC.

4.107 CxlDtls +TxInfAndSts ++OrgnlTxRef +++CdtrAgt ++++FinInstnId +++++BIC

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

M AT-23

The Creditor Agent.

4.107 CxlDtls +TxInfAndSts ++OrgnlTxRef +++Cdtr ++++Nm

70x

** CW **

M AT-21

The Creditor Name.

4.107 CxlDtls +TxInfAndSts ++OrgnlTxRef +++Cdtr ++++PstlAdr +++++Ctry



4.107 CxlDtls +TxInfAndSts ++OrgnlTxRef +++Cdtr ++++PstlAdr +++++AdrLine

70x

** CW **





Version 20111121 (RB5.0) 83 of 154


Ref



4.107 CxlDtls +TxInfAndSts ++OrgnlTxRef +++Cdtr ++++Id +++++OrgId

See Schema

C AT-24 The identification of the Creditor: Organisation Id.




4.107 CxlDtls +TxInfAndSts ++OrgnlTxRef +++Cdtr ++++Id +++++PrvtId

See Schema





4.107 CxlDtls +TxInfAndSts ++OrgnlTxRef +++Cdtr ++++CtryOfRes

2!a O NA


4.107 CxlDtls +TxInf ++OrgnlTxRef +++CdtrAcct ++++Id +++++IBAN

2!a2!n30x

M AT-20

The Creditor Account IBAN.

4.107 CxlDtls +TxInf ++OrgnlTxRef +++UltmtCdtr

See schema

O AT-28 AT-29

The Ultimate Creditor.

• Not checked by STEP2 CS; and • All subfields present in the original Credit

Transfer message are supported (schema validation).



Version 20111121 (RB5.0) 84 of 154

Table 4-15 - SCT Resolution of Investigation (camt.029) - Individual Transaction Details



Version 20111121 (RB5.0) 85 of 154

C.4 STEP2 Usage of pacs.002S2 (Payment Status)

This is a Payment Status sent by STEP2 to inform a bank of rejected Credit Transfer, Return, Payment Cancellation Request or Resolution of Investigation. The Payment Status is also used in optional file PCF to notify CT Instructing Agent of the status of a CT object of a Recall Procedure.

C.4.1 SCT Reject (pacs.002S2) in CVF,CCF and PCF 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.

GrpHdr +InstgAgt ++FinInstnId +++BIC

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

C The Instructing Agent BIC (Instructing Agent of the original transaction).

• Not used in CVF; and • Present in CCF and PCF.

Table 4-16 SCT Reject (pacs.002S2) in CVF, CCF and PCF Bulk Header



Version 20111121 (RB5.0) 86 of 154

C.4.2 SCT Reject (pacs.002S2) in CVF,CCF and PCF - Original Group Information And Status

XML Element Format Status STEP2 Usage Rules OrgnlGrpInfAndSts +OrgnlMsgId

35x M The Message Id of the original bulk

OrgnlGrpInfAndSts +OrgnlMsgNmId

35x M The type of XML message to be rejected. CVF: pacs.008, pacs.004, camt.056, camt.029; and CCF: pacs.008, pacs.004. PCF: pacs.008

OrgnlGrpInfAndSts +OrgnlNbOfTxs

15n M The total number of transactions received within the original bulk.

OrgnlGrpInfAndSts +OrgnlCtrlSum

18d M CVF: The total amount received within the original bulk. CCF and PCF: The total amount of valid transactions received within the original bulk and cancelled at settlement

OrgnlGrpInfAndSts +GrpSts

4!a M The status of the original bulk; values allowed are: • CVF: “ACCP”= accepted, “PART” = partially accepted or “RJCT” = rejected; and • CCF: “RJCT”= cancelled by Settlement Mechanism or “PART” = partially settled. • PCF: always set to “PART”

OrgnlGrpInfAndSts +StsRsnInf ++Orgtr +++Id ++++OrgId +++++BICOrBEI

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

M The STEP2 CS BIC.

OrgnlGrpInfAndSts +StsRsnInf ++Rsn +++Cd

4!a C The indication of the error code of the bulk. Code is defined as per ISO20022.

• Cannot be used with Rsn Prtry (see below). • Not used in PCF files

OrgnlGrpInfAndSts +StsRsnInf ++Rsn +++Prtry

35x C The indication of the error code of the bulk. Code is STEP2 Specific (proprietary).

• Cannot be used with Rsn Code (see above); • If Group Status is Accepted: B00; • If Group Status is Partially Accepted: B01; and • If Group Status is Rejected: contains bulk rejection reason code.

For PCF files the value is always set to “PCR”



Version 20111121 (RB5.0) 87 of 154

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

15n C The number of transactions per this status in the bulk.

• Status = Accepted for CVF and CCF – Cancelled for PCF • Present if Group Status is PART.

OrgnlGrpInfAndSts +NbOfTxsPerSts ++DtldSts

4!a C The status of the transactions (Accepted).

• Status = “ACCP” for CVF and CCF – “RJCT” for PCF

• Present if Group Status is PART. OrgnlGrpInfAndSts +NbOfTxsPerSts ++DtldCtrlSum

18d C The Value of the transactions per this status (Accepted) in the bulk.

• Status = Accepted for CVF and CCF – Cancelled for PCF

• Present if Group Status is PART. OrgnlGrpInfAndSts +NbOfTxsPerSts ++DtldNbOfTxs

15n C The number of transactions per this status in the bulk.

• Status = Rejected for CVF and CCF – Recalled for PCF

• Present if Group Status is PART. OrgnlGrpInfAndSts +NbOfTxsPerSts ++DtldSts

4!a C The status of the transactions (Rejected).

• Status = “RJCT” for CVF and CCF – “PDNG” for PCF • Present if Group Status is PART.

OrgnlGrpInfAndSts +NbOfTxsPerSts ++DtldCtrlSum

18d C The Value of the transactions per this status (Rejected) in the bulk.

• Status = Rejected for CVF and CCF – Recalled for PCF • Present if Group Status is PART.

Table 4-17 SCT Reject (pacs.002S2) in CVF, CCF and PCF - Original Group Information And Status



Version 20111121 (RB5.0) 88 of 154

C.4.3 SCT Reject (pacs.002S2) in CVF,CCF and PCF – Individual Transaction

This part of the message is only present if there are any transactions rejected inside the bulk as described below or in the case of PCF files. 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 CT; populated only if it was present in the original CT.

TxInfAndSts +OrgnlEndToEndId

35x M The End to End Id of the original CT.

TxInfAndSts +OrgnlTxId

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

TxInfAndSts +TxSts

4!a M The status of this transaction.

• The only value allowed for CVF and CCF is: “RJCT”= rejected. • The values for PCF file are:

o “RJCT” if StsRsnInf/Rsn/Prtry below is set to “CANC” o “PDNG” if StsRsnInf/Rsn/Prtry below is set to “RCLL”

TxInfAndSts +StsRsnInf ++Orgtr +++Id ++++OrgId +++++BICOrBEI

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

TxInfAndSts +StsRsnInf ++Rsn +++Cd

4!a C The indication of the error code for the transaction (ISO20022 codes).

• For CCF: ED05 is the value allowed for cancellation at settlement; and • Cannot be used at the same time as Proprietary (see below).



Version 20111121 (RB5.0) 89 of 154

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

35x C For CVF and CCF files: 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 follows: [CODE][1 blank character][Offending XML tag] Where: CODE: XT13 or XT33 Offending XML tag: Cannot be used at the same time as Code (see above). For PCF Files:

• “CANC” = the PCR was processed before the settlement of the original Credit Transfer. The original CT was not settled.

• “RCLL” = the PCR was processed after the settlement of the original Credit Transfer. The CT has been settled/cancelled and the Recall Request was forwarded to the Beneficiary Bank of the original CT.

TxInfAndSts +InstdAgt ++FinInstnId +++BIC

4!a2!a2!c[3!c] C The Instructed Agent BIC (Instructed Agent obtained from the original transaction).

• Present only in CCF and PCF.

TxInfAndSts +OrgnlTxRef ++IntrBkSttlmAmt Attribute

18d

EUR

C C

The Amount of the original transaction. Depending on the type of the original message, this can either be:

• Credit Transfer: Interbank Settlement Amount; • Return: Returned Interbank Settlement Amount; and • Payment Cancellation Request: Interbank Settlement Amount of the original

transaction. • Resolution of Investigation: the field will be set to zero

TxInfAndSts +OrgnlTxRef ++IntrBkSttlmDt

ISODate M The Original Interbank Settlement Date.



Version 20111121 (RB5.0) 90 of 154

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

4!a2!a2!c[3!c] M The Original Debtor Agent.

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

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

Table 4-18 SCT Reject (pacs.002S2) in CVF, CCF and PCF – Individual Transaction



Version 20111121 (RB5.0) 91 of 154

C.5 STEP2 Usage of pacs.004 (Return)

C.5.1 SCT Return (pacs.004) Bulk Header SCF & ICF


Ref




1.1 GrpHdr +MsgId

35x M NA The bulk reference of the generating party. ICF: Direct Participant reference SCF: STEP2 reference

• Uniqueness is checked for ICF: error code B14; and


1.2 GrpHdr +CreDtTm

ISO Date & Time

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

1.7 GrpHdr +NbOfTxs

15n M NA 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.

1.10 GrpHdr +TtlRtrdIntrBkSttlmAmt Attribute

18d

EUR

M M

NA Mandatory




The Value of the transactions included in this bulk.

• Values are supported with up to 15 digits in the integer part, a decimal point and up to 2 fraction digits (schema validation);

• Currency attribute must be always “EUR” (schema validation);

• Must be greater than “0”: error code B13; and

• Must equal the sum of individual transactions inside the bulk: error code B05.



Version 20111121 (RB5.0) 92 of 154


Ref




1.11 GrpHdr +IntrBkSttlmDt

ISODate M AT-R4/AT-R8 Mandatory The Interbank Settlement Date

The business date in which the transactions inside this bulk must be settled in the relevant settlement mechanism.

• IntrBkSttlmDt must be in the allowed range: error code B15.

1.13 GrpHdr +SttlmInf ++SttlmMtd

4!a M NA Only CLRG, INGA and INDA are allowed.

Information on settlement method.

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

1.15 GrpHdr

+SttlmInf

++ClrSys

+++Prtry

35x M NA The Identifier of the Clearing System.

• Only the value ‘ST2’ is supported: error code B16.

1.24 GrpHdr +InstgAgt ++FinInstnId +++BIC

4!a2!a2!c C NA Only BIC is allowed. The DP originating this bulk.

• Must equal SndgInst element in ICF and must not contain a branch code: error code B10; and

• Must be used only in ICF. error code B10.

1.25 GrpHdr +InstdAgt ++FinInstnId +++BIC

4!a2!a2!c C NA Only BIC is allowed. The DP receiving this bulk.

• Used only in SCF: error code B11

Table 4-19 SCT Return (pacs.004) Bulk Header



Version 20111121 (RB5.0) 93 of 154

C.5.2 SCT Return (pacs.004) Individual Transaction

Each ICF message must be sent within the configured time period for type of message. No matching is performed towards the original CT (pacs.008). Index XML Element Format Status Rulebook

Ref STEP2 Usage Rules and Validation

3.1 TxInf +RtrId

35x M AT-R5 (Return)

Mandatory The Return Identification

• Uniqueness is checked under the rules for duplicate checking: error code AM05; and

• This identification cannot include leading, trailing or internal spaces. (schema validation)

3.3 TxInf +OrgnlGrpInf ++OrgnlMsgId

35x M NA The Message ID of the bulk containing the original CT. In the case of ICF, the Original Message Id is the one generated by the CS for the Original CT bulk in the original SCF. In case of the SCF, the Original Message Id is the one generated by DP for the Original Return bulk in the original ICF containing the Returns.


3.4 TxInf +OrgnlGrpInf ++OrgnlMsgNmId

35x M NA The type of XML message bulk to be Returned.

• For SCT Service: must always equal to pacs.008* (use of wildcard in schema validation).



Version 20111121 (RB5.0) 94 of 154


Ref

STEP2 Usage Rules and Validation

3.6 TxInf +OrgnlInstrId

35x O NA Mandatory if provided in the original instruction.

The Instruction ID of the original CT; populated only if it was present in the original DD.

• This identification cannot include leading, trailing or internal spaces. (schema validation).

3.7 TxInf +OrgnlEndToEndId

35x ** CW **

M AT-41 Mandatory The original End to End Id.

3.8 TxInf +OrgnlTxId

35x M AT-43 Mandatory Must contain a reference that is meaningful to the Originator’s Bank and is unique over time.

The original Transaction Id.

• This identification cannot include leading, trailing or internal spaces. (schema validation)

3.10 TxInf +OrgnlIntrBkSttlmAmt Attribute

18d

3!a

M

AT-04 Mandatory • Amount must be 0.01 or more and

999999999.99 or less. • The fractional part has maximum

of two digits.

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



Version 20111121 (RB5.0) 95 of 154


Ref


3.11 TxInf +RtrdIntrBkSttlmAmt Attribute

18d

3!a

M M

AT-04 (Return)

Or AT-46 (Recall)

• If the return message is a positive answer to a Recall (ie, if ‘Code’ under ‘Return Reason Information’ specifies ‘FOCR’), the amount must be equal to the ‘Original Interbank Settlement Amount’ less the ‘Amount’ under ‘Charges Information’.

• If the return message is not a positive answer to a Recall (ie, if ‘Code’ under

• ‘Return Reason Information’ is different from ‘FOCR’), the Amount must be the same as in ‘Original Interbank Settlement Amount’.




The amount of this transaction (Return).

. • If the return message is a positive answer to

a Recall (‘Code’ under ‘Return Reason Information’ specifies ‘FOCR’), the amount must be equal to the ‘Original Interbank Settlement Amount’ less the ‘Amount’ under ‘Charges Information’: error code AM02;

• If the return message is not a positive answer to a Recall (‘Code’ under ‘Return Reason Information’ different from ‘FOCR’), the amount must be the same as in ‘Original Interbank Settlement Amount’: error code AM02;


• The number of digits following the decimal point in Returned Interbank Settlement Amount must not exceed the maximum number allowed for the EUR currency (schema validation);

• Amount must be 0.01 or more: error code AM01; and



Version 20111121 (RB5.0) 96 of 154


Ref


3.13 TxInf +RtrdInstdAmt Attribute

18d

3!a

C NA • Only allowed in the case of a return in response to a cancellation request, ie, ‘Reason’ in ‘Return Reason Information’ specifies ‘FOCR’.




The Returned Instructed Amount

• Must be present if ‘Charges Information is present’, in line with ISO rules: error code XT13; ; and ‘optional’ otherwise.

• Only allowed in the case of a return in response to a cancellation request, ie, ‘Reason’ in ‘Return Reason Information’ is populated with ‘FOCR’: error code XT33;


3.15 TxInf +CompstnAmt

18d

3!a

O M

NA The Returned Compensation amount of the returned transaction.

• The Currency attribute must be “EUR” (schema validation); and

• The number of digits following the decimal point in Compensation Amount must not exceed the maximum number allowed for the EUR currency (schema validation).

3.16 TxInf +ChrgBr

4!a O NA The Charge Bearer Information.

• Only the value SLEV is allowed (schema validation).



Version 20111121 (RB5.0) 97 of 154


Ref


3.18 TxInf +ChrgsInf ++Amt Attribute

18d

3!a

C AT-47 • Only allowed in case of a return in response to a cancellation request, ie, ‘Reason’ in ‘Return Reason Information’ specifies ‘FOCR’.

• Only one occurrence is allowed.

The Charges Amount.

• Only one occurrence is allowed (schema validation);

• Amount must be 0.01 or more: error code AM01;

• The number of digits following the decimal point in Charges Amount must not exceed the maximum number allowed for the EUR currency (schema validation);and

• Only allowed in case of a return in response to a cancellation request, .i.e. ‘Reason’ in ‘Return Reason Information’ specifies ‘FOCR’: error code XT33.

3.19 TxInf +ChrgsInf ++Pty +++FinInstnId ++++BIC

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

O AT-23 Only BIC is allowed. The Charges Party (BIC).


3.20 TxInf +InstgAgt ++FinInstnId +++BIC

4!a2!a2!c C NA Only BIC is allowed. The DP originating this Return.

• Must be present in the SCF only: error code XT13.

3.23 TxInf +RtrRsnInf ++Orgtr +++Nm

70x

** CW **

C AT-R2 • ‘Name’ is limited to 70 characters in length.

The Customer originating this transaction.

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



Version 20111121 (RB5.0) 98 of 154


Ref


3.23 TxInf +RtrRsnInf ++Orgtr +++Id ++++OrgId +++++BICOrBEI

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

C AT-R2 The Party originating this transaction.

• Cannot be used at the same time as Originator/Name (see above) (schema validation).

3.25 TxInf +RtrRsnInf ++Rsn +++Cd

4!c C AT-R3 The Return Reason Code (ISO20022).

• Must be used with a valid ISO code (schema validation); and

• Cannot be used at the same time than Prty (see below) (schema validation).

3.26 TxInf +RtrRsnInf ++Rsn +++Prtry

35x

** CW **

C NA The Return Reason Code (STEP2).

• Cannot be used at the same time than Code (see above) (schema validation).

3.27 TxInf +RtrRsnInf ++AddtlInf

105x

** CW **

C AT-R7 • Only one occurrence allowed.

• Only allowed when ‘FOCR’ is present in ‘Reason’.

Additional Information

• AT-R7 Specific Reference of the bank initiating the recall

• Usage Rule: Only one occurrence allowed (Schema validation).

• Usage Rule: Only allowed when ‘FOCR’ is present in ‘Reason’ (Error code XT13).

3.35 TxInf +OrgnlTxRef ++IntrBkSttlmDt

ISO DATE M AT-42 The Original Interbank Settlement Date.

3.39 TxInf +OrgnlTxRef ++SttlmInf +++SttlmMtd

4!a M NA The Settlement Method.

• Only the value “CLRG” is allowed (schema validation).



Version 20111121 (RB5.0) 99 of 154


Ref


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

4!a M AT-40 The Transaction Service Level.


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

35x

** CW **

C NA The Payment Type Information.

• Cannot be used at the same time than Prty (see below) (schema validation); and

• The value is based on an external list and is not checked by STEP2 CS.

3.51 TxInf +OrgnlTxRef ++PmtTpInf +++LclInstrm ++++Prtry

35x C NA The Payment Type Information.

• Cannot be used at the same time than Code (see above) (schema validation);

• The value is based on an external list and is not checked by STEP2 CS;


3.51 TxInf

+OrgnlTxRef

++PmtTpInf

+++CtgyPurp

++++Cd

4x

** CW **

C AT-45 The Category Purpose of the transaction (ISO 20022 Code values).



3.51 TxInf

+OrgnlTxRef

++PmtTpInf

+++CtgyPurp

++++Prtry

35x

** CW **

C AT-45 The Category Purpose of the transaction Proprietary.

• Cannot be used at the same time as Cd (above) (schema validation); and




Version 20111121 (RB5.0) 100 of 154


Ref


3.84 TxInf +OrgnlTxRef ++RmtInf +++Ustrd

140x

** CW **

C AT-05 Unstructured Remittance Information.



• First occurrence is yellow and optional; and

• Subsequent occurrences are white and reserved for future use. Error code: XT81.

3.84 TxInf +OrgnlTxRef ++RmtInf +++Strd

140x C AT-05 Structured Remittance Information.



• First occurrence is yellow and optional; • Subsequent occurrences are white and

reserved for future use. Error code: XT81; and

• Format is 140x for entire data in each occurrence where the number of characters is counted between the Structured tags (not inclusive). Error Code: XT33.

TxInf +OrgnlTxRef ++RmtInf +++Strd ++++RfrdDocInf

See Schema


TxInf +OrgnlTxRef ++RmtInf +++Strd ++++RfrdDocAmt

See Schema




Version 20111121 (RB5.0) 101 of 154


Ref


3.123 TxInf +OrgnlTxRef ++RmtInf +++Strd ++++CdtrRefInf +++++Tp ++++++CdOrPrtry +++++++Cd




TxInf +OrgnlTxRef ++RmtInf +++Strd ++++CdtrRefInf +++++Tp ++++++CdOrPrtry +++++++Prtry

35x

** CW **



3.123 TxInf +OrgnlTxRef ++RmtInf +++Strd ++++CdtrRefInf +++++Tp ++++++Issr

35x

** CW **


3.123 TxInf +OrgnlTxRef ++RmtInf +++Strd ++++CdtrRefInf +++++Ref

35x

** CW **



TxInf +OrgnlTxRef ++RmtInf +++Strd ++++Invcr

See Schema

O AT-05 Invoicer.



Version 20111121 (RB5.0) 102 of 154


Ref


TxInf +OrgnlTxRef ++RmtInf +++Strd ++++Invcee

See Schema

O AT-05 Invoicee.

TxInf

+RmtInf

++Strd

+++AddtlRmtInf

140x

** CW **


3.116 TxInf +OrgnlTxRef ++UltmtDbtr +++Nm

70x

** CW **

O AT-08 The Ultimate Debtor Name.

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

2!a

O NA

Country of the Ultimate Debtor address.

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

70x

** CW ** O NA

The Ultimate Debtor Address.


3.116 TxInf

+OrgnlTxRef

++UltmtDbtr +++Id ++++OrgId See

Schema C AT-09

The identification of the Ultimate Debtor: Organisation Id.



• All of the ISO options are available (see ISO document or schema);




Version 20111121 (RB5.0) 103 of 154


Ref


3.116 TxInf

+OrgnlTxRef

++UltmtDbtr +++Id ++++PrvtId

See Schema

C AT-09

The identification of the Ultimate Debtor: Private Id.




TxInf

+OrgnlTxRef

++UltmtDbtr +++CtryOfRes

2!a O NA

The Country of Residence of the Ultimate Debtor.

3.117 TxInf +OrgnlTxRef ++Dbtr +++Nm

70x

** CW **

M AT-02

The Debtor Name.

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



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

70x

** CW **





Version 20111121 (RB5.0) 104 of 154


Ref


3.117 TxInf

+OrgnlTxRef ++Dbtr

+++Id

++++OrgId

See Schema




• All of the ISO options are available (see ISO document or XML Schema);


3.117 TxInf

+OrgnlTxRef ++Dbtr

+++Id

++++PrvtId

See Schema

C NA The identification of the Debtor: Private Id.




3.117 TxInf +OrgnlTxRef ++Dbtr +++CtryOfRes

2!a O NA


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

2!a2!n30x M AT-01

The Debtor Account IBAN.

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

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

M AT-06

The Debtor Agent BIC.



Version 20111121 (RB5.0) 105 of 154


Ref


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

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

M AT-23

The Creditor Agent BIC.

3.123 TxInf +OrgnlTxRef ++Cdtr +++Nm

70x

** CW **

M AT-21

The Creditor Name.

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



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

70x

** CW **



3.123 TxInf

+OrgnlTxRef ++Cdtr

+++Id

++++OrgId

See schema




• All of the ISO options are available (see ISO document or XML Schema);




Version 20111121 (RB5.0) 106 of 154


Ref


3.123 TxInf

+OrgnlTxRef ++Cdtr

+++Id

++++PrvtId

See schema





3.123 TxInf +OrgnlTxRef ++Cdtr +++CtryOfRes

2!a O NA


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

2!a2!n30x M AT-20

The Creditor Account IBAN.

3.125 TxInf +OrgnlTxRef ++UltmtCdtr +++Nm

70x

** CW **

O AT-28

The Ultimate Creditor Name.

3.125 TxInf

+OrgnlTxRef

++UltmtCdtr +++PstlAdr ++++Ctry

2!a

O NA

Country of the Ultimate Creditor address.

3.125 TxInf

+OrgnlTxRef

++UltmtCdtr +++PstlAdr ++++AdrLine

70x

** CW ** O NA

The Ultimate Creditor Address.




Version 20111121 (RB5.0) 107 of 154


Ref


3.125 TxInf

+OrgnlTxRef

++UltmtCdtr +++Id ++++OrgId

See Schema

C AT-29

The identification of the Ultimate Creditor: Organisation Id.



• All of the ISO options are available (see ISO document or schema);


3.125 TxInf

+OrgnlTxRef

++UltmtCdtr +++Id ++++PrvtId

See Schema

C AT-29

The identification of the Ultimate Creditor: Private Id.




3.125 TxInf

+OrgnlTxRef

++UltmtCdtr +++CtryOfRes

2!a O NA

The Country of Residence of the Ultimate Creditor.

Table 4-20 SCT Return (pacs.004) Individual Transaction



Version 20111121 (RB5.0) 108 of 154

APPENDIX D FILE/BULK VALIDATION AND ERROR CODES

D.1 ICF Naming & Structure Validation Process

Processing Error report

The STEP2 service identifier (e.g. SCT) 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 CVF because:

• It is not possible to associate a destination network address to which to send the file.

Resolution must involve a phone call from 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 CVF as follows:

• The ICF is totally accepted;

The reported FileRjctRsn at the level of ICF is:

• A00: the ICF 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 ICF is partially accepted;

The FileRjctRsn equals:

• A01: the file is partially accepted.

The file has been sent during non-Target days.


• The ICF is totally rejected;

• In a CVF OrigFRef and OrigDtTm will not be present (for CVF matching, only the Original File Name field is meaningful); and

• The transactions contained in the ICF have not been validated, and therefore:

• The CVF will not contain any rejected transaction, and

• In a CVF OrgnlGrpInfAndSts will not be present.



Version 20111121 (RB5.0) 109 of 154


The FileRjctRsn is:

• R01: the ICF has been received during non-Target days.



Version 20111121 (RB5.0) 110 of 154


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 following CVF fields are filled using the information derived from the network header:

• SrvcId,

• RcvgInst (the DP), and

• OrigFName.

• In a CVF, OrigFRef and OrigDtTm will not be present (for CVF matching, only the Original File Name field is meaningful); and



The FileRjctRsn is:

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



Version 20111121 (RB5.0) 111 of 154


The parser will validate the received file against the ICF XML schema.

If problems are encountered in the parsing of the XML file then the file is rejected.



• The CVF will not contain any rejected transaction;

The FileRjctRsn is:

• R08: Unable to process input file.

The parser will validate the received file against the ICF XML schema.

If the file does not comply with the schema then it is rejected as garbage.



• OrigFRef and OrigDtTm will not be present (for CVF matching, only the Original File Name field is meaningful); and



The FileRjctRsn is:

• R10: ICF does not comply with schema; the file cannot be processed.

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 payment instructions contained in the ICF have not been validated, and therefore:

• The CVF will not contain any rejected payment instructions.

The FileRjctRsn is:

• R13: the ICF is a duplicate.

The contents of the ICF 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




• The CVF will not contain any rejected transactions,

The FileRjctRsn is:

• R11: incorrect SndgInst.

• R12: incorrect RcvgInst.



Version 20111121 (RB5.0) 112 of 154


system value.

If any check fails then the file is rejected.

• R14: incorrect TstCode.

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)



• OrigFRef and OrigDtTm will not be present (for CVF matching, only the OrigFName field is meaningful); and



The FileRjctRsn is:

• R15: incorrect SndgInst format;

• R16: incorrect RcvgInst format.

The Credit Transfer bulks within the file are counted and the total is compared against NumCTBlk.

If the numbers are different then the file is rejected.



• The CVF will not contain any rejected payment instructions; and

• The payment instructions contained in the ICF have not been validated

The FileRjctRsn is:

R18: the number of Credit Transfer bulks within the ICF does not match the number declared at the ICF level.

The Request for Cancellation bulks within the file are counted and the total is compared against NumPCRBlk.






The FileRjctRsn is:

R19: the number of Payment Cancellation Request bulks within the ICF does not match the number declared at the ICF level.

The Return bulks within the file are counted and the total is compared against




Version 20111121 (RB5.0) 113 of 154


NumRETBlk.





The FileRjctRsn is:

R20: the number of RET bulks within the ICF does not match the value declared at the ICF level.

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


The ICF is totally rejected;

In a CVF, OrigFRef and OrigDtTm will be present (for CVF matching, only the Original File Name field is meaningful); and

The bulks contained in the ICF have been validated, and therefore:

The CVF will contain the rejected bulks, and

The StsRsnInf Prtry field will contain the error code.

R23: The ICF has been rejected because each bulk inside was rejected by the STEP2 CS

The Resolution of Investigation bulks within the file are counted and the total is compared against NumROIBlk.






The FileRjctRsn is:

R21: the number of Resolution of Investigation bulks within the ICF does not match the number declared at the ICF level.

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 ICF is totally rejected;

In a CVF, OrigFRef and OrigDtTm will be present (for CVF matching, only the Original File Name field is meaningful)

R24: The ICF has been rejected because the maximum number of accepted ICFs has already been reached.

Table 4-21 ICF Naming & Structure Validation



Version 20111121 (RB5.0) 114 of 154

D.2 Bulks Naming & Structure Validation Process

Error /Reason Code Processing Error report

B00: the bulk is totally accepted. 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 bulk is totally accepted

• All the transactions have been validated

• All the transactions have succeeded the validation of the Interbank Settled Amount, and therefore:

In the CVF OrgnlGrpInfAndSts will all be present and contain meaningful values.

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 bulk is partially accepted

• The CVF contains all the rejected transactions

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

• All the transactions have succeeded the validation of the Interbank Settled Amount, and therefore:

In a CVF OrgnlGrpInfAndSts will all be present and contain meaningful values.

B02: the maximum number of

transactions within one bulk is exceeded.

NbOfTxs is compared against the maximum number of transactions supported in one bulk.

If there is a greater number of transactions in the file than are supported then the file is rejected.


• The bulk is totally rejected

• The transactions contained in the bulk have not been validated therefore the CVF will not contain any rejected transactions

• The StsRsnInf Prtry field will contain the error code

• TxInf/OrgnlTxInfAndSts will not be present

• OrgnlNbOfTxs and OrgnlCtrlSum will be set to zero



Version 20111121 (RB5.0) 115 of 154


B03: the number of transactions within the bulk does not match the

value declared in the GrpHdr

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.







B04: Not used NA NA

B05: TtlIntrBkSttlmAmt or TtlRtrdIntrBkSttlmAmt do not

match the sum of the transactions amounts inside the bulk.

After the completion of pacs.008, or pacs.004 content validation, the number of processed transactions and the number of transactions with a valid "Interbank Settled Amount" or “Returned Settlement amount” are checked.

If these numbers are equal, then the sum of the “Interbank Settled Amount” or ”Returned Settlement amount” from every transaction is verified against TtlIntrBkSttlmAmt or TtlRtrdIntrBkSttlmAmt. If the calculated sum is different from that indicated in the bulk this is rejected.







B06: Not used NA NA

B07: Not used NA NA



Version 20111121 (RB5.0) 116 of 154


B08: the maximum number of bulks in a single file has been

exceeded.

If the maximum have already been accepted then this bulk is rejected.







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 CVF contains all rejected transactions

• All the transactions have been validated

• All the transactions have succeeded the validation of the Interbank Settled Amount

• OrgnlNbOfTxs and OrgnlCtrlSum will contain the values from the original pacs008 bulk

• The StsRsnInf Prtry field will contain the error code.

B10: the bulk is totally rejected because Instructing Agent must

equal the sending institution element must not contain a branch

code and must be present at the group header level.

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







B11: the bulk is totally rejected because Instructed Agent must not

be present at group header level.

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









Version 20111121 (RB5.0) 117 of 154


B12: the bulk is totally rejected because Assgnr/Assgne does not

have the correct value

Assgnr/Assgne does not have the correct value






• OrgnlNbOfTxs will be set to zero

B13: the bulk is totally rejected because TtlIntrBkSttlmAmt is zero

TtlIntrBkSttlmAmt must be greater than zero.







B14: the bulk is totally rejected

because MsgId is duplicated.

The Message Id must be unique The CS generates a CVF as follows:








Version 20111121 (RB5.0) 118 of 154


B15: the bulk is totally rejected because IntrBkSttlmDt is not in the

allowed range.

IntrBkSttlmDt must be present at the bulk level and must be within the allowed range. (see Business Function Document)







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

ClrSys should equal to "ST2" or “ST2nn” when specific settlement cycle is required.

If the settlement cycle specified is already processed or is being processed (Sending cut-off already reached), the bulk is rejected with error code B16.







B17: Not used NA NA

B18: Not used NA NA

B19: Not used NA. NA

B20: Not used NA NA

B21: Not Used NA NA

B22: Not Used NA NA

B23: the bulk is totally rejected because too much 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"



• All the transactions contained in the bulk have not been validated therefore the CVF will not contain any rejected transactions


• The StsRsnInf Prtry field will contain the error code.

B24: the bulk is totally rejected because of incorrect use of bulk

CxlRsn must be used only if entire Bulk is Cancelled and no transaction must be





Version 20111121 (RB5.0) 119 of 154


transaction present in the body of the bulk.







Version 20111121 (RB5.0) 120 of 154

APPENDIX E TRANSACTION ERROR CODES

Where possible, ISO codes are used (refer to ISO definitions). In cases where no ISO code exists, the following STEP2 proprietary error codes are used in the Proprietary field of the message.

Reason

Code

Names Error Description

PY01 Unknown BIC (Routing Table) • The transaction cannot be processed because the Agent bank is unknown to the STEP2 central system.

XD19 Invalid IBAN format • An IBAN in the transaction has failed the ISO 13616 check.

XT13 Unsupported XML field • The transaction contains at least one unsupported field for this file;

The offending XML tag is present with the error code (if available).

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.

XT73 Invalid Country Code • The two characters for country code are not a valid SWIFT country code.

XT74 Invalid Original Transaction Status

• Invalid original transaction status for R-message received, action required.

XT75 Invalid Original Transaction Status

• Invalid original transaction status for R-message received, action not required.

XT77 Original Amount Mismatch • The amount of the original transaction does not match with the amount in the R-message

XT81 XML field not permitted in CT service

� A XML field present in the XML schemas but not permitted in the CT service was used.

XT85 No Settlement Cycle available � No settlement cycle available in the current business date for both Debtor and Creditor Agents.

� For optional settlement cycles, the Debtor Agent is not an Indirect Participant of the Instructing Agent



Version 20111121 (RB5.0) 121 of 154

APPENDIX F REPORT FILE DETAILS

F.1 CRR Cycle Settlement Report

F.1.1 CRR Header

Status Field Name Format Value Position

M Record Type 4x “HCRR” 0

M Service Identifier 3!a “SCT” 4

M File Type 3x "CRR" 7

M Sending Institution 4!a2!a2!c EBAPFRPP 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 Settlement Amount Debit Party Settled

18d 63

M Total Settlement Amount Debit Party Cancelled

18d 81

M Total Settlement Amount Credit Party Settled

18d 99

M Total Settlement Amount Credit Party Cancelled

18d 117

M Total Number Records 6n 135

Table 4-22 CRR Header

*CET (CEST in the summer).

Table 4-23 CRR Debit Party

F.1.2 CRR Debit Party

The CRR Debit Party contains one record for each settlement instruction sent by the STEP2 central system during the processing of the value date to which this CRR relates (if no settlement instructions were sent then no records will be present) where the direct participant receiving this CRR is the debit party. The contents of the fields in each such record are as follows:


M Record Type 4x "CDBB" 0

M Instruction Reference 16x 4

M Credit Party DP BIC 4!a2!a2!c 20

M Credit Party Settlement BIC 4!a2!a2!c3!c 28

M Value of CTRs Settled 18d 39

M Value of Returns Settled 18d 57

M Value of CTRs Cancelled 18d 75

M Value of Returns Cancelled 18d 93

M Total Amount Settled 18d 111

M Total Amount Cancelled 18d 129



Version 20111121 (RB5.0) 122 of 154

Field Name Contents

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.

Value of CTRs settled The value of the CTRs settled in this cycle.

Value of Returns settled The value of the Returns settled this cycle.

Value of CTRs cancelled The value of the CTRs cancelled in this cycle.

Value of Returns cancelled The value of the Returns cancelled this cycle.

Total Amount Settled The amount of settled transactions included in this body.

Total Amount Cancelled The amount of cancelled transactions included in this body.

Table 4-24 CRR Debit Party – field contents


M Record Type 4x "CDBT” 0

Table 4-25 CRR Debit Party trailer

F.1.3 CRR Credit Party


M Record Type 4x "CCRB" 0

M Instruction Reference 16x 4

M Debit Party DP BIC 4!a2!a2!c 20

M Debit Party Settlement BIC 4!a2!a2!c[3!c] 28

M Value of CTRs 18d 39

M Value of Returns 18d 57

M Total Settlement Amount 18d 75

M Settlement Result 4x 93

Table 4-26 CRR Credit Party

The CRR Credit Party contains one record for each settlement instruction sent by the STEP2 central system during the processing of the value date to which this CRR relates (if no settlement instructions were sent then no records will be present) where the direct participant receiving this CRR 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.

Value of CTRs The value of the CTRs included in this body.

Value of Returns The value of the Returns included in this body.

Total Settlement Amount The amount of the settlement instruction included in this body.

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

“PROC”, indicating that the settlement instruction was successfully processed, or “CANC”, indicating that the settlement instruction was cancelled.

Table 4-27 CRR Credit Party – field contents



Version 20111121 (RB5.0) 123 of 154


M Record Type 4x "CCRT” 0

Table 4-28 CRR Credit Party trailer


M Record Type 4x "TCRR” 0

Table 4-29 CRR trailer



Version 20111121 (RB5.0) 124 of 154

F.2 Daily Reconciliation Report (DRR)

F.2.1 DRR header


M Record Type 4x “HDRR” 0

M Service Identifier 3!a SCT 4

M File Type 3x "DRR" 7

M Sending Institution 4!a2!a2!c 10





M Interbank settlement Date 6!n 55


Table 4-30 DRR header

*CET (CEST in the summer).

In case the service supports payment warehousing, the DRR will include data related to:

• Files/bulks/transactions exchanged in that specific processing date, independently from their settlement date; and

• Transactions settled in that specific business date, independently from their exchange date.

F.2.2 DRR files/bulks/transactions sent


M Record Type 4x "DFTH" 0 M Number Files Sent 4n 4 M Number Files Rejected 4n 8 M Number Bulks Sent 4n 12 M Number Bulks Rejected 4n 16 M Number Bulks CRT Sent 4n 20 M Number Bulks CRT Rejected 4n 24 M Number Bulks RET Sent 4n 28 M Number Bulks RET Rejected 4n 32 M Number Bulks PCR Sent 4n 36 M Number Bulks PCR Rejected 4n 40 M Number Bulks ROI Sent 4n 44 M Number Bulks ROI Rejected 4n 48 M Number Credit Transfers Sent 10n 52 M Number Credit Transfers Rejected 10n 62 M Number Credit Transfers Held 10n 72 M Number Credit Transfers Cancelled 10n 82 M Number Credit Transfers Settled 10n 92 M Number Returns Sent 10n 102 M Number Returns Rejected 10n 112 M Number Returns Held 10n 122 M Number Returns Cancelled 10n 132 M Number Returns Settled 10n 142 M Number PCR Sent 10n 152 M Number PCR Rejected 10n 162 M Number ROI Sent 10n 172



Version 20111121 (RB5.0) 125 of 154


M Number ROI Rejected 10n 182 M Value Credit Transfers Sent 18d 192 M Value Credit Transfers Rejected 18d 210 M Value Credit Transfers Held 18d 228 M Value Credit Transfers Cancelled 18d 246 M Value Credit Transfers Settled 18d 264 M Value Returns Sent 18d 282 M Value Returns Rejected 18d 300 M Value Returns Held 18d 318 M Value Returns Cancelled 18d 336 M Value Returns Settled 18d 354 M Value PCR Sent 18d 372 M Value PCR Rejected 18d 390

Table 4-31 DRR files/bulks/transactions sent header

Each DRR contains one and only one DRR files/bulks/transactions sent header record. The contents of the fields in this record are as follows:

Field Name Contents

Number Files Sent The number of times an ICF 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 Files Rejected The number of CVFs indicating complete rejection of a file that were transmitted by the STEP2 central system to this direct participant.

ICFs for which the STEP2 central system transmits an CVF with the codes different from A00 and A01 in the File Reject Reason of the CVF header.

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 CTRs Bulks Sent The total number of CTRs bulks received by the STEP2 central system from this direct participant.

Number CTRs Bulks Rejected The number of CTRs bulks completely rejected by the STEP2 central system to this direct participant.

Number Return Bulks Sent The total number of Return bulks received by the STEP2 central system from this direct participant.

Number Return Bulks Rejected

The number of Return bulks completely rejected by the STEP2 central system to this direct participant.

Number PCR Bulks Sent The total number of PCR bulks received by the STEP2 central system from this direct participant.

Number PCR Bulks Rejected The number of PCR bulks completely rejected by the STEP2 central system to this direct participant.

Number ROI Bulks Sent The total number of ROI bulks received by the STEP2 central system from this direct participant.

Number ROI Bulks Rejected The number of ROI bulks completely rejected by the STEP2 central system to this direct participant.

Number Credit Transfers Sent The number of Credit Transfers instructions received in bulks from this direct participant by the STEP2 central system where the bulk was completely or partially accepted.

Bulks for which the STEP2 central system transmits an CVF bulk with the following codes in the File Reject Reason of the CVF bulk header are included



Version 20111121 (RB5.0) 126 of 154

Field Name Contents

in this field: B00 and B01 (there will be Number Bulk Sent – Number bulks Rejected such files).

The contents of this field will equal:

• The sum of the Total Number Of Transactions fields from each partially or completely accepted bulk, and

• The sum of the following DRR Files Sent Header fields, below:

Number Credit Transfers Rejected,

Number Credit Transfers Held,

Number Credit Transfers Cancelled, and

Number Credit Transfers Settled.

Number Credit Transfers Rejected

The number of Credit Transfers that were rejected from partially accepted bulks received from this direct participant.

Bulks for which the STEP2 central system transmits an CVF bulk with the following codes in the Reason code of the CVF bulk are included in this field: B01. The contents of this field will equal the sum of the contents of the Total Number Rejected fields from each such CVF bulk.

Number Credit Transfers Held The number of Credit Transfers from this direct participant accepted for processing by the STEP2 central system but that have been held in the external settlement mechanism (for future use; currently this will always contain zero).

Number Credit Transfers Cancelled

The number of Credit Transfers that were accepted from this direct participant that have been cancelled by the external settlement mechanism and transmitted by the STEP2 central system to this direct participant in a CCF. The contents of this field will equal the sum of the Total Number Cancelled fields from each such CCF.

Number Credit Transfers Settled

The number of Credit Transfers that were accepted from this direct participant that have been processed by the external settlement mechanism and transmitted by the STEP2 central system to the relevant receiving direct participants in SCFs.

Number Returns Sent The number of Returns instructions received in bulks from this direct participant by the STEP2 central system where the bulk was completely or partially accepted.

Bulks for which the STEP2 central system transmits an CVF bulk with the following codes in the File Reject Reason of the CVF bulk header are included in this field: B00 and B01 (there will be Number Bulk Sent – Number bulks Rejected such files).




Number Returns Rejected,

Number Returns Held,

Number Returns Cancelled, and

Number Returns Settled.

Number Returns Rejected The number of Returns that were rejected from partially accepted bulks received from this direct participant.


Number Returns Held The number of Returns from this direct participant accepted for processing by the STEP2 central system but that have been held in the external settlement mechanism (for future use; currently this will always contain zero).



Version 20111121 (RB5.0) 127 of 154

Field Name Contents

Number Returns Cancelled The number of Returns that were accepted from this direct participant that have been cancelled by the external settlement mechanism and transmitted by the STEP2 central system to this direct participant in a CCF. The contents of this field will equal the sum of the Total Number Cancelled fields from each such CCF.

Number Returns Settled The number of Returns that were accepted from this direct participant that have been processed by the external settlement mechanism and transmitted by the STEP2 central system to the relevant receiving direct participants in SCFs.

Number PCR Sent The number of PCR instructions received in bulks from this direct participant by the STEP2 central system where the bulk was completely or partially accepted.





Number PCR Rejected.

Number PCR Rejected The number of PCR that were rejected from partially accepted bulks received from this direct participant.


Number ROI Sent The number of ROI instructions received in bulks from this direct participant by the STEP2 central system where the bulk was completely or partially accepted.





Number ROI Rejected.

Number ROI Rejected The number of ROI that were rejected from partially accepted bulks received from this direct participant.




Version 20111121 (RB5.0) 128 of 154

Field Name Contents

Value Credit Transfers Sent The value of the Credit Transfers included in the Number Credit Transfers Rejected field of this DRR Files Sent Header.


• The sum of the contents of the Sum Of Amounts fields from each partially or completely accepted bulk, and


Value Credit Transfers Rejected;

Value Credit Transfers Held;

Value Credit Transfers Cancelled; and

Value Credit Transfers Settled.

Value Credit Transfers Rejected

The value of the payments included in the Number Credit Transfers Rejected field of this DRR Files Sent Header. The contents of this field will equal the sum of the contents of the Total Value Credit Transfers Rejected fields from the bulk header of each CVF specified in Number Credit Transfers Rejected.

Value Credit Transfers Held The value of the payments included in the Number Credit Transfers Held field of this DRR Files Sent Header.

Value Credit Transfers Cancelled

The value of the payments included in the Number Credit Transfers Cancelled field of this DRR Files Sent Header.

The contents of this field will equal the sum of the Total Value Credit Transfers Cancelled fields from the header of each CCF transmitted to the direct participant.

Value Credit Transfers Settled The value of the payments included in the Number Credit Transfers Settled field of this DRR Files Sent Header.

Value Returns Sent The value of the Returns included in the Number Returns Rejected field of this DRR Files Sent Header.




Value Returns Rejected;

Value Returns Held;

Value Returns Cancelled; and

Value Returns Settled.

Value Returns Rejected The value of the payments included in the Number Returns Rejected field of this DRR Files Sent Header. The contents of this field will equal the sum of the contents of the Total Value Returns Rejected fields from the bulk header of each CVF specified in Number Returns Rejected.

Value Returns Held The value of the payments included in the Number Returns Held field of this DRR Files Sent Header.

Value Returns Cancelled The value of the payments included in the Number Returns Cancelled field of this DRR Files Sent Header.

The contents of this field will equal the sum of the Total Value Returns Cancelled fields from the header of each CCF transmitted to the direct participant.

Value Returns Settled The value of the payments included in the Number Returns Settled field of this DRR Files Sent Header.



Version 20111121 (RB5.0) 129 of 154

Field Name Contents

Value PCR Sent The value of the PCRs included in the Number RFCs Rejected field of this DRR Files Sent Header.




Value PCRs Rejected.

Value PCR Rejected The value of the PCRs included in the Number PCRs Rejected field of this DRR Files Sent Header. The contents of this field will equal the sum of the contents of the Total Value PCRs Rejected fields from the bulk header of each CVF specified in Number PCRs Rejected.

Table 4-32 DRR files/bulks/transactions sent header – field contents


M Record Type 4x "DTSB" 0 M Bulk Reference 35x 4 M Number Credit Transfers Sent 8n 39 M Number Credit Transfers

Rejected 8n

47 M Number Credit Transfers Held 8n 55 M Number Credit Transfers

Cancelled 8n

63 M Number Credit Transfers

Settled 8n

71 M Value Credit Transfers Sent 18d 79 M Value Credit Transfers

Rejected 18d

97 M Value Credit Transfers Held 18d 115 M Value Credit Transfers

Cancelled 18d

133 M Value Credit Transfers Settled 18d 151 M Process Cycle nr 2n 169

Table 4-33 DRR Credit Transfer bulks sent body

The DRR Credit Transfer bulks sent body contains one record for each Credit Transfer 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

Bulk Reference The reference of the bulk for which the information in this record relates.

Number Credit Transfers Sent The number of Credit Transfers 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 Credit Transfers Rejected

The number of Credit Transfers from this bulk that were rejected by the STEP2 central system.

A CVF containing these Credit Transfers 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 CVF.



Version 20111121 (RB5.0) 130 of 154

Field Name Contents

Number Credit Transfers Held The number of Credit Transfers from this bulk that were accepted for processing by the STEP2 central system but are now held in the external settlement mechanism.

Number Credit Transfers Cancelled

The number of Credit Transfers from this bulk that were accepted by the STEP2 central system but subsequently cancelled by the external settlement mechanism.

A CCF containing these Credit Transfers will have been transmitted to the direct participant and the contents of this field will equal the contents of the Total Number Cancelled field in the header of that CCF Credit Transfers bulk.

Number Credit Transfers Settled

The number of Credit Transfers that were accepted from this bulk, successfully processed by the external settlement mechanism, and transmitted to the relevant receiving direct participants in SCFs bulks.

Value Credit Transfers Sent The value of the Credit Transfers 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 Credit Transfers Rejected

The value of the Credit Transfers from this bulk that were rejected by the STEP2 central system.

A CVF containing these payment instructions 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 CVF bulk.

Value Credit Transfers Held The value of the Credit Transfers from this bulk that were accepted for processing by the STEP2 central system but are now held in the external settlement mechanism.

Value Credit Transfers Cancelled

The value of the Credit Transfers from this bulk that were accepted for processing by the STEP2 central system but subsequently cancelled by the external settlement mechanism.

A CCF containing these Credit Transfers will have been transmitted to the direct participant and the contents of this field will equal the contents of the Total Value Cancelled Credit Transfers bulk field in the header of that CCF bulk.

Value Credit Transfers Settled The value of the Credit Transfers from this bulk that were accepted for processing by the STEP2 central system and settled by the external settlement mechanism.

Process Cycle nr The process cycle in which this bulk was processed by STEP2 CS.

Table 4-34 DRR Credit Transfer bulks sent body – field contents


M Record Type 4x "DRSB" 0 M Bulk Reference 35x 4 M Number Returns Sent 8n 39 M Number Returns Rejected 8n 47 M Number Returns Held 8n 55 M Number Returns Cancelled 8n 63 M Number Returns Settled 8n 71 M Value Returns Sent 18d 79 M Value Returns Rejected 18d 97 M Value Returns Held 18d 115 M Value Returns Cancelled 18d 133 M Value Returns Settled 18d 151 M Process Cycle nr 2n 169

Table 4-35 DRR Return bulks sent body



Version 20111121 (RB5.0) 131 of 154

The DRR Return bulks sent body contains one record for each return 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 Sent The number of Returns received by the STEP2 central system in this bulk.


Number Returns Rejected The number of Returns from this bulk that were rejected by the STEP2 central system.

A CVF containing these 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 CVF.

Number Returns Held The number of Returns from this bulk that were accepted for processing by the STEP2 central system but are now held in the external settlement mechanism.

Number Returns Cancelled The number of Returns from this bulk that were accepted by the STEP2 central system but subsequently cancelled by the external settlement mechanism.

A CCF containing these Returns will have been transmitted to the direct participant and the contents of this field will equal the contents of the Total Number Cancelled return bulk field in the header of that CCF.

Number Returns Settled The number of Returns that were accepted from this bulk, successfully processed by the external settlement mechanism, and transmitted to the relevant receiving direct participants in SCFs.

Value Returns Sent The value of the Returns received by the STEP2 central system in this bulk.

The contents of this field will equal the contents of the transaction Amounts field in the header of this bulk.

Value Returns Rejected The value of the Returns from this bulk that were rejected by the STEP2 central system.

A CVF containing these payment instructions 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 CVF.

Value Returns Held The value of the Returns from this bulk that were accepted for processing by the STEP2 central system but are now held in the external settlement mechanism.

Value Returns Cancelled The value of the Returns from this bulk that were accepted for processing by the STEP2 central system but subsequently cancelled by the external settlement mechanism.

A CCF containing these Returns will have been transmitted to the direct participant and the contents of this field will equal the contents of the Total Value Cancelled return bulk field.

Value Returns Settled The value of the Returns from this bulk that were accepted for processing by the STEP2 central system and settled by the external settlement mechanism.


Table 4-36 DRR Return bulks sent body – field contents


M Record Type 4x "DCSB" 0 M Bulk Reference 35x 4 M Number PCRs Sent 8n 39



Version 20111121 (RB5.0) 132 of 154


M Number PCRs Rejected 8n 47 M Value PCRs Sent 18d 55 M Value PCRs Rejected 18d 73 M Process Cycle nr 2n 91

Table 4-37 DRR PCR bulks sent body

The DRR PCR bulks sent body contains one record for each PCR 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 PCRs Sent The number of PCRs received by the STEP2 central system in this bulk.


Number PCRs Rejected The number of PCRs from this bulk that were rejected by the STEP2 central system.

A CVF containing these PCRs 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 CVF.

Value PCRs Sent The value of the PCRs received by the STEP2 central system in this bulk.

The contents of this field will equal the contents of the transaction Amounts field in the header of this bulk.

Value PCRs Rejected The value of the PCRs from this bulk that were rejected by the STEP2 central system.

A CVF containing these transactions 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 CVF.


Table 4-38 DRR PCR bulks sent body – field contents



Version 20111121 (RB5.0) 133 of 154


M Record Type 4x "DRIB" 0 M Bulk Reference 35x 4 M Number ROIs Sent 8n 39 M Number ROIs Rejected 8n 47 M Process Cycle nr 2n 55

Table 4-39 DRR ROI bulks sent body

The DRR ROI bulks sent body contains one record for each Resolution of Investigation 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 ROIs Sent The number of ROIs received by the STEP2 central system in this bulk.


Number ROIs Rejected The number of ROIs from this bulk that were rejected by the STEP2 central system.

A CVF containing these ROIs 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 CVF.


Table 4-40 DRR ROI bulks sent body – field contents


M Record Type 4x "DFTT” 0

Table 4-41 DRR files/bulks/transactions sent trailer

DRR bulks received


M Record Type 4x "DBRH" 0 M Number bulks Received 4n 4 M Value bulks Received 18d 8 M Number Credit Transfers

Direct 10n


Indirect 10n

36 M Number Returns 10n 46 M Number PCR 10n 56 M Number ROI 10n 66 M Value Credit Transfers

Direct 18d

76 M Value Credit Transfers

Indirect 18d

94 M Value Returns 18d 112 M Value PCR 18d 130

Table 4-42 DRR bulks received header



Version 20111121 (RB5.0) 134 of 154

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

Field Name Contents

Number Bulks Received The number of bulks in SCFs generated by the STEP2 central system for this direct participant during the processing of this interbank settlement date.

Value Bulks Received The sum of the Total Value Settled fields from the header of each SCF generated for this direct participant during the processing of this interbank settlement date.

Number Credit Transfers Direct

The number of Credit Transfers in SCFs generated by the STEP2 central system for this direct participant during the processing of this interbank settlement date where this direct participant is receiving the payment instructions as the beneficiary bank.

Number Credit Transfers Indirect

The number of payment instructions in SCFs generated by the STEP2 central system for this direct participant during the processing of this interbank settlement date where this direct participant is receiving the payment instructions on behalf of an indirect participant as the beneficiary bank.

Number Returns The number of returns in SCFs generated by the STEP2 central system for this direct participant during the processing of this interbank settlement date where this direct participant is receiving the returns.

Number PCR The number of Payment Cancellation Requests in SCFs generated by the STEP2 central system for this direct participant during the processing of this interbank settlement date where this direct participant is receiving the PCR.

Number ROI The number of Resolution of Investigation in SCFs generated by the STEP2 central system for this direct participant during the processing of this interbank settlement date where this direct participant is receiving the ROI.

Value Credit Transfers Direct The value of the payment instructions in identified Number Credit Transfers Direct, above.

Value Credit Transfers Indirect

The value of the payment instructions in identified Number Credit Transfers Indirect, above.

Value Returns The value of the Returns in identified Number Returns, above.

Value PCR The value of the Payment Cancellation Requests in identified Number PCR, above.

Table 4-43 DRR bulks received header – field contents


M Record Type 4x "DTRB" 0

M Bulk Reference 35x 4 M Number Credit Transfers

Direct 8n


Indirect 8n

47 M Value Credit Transfers

Direct 18d 55

M Value Credit Transfers Indirect

18d 73

M Settlement Cycle nr 2n 91

Table 4-44 DRR Credit Transfer bulks received body

The DRR Credit Transfer bulks received body contains one record for each SCF Credit Transfer bulk 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 SCFs were sent then no records will be present). The contents of the fields in each such record are as follows:



Version 20111121 (RB5.0) 135 of 154

Field Name Contents

Bulk Reference The bulk reference of the SCF Credit Transfer bulk to which these statistics relate.

Credit Transfers Direct The number of Credit Transfers in this SCF Credit Transfer bulk where this direct participant is receiving the payment instructions as the beneficiary bank.

Number Credit Transfers Indirect

The number of Credit Transfers in this SCF Credit Transfer bulk where this direct participant is receiving the payment instructions on behalf of an indirect participant as the beneficiary bank.

Value Credit Transfers Direct The value of the Credit Transfers identified in Number Credit Transfers Direct, above.

Value Credit Transfers Indirect

The value of the Credit Transfers identified in Number Credit Transfers Indirect, above.

Settlement Cycle nr The settlement cycle in which this bulk was processed by STEP2 CS.

Table 4-45 DRR Credit Transfer bulks received body – field contents


M Record Type 4x "DRRB" 0

M Bulk Reference 35x 4 M Number Returns 8n 39 M Value Returns 18d 47 M Settlement Cycle nr 2n 65

Table 4-46 DRR Return bulks received body

The DRR bulks received body contains one record for each SCF 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 SCFs were sent then no records will be present). The contents of the fields in each such record are as follows:

Field Name Contents

Bulk Reference The bulk reference of the SCF bulk to which these statistics relate.

Number Returns The number of Returns in this SCF bulk where this direct participant is receiving the payment instructions as returned.

Value Returns The value of the Returns identified in Number Returns, above.

Settlement Cycle nr The settlement cycle in which this bulk was processed by STEP2 CS.

Table 4-47 DRR Return bulks received body – field contents


M Record Type 4x "DRCB" 0

M Bulk Reference 35x 4 M Number PCR 8n 39 M Value PCR 18d 47

Table 4-48 DRR PCR bulks received body

The DRR PCR bulks received body contains one record for each SCF 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 SCFs were sent then no records will be present). The contents of the fields in each such record are as follows:



Version 20111121 (RB5.0) 136 of 154

Field Name Contents


Number PCR The number of Payment Cancellation Requests in this SCF bulk where this direct participant is receiving the PCR.

Value PCR The value of the Payment Cancellation Requests identified in Number PCR, above.

Table 4-49 DRR PCR bulks received body – field contents


M Record Type 4x "DROB" 0

M Bulk Reference 35x 4 M Number ROI 8n 39

Table 4-50 DRR ROI bulks received body

The DRR ROI bulks received body contains one record for each SCF 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 SCFs were sent then no records will be present). The contents of the fields in each such record are as follows:

Field Name Contents


Number ROI The number of Resolution of Investigation in this SCF bulk where this direct participant is receiving the ROI.

Table 4-51 DRR ROI bulks received body – field contents


M Record Type 4x "DBRT” 0

Table 4-52 DRR bulks received trailer

F.2.3 DRR settlement transactions sent


M Record Type 4x "DDBH" 0

M Number Debit Instructions 6n 4

M Number Debit Instructions Cancelled

6n 10

M Value Debit Instructions 18d 16

M Value Debit Instructions Cancelled

18d 34

Table 4-53 DRR settlement transactions sent header

Each DRR contains one and only one DRR settlement transactions sent header record. The contents of the fields in this record are as follows:



Version 20111121 (RB5.0) 137 of 154

Field Name Contents

Number Debit Instructions 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 payments sent body will contain one record for each such settlement instruction.

Number Debit Instruct Cancelled

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

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

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

Table 4-54 DRR settlement payments sent header – field contents


M Record Type 4x "DDBB" 0

M Settlement Reference 16x 4


M Credit Party DP BIC 4!a2!a2!c 26

M Credit Party Settlement BIC 4!a2!a2!c[3!c] 34

M Settlement Amount 18d 45



Table 4-55 DRR transactions sent body

The DRR settlement transactions sent body contains one record for each settlement instruction sent 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 debit party. The contents of the fields in each such record are as follows:

Field Name Contents


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

Interbank settlement date The interbank settlement date during which this instruction was sent for settlement.

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.

Settlement Amount The amount of this settlement instruction.

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


Table 4-56 DRR settlement payments sent body – field contents


M Record Type 4x "DDBT” 0

Table 4-57 DRR settlement transactions sent trailer



Version 20111121 (RB5.0) 138 of 154

F.2.4 DRR settlement transactions received


M Record Type 4x "DCRH" 0

M Number Credit Instruct 6n 4

M Number Credit Instruct Cancelled

6n 10

M Value Credit Instruct 18d 16

M Value Credit Instruct Cancelled

18d 34

Table 4-58 DRR settlement payments received header

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

Field Name Contents

Number Credit Instructions The number of settlement instructions sent 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 payments received body will contain one record for each such settlement instruction.

Number Credit Instruct Cancelled

The number of settlement instructions identified in Number Credit Instruct, above, cancelled by the external settlement mechanism.

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

Value Credit Instruct Cancelled

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

Table 4-59 DRR settlement transactions received header – field contents


M Record Type 4x "DCRB" 0

M Settlement Reference 16x 4


M Debit Party DP BIC 4!a2!a2!c 26

M Debit Party Settlement BIC 4!a2!a2!c[3!c] 34

M Settlement Amount 18d 45



Table 4-60 DRR settlement transactions received body

The DRR settlement payments received body contains one record for each settlement instruction sent 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:



Version 20111121 (RB5.0) 139 of 154

Field Name Contents


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

Interbank settlement Date The interbank settlement date during which this instruction was sent for settlement

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.

Settlement Amount The amount of this settlement instruction.

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


Table 4-61 DRR settlement transactions sent body – field contents


M Record Type 4x "DCRT” 0

Table 4-62 DRR settlement transactions received trailer

F.2.5 DRR trailer


M Record Type 4x "TDRR” 0

Table 4-63 DRR trailer

F.2.6 DRR Record table index

Definition Trailer Record

HDRR DRR Header TDRR

DFTH DRR File/Bulk/Transaction sent DFTT

DTSB DRR Credit Transfer bulks sent body

DRSB DRR Return bulks sent body

DCSB DRR Payment Cancellation Request bulk sent body

DRIB DRR Resolution of Investigation bulk sent body

DBRH DRR bulks received header DBRT

DTRB DRR Credit Transfer bulks received body

DRRB DRR Return bulks received body

DRCB DRR Payment Cancellation Request received body

DROB DRR Resolution of Investigation received body

DDBH DRR Settlement transactions sent header DDBT

DDBB DRR Settlement transactions sent body

DCRH DRR Settlement transactions received header DCRT

DCRB DRR Settlement transactions received body



Version 20111121 (RB5.0) 140 of 154

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. There are two categories of STEP2 service for which the monthly statistics report gives assistance. These are:

� Payments sent; and � Payments received.

F.3.1 MSR header


M Record Type 4x “HMSR” 0

M Service Identifier 3!a SCT 4

M File Type 3x "MSR" 7

M Sending Institution 4!a2!a2!c 10





M Reference Date% 6!n 55


Table 4-64 MSR header

* CET (CEST in the summer). % Reference Date is in YYMMDD format.

F.3.2 MSR body: statistics on transactions sent


M Record Type 4x "MTSH" 0 M Number Credit Transfers Sent 12n 4 M Number Credit Transfers Rejected 12n 16 M Number Credit Transfers Cancelled 12n 28 M Number Credit Transfers Settled 12n 40 M Number Returns Sent 12n 52 M Number Returns Rejected 12n 64 M Number Returns Cancelled 12n 76 M Number Returns Settled 12n 88 M Number PCRs Sent 12n 100 M Number PCRs Rejected 12n 112 M Number ROIs Sent 12n 124 M Number ROIs Rejected 12n 136 M Value Credit Transfers Sent 18d 148 M Value Credit Transfers Rejected 18d 166 M Value Credit Transfers Cancelled 18d 184 M Value Credit Transfers Settled 18d 202



Version 20111121 (RB5.0) 141 of 154


M Value Returns Sent 18d 220 M Value Returns Rejected 18d 238 M Value Returns Cancelled 18d 256 M Value Returns Settled 18d 274 M Value PCR Sent 18d 292 M Value PCR Rejected 18d 310

Table 4-65 MSR transactions sent header


M Record Type 4x "MCTB" 0 M Receiving Participant 4!a2!a2!c 4 M Number Credit Transfers

Accepted 12n 12

M Number Credit Transfers Cancelled

12n 24

M Number Credit Transfers Settled

12n 36

M Value Credit Transfers Accepted

18d 48

M Value Credit Transfers Cancelled

18d 66

M Value Credit Transfers Settled 18d 84

Table 4-66 MSR Credit Transfers sent body


M Record Type 4x "MRTB" 0 M Receiving Participant 4!a2!a2!c 4 M Number Returns Accepted 12n 12 M Number Returns Cancelled 12n 24 M Number Returns Settled 12n 36 M Value Returns Accepted 18d 48 M Value Returns Cancelled 18d 66 M Value Returns Settled 18d 84

Table 4-67 MSR Returns sent body


M Record Type 4x "MRCB" 0 M Receiving Participant 4!a2!a2!c 4 M Number PCRs Accepted 12n 12 M Value PCRs Accepted 18d 24

Table 4-68 MSR PCRs sent body


M Record Type 4x "MRIB" 0 M Receiving Participant 4!a2!a2!c 4 M Number ROIs Accepted 12n 12

Table 4-69 MSR ROIs sent body


M Record Type 4x "MTXT” 0

Table 4-70 MSR transactions sent trailer



Version 20111121 (RB5.0) 142 of 154

F.3.3 MSR body: statistics on transactions received


M Record Type 4x "MTRH" 0

M Number Credit Transfers Received

12n 4

M Number Returns Received 12n 16

M Value Credit Transfers Received

18d 28

M Value Returns Received 18d 46

Table 4-71 MSR transactions received header


M Record Type 4x "MCRB" 0

M Sending Participant 4!a2!a2!c 4

M Number Credit Transfers Received

12n 12

M Value Credit Transfers Received

18d 24

Table 4-72 MSR Credit Transfers received body


M Record Type 4x "MRRB" 0


M Number Returns Received 12n 12

M Value Returns Received 18d 24

Table 4-73 MSR Returns received body


M Record Type 4x "MPRB" 0


M Number PCR Received 12n 12

M Value PCR Received 18d 24

Table 4-74 MSR PCR received body


M Record Type 4x "MIRB" 0


M Number ROI Received 12n 12

Table 4-75 MSR ROI received body


M Record Type 4x "MTRT” 0

Table 4-76 MSR transactions received trailer



Version 20111121 (RB5.0) 143 of 154

F.3.4 MSR trailer


M Record Type 4x "TMSR” 0

Table 4-77 MSR trailer

F.3.5 MSR Record table index

Definition Trailer Record

HMSR MSR Header TMSR

MTSH MSR transactions sent header MTXT

MCTB MSR Credit Transfer sent body

MRTB MSR Return sent body

MRCB MSR Payment Cancellation Request sent body

MRIB MSR Resolution of Investigation sent body

MTRH MSR transactions received header MTRT

MCRB MSR Credit Transfer received body

MRRB MSR Returns received body

MPRB MSR Payment Cancellation Request received body

MIRB MSR Resolution of Investigation received body

21/11/2011

STEP2 SCT


Version 20111121 (RB5.0) 144 of 154

APPENDIX G INTERFACES TO SUPPORTED NETWORKS

Information regarding the Network Configuration can be found in the “STEP2 Technical Configuration” document. (Ref. [18]).

21/11/2011

STEP2 SCT


Version 20111121 (RB5.0) 145 of 154

APPENDIX H SCT ROUTING TABLE

H.1 The STEP2 SCT Routing Table

The Routing Table is available in two different parts: one for Direct Participants and one for Indirect Participants. It can be downloaded directly from the Central System through the use of the Direct Participant Web Station (DPWS).

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 without an End Date, the default value is 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. The “DATE FROM” condition will return all of the entries in the table with Init Date greater than or equal to the inserted value. The “DATE TO” condition will return all of the entries in the table with End Date less than or equal to the inserted value. BIC, NAME and STATUS are self-explanatory.

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 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. Suspended is a temporary status used for emergency conditions.

21/11/2011

STEP2 SCT


Version 20111121 (RB5.0) 146 of 154

DISABLED status

The Participant is in disabled mode and can no longer send or receive any transaction. This status is automatically given to entry with past DATE TO field.

H.4 Payment Type Allowed

This three letters code is used in the case of pre-defined AOS service usage. The identifier is used to check if the sending and receiving bank is part of the AOS service and thus process the transaction accordingly. Note that a blank Payment Type allowed is used for the default SEPA SCT core service. The following values will be inserted in the “Payment Type Allowed” field for both Direct and Indirect Participant Routing Table in order to specify the adherence of the participant to a specific AOS. BIC Routing Table RTF File

Acc. Date

Rem. Info

ITA Trasf.

Payment Type allowed Physical Representation (HX)

BIC A N N N 1 space char 09 20 09

BIC B Y N N AO1 09 41 4F 31 09

BIC C N Y N AO2 09 41 4F 32 09

BIC D Y Y N AO1 AO2 09 41 4F 31 09 41 4F 32 09

BIC E Y Y Y AO1 AO2 AO3 09 41 4F 31 09 41 4F 32 09 41 4F 33 09

H.5 The Routing Table File (FileAct upload)

The RTF sent to Direct Participant via FileAct follows the exact same layout as the one described in the following sections for the Routing Table available through the DPWS. However, the file format is a tab-separated values file and not an Excel file as for the one obtained through the DPWS.

21/11/2011

STEP2 SCT


Version 20111121 (RB5.0) 147 of 154

H.6 SCT Direct Participant Routing Table

H.6.1 Header row

Field name Format Size Description

File Title Text 32x SCT 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 None 50x Bank Name used in search criteria

Date From YYYYMMDD 6x Date From used in search criteria

Date To YYYYMMDD 6x Date To used in search criteria

Status Text 9x Status used in search criteria

Matching Records Integer 4n Number of records returned in search

H.6.5 Results header row 1


Row name Text 7 RESULTS

21/11/2011

STEP2 SCT


Version 20111121 (RB5.0) 148 of 154



Header 2 col. A Text 6 BIC

Header 2 col. B Text 7 NAME

Header 2 col. C Text 9 INIT DATE

Header 2 col. D Text 8 END DATE

Header 2 col. F Text 17 SETTLEMENT BIC

Header 2 col. H Text 6 STATUS

Header 2, col. I Text 20 PAYMENT TYPE ALLOWED

H.6.7 Results row


DP BIC AN BIC (8) BIC(8) format.

DP Name Text 50x Bank name. Free format.

Init Date Date YYYYMMDD Date from which BIC is valid.

End date Date YYYYMMDD Date up to which BIC is valid

Settlement BIC Text BIC (11) The BIC used for settlement of the IP data.

Status Text 9x ENABLED, SUSPENDED, DISABLED

Payment Type Allowed Text See (H.4) A 3-character code indicating the product(s) available to this participant. See (H.4)

The Payment Type Allowed column may repeat up to 10- times for each successive product that the BIC may use. Format is 3 alphanumeric, e.g. A01,A02,A03 etc

21/11/2011

STEP2 SCT


Version 20111121 (RB5.0) 149 of 154

H.7 SCT Indirect Participant Routing Table

H.7.1 Header row


File Title Text 34x SCT 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 AN BIC (11) BIC(11) format. Ending in XXX is permissible.

IP Name Text 50x Bank name. Free format.

Date From Date YYYYMMDD Date from which BIC is valid.

Date To Date YYYYMMDD Date up to which BIC is valid

DP BIC AN BIC (11) The BIC of the associated Direct Participant.

Status Text 9x ENABLED, SUSPENDED, DISABLED

Matching Rows Integer 4n No. of Search Results rows returned

21/11/2011

STEP2 SCT


Version 20111121 (RB5.0) 150 of 154



Row name Text 7x RESULTS



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. I Text 20x PAYMENT TYPE ALLOWED

H.7.7 Results row


IP BIC AN 11x BIC(11) format. Ending in XXX is permissible.

IP Name Text 50x Bank name. Free format.

Init Date Date YYYYMMDD Date from which BIC is valid.

End date Date YYYYMMDD Date up to which BIC is valid

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

DP Settlement BIC Text BIC (11) The BIC used for settlement of the IP data.

Status Text 9x ENABLED, DISABLED

Payment Type Allowed Text See (H.4) A 3-character code indicating the product(s) available to this participant. See (H.4)

The Payment Type Allowed column may repeat up to 10 times for each successive product that the BIC may use. Format is 3 alphanumeric, e.g. A01,A02,A03 etc

21/11/2011

STEP2 SCT


Version 20111121 (RB5.0) 151 of 154

APPENDIX I ERROR CODE REFERENCE LIST

I.1 File Level Codes

File error codes are always used in the CVF header as part of the File Reject Reason (FileRjctRsn) field.

Code Description

A00 ICF totally accepted

A01 ICF partially accepted

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

R08 Unable to process input file

R09 Decompression failed

R10 Schema validation failed

R11 Invalid Sending Institution

R12 Invalid Receiving Institution

R13 Duplicate ICF

R14 Invalid Test Code

R15 Invalid Sending Institution BIC format

R16 Invalid Receiving Institution BIC format.

R18 Credit Transfer bulk number mismatch

R19 Payment Cancellation Request bulk number mismatch

R20 Returns bulk number mismatch

R21 Resolution of Investigation bulk number mismatch

R23 All bulks rejected

R24 Maximum number of ICF received

21/11/2011

STEP2 SCT


Version 20111121 (RB5.0) 152 of 154

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 Pacs002S2

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

B12 Invalid Use of Assgnr/Assgne PRTRY X

B13 Zero Settlement Amount PRTRY X

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

B24 Invalid use of bulk transaction PRTRY X

ED05 Settlement Failed PRTRY X

XT81 Only SEPA core fields are allowed PRTRY X

21/11/2011

STEP2 SCT


Version 20111121 (RB5.0) 153 of 154

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

Pacs004

Camt029

Camt056

Pacs002S2

CUST Requested By Customer ISO X

LEGL Legal Decision ISO X

DUPL Duplicate Payment ISO X

TECH Technical Problem PRTRY X

FRAD Fraudulent Original Credit Transfer PRTRY X

AC01 Incorrect Account Number ISO X

AC04 Closed Account Number ISO X

AC04 Closed Account Number PRTRY X

AC06 Blocked Account ISO X

AG01 Transaction Forbidden ISO X

AG02 Invalid Bank Operation Code ISO X

AM01 Zero Amount ISO X

AM02 Not Allowed Amount ISO X

AM04 Insufficient Funds PRTRY X

NOAS No Answer from Customer PRTRY X

NOOR No Original Transaction Received PRTRY X

AM05 Duplication ISO X X

DT01 Invalid Date ISO X

BE04 Missing Creditor Address ISO X

ED05 Settlement Failed ISO X

FOCR Following Cancellation Request ISO X

MD07 End Customer Deceased ISO X

MS02 Not Specified Reason Customer Generated

ISO X

MS03 Not Specified Reason Agent Generated ISO X

RC01 Bank Identifier Incorrect ISO X

21/11/2011

STEP2 SCT


Version 20111121 (RB5.0) 154 of 154

Code Description Type

Pacs004

Camt029

Camt056

Pacs002S2

RR01 Not Specified Reason Customer Generated

ISO X

RR02

Missing Debtor Name or Address - Code used by banks to indicate a Return for Regulatory Reason

ISO X

RR03

Missing Creditor Name or Address - Code used by banks to indicate a Return for Regulatory Reason

ISO X

RR04 Regulatory Reason ISO X

ARDT Already Returned Transaction PRTRY X

PY01 Unknown BIC in routing table PRTRY X

XD19 Invalid IBAN format PRTRY X

XT13 Unsupported XML field PRTRY X

XT33 Invalid data format PRTRY X

XT73 Invalid country code PRTRY X

XT74 Invalid original transaction status, action required

PRTRY X

XT75 Invalid original transaction status, action not required

PRTRY X

XT77 Original Amount mismatch PRTRY X

XT81 Only SEPA core fields are allowed PRTRY X

XT85 Invalid Settlement Cycle PRTRY X

CANC Used in PCF file

The PCR was processed before the settlement of the original Credit Transfer. The original CT was not settled.

PRTRY X

RCLL the PCR was processed after the settlement of the original Credit Transfer. The CT has been settled/cancelled and the Recall Request was forwarded to the Beneficiary Bank of the original CT.

PRTRY X

1_EBA STEP2 SCT Interface Specifications v20111121 - Updated 20110606 Clean

Documents

Transcript of 1_EBA STEP2 SCT Interface Specifications v20111121 - Updated 20110606 Clean