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
HISTORY OF MODIFICATIONS
Version
0.1 0.2 1.0 1.1 1.2 20070622 20080128 20080505 20081208 20081208 20081208 20091001 20091204
Date
15/09/2006 27/10/2006 21/12/2006 26/01/2007 02/02/2007 22/06/2007 28/01/2008 05/02/2008 15/06/2008 30/07/2008 08/12/2008 01/10/2009 14/12/2009
Authored by
Richard Liblanc Richard Liblanc Richard Liblanc Richard Liblanc Richard Liblanc Richard Liblanc Richard Liblanc Richard Liblanc Richard Liblanc Richard Liblanc David Blanchemanche SIA-SSB SIA-SSB
Status
Draft Draft Draft Draft sent to banks for approval Final Updated Final version for SEPA go live date Corrected version of v20080128 First Draft for version 20081208 Updated version for 20081208 Final version of v20081208 Review for SWIFTNet 6.1 (Par. Error! Reference source not found./3.5.1) 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 20101101 20101101 20101101 20101101 20101101 20101101 20101101
05/02/2010 25/02/2010 10/03/2010 26/03/2010 02/04/2010 28/05/2010 04/06/2010 07/10/2010
SIA-SSB SIA-SSB SIA-SSB SIA-SSB SIA-SSB SIA-SSB SIA-SSB SIA-SSB
First Draft for version 20101101 First review for version 20101101 Review due to errata list for version 20101101 Review due to errata list for version 20101101 Review due to errata list for version 20101101 Review due to errata list for version 20101101 Field Issr now Yellow Review due to errata list for version 20101101 First Draft for version 20111121 Rulebook 5.0 Review due to EPC Errata List (EPC 167-11)
20111121
20111121
25/03/2011
01/06/2011
SIA-SSB
SIA
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) ii of 154 -
21/11/2011
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)
iii of 154
21/11/2011
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)
iv of 154
21/11/2011
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)
v of 154
21/11/2011
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 Senders 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)
vi of 154
21/11/2011
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 F.1.2 F.1.3 CRR Header ............................................................................................................. 121 CRR Debit Party....................................................................................................... 121 CRR Credit Party ..................................................................................................... 122 vii of 154
Version 20111121 (RB5.0)
21/11/2011
F.2 Daily Reconciliation Report (DRR) .............................................................................. 124 F.2.1 F.2.2 F.2.3 F.2.4 F.2.5 F.2.6 F.3.1 F.3.2 F.3.3 F.3.4 F.3.5 DRR header ............................................................................................................. 124 DRR files/bulks/transactions sent .......................................................................... 124 DRR settlement transactions sent .......................................................................... 136 DRR settlement transactions received .................................................................... 138 DRR trailer ............................................................................................................... 139 DRR Record table index .......................................................................................... 139 MSR header ............................................................................................................. 140 MSR body: statistics on transactions sent .............................................................. 140 MSR body: statistics on transactions received ....................................................... 142 MSR trailer .............................................................................................................. 143 MSR Record table index .......................................................................................... 143
F.3 Monthly Statistics Report (MSR) ................................................................................. 140
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.3 Search Criteria header row 2 .................................................................................. 147 H.6.4 Search criteria ......................................................................................................... 147 H.6.5 Results header row 1 .............................................................................................. 147 H.6.6 Results header row 2 .............................................................................................. 148 H.6.7 Results row ............................................................................................................. 148 H.7 SCT Indirect Participant Routing Table ....................................................................... 149 H.7.1 Header row .............................................................................................................. 149 H.7.2 Search Criteria header row 1 .................................................................................. 149 H.7.3 Search Criteria header row 2 .................................................................................. 149 H.7.4 Search Criteria results ............................................................................................. 149 H.7.5 Results header row 1 .............................................................................................. 150 H.7.6 Results header row 2 .............................................................................................. 150 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)
viii of 154
21/11/2011
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)
ix of 154
21/11/2011
Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table
4-48 DRR PCR bulks received body field contents _________________________________ 136 4-49 DRR ROI bulks received body _______________________________________________ 136 4-50 DRR ROI bulks received body field contents__________________________________ 136 4-51 DRR bulks received trailer __________________________________________________ 136 4-52 DRR settlement transactions sent header _____________________________________ 136 4-53 DRR settlement payments sent header field contents __________________________ 137 4-54 DRR transactions sent body ________________________________________________ 137 4-55 DRR settlement payments sent body field contents ____________________________ 137 4-56 DRR settlement transactions sent trailer ______________________________________ 137 4-57 DRR settlement payments received header ____________________________________ 138 4-58 DRR settlement transactions received header field contents _____________________ 138 4-59 DRR settlement transactions received body ____________________________________ 138 4-60 DRR settlement transactions sent body field contents __________________________ 139 4-61 DRR settlement transactions received trailer ___________________________________ 139 4-62 DRR trailer ______________________________________________________________ 139 4-63 MSR header _____________________________________________________________ 140 4-64 MSR transactions sent header ______________________________________________ 141 4-65 MSR Credit Transfers sent body _____________________________________________ 141 4-66 MSR Returns sent body ____________________________________________________ 141 4-67 MSR PCRs sent body ______________________________________________________ 141 4-68 MSR ROIs sent body ______________________________________________________ 141 4-69 MSR transactions sent trailer _______________________________________________ 141 4-70 MSR transactions received header ___________________________________________ 142 4-71 MSR Credit Transfers received body__________________________________________ 142 4-72 MSR Returns received body ________________________________________________ 142 4-73 MSR PCR received body ___________________________________________________ 142 4-74 MSR ROI received body ___________________________________________________ 142 4-75 MSR transactions received trailer ____________________________________________ 142 4-76 MSR trailer ______________________________________________________________ 143
Version 20111121 (RB5.0)
x of 154
21/11/2011
1.
1.1
INTRODUCTION
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
[1] [2] [3]
References
Document Number EPC125-05 EPC115_06 EPC170-05 Title SEPA Credit Transfer Scheme Rulebook Version 5.0 November 2010 SEPA Credit Transfer Scheme Implementation guidelines Version 5.0 November 2010 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 PEACH Model (PE-ACH/CSM Framework). IBAN: International Bank Account Number (Standard) IBAN Standard Implementation Guidelines Country Codes Currency code List Bank Identifier codes Financial services Universal Financial Industry message scheme SEPA Data Model A Glossary of Terms Used in Payments and Settlement Systems The Interbank Convention on Payments The Cross-border Credit Transfer Convention EPC Resolution on Receiver Capability SEPA Credit Transfer Adherence Agreement Errata Implementation Guidelines STEP2 Technical Configuration Issued By EPC EPC EPC
[4] [5] [6] [7] [9] [10] [11] [12]
ISO 13616 SIG 203 ISO 3166 ISO 4217 ISO 9362 ISO 20022 EPC 190-05
ISO ECBS ISO ISO ISO ISO EPC Bank for International Settlements EPC EPC EPC EPC EPC EBA CLEARING
[13] [14] [15] [16] [17] [18]
EPC-0265/03 EPC027-06 EPC041-10 V 0.3
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)
11 of 154
21/11/2011
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
ACL
Meaning
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. 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. 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. A group of Settlement Instructions transmitted to an External Settlement Mechanism in bulk in one message. The unique reference number automatically associated with a Batch Settlement by the Central System. Bank Identification Code. SWIFT standard for identification of banks within payment instructions. 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. The function within EBA that controls the business operation of STEP2. Central System functions that may be used by Business Control to change the times at which processing deadlines are enforced. 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. See Cancelled Credit File. Processing engine used to perform all STEP2 processing activities. Central European Time. Central European Summer Time Customer Information Control System. An IBM product that implements an execution environment for transaction processing. 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. See Cycle Reconciliation Report Central System See Credit Validation File 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. Report transmitted daily to every Direct Participant by the Central System for a Settlement Date that includes summary information to assist reconciliation. A names set of records stored or processed as a unit on the IBM OS/390 file system.
Automatic Routing
Batch Reporting Time
Batch Settlement Batch Settlement Reference BIC Bilateral Gross Settlement
Business Control Business Control Override Cancelled Credit File
CCF Central System CET CEST CICS Credit Validation File
CRR CS CVF Cycle Reconciliation Report
Daily Reconciliation Report
Dataset
Version 20111121 (RB5.0)
12 of 154
21/11/2011
Term
DB2 Direct Participant DRR External Settlement Mechanism File Transfer Protocol FileAct FIN FTP GMT ICF Indirect Participant
Meaning
Relational database platform on IBM OS/390 systems. A bank that may directly transmit files to and directly receive files from the Central System. See Daily Reconciliation Report. External processing system used by STEP2 to process the settlement obligations arising from its processing of bulk payment processing Services. International standard protocol for the exchange of files between two computers connected via a network. A service of SWIFTNet for the secure transmission of files. Secure global network operated by SWIFT. See File Transfer Protocol. Greenwich Mean Time. See Input Credit File. A bank known to the Central System that may receive files payment instructions from the Central System via the services of a Direct Participant. A STEP2-standard file that is used to transmit payment instructions for processing from Direct Participants to the Central System. 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) 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. 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. Queue-based transactional middleware supplied by IBM. See Monthly Statistics Report. See Original File Reference. The function within SIA that controls the technical operation of STEP2. The Senders 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. Current operating system for IBM mainframe platforms. 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. Operating mode of STEP2s secure networks whereby Direct Participants receive files unsolicited from the Central System. See Payment Cancellation Request 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 Resource Access Control Facilities. The security server for the IBM mainframe platform. 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) 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. Negative answer to a Recall of a credit transfer See Resolution of Investigation
Input Credit File Instructed Agent
Instructing Agent
Monthly Statistics Report
MQ Series MSR OFR Operational Control Original File Reference
OS/390 Payment Cancellation Request Push Mode PCR PCF
RACF Recall Procedure
Receiver
Resolution of Investigation ROI

Version 20111121 (RB5.0)
13 of 154
21/11/2011
Term
Routing SCF Security Support Provider Interface Sender
Meaning
The process of selecting a Receiver for a payment instruction. See Settled Credit File. Microsoft Windows 2000 component providing flexible support for different security mechanisms. 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. Unique reference allocated to every STEP2-standard file. The after which ICFs transmitted to the Central System will either be rejected or processed in the following Settlement Cycle. A processing facility offered by STEP2, e.g. -denominated, cross border credit transfers. Three-character identifier used to uniquely identify each STEP2 Service, e.g. SCT. 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. The BIC by which a Direct Participant is known in an External Settlement Mechanism. 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. 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. 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. 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. A unique reference allocated to each Settlement Instruction by the Central System. The time at which the Central System transmits Batch Settlements to an External Settlement Mechanism. Societ Interbancaria per lAutomazione S.p.A. The company that operates STEP2 on behalf of EBA. Secure global IP network operated by SIA-SSB. See Security Support Provider Interface. Secure global IP network operated by SWIFT. Trans-European Automated Real-time Gross settlement Express Transfer system. The EU-wide system for the settlement of euro-denominated gross payments in euro. A unique reference number used to uniquely identify each payment instruction. A set of rules enforce by the Central System on the structure and content of payment instructions and ICFs. 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. Hardware architecture for IBM mainframe computers.
Senders File Reference Sending Cut-Off Time Service Service Identifier Settled Credit File
Settlement BIC Settlement Cut-Off Time
Settlement Cycle
Settlement Date
Settlement Instruction
Settlement Instruction Reference Settlement Time SIA-SBB SIANet SSPI SWIFTNet TARGET
Transaction Identification Validation Rules XML
z/Series
Table 1-1 Glossary

Version 20111121 (RB5.0)
14 of 154
21/11/2011
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)
15 of 154
21/11/2011
2.
2.1
THE STEP2 SYSTEM

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 Credit Transfer File Type XML Message used pacs.008 XML Message Description FI to FI Customer Credit Transfer Payment Cancellation Request pacs.004 Payment Return
Bank to STEP2
Input Credit File (ICF)
Payment Cancellation Request / Payment Recall
camt.056
Return / Positive Answer to CT Recall Negative Answer to a CT Recall
camt.029
STEP2 To Sending Bank STEP2 To Sending Bank STEP2 To Receiving Bank
Confirmation / Rejection of messages received
Credit Validation File (CVF)
pacs.002S2
Resolution of Investigation Payment Status Report Payment Status Report FI to FI Customer Credit Transfer 16 of 154
Settlement Cancellation Messages Notification of Credit Transfer
Cancelled Credit File (CCF)
pacs.002S2
Settled Credit File (SCF)
pacs.008
Version 20111121 (RB5.0)
21/11/2011
Sender
Business Level message according to the Scheme Return / Positive Answer to CT Recall Payment Recall
File Type
XML Message used pacs.004
XML Message Description Payment Return Payment Cancellation Request Resolution of Investigation NA
camt.056
Negative Answer to a CT Recall
camt.029
STEP2 To Direct Participants STEP2 To Direct Participants STEP2 To Direct Participants STEP2 To Direct Participants STEP2 To Direct Participants
Machine Readable Report
Cycle Reconciliation Report (CRR) Payment Cancellation File (PCF)
NA
Payment Status
Pacs.002S2
Daily Reconciliation Report (DRR) Monthly Statistical Report (MSR)
NA
Payment Status Report NA
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)
17 of 154
21/11/2011
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)
18 of 154
21/11/2011
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 STEP2enable payment system.
Webstation Interface
1,7 Network 1,2,3,4,7 Direct Participant Payment System(s)
1,7 1,2,3,4,7 STEP2 Central System
Figure 2-7: Connection via a STEP2-enable payment system
Version 20111121 (RB5.0)
19 of 154
21/11/2011
Flow
1 2 3 4 5 6 7 All
Description
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. Transmission of processed transactions from the STEP2 central system to the Direct Participant. Transmission of exception messages from the STEP2 central system to the Direct Participant. Transmission of reconciliation information (daily and monthly) from the STEP2 central system to the Direct Participant. Execution of enquiries on the central system and the delivery of browser-based reports on online data held within the central system. Internal routing of received transactions within the STEP2 central system. Recovery of information from the STEP2 central system in the event of data loss at the Direct Participant. Interfaces to supported networks.
Table 2-1 Connection via a STEP2-enabled payment system
2.3 2.3.1
STEP2 SCT File Types Input Credit File (ICF)
Direct participants systems must transmit transactions to the central system in Input Credit Files (ICF). Each ICF must have a unique Senders 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 Participants 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)
20 of 154
21/11/2011
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)
21 of 154
21/11/2011
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
2.3.7.1
Reports Files
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 reports 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)
22 of 154
21/11/2011
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)
23 of 154
21/11/2011
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)
24 of 154
21/11/2011
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 3.5.1
File Naming Conventions 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: EEVVSSSBBBBBBBBXX.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; XX (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 XX field is not validated. The STEP2 central system generates files with XX fields as follows: YYMMDDHHMMSSNNN, where: YYMMDDHHMMSS, which is the file creation date and time, and
Version 20111121 (RB5.0)
25 of 154
21/11/2011
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
Senders File Reference (SFR)
The Senders 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 Senders 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)
26 of 154
21/11/2011
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. 2. 3. 4. Credit Transfers; Payment Cancellation Request/Recall; Returns/Positive Answer to Recall; 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 banks 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)
27 of 154
21/11/2011
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 ICFs 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)
28 of 154
21/11/2011
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)
29 of 154
21/11/2011
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: 2. Transaction Routing is set to DIR Instructed Agent is stored and equals the Creditor Agent of the transaction; otherwise
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)
30 of 154
21/11/2011
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)
31 of 154
21/11/2011
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 XML Element Format Description The ISO20022 XML tag name used to identify the field. Where the field is nested under other tags, this nesting is shown. The format of the field that is expected 4a - Four alpha characters (capital) 4n - Four digits 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. 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. Where the Data element exists in the SEPA Credit Transfer Rulebook, as cross-reference has been given. 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
Status
Rule Book reference Validation rules
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.
The timezone (Thh:mm:ss) component is optional, as defined in the definition of the XML data type.
Version 20111121 (RB5.0)
32 of 154
21/11/2011
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)
33 of 154
21/11/2011
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 Rmessages) 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. abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ 0123456789 /-?:().,'+ Space They can choose to receive transactions with non-Latin characters if this is subject to bilateral or multilateral agreements amongst themselves. This will not be checked or controlled by STEP SCT Central System.
A.4
Duplicate Checking
Every transaction must be uniquely identified within the system in order: i) ii) to stop duplication of data, 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 The The The service; message type; reference of the item; and identity of the party that created the reference.
Version 20111121 (RB5.0)
34 of 154
21/11/2011
The following table gives the duplicate checking criteria for different files, bulks and transactions. Service Files ICF Bulks STEP2 generated Bulks Credit Transfers Payment Cancellation Request STEP2 Reject Return SCT SCT SCT Message Type Reference Number File Reference Msg ID Msg ID Bank ID Sending Institution Instructing Agent STEP2 BIC Date -
SCT
FIToFICstmrCdtTrf (pacs.008) FIToFIPmtCxlReq (camt.056) FIToFIPmtStsRptS2 (pacs.002S2) PmtRtr (pacs.004)
Transaction ID
Debtor Agent Original Debtor Agent STEP2 BIC Original Creditor Agent
SCT
Cancellation ID
Interbank Settlement Date Processing Date Processing Date Interbank Settlement Date Processing Date
SCT SCT
Status ID Return ID
Result of Investigation
SCT
RsltnOfInvstgtn Cancellation Original Creditor (camt.029) Status ID Agent 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)
35 of 154
21/11/2011
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.
MessageID ABC
CT
MessageID XYZ
CT
BANK1
STEP2
OrgnlMsgID XYZ
RET
BANK2
OrgnlMsgID XYZ
RET
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.
Version 20111121 (RB5.0)
36 of 154
21/11/2011
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 Instructing Agent Instructed Agent Level Group Header Individual Transaction Group Header Individual Transaction Level Group Header Individual Transaction Group Header Individual Transaction Status Mandatory Not Present Not Present Not Present Status Mandatory Not Present Mandatory Not Present
Camt Messages Field Assigner Assignee
CVF Field Instructing Agent Instructed Agent Level Group Header Individual Transaction Group Header Individual Transaction Status Not Present Not Present Not Present Not Present
SCF Pacs Messages Field Instructing Agent Instructed Agent Level Group Header Individual Transaction Group Header Individual Transaction Level Group Header Individual Transaction Group Header Individual Transaction Status Not Present Mandatory Mandatory Not Present Status Mandatory Mandatory Mandatory Not Present
Camt Messages Field Assigner Assignee
CCF Field Instructing Agent Instructed Agent Level Group Header Individual Transaction Group Header Individual Transaction Status Mandatory Not Present Not Present Mandatory
Version 20111121 (RB5.0)
37 of 154
21/11/2011
PCF Field Instructing Agent Instructed Agent Level Group Header Individual Transaction Group Header Individual Transaction Status Mandatory Not Present Not Present 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 wont 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 wont 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 wont 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)
38 of 154
21/11/2011
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 Message Type Debtor Agent BANK1 BANK1 BANK1 BANK1 BANK1 BANK1 BANK1 Creditor Agent BANK2 BANK2 BANK2 BANK2 BANK2 BANK2 BANK2 BANK2 BANK1 Money transfer Debtor Bank BANK1 Creditor Bank BANK2
CT Pacs.008 (ICF) REJ of CT Pacs.002S2 (CVF) PCR Camt.056 (ICF) REJ of PCR pacs.002S2 (CVF) ROI Camt.029 (ICF) REJ of ROI pacs.002S2 (CVF) RET Pacs.004 (ICF)
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)
39 of 154
21/11/2011
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)
40 of 154
21/11/2011
APPENDIX B XML FILES HEADERS

B.1 INPUT CREDIT FILE (ICF) HEADER
The STEP2 schema SctIcfBlkCdtTrf specifies the ICF. Status

M M M M M M M M M
Field Name
Sending Institution Receiving Institution File Reference Service Identifier Test Code File Type File Date and Time Total Number of pacs.008 Bulks Total Number of camt.056 Payment Cancellation Request bulks Total Number of pacs.004 Bulks Total Number of camt.029 Result of Investigation bulks
XML Element
SndgInst RcvgInst FileRef SrvcId TstCode FType FDtTm NumCTBlk NumPCRBlk
Format
4!a2!a2!c 4!a2!a2!c 16!c 3!a 1!a 3!a ISODateTime 8n 8n
Notes
It must always be the BIC of the Direct Participant sending the file. The STEP2 BIC. The Direct Participant reference of the ICF. Must be SCT Must be always T or P, depending on the environment used Must be always ICF. The file creation Date and Time The total number of Credit Transfers bulks contained in the ICF. The total number of Payment Cancellation Requests bulks contained in the ICF. The total number of Returns bulks contained in the ICF. The total number of Resolution of Investigation bulks contained in the ICF.
M M
NumRFRBlk NumROIBlk
8n 8n
Table 4-5 Input Credit File (ICF) XML Header Elements
Version 20111121 (RB5.0)
41 of 154
21/11/2011
B.2
XML Credit Validation File (CVF) Header
The CVF is specified by the STEP2 schema SctCvfBlkCdtTrf. Status

M M
Field Name
Sending Institution Receiving Institution
XML Element
SndgInst RcvgInst
Format
4!a2!a2!c 4!a2!a2!c
Notes
The STEP2 SCT CS BIC code. 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). The STEP2 service identifier : SCT Always T or P, depending on the environment used Always CVF. The STEP2 reference of the CVF. The file creation Date and Time In circumstances where it has not been possible to gather this information OrigFRef will not be present. Original ICF File Name. On circumstances where it has not been possible to gather this information OrigDtTm will not be present. The ICF reject reason code. (see Appendix D) The business date in which this file was created by the STEP2 central system. The cycle in which this file was created by the STEP2 central system.
M M M M M O
Service Identifier Test Code File Type File Reference File Date and Time Original File Reference
SrvcId TstCode Ftype FileRef FDtTm OrigFRef
3!a 1!a 3!a 16!c ISODateTi me
16c
M O
Original File Name Original Date And Time
OrigFName OrigDtTm
32x ISO Date & Time
M M
File Reject Reason File Business Date
FileRjctRsn FileBusDt
3!c
ISO Date
File Cycle Number
FileCycleNo
2!n
Table 4-6 Credit Validation File (CVF) XML Header Elements
Version 20111121 (RB5.0)
42 of 154
21/11/2011
B.3
XML Settled Credit File (SCF) STEP2 File Header
The SCF is specified by the STEP2 schema SCTScfBlkCdtTrf. Status Field Name XML Element
M M M M M M M Sending Institution Receiving Institution Service Identifier Test Code File Type File Reference Routing Indicator SndgInst RcvgInst SrvcId TstCode FType FileRef RoutingInd 4!a2!a2!c 4!a2!a2!c 3!a 1!a 3!a 16!c 3!a The STEP2 CS BIC code. The BIC of the Direct Participant receiving the file. Must be SCT Must be always T or P, depending on the environment used Must be always SCF. The SCF file reference The routing Indicator DIR: Direct Participant File IND: Indirect Participant File ALL: Both RET: Return File M M File Business Date File Cycle Number FileBusDt FileCycleNo ISO Date 2!n The business date in which this file was created by the STEP2 central system. The cycle in which this file was created by the STEP2 central system.
Format
Notes
Table 4-7 Settled Credit File (SCF) STEP2 File Header
Version 20111121 (RB5.0)
43 of 154
21/11/2011
B.4
XML Cancelled Credit File (CCF) STEP2 File Header
The CCF is specified by the STEP2 schema SCTCcfBlkCdtTrf. Status Field Name XML Element
M M M M M M M M Sending Institution Receiving Institution Service Identifier Test Code File Type File Reference File Business Date File Cycle Number SndgInst RcvgInst SrvcId TstCode FType FileRef FileBusDt FileCycleNo 4!a2!a2!c[3! c] 4!a2!a2!c 3!a 1!a 3!a 16!c ISO Date 2!n The STEP2 CS BIC code. The BIC of the Direct Participant receiving the file. Must be SCT Must be always T or P, depending on the environment used Must be always CCF. The CCF file reference The business date in which this file was created by the STEP2 central system. The cycle in which this file was created by the STEP2 central system.
Format
Notes
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. Status Field Name XML Element
M M M M M M M M Sending Institution Receiving Institution Service Identifier Test Code File Type File Reference File Business Date File Cycle Number SndgInst RcvgInst SrvcId TstCode FType FileRef FileBusDt FileCycleNo 4!a2!a2!c 4!a2!a2!c 3!a 1!a 3!a 16!c ISO Date 2!n The STEP2 CS BIC code. The BIC of the Direct Participant receiving the file. Must be SCT Must be always T or P, depending on the environment used Must be always PCF. The PCF file reference The business date in which this file was created by the STEP2 central system. The settlement cycle in which this file was created by the STEP2 central system.
Format
Notes
Table 4-9 Payment Cancellation File (PCF) STEP2 File Header
Version 20111121 (RB5.0)
44 of 154
21/11/2011
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
1.1
XML Tag
GrpHdr +MsgId
Format
35x
Status
M
Rulebook Ref
NA
EPC SCT Implementation Guidelines - Usage rules
STEP2 Usage Rules and Validations

ICF: The DPs bulk reference. SCF: STEP2s 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 1.4
GrpHdr +CreDtTm GrpHdr +NbOfTxs
ISODate &Time 15n
M M
NA NA
The date & time in which this bulk was created by the DP. 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)
45 of 154
21/11/2011
Index
1.6
XML Tag
GrpHdr +TtlIntrBkSttlmAmt
Format
18d EUR
Status
M M
Rulebook Ref
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.
Attribute
1.7
GrpHdr +IntrBkSttlmDt
ISO DATE
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
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
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)
46 of 154
21/11/2011
Index
1.32
XML Tag
GrpHdr +InstgAgt ++FinInstnId +++BIC
Format
4!a2!a2!c
Status
C
Rulebook Ref
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. Used only in SCF: error code B11; and Equals Receiving Inst element in SCF: error code B11.
1.33
GrpHdr +InstdAgt ++FinInstnId +++BIC
4!a2!a2!c
NA
The DP receiving this bulk.
Table 4-10 SCT Credit Transfer (pacs008) Bulk Header
Version 20111121 (RB5.0)
47 of 154
21/11/2011
C.1.2 SCT Credit Transfer (pacs.008) Individual Transaction

Index
2.2
XML tag
CdtTrfTxInf +PmtId ++InstrId
Format
35x
Status
O
Rulebook Ref
NA
STEP2 Usage Rules and Validation Rules

The Instruction Id. This identification cannot include leading, trailing or internal spaces (schema validation).
2.3
CdtTrfTxInf +PmtId ++EndToEndId
35x **CW** 35x
AT-41
2.4
CdtTrfTxInf +PmtId ++TxId
AT-43
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. Must contain a reference that is meaningful to the Originators Bank and is unique over time.
The End to End Id. The Transaction Id. Uniqueness is checked under the rules for duplicate checking: error code AM05; and This identification cannot include leading, trailing or internal spaces (schema validation). The Identification Code of the Scheme Must be SEPA (schema validation).
2.10
CdtTrfTxInf +PmtTpInf ++SvcLvl ++Cd
4!a
AT-40
Only SEPA is allowed.
2.13
CdtTrfTxInf +PmtTpInf ++LclInstrm +++Cd
35x **CW**
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)
48 of 154
21/11/2011
Index
2.14
XML tag
CdtTrfTxInf +PmtTpInf ++LclInstrm +++Prtry
Format
35x
Status
C
Rulebook Ref
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; This identification cannot include leading, trailing or internal spaces (schema validation).
2.16
CdtTrfTxInf +PmtTpInf ++CtgyPurp +++Cd
4x **CW**
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). Cannot be used at the same time as Prtry (below) (schema validation); and This is not checked by the CS (schema validation).
2.17
CdtTrfTxInf +PmtTpInf ++CtgyPurp +++Prtry
35x **CW**
AT-45
The Category Purpose of the transaction Proprietary. Cannot be used at the same time as Cd (above) (schema validation); and This is not checked by the CS (schema validation).
Version 20111121 (RB5.0)
49 of 154
21/11/2011
Index
2.18
XML tag
CdtTrfTxInf +IntrBkSttlmAmt
Format
18d EUR
Status
M M
Rulebook Ref
AT-04

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 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.
Attribute
2.19 2.29 2.31 CdtTrfTxInf +IntrBkSttlmDt CdtTrfTxInf +AccptncDtTm CdtTrfTxInf +InstdAmt 18d 3!a 11d 4!a 18d 3!a O M O M O M NA NA NA Only SLEV validation). is allowed (schema NA ISO DATE ISO Date O O NA NA
The Interbank Settlement Date The Acceptance Date & Time. The Instructed Amount
Attribute
2.32 2.33 2.35 CdtTrfTxInf +XchgRate CdtTrfTxInf +ChrgBr CdtTrfTxInf +ChrgsInf ++Amt
The Exchange rate of the Credit Transfer. The Charge Bearer The Charges Amount. Only one validation). occurrence is allowed (schema
Attribute
Version 20111121 (RB5.0)
50 of 154
21/11/2011
Index
2.36
XML tag
CdtTrfTxInf +ChrgsInf ++Pty +++FinInstnId ++++BIC CdtTrfTxInf + PrvsInstgAgt ++ FinInstnId +++BIC CdtTrfTxInf +InstgAgt ++FinInstnId +++BIC
Format
4!a2!a2!c [3!c]
Status
O
Rulebook Ref
NA

The Charges Party. Only one validation). occurrence is allowed (schema
2.37
4!a2!a2!c [3!c]
NA
The Previous Instructing Agent.
2.39
4!a2!a2!c [3!c]
NA
The DP originating this Credit Transfer. Used in SCF only: error code XT13.
2.47
CdtTrfTxInf +UltmtDbtr ++Nm CdtTrfTxInf +UltmtDbtr ++PstlAdr +++Ctry CdtTrfTxInf +UltmtDbtr ++PstlAdr +++AdrLine
70x **CW** 2!a
AT-08
Name is limited to 70 characters in length.
The Name of the Originator Reference Party.
2.47
C NA
Country of the Ultimate Debtor address.
2.47
70x **CW**
O NA
The Ultimate Debtor address. Address line can have a maximum of two occurrences. (schema validation)
Version 20111121 (RB5.0)
51 of 154
21/11/2011
Index
2.47
XML tag
CdtTrfTxInf +UltmtDbtr ++Id +++OrgId
Format
See Schema
Status
C
Rulebook Ref

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. Cannot be used at the same time as Id/OrgId (above) (schema validation); Only one occurrence of Othr is allowed (schema validation); All of the ISO options are available (see ISO document or schema).
AT-09 2.47 CdtTrfTxInf +UltmtDbtr ++Id +++PrvtId See Schema C Either Date and Place of Birth or one occurrence of Other is allowed. AT-09
The identification of the Ultimate Debtor: Private Id.
2.47
CdtTrfTxInf +UltmtDbtr ++CtryOfRes CdtTrfTxInf +Dbtr ++Nm
2!a
O NA
The Country of Residence of the Ultimate Debtor.
2.49
70x **CW** 2!a
AT-02
The Name of the Debtor.
2.49
CdtTrfTxInf +Dbtr ++PstlAdr +++Ctry
AT-03
Country of the Debtor address. Must be a valid country code according to ISO 3166. Error code: XT73.
Version 20111121 (RB5.0)
52 of 154
21/11/2011
Index
2.49
XML tag
CdtTrfTxInf +Dbtr ++PstlAdr +++AdrLine CdtTrfTxInf +Dbtr ++Id +++OrgId
Format
70x **CW** See schema
Status
O
Rulebook Ref
AT-03

Only two occurrences are allowed.

The Debtor address. Address line can have a maximum of two occurrences (schema validation).
2.49
AT-10
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); 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.49
CdtTrfTxInf +Dbtr ++Id +++PrvtId
See schema
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); Only one occurrence of Othr is allowed (schema validation); All of the ISO options are available (see ISO document or schema).
2.49
CdtTrfTxInf +Dbtr ++CtryOfRes
2!a
NA
The Country of Residence of the Debtor.
Version 20111121 (RB5.0)
53 of 154
21/11/2011
Index
2.50
XML tag
CdtTrfTxInf +DbtrAcct ++Id +++IBAN
Format
2!a2!n30 x
Status
M
Rulebook Ref
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. Must be an active DP or IP: error code PY01.
2.51 CdtTrfTxInf +DbtrAgt ++FinInstnId +++BIC CdtTrfTxInf +CdtrAgt ++FinInstnId +++BIC CdtTrfTxInf +Cdtr ++Nm CdtTrfTxInf +Cdtr ++PstlAdr +++Ctry CdtTrfTxInf +Cdtr ++PstlAdr +++AdrLine 4!a2!a2!c [3!c] M AT-06 Only BIC is allowed.
The Debtor Agent BIC.
2.53
4!a2!a2!c [3!c]
AT-23
The Creditor Agent BIC.Must be an active DP or IP: error code PY01.
2.55
70x **CW** 2!a
AT-21
The Name of the Creditor.
2.55
AT-22
Country of the Creditor address. Must be a valid country code according to ISO3166. Error code: XT73. Address line can have a maximum of two occurrences. (schema validation).
2.55
70x **CW**
AT-22
Only two occurrences are allowed.
The Creditor address.
Version 20111121 (RB5.0)
54 of 154
21/11/2011
Index
2.55
XML tag
CdtTrfTxInf +Cdtr ++Id +++OrgId
Format
See schema
Status
C
Rulebook Ref
AT-24


The identification of the Creditor (Beneficiary identification code): 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.55
CdtTrfTxInf +Cdtr ++Id +++PrvtId
See schema
AT-24
The identification of the Creditor (Beneficiary identification code): Private ID. Cannot be used at the same time as Id/OrgId (above) (schema validation); Only one occurrence of Othr is allowed (schema validation); All of the ISO options are available (see ISO document or schema).
2.55
CdtTrfTxInf +Cdtr ++CtryOfRes CdtTrfTxInf +CdtrAcct ++Id +++IBAN
2!a
NA
The Country of Residence of the Creditor.
2.56
2!a2!n30 x
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)
55 of 154
21/11/2011
Index
2.57
XML tag
CdtTrfTxInf +UltmtCdtr ++Nm CdtTrfTxInf +UltmtCdtr ++PstlAdr +++Ctry CdtTrfTxInf +UltmtCdtr ++PstlAdr +++AdrLine CdtTrfTxInf +UltmtCdtr ++Id +++OrgId
Format
70x **CW** 2!a
Status
O
Rulebook Ref
AT-28


The Name of the Beneficiary Reference Party.
2.57
NA
Country of the Ultimate Creditor address.
2.57
70x **CW** See Schemas
NA
The Ultimate Creditor Address. Address line can have a maximum of two occurrences (schema validation). 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. Cannot be used at the same time as Id/OrgId (above) (schema validation); A Only one occurrence of Othr is allowed (schema validation); ll of the ISO options are available (see ISO document or schema).
2.57
AT-29
The identification of the Ultimate Creditor: Organisation Id.
2.57
CdtTrfTxInf +UltmtCdtr ++Id +++PrvtId
See Schemas
AT-29
The identification of the Ultimate Creditor: Private Id.
Version 20111121 (RB5.0)
56 of 154
21/11/2011
Index
2.57
XML tag
CdtTrfTxInf +UltmtCdtr ++CtryOfRes CdtTrfTxInf +InstrForCdtrAgt ++Cd
Format
Status
Rulebook Ref
NA NA

The Country of Residence of the Ultimate Creditor.
2!a 4!a
O O
2.59
The Instruction for Creditor Agent (ISO20022 code). All of the ISO options are available (see ISO document or schema).
2.60
CdtTrfTxInf +InstrForCdtrAgt ++InstrInf
140x **CW** 4x **CW**
NA
The Instruction for Creditor Agent.
2.65
CdtTrfTxInf +Purp ++Cd
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** See Schema
AT-44
The Purpose of the transaction (Proprietary). Cannot be used at the same time as Code (above) (schema validation).
2.67
CdtTrfTxInf +RgltryRptg
NA
The Regulatory Reporting. All ISO20022 validation). fields are supported (schema
2.68
CdtTrfTxInf +RltdRmtInf
See Schema
NA
The Related Remittance Information. All ISO20022 validation). fields are supported (schema
Version 20111121 (RB5.0)
57 of 154
21/11/2011
Index
2.76
XML tag
CdtTrfTxInf +RmtInf ++Ustrd
Format
140x **CW**
Status
C
Rulebook Ref
AT-05

Unstructured may carry structured remittance information, as agreed between the Originator and the Beneficiary. Only one occurrence Unstructured is allowed. of

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. 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: 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. Referred Document Information.
2.77
CdtTrfTxInf +RmtInf ++Strd
140x
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.
2.78
CdtTrfTxInf +RmtInf ++Strd +++RfrdDocInf
See Schema
AT-05
2.86
CdtTrfTxInf +RmtInf ++Strd +++RfrdDocAmt
See Schema
AT-05
Referred Document Amount.
Version 20111121 (RB5.0)
58 of 154
21/11/2011
Index
2.100
XML tag
CdtTrfTxInf +RmtInf ++Strd +++CdtrRefInf ++++Tp +++++CdOrPrtry ++++++Cd
Format
4!a
Status
O
Rulebook Ref
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**
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**
AT-05
Creditor Reference Information Type Issuer.
Version 20111121 (RB5.0)
59 of 154
21/11/2011
Index
2.103
XML tag
CdtTrfTxInf +RmtInf ++Strd +++CdtrRefInf ++++Ref
Format
35x **CW**
Status
O
Rulebook Ref
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. When used both Type and Reference must be present (schema validation).
2.104 CdtTrfTxInf +RmtInf ++Strd +++Invcr 2.105 CdtTrfTxInf +RmtInf ++Strd +++Invcee 2.106 CdtTrfTxInf +RmtInf ++Strd +++AddtlRmtInf **CW** 140x O AT-05 See Schema O AT-05 See Schema O AT-05
Invoicer.
Invoicee.
Additional Remittance Information.
Table 4-11 SCT Credit Transfer (pacs.008) Individual Transaction
Version 20111121 (RB5.0)
60 of 154
21/11/2011
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
1.1
XML Element
Assgnmt +Id
Format
35x
Status
M
Rulebook Ref
EPC SCT Implementation Guidelines Usage Rules

The Identifier of the assignment. ICF: The DPs assignment reference; SCF: STEP2 CS assignment reference; and The identification cannot include leading, trailing or internal spaces (schema validation). Must equal SndgInst element in ICF and must not contain a branch code: error code B12.
1.2
1.5
1.8
Assgnmt +Assgnr ++Agt +++FinInstnId ++++BIC Assgnmt +Assgne ++Agt +++FinInstnId ++++BIC Assgnmt +CreDtTm
4!a2!a2!c
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. For SCF: the DP receiving this assignment. For ICF: the STEP2 CS BIC. Error code B12.
4!a2!a2!c
Instructed Party Limited to BIC to identify a bank or CSM or Name to indicate the CSM when it has no BIC.
ISODate &Time
The date & time in which this bulk was created by the DP.
Index
3.1
XML Element
CtrlData +NbOfTxs
Format
15n
Status
M
Rulebook Ref

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)
61 of 154
21/11/2011
3.2
CtrlData +CtrlSum
18d
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 EPC SCT Implementation STEP2 Validation Rules Ref Guidelines Usage 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). The Cancellation Identification. Uniqueness is checked under the rules for duplicate checking. Error code AM05; and
4.22
Undrlyg +TxInf ++CxlId
35x
AT-R7
Mandatory This element must be transported up to the Creditor Agent.
4.30
Undrlyg +TxInf ++OrgnlGrpInf +++OrgnlMsgId
35x
NA
This identification cannot include leading, trailing or internal spaces (schema validation). 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)
62 of 154
21/11/2011
Index
4.31
XML Acronym
Undrlyg +TxInf ++OrgnlGrpInf +++OrgnlMsgNmId Undrlyg +TxInf ++OrgnlInstrId Undrlyg +TxInf ++OrgnlEndToEndId Undrlyg +TxInf ++OrgnlTxId
Format
35x
Status
M
Rulebook Ref
NA

Only pacs.008.001.02 is allowed.
STEP2 Validation Rules

The type of XML message bulk to be cancelled. Must always equal to pacs.008* (use of wildcard in validation) (schema validation).
4.33
35x
NA
The Original instruction Identifier. This identification cannot include leading, trailing or internal spaces (schema validation). The Original End to End Identifier. 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.34
35x ** CW ** 35x
AT-41
Mandatory Mandatory
4.35
AT-43
4.37
Undrlyg +TxInf ++OrgnlIntrBkSttlmAmt
18d
AT-04
Attribute
3!a
This identification cannot include leading, trailing or internal spaces (schema validation). 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)
63 of 154
21/11/2011
Index
4.38
XML Acronym
Undrlyg +TxInf ++OrgnlIntrBkSttlmDt
Format
ISO DATE
Status
M
Rulebook Ref
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. The DP originating this assignment. Only used in SCF. Error code XT13
4.39
4.42
Undrlyg +TxInf ++Assgnr +++FinInstnId ++++BIC Undrlyg +TxInf +CxlRsnInf ++Orgtr +++Nm Undrlyg +TxInf ++CxlRsnInf +++Orgtr ++++Id +++++OrgId ++++++BICOrBEI Undrlyg +TxInf ++CxlRsnInf +++Rsn ++++Cd
4!a2!a2!c
NA
70x ** CW **
R2
Limited to BIC for an Agent or Name for a non-financial institution.
The party originating (customer).
the
request
for
cancellation
4.42
4!a2!a2!c [3!c]
AT-R2
Cannot be used at the same time as Originator/BICOrBEI (see below) (schema validation). The party originating the request for cancellation (bank). Cannot be used at the same time as Originator/Name (see above) (schema validation).
4.44
4!a
AT-48
The Payment Cancellation (ISO20022 code).
Request
Reason
Code
4.45
Undrlyg +TxInf ++CxlRsnInf +++Rsn ++++Prtry
35x ** CW **
AT-48
Must be used with a valid code (schema validation); and Cannot be used at the same time as Prtry (see below) (schema validation). The Request for Cancellation Reason Code. Cannot be used at the same time as Code (see above) (schema validation).
Version 20111121 (RB5.0)
64 of 154
21/11/2011
Index
4.47
XML Acronym
Undrlyg +TxInf ++OrgnlTxRef
Format
Status
M
Rulebook Ref

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
4.47
4.47
4.47
Undrlyg +TxInf ++OrgnlTxRef +++SttlmInf ++++SttlmMtd Undrlyg +TxInf ++OrgnlTxRef +++SttlmInf ++++ClrSys +++++Prtry Undrlyg +TxInf ++OrgnlTxRef +++PmtTpInf ++++SvcLvl +++++Cd Undrlyg +TxInf ++OrgnlTxRef +++PmtTpInf ++++LclInstrm +++++Cd
4!a
NA
The Settlement Method. Only CLRG is allowed (schema validation).
35x
NA
Proprietary identification of the Clearing System. Value must be ST2: error code XT33.
4!a
AT-40 The Service Level Code. Must be SEPA (schema validation).
35x ** CW **
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)
65 of 154
21/11/2011
Index
4.47
XML Acronym
Undrlyg +TxInf ++OrgnlTxRef +++PmtTpInf ++++LclInstrm +++++Prtry
Format
35x
Status
C
Rulebook Ref
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
4.47
Undrlyg +TxInf ++OrgnlTxRef +++PmtTpInf ++++CtgyPurp Undrlyg +TxInf +OrgnlTxRef ++RmtInf +++Ustrd
See schema
AT-45 The category purpose.
140x ** CW **
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. 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.47
Undrlyg +TxInf +OrgnlTxRef ++RmtInf +++Strd
140x
AT-05
Version 20111121 (RB5.0)
66 of 154
21/11/2011
Index
4.47
XML Acronym
Undrlyg +TxInf ++OrgnlTxRef +++RmtInf ++++Strd +++++RfrdDocInf Undrlyg +TxInf ++OrgnlTxRef +++RmtInf ++++Strd +++++RfrdDocAmt Undrlyg +TxInf ++OrgnlTxRef +++RmtInf ++++Strd +++++CdtrRefInf ++++++Tp +++++++CdOrPrtry ++++++++Cd Undrlyg +TxInf ++OrgnlTxRef +++RmtInf ++++Strd +++++CdtrRefInf ++++++Tp +++++++CdOrPrtry ++++++++Prtry
Format
See Schema
Status
O
Rulebook Ref
AT-05

Referred Document Information.
4.47
See Schema
AT-05
4!a
AT-05
35x ** CW **
AT-05
Version 20111121 (RB5.0)
67 of 154
21/11/2011
Index
XML Acronym
Undrlyg +TxInf ++OrgnlTxRef +++RmtInf ++++Strd +++++CdtrRefInf ++++++Tp +++++++Issr Undrlyg +TxInf ++OrgnlTxRef +++RmtInf ++++Strd +++++CdtrRefInf ++++++Ref Undrlyg +TxInf ++OrgnlTxRef +++RmtInf ++++Strd +++++Invcr Undrlyg +TxInf ++OrgnlTxRef +++RmtInf ++++Strd +++++Invcee Undrlyg +TxInf ++OrgnlTxRef +++RmtInf ++++Strd +++++AddtlRmtInf
Format
35x ** CW **
Status
O
Rulebook Ref
AT-05

35x ** CW **
AT-05
4.47
See Schema
AT-05
Invoicer.
4.47
See Schema
AT-05
Invoicee.
4.47
140x ** CW **
AT-05
Version 20111121 (RB5.0)
68 of 154
21/11/2011
Index
4.47
XML Acronym
Undrlyg +TxInf ++OrgnlTxRef +++UltmtDbtr Undrlyg +TxInf ++OrgnlTxRef +++Dbtr ++++Nm Undrlyg +TxInf ++OrgnlTxRef +++Dbtr ++++PstlAdr +++++Ctry Undrlyg +TxInf ++OrgnlTxRef +++Dbtr ++++PstlAdr +++++AdrLine Undrlyg +TxInf ++OrgnlTxRef +++Dbtr ++++Id +++++OrgId
Format
See schema
Status
O
Rulebook Ref
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
70x ** CW **
AT-02 The Debtor Name.
4.47
2!a
AT-03
The Debtor Country. Must be a valid country code according to ISO 3166. Error code: XT73
4.47
70x ** CW **
AT-03
The Debtor Postal Address Lines. Up to two occurrences are supported (schema validation).
4.47
See Schema
AT-10
The identification of the 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 XML Schema).
Version 20111121 (RB5.0)
69 of 154
21/11/2011
Index
4.47
XML Acronym
Undrlyg +TxInf ++OrgnlTxRef +++Dbtr ++++Id +++++PrvtId
Format
See Schema
Status
C
Rulebook Ref
AT-10

The identification of the Debtor: Private Id. Cannot be used at the same time as Id/OrgId (above) (schema validation); Only one occurrence of Othr is allowed (schema validation); All of the ISO options are available (see ISO document or XML Schema).
4.47
4.47
4.47
4.47
Undrlyg +TxInf ++OrgnlTxRef +++Dbtr ++++CtryOfRes Undrlyg +TxInf ++OrgnlTxRef +++DbtrAcct ++++Id +++++IBAN Undrlyg +TxInf ++OrgnlTxRef +++DbtrAgt ++++FinInstnId +++++BIC Undrlyg +TxInf ++OrgnlTxRef +++CdtrAgt ++++FinInstnId +++++BIC
2!a
NA The Debtor Country of Residence.
2!a2!n30 x
AT-01 The Debtor Account.
4!a2!a2!c [3!c]
AT-06
The Debtor Agent BIC. Must be present in the CS repository. Error Code XT74.
4!a2!a2!c [3!c]
AT-23 The Creditor Agent.
Version 20111121 (RB5.0)
70 of 154
21/11/2011
Index
4.47
XML Acronym
Undrlyg +TxInf ++OrgnlTxRef +++Cdtr ++++Nm Undrlyg +TxInf ++OrgnlTxRef +++Cdtr ++++PstlAdr +++++Ctry Undrlyg +TxInf ++OrgnlTxRef +++Cdtr ++++PstlAdr +++++AdrLine Undrlyg +TxInf ++OrgnlTxRef +++Cdtr ++++Id +++++OrgId
Format
70x ** CW **
Status
M
Rulebook Ref
AT-21
The Creditor Name.
4.47
2!a
AT-22
The Creditor Country. Must be a valid country code according to ISO 3166. Error code: XT73
4.47
70x ** CW **
AT-22
The Creditor Postal Address Lines. Up to two occurrences are supported (schema validation).
4.47
See Schema
AT-24
The identification of the Creditor: 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 XML Schema). Cannot be used at the same time as Id/OrgId (above) (schema validation); Only one occurrence of Othr is allowed (schema validation); All of the ISO options are available (see ISO document or XML Schema).
4.47
Undrlyg +TxInf ++OrgnlTxRef +++Cdtr ++++Id +++++PrvtId
See Schema
AT-24
The identification of the Creditor: Private Id.
Version 20111121 (RB5.0)
71 of 154
21/11/2011
Index
4.47
XML Acronym
Undrlyg +TxInf ++OrgnlTxRef +++Cdtr ++++CtryOfRes Undrlyg +TxInf ++OrgnlTxRef +++CdtrAcct ++++Id +++++IBAN Undrlyg +TxInf ++OrgnlTxRef +++UltmtCdtr
Format
2!a
Status
O
Rulebook Ref
NA
The Creditor Country of Residence.
4.47
2!a2!n30 x
AT-20 The Creditor Account.
4.47
See schema
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)
72 of 154
21/11/2011
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
1.1
XML Element
Assgnmt +Id
Format
35x
Status
M
Rulebook Ref
EPC SCT Implementation Guidelines Usage Rule


The Identifier of the assignment. ICF: The DPs assignment reference; SCF: STEP2 CS assignment reference; and The identification cannot include leading, trailing or internal spaces (schema validation). Must equal SndgInst element in ICF and must not contain a branch code: error code B12. For SCF: the STEP2 CS BIC. For ICF: the STEP2 CS BIC. Error code B12.
1.2
1.5
1.8
Assgnmt +Assgnr ++Agt +++FinInstnId ++++BIC Assgnmt +Assgne ++Agt +++FinInstnId ++++BIC Assgnmt +CreDtTm
4!a2!a2!c
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.
4!a2!a2!c
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.
ISODate &Time
The date & time in which this bulk was created by the DP.
Index
3.1
XML Element
Sts +Conf
Format
4!a
Status
M
Rulebook Ref
EPC SCT Implementation Guidelines Usage Rule

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)
73 of 154
21/11/2011
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
4.72
XML Acronym
CxlDtls +TxInfAndSts
Format
See below
Status
M
Rulebook Ref
See below

Mandatory
Validation Rules
Transaction Information and Status. At least one transaction must be present (schema validation). The Cancellation Identification. Uniqueness is checked under the rules for duplicate checking. Error code AM05; and
4.73
CxlDtls +TxInfAndSts ++CxlStsId
35x
NA
4.81
CxlDtls +TxInfAndSts ++OrgnlGrpInf +++OrgnlMsgId
35x
NA
This identification cannot include leading, trailing or internal spaces (schema validation). 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. Must always equal to pacs.008* (use of wildcard in validation) (schema validation).
4.82
CxlDtls +TxInfAndSts ++OrgnlGrpInf +++OrgnlMsgNmId CxlDtls +TxInfAndSts ++OrgnlInstrId
35x
NA
Only pacs.008.001.02 is allowed.
The type of XML message bulk to be cancelled.
4.84
35x
NA
The Original instruction Identifier of the pacs 008.
Version 20111121 (RB5.0)
74 of 154
21/11/2011
Index
4.85
XML Acronym
CxlDtls +TxInfAndSts ++OrgnlEndToEndId CxlDtls +TxInfAndSts ++OrgnlTxId CxlDtls +TxInfAndSts ++TxCxlSts CxlDtls +TxInfAndSts ++CxlStsRsnInf +++Orgtr ++++Nm CxlDtls +TxInfAndSts ++CxlStsRsnInf +++Orgtr ++++Id +++++OrgId ++++++BICOrBEI CxlDtls +TxInfAndSts ++CxlStsRsnInf +++Rsn ++++Cd
Format
35x ** CW ** 35x
Status
M
Rulebook Ref
AT-41

Mandatory
Validation Rules
The Original End to End Identifier of the pacs 008.
4.86
AT-43
Mandatory The Original Transaction Identifier of the pacs 008.
4.88
4!a
NA
Only RJCR is allowed
Transaction Cancellation Status. Only the value RJCR is allowed (schema validation). The party originating the Resolution of Investigation (customer). Cannot be used at the same time as Originator/BICOrBEI (below) (schema validation). The party originating the Resolution of Investigation (bank). Cannot be used at the same time as Originator/Name (above) (schema validation).
4.90
70x ** CW **
NA
4.90
4!a2!a2!c [3!c]
AT-R2
4.92
4!a
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)
75 of 154
21/11/2011
Index
4.93
XML Acronym
CxlDtls +TxInfAndSts ++CxlStsRsnInf +++Rsn ++++Prtry CxlDtls +TxInfAndSts ++CxlStsRsnInf +++AddtlInf
Format
35x ** CW **
Status
C
Rulebook Ref
AT-R6
Validation Rules
The Resolution Proprietary. of Investigation Reason Code
Cannot be used at the same time as Code (above) (schema validation).
4.94
105x ** CW **
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). The DP originating this assignment. Only used in SCF. Error code XT13.
4.101
4.107
CxlDtls +TxInfAndSts ++Assgnr +++Agt ++++FinInstnId +++++BIC CxlDtls +TxInfAndSts ++OrgnlTxRef
4!a2!a2!c
NA
See Schema
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
NA The original Interbank Settlement Date.
Version 20111121 (RB5.0)
76 of 154
21/11/2011
Index
4.107
XML Acronym
CxlDtls +TxInfAndSts ++OrgnlTxRef +++SttlmInf ++++SttlmMtd CxlDtls + TxInfAndSts ++OrgnlTxRef +++SttlmInf ++++ClrSys +++++Prtry CxlDtls +TxInfAndSts ++OrgnlTxRef +++PmtTpInf ++++SvcLvl +++++Cd CxlDtls +TxInfAndSts ++OrgnlTxRef +++PmtTpInf ++++LclInstrm +++++Cd CxlDtls +TxInfAndSts ++OrgnlTxRef +++PmtTpInf ++++LclInstrm +++++Prtry
Format
4!a
Status
M
Rulebook Ref
NA
Validation Rules
The Settlement Method. Only CLRG is allowed (schema validation).
4.107
35x
NA
Proprietary identification of the Clearing System. Value must be ST2: error code XT33.
4.107
4!a
AT-40 The Service Level Code. Must be SEPA (schema validation).
4.107
35x ** CW **
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
35x
NA
The indication of the scheme or service. Cannot be used at the same time as Code (above) (schema validation). 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)
77 of 154
21/11/2011
Index
4.107
XML Acronym
CxlDtls +TxInfAndSts ++OrgnlTxRef +++PmtTpInf ++++CtgyPurp CxlDtls +TxInfAndSts +OrgnlTxRef ++RmtInf +++Ustrd
Format
See schema
Status
O
Rulebook Ref
AT-45
Validation Rules
The category purpose.
4.107
140x ** CW **
AT-05
4.107
CxlDtls +TxInfAndSts +OrgnlTxRef ++RmtInf +++Strd
140x
AT-05
4.107
CxlDtls +TxInfAndSts ++OrgnlTxRef +++RmtInf ++++Strd +++++RfrdDocInf
See Schema
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. 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. Referred Document Information.
Version 20111121 (RB5.0)
78 of 154
21/11/2011
Index
4.107
XML Acronym
CxlDtls +TxInfAndSts ++OrgnlTxRef +++RmtInf ++++Strd +++++RfrdDocAmt CxlDtls +TxInfAndSts ++OrgnlTxRef +++RmtInf ++++Strd +++++CdtrRefInf ++++++Tp +++++++CdOrPrtry ++++++++Cd CxlDtls +TxInfAndSts ++OrgnlTxRef +++RmtInf ++++Strd +++++CdtrRefInf ++++++Tp +++++++CdOrPrtry ++++++++Prtry CxlDtls +TxInfAndSts ++OrgnlTxRef +++RmtInf ++++Strd +++++CdtrRefInf ++++++Tp +++++++Issr
Format
See Schema
Status
O
Rulebook Ref
AT-05
Validation Rules
4.107
4!a
AT-05
4.107
35x ** CW **
AT-05
4.107
35x ** CW **
AT-05
Version 20111121 (RB5.0)
79 of 154
21/11/2011
Index
4.107
XML Acronym
CxlDtls +TxInfAndSts ++OrgnlTxRef +++RmtInf ++++Strd +++++CdtrRefInf ++++++Ref CxlDtls +TxInfAndSts ++OrgnlTxRef +++RmtInf ++++Strd +++++Invcr CxlDtls +TxInfAndSts ++OrgnlTxRef +++RmtInf ++++Strd +++++Invcee CxlDtls +TxInfAndSts ++OrgnlTxRef +++RmtInf ++++Strd +++++AddtlRmtInf CxlDtls +TxInfAndSts ++OrgnlTxRef +++UltmtDbtr CxlDtls +TxInfAndSts ++OrgnlTxRef +++Dbtr ++++Nm
Format
35x ** CW **
Status
O
Rulebook Ref
AT-05
Validation Rules
4.107
See Schema
AT-05
Invoicer.
4.107
See Schema
AT-05
Invoicee.
4.107
140x ** CW **
AT-05
4.107
See schema
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
70x ** CW **
Version 20111121 (RB5.0)
80 of 154
21/11/2011
Index
4.107
XML Acronym
CxlDtls +TxInfAndSts ++OrgnlTxRef +++Dbtr ++++PstlAdr +++++Ctry CxlDtls +TxInfAndSts ++OrgnlTxRef +++Dbtr ++++PstlAdr +++++AdrLine CxlDtls +TxInfAndSts ++OrgnlTxRef +++Dbtr ++++Id +++++OrgId
Format
2!a
Status
O
Rulebook Ref
AT-03
Validation Rules
4.107
70x ** CW **
AT-03
The Debtor Postal Address Lines. Up to two occurrences are supported (schema validation).
4.107
See Schema
AT-10
The identification of the 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 XML Schema).
4.107
CxlDtls +TxInfAndSts ++OrgnlTxRef +++Dbtr ++++Id +++++PrvtId
See Schema
NA
4.107
CxlDtls +TxInfAndSts ++OrgnlTxRef +++Dbtr ++++CtryOfRes
2!a
Version 20111121 (RB5.0)
81 of 154
21/11/2011
Index
4.107
XML Acronym
CxlDtls +TxInfAndSts ++OrgnlTxRef +++DbtrAcct ++++Id +++++IBAN CxlDtls +TxInfAndSts ++OrgnlTxRef +++DbtrAgt ++++FinInstnId +++++BIC CxlDtls +TxInfAndSts ++OrgnlTxRef +++CdtrAgt ++++FinInstnId +++++BIC CxlDtls +TxInfAndSts ++OrgnlTxRef +++Cdtr ++++Nm CxlDtls +TxInfAndSts ++OrgnlTxRef +++Cdtr ++++PstlAdr +++++Ctry CxlDtls +TxInfAndSts ++OrgnlTxRef +++Cdtr ++++PstlAdr +++++AdrLine
Format
2!a2!n30 x
Status
M
Rulebook Ref
AT-01
Validation Rules
The Debtor Account.
4.107
4!a2!a2!c [3!c]
AT-06 The Debtor Agent BIC.
4.107
4!a2!a2!c [3!c]
AT-23 The Creditor Agent.
4.107
70x ** CW **
AT-21 The Creditor Name.
4.107
2!a
AT-22
4.107
70x ** CW **
AT-22
The Creditor Postal Address Lines. Up to two occurrences are supported (schema validation).
Version 20111121 (RB5.0)
82 of 154
21/11/2011
Index
4.107
XML Acronym
CxlDtls +TxInfAndSts ++OrgnlTxRef +++Cdtr ++++Id +++++OrgId
Format
See Schema
Status
C
Rulebook Ref
AT-24
Validation Rules
The identification of the Creditor: 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 XML Schema).
4.107
CxlDtls +TxInfAndSts ++OrgnlTxRef +++Cdtr ++++Id +++++PrvtId
See Schema
AT-24
The identification of the Creditor: Private Id. Cannot be used at the same time as Id/OrgId (above) (schema validation); Only one occurrence of Othr is allowed (schema validation); All of the ISO options are available (see ISO document or XML Schema).
4.107
4.107
4.107
CxlDtls +TxInfAndSts ++OrgnlTxRef +++Cdtr ++++CtryOfRes CxlDtls +TxInf ++OrgnlTxRef +++CdtrAcct ++++Id +++++IBAN CxlDtls +TxInf ++OrgnlTxRef +++UltmtCdtr
2!a
NA The Creditor Country of Residence.
2!a2!n30 x
AT-20 The Creditor Account IBAN.
See schema
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)
83 of 154
21/11/2011
Table 4-15 - SCT Resolution of Investigation (camt.029) - Individual Transaction Details
Version 20111121 (RB5.0)
84 of 154
21/11/2011
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
GrpHdr +MsgId GrpHdr +CreDtTm GrpHdr +InstgAgt ++FinInstnId +++BIC
Format
35x ISODate &Time 4!a2!a2!c[3 !c]
Status
M M C The STEP2 CS bulk reference.
STEP2 Usage Rules
The date & Time in which this bulk was created by the STEP2 CS. 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)
85 of 154
21/11/2011
C.4.2 SCT Reject (pacs.002S2) in CVF,CCF and PCF - Original Group Information And Status
XML Element
OrgnlGrpInfAndSts +OrgnlMsgId OrgnlGrpInfAndSts +OrgnlMsgNmId
Format
35x 35x
Status
M M The Message Id of the original bulk
STEP2 Usage Rules
OrgnlGrpInfAndSts +OrgnlNbOfTxs OrgnlGrpInfAndSts +OrgnlCtrlSum OrgnlGrpInfAndSts +GrpSts
15n 18d
M 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 The total number of transactions received within the original bulk. 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 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 The STEP2 CS BIC.
4!a
OrgnlGrpInfAndSts +StsRsnInf ++Orgtr +++Id ++++OrgId +++++BICOrBEI OrgnlGrpInfAndSts +StsRsnInf ++Rsn +++Cd OrgnlGrpInfAndSts +StsRsnInf ++Rsn +++Prtry
4!a2!a2!c[3 !c]
4!a
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 The indication of the error code of the bulk. Code is STEP2 Specific (proprietary). For PCF 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. files the value is always set to PCR
35x
Version 20111121 (RB5.0)
86 of 154
21/11/2011
XML Element
OrgnlGrpInfAndSts +NbOfTxsPerSts ++DtldNbOfTxs OrgnlGrpInfAndSts +NbOfTxsPerSts ++DtldSts OrgnlGrpInfAndSts +NbOfTxsPerSts ++DtldCtrlSum OrgnlGrpInfAndSts +NbOfTxsPerSts ++DtldNbOfTxs OrgnlGrpInfAndSts +NbOfTxsPerSts ++DtldSts OrgnlGrpInfAndSts +NbOfTxsPerSts ++DtldCtrlSum
Format
15n
Status
C
STEP2 Usage Rules

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. The status of the transactions (Accepted). Status = ACCP for CVF and CCF RJCT for PCF Present if Group Status is PART. 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. 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. The status of the transactions (Rejected). Status = RJCT for CVF and CCF PDNG for PCF Present if Group Status is PART. 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.
4!a
18d
15n
4!a
18d
Table 4-17 SCT Reject (pacs.002S2) in CVF, CCF and PCF - Original Group Information And Status
Version 20111121 (RB5.0)
87 of 154
21/11/2011
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
TxInfAndSts +StsId TxInfAndSts +OrgnlInstrId TxInfAndSts +OrgnlEndToEndId TxInfAndSts +OrgnlTxId TxInfAndSts +TxSts
Format
35x 35x 35x 35x 4!a
Status
M O M M M
STEP2 Usage Rules

The Status Report Message Identification (generated by the Central System). The Instruction ID of the original CT; populated only if it was present in the original CT. The End to End Id of the original CT. The Id of the original transaction (Id is specific to the original message type). 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 The STEP2 CS system BIC.
TxInfAndSts +StsRsnInf ++Orgtr +++Id ++++OrgId +++++BICOrBEI TxInfAndSts +StsRsnInf ++Rsn +++Cd
4!a2!a2!c[3!c]
4!a
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)
88 of 154
21/11/2011
XML Acronym
TxInfAndSts +StsRsnInf ++Rsn +++Prtry
Format
35x
Status
C
STEP2 Usage Rules

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. The Instructed Agent BIC (Instructed Agent obtained from the original transaction). Present only in CCF and PCF.
TxInfAndSts +InstdAgt ++FinInstnId +++BIC TxInfAndSts +OrgnlTxRef ++IntrBkSttlmAmt
4!a2!a2!c[3!c]
18d
The Amount of the original transaction. Depending on the type of the original message, this can either be:
Attribute
EUR
TxInfAndSts +OrgnlTxRef ++IntrBkSttlmDt
ISODate
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 The Original Interbank Settlement Date.
Version 20111121 (RB5.0)
89 of 154
21/11/2011
XML Acronym
TxInfAndSts +OrgnlTxRef ++DbtrAgt +++FinInstnId ++++BIC TxInfAndSts +OrgnlTxRef ++CdtrAgt +++FinInstnId ++++BIC
Format
4!a2!a2!c[3!c]
Status
M
STEP2 Usage Rules

The Original Debtor Agent.
4!a2!a2!c[3!c]
The Original Creditor Agent.
Table 4-18 SCT Reject (pacs.002S2) in CVF, CCF and PCF Individual Transaction
Version 20111121 (RB5.0)
90 of 154
21/11/2011
C.5
STEP2 Usage of pacs.004 (Return)
C.5.1 SCT Return (pacs.004) Bulk Header SCF & ICF

Index
1.1 GrpHdr +MsgId
XML Element
Format
35x
Status
M
Rulebook Ref
NA

The bulk reference of the generating party. ICF: Direct Participant reference SCF: STEP2 reference Uniqueness is checked for ICF: error code B14; and This identification cannot include leading, trailing or internal spaces (schema validation). The date & time in which this bulk was created by the DP. 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. 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.
1.2 1.7
GrpHdr +CreDtTm GrpHdr +NbOfTxs
ISO Date & Time 15n
M M
NA NA
1.10
GrpHdr +TtlRtrdIntrBkSttlmAmt
18d EUR
M M
NA
The Value of the transactions included in this bulk.
Attribute
Version 20111121 (RB5.0)
91 of 154
21/11/2011
Index
1.11
XML Element
GrpHdr +IntrBkSttlmDt
Format
ISODate
Status
M
Rulebook Ref
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. Only the value CLRG is supported (schema validation).
1.13
GrpHdr +SttlmInf ++SttlmMtd GrpHdr +SttlmInf ++ClrSys +++Prtry GrpHdr +InstgAgt ++FinInstnId +++BIC
4!a
NA
Only CLRG, allowed.
INGA
and
INDA
are
Information on settlement method.
1.15
35x
NA
The Identifier of the Clearing System. Only the value ST2 is supported: error code B16. 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.24
4!a2!a2!c
NA
The DP originating this bulk.
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)
92 of 154
21/11/2011
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
3.1 TxInf +RtrId
XML Element
Format
35x
Status
M
Rulebook Ref
AT-R5 (Return) Mandatory
STEP2 Usage Rules and Validation

The Return Identification Uniqueness is checked under the rules for duplicate checking: error code AM05; and
3.3
TxInf +OrgnlGrpInf ++OrgnlMsgId
35x
NA
This identification cannot include leading, trailing or internal spaces. (schema validation) 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. This identification cannot include leading, trailing or internal spaces (schema validation). The type of XML message bulk to be Returned. For SCT Service: must always equal to pacs.008* (use of wildcard in schema validation).
3.4
TxInf +OrgnlGrpInf ++OrgnlMsgNmId
35x
NA
Version 20111121 (RB5.0)
93 of 154
21/11/2011
Index
3.6
XML Element
TxInf +OrgnlInstrId
Format
35x
Status
O
Rulebook Ref
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). The original End to End Id. The original Transaction Id. This identification cannot include leading, trailing or internal spaces. (schema validation) 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).
3.7 3.8
TxInf +OrgnlEndToEndId TxInf +OrgnlTxId
35x ** CW ** 35x
M M
AT-41 AT-43
Mandatory Mandatory Must contain a reference that is meaningful to the Originators Bank and is unique over time. Mandatory Amount must be 0.01 or more and 999999999.99 or less. The fractional part has maximum of two digits.
3.10
TxInf +OrgnlIntrBkSttlmAmt
18d 3!a
AT-04
Attribute
Version 20111121 (RB5.0)
94 of 154
21/11/2011
Index
3.11
XML Element
TxInf +RtrdIntrBkSttlmAmt
Format
18d 3!a
Status
M M
Rulebook Ref
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. 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 amount of this transaction (Return). .
Attribute
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 Currency attribute must be EUR (schema validation); 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)
95 of 154
21/11/2011
Index
3.13
XML Element
TxInf +RtrdInstdAmt Attribute
Format
18d 3!a
Status
C
Rulebook Ref
NA Only allowed in the case of a return in response to a cancellation request, ie, Reason in Return Reason Information specifies FOCR. 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 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 Currency attribute must be EUR (schema validation); 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
NA
The Charge Bearer Information. Only the value SLEV is allowed (schema validation).
Version 20111121 (RB5.0)
96 of 154
21/11/2011
Index
3.18
XML Element
TxInf +ChrgsInf ++Amt
Format
18d 3!a
Status
C
Rulebook Ref
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;
Attribute
3.19
3.20
TxInf +ChrgsInf ++Pty +++FinInstnId ++++BIC TxInf +InstgAgt ++FinInstnId +++BIC TxInf +RtrRsnInf ++Orgtr +++Nm
4!a2!a2!c[3 !c]
AT-23
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. The Charges Party (BIC). Only one occurrence is allowed (schema validation).
4!a2!a2!c
NA
The DP originating this Return. Must be present in the SCF only: error code XT13. The Customer originating this transaction. Cannot be used at the same time as Originator/BIC (see below) (schema validation).
3.23
70x ** CW **
AT-R2
Version 20111121 (RB5.0)
97 of 154
21/11/2011
Index
3.23
XML Element
TxInf +RtrRsnInf ++Orgtr +++Id ++++OrgId +++++BICOrBEI TxInf +RtrRsnInf ++Rsn +++Cd
Format
4!a2!a2!c[3 !c]
Status
C
Rulebook Ref
AT-R2

The Party originating this transaction. Cannot be used at the same time as Originator/Name (see above) (schema validation). 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). The Return Reason Code (STEP2). Cannot be used at the same time than Code (see above) (schema validation). Additional Information is 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). The Original Interbank Settlement Date.
3.25
4!c
AT-R3
3.26
3.27
TxInf +RtrRsnInf ++Rsn +++Prtry TxInf +RtrRsnInf ++AddtlInf
35x ** CW ** 105x
NA
AT-R7
Only one occurrence allowed. Only allowed when present in Reason. FOCR
** CW **
3.35
3.39
TxInf +OrgnlTxRef ++IntrBkSttlmDt TxInf +OrgnlTxRef ++SttlmInf +++SttlmMtd
ISO DATE
AT-42
4!a
NA
The Settlement Method. Only the value CLRG is allowed (schema validation).
Version 20111121 (RB5.0)
98 of 154
21/11/2011
Index
3.51
XML Element
TxInf +OrgnlTxRef ++PmtTpInf +++SvcLvl ++++Cd TxInf +OrgnlTxRef ++PmtTpInf +++LclInstrm ++++Cd TxInf +OrgnlTxRef ++PmtTpInf +++LclInstrm ++++Prtry
Format
4!a
Status
M
Rulebook Ref
AT-40

The Transaction Service Level. Must be SEPA (schema validation).
3.51
35x ** CW **
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. 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; This identification cannot include leading, trailing or internal spaces (schema validation).
3.51
35x
NA
The Payment Type Information.
3.51
TxInf +OrgnlTxRef ++PmtTpInf +++CtgyPurp ++++Cd
4x ** CW **
AT-45
The Category Purpose of the transaction (ISO 20022 Code values). Cannot be used at the same time as Prtry (below) (schema validation); and This is not checked by the CS (schema validation).
3.51
TxInf +OrgnlTxRef ++PmtTpInf +++CtgyPurp ++++Prtry
35x ** CW **
AT-45
The Category Purpose of the transaction Proprietary. Cannot be used at the same time as Cd (above) (schema validation); and This is not checked by the CS (schema validation).
Version 20111121 (RB5.0)
99 of 154
21/11/2011
Index
3.84
XML Element
TxInf +OrgnlTxRef ++RmtInf +++Ustrd
Format
140x ** CW **
Status
C
Rulebook Ref
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. 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: 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.
3.84
TxInf +OrgnlTxRef ++RmtInf +++Strd
140x
AT-05
TxInf +OrgnlTxRef ++RmtInf +++Strd ++++RfrdDocInf TxInf +OrgnlTxRef ++RmtInf +++Strd ++++RfrdDocAmt
See Schema
AT-05
Referred Document Information.
See Schema
AT-05
Version 20111121 (RB5.0)
100 of 154
21/11/2011
Index
3.123
XML Element
TxInf +OrgnlTxRef ++RmtInf +++Strd ++++CdtrRefInf +++++Tp ++++++CdOrPrtry +++++++Cd TxInf +OrgnlTxRef ++RmtInf +++Strd ++++CdtrRefInf +++++Tp ++++++CdOrPrtry +++++++Prtry TxInf +OrgnlTxRef ++RmtInf +++Strd ++++CdtrRefInf +++++Tp ++++++Issr TxInf +OrgnlTxRef ++RmtInf +++Strd ++++CdtrRefInf +++++Ref TxInf +OrgnlTxRef ++RmtInf +++Strd ++++Invcr
Format
4!a
Status
O
Rulebook Ref
AT-05

35x ** CW **
AT-05
3.123
35x ** CW **
AT-05
3.123
35x ** CW **
AT-05
See Schema
AT-05
Invoicer.
Version 20111121 (RB5.0)
101 of 154
21/11/2011
Index
XML Element
TxInf +OrgnlTxRef ++RmtInf +++Strd ++++Invcee TxInf +RmtInf ++Strd +++AddtlRmtInf TxInf +OrgnlTxRef ++UltmtDbtr +++Nm TxInf +OrgnlTxRef ++UltmtDbtr +++PstlAdr ++++Ctry TxInf +OrgnlTxRef ++UltmtDbtr +++PstlAdr ++++AdrLine TxInf +OrgnlTxRef ++UltmtDbtr +++Id ++++OrgId
Format
See Schema
Status
O
Rulebook Ref
AT-05

Invoicee.
140x ** CW **
AT-05
3.116
70x ** CW ** 2!a
AT-08
The Ultimate Debtor Name.
Country of the Ultimate Debtor address. O NA
70x ** CW ** O NA
The Ultimate Debtor Address. Address line can have a maximum of two occurrences. (schema validation).
3.116
The identification of the Ultimate Debtor: Organisation Id. See Schema C AT-09 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.
Version 20111121 (RB5.0)
102 of 154
21/11/2011
Index
3.116 TxInf
XML Element
Format
Status
Rulebook Ref

The identification of the Ultimate Debtor: Private Id. Cannot be used at the same time as Id/OrgId (above) (schema validation); Only one occurrence of Othr is allowed (schema validation); All of the ISO options are available (see ISO document or schema).
+OrgnlTxRef ++UltmtDbtr +++Id ++++PrvtId
See Schema
AT-09
TxInf +OrgnlTxRef ++UltmtDbtr +++CtryOfRes TxInf +OrgnlTxRef ++Dbtr +++Nm TxInf +OrgnlTxRef ++Dbtr +++PstlAdr ++++Ctry TxInf +OrgnlTxRef ++Dbtr +++PstlAdr ++++AdrLine 2!a O NA
The Country of Residence of the Ultimate Debtor.
3.117
70x ** CW ** 2!a
3.117
AT-03
3.117
70x ** CW **
AT-03
The Debtor Postal Address Lines. Up to two occurrences (schema validation). are supported
Version 20111121 (RB5.0)
103 of 154
21/11/2011
Index
3.117
XML Element
TxInf +OrgnlTxRef ++Dbtr +++Id ++++OrgId
Format
See Schema
Status
C
Rulebook Ref
AT-10

The identification of the 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 XML Schema); Either BIC or BEI or one occurrence of Other is allowed.
3.117
TxInf +OrgnlTxRef ++Dbtr +++Id ++++PrvtId
See Schema
NA
3.117
3.118
3.119
TxInf +OrgnlTxRef ++Dbtr +++CtryOfRes TxInf +OrgnlTxRef ++DbtrAcct +++Id ++++IBAN TxInf +OrgnlTxRef ++DbtrAgt +++FinInstnId ++++BIC
2!a
2!a2!n30x
AT-01 The Debtor Account IBAN.
4!a2!a2!c[3 !c]
AT-06 The Debtor Agent BIC.
Version 20111121 (RB5.0)
104 of 154
21/11/2011
Index
3.121
XML Element
TxInf +OrgnlTxRef ++CdtrAgt +++FinInstnId ++++BIC TxInf +OrgnlTxRef ++Cdtr +++Nm TxInf +OrgnlTxRef ++Cdtr +++PstlAdr ++++Ctry TxInf +OrgnlTxRef ++Cdtr +++PstlAdr ++++AdrLine TxInf +OrgnlTxRef ++Cdtr +++Id ++++OrgId
Format
4!a2!a2!c[3 !c]
Status
M
Rulebook Ref
AT-23
The Creditor Agent BIC.
3.123
70x ** CW ** 2!a
AT-21 The Creditor Name.
3.123
AT-22
3.123
70x ** CW **
AT-22
The Creditor Postal Address Lines. Up to two occurrences (schema validation). are supported
3.123
See schema
AT-24
The identification of the Creditor: Private 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 XML Schema); Either BIC or BEI or one occurrence of Other is allowed.
Version 20111121 (RB5.0)
105 of 154
21/11/2011
Index
3.123
XML Element
TxInf +OrgnlTxRef ++Cdtr +++Id ++++PrvtId
Format
See schema
Status
C
Rulebook Ref
AT-24

The identification of the Creditor: Private Id. Cannot be used at the same time as Id/OrgId (above) (schema validation); Only one occurrence of Othr is allowed (schema validation); All of the ISO options are available (see ISO document or XML Schema).
3.123
3.124
3.125
3.125
TxInf +OrgnlTxRef ++Cdtr +++CtryOfRes TxInf +OrgnlTxRef ++CdtrAcct +++Id ++++IBAN TxInf +OrgnlTxRef ++UltmtCdtr +++Nm TxInf +OrgnlTxRef ++UltmtCdtr +++PstlAdr ++++Ctry TxInf +OrgnlTxRef ++UltmtCdtr +++PstlAdr ++++AdrLine
2!a
NA The Creditor Country of Residence.
2!a2!n30x
AT-20 The Creditor Account IBAN.
70x ** CW ** 2!a
AT-28 The Ultimate Creditor Name. Country of the Ultimate Creditor address.
NA
3.125
70x ** CW ** O NA
The Ultimate Creditor Address. Address line can have a maximum of two occurrences. (schema validation).
Version 20111121 (RB5.0)
106 of 154
21/11/2011
Index
3.125 TxInf
XML Element
Format
Status
Rulebook Ref

The identification of the Ultimate Creditor: 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. Cannot be used at the same time as Id/OrgId (above) (schema validation); Only one occurrence of Othr is allowed (schema validation); All of the ISO options are available (see ISO document or schema).
+OrgnlTxRef ++UltmtCdtr +++Id ++++OrgId See Schema C AT-29
3.125
TxInf +OrgnlTxRef ++UltmtCdtr +++Id ++++PrvtId
The identification of the Ultimate Creditor: Private Id. See Schema C AT-29
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)
107 of 154
21/11/2011
APPENDIX D FILE/BULK VALIDATION AND ERROR CODES

D.1 ICF Naming & Structure Validation Process
Error report
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.
Processing
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. 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; A00: the ICF is totally accepted. The ICF is partially accepted; A01: the file is partially accepted. 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. The reported FileRjctRsn at the level of ICF is: The CS generates a CVF as follows: The FileRjctRsn equals: The CS generates a CVF as follows:
If the number of rejected transactions is different from 0, and there are some transaction accepted then the file is partially accepted. The file has been sent during non-Target days.
Version 20111121 (RB5.0)
108 of 154
21/11/2011
Processing
Error report
The FileRjctRsn is: R01: the ICF has been received during non-Target days.
Version 20111121 (RB5.0)
109 of 154
21/11/2011
Processing
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
Error report
The CS generates a CVF as follows: The ICF is totally rejected; 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 transactions contained in the ICF have not been validated, and therefore: The CVF will not contain any rejected transaction, 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)
110 of 154
21/11/2011
Processing
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 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.
Error report
The CS generates a CVF as follows: The ICF is totally rejected; The CVF will not contain any rejected transaction; R08: Unable to process input file. The ICF is totally rejected; 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
The FileRjctRsn is: The CS generates a CVF as follows:
The FileRjctRsn is: R10: ICF does not comply with schema; the file cannot be processed. The ICF is totally rejected; The payment instructions contained in the ICF have not been validated, and therefore: The CVF will not contain any rejected payment instructions. The following fields are compared against the record of accepted files held online: ServiceId; SngInst; FileReference. The CS generates a CVF as follows:
The FileRjctRsn is: R13: the ICF is a duplicate.
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 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 CS generates a CVF as follows: The ICF is totally rejected; The transactions contained in the ICF have not been validated, and therefore: The CVF will not contain any rejected transactions,
The FileRjctRsn is: R11: incorrect SndgInst. R12: incorrect RcvgInst.
Version 20111121 (RB5.0)
111 of 154
21/11/2011
Processing
system value. If any check fails then the file is rejected. 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)
Error report
R14: incorrect TstCode.
The CS generates a CVF as follows: The ICF is totally rejected; OrigFRef and OrigDtTm will not be present (for CVF matching, only the OrigFName 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
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 CS generates a CVF as follows: The ICF is totally 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. If the numbers are different then the file is rejected. The CS generates a CVF as follows: The ICF is totally 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: 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 The CS generates a CVF as follows:
Version 20111121 (RB5.0)
112 of 154
21/11/2011
Processing
NumRETBlk. If the numbers are different then the file is rejected.
Error report
The ICF is totally 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: 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 CS generates a CVF as follows: 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. If the numbers are different then the file is rejected. The CS generates a CVF as follows: The ICF is totally 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: 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 CS generates a CVF as follows: 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)
113 of 154
21/11/2011
D.2
Bulks Naming & Structure Validation Process

Processing 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. Error report The CS generates a CVF as follows: 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. The CS generates a CVF as follows: 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.
Error /Reason Code B00: the bulk is totally accepted.
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.
B02: the maximum number of transactions within one bulk is exceeded.
NbOfTxs is compared against the
The CS generates a CVF as follows: 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
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.
Version 20111121 (RB5.0)
114 of 154
21/11/2011
Error /Reason Code B03: the number of transactions within the bulk does not match the value declared in the GrpHdr
Processing 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.
Error report The CS generates a CVF as follows: 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
B04: Not used B05: TtlIntrBkSttlmAmt or TtlRtrdIntrBkSttlmAmt do not match the sum of the transactions amounts inside the bulk.
NA 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. NA NA
NA The CS generates a CVF as follows: 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
B06: Not used B07: Not used
NA NA
Version 20111121 (RB5.0)
115 of 154
21/11/2011
Error /Reason Code B08: the maximum number of bulks in a single file has been exceeded.
Processing If the maximum have already been accepted then this bulk is rejected.
Error report The CS generates a CVF as follows: 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 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. 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 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
B09: the bulk is totally rejected because all transactions within it have been rejected.
After the completion of bulk content validation, the number of processed transactions is compared with the number of rejected transactions. If they are equal, the bulk is totally rejected.
The CS generates a CVF as follows:
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)
116 of 154
21/11/2011
Error /Reason Code B12: the bulk is totally rejected because Assgnr/Assgne does not have the correct value
Processing Assgnr/Assgne does not have the correct value
Error report The CS generates a CVF as follows: 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 will be set to zero 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 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
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
Version 20111121 (RB5.0)
117 of 154
21/11/2011
Error /Reason Code B15: the bulk is totally rejected because IntrBkSttlmDt is not in the allowed range.
Processing IntrBkSttlmDt must be present at the bulk level and must be within the allowed range. (see Business Function Document)
Error report The CS generates a CVF as follows: 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 contain the values from the original pacs008 bulk 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
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.
The CS generates a CVF as follows: NA
B17: Not used B18: Not used B19: Not used B20: Not used B21: Not Used B22: Not Used
NA
NA
NA. NA
NA
NA NA
NA NA 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"
NA NA
The CS generates a CVF as follows: The bulk is totally rejected All the transactions contained in the bulk have not been validated therefore the CVF will not contain any rejected transactions OrgnlNbOfTxs and OrgnlCtrlSum will contain the values from the original pacs008 bulk The StsRsnInf Prtry field will contain the error code. The bulk is totally rejected
B23: the bulk is totally rejected because too much consecutive rejected transactions
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)
118 of 154
21/11/2011
Error /Reason Code transaction
Processing present in the body of the bulk.
Error report 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)
119 of 154
21/11/2011
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 PY01 XD19 XT13 XT33 XT73 XT74 XT75 XT77 XT81 XT85 Names Unknown BIC (Routing Table) Invalid IBAN format Unsupported XML field Invalid Data Format Invalid Country Code Invalid Original Transaction Status Invalid Original Transaction Status Original Amount Mismatch XML field not permitted in CT service No Settlement Cycle available
Error Description The transaction cannot be processed because the Agent bank is unknown to the STEP2 central system. An IBAN in the transaction has failed the ISO 13616 check. The transaction contains at least one unsupported field for this file;
The offending XML tag is present with the error code (if available).
The content of at least one XML element is not in the required format.
The offending XML tag is present with the error code.
The two characters for country code are not a valid SWIFT country code. Invalid original transaction status for R-message received, action required. Invalid original transaction status for R-message received, action not required. The amount of the original transaction does not match with the amount in the R-message
A XML field present in the XML schemas but not permitted in the CT service was used. 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)
120 of 154
21/11/2011
APPENDIX F REPORT FILE DETAILS

F.1 CRR Cycle Settlement Report
F.1.1 CRR Header

Status
M M M M M M M M M M M M M M M
Field Name
Record Type Service Identifier File Type Sending Institution Senders File Reference * Date And Time Test Code Receiving Institution Settlement Cycle
Format
4x 3!a 3x 4!a2!a2!c 16!c 6!n6!n 1x 4!a2!a2!c 2n 6n 18d 18d 18d 18d 6n
Value
HCRR SCT "CRR" EBAPFRPP
Position
0 4 7 10 18 34 46 47 55 57 63 81 99 117 135
"P" / "T"
Interbank Settlement Date

Total Settlement Amount Debit Party Settled Total Settlement Amount Debit Party Cancelled Total Settlement Amount Credit Party Settled Total Settlement Amount Credit Party Cancelled Total Number Records
Table 4-22 CRR Header *CET (CEST in the summer). Status

M M M M M M M M M M
Field Name
Record Type Instruction Reference Credit Party DP BIC Credit Party Settlement BIC Value of CTRs Settled Value of Returns Settled Value of CTRs Cancelled Value of Returns Cancelled Total Amount Settled Total Amount Cancelled
Format
4x 16x 4!a2!a2!c 4!a2!a2!c3!c 18d 18d 18d 18d 18d 18d
Value
"CDBB"
Position
0 4 20 28 39 57 75 93 111 129
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:
Version 20111121 (RB5.0)
121 of 154
21/11/2011
Field Name
Credit Party DP BIC Credit Party Settlement BIC Value of CTRs settled Value of Returns settled Value of CTRs cancelled Value of Returns cancelled Total Amount Settled Total Amount Cancelled
Contents
The BIC of the direct participant who was the credit party of these transactions. The BIC used by the direct participant identified in Credit Party Settlement BIC. The value of the CTRs settled in this cycle. The value of the Returns settled this cycle. The value of the CTRs cancelled in this cycle. The value of the Returns cancelled this cycle. The amount of settled transactions included in this body. The amount of cancelled transactions included in this body.
Table 4-24 CRR Debit Party field contents Status

M
Field Name
Record Type
Format
4x
Value
"CDBT
Position
0
Table 4-25 CRR Debit Party trailer
F.1.3 CRR Credit Party

Status
M M M M M M M M
Field Name
Record Type Instruction Reference Debit Party DP BIC Debit Party Settlement BIC Value of CTRs Value of Returns Total Settlement Amount Settlement Result
Format
4x 16x 4!a2!a2!c 4!a2!a2!c[3!c] 18d 18d 18d 4x
Value
"CCRB"
Position
0 4 20 28 39 57 75 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
Settlement Reference Debit Party DP BIC Debit Party Settlement BIC Value of CTRs Value of Returns Total Settlement Amount Settlement Result
Contents
The unique STEP2 generated reference for this settlement instruction. The BIC of the direct participant who was the debit party of this settlement instruction. The BIC used by the direct participant identified in Debit Party Settlement BIC. The value of the CTRs included in this body. The value of the Returns included in this body. The amount of the settlement instruction included in this body. 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)
122 of 154
21/11/2011
Status
M
Field Name
Record Type
Format
4x
Value
"CCRT
Position
0
Table 4-28 CRR Credit Party trailer Status

M
Field Name
Record Type
Format
4x
Value
"TCRR
Position
0
Table 4-29 CRR trailer
Version 20111121 (RB5.0)
123 of 154
21/11/2011
F.2
Daily Reconciliation Report (DRR)
F.2.1 DRR header

Status
M M M M M M M M M M
Field Name
Record Type Service Identifier File Type Sending Institution Senders File Reference * Date And Time Test Code Receiving Institution Interbank settlement Date Total Number Records
Format
4x 3!a 3x 4!a2!a2!c 16!c 6!n6!n 1x 4!a2!a2!c 6!n 6n
Value
HDRR SCT "DRR"
Position
0 4 7 10 18 34 46 47 55 61
"P" / "T"
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

Status
M M M M M M M M M M M M M M M M M M M M M M M M M M
Version 20111121 (RB5.0)
Field Name
Record Type Number Files Sent Number Files Rejected Number Bulks Sent Number Bulks Rejected Number Bulks CRT Sent Number Bulks CRT Rejected Number Bulks RET Sent Number Bulks RET Rejected Number Bulks PCR Sent Number Bulks PCR Rejected Number Bulks ROI Sent Number Bulks ROI Rejected Number Credit Transfers Sent Number Credit Transfers Rejected Number Credit Transfers Held Number Credit Transfers Cancelled Number Credit Transfers Settled Number Returns Sent Number Returns Rejected Number Returns Held Number Returns Cancelled Number Returns Settled Number PCR Sent Number PCR Rejected Number ROI Sent
Format
4x 4n 4n 4n 4n 4n 4n 4n 4n 4n 4n 4n 4n 10n 10n 10n 10n 10n 10n 10n 10n 10n 10n 10n 10n 10n
Value
"DFTH"
Position 0 4 8 12 16 20 24 28 32 36 40 44 48 52 62 72 82 92 102 112 122 132 142 152 162 172 124 of 154
21/11/2011
Status
M M M M M M M M M M M M M
Field Name
Number ROI Rejected Value Credit Transfers Sent Value Credit Transfers Rejected Value Credit Transfers Held Value Credit Transfers Cancelled Value Credit Transfers Settled Value Returns Sent Value Returns Rejected Value Returns Held Value Returns Cancelled Value Returns Settled Value PCR Sent Value PCR Rejected
Format
10n 18d 18d 18d 18d 18d 18d 18d 18d 18d 18d 18d 18d
Value
Position 182 192 210 228 246 264 282 300 318 336 354 372 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
Number Files Sent
Contents
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 Number CTRs Bulks Sent Number CTRs Bulks Rejected Number Return Bulks Sent Number Return Bulks Rejected Number PCR Bulks Sent Number PCR Bulks Rejected Number ROI Bulks Sent Number ROI Bulks Rejected Number Credit Transfers Sent
The number of the bulks completely rejected by the STEP2 central system to this direct participant. The total number of CTRs bulks received by the STEP2 central system from this direct participant. The number of CTRs bulks completely rejected by the STEP2 central system to this direct participant. The total number of Return bulks received by the STEP2 central system from this direct participant. The number of Return bulks completely rejected by the STEP2 central system to this direct participant. The total number of PCR bulks received by the STEP2 central system from this direct participant. The number of PCR bulks completely rejected by the STEP2 central system to this direct participant. The total number of ROI bulks received by the STEP2 central system from this direct participant. The number of ROI bulks completely rejected by the STEP2 central system to this direct participant. 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)
125 of 154
21/11/2011
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 Rejected Credit Transfers 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). 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. 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. 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). 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 Cancelled
Transfers
Number Settled
Credit
Transfers
Number Returns Sent
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. 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 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)
126 of 154
21/11/2011
Field Name
Number Returns Cancelled
Contents
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. 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. 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. 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). 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 Returns Settled
Number PCR Sent
Number PCR Rejected. Number PCR Rejected The number of PCR 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 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. 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). The contents of this field will equal: Number ROI Rejected 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 ROI Rejected. The number of ROI 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.
Version 20111121 (RB5.0)
127 of 154
21/11/2011
Field Name
Value Credit Transfers Sent
Contents
The value of the Credit Transfers 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 Sum Of Amounts fields from each partially or completely accepted bulk, and The sum of the following DRR Files Sent Header fields, below: Value Credit Transfers Rejected; Value Credit Transfers Held; Value Credit Transfers Cancelled; and Value Credit Transfers Settled.
Value Credit Rejected
Transfers
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. The value of the payments included in the Number Credit Transfers Held field of this DRR Files Sent Header. 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 Held Value Credit Cancelled Transfers
Value Credit Transfers Settled Value Returns Sent
The value of the payments included in the Number Credit Transfers Settled field of this DRR Files Sent Header. The value of the Returns 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 Sum Of Amounts fields from each partially or completely accepted bulk, and The sum of the following DRR Files Sent Header fields, below:
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. The value of the payments included in the Number Returns Held field of this DRR Files Sent Header. 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.
Value Returns Held Value Returns Cancelled
Version 20111121 (RB5.0)
128 of 154
21/11/2011
Field Name
Value PCR Sent
Contents
The value of the PCRs included in the Number RFCs Rejected field of this DRR Files Sent Header. The contents of this field will equal: The sum of the contents of the Sum Of Amounts fields from each partially or completely accepted bulk, and The sum of the following DRR Files Sent Header fields, below:
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
Status
Field Name
Record Type Bulk Reference Number Credit Transfers Sent Number Credit Transfers Rejected Number Credit Transfers Held Number Credit Transfers Cancelled Number Credit Transfers Settled Value Credit Transfers Sent Value Credit Transfers Rejected Value Credit Transfers Held Value Credit Transfers Cancelled Value Credit Transfers Settled Process Cycle nr
Format
4x 35x 8n 8n 8n 8n 8n 18d 18d 18d 18d 18d 2n
Value
"DTSB"
Position 0 4 39 47 55 63 71 79 97 115 133 151 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
Bulk Reference Number Credit Transfers Sent
Contents
The reference of the bulk for which the information in this record relates. 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 Rejected
Credit
Transfers
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)
129 of 154
21/11/2011
Field Name
Number Credit Transfers Held
Contents
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. 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 Cancelled
Transfers
Number Settled
Credit
Transfers
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. 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 Sent
Value Credit Rejected
Transfers
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. 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 Cancelled
Transfers
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. The process cycle in which this bulk was processed by STEP2 CS.
Process Cycle nr
Table 4-34 DRR Credit Transfer bulks sent body field contents Status
Field Name
Record Type Bulk Reference Number Returns Sent Number Returns Rejected Number Returns Held Number Returns Cancelled Number Returns Settled Value Returns Sent Value Returns Rejected Value Returns Held Value Returns Cancelled Value Returns Settled Process Cycle nr
Format
4x 35x 8n 8n 8n 8n 8n 18d 18d 18d 18d 18d 2n
Value
"DRSB"
Position 0 4 39 47 55 63 71 79 97 115 133 151 169
Table 4-35 DRR Return bulks sent body
Version 20111121 (RB5.0)
130 of 154
21/11/2011
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
Bulk Reference Number Returns Sent
Contents
The reference of the bulk for which the information in this record relates. The number of Returns received by the STEP2 central system in this bulk. The contents of this field will equal the contents of the Total Number Of Transactions field in the header of this bulk.
Number 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. 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 Cancelled
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. 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 Sent
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. 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 Cancelled
Value Returns Settled Process Cycle nr
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. The process cycle in which this bulk was processed by STEP2 CS.
Table 4-36 DRR Return bulks sent body field contents
Status
M M M
Version 20111121 (RB5.0)
Field Name
Record Type Bulk Reference Number PCRs Sent
Format
4x 35x 8n
Value
"DCSB"
Position 0 4 39 131 of 154
21/11/2011
Status
M M M M
Field Name
Number PCRs Rejected Value PCRs Sent Value PCRs Rejected Process Cycle nr
Format
8n 18d 18d 2n
Value
Position 47 55 73 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
Bulk Reference Number PCRs Sent
Contents
The reference of the bulk for which the information in this record relates. The number of PCRs 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 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.
Process Cycle nr
The process cycle in which this bulk was processed by STEP2 CS.
Table 4-38 DRR PCR bulks sent body field contents
Version 20111121 (RB5.0)
132 of 154
21/11/2011
Status
M M M M M
Field Name
Record Type Bulk Reference Number ROIs Sent Number ROIs Rejected Process Cycle nr
Format
4x 35x 8n 8n 2n
Value
"DRIB"
Position 0 4 39 47 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
Bulk Reference Number ROIs Sent
Contents
The reference of the bulk for which the information in this record relates. The number of ROIs 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 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.
Process Cycle nr
The process cycle in which this bulk was processed by STEP2 CS.
Table 4-40 DRR ROI bulks sent body field contents
Status
M
Field Name
Record Type
Format
4x
Value
"DFTT
Position
0
Table 4-41 DRR files/bulks/transactions sent trailer DRR bulks received Status
M M M M M M M M M M M M
Field Name
Record Type Number bulks Received Value bulks Received Number Credit Transfers Direct Number Credit Transfers Indirect Number Returns Number PCR Number ROI Value Credit Transfers Direct Value Credit Transfers Indirect Value Returns Value PCR
Format
4x 4n 18d 10n 10n 10n 10n 10n 18d 18d 18d 18d
Value
"DBRH"
Position 0 4 8 26 36 46 56 66 76 94 112 130
Table 4-42 DRR bulks received header
Version 20111121 (RB5.0)
133 of 154
21/11/2011
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
Number Bulks Received Value Bulks Received
Contents
The number of bulks in SCFs generated by the STEP2 central system for this direct participant during the processing of this interbank settlement date. 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. 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. 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. 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. 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. 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. The value of the payment instructions in identified Number Credit Transfers Direct, above. The value of the payment instructions in identified Number Credit Transfers Indirect, above. The value of the Returns in identified Number Returns, above. The value of the Payment Cancellation Requests in identified Number PCR, above.
Number Direct
Credit
Transfers
Number Indirect
Credit
Transfers
Number Returns
Number PCR
Number ROI
Value Credit Transfers Direct Value Credit Transfers Indirect Value Returns Value PCR
Table 4-43 DRR bulks received header field contents Status

M M M M M M M
Field Name
Record Type Bulk Reference Number Credit Transfers Direct Number Credit Transfers Indirect Value Credit Transfers Direct Value Credit Transfers Indirect Settlement Cycle nr
Format
4x 35x 8n 8n
Value
"DTRB"
Position
0
4 39 47
18d 18d 2n
55 73 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)
134 of 154
21/11/2011
Field Name
Bulk Reference Credit Transfers Direct
Contents
The bulk reference of the SCF Credit Transfer bulk to which these statistics relate. The number of Credit Transfers in this SCF Credit Transfer bulk where this direct participant is receiving the payment instructions as the beneficiary bank. 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. The value of the Credit Transfers identified in Number Credit Transfers Direct, above. The value of the Credit Transfers identified in Number Credit Transfers Indirect, above. The settlement cycle in which this bulk was processed by STEP2 CS.
Number Indirect
Credit
Transfers
Value Credit Transfers Direct Value Indirect Credit Transfers
Settlement Cycle nr
Table 4-45 DRR Credit Transfer bulks received body field contents Status
M M M M M
Field Name
Record Type Bulk Reference Number Returns Value Returns Settlement Cycle nr
Format
4x 35x 8n 18d 2n
Value
"DRRB"
Position
0
4 39 47
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
Bulk Reference Number Returns Value Returns Settlement Cycle nr
Contents
The bulk reference of the SCF bulk to which these statistics relate. The number of Returns in this SCF bulk where this direct participant is receiving the payment instructions as returned. The value of the Returns identified in Number Returns, above. The settlement cycle in which this bulk was processed by STEP2 CS.
Table 4-47 DRR Return bulks received body field contents
Status
M M M M
Field Name
Record Type Bulk Reference Number PCR Value PCR
Format
4x 35x 8n 18d
Value
"DRCB"
Position
0
4 39 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)
135 of 154
21/11/2011
Field Name
Bulk Reference Number PCR Value PCR
Contents
The bulk reference of the SCF bulk to which these statistics relate. The number of Payment Cancellation Requests in this SCF bulk where this direct participant is receiving the PCR. The value of the Payment Cancellation Requests identified in Number PCR, above.
Table 4-49 DRR PCR bulks received body field contents
Status
M M M
Field Name
Record Type Bulk Reference Number ROI
Format
4x 35x 8n
Value
"DROB"
Position
0
4 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
Bulk Reference Number ROI
Contents
The bulk reference of the SCF bulk to which these statistics relate. 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
Status
M
Field Name
Record Type
Format
4x
Value
"DBRT
Position
0
Table 4-52 DRR bulks received trailer
F.2.3 DRR settlement transactions sent

Status
M M M M M
Field Name
Record Type Number Debit Instructions Number Debit Instructions Cancelled Value Debit Instructions Value Debit Instructions Cancelled
Format
4x 6n 6n 18d 18d
Value
"DDBH"
Position
0 4 10 16 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)
136 of 154
21/11/2011
Field Name
Number Debit Instructions
Contents
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. The number of settlement instructions identified in Number Debit Instruct, above, that were cancelled by the external settlement mechanism. The value of the settlement instructions identified in Number Debit Instruct, above. The value of the settlement instructions identified in Number Debit Instruct Cancelled, above.
Number Debit Instruct Cancelled Value Debit Instruct Value Debit Instruct Cancelled
Table 4-54 DRR settlement payments sent header field contents
Status
M M M M M M M M
Field Name
Record Type Settlement Reference Interbank settlement Date Credit Party DP BIC Credit Party Settlement BIC Settlement Amount Settlement Result Settlement Cycle nr
Format
4x 16x 6!n 4!a2!a2!c 4!a2!a2!c[3!c] 18d 4x 2n
Value
"DDBB"
Position
0 4 20 26 34 45 63 67
Table 4-55 DRR transactions sent body The DRR settlement transactions sent the STEP2 central system during the relates (if no settlement instructions participant receiving this DRR was the follows: Field Name
Settlement Reference Settlement Cycle Interbank settlement date Credit Party DP BIC Credit Party Settlement BIC Settlement Amount Settlement Result
body contains one record for each settlement instruction sent by processing of the interbank settlement date to which this DRR were sent then no records will be present) where the direct debit party. The contents of the fields in each such record are as
Contents
The unique STEP2 generated reference for this settlement instruction. The STEP2 cycle during which this instruction was transmitted for settlement. The interbank settlement date during which this instruction was sent for settlement. The BIC of the direct participant who was the credit party of this settlement instruction. The BIC used by the direct participant identified in Credit Party Settlement BIC above. The amount of this settlement instruction. The result of processing 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-56 DRR settlement payments sent body field contents Status
M
Field Name
Record Type
Format
4x
Value
"DDBT
Position
0
Table 4-57 DRR settlement transactions sent trailer
Version 20111121 (RB5.0)
137 of 154
21/11/2011
F.2.4 DRR settlement transactions received

Status
M M M M M
Field Name
Record Type Number Credit Instruct Number Credit Instruct Cancelled Value Credit Instruct Value Credit Instruct Cancelled
Format
4x 6n 6n 18d 18d
Value
"DCRH"
Position
0 4 10 16 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
Number Credit Instructions
Contents
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. The number of settlement instructions identified in Number Credit Instruct, above, cancelled by the external settlement mechanism. The value of the settlement instructions identified in Number Credit Instruct, above. The value of the settlement instructions identified in Number Credit Instruct Cancelled, above.
Number Credit Instruct Cancelled Value Credit Instruct Value Credit Instruct Cancelled
Table 4-59 DRR settlement transactions received header field contents
Status
M M M M M M M M
Field Name
Record Type Settlement Reference Interbank settlement Date Debit Party DP BIC Debit Party Settlement BIC Settlement Amount Settlement Result Settlement Cycle nr
Format
4x 16x 6!n 4!a2!a2!c 4!a2!a2!c[3!c] 18d 4x 2n
Value
"DCRB"
Position
0 4 20 26 34 45 63 67
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)
138 of 154
21/11/2011
Field Name
Settlement Reference Settlement Cycle Interbank settlement Date Debit Party DP BIC Debit Party Settlement BIC Settlement Amount Settlement Result
Contents
The unique STEP2 generated reference for this settlement instruction. The STEP2 cycle during which this instruction was transmitted for settlement. The interbank settlement date during which this instruction was sent for settlement The BIC of the direct participant who was the debit party of this settlement instruction. The BIC used by the direct participant identified in Debit Party Settlement BIC. The amount of this settlement instruction. 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-61 DRR settlement transactions sent body field contents
Status
M
Field Name
Record Type
Format
4x
Value
"DCRT
Position
0
Table 4-62 DRR settlement transactions received trailer
F.2.5 DRR trailer

Status
M
Field Name
Record Type
Format
4x
Value
"TDRR
Position
0
Table 4-63 DRR trailer
F.2.6 DRR Record table index

Definition
HDRR DFTH DTSB DRSB DCSB DRIB DBRH DTRB DRRB DRCB DROB DDBH DDBB DCRH DCRB DRR DRR DRR DRR DRR DRR DRR DRR DRR DRR DRR DRR DRR DRR DRR Header File/Bulk/Transaction sent Credit Transfer bulks sent body Return bulks sent body Payment Cancellation Request bulk sent body Resolution of Investigation bulk sent body bulks received header Credit Transfer bulks received body Return bulks received body Payment Cancellation Request received body Resolution of Investigation received body Settlement transactions sent header Settlement transactions sent body Settlement transactions received header Settlement transactions received body
Trailer Record
TDRR DFTT
DBRT
DDBT DCRT
Version 20111121 (RB5.0)
139 of 154
21/11/2011
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

Status
M M M M M M M M M M
Field Name
Record Type Service Identifier File Type Sending Institution Senders File Reference * Date And Time Test Code Receiving Institution Reference Date% Total Number Records
Format
4x 3!a 3x 4!a2!a2!c 16!c 6!n6!n 1x 4!a2!a2!c 6!n 6n
Value
HMSR SCT "MSR"
Position
0 4 7 10 18 34 46 47 55 61
"P" / "T"
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

Status
M M M M M M M M M M M M M M M M M
Version 20111121 (RB5.0)
Field Name
Record Type Number Credit Transfers Sent Number Credit Transfers Rejected Number Credit Transfers Cancelled Number Credit Transfers Settled Number Returns Sent Number Returns Rejected Number Returns Cancelled Number Returns Settled Number PCRs Sent Number PCRs Rejected Number ROIs Sent Number ROIs Rejected Value Credit Transfers Sent Value Credit Transfers Rejected Value Credit Transfers Cancelled Value Credit Transfers Settled
Format
4x 12n 12n 12n 12n 12n 12n 12n 12n 12n 12n 12n 12n 18d 18d 18d 18d
Value
"MTSH"
Position 0 4 16 28 40 52 64 76 88 100 112 124 136 148 166 184 202 140 of 154
21/11/2011
Status
M M M M M M
Field Name
Value Value Value Value Value Value Returns Sent Returns Rejected Returns Cancelled Returns Settled PCR Sent PCR Rejected
Format
18d 18d 18d 18d 18d 18d
Value
Position 220 238 256 274 292 310
Table 4-65 MSR transactions sent header Status

M M M M M M M M
Field Name
Record Type Receiving Participant Number Credit Transfers Accepted Number Credit Transfers Cancelled Number Credit Transfers Settled Value Credit Transfers Accepted Value Credit Transfers Cancelled Value Credit Transfers Settled
Format
4x 4!a2!a2!c 12n 12n 12n 18d 18d 18d
Value
"MCTB"
Position
0 4 12 24 36 48 66 84
Table 4-66 MSR Credit Transfers sent body Status

M M M M M M M M
Field Name
Record Type Receiving Participant Number Returns Accepted Number Returns Cancelled Number Returns Settled Value Returns Accepted Value Returns Cancelled Value Returns Settled
Format
4x 4!a2!a2!c 12n 12n 12n 18d 18d 18d
Value
"MRTB"
Position
0 4 12 24 36 48 66 84
Table 4-67 MSR Returns sent body Status

M M M M
Field Name
Record Type Receiving Participant Number PCRs Accepted Value PCRs Accepted
Format
4x 4!a2!a2!c 12n 18d
Value
"MRCB"
Position
0 4 12 24
Table 4-68 MSR PCRs sent body
Status
M M M
Field Name
Record Type Receiving Participant Number ROIs Accepted
Format
4x 4!a2!a2!c 12n
Value
"MRIB"
Position
0 4 12
Table 4-69 MSR ROIs sent body
Status
M
Field Name
Record Type
Format
4x
Value
"MTXT
Position
0
Table 4-70 MSR transactions sent trailer

Version 20111121 (RB5.0)
141 of 154
21/11/2011
F.3.3 MSR body: statistics on transactions received

Status
M M M M M
Field Name
Record Type Number Credit Transfers Received Number Returns Received Value Credit Transfers Received Value Returns Received
Format
4x 12n 12n 18d 18d
Value
"MTRH"
Position
0 4 16 28 46
Table 4-71 MSR transactions received header
Status
M M M M
Field Name
Record Type Sending Participant Number Credit Transfers Received Value Credit Transfers Received
Format
4x 4!a2!a2!c 12n 18d
Value
"MCRB"
Position
0 4 12 24
Table 4-72 MSR Credit Transfers received body Status

M M M M
Field Name
Record Type Sending Participant Number Returns Received Value Returns Received
Format
4x 4!a2!a2!c 12n 18d
Value
"MRRB"
Position
0 4 12 24
Table 4-73 MSR Returns received body
Status
M M M M
Field Name
Record Type Sending Participant Number PCR Received Value PCR Received
Format
4x 4!a2!a2!c 12n 18d
Value
"MPRB"
Position
0 4 12 24
Table 4-74 MSR PCR received body Status

M M M
Field Name
Record Type Sending Participant Number ROI Received
Format
4x 4!a2!a2!c 12n
Value
"MIRB"
Position
0 4 12
Table 4-75 MSR ROI received body
Status
M
Field Name
Record Type
Format
4x
Value
"MTRT
Position
0
Table 4-76 MSR transactions received trailer
Version 20111121 (RB5.0)
142 of 154
21/11/2011
F.3.4 MSR trailer

Status
M
Field Name
Record Type
Format
4x
Value
"TMSR
Position
0
Table 4-77 MSR trailer
F.3.5 MSR Record table index

Definition
HMSR MTSH MCTB MRTB MRCB MRIB MTRH MCRB MRRB MPRB MIRB MSR Header MSR transactions sent header MSR Credit Transfer sent body MSR Return sent body MSR Payment Cancellation Request sent body MSR Resolution of Investigation sent body MSR transactions received header MSR Credit Transfer received body MSR Returns received body MSR Payment Cancellation Request received body MSR Resolution of Investigation received body
Trailer Record
TMSR MTXT
MTRT
Version 20111121 (RB5.0)
143 of 154
21/11/2011
STEP2 SCT Interface Specifications
APPENDIX G INTERFACES TO SUPPORTED NETWORKS
Information regarding the Network Configuration can be found in the STEP2 Technical Configuration document. (Ref. [18]).
Version 20111121 (RB5.0)
144 of 154
21/11/2011
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.
Version 20111121 (RB5.0)
145 of 154
21/11/2011
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 Acc. Date N Y N Y Y Rem. Info N N Y Y Y ITA Trasf. N N N N Y Payment Type allowed 1 space char AO1 AO2 AO1 AO2 AO1 AO2 AO3 RTF File Physical Representation (HX) 09 09 09 09 09 41 20 41 41 41 41 4F 09 4F 4F 4F 4F 33
BIC BIC BIC BIC BIC
A B C D E
31 32 31 31 09
09 09 09 41 4F 32 09 09 41 4F 32 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 tabseparated values file and not an Excel file as for the one obtained through the DPWS.
Version 20111121 (RB5.0)
146 of 154
21/11/2011
H.6
SCT Direct Participant Routing Table
H.6.1 Header row

Field name File Title Format Text Size 32x Description SCT DIRECT PARTICIPANT ROUTING TABLE
H.6.2 Search Criteria header row 1

Field name Row name Format Text Size 15x Description SEARCH CRITERIA

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

Field name BIC Name Date From Date To Status Matching Records Format BIC (8) None YYYYMMDD YYYYMMDD Text Integer Size 8x 50x 6x 6x 9x 4n Description BIC used in search criteria Bank Name used in search criteria Date From used in search criteria Date To used in search criteria Status used in search criteria Number of records returned in search
H.6.5 Results header row 1

Field name Row name Format Text Size 7 RESULTS Description
Version 20111121 (RB5.0)
147 of 154
21/11/2011

Field name Header 2 col. A Header 2 col. B Header 2 col. C Header 2 col. D Header 2 col. F Header 2 col. H Header 2, col. I Format Text Text Text Text Text Text Text Size 6 7 9 8 17 6 20 BIC NAME INIT DATE END DATE SETTLEMENT BIC STATUS PAYMENT TYPE ALLOWED Description
H.6.7 Results row

Field name DP BIC DP Name Init Date End date Settlement BIC Status Payment Type Allowed Format AN Text Date Date Text Text Text Size BIC (8) 50x YYYYMMDD YYYYMMDD BIC (11) 9x See (H.4) BIC(8) format. Bank name. Free format. Date from which BIC is valid. Date up to which BIC is valid The BIC used for settlement of the IP data. ENABLED, SUSPENDED, DISABLED A 3-character code indicating the product(s) available to this participant. See (H.4) Description
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
Version 20111121 (RB5.0)
148 of 154
21/11/2011
H.7
SCT Indirect Participant Routing Table
H.7.1 Header row

Field name File Title Format Text Size 34x Description SCT INDIRECT PARTICIPANT ROUTING TABLE

Field name Row name Format Text Size 15x Description SEARCH CRITERIA

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

Field name IP BIC IP Name Date From Date To DP BIC Status Matching Rows Format AN Text Date Date AN Text Integer Size BIC (11) 50x YYYYMMDD YYYYMMDD BIC (11) 9x 4n Description BIC(11) format. Ending in XXX is permissible. Bank name. Free format. Date from which BIC is valid. Date up to which BIC is valid The BIC of the associated Direct Participant. ENABLED, SUSPENDED, DISABLED No. of Search Results rows returned
Version 20111121 (RB5.0)
149 of 154
21/11/2011

Field name Row name Format Text Size 7x RESULTS Description

Field name Header 2 col. A Header 2 col. B Header 2 col. C Header 2 col. D Header 2 col. E Header 2 col. F Header 2 col. H Header 2 col. I Format Text Text Text Text Text Text Text Text Size 6x 7x 9x 8x 6x 17x 6x 20x IP BIC IP NAME INIT DATE END DATE DP BIC DP SETTLEMENT BIC STATUS PAYMENT TYPE ALLOWED Description
H.7.7 Results row

Field name IP BIC IP Name Init Date End date DP BIC DP Settlement BIC Status Payment Type Allowed Format AN Text Date Date AN Text Text Text Size 11x 50x YYYYMMDD YYYYMMDD BIC (8) BIC (11) 9x See (H.4) Description BIC(11) format. Ending in XXX is permissible. Bank name. Free format. Date from which BIC is valid. Date up to which BIC is valid The BIC of the associated Direct Participant. The BIC used for settlement of the IP data. ENABLED, DISABLED 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
Version 20111121 (RB5.0)
150 of 154
21/11/2011
APPENDIX I ERROR CODE REFERENCE LIST
I.1
File Level Codes

Description
ICF totally accepted ICF partially accepted ICF received on non-Target day Network file name not compliant Unknown Service identifier Direct Participant BIC mismatch (network address) Invalid file name format Invalid file extension Unable to process input file Decompression failed Schema validation failed Invalid Sending Institution Invalid Receiving Institution Duplicate ICF Invalid Test Code Invalid Sending Institution BIC format Invalid Receiving Institution BIC format. Credit Transfer bulk number mismatch Payment Cancellation Request bulk number mismatch Returns bulk number mismatch Resolution of Investigation bulk number mismatch All bulks rejected Maximum number of ICF received
Code
A00 A01 R01 R02 R03 R04 R06 R07 R08 R09 R10 R11 R12 R13 R14 R15 R16 R18 R19 R20 R21 R23 R24
File error codes are always used in the CVF header as part of the File Reject Reason (FileRjctRsn) field.
Version 20111121 (RB5.0)
151 of 154
21/11/2011
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 B00 B01 B02 B03 B05 B07 B08 B09 B10 B11 B12 B13 B14 B15 B16 B23 B24 ED05 XT81
Description Bulk totally accepted Bulk partially accepted Maximum number of transactions in a bulk exceeded Number of transactions mismatch Total amount mismatch Control Sum mismatch Maximum number of bulks in a file exceeded All transactions rejected Instructing Agent mismatch Invalid use of Instructed Agent Invalid Use of Assgnr/Assgne Zero Settlement Amount Duplicate MessageID Invalid Settlement Date Invalid Settlement Info details Too many consecutive rejected transactions Invalid use of bulk transaction Settlement Failed Only SEPA core fields are allowed
Type PRTRY PRTRY PRTRY PRTRY PRTRY PRTRY PRTRY PRTRY PRTRY PRTRY PRTRY PRTRY PRTRY PRTRY PRTRY PRTRY PRTRY PRTRY PRTRY
Pacs002S2 X X X X X X X X X X X X X X X X X X X
Version 20111121 (RB5.0)
152 of 154
21/11/2011
I.3
Transaction level Error Codes
Transaction error codes are always used at the transaction level as part of either Code or Proprietary field. Pacs002S2 X X X X X X X X X X X X X X X 153 of 154
Camt029 X X X
Code
Description
Type
CUST LEGL DUPL TECH FRAD AC01 AC04 AC04 AC06 AG01 AG02 AM01 AM02 AM04 NOAS NOOR AM05 DT01 BE04 ED05 FOCR MD07 MS02 MS03 RC01
Requested By Customer Legal Decision Duplicate Payment Technical Problem Fraudulent Original Credit Transfer Incorrect Account Number Closed Account Number Closed Account Number Blocked Account Transaction Forbidden Invalid Bank Operation Code Zero Amount Not Allowed Amount Insufficient Funds No Answer from Customer No Original Transaction Received Duplication Invalid Date Missing Creditor Address Settlement Failed Following Cancellation Request End Customer Deceased Not Specified Reason Customer Generated Not Specified Reason Agent Generated Bank Identifier Incorrect
ISO ISO ISO PRTRY PRTRY ISO ISO PRTRY ISO ISO ISO ISO ISO PRTRY PRTRY PRTRY ISO ISO ISO ISO ISO ISO ISO ISO ISO X X X X X
X X X
Version 20111121 (RB5.0)
Camt056
Pacs004
21/11/2011
Code
Description
Type
RR01
Not Specified Reason Customer Generated Missing Debtor Name or Address - Code used by banks to indicate a Return for Regulatory Reason Missing Creditor Name or Address - Code used by banks to indicate a Return for Regulatory Reason Regulatory Reason Already Returned Transaction Unknown BIC in routing table Invalid IBAN format Unsupported XML field Invalid data format Invalid country code Invalid original transaction status, action required Invalid original transaction status, action not required Original Amount mismatch Only SEPA core fields are allowed Invalid Settlement Cycle Used in PCF file The PCR was processed before the settlement of the original Credit Transfer. The original CT was not settled.
ISO
X X
ISO
RR02
ISO
RR03 RR04 ARDT PY01 XD19 XT13 XT33 XT73 XT74 XT75 XT77 XT81 XT85 CANC
ISO PRTRY PRTRY PRTRY PRTRY PRTRY PRTRY PRTRY PRTRY PRTRY PRTRY PRTRY
X X X X X X X X X X X X
PRTRY
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
Version 20111121 (RB5.0)
Pacs002S2 154 of 154
Camt029
Camt056
Pacs004

1 - EBA STEP2 SCT Interface Specifications v20111121 - Updated 20110606 Clean

Uploaded by

Copyright:

Available Formats

1 - EBA STEP2 SCT Interface Specifications v20111121 - Updated 20110606 Clean

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

1 - EBA STEP2 SCT Interface Specifications v20111121 - Updated 20110606 Clean

Uploaded by

Copyright:

Available Formats

What is the purpose of this document?

What is the purpose of this document?

What versions of the document have been released?

What versions of the document have been released?

STEP2 SEPA Credit Transfer Processing Service

STEP2 SEPA Credit Transfer Service

20101101 20101101 20101101 20101101 20101101 20101101 20101101 20101101

05/02/2010 25/02/2010 10/03/2010 26/03/2010 02/04/2010 28/05/2010 04/06/2010 07/10/2010

SIA-SSB SIA-SSB SIA-SSB SIA-SSB SIA-SSB SIA-SSB SIA-SSB SIA-SSB

STEP2 SEPA Credit Transfer Service

Version 20101101 Changes Update 2010-03-10

STEP2 SEPA Credit Transfer Service

Version 20111121 (RB5.0)

STEP2 SEPA Credit Transfer Service

Version 20111121 (RB5.0)

STEP2 SEPA Credit Transfer Service

STEP2 SEPA Credit Transfer Service

Version 20111121 (RB5.0)

STEP2 SEPA Credit Transfer Service

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

Version 20111121 (RB5.0)

STEP2 SEPA Credit Transfer Service

STEP2 SEPA Credit Transfer Service

Version 20111121 (RB5.0)

STEP2 SEPA Credit Transfer Service

[4] [5] [6] [7] [9] [10] [11] [12]

[13] [14] [15] [16] [17] [18]

EPC-0265/03 EPC027-06 EPC041-10 V 0.3

SEPA Credit Transfer Service Requirements

Version 20111121 (RB5.0)

STEP2 SEPA Credit Transfer Service

Batch Reporting Time

Batch Settlement Batch Settlement Reference BIC Bilateral Gross Settlement

Business Control Business Control Override Cancelled Credit File

CCF Central System CET CEST CICS Credit Validation File

CRR CS CVF Cycle Reconciliation Report

Daily Reconciliation Report

STEP2 SEPA Credit Transfer Service

Input Credit File Instructed Agent

Monthly Statistics Report

MQ Series MSR OFR Operational Control Original File Reference

OS/390 Payment Cancellation Request Push Mode PCR PCF

RACF Recall Procedure

Resolution of Investigation ROI

STEP2 SEPA Credit Transfer Service

Settlement BIC Settlement Cut-Off Time

Transaction Identification Validation Rules XML

Table 1-1 Glossary

STEP2 SEPA Credit Transfer Service

XML Schema Versions

Version 20111121 (RB5.0)

STEP2 SEPA Credit Transfer Service

THE STEP2 SYSTEM

Input Credit File (ICF)

Payment Cancellation Request / Payment Recall

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

STEP2 To Sending Bank STEP2 To Sending Bank STEP2 To Receiving Bank

Confirmation / Rejection of messages received

Credit Validation File (CVF)