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.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
STEP2 – SEPA Credit Transfer Processing Service
Interface Specifications
This document is confidential within the institutions which have received them from EBA CLEARING.
Version: 20111121(RB5.0)
This document is compliant with version 5.0 of the EPC Rulebook.
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) ii of 154
HISTORY OF MODIFICATIONS
Version Date Authored by Status
0.1 15/09/2006 Richard Liblanc Draft
0.2 27/10/2006 Richard Liblanc Draft
1.0 21/12/2006 Richard Liblanc Draft
1.1 26/01/2007 Richard Liblanc Draft sent to banks for approval
1.2 02/02/2007 Richard Liblanc Final
20070622 22/06/2007 Richard Liblanc Updated
20080128 28/01/2008 Richard Liblanc Final version for SEPA go live date
20080505 05/02/2008 Richard Liblanc Corrected version of v20080128
20081208 15/06/2008 Richard Liblanc First Draft for version 20081208
20081208 30/07/2008 Richard Liblanc Updated version for 20081208
20081208 08/12/2008 David Blanchemanche Final version of v20081208
20091001 01/10/2009 SIA-SSB Review for SWIFTNet 6.1 (Par. Error! Reference source not found./3.5.1)
20101101 05/02/2010 SIA-SSB First Draft for version 20101101
20101101 25/02/2010 SIA-SSB First review for version 20101101
20101101 10/03/2010 SIA-SSB Review due to errata list for version 20101101
20101101 26/03/2010 SIA-SSB Review due to errata list for version 20101101
20101101 02/04/2010 SIA-SSB Review due to errata list for version 20101101
20101101 28/05/2010 SIA-SSB Review due to errata list for version 20101101
20101101 04/06/2010 SIA-SSB Field “Issr” now Yellow
20101101
20111121
07/10/2010
25/03/2011
SIA-SSB
SIA-SSB
Review due to errata list for version 20101101
First Draft for version 20111121 – Rulebook 5.0
20111121 01/06/2011 SIA Review due to EPC Errata List (EPC 167-11)
Version 20081208 Changes
- Included changes related to Rulebook/Implementation Guidelines v3.2:
o Usage of Ultimate Debtor/Creditor Name and Identification fields o Usage of field Purpose in SEPA messages o Usage of field Category Purpose in SEPA messages o Check that Returned Interbank Settlement Amount is equal to Original Interbank Settlement
Amount in a pacs004 transaction o New SEPA reason codes for pacs004: AG02, MD03, RC01, and TM01 (see section I.3)
- Added extra occurrences to both Structured and Unstructured Remittance Information for AOS purpose - pacs004 and pacs006 messages updated according to the RB3.2 and AOS changes above - <RmtInf> and </RmtInf> tags are no longer counted against the 140 characters limit for Structured
Remittance Information. The 140 characters limit is for all characters between the <Strd> and </Strd> tags, not inclusive.
- Duplicate key for Return (pacs004) has changed from Instructing Agent to Original Creditor Agent - Clarified validation rules for IBAN fields in pacs008 messages
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) iii of 154
- Removed mentions of EURO1/STEP1 as settlement engine as STEP2 settlement is now performed in TARGET2
- Added details concerning the new file, Routing Table File (RTF), in particular its naming convention (see section 3.5 and H.5 )
- Added note about CCF only being sent after the last cycle of a business day (result of new feature for automated deferral of failed settlement instructions to next same-day settlement cycle) (see section 2.3.4)
- Added diagram and clarified text on the generation of MessageId by the Central System (section A.5) - Clarified format for field CdtTrfTxInf/Purp/Cd is 35x and not 4!a (see section C1.2) - Clarified use of error code AM01 (PACS 004) (see section I.3) - Clarified request type (pacs.xxx.sct.a.any) for routing table (see section G.1.3) - Added remarks on the format ISODateAndTime (see section 4) - Clarification on number of settlements files (SCF) (see section 2.3.3) - Clarified format for field SndgInst in CCF (see section B.4 and C.3.2)
Version 20080505 Changes - Removed word Credeuro in the document for legal reasons - Section A.5 on the format of the MessageId generated by STEP2 has been aligned with the current
behavior of the system. - Clarified bulk error codes usage in section D.2 - Corrected positions in table for MTSH record (section F.3.2) Version 20101101 Changes – Update 2010-02-05 - Included changes related to Rulebook/Implementation Guidelines v4.0 - Removed the pacs.006 message (See 2.1) - Added two new messages types : camt.056 and camt.029 (See 2.1) - Recall Procedure of a settled Credit Transfer (See 2.1) - SCF file content (See 2.3.3): added camt.056 and camt.029 messages - File Format and Bulks (See 3.6) - Duplicate Checking (See A.4) - Bulk level Error Codes (See I.2) - Transaction level Error Codes (See I.3) - DRR File structures: modified for new camt messages (See F.2.2/F.2.6) - MSR File structures: modified for new camt messages (See F.3.2/F.3.5) - Added explanation for Recall Procedure (See A.8) - Added explanation on CR/DB Agents in pacs.002S2 (See A.9) - Changes to the pacs.008 CT format (See C.1) - New camt.056 Payment Cancellation Request message format (See C.2) - New camt.029 Resolution of Investigation message format (See C.3) - Changes to the pacs.002S2 Reject format (See C.4) - Changes to the pacs.004 Return format (See C.5) Version 20101101 Changes – Update 2010-02-25
- Added the R21 Error code (See D.1 / I.1) - Added the label “** CW **” to identify which fields have the “Collapse Whitespaces” setting at Schema
level (See Appendix C) - Split output files based on network limit file size (See 3.6 / 2.3.3) - Changes to validation rules due to camt.056 message (See D.2) - Added new values for Payment Type Allowed in RTF files (See H.4) - Changes due to Errata List of 20100219 - Changes in the routing of transactions (See 3.10) - Added the Error code B12 (See D.2/I.2) Version 20101101 Changes – Update 2010-03-10
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) iv of 154
- Changed field name from BICorBEI to BICOrBEI ( See Appendix C). - Changed field name from SrvcID to SrvcId (See B.1) - Changed Error code for invalid ClrSys in camt.056 (See C.2.2) Version 20101101 Changes – Update 2010-03-26
- Changed validation rules for Reason field of camt.029 (See C.3.2). - Changes due to EPC Errata List (EPC041-10 V 0.3). (See C.1.2 / C.2.2 / C.5.2). - Changes due to Italian AOS for transferability (See C.1.2 / H.4). - Changes due to Errata List of 20100326 (See 2.1 / F.2.2 / H.6.7 / H.7.7 / 3.6). - Removed information from Appendix G.1.4 - Changes to DRR and MSR for PCR/ROI (See F.2.2/F.3.3) Version 20101101 Changes – Update 2010-04-02 - Added code “ARDT” in Reason field of camt.029 ( See I.3) - Changes due to Errata List of 20100326 (See F.2.2/F.3.2) Version 20101101 Changes – Update 2010-04-23
- Changes due to Errata List of 20100423 (See F.2.2) - Changes due to EPC Errata List of 2010408 (See C.5.2) Version 20101101 Changes – Update 2010-05-28
- Changes due to Errata List of 20100528 (See I.3/C.4/C.5.2) Version 20101101 Changes – Update 2010-06-04 - Field “Issr” under Structured Remittance Info is now yellow (See C.2.2/C.3.2/C.5.2) - Changed the name of the field “OrgnlIntrBkSttlmDt” in “IntrBkSttlmDt” for camt.029 (See C.3.2) Version 20101101 Changes – Update 2010-08-13 - Rulebook reference changed from AT-R3 to AT-R6 (See C.3.2) - Rulebook reference changed from AT-R3 to AT-R48 (See C.2.2) - Added error code XT81 at bulk level for CtrlSum in Camt.056 (See C.2.1/I.2) - Changed FinInstId with FinInstnId (See C.2.2/C.3.1/C.3.2) - Error code for subsequent Strd elements changed from XT13 to XT81 (See C.1.2/C.2.2/C.3.2/C.5.2) - Clarification on second bullet for RtrdIntrBkSttlmAmt (See C.5.2) - Removed wildcard from OrgnlMsgNmId in pacs.002S2 (See C.4.2) - Added attribute check for RtrdInstdAmt (See C.5.2) - Added error code XT33 in Charges Amount (See C.5.2) - Removed char ‘*’ from Report description (See Appendix F) Version 20101101 Changes – Update 2010-08-31
- Clarified format for the field (TxInf+RtrRsnInf++Rsn++++Cd) is 4!c and not 4!a (See C.5.2) - Clarification on the restriction of the usage of BICorBEI and OTHERS fields under OrgId (See C.1.2/C.5.2 Version 20101101 Changes – Update 2010-10-07
- Clarification regarding sending of camt.056 during settlement (See A.8) - Clarification regarding the Collapse Whitespaces option (See 4) - Clarification regarding the RTF format (See H.4)
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) v of 154
Version 20111121 Changes – Update 2011-03-25 - Changed the Rulebook version number to 5.0 - Added field ClrSys to Camt.029 Message (See C.3.2) - New PCF file (See 2.1/2.3.5/3.5.1/3.5.2/A.1.5/A.7/A.8/B.5/C.4) - Last settlement cycle of the day is optional (See 3.1/3.2) - Setting the settlement cycle (See A.10/C.1.1) Version 20111121– Update 2011-05-27
- Changes due to Errata List of 2011-05-27 (See 2.1/3.6/3.11/A.8/A.10/C.4.1/C.4.2/C.4.3/C.5.2D.1D.2/I.3) Version 20111121– Update 2011-06-01
- Changes due to the EPC Errata List of 2011-05-30 (See C.2.2)
This document is the Interface requirements for an EBA CLEARING STEP2 Credit Transfer service (SCT) compliant with the SEPA Credit Transfer Rulebook.
1.2 References
Document Number Title Issued By [1] EPC125-05 SEPA Credit Transfer Scheme Rulebook
Version 5.0 November 2010 EPC
[2] EPC115_06 SEPA Credit Transfer Scheme Implementation guidelines Version 5.0 November 2010
EPC
[3] EPC170-05 Framework for the Evolution of the Clearing and Settlement of Payments in SEPA – Including the Principles for SEPA Scheme Compliance and Re-statement of the PE-ACH Model (“PE-ACH/CSM Framework”).
EPC
[4] ISO 13616 IBAN: International Bank Account Number (Standard) ISO [5] SIG 203 IBAN Standard Implementation Guidelines ECBS [6] ISO 3166 Country Codes ISO [7] ISO 4217 Currency code List ISO [9] ISO 9362 Bank Identifier codes ISO [10] ISO 20022 Financial services – Universal Financial Industry message
scheme ISO
[11] EPC 190-05 SEPA Data Model EPC [12] A Glossary of Terms Used in Payments and Settlement
Systems
Bank for International Settlements
[13] The Interbank Convention on Payments EPC [14] The Cross-border Credit Transfer Convention EPC [15] EPC-0265/03 EPC Resolution on Receiver Capability EPC [16] EPC027-06 SEPA Credit Transfer Adherence Agreement EPC [17] EPC041-10 V 0.3 Errata Implementation Guidelines EPC [18] STEP2 Technical Configuration EBA CLEARING
1.3 SEPA Credit Transfer Service Requirements
The service is compatible with the SEPA Credit Transfer Scheme Rulebook and Implementation guidelines version 5.0(), using the ISO 20022 Standards.
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 12 of 154
1.4 Glossary
The following terms are presented alphabetically. A bold word or phrase in the Meaning section indicates that the word or phrase is a term also explained within this glossary.
Term Meaning
ACL Access Control List. List of users or groups of users associated with an object (such as a file or database table) that controls the actions that can be performed on the object by the users or groups of users in the ACL.
Automatic Routing The process by which the Central System automatically chooses the Direct Participant who will be the Receiver of a payment instruction based on:
• The beneficiary bank (Creditor Agent) of the payment instruction, and
• The Direct Participant who is sending the payment instruction to STEP2 in an ICF.
Batch Reporting Time The time at which an External Settlement Mechanism is expected to transmit the results of settlement processing to the STEP2 Central System. Under normal circumstances, the batch reporting time is equal to the Settlement Cut-Off Time, but this may be changed by a Business Control Override or by the External Settlement Mechanism under exceptional circumstances.
Batch Settlement A group of Settlement Instructions transmitted to an External Settlement Mechanism in bulk in one message.
Batch Settlement Reference The unique reference number automatically associated with a Batch Settlement by the Central System.
BIC Bank Identification Code. SWIFT standard for identification of banks within payment instructions.
Bilateral Gross Settlement The process of calculating amounts to be settled whereby each party, A, pays every other party, B (where B does not equal A), the sum of the amounts of all payment instructions to be settled where the A is the debtor and the B is the creditor.
Business Control The function within EBA that controls the business operation of STEP2. Business Control Override Central System functions that may be used by Business Control to
change the times at which processing deadlines are enforced. Cancelled Credit File A STEP2-standard file of payment instructions that have been cancelled by
the relevant External Settlement Mechanism and are returned by the STEP2 Central System to the Direct Participant who was the Sender of the ICF in which the cancelled payment instructions were delivered to the Central System. CCFs are only transmitted in exceptional circumstances.
CCF See Cancelled Credit File. Central System Processing engine used to perform all STEP2 processing activities. CET Central European Time. CEST Central European Summer Time CICS Customer Information Control System. An IBM product that implements an
execution environment for transaction processing. Credit Validation File A STEP2-standard file transmitted by the Central System to the Direct
Participant in response to an ICF that contains information regarding the success or failure of the application of Validation Rules to that ICF.
CRR See Cycle Reconciliation Report CS Central System CVF See Credit Validation File Cycle Reconciliation Report Report transmitted to every Direct Participant by the Central System
following the completion of the last Settlement Cycle for a Settlement Date that includes summary information to assist reconciliation.
Daily Reconciliation Report Report transmitted daily to every Direct Participant by the Central System for a Settlement Date that includes summary information to assist reconciliation.
Dataset A names set of records stored or processed as a unit on the IBM OS/390 file system.
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 13 of 154
Term Meaning
DB2 Relational database platform on IBM OS/390 systems. Direct Participant A bank that may directly transmit files to and directly receive files from the
Central System. DRR See Daily Reconciliation Report. External Settlement Mechanism
External processing system used by STEP2 to process the settlement obligations arising from its processing of bulk payment processing Services.
File Transfer Protocol International standard protocol for the exchange of files between two computers connected via a network.
FileAct A service of SWIFTNet for the secure transmission of files. FIN Secure global network operated by SWIFT. FTP See File Transfer Protocol. GMT Greenwich Mean Time. ICF See Input Credit File. Indirect Participant A bank known to the Central System that may receive files payment
instructions from the Central System via the services of a Direct Participant.
Input Credit File A STEP2-standard file that is used to transmit payment instructions for processing from Direct Participants to the Central System.
Instructed Agent SWIFT Bulk Payments Modeling Group equivalent of receiving bank. Definition:
“Clearing agent that is instructed by a previous clearing agent about a (file of) payment instruction(s)”
Instructing Agent SWIFT Bulk Payments Modeling Group equivalent of sending bank. Definition:
“Clearing agent that prepares the (file of) payment instructions and forwards it to the next party in the payment chain.”
Monthly Statistics Report Report can be (optionally) transmitted to a Direct Participant by the Central System following the completion of the last Settlement Cycle of the last Settlement Date for a calendar month that includes statistical information to assist charging.
MQ Series Queue-based transactional middleware supplied by IBM. MSR See Monthly Statistics Report. OFR See Original File Reference. Operational Control The function within SIA that controls the technical operation of STEP2. Original File Reference The Sender’s File Reference for an ICF when this ICF is referred to
within a related file, e.g. the Original File Reference in a CCF refers to the SFR of the ICF in which the Central System accepted the payment instructions cancelled within the CCF.
OS/390 Current operating system for IBM mainframe platforms. Payment Cancellation Request
An instruction sent by a Direct Participant to STEP2 to Cancel a previously sent Credit Transfer instruction or to initiate a Recall of Credit Transfer Procedure.
Push Mode Operating mode of STEP2’s secure networks whereby Direct Participants receive files unsolicited from the Central System.
PCR See Payment Cancellation Request PCF Payment Cancellation File – The file can be (optionally) transmitted to a
Direct Participant by the Central System following the completion of each Settlement Cycle reporting pre and post settlement cancellations
RACF Resource Access Control Facilities. The security server for the IBM mainframe platform.
Recall Procedure The Debtor Agent requires a Recall of a previously settled Credit Transfer sending a Payment Cancellation Request (camt.056) message to the Creditor Agent, which could answer positively with a Return (pacs.004) or negatively with a Resolution of Investigation (camt.029)
Receiver The receiver of a file is the Direct Participant to whom the Central System directly transmits the file (and whose BIC is the in the Receiving Institution field of the file header). The receiver of a payment instruction within a file is the receiver of the file within which the payment instruction is contained.
Resolution of Investigation Negative answer to a Recall of a credit transfer ROI See Resolution of Investigation
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 14 of 154
Term Meaning
Routing The process of selecting a Receiver for a payment instruction. SCF See Settled Credit File. Security Support Provider Interface
Microsoft Windows 2000 component providing flexible support for different security mechanisms.
Sender The sender of a file is the Direct Participant from whom the Central System directly receives the file (and whose BIC is the in the Sending Institution field of the file header). The sender of a payment instruction within a file is the sender of the file within which the payment instruction is contained.
Sender’s File Reference Unique reference allocated to every STEP2-standard file. Sending Cut-Off Time The after which ICFs transmitted to the Central System will either be
rejected or processed in the following Settlement Cycle. Service A processing facility offered by STEP2, e.g. €-denominated, cross border
credit transfers. Service Identifier Three-character identifier used to uniquely identify each STEP2 Service, e.g.
“SCT”. Settled Credit File A STEP2-standard file of payment instructions that have been successfully
processed by the relevant External Settlement Mechanism and are transmitted by the Central System to the receiving Direct Participant.
Settlement BIC The BIC by which a Direct Participant is known in an External Settlement Mechanism.
Settlement Cut-Off Time The time at which the Central System expects responses to Settlement Instructions transmitted to an External Settlement Mechanism. Under normal circumstances, the Settlement Cut-Off Time is equal to the Batch Reporting Time.
Settlement Cycle One complete processing cycle for a Service beginning with the acceptance and validation of ICFs and concluding with the transmission of the resulting SCF and CRR (and possibly, under rare circumstances, CCFs). The final Settlement Cycle for a Settlement Date concludes with the additional transmission of DRRs to Direct Participants. The final Settlement Cycle for a Settlement Date on the last operating day of a calendar month concludes with the additional transmission of MSRs to Direct Participants who wish to receive them.
Settlement Date The date on which the value of a payment instruction must be debited from the account of the sending Direct Participant within the External Settlement Mechanism and credited to the account of the receiving Direct Participant in the External Settlement Mechanism.
Settlement Instruction An instruction sent by the Central System to External Settlement Mechanism to debit the account of one specified participant and credit the amount of another specified participant by a specified amount.
Settlement Instruction Reference
A unique reference allocated to each Settlement Instruction by the Central System.
Settlement Time The time at which the Central System transmits Batch Settlements to an External Settlement Mechanism.
SIA-SBB Società Interbancaria per l’Automazione S.p.A. The company that operates STEP2 on behalf of EBA.
SIANet Secure global IP network operated by SIA-SSB. SSPI See Security Support Provider Interface. SWIFTNet Secure global IP network operated by SWIFT. TARGET Trans-European Automated Real-time Gross settlement Express Transfer
system. The EU-wide system for the settlement of euro-denominated gross payments in euro.
Transaction Identification A unique reference number used to uniquely identify each payment instruction.
Validation Rules A set of rules enforce by the Central System on the structure and content of payment instructions and ICFs.
XML Extensible Mark-up Language. Language that is used to specify information exchange formats and in which the SWIFT Bulk Processing Modeling Group standards are written.
z/Series Hardware architecture for IBM mainframe computers.
Table 1-1 Glossary
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 15 of 154
1.5 XML Schema Versions
This document is compatible with the following version of the XML Schemas: • camt.029.001.03 • camt.056.001.01 • pacs.002.001.03S2 • pacs.004.001.02 • pacs.008.001.02
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 16 of 154
2. THE STEP2 SYSTEM
2.1 Overview
All transaction processing information exchanged between the STEP2 central system and a Direct Participant is performed via files transmitted across a secure network. The formats of the various files are specified in the appendices of this document. Information that is presented to the STEP2 central system in a file that does not strictly match the specified format is rejected. Similarly, the STEP2 central system delivers information to Direct Participants in files that are strictly formatted in accordance with this published specification. The formatting of payment instructions within files is service specific. STEP2 SCT supports Credit Transfers in XML format, as per the ISO20022 Payments Standards. The validation rules for these formats are also specified in the appendices of this document. The business level messages in the SEPA Credit Transfer service do not match one to one with the ISO20022 XML Messages, as some XML messages are used for more than one purpose, e.g. the pacs.002 Payment Status message. This message is used by STEP2 to reject messages and to give information about the failure of settlement.
Sender Business Level message
according to the Scheme
File Type XML
Message used
XML
Message Description
Bank to STEP2
Credit Transfer Payment Cancellation Request / Payment Recall Return / Positive Answer to CT Recall Negative Answer to a CT Recall
Machine Readable Report Monthly Statistical Report (MSR) NA NA
STEP2 To Direct Participants
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
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 18 of 154
Figure 2-3
Figure 2-4: Bulk types in SCF file sent by STEP2
Figure 2-5 : Bulk types in CCF file sent by STEP2
Figure 2-6 : Bulk types in PCF file sent by STEP2
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 19 of 154
2.2 Connecting to STEP2 as a Direct Participant
Direct participants connect to STEP2 as the following: � STEP2 receives payment instructions for processing from Direct Participants and transmits processed payment instructions to Direct Participants in bulk files; and � In addition, all reporting and reconciliation information is transmitted to Direct Participants in files or reported via an Internet-browser based enquiry terminal (Direct Participant Web Station, or DPWS). The STEP2 system expects all files it receives to be strictly formatted in accordance with the STEP2 file specifications laid out in this document. All files transmitted by the STEP2 system are similarly formatted in accordance with these standards. To maximise the possible degree of STP, all files are designed to be easily readable by machines. Banks that join the service must be able to send and receive structured files in the STEP2 standard. Direct participants must understand the options open to them for the routing of their transactions within each service. STEP2 provides facilities for the automatic routing of transactions � Directly – where the originating/beneficiary bank is a Direct Participant; � Indirectly – where the originating/beneficiary bank is an Indirect Participant; or for some services. Routing via sender nominated intermediaries is not supported.
2.2.1 Connecting to STEP2 via a STEP2-enabled payment system
Direct participants may choose to modify their existing, internal payment systems to communicate directly with STEP2. The architecture of this option is shown in Figure 2-7: Connection via a STEP2-enable payment system.
Figure 2-7: Connection via a STEP2-enable payment system
STEP2 Central System
Network1,7
1,2,3,4,7
Direct ParticipantPayment System(s)
1,7
1,2,3,4,7
WebstationInterface 5 6
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 20 of 154
Flow Description
1 Transmission of files of transactions to the STEP2 central system and the reception of information from the STEP2 central system on the success of validation of those files.
2 Transmission of processed transactions from the STEP2 central system to the Direct Participant.
3 Transmission of exception messages from the STEP2 central system to the Direct Participant.
4 Transmission of reconciliation information (daily and monthly) from the STEP2 central system to the Direct Participant.
5 Execution of enquiries on the central system and the delivery of browser-based reports on online data held within the central system.
6 Internal routing of received transactions within the STEP2 central system. 7 Recovery of information from the STEP2 central system in the event of data loss at the
Direct Participant. All Interfaces to supported networks.
Table 2-1 Connection via a STEP2-enabled payment system
2.3 STEP2 SCT File Types
2.3.1 Input Credit File (ICF)
Direct participant’s systems must transmit transactions to the central system in Input Credit Files (ICF). Each ICF must have a unique Sender’s File Reference (SFR). The precise format required for an ICF is specified in the Appendices. Direct participants need not transmit ICFs to the Central System for every settlement cycle. However, a configurable maximum number of ICFs per Direct Participant per settlement cycle is enforced by the STEP2 central system. Immediately upon receipt of an ICF by the STEP2 central system the network returns a network acknowledgement of receipt (ACK or Delivery Notification) to the Direct Participant’s system; receipt of this acknowledgement signals to the Direct Participant that the file has been received and will be processed further.
2.3.2 Credit Validation File (CVF)
Irrespective of the result of validation, one and only one Credit Validation File (CVF) is returned per transmitted ICF to the sending Direct Participant indicating the success or otherwise of the validation process. The structure of a CVF and the range and meaning of errors codes are defined in the Appendices. Direct participants which receive a CVF indicating complete acceptance of the file do not need to take any further action for settlement. Direct participants receiving CVFs that indicate complete rejection or partial acceptance of a file should consult the details of the CVF, correct the error(s) and retransmit the entire file, bulk or erroneous credit transfers instructions only, as appropriate. In case of complete rejection of an element (not partial acceptance), the same reference can be reused when resending the transaction, bulk or file as it has not been stored by the Central System. Note that CVFs indicating complete acceptance do not contain any specific rejected transactions. CVFs indicating partial acceptance of an ICF will contain specific rejected transactions. CVFs indicating complete rejection of an ICF may contain specific rejected credit transfer instructions only if all the credit
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 21 of 154
transfers have been rejected individually; under these circumstances, the rejected transactions in the CVF give the user information to enable diagnosis of the problem.
2.3.3 Settled Credit File (SCF)
Settled transactions will be delivered to the relevant counterparty Direct Participant in a SCF after settlement of the transaction is completed. The structure of a SCF and the contents are defined in the Appendices. Direct participants receiving a SCF are notified of all the Credit Transfers and Returns that were successfully settled for the last settlement cycle for which they are the counterparty. The number of SCF to be received by a DP is configurable as a participant configuration parameter from 1 to 3 as follows:
1. One SCF if the direct participant wants to receive all its transactions in one file (transactions for the direct participant, transactions for its indirect participants, returns)
2. Two SCF if the direct participant wants to split in one side all the direct participant transactions (included direct participant returns) and in the other side indirect participants transactions (included indirect participants’ returns)
3. Three SCF if the direct participant wants to have in one hand all credit transactions from the direct participant and in the other hand all credit transactions from its indirect participants and in a third file all the returns received for the direct participant and its indirect participants.
SCF files may be split into several different files when service configuration limits are exceeded for: • number of bulks per file • the total number of transactions per bulk • the file exceeds the network limit for a file to be transmitted.
SCF Files will also be used to carry information regarding the Recall of a Settled Credit transfer. In this case an SCF file could also contain the following message types: camt.056 and camt.029. These messages are not relevant to settlement as they do not cause a money transfer between counterparts.
2.3.4 Cancelled Credit File (CCF)
Originating Direct Participants are notified of any cancelled instructions at settlement level via a CCF. The structure of a CCF and the contents are defined in the Appendices.
2.3.5 Payment Cancellation File (PCF) - Optional
The File is generated and sent to the Direct Participant only if the participant explicitly requires to receive the file. The file is sent after each settlement cycle if the Direct Participant has sent at least one PCR (camt.056) message in the previous validation window that precedes the current settlement cycle, otherwise the file will not be generated even if the DP is configured to receive it. The structure of a PCF and the contents are defined in the Appendices.
2.3.6 Routing Table File (RTF)
The routing table file consists of the Direct and Indirect Participant lists sent to all STEP2 Direct Participants to allow them to implement an automated handling of the information in their backoffice applications. These are a total of two files sent, one with the Direct Participant list and one for the Indirect Participant list.
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 22 of 154
The RTF are sent monthly to the STEP2 Direct Participants according to a calendar published by EBA Clearing (see EBA Clearing website for details).
2.3.7 Reports Files
2.3.7.1 Reception of reconciliation and statistical reports
Following transmission of settlement results, information to assist reconciliation is forwarded by STEP2 to Direct Participants. There are three forms of reconciliation information.
1. Cycle reconciliation report; 2. Daily reconciliation information; and 3. Optional monthly statistics information. These reports are service specific, e.g. one report per service will be made available.
2.3.7.2 Cycle Reconciliation Report (CRR)
The Cycle Reconciliation Report will include the data to allow Participant reconciliation in terms of amounts debited and credited for the relevant settlement cycle. This file is sent by the Central System at the end of each settlement cycle in a window specified during the daily cycle. The structure of a CRR and the contents are defined in Appendix F.1
2.3.7.3 Daily Reconciliation Report (DRR)
The Daily Reconciliation Report will include the data to allow Participant reconciliation in terms of transactions sent and received and in terms of amounts debited and credited for the relevant business date. This file is sent by the central system during the output phase in a window specified at the end of the daily cycles. The structure of a DRR and the contents are defined in Appendix F.2.
2.3.7.4 Monthly Statistical Report (MSR)
The Monthly Statistical Report will include the data to allow Participant statistical reconciliation in terms of transactions sent and received and in terms of amounts debited and credited. The file will be transmitted following the close of the last settlement cycle of the last Target day of each month, following the opening of the processing for first Target day of the next month. The structure of a MSR and the contents are defined in Appendix F.3. This report’s contents may be used, for example, for billing purposes, as the Banks receive the total of transactions exchanged and settled on monthly basis.
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 23 of 154
3. STEP2 FILE EXCHANGE FUNDAMENTALS
3.1 STEP2 SCT Timetable
STEP2 is operational on all TARGET days. On non-target days, STEP2 processing ceases at midnight at the end of the previous TARGET day and recommences at midnight at the beginning of the next TARGET day. However, the service will only validate received files and send responses during real-time validation windows. Outside of these times and during normal business (TARGET) days, received files are subject to ‘deferred validation’, meaning that STEP2 will validate and send responses once the service re-opens. The STEP2 Credit service will support payment warehousing that consists of credits and returns sent a number of days ahead of value date, the number of days dependent on the business requirement of the User Community. File cancellation or individual credit cancellation within a file, for those held in storage prior to the start of the relevant processing cycle will be available through the use of the ISO20022 Payment Cancellation Request (camt.056) message format. PCR message could also be used after settlement cycle of CT, in this case the message is forwarded to the counterpart (Creditor Bank) which can accept the Recall of the CR with a Return Message (pacs.004) or reject it with a Resolution of Investigation message (camt.029). The service consists of a number of processing and settlement cycles per day. They will have an Opening Time, after which files will be accepted to start up processing; included files received for the next processing cycle stored in secure environment and all the credits stored in the data warehousing with the same value date of the processing day. During the last settlement cycle of the day, after the sending cut-off, the system will start validating files for the next business date (target days only). This applies also in the case the last settlement cycle of the day is an optional settlement cycle.
3.2 STEP2 SCT Settlement Cycles
Details on the number of Settlement Cycles and precise timings will be documented as parameters within the Service Overview document. Settlement of validated transactions will occur in a specific settlement cycle in the day depending on Debtor and Creditor Agent configuration. Transactions will be settled in the first settlement cycle where both agents are configured to settle. During validation, if there are no more available cycles for both agents in the business date, the transaction will be rejected within the CVF file. After settlement cancellation, the transaction will be automatically resubmitted to the next available settlement cycle. If no more cycle are available for settlement of both debtor and creditor agents, the transaction will be cancelled within a CCF file sent to debtor agent. If the system is configured to have the last settlement cycle of the day as a mandatory cycle, the CCF files are always generated after this cycle, whereas if the last settlement cycle is optional the CCF files may be generated after different cycles depending on participant configurations regarding the settlement cycles.
3.3 File exchange security
Files exchanged between Direct Participants and the STEP2 central system are secured (digitally signed) by features of the network within the STEP2 central system and on Direct Participants’ premises to ensure the authenticity and integrity of the files exchanged. Files that are received by the STEP2 central
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 24 of 154
system whose security credentials are found to be in less than perfect order are immediately rejected and no further processing is performed.
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 25 of 154
3.4 File formats, naming conventions, and format versioning
STEP2 SCT files are based on XML standards and made of different levels of Headers as well as messages of different types. Each file has a specific STEP2 Header (STEP2 standard) and is made of a body of messages grouped into ‘bulks’, according to the proposed ISO 20022 standards. The body will contain standard SWIFT message formats wherever possible so that standard software tools can be used to parse and generate the files. EBA CLEARING is dedicated to the use of widespread international standards. Where the application demands deviations from these standards these will be kept to a minimum and clearly highlighted in the content and validation rules given in the appendices. From time to time as additional services are introduced it may be necessary to modify the ISO file specifications to support additional functionality. In order to insulate existing STEP2 participants from the details of these changes until absolutely necessary STEP2 will examine the file name of the physical file and take this as an indication of the format contained within it. This method gives EBA CLEARING the flexibility to manage standards with the minimum of disruption to participants.
3.5 File Naming Conventions
3.5.1 Network File Names
The Network File Name is the identifier of the file as it is transferred over the file exchange. STEP2 network filenames structures are as follows: EEVVSSSBBBBBBBBX…X.Z The meaning of these fields is as follows: EE must be S2 (STEP2); VV is the format version (02 = XML for files and text format for reports); SSS is the three character service identifier, SCT in this case; BBBBBBBB is the BIC(8) of the Direct Participant; X…X (optional) is up to 15 characters for use by the Direct Participant; and Z indicates the type of the file, where:
� I = ICF; � V = CVF; � N = SCF; � C = CCF; � L = PCF; � R = CRR; � D = DRR � M = MSR � T = RTF
All Direct Participants sending files to the STEP2 central system must adopt this convention. The X…X field is not validated. The STEP2 central system generates files with X…X fields as follows: YYMMDDHHMMSSNNN, where: YYMMDDHHMMSS, which is the file creation date and time, and
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 26 of 154
NNN, which is an incremental number starting from 000 that is reset to 000 every time DD (date) changes (this number is global for all files sent by CS and not specific to a single DP). Note that in the case of STEP2 generated files, the BIC part of the Filename (BBBBBBBB) is the BIC of the Direct Participant (and not the STEP2 BIC). The following standards apply to filenames: No leading spaces are allowed; No internal spaces are allowed; Trailing spaces are ignored; and Alpha characters are case insensitive, e.g. “filename” is the same as “FILENAME” and “Filename”.
In the case of the RTF, the first character of the incremental number (NNN) will be either: ‘D’ – to identify a Direct Participant Routing Table ‘I’ – to identify an Indirect Participant Routing Table
3.5.2 Sender’s File Reference (SFR)
The Sender’s File Reference is a unique identifier that is carried in the header of the file. Banks are free to use any reference as long as they comply with the following standards to Sender’s File References: No leading spaces are allowed; No internal spaces are allowed; Trailing spaces are ignored; and Alpha characters are case insensitive, e.g. “reference” is the same as “REFERENCE” and “Reference”. The STEP2 central system generates SFRs of a specific format. When generating SFRs in their own systems, Direct Participants must avoid clashes with this name-space. The format is: ASSSYYMMDDNNNNNN, where:
A indicates the type of file:
• I – Input Credit File (ICF) • V – Credit Validation File (CVF) • N – Settled Credit File (SCF) • C – Cancelled Credit File (CCF) • L – Payment Cancellation File (PCF) • R – Cycle Reconciliation Report (CRR) • D – Daily Reconciliation Report (DRR) • M – Monthly Statistics Report (MSR) • T – Routing Table File (RTF)
SSS is the three-character service identifier, e.g. “SCT”;
YYMMDD is the date of the generation of the file; and
NNNNNNNN is an incremental number that will restart from 00000001 every time DD, above, changes (this number is global for all files sent by CS and not specific to a single DP).
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 27 of 154
The SFR of a file rejected in its entirety may be reused to resend the file. However, once a file has been accepted in whole or part the SFR is registered within the STEP2 central system. Therefore, in order to retransmit corrected transactions from a partially rejected file a new unique SFR is required.
3.6 File format and bulks
Input Credit Files (ICF), Credit Validation File (CVF), Settled Credit Files (SCF) and Payment Cancellation Files (PCF) are made of messages bulks. These bulks must follow certain rules and guidelines to form a valid file to be processed by STEP2 or the Participating banks.
• Bulks are always made of a header and one or many messages; • Bulks can only contain a single type of message (ex: Credit Transfers, Returns or Payment
Cancellation Request) • Bulks always have a unique identifier (Message Identifier); • Messages in a Credit Transfer bulk must all have the same Interbank Settlement Date; • Multiple bulks with same Settlement Date can be present in a single file; and • Within a file containing different types of messages, bulks follow a specific order.
Bulks must be sorted in ICF file by Banks according to the XML Schema in a particular order:
1. Credit Transfers; 2. Payment Cancellation Request/Recall; 3. Returns/Positive Answer to Recall; 4. Resolution of Investigation/Negative Answer to Recall.
The order of bulks in files created by STEP2 CS is the one defined in the files XML Schema. There will be a total maximum number of bulks per files, both received and sent (all types of bulks, see STEP2 SEPA Credit Transfer Overview document). The maximum number of bulks per file as well as the total number of transactions per bulk (Credit Transfer and R-messages) are Central System parameters. STEP2 CS output files may be split into several different files when these limits are exceeded. Output files may also be split into several different files when the size of the file exceeds the network limit for a file to be transmitted. To calculate the file size, the size of every transaction inserted into the file is added considering a fixed hardcoded average value for the transaction size.
3.7 XML Schemas
The STEP2 SCT service uses XML schemas to define the files and messages exchanged between the Central System and the Participants. XML schemas define:
• Data fields to be used; • Status (optional, mandatory, recurring, “Either/Or”); • Formats of the information they contain; and • Content – in some cases (e.g. code lists) the permitted codes are carried within the schema.
XML schemas can be distributed and quickly integrated into XML applications (an XML Parser) to automatically generate validation code. This means that the STEP2 Central system and all banks’ participant systems can perform validation using the same schema, to verify messages being exchanged. This can happen without the need to write long, linear validation programs, each one based on the bank’s own interpretation of the standard. All the XML validation on STEP2 SCT will be performed using the STEP2 SCT schemas. Direct Participants will be expected to validate outgoing messages against these STEP2 SCT schemas and not, for example, the ISO schemas.
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 28 of 154
It should also be noted as a feature of XML parsing that Schema errors that are found will cause the rejection of an entire file sent to STEP2 (error code R10). As the bank has the opportunity to verify the entire file using the same schema before sending to STEP2 this should in reality never happen. The STEP2 schemas are a variant of the ISO 20022 schemas. They have been created by:
• Taking the original ISO20022 schemas • Removing all the fields that STEP2 does not accept • Where necessary, changing the status of Optional fields to Mandatory or Conditional
Note: in the few cases where the Format differs between the ISO standard and the STEP2 standard the schema has NOT been changed. In this case an additional check will be performed though a coded check.
3.8 Validation of Input Credit Files
Once received by the STEP2 central system, ICFs are validated during STEP2 real time validation window. Banks can send input files at any time to the central system but validation will only occur during the validation time window.
The file validation process has five phases:
1. The security-context (creation date & time and correct network identifiers) and network file name are checked;
2. Structural integrity verification, during which the basic structure and content of the ICF is verified against the schemas;
3. Duplicate removal, during which the ICF’s details are compared against the details of files already held by the STEP2 central system;
4. Bulk validation, during which the individual bulks contained within the ICF are validated against the validation rules for bulks; and
5. Transaction validation, during which the individual transactions contained within the ICF are validated against the validation rules specific to their format, including routing tables.
The precise details of the validation checks performed are defined in the Appendices of this document. If an ICF does not have perfect structural integrity or is found to be a duplicate, then it is rejected in its entirety and no further validation or processing is performed on the file or any of the transactions that it contains. If a bulk is found to be invalid, it is rejected in its entirety and no further validation or processing is performed on the bulk or any transaction that it contains. Errors discovered within transactions result in the erroneous payment instruction(s) being rejected and the remaining valid transactions being carried forward for processing (this is referred to as “partial acceptance”). However, a configurable limit (System Parameter) is placed on the maximum number of consecutive transaction errors that will be tolerated at the beginning of a single bulk by the STEP2 central system. Once the number of transaction errors discovered within a single bulk exceeds this limit, the bulk is assumed to be completely faulty and is rejected in its entirety and no further validation or processing is performed on it or any of the remaining transactions it contains.
3.9 BIC Validation
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 29 of 154
STEP2 checks the destination BIC against the Routing Table. In the case of a Return, considerable time may have elapsed between the settlement of a Credit Transfer and the Refund. The STEP2 Routing Table will contain, for all BICs that have changed or merged, the values of both the old BIC and the new BIC. If the destination BIC has changed, the Return is therefore routed to the correct BIC. Note that this lookup will not apply to Credit Transfers Messages, which should be submitted with the correct BIC in the first place.
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 30 of 154
3.10 STEP2 Message Routing
STEP2 Central System will route all the valid messages it receives to the counterparty according to its routing tables. This counterparty is referred to as the Instructed Agent. For Credit Transfers, the Instructed Agent is found using the Creditor Agent BIC. For Returns, the Instructed Agent is found using the Original Debtor Agent BIC contained in the copy of the original Credit Transfer being returned.
3.10.1 Routing process
The Routing of Credit Transfers, Returns, Payments Cancellation Req and Resolution of Investigation messages is a step of validation process which establishes the DP to be credited for this instruction. The routing process for Credit Transfers and Payment Cancellation Requests (Debtor Side) acts as follows:
1. The Direct Participant routing table of the service being processed is consulted. If a matching for the Creditor Agent BIC(8) of the instruction being routed is found within this table then:
• Transaction Routing is set to “DIR”
• Instructed Agent is stored and equals the Creditor Agent of the transaction; otherwise
2. The Indirect Participant routing table of the service being processed is consulted. If a matching for the Creditor Agent BIC of the transaction being routed is found within this table then:
• Transaction Routing = “IND”,
• Instructed Agent = the Direct Participant associated through the Indirect Participant routing table with the Indirect Participant identified in the Creditor Agent field of the transaction being routed; otherwise
3. The Creditor Agent is not known to the system, therefore:
• The transaction is rejected.
Note that a if a branch code is supplied in the Creditor Agent BIC(11) but the first 8 characters of this BIC match a Direct Participant BIC(8) then test 1, above, will succeed and the transaction will be routed to the matching Direct Participant. The matching process will follow the SWIFT rules for matching BIC(11) with “XXX” as the last three characters. For example, if the Creditor Agent is a BIC(11) and no exact match at BIC(11) is found in the Indirect Participant table but a matching BIC(8) (or BIC(8)+”XXX”) is found then test 2, above, will succeed and the transaction will be routed to the Direct Participant serving the matched Indirect Participant. The routing process for transactions originated from the Creditor side (Returns and Resolution of Investigation) is similar but will use the Debtor Agent BIC from the original transaction instead of the Creditor Agent BIC.
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 31 of 154
3.11 Retransmission of output files
3.11.1 File Retransmission Requested via STEP2 CS
When requested, the STEP2 central system can re-transmit files to Direct Participants via operational control. Files that are lost by a Direct Participant can therefore be recovered. Such retransmission is manually initiated on the STEP2 central system following a request from a Direct Participant. The mechanism of re-transmission is identical to that used for transmission of all files.
3.11.2 File Retransmission Requested via DPWS - SwiftNet
This functionality is limited to Participants that use SwiftNet to Send/Receive files to/from STEP2 CS. Participant operator connected to DPWS may require the retransmission of STEP2 output files. The operator must use a specific DPWS user enabled to use the Retransmission Function (new User Profile). The Retransmission request must be requesterd by one user and authorized by another user (Dual Control). The Participant requesting Re-Transmission of files is completely responsible for the correct processing of possible duplicate data in their system due to the re-transmission. STEP2 CS will always re-transmit the files with the same Network File Name, Internal Sender File Reference and Data Content. More details can be found in STEP2 DPWS User Manual.
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 32 of 154
4. HOW TO USE THE APPENDICES
The data elements used in the STEP2 messages described in Appendix C. They are based on the ISO20022 standards but do not allow all fields and options available within the ISO20022 standard. Table Heading Description
XML Element The ISO20022 XML tag name used to identify the field. Where the field is nested under other tags, this nesting is shown.
Format The format of the field that is expected 4a - Four alpha characters (capital) 4n - Four digits 4c – Four alphanumerical characters, letters are uppercase 4x – Four characters (any supported character) 4!a – Must be four alpha characters (and no less than four) in capital [3x] – Three optional characters ISODate – YYYY-MM-DD ISODateAndTime1 - YYYY-MM-DDThh:mm:ss ** CW ** - this label indicate whether the field has the “Collapse Whitespaces” setting in the XML Schema. The “Collapse Whitespaces” option could allow in the XML message fields with an extended length since the calculation of the field length is performed after applying the Collapse option.
Status Whether the field is M - Mandatory O - Optional C – Conditional further text will specify whether this field is
conditional on other fields being present. If a field does not exist in the table, it cannot be used (i.e. a message will be rejected if it is contained in the Input file, even if the field exists in the full ISO20022 standard.
Rule Book reference Where the Data element exists in the SEPA Credit Transfer Rulebook, as cross-reference has been given.
Validation rules This column details the validation that will be performed on the field. The first check is Schema Validation, and then subsequent checks are performed as stated in the content of the fields. Table 4-1 STEP2 XML definitions
The fields have been defined by taking the ISO 20022 schema as a superset, the SEPA Credit Transfer rulebook (including the Implementation guidelines) as a subset and adding the fields requested by the Banks designing the STEP2 SCT service. The fields required by the SEPA Rulebook and Implementation guidelines are identified in yellow.
1 The timezone (Thh:mm:ss) component is optional, as defined in the definition of the XML data type.
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 33 of 154
APPENDIX A FILE STRUCTURES AND DETAILS
A.1 STEP2 SCT BULK TYPES
A.1.1 ICF Bulk messages
The Input Credit File may contain multiple bulks. The number is set by the bank subject to a maximum threshold. Each bulk will contain the same
• Message Type, and • Interbank Settlement Date.
A.1.2 CVF Bulk messages
For each Bulk received by STEP2, one Bulk Payment Status message is returned. An ICF containing 20 Bulks, will be answered by one and one only File Validation Report containing exactly 20 Bulk Payment Status Messages. The CVF sent to the sender of the ICF contains one bulk for every bulk received from that sender. Each bulk contains the total number and value of the messages from the original bulk that were sent and passed validation.
The Payment Status Bulk will contain zero or more transactions, one for each message from the original bulk that failed validation. In the case where the received bulk itself has failed validation, e.g. the total number of transaction in the bulk header, does not equal the number of transactions in the body, then there will be a bulk rejection code, and the individual transactions will not be separately listed.
A.1.3 SCF Bulk messages
The messages and bulks sent to the receiving Direct Participants are grouped by Interbank Settlement Date, but there is not a one to one relationship between the Bulk messages received by STEP2 and the Bulk messages sent by STEP2.
A.1.4 CCF Bulk messages
The CCF file contains bulks corresponding to the original Credit Transfer bulks in the ICF.
A.1.5 PCF Bulk messages
The PCF file contains bulks corresponding to the original Credit Transfer bulks in the ICF.
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 34 of 154
A.2 ICF Multiple Bulks and restrictions
Multiple bulks of the same type are allowed in the ICF file. Bulks must be sorted by value date (Interbank Settlement Date). This implies having multiple bulks in the same ICF file. However, banks are free to add other sorting conditions to bulks as long as the value date condition is met. For example, a bank could sort Credit Transfer instruction bulks by value date and Creditor Agents. The maximum number of bulks per file as well as the total number of instructions (Credit Transfer and R-messages) are Central System parameters.
A.3 File Content Encoding
As per the SEPA Implementation Guidelines, STEP2 SCT supports the UTF-8 character set. However, banks are required only to support the Latin character set. a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space They can choose to receive transactions with non-Latin characters if this is subject to bilateral or multilateral agreements amongst themselves. This will not be checked or controlled by STEP SCT Central System.
A.4 Duplicate Checking
Every transaction must be uniquely identified within the system in order:
i) to stop duplication of data, ii) to find unambiguously one and one only data item when searching or matching.
In STEP2 the duplicate check is done by combining a set of fields to form a unique key. These fields are:
• The service; • The message type; • The reference of the item; and • The identity of the party that created the reference.
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 35 of 154
The following table gives the duplicate checking criteria for different files, bulks and transactions.
Return SCT PmtRtr (pacs.004) Return ID Original Creditor Agent
Interbank Settlement Date
Result of Investigation
SCT RsltnOfInvstgtn (camt.029)
Cancellation Status ID
Original Creditor Agent
Processing Date
Table 4-2 STEP2 Duplicate Checking
In each case:
Service: is taken from the header of the file. Message Type is taken from the MessageName XML tag of the ISO message. Note that the Processing Date is the actual date on which the data is being received and processed by the Central System (Camt.* messages do not have a Settlement Date).
During recovery scenarios, it is possible that the network will send and resend the same file to ensure delivery. It is important that the application behind the network is able to detect if file received, is the same file based on the duplicate checking criteria defined in Table 4-2. This includes the situation where a resend occurs on a different day to the day on which the file was originally sent. STEP2 is network independent application, and so it does not systematically use ‘Possible Duplicate’ flags to warn a participant if a file is resent. In some circumstances, a possible duplicate flag may be automatically set by the network middleware component, but the duplicate checking criteria defined in Table 4-2 take precedence over the network based flag that may or may not be set.
A.5 Message ID
The Message Id is a unique identifier that is carried in the header of the bulk. Banks are free to use any reference as long as they comply with the following standards to Message ID:
• No leading, internal or trailing spaces are allowed;
• Alpha characters are case insensitive, e.g. “reference” is the same as “REFERENCE” and “Reference”.
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 36 of 154
For Credit Transfers (pacs.008) sent to Direct Participants, the STEP2 Central System generates Message ID of the output bulks. The format is:
FFFFFFFFFFFFFFFFNNNNNNNNNNNNNNNNNNN
First 16 chars: the file reference in which the bulk is contained; Last 19 chars: a progressive number. FFFFFFFFFFFFFFFF is the File Reference generated by CS. The details on the File Reference naming scheme can be found in Section 3.6.2. NNNNNNNNNNNNNNN is an incremental number which restarts at 000000000000001 when a new file is generated.
The Message ID of a completely rejected bulk may be reused to resend the file. However, once a bulk has been accepted in whole or part the Message ID is registered within the STEP2 central system. Therefore, in order to retransmit corrected transactions from a partially rejected bulk a new unique Message ID is required.
For Returns (pacs.004) sent to Direct Participants, STEP2 Central System uses the same Message ID generation method as for the Credit Transfers. However, the Original Message Id of a Return is always the one used by the bank originating the bulk of returns and is not replaced by the Message Id of the original Credit Transfer bulk.
Figure 4-1: STEP2 SCT Original Message Id in Returns
A.6 Schema validation
The content of some XML fields is validated at the schema level. For example, fields with required value as per Credit Transfer Implementation Guidelines (ex. “SEPA” or “CLRG”) are part of the schema validation. Moreover, fields with specific data format (ex. amounts) are also validated at schema level. When this schema validation fails, the error code is always R10 and the whole file will be rejected.
BANK1 BANK2
MessageID ABC
STEP2
MessageID XYZ
CT
OrgnlMsgID XYZ
RET
OrgnlMsgID XYZ RET
CT
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 37 of 154
A.7 Usage of Instructed and Instructing Agents
In the XML schema the Instructing/Instructed Agent fields appears at both the Group Header and the Individual transaction level. The rules for using these are described as follows. ICF
Pacs Messages Field Level Status Instructing Agent Group Header Mandatory Individual Transaction Not Present Instructed Agent Group Header Not Present Individual Transaction Not Present
Camt Messages Field Level Status
Assigner Group Header Mandatory Individual Transaction Not Present Assignee Group Header Mandatory Individual Transaction Not Present
CVF
Field Level Status
Instructing Agent Group Header Not Present Individual Transaction Not Present Instructed Agent Group Header Not Present Individual Transaction Not Present
SCF
Pacs Messages Field Level Status
Instructing Agent Group Header Not Present Individual Transaction Mandatory Instructed Agent Group Header Mandatory Individual Transaction Not Present
Camt Messages Field Level Status Assigner Group Header Mandatory Individual Transaction Mandatory Assignee Group Header Mandatory Individual Transaction Not Present
CCF
Field Level Status
Instructing Agent Group Header Mandatory Individual Transaction Not Present Instructed Agent Group Header Not Present Individual Transaction Mandatory
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 38 of 154
PCF
Field Level Status
Instructing Agent Group Header Mandatory
Individual Transaction Not Present
Instructed Agent Group Header Not Present
Individual Transaction Mandatory
Table 4-3 Use of Instructing and Instructed Agent
A.8 Recall Procedure
A new Recall procedure is introduced with the SCT Rulebook version 4.0 in 2010. The message type “pacs.006” (Request For Cancellation) has been removed from the system (and also ISO Standards) and is substituted with the message type “camt.056” (Payment Cancellation Request) to cancel Credit Transfer not yet settled. When STEP2 CS receives a camt.056 message from bank, the following situations could occur in relation to the original Credit transfer (pacs.008): A. The CT has not been yet settled B. The sending cut-off for the settlement of the pacs.008 has already been reached but settlement is
still in progress C. The settlement of the pacs.008 is finished and the CT is settled D. The settlement of the pacs.008 is finished and the CT is cancelled � In case A: the camt.056 message will be processed as currently is done for the pacs.006. The original
credit transfer will be cancelled and not forwarded to settlement. The status of the original Credit Transfer will be changed in “RFC”.
� In case B: the camt.056 message will be forwarded to the counterpart regardless of the settlement result for the original Credit Transfer. The status of the original Credit Transfer won’t be changed. In the case the CT is cancelled by settlement and is not forwarded within SCF file, the counterpart may reject the recall message with a camt.029 with reason “NOOR” (Original Credit Transfer Never Received). The camt.056 will be included in the SCF file of the next settlement cycle, not in the one generated for the settlement cycle in progress.
� In case C: the camt.056 message will be forwarded to the counterpart. The status of the original Credit Transfer won’t be changed.
� In case D: the camt.056 message will be rejected to the sending bank within a CVF file. The status of the original Credit Transfer won’t be changed
EBA STEP2 CS do not perform any matching check with the original pacs.008/camt.056 when validating camt.029 or pacs.004 messages. Only Schema and format validation are performed on these messages by STEP2 CS. Consequently, no changing of status is performed on the original pacs.008/camt.056 message after processing the recall response. Debtor Bank must trigger the Recall Procedure (with camt.056) within 10 days from CT settlement as for EPC Rulebook requirement, and Beneficiary Bank has 10 more days to answer with camt.029 or pacs.004 message from the receipt of the camt.056. No checks are performed by STEP2 CS on the elapsed period for reception of the camt.056 or camt.029 message and these messages will always be accepted (after Schema and Format positive validation) and forwarded to the counterpart. The camt.056 and camt.029 messages can be sent by Banks to STEP2 CS within ICF files. These messages will be delivered by STEP2 CS to the counterpart Bank within SCF files in the first delivery of output files phase available (for camt.056 only after pacs.008 settlement).
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 39 of 154
Each Direct Participant may (Optionally) require (Participant Configuration) the generation and transmission of the Payment Cancellation File (PCF). The file will contain a Payment Status Report (Pacs.002S2) for each Credit Transfer object of a Recall Procedure specifying if the original CT was processed as case A, B or C above. This will allow the DP to know if the PCR has cancelled the original CT before settlement or if the PCR was forwarded to the counterpart as the original CT was already settled. Specifically, in the Transaction Details (TxInfAndSts+StsRsnInf++Rsn+++Prtry) the following values will be set:
• “CANC” = the PCR was processed before the settlement of the original Credit Transfer. The original CT was not settled.
• “RCLL” = the PCR was processed after the settlement of the original Credit Transfer. The CT has been settled/cancelled and the Recall Request was forwarded to the Beneficiary Bank of the original CT.
A.9 Usage of Creditor/Debtor Agent in pacs.002S2
The table below, describe the rules applied by STEP2 CS to set the following fields in the pacs.002S2 message in CVF files: • FIToFIPmtStsRptS2/TxInfAndSts/OrgnlTxRef/DbtrAgt • FIToFIPmtStsRptS2/TxInfAndSts/OrgnlTxRef/CdtrAgt
Message fields Money transfer
Message Type Debtor Agent
Creditor Agent
Debtor
Bank
Creditor
Bank
CT Pacs.008 (ICF) BANK1 BANK2 BANK1 BANK2
REJ of CT Pacs.002S2 (CVF) BANK1 BANK2
PCR Camt.056 (ICF) BANK1 BANK2
REJ of PCR pacs.002S2 (CVF) BANK1 BANK2
ROI Camt.029 (ICF) BANK1 BANK2
REJ of ROI pacs.002S2 (CVF) BANK1 BANK2
RET Pacs.004 (ICF) BANK1 BANK2 BANK2 BANK1
REJ of RET pacs.002S2 (CVF) BANK1 BANK2
Table 4-4 - CR/DB Agent in pacs.002S2
A.10 Setting the Settlement Cycle
Direct Participants sending ICF files may require to settle Credit transfer Bulks (pacs.008) in a specific settlement cycle setting the settlement cycle number in the following field:
GrpHdr +SttlmInf ++ClrSys +++Prtry
The format checks on the field will admit the following options:
1- “ST2” : normal setting of the field. Does not require any specific settlement cycle 2- “ST2nn” : where “nn” is the required settlement cycle in numeric format starting from ‘00’ to ‘XX’
where XX is the maximum number of settlement cycles configured in the system minus 1. Any other format will not be accepted causing the entire bulk rejection (error code B16). The following other errors may be possible when setting a specific settlement cycle:
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 40 of 154
� The required settlement cycle for payments not in warehouse has been already completed; In this case the bulk is rejected with error code “B16”.
� The required settlement cycle is currently being processed, therefore the sending cut-off has already expired. In this case the bulk is rejected with error code “B16”.
� The Debtor and Creditor Banks are not configured to settle in the required settlement cycle. In this case, the single payment will be submitted to the next available settlement cycle (of the same settlement date) to which both Participants are configured to settle. In the case a suitable settlement cycle can not be found, the single payment will be rejected with error code “XT85”.
Whether the settlement cycle is not specified, payments will be settled in the first settlement cycle available for the specified settlement date where both participants are configured to settle.
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 41 of 154
APPENDIX B XML FILES HEADERS
B.1 INPUT CREDIT FILE (ICF) HEADER
The STEP2 schema SctIcfBlkCdtTrf specifies the ICF.
Status Field Name XML Element Format Notes
M Sending Institution SndgInst 4!a2!a2!c It must always be the BIC of the Direct Participant sending the file.
M Receiving Institution RcvgInst 4!a2!a2!c The STEP2 BIC.
M File Reference FileRef 16!c The Direct Participant reference of the ICF.
M Service Identifier SrvcId 3!a Must be SCT
M Test Code TstCode 1!a Must be always “T” or “P”, depending on the environment used
M File Type FType 3!a Must be always “ICF”.
M File Date and Time FDtTm ISODateTime The file creation Date and Time
M Total Number of pacs.008 Bulks
NumCTBlk 8n The total number of Credit Transfers bulks contained in the ICF.
M Total Number of camt.056 Payment Cancellation Request bulks
NumPCRBlk 8n The total number of Payment Cancellation Requests bulks contained in the ICF.
M Total Number of pacs.004 Bulks
NumRFRBlk 8n The total number of Returns bulks contained in the ICF.
M Total Number of camt.029 Result of Investigation bulks
NumROIBlk 8n The total number of Resolution of Investigation bulks contained in the ICF.
Table 4-5 Input Credit File (ICF) XML Header Elements
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 42 of 154
B.2 XML Credit Validation File (CVF) Header
The CVF is specified by the STEP2 schema SctCvfBlkCdtTrf.
Status Field Name XML Element Format Notes
M Sending Institution
SndgInst 4!a2!a2!c The STEP2 SCT CS BIC code.
M Receiving Institution
RcvgInst 4!a2!a2!c If rejected payment instructions are present then RcvgInst will equal the Instructing Agent element in the (SWIFT) Header (which contains information from the original ICF).
M Service Identifier SrvcId 3!a The STEP2 service identifier : SCT
M Test Code TstCode 1!a Always “T” or “P”, depending on the environment used
M File Type Ftype 3!a Always “CVF”.
M File Reference FileRef 16!c The STEP2 reference of the CVF.
M File Date and Time FDtTm ISODateTime
The file creation Date and Time
O Original File Reference
OrigFRef 16c In circumstances where it has not been possible to gather this information OrigFRef will not be present.
M Original File Name OrigFName 32x Original ICF File Name.
O Original Date And Time
OrigDtTm ISO Date & Time
On circumstances where it has not been possible to gather this information OrigDtTm will not be present.
M File Reject Reason FileRjctRsn 3!c The ICF reject reason code. (see Appendix D)
M File Business Date FileBusDt ISO Date The business date in which this file was created by the STEP2 central system.
M File Cycle Number FileCycleNo 2!n The cycle in which this file was created by the STEP2 central system.
Table 4-6 Credit Validation File (CVF) XML Header Elements
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 43 of 154
B.3 XML Settled Credit File (SCF) STEP2 File Header
The SCF is specified by the STEP2 schema SCTScfBlkCdtTrf.
Status Field Name XML
Element
Format Notes
M Sending Institution
SndgInst 4!a2!a2!c The STEP2 CS BIC code.
M Receiving Institution
RcvgInst 4!a2!a2!c The BIC of the Direct Participant receiving the file.
M Service Identifier SrvcId 3!a Must be SCT
M Test Code TstCode 1!a Must be always “T” or “P”, depending on the environment used
M File Type FType 3!a Must be always “SCF”.
M File Reference FileRef 16!c The SCF file reference
M Routing Indicator
RoutingInd 3!a The routing Indicator
DIR: Direct Participant File
IND: Indirect Participant File
ALL: Both
RET: Return File
M File Business Date
FileBusDt ISO Date The business date in which this file was created by the STEP2 central system.
M File Cycle Number
FileCycleNo 2!n The cycle in which this file was created by the STEP2 central system.
This is a Credit Transfer transaction either sent by a Direct Participant to STEP2 (ICF) or by STEP2 to a Direct Participant (SCF).
C.1.1 SCT Credit Transfer (pacs.008) Bulk Header
Index XML Tag Format Status Rulebook Ref
EPC SCT Implementation Guidelines - Usage rules
STEP2 Usage Rules and Validations
1.1 GrpHdr
+MsgId
35x M NA ICF: The DP’s bulk reference.
SCF: STEP2’s bulk reference.
• Uniqueness is checked for ICF bulks: error code B14; and
• This identification cannot include leading, trailing or internal spaces (schema validation).
1.2 GrpHdr
+CreDtTm
ISODate
&Time M NA The date & time in which this bulk was created by the
DP.
1.4 GrpHdr
+NbOfTxs
15n M NA The number of transactions included in this bulk.
• Must not be greater than the Maximum Number Of Transactions parameter: error code B02; and
• Must be the total number of transactions included in this bulk: error code B03.
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 46 of 154
Index XML Tag Format Status Rulebook
Ref
EPC SCT Implementation
Guidelines - Usage rules
STEP2 Usage Rules and Validations
1.6 GrpHdr
+TtlIntrBkSttlmAmt
Attribute
18d
EUR
M
M
NA Mandatory
• Only ‘EUR’ is allowed.
• Amount must be 0.01 or more and 999999999999999.99 or less.
• The fractional part has a maximum of two digits.
The total amount of transactions inside this bulk.
• Values are supported with up to 15 digits in the integer part a decimal point and up to 2 fraction digits (schema validation);
• Currency attribute is always “EUR” (schema validation);
• Must equal the sum of individual transactions inside the bulk: error code B05; and
• Amount must be greater than zero: error code B13.
1.7 GrpHdr
+IntrBkSttlmDt
ISO DATE M AT-42 Mandatory The business date in which the transactions inside this bulk must be settled in the relevant settlement mechanism.
• IntrBkSttlmDt must be in the allowed range: error code B15.
1.9 GrpHdr
+SttlmInf
++SttlmMtd
4!a M NA Only CLRG, INGA and INDA are allowed. Information on settlement method.
• Only the value “CLRG” is supported (schema validation).
1.11 GrpHdr
+SttlmInf
++ClrSys
+++Prtry
35x M NA Proprietary identification of the Clearing System.
• Value must be ‘ST2’ or ‘ST2nn’ , where ‘nn’ is the required settlement cycle (Ref. A.10): error code B16.
• ‘nn’ must always be in numeric format with two digits : error code B16.
• The required settlement cycle must be a suitable settlement cycle (Sending Cut-Off not already reached): error code B16.
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 47 of 154
Index XML Tag Format Status Rulebook
Ref
EPC SCT Implementation
Guidelines - Usage rules
STEP2 Usage Rules and Validations
1.32 GrpHdr
+InstgAgt
++FinInstnId
+++BIC
4!a2!a2!c C NA Only BIC is allowed. The DP originating this bulk.
• Must be present in ICF: error code B10; and
• Must equal SndgInst element in ICF and must not contain a branch code: error code B10.
1.33 GrpHdr
+InstdAgt
++FinInstnId
+++BIC
4!a2!a2!c C NA Only BIC is allowed. The DP receiving this bulk.
• Used only in SCF: error code B11; and
• Equals Receiving Inst element in SCF: error code B11.
Table 4-10 SCT Credit Transfer (pacs008) Bulk Header
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 48 of 154
C.1.2 SCT Credit Transfer (pacs.008) Individual Transaction
Index XML tag Format Status
Rulebook Ref
EPC SCT Implementation Guidelines - Usage rules
STEP2 Usage Rules and Validation Rules
2.2 CdtTrfTxInf
+PmtId
++InstrId
35x O NA The Instruction Id.
• This identification cannot include leading, trailing or internal spaces (schema validation).
2.3 CdtTrfTxInf
+PmtId
++EndToEndId
35x
**CW**
M AT-41 A customer reference that must be passed on in the end-to-end chain. In the event that no reference was given, ‘NOTPROVIDED’ must be used.
The End to End Id.
•
2.4 CdtTrfTxInf
+PmtId
++TxId
35x M AT-43 Must contain a reference that is meaningful to the Originator’s Bank and is unique over time.
The Transaction Id.
• Uniqueness is checked under the rules for duplicate checking: error code AM05; and
• This identification cannot include leading, trailing or internal spaces (schema validation).
2.10 CdtTrfTxInf
+PmtTpInf
++SvcLvl
++Cd
4!a M AT-40 Only ‘SEPA’ is allowed. The Identification Code of the Scheme
• Must be “SEPA” (schema validation).
2.13 CdtTrfTxInf
+PmtTpInf
++LclInstrm
+++Cd
35x
**CW**
C NA Only used if bilaterally agreed between the Debtor Bank and the Creditor Bank.
The transaction Local Instrument.
• Cannot be used at the same time as Prtry (below) (schema validation); and
• The value is based on an external list and is not checked by the CS.
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 49 of 154
Index XML tag Format Status
Rulebook
Ref
EPC SCT Implementation
Guidelines - Usage rules STEP2 Usage Rules and Validation Rules
2.14 CdtTrfTxInf
+PmtTpInf
++LclInstrm
+++Prtry
35x C NA The transaction Local Instrument Proprietary.
• Cannot be used at the same time as Cd (above) (schema validation);
• The value is based on an external list and is not checked by the CS;
• This identification cannot include leading, trailing or internal spaces (schema validation).
2.16 CdtTrfTxInf
+PmtTpInf
++CtgyPurp
+++Cd
4x
**CW**
C AT-45 Depending on the agreement between the Originator and the Originator Bank, ‘Category Purpose’ may be forwarded to the Beneficiary Bank.
The Category Purpose of the transaction (ISO 20022 Code values).
• 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**
C 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).
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 50 of 154
Index XML tag Format Status
Rulebook
Ref
EPC SCT Implementation
Guidelines - Usage rules STEP2 Usage Rules and Validation Rules
2.18 CdtTrfTxInf
+IntrBkSttlmAmt
Attribute
18d
EUR
M
M
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.
2.19 CdtTrfTxInf
+IntrBkSttlmDt
ISO DATE
O NA The Interbank Settlement Date
2.29 CdtTrfTxInf
+AccptncDtTm
ISO Date O NA The Acceptance Date & Time.
2.31 CdtTrfTxInf
+InstdAmt
Attribute
18d
3!a
O
M
NA The Instructed Amount
2.32 CdtTrfTxInf
+XchgRate
11d O NA The Exchange rate of the Credit Transfer.
2.33 CdtTrfTxInf
+ChrgBr
4!a M NA Only SLEV is allowed (schema validation).
The Charge Bearer
•
2.35 CdtTrfTxInf +ChrgsInf ++Amt
Attribute
18d
3!a
O
M
NA The Charges Amount.
• Only one occurrence is allowed (schema validation).
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 51 of 154
Index XML tag Format Status
Rulebook
Ref
EPC SCT Implementation
Guidelines - Usage rules STEP2 Usage Rules and Validation Rules
2.36 CdtTrfTxInf +ChrgsInf ++Pty +++FinInstnId
++++BIC
4!a2!a2!c[3!c]
O NA The Charges Party.
• Only one occurrence is allowed (schema validation).
O AT-08 ‘Name’ is limited to 70 characters in length.
The Name of the Originator Reference Party.
2.47 CdtTrfTxInf
+UltmtDbtr ++PstlAdr
+++Ctry
2!a C
NA
Country of the Ultimate Debtor address.
2.47 CdtTrfTxInf
+UltmtDbtr ++PstlAdr
+++AdrLine
70x
**CW**
O
NA
The Ultimate Debtor address.
• Address line can have a maximum of two occurrences. (schema validation)
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 52 of 154
Index XML tag Format Status
Rulebook
Ref
EPC SCT Implementation
Guidelines - Usage rules STEP2 Usage Rules and Validation Rules
2.47 CdtTrfTxInf
+UltmtDbtr ++Id
+++OrgId
See Schema
C
AT-09
Either ‘BIC or BEI’ or one occurrence of ‘Other’ is allowed.
The identification of the Ultimate Debtor: Organisation Id.
• Cannot be used at the same time as Id/PrvtId (below) (schema validation);
• Only one occurrence of Othr is allowed (schema validation);
• All of the ISO options are available (see ISO document or schema).
• Either ‘BIC or BEI’ or one occurrence of ‘Other’ is allowed.
2.47 CdtTrfTxInf
+UltmtDbtr ++Id
+++PrvtId
See Schema
C
AT-09
Either ‘Date and Place of Birth’ or one occurrence of ‘Other’ is allowed.
The identification of the Ultimate Debtor: Private Id.
• Cannot be used at the same time as Id/OrgId (above) (schema validation);
• Only one occurrence of Othr is allowed (schema validation);
• All of the ISO options are available (see ISO document or schema).
2.47 CdtTrfTxInf
+UltmtDbtr
++CtryOfRes
2!a O
NA
The Country of Residence of the Ultimate Debtor.
2.49 CdtTrfTxInf
+Dbtr
++Nm
70x
**CW**
M AT-02 ‘Name’ is limited to 70 characters in length.
The Name of the Debtor.
2.49 CdtTrfTxInf
+Dbtr ++PstlAdr
+++Ctry
2!a O AT-03 Country of the Debtor address.
• Must be a valid country code according to ISO 3166. Error code: XT73.
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 53 of 154
Index XML tag Format Status
Rulebook
Ref
EPC SCT Implementation
Guidelines - Usage rules STEP2 Usage Rules and Validation Rules
2.49 CdtTrfTxInf
+Dbtr ++PstlAdr +++AdrLine
70x
**CW**
O AT-03 Only two occurrences are allowed. The Debtor address.
• Address line can have a maximum of two occurrences (schema validation).
2.49 CdtTrfTxInf
+Dbtr
++Id
+++OrgId
See schema
C AT-10 Either ‘BIC or BEI’ or one occurrence of ‘Other’ is allowed.
The identification of the Debtor (Ordering identification code): Organisation ID.
• If used, cannot be used at the same time as Id/PrvtId (below) (schema validation);
• 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
C AT-10 Either ‘Date and Place of Birth’ or one occurrence of ‘Other’ is allowed.
The identification of the Debtor (Ordering identification code): Private ID.
• If used, cannot be used at the same time as Id/OrgId (above) (schema validation);
• 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 O NA The Country of Residence of the Debtor.
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 54 of 154
Index XML tag Format Status
Rulebook
Ref
EPC SCT Implementation
Guidelines - Usage rules STEP2 Usage Rules and Validation Rules
2.50 CdtTrfTxInf
+DbtrAcct ++Id
+++IBAN
2!a2!n30x
M AT-01 Only IBAN is allowed. The Debtor Account IBAN.
• First two characters must be valid according to ISO 3166 and correspond to country in SEPA: error code XT73;
• The third and the fourth characters must be digits: error code XT73; and
• The IBAN Check Digit is validated as per ISO13616: error code XD19.
2.51 CdtTrfTxInf
+DbtrAgt ++FinInstnId
+++BIC
4!a2!a2!c[3!c]
M AT-06 Only BIC is allowed. The Debtor Agent BIC.
• Must be an active DP or IP: error code PY01.
2.53 CdtTrfTxInf
+CdtrAgt ++FinInstnId
+++BIC
4!a2!a2!c[3!c]
M AT-23 Only BIC is allowed. • The Creditor Agent BIC.Must be an active DP or IP: error code PY01.
2.55 CdtTrfTxInf
+Cdtr ++Nm
70x
**CW**
M AT-21 ‘Name’ is limited to 70 characters in length.
The Name of the Creditor.
2.55 CdtTrfTxInf
+Cdtr ++PstlAdr
+++Ctry
2!a O AT-22 Country of the Creditor address.
• Must be a valid country code according to ISO3166. Error code: XT73.
2.55 CdtTrfTxInf
+Cdtr ++PstlAdr +++AdrLine
70x
**CW**
O AT-22 Only two occurrences are allowed. The Creditor address.
• Address line can have a maximum of two occurrences. (schema validation).
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 55 of 154
Index XML tag Format Status
Rulebook
Ref
EPC SCT Implementation
Guidelines - Usage rules STEP2 Usage Rules and Validation Rules
2.55 CdtTrfTxInf
+Cdtr
++Id
+++OrgId
See schema
C AT-24 Either ‘BIC or BEI’ or one occurrence of ‘Other’ is allowed.
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
C AT-24 Either ‘Date and Place of Birth’ or one occurrence of ‘Other’ is allowed.
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
2!a O NA The Country of Residence of the Creditor.
2.56 CdtTrfTxInf
+CdtrAcct ++Id
+++IBAN
2!a2!n30x
M AT-20 Only IBAN is allowed. The Creditor Account IBAN.
• First two characters must be valid according to ISO 3166 and correspond to country in SEPA: error code XT73;
• The third and the fourth characters must be digits: error code XT73; and
• The IBAN Check Digit is validated as per ISO13616: error code XD19.
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 56 of 154
Index XML tag Format Status
Rulebook
Ref
EPC SCT Implementation
Guidelines - Usage rules STEP2 Usage Rules and Validation Rules
2.57 CdtTrfTxInf
+UltmtCdtr
++Nm
70x
**CW**
O AT-28 ‘Name’ is limited to 70 characters in length.
The Name of the Beneficiary Reference Party.
2.57 CdtTrfTxInf
+UltmtCdtr ++PstlAdr
+++Ctry
2!a O NA Country of the Ultimate Creditor address.
2.57 CdtTrfTxInf
+UltmtCdtr ++PstlAdr
+++AdrLine
70x
**CW**
O NA The Ultimate Creditor Address.
• Address line can have a maximum of two occurrences (schema validation).
2.57 CdtTrfTxInf
+UltmtCdtr ++Id
+++OrgId
See Schemas
C AT-29 Either ‘BIC or BEI’ or one occurrence of ‘Other’ is allowed.
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.
2.57 CdtTrfTxInf
+UltmtCdtr ++Id
+++PrvtId
See Schemas
C AT-29 Either ‘Date and Place of Birth’ or one occurrence of ‘Other’ is allowed.
The identification of the Ultimate Creditor: Private Id.
• 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).
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 57 of 154
Index XML tag Format Status
Rulebook
Ref
EPC SCT Implementation
Guidelines - Usage rules STEP2 Usage Rules and Validation Rules
2.57 CdtTrfTxInf
+UltmtCdtr
++CtryOfRes
2!a O NA
The Country of Residence of the Ultimate Creditor.
2.59 CdtTrfTxInf
+InstrForCdtrAgt
++Cd
4!a O NA The Instruction for Creditor Agent (ISO20022 code).
• All of the ISO options are available (see ISO document or schema).
2.60 CdtTrfTxInf
+InstrForCdtrAgt
++InstrInf
140x
**CW**
O NA The Instruction for Creditor Agent.
2.65 CdtTrfTxInf
+Purp
++Cd
4x
**CW**
C AT-44 The Purpose of the transaction (ISO20022 Code).
• Cannot be used at the same time as Proprietary (below) (schema validation); and
• Codes are based on external list definition. This is not checked by STEP2.
2.66 CdtTrfTxInf
+Purp
++Prtry
35x
**CW**
C AT-44 The Purpose of the transaction (Proprietary).
• Cannot be used at the same time as Code (above) (schema validation).
2.67 CdtTrfTxInf
+RgltryRptg
See Schema
O NA The Regulatory Reporting.
• All ISO20022 fields are supported (schema validation).
2.68 CdtTrfTxInf
+RltdRmtInf
See Schema
O NA The Related Remittance Information.
• All ISO20022 fields are supported (schema validation).
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 58 of 154
Index XML tag Format Status
Rulebook
Ref
EPC SCT Implementation
Guidelines - Usage rules STEP2 Usage Rules and Validation Rules
2.76 CdtTrfTxInf
+RmtInf
++Ustrd
140x
**CW**
C AT-05 • ‘Unstructured’ may carry structured remittance information, as agreed between the Originator and the Beneficiary.
• Only one occurrence of ‘Unstructured’ is allowed.
Unstructured Remittance Information.
• Either Unstructured or Structured Remittance Information can be used (schema validation);
• Maximum of 10 occurrences of this field. (schema validation);
• First occurrence is yellow and optional; and • Subsequent occurrences are white and reserved
for future use. Error code: XT13.
2.77 CdtTrfTxInf
+RmtInf
++Strd
140x C AT-05 • ‘Structured’ can be used, provided the tags and the data within the ‘Structured’ element do not exceed 140 characters in length.
• Only one occurrence of ‘Structured’ is allowed.
Structured Remittance Information.
• 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.
2.78 CdtTrfTxInf
+RmtInf
++Strd
+++RfrdDocInf
See Schema
O AT-05 Referred Document Information.
2.86 CdtTrfTxInf
+RmtInf
++Strd
+++RfrdDocAmt
See Schema
O AT-05 Referred Document Amount.
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 59 of 154
Index XML tag Format Status
Rulebook
Ref
EPC SCT Implementation
Guidelines - Usage rules STEP2 Usage Rules and Validation Rules
2.100 CdtTrfTxInf
+RmtInf
++Strd
+++CdtrRefInf
++++Tp
+++++CdOrPrtry
++++++Cd
4!a O AT-05 When present, the Debtor Bank is not obliged to validate the reference information.
When used both ‘Type’ and ‘Reference’ must be present.
Creditor Reference Information Type Code.
• When used both ‘Type’ and ‘Reference’ must be present (schema validation); and
• Only “SCOR” is allowed (schema validation).
2.101 CdtTrfTxInf
+RmtInf
++Strd
+++CdtrRefInf
++++Tp
+++++CdOrPrtry
++++++Prtry
35x
**CW**
O AT-05 Creditor Reference Information Type Proprietary
• When used both ‘Type’ and ‘Reference’ must be present (schema validation).
2.102 CdtTrfTxInf
+RmtInf
++Strd
+++CdtrRefInf
++++Tp
+++++Issr
35x
**CW**
O AT-05 Creditor Reference Information Type Issuer.
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 60 of 154
Index XML tag Format Status
Rulebook
Ref
EPC SCT Implementation
Guidelines - Usage rules STEP2 Usage Rules and Validation Rules
2.103 CdtTrfTxInf
+RmtInf
++Strd
+++CdtrRefInf
++++Ref
35x
**CW**
O AT-05 • If a Creditor Reference contains a check digit, the receiving bank is not required to validate this.
• If the receiving bank validates the check digit and if this validation fails, the bank may continue its processing and send the transaction to the next party in the chain
• RF Creditor Reference may be used (ISO 11649)
Creditor Reference Information Reference.
• When used both ‘Type’ and ‘Reference’ must be present (schema validation).
2.104 CdtTrfTxInf
+RmtInf
++Strd
+++Invcr
See Schema
O AT-05 Invoicer.
2.105 CdtTrfTxInf
+RmtInf
++Strd
+++Invcee
See Schema
O AT-05 Invoicee.
2.106 CdtTrfTxInf
+RmtInf
++Strd
+++AddtlRmtInf
140x
**CW**
O AT-05 Additional Remittance Information.
Table 4-11 SCT Credit Transfer (pacs.008) Individual Transaction
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 61 of 154
C.2 STEP2 usage of camt.056 (Payment Cancellation Request)
This transaction can be present in the ICF and SCF files.
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
AT-04 Mandatory • Only ‘EUR’ is allowed. • Amount must be 0.01 or more
and 999999999.99 or less. • The fractional part has a
maximum of two digits.
The original Interbank Settlement Amount.
• The Currency attribute must be “EUR”: (schema validation);
• The number of digits following the decimal point in Interbank Settlement Amount must not exceed the maximum number allowed for the EUR currency (schema validation); and
• Must be the same as the Interbank Settlement Amount for the original credit transfer transaction (pacs.008) as stored in the STEP2 CS: error code XT77.
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 64 of 154
Index XML Acronym Format Status Rulebook
Ref
EPC SCT Implementation
Guidelines – Usage Rules STEP2 Validation Rules
4.38 Undrlyg +TxInf ++OrgnlIntrBkSttlmDt
ISO DATE
M AT-42 Mandatory The original Interbank Settlement Date.
• Must be the same date as the date of the original credit transfer transaction (pacs.008) in the CS repository. Error code XT74.
The party originating the request for cancellation (bank).
• Cannot be used at the same time as Originator/Name (see above) (schema validation).
4.44 Undrlyg +TxInf ++CxlRsnInf +++Rsn ++++Cd
4!a C AT-48 The Payment Cancellation Request Reason Code (ISO20022 code).
• Must be used with a valid code (schema validation); and
• Cannot be used at the same time as Prtry (see below) (schema validation).
4.45 Undrlyg +TxInf ++CxlRsnInf +++Rsn ++++Prtry
35x
** CW **
C AT-48 The Request for Cancellation Reason Code.
• Cannot be used at the same time as Code (see above) (schema validation).
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 65 of 154
Index XML Acronym Format Status Rulebook
Ref
EPC SCT Implementation
Guidelines – Usage Rules STEP2 Validation Rules
4.47 Undrlyg +TxInf ++OrgnlTxRef
M Mandatory
(an exact copy of all attributes of the initially sent DS-02 which is to be cancelled)
The message elements under ‘Original Transaction Reference’ must be populated with the same value as the message elements of the original instruction as defined within the following elements.
C.3.2 SCT Resolution of Investigation (camt.029) Individual Transaction Information
Multiple occurrences of Transaction Information can be used. No matching is performed towards the original CT (pacs.008) or the Payment Cancellation Request (camt.056). Index XML Acronym Format Status Rulebook
Ref
EPC SCT Implementation
Guidelines – Usage Rules Validation Rules
4.72 CxlDtls +TxInfAndSts
See below
M See below Mandatory Transaction Information and Status.
• At least one transaction must be present (schema validation).
4.73 CxlDtls +TxInfAndSts ++CxlStsId
35x M NA The Cancellation Identification.
• Uniqueness is checked under the rules for duplicate checking. Error code AM05; and
• This identification cannot include leading, trailing or internal spaces (schema validation).
4.81 CxlDtls
+TxInfAndSts
++OrgnlGrpInf
+++OrgnlMsgId
35x M NA The Message Identifier of the original bulk.
• For ICF the Message Identifier is the one generated by STEP2 CS for the Original CT bulk in the original SCF; and
• For SCF, the Message Identifier is the Original Message Identifier of the original bulk received from the bank.
4.82 CxlDtls
+TxInfAndSts
++OrgnlGrpInf
+++OrgnlMsgNmId
35x M NA Only ‘pacs.008.001.02’ is allowed. The type of XML message bulk to be cancelled.
• Must always equal to pacs.008* (use of wildcard in validation) (schema validation).
4.84 CxlDtls
+TxInfAndSts
++OrgnlInstrId
35x O NA The Original instruction Identifier of the pacs 008.
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 75 of 154
Index XML Acronym Format Status Rulebook
Ref
EPC SCT Implementation
Guidelines – Usage Rules Validation Rules
4.85 CxlDtls
+TxInfAndSts
++OrgnlEndToEndId
35x
** CW **
M AT-41 Mandatory The Original End to End Identifier of the pacs 008.
4.86 CxlDtls
+TxInfAndSts
++OrgnlTxId
35x M AT-43 Mandatory
The Original Transaction Identifier of the pacs 008.
4.88 CxlDtls
+TxInfAndSts
++TxCxlSts
4!a M NA Only ‘RJCR’ is allowed Transaction Cancellation Status. • Only the value “RJCR” is allowed (schema validation).
The party originating the Resolution of Investigation (bank).
• Cannot be used at the same time as Originator/Name (above) (schema validation).
4.92 CxlDtls
+TxInfAndSts
++CxlStsRsnInf +++Rsn ++++Cd
4!a C AT-R6 Mandatory The Resolution of Investigation Reason Code.
• Must be used with a valid code (schema validation);
• Only ISO Codes can be used in this field : LEGL and CUST (schema validation); other values should be used with the “Prtry” field below;
• Cannot be used at the same time as Prtry (below) (schema validation).
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 76 of 154
Index XML Acronym Format Status Rulebook
Ref
EPC SCT Implementation
Guidelines – Usage Rules Validation Rules
4.93 CxlDtls
+TxInfAndSts
++CxlStsRsnInf +++Rsn ++++Prtry
35x
** CW **
C AT-R6 The Resolution of Investigation Reason Code Proprietary.
• Cannot be used at the same time as Code (above) (schema validation).
4.94 CxlDtls
+TxInfAndSts
++CxlStsRsnInf +++AddtlInf
105x
** CW **
C NA • To be used only when code is ‘LEGL’ in order to precise the reason.
• Only two occurrences are allowed
The Resolution of Investigation Additional Information.
• To be used only when Reason Code is ‘LEGL’ in order to specify the reason. Error code XT13.; and
• Only two occurrences are allowed (schema validation).
4.101 CxlDtls
+TxInfAndSts
++Assgnr +++Agt ++++FinInstnId +++++BIC
4!a2!a2!c C NA The DP originating this assignment.
• Only used in SCF. Error code XT13.
4.107 CxlDtls
+TxInfAndSts
++OrgnlTxRef
See Schema
M NA Mandatory
(an exact copy of all attributes of the initially sent DS-02 which is to be cancelled)
The yellow shaded message elements under ‘Original Transaction Reference’ must be populated with the same value as the message elements of the original instruction as defined within the following elements.
This is a Payment Status sent by STEP2 to inform a bank of rejected Credit Transfer, Return, Payment Cancellation Request or Resolution of Investigation. The Payment Status is also used in optional file PCF to notify CT Instructing Agent of the status of a CT object of a Recall Procedure.
C.4.1 SCT Reject (pacs.002S2) in CVF,CCF and PCF Bulk Header
XML Element Format Status STEP2 Usage Rules
GrpHdr +MsgId
35x M The STEP2 CS bulk reference.
GrpHdr +CreDtTm
ISODate &Time
M The date & Time in which this bulk was created by the STEP2 CS.
GrpHdr +InstgAgt ++FinInstnId +++BIC
4!a2!a2!c[3!c]
C The Instructing Agent BIC (Instructing Agent of the original transaction).
• Not used in CVF; and • Present in CCF and PCF.
Table 4-16 SCT Reject (pacs.002S2) in CVF, CCF and PCF Bulk Header
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 86 of 154
C.4.2 SCT Reject (pacs.002S2) in CVF,CCF and PCF - Original Group Information And Status
XML Element Format Status STEP2 Usage Rules OrgnlGrpInfAndSts +OrgnlMsgId
35x M The Message Id of the original bulk
OrgnlGrpInfAndSts +OrgnlMsgNmId
35x M The type of XML message to be rejected. CVF: pacs.008, pacs.004, camt.056, camt.029; and CCF: pacs.008, pacs.004. PCF: pacs.008
OrgnlGrpInfAndSts +OrgnlNbOfTxs
15n M The total number of transactions received within the original bulk.
OrgnlGrpInfAndSts +OrgnlCtrlSum
18d M CVF: The total amount received within the original bulk. CCF and PCF: The total amount of valid transactions received within the original bulk and cancelled at settlement
OrgnlGrpInfAndSts +GrpSts
4!a M The status of the original bulk; values allowed are: • CVF: “ACCP”= accepted, “PART” = partially accepted or “RJCT” = rejected; and • CCF: “RJCT”= cancelled by Settlement Mechanism or “PART” = partially settled. • PCF: always set to “PART”
4!a C The indication of the error code of the bulk. Code is defined as per ISO20022.
• Cannot be used with Rsn Prtry (see below). • Not used in PCF files
OrgnlGrpInfAndSts +StsRsnInf ++Rsn +++Prtry
35x C The indication of the error code of the bulk. Code is STEP2 Specific (proprietary).
• Cannot be used with Rsn Code (see above); • If Group Status is Accepted: B00; • If Group Status is Partially Accepted: B01; and • If Group Status is Rejected: contains bulk rejection reason code.
For PCF files the value is always set to “PCR”
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 87 of 154
XML Element Format Status STEP2 Usage Rules OrgnlGrpInfAndSts +NbOfTxsPerSts ++DtldNbOfTxs
15n C The number of transactions per this status in the bulk.
• Status = Accepted for CVF and CCF – Cancelled for PCF • Present if Group Status is PART.
OrgnlGrpInfAndSts +NbOfTxsPerSts ++DtldSts
4!a C The status of the transactions (Accepted).
• Status = “ACCP” for CVF and CCF – “RJCT” for PCF
• Present if Group Status is PART. OrgnlGrpInfAndSts +NbOfTxsPerSts ++DtldCtrlSum
18d C The Value of the transactions per this status (Accepted) in the bulk.
• Status = Accepted for CVF and CCF – Cancelled for PCF
• Present if Group Status is PART. OrgnlGrpInfAndSts +NbOfTxsPerSts ++DtldNbOfTxs
15n C The number of transactions per this status in the bulk.
• Status = Rejected for CVF and CCF – Recalled for PCF
• Present if Group Status is PART. OrgnlGrpInfAndSts +NbOfTxsPerSts ++DtldSts
4!a C The status of the transactions (Rejected).
• Status = “RJCT” for CVF and CCF – “PDNG” for PCF • Present if Group Status is PART.
OrgnlGrpInfAndSts +NbOfTxsPerSts ++DtldCtrlSum
18d C The Value of the transactions per this status (Rejected) in the bulk.
• Status = Rejected for CVF and CCF – Recalled for PCF • Present if Group Status is PART.
Table 4-17 SCT Reject (pacs.002S2) in CVF, CCF and PCF - Original Group Information And Status
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 88 of 154
C.4.3 SCT Reject (pacs.002S2) in CVF,CCF and PCF – Individual Transaction
This part of the message is only present if there are any transactions rejected inside the bulk as described below or in the case of PCF files. XML Acronym Format Status STEP2 Usage Rules TxInfAndSts +StsId
35x M The Status Report Message Identification (generated by the Central System).
TxInfAndSts +OrgnlInstrId
35x O The Instruction ID of the original CT; populated only if it was present in the original CT.
TxInfAndSts +OrgnlEndToEndId
35x M The End to End Id of the original CT.
TxInfAndSts +OrgnlTxId
35x M The Id of the original transaction (Id is specific to the original message type).
TxInfAndSts +TxSts
4!a M The status of this transaction.
• The only value allowed for CVF and CCF is: “RJCT”= rejected. • The values for PCF file are:
o “RJCT” if StsRsnInf/Rsn/Prtry below is set to “CANC” o “PDNG” if StsRsnInf/Rsn/Prtry below is set to “RCLL”
4!a C The indication of the error code for the transaction (ISO20022 codes).
• For CCF: ED05 is the value allowed for cancellation at settlement; and • Cannot be used at the same time as Proprietary (see below).
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 89 of 154
XML Acronym Format Status STEP2 Usage Rules TxInfAndSts +StsRsnInf ++Rsn +++Prtry
35x C For CVF and CCF files: The indication of the error code for the transaction (STEP2 specific). If the error code is XT13 or XT33, this Prtry will be formatted as follows: [CODE][1 blank character][Offending XML tag] Where: CODE: XT13 or XT33 Offending XML tag: Cannot be used at the same time as Code (see above). For PCF Files:
• “CANC” = the PCR was processed before the settlement of the original Credit Transfer. The original CT was not settled.
• “RCLL” = the PCR was processed after the settlement of the original Credit Transfer. The CT has been settled/cancelled and the Recall Request was forwarded to the Beneficiary Bank of the original CT.
TxInfAndSts +InstdAgt ++FinInstnId +++BIC
4!a2!a2!c[3!c] C The Instructed Agent BIC (Instructed Agent obtained from the original transaction).
The Amount of the original transaction. Depending on the type of the original message, this can either be:
• Credit Transfer: Interbank Settlement Amount; • Return: Returned Interbank Settlement Amount; and • Payment Cancellation Request: Interbank Settlement Amount of the original
transaction. • Resolution of Investigation: the field will be set to zero
TxInfAndSts +OrgnlTxRef ++IntrBkSttlmDt
ISODate M The Original Interbank Settlement Date.
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 90 of 154
XML Acronym Format Status STEP2 Usage Rules TxInfAndSts +OrgnlTxRef ++DbtrAgt +++FinInstnId ++++BIC
Each ICF message must be sent within the configured time period for type of message. No matching is performed towards the original CT (pacs.008). Index XML Element Format Status Rulebook
Ref STEP2 Usage Rules and Validation
3.1 TxInf +RtrId
35x M AT-R5 (Return)
Mandatory The Return Identification
• Uniqueness is checked under the rules for duplicate checking: error code AM05; and
• This identification cannot include leading, trailing or internal spaces. (schema validation)
3.3 TxInf +OrgnlGrpInf ++OrgnlMsgId
35x M NA The Message ID of the bulk containing the original CT. In the case of ICF, the Original Message Id is the one generated by the CS for the Original CT bulk in the original SCF. In case of the SCF, the Original Message Id is the one generated by DP for the Original Return bulk in the original ICF containing the Returns.
• This identification cannot include leading, trailing or internal spaces (schema validation).
3.4 TxInf +OrgnlGrpInf ++OrgnlMsgNmId
35x M NA The type of XML message bulk to be Returned.
• For SCT Service: must always equal to pacs.008* (use of wildcard in schema validation).
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 94 of 154
Index XML Element Format Status Rulebook
Ref
STEP2 Usage Rules and Validation
3.6 TxInf +OrgnlInstrId
35x O NA Mandatory if provided in the original instruction.
The Instruction ID of the original CT; populated only if it was present in the original DD.
• This identification cannot include leading, trailing or internal spaces. (schema validation).
3.7 TxInf +OrgnlEndToEndId
35x ** CW **
M AT-41 Mandatory The original End to End Id.
3.8 TxInf +OrgnlTxId
35x M AT-43 Mandatory Must contain a reference that is meaningful to the Originator’s Bank and is unique over time.
The original Transaction Id.
• This identification cannot include leading, trailing or internal spaces. (schema validation)
3.10 TxInf +OrgnlIntrBkSttlmAmt Attribute
18d
3!a
M
AT-04 Mandatory • Amount must be 0.01 or more and
999999999.99 or less. • The fractional part has maximum
of two digits.
The original Interbank Settlement Amount.
• The Currency attribute must be “EUR” (schema validation) and;
• The number of digits following the decimal point in Interbank Settlement Amount must not exceed the maximum number allowed for the EUR currency. (schema validation).
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 95 of 154
Index XML Element Format Status Rulebook
Ref
STEP2 Usage Rules and Validation
3.11 TxInf +RtrdIntrBkSttlmAmt Attribute
18d
3!a
M M
AT-04 (Return)
Or AT-46 (Recall)
• If the return message is a positive answer to a Recall (ie, if ‘Code’ under ‘Return Reason Information’ specifies ‘FOCR’), the amount must be equal to the ‘Original Interbank Settlement Amount’ less the ‘Amount’ under ‘Charges Information’.
• If the return message is not a positive answer to a Recall (ie, if ‘Code’ under
• ‘Return Reason Information’ is different from ‘FOCR’), the Amount must be the same as in ‘Original Interbank Settlement Amount’.
• 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).
. • 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
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 96 of 154
Index XML Element Format Status Rulebook
Ref
STEP2 Usage Rules and Validation
3.13 TxInf +RtrdInstdAmt Attribute
18d
3!a
C NA • Only allowed in the case of a return in response to a cancellation request, ie, ‘Reason’ in ‘Return Reason Information’ specifies ‘FOCR’.
• 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;
• The Currency attribute must be “EUR” (schema validation);
3.15 TxInf +CompstnAmt
18d
3!a
O M
NA The Returned Compensation amount of the returned transaction.
• The Currency attribute must be “EUR” (schema validation); and
• The number of digits following the decimal point in Compensation Amount must not exceed the maximum number allowed for the EUR currency (schema validation).
3.16 TxInf +ChrgBr
4!a O NA The Charge Bearer Information.
• Only the value SLEV is allowed (schema validation).
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 97 of 154
Index XML Element Format Status Rulebook
Ref
STEP2 Usage Rules and Validation
3.18 TxInf +ChrgsInf ++Amt Attribute
18d
3!a
C AT-47 • Only allowed in case of a return in response to a cancellation request, ie, ‘Reason’ in ‘Return Reason Information’ specifies ‘FOCR’.
• Only one occurrence is allowed.
The Charges Amount.
• Only one occurrence is allowed (schema validation);
• Amount must be 0.01 or more: error code AM01;
• The number of digits following the decimal point in Charges Amount must not exceed the maximum number allowed for the EUR currency (schema validation);and
• Only allowed in case of a return in response to a cancellation request, .i.e. ‘Reason’ in ‘Return Reason Information’ specifies ‘FOCR’: error code XT33.
3.19 TxInf +ChrgsInf ++Pty +++FinInstnId ++++BIC
4!a2!a2!c[3!c]
O AT-23 Only BIC is allowed. The Charges Party (BIC).
• Only one occurrence is allowed (schema validation).
3.20 TxInf +InstgAgt ++FinInstnId +++BIC
4!a2!a2!c C NA Only BIC is allowed. The DP originating this Return.
• Must be present in the SCF only: error code XT13.
3.23 TxInf +RtrRsnInf ++Orgtr +++Nm
70x
** CW **
C AT-R2 • ‘Name’ is limited to 70 characters in length.
The Customer originating this transaction.
• Cannot be used at the same time as Originator/BIC (see below) (schema validation).
• 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 TxInf
+OrgnlTxRef
++PmtTpInf
+++CtgyPurp
++++Cd
4x
** CW **
C 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 **
C 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).
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 100 of 154
Index XML Element Format Status Rulebook
Ref
STEP2 Usage Rules and Validation
3.84 TxInf +OrgnlTxRef ++RmtInf +++Ustrd
140x
** CW **
C AT-05 Unstructured Remittance Information.
• Either Unstructured or Structured Remittance Information can be used (schema validation);
• Maximum of 10 occurrences of this field. (schema validation);
• First occurrence is yellow and optional; and
• Subsequent occurrences are white and reserved for future use. Error code: XT81.
3.84 TxInf +OrgnlTxRef ++RmtInf +++Strd
140x C AT-05 Structured Remittance Information.
• Either Unstructured or Structured Remittance Information can be used (schema validation);
• Maximum of 10 occurrences of this field (schema validation);
• First occurrence is yellow and optional; • Subsequent occurrences are white and
reserved for future use. Error code: 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.
The STEP2 service identifier (e.g. SCT) associated with the network address (from the Request Type network parameter) must be one of the configured services.
The sending address must be present in the STEP2 Central System addressing table for the specified STEP2 service identifier.
The CS cannot generate a CVF because:
• It is not possible to associate a destination network address to which to send the file.
Resolution must involve a phone call from Customer Support and manual management.
If the number of rejected transactions is equal to 0, then the file is completely accepted.
The CS generates a CVF as follows:
• The ICF is totally accepted;
The reported FileRjctRsn at the level of ICF is:
• A00: the ICF is totally accepted.
If the number of rejected transactions is different from 0, and there are some transaction accepted then the file is partially accepted.
The CS generates a CVF as follows:
• The ICF is partially accepted;
The FileRjctRsn equals:
• A01: the file is partially accepted.
The file has been sent during non-Target days.
The CS generates a CVF as follows:
• 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.
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 109 of 154
Processing Error report
The FileRjctRsn is:
• R01: the ICF has been received during non-Target days.
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 110 of 154
Processing Error report
The network file name is compared against the valid naming convention being accepted.
This check is divided into several checks:
• The network file name must begin with the fixed value according to the naming convention;
• The Service Identifier contained in the network file name must be equal to the one associated with the network address;
• The DP BIC contained in the network file name must be equal to the one associated with the network address (as derived from the STEP2 Central System addressing table);
• The format version contained in the network file name is checked against the legal values; and
•
The 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.
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 111 of 154
Processing Error report
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 CS generates a CVF as follows:
• The ICF is totally rejected;
• The CVF will not contain any rejected transaction;
The FileRjctRsn is:
• R08: Unable to process input file.
The parser will validate the received file against the ICF XML schema.
If the file does not comply with the schema then it is rejected as garbage.
The CS generates a CVF as follows:
• 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:
• R10: ICF does not comply with schema; the file cannot be processed.
The following fields are compared against the record of accepted files held online:
• ServiceId;
• SngInst;
• FileReference.
If a match is found for these fields between the file being validated and a file held online then the file is rejected as a duplicate.
The CS generates a CVF as follows:
• 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 FileRjctRsn is:
• R13: the ICF is a duplicate.
The contents of the ICF header fields are checked against the configured set of legal values.
• SndgInst must equal the BIC associated with the network address;
• RcvgInst must equal the configured STEP2 central system BIC; and
• TstCode must equal the configured
The 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.
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 112 of 154
Processing Error report
system value.
If any check fails then the file is rejected.
• R14: incorrect TstCode.
The format (syntax and character set) and presence of those file- and header-level elements not verified by schema validation is checked.
Specifically, it is verified that:
• The format of SndgInst must be 4!a2!a2!c (e.g. must not contain a branch code);
• The format of RcvgInst must be 4!a2!a2!c (e.g. must not contain a branch code)
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:
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 113 of 154
Processing Error report
NumRETBlk.
If the numbers are different then the file is rejected.
• 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
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 114 of 154
D.2 Bulks Naming & Structure Validation Process
Error /Reason Code Processing Error report
B00: the bulk is totally accepted. After the bulk content validation completion, the number of rejected transactions is checked.
If the number of rejected transaction is equal to 0 and the number of accepted transaction is greater than 0, then the bulk is totally accepted.
The 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.
B01: the bulk is partially accepted. After the bulk content validation completion, the number of rejected transactions is checked.
If the number of rejected transaction is greater than 0 and the number of accepted transaction is greater than 0, then the bulk is partially accepted.
The CS generates a 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.
B02: the maximum number of
transactions within one bulk is exceeded.
NbOfTxs is compared against the maximum number of transactions supported in one bulk.
If there is a greater number of transactions in the file than are supported then the file is rejected.
The 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
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 115 of 154
Error /Reason Code Processing Error report
B03: the number of transactions within the bulk does not match the
value declared in the GrpHdr
The transactions within the bulk are counted and the total is compared against NbOfTxs/NbOfTxsPerSts.
If the numbers are different then the bulk is rejected.
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 NA NA
B05: TtlIntrBkSttlmAmt or TtlRtrdIntrBkSttlmAmt do not
match the sum of the transactions amounts inside the bulk.
After the completion of pacs.008, or pacs.004 content validation, the number of processed transactions and the number of transactions with a valid "Interbank Settled Amount" or “Returned Settlement amount” are checked.
If these numbers are equal, then the sum of the “Interbank Settled Amount” or ”Returned Settlement amount” from every transaction is verified against TtlIntrBkSttlmAmt or TtlRtrdIntrBkSttlmAmt. If the calculated sum is different from that indicated in the bulk this is rejected.
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 NA NA
B07: Not used NA NA
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 116 of 154
Error /Reason Code Processing Error report
B08: the maximum number of bulks in a single file has been
exceeded.
If the maximum have already been accepted then this bulk is rejected.
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
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:
• The bulk is totally rejected
• The CVF contains all rejected transactions
• All the transactions have been validated
• All the transactions have succeeded the validation of the Interbank Settled Amount
• OrgnlNbOfTxs and OrgnlCtrlSum will contain the values from the original pacs008 bulk
• The StsRsnInf Prtry field will contain the error code.
B10: the bulk is totally rejected because Instructing Agent must
equal the sending institution element must not contain a branch
code and must be present at the group header level.
Instructing Agent must be present at the group header level in an ICF and have the format 4!a2!a2!c (e.g. must not contain a branch code).
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
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.
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
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 117 of 154
Error /Reason Code Processing Error report
B12: the bulk is totally rejected because Assgnr/Assgne does not
have the correct value
Assgnr/Assgne does not have the correct value
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
B13: the bulk is totally rejected because TtlIntrBkSttlmAmt is zero
TtlIntrBkSttlmAmt must be greater than zero.
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
B14: the bulk is totally rejected
because MsgId is duplicated.
The Message Id must be unique 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
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 118 of 154
Error /Reason Code Processing Error report
B15: the bulk is totally rejected because IntrBkSttlmDt is not in the
allowed range.
IntrBkSttlmDt must be present at the bulk level and must be within the allowed range. (see Business Function Document)
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
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:
• 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
B17: Not used NA NA
B18: Not used NA NA
B19: Not used NA. NA
B20: Not used NA NA
B21: Not Used NA NA
B22: Not Used NA NA
B23: the bulk is totally rejected because too much consecutive rejected transactions
The number of consecutive rejected transactions found at the beginning of the bulk must not exceed the CS parameter "maximum number of errors in the bulk"
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.
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
The CS generates a CVF as follows:
• The bulk is totally rejected
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 119 of 154
Error /Reason Code Processing Error report
transaction present in the body of the bulk.
• 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
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 120 of 154
APPENDIX E TRANSACTION ERROR CODES
Where possible, ISO codes are used (refer to ISO definitions). In cases where no ISO code exists, the following STEP2 proprietary error codes are used in the Proprietary field of the message.
Reason
Code
Names Error Description
PY01 Unknown BIC (Routing Table) • The transaction cannot be processed because the Agent bank is unknown to the STEP2 central system.
XD19 Invalid IBAN format • An IBAN in the transaction has failed the ISO 13616 check.
XT13 Unsupported XML field • The transaction contains at least one unsupported field for this file;
The offending XML tag is present with the error code (if available).
XT33 Invalid Data Format • The content of at least one XML element is not in the required format.
The offending XML tag is present with the error code.
XT73 Invalid Country Code • The two characters for country code are not a valid SWIFT country code.
XT74 Invalid Original Transaction Status
• Invalid original transaction status for R-message received, action required.
XT75 Invalid Original Transaction Status
• Invalid original transaction status for R-message received, action not required.
XT77 Original Amount Mismatch • The amount of the original transaction does not match with the amount in the R-message
XT81 XML field not permitted in CT service
� A XML field present in the XML schemas but not permitted in the CT service was used.
XT85 No Settlement Cycle available � No settlement cycle available in the current business date for both Debtor and Creditor Agents.
� For optional settlement cycles, the Debtor Agent is not an Indirect Participant of the Instructing Agent
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 121 of 154
APPENDIX F REPORT FILE DETAILS
F.1 CRR Cycle Settlement Report
F.1.1 CRR Header
Status Field Name Format Value Position
M Record Type 4x “HCRR” 0
M Service Identifier 3!a “SCT” 4
M File Type 3x "CRR" 7
M Sending Institution 4!a2!a2!c EBAPFRPP 10
M Sender’s File Reference 16!c 18
M Date And Time* 6!n6!n 34
M Test Code 1x "P" / "T" 46
M Receiving Institution 4!a2!a2!c 47
M Settlement Cycle 2n 55
M Interbank Settlement Date 6n 57
M Total Settlement Amount Debit Party Settled
18d 63
M Total Settlement Amount Debit Party Cancelled
18d 81
M Total Settlement Amount Credit Party Settled
18d 99
M Total Settlement Amount Credit Party Cancelled
18d 117
M Total Number Records 6n 135
Table 4-22 CRR Header
*CET (CEST in the summer).
Table 4-23 CRR Debit Party
F.1.2 CRR Debit Party
The CRR Debit Party contains one record for each settlement instruction sent by the STEP2 central system during the processing of the value date to which this CRR relates (if no settlement instructions were sent then no records will be present) where the direct participant receiving this CRR is the debit party. The contents of the fields in each such record are as follows:
Status Field Name Format Value Position
M Record Type 4x "CDBB" 0
M Instruction Reference 16x 4
M Credit Party DP BIC 4!a2!a2!c 20
M Credit Party Settlement BIC 4!a2!a2!c3!c 28
M Value of CTRs Settled 18d 39
M Value of Returns Settled 18d 57
M Value of CTRs Cancelled 18d 75
M Value of Returns Cancelled 18d 93
M Total Amount Settled 18d 111
M Total Amount Cancelled 18d 129
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 122 of 154
Field Name Contents
Credit Party DP BIC The BIC of the direct participant who was the credit party of these transactions.
Credit Party Settlement BIC The BIC used by the direct participant identified in Credit Party Settlement BIC.
Value of CTRs settled The value of the CTRs settled in this cycle.
Value of Returns settled The value of the Returns settled this cycle.
Value of CTRs cancelled The value of the CTRs cancelled in this cycle.
Value of Returns cancelled The value of the Returns cancelled this cycle.
Total Amount Settled The amount of settled transactions included in this body.
Total Amount Cancelled The amount of cancelled transactions included in this body.
Table 4-24 CRR Debit Party – field contents
Status Field Name Format Value Position
M Record Type 4x "CDBT” 0
Table 4-25 CRR Debit Party trailer
F.1.3 CRR Credit Party
Status Field Name Format Value Position
M Record Type 4x "CCRB" 0
M Instruction Reference 16x 4
M Debit Party DP BIC 4!a2!a2!c 20
M Debit Party Settlement BIC 4!a2!a2!c[3!c] 28
M Value of CTRs 18d 39
M Value of Returns 18d 57
M Total Settlement Amount 18d 75
M Settlement Result 4x 93
Table 4-26 CRR Credit Party
The CRR Credit Party contains one record for each settlement instruction sent by the STEP2 central system during the processing of the value date to which this CRR relates (if no settlement instructions were sent then no records will be present) where the direct participant receiving this CRR was the credit party. The contents of the fields in each such record are as follows:
Field Name Contents
Settlement Reference The unique STEP2 generated reference for this settlement instruction.
Debit Party DP BIC The BIC of the direct participant who was the debit party of this settlement instruction.
Debit Party Settlement BIC The BIC used by the direct participant identified in Debit Party Settlement BIC.
Value of CTRs The value of the CTRs included in this body.
Value of Returns The value of the Returns included in this body.
Total Settlement Amount The amount of the settlement instruction included in this body.
Settlement Result The result of processing of this settlement instruction, e.g.:
“PROC”, indicating that the settlement instruction was successfully processed, or “CANC”, indicating that the settlement instruction was cancelled.
Table 4-27 CRR Credit Party – field contents
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 123 of 154
Status Field Name Format Value Position
M Record Type 4x "CCRT” 0
Table 4-28 CRR Credit Party trailer
Status Field Name Format Value Position
M Record Type 4x "TCRR” 0
Table 4-29 CRR trailer
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 124 of 154
F.2 Daily Reconciliation Report (DRR)
F.2.1 DRR header
Status Field Name Format Value Position
M Record Type 4x “HDRR” 0
M Service Identifier 3!a SCT 4
M File Type 3x "DRR" 7
M Sending Institution 4!a2!a2!c 10
M Sender’s File Reference 16!c 18
M Date And Time* 6!n6!n 34
M Test Code 1x "P" / "T" 46
M Receiving Institution 4!a2!a2!c 47
M Interbank settlement Date 6!n 55
M Total Number Records 6n 61
Table 4-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 Field Name Format Value Position
M Record Type 4x "DFTH" 0 M Number Files Sent 4n 4 M Number Files Rejected 4n 8 M Number Bulks Sent 4n 12 M Number Bulks Rejected 4n 16 M Number Bulks CRT Sent 4n 20 M Number Bulks CRT Rejected 4n 24 M Number Bulks RET Sent 4n 28 M Number Bulks RET Rejected 4n 32 M Number Bulks PCR Sent 4n 36 M Number Bulks PCR Rejected 4n 40 M Number Bulks ROI Sent 4n 44 M Number Bulks ROI Rejected 4n 48 M Number Credit Transfers Sent 10n 52 M Number Credit Transfers Rejected 10n 62 M Number Credit Transfers Held 10n 72 M Number Credit Transfers Cancelled 10n 82 M Number Credit Transfers Settled 10n 92 M Number Returns Sent 10n 102 M Number Returns Rejected 10n 112 M Number Returns Held 10n 122 M Number Returns Cancelled 10n 132 M Number Returns Settled 10n 142 M Number PCR Sent 10n 152 M Number PCR Rejected 10n 162 M Number ROI Sent 10n 172
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 125 of 154
Status Field Name Format Value Position
M Number ROI Rejected 10n 182 M Value Credit Transfers Sent 18d 192 M Value Credit Transfers Rejected 18d 210 M Value Credit Transfers Held 18d 228 M Value Credit Transfers Cancelled 18d 246 M Value Credit Transfers Settled 18d 264 M Value Returns Sent 18d 282 M Value Returns Rejected 18d 300 M Value Returns Held 18d 318 M Value Returns Cancelled 18d 336 M Value Returns Settled 18d 354 M Value PCR Sent 18d 372 M Value PCR Rejected 18d 390
Table 4-31 DRR files/bulks/transactions sent header
Each DRR contains one and only one DRR files/bulks/transactions sent header record. The contents of the fields in this record are as follows:
Field Name Contents
Number Files Sent The number of times an ICF was received by the STEP2 central system from this direct participant.
Rejected files that are re-sent (with the same or a different SFR) are counted once for each time they are received by the STEP2 central system.
Number Files Rejected The number of CVFs indicating complete rejection of a file that were transmitted by the STEP2 central system to this direct participant.
ICFs for which the STEP2 central system transmits an CVF with the codes different from A00 and A01 in the File Reject Reason of the CVF header.
Number Bulks Sent The total number of bulks received by the STEP2 central system from this direct participant.
Rejected bulks that are re-sent (with the same or a different reference) are counted once for each time they are received by the STEP2 central system.
Number Bulks Rejected The number of the bulks completely rejected by the STEP2 central system to this direct participant.
Number CTRs Bulks Sent The total number of CTRs bulks received by the STEP2 central system from this direct participant.
Number CTRs Bulks Rejected The number of CTRs bulks completely rejected by the STEP2 central system to this direct participant.
Number Return Bulks Sent The total number of Return bulks received by the STEP2 central system from this direct participant.
Number Return Bulks Rejected
The number of Return bulks completely rejected by the STEP2 central system to this direct participant.
Number PCR Bulks Sent The total number of PCR bulks received by the STEP2 central system from this direct participant.
Number PCR Bulks Rejected The number of PCR bulks completely rejected by the STEP2 central system to this direct participant.
Number ROI Bulks Sent The total number of ROI bulks received by the STEP2 central system from this direct participant.
Number ROI Bulks Rejected The number of ROI bulks completely rejected by the STEP2 central system to this direct participant.
Number Credit Transfers Sent The number of Credit Transfers instructions received in bulks from this direct participant by the STEP2 central system where the bulk was completely or partially accepted.
Bulks for which the STEP2 central system transmits an CVF bulk with the following codes in the File Reject Reason of the CVF bulk header are included
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 126 of 154
Field Name Contents
in this field: B00 and B01 (there will be Number Bulk Sent – Number bulks Rejected such files).
The contents of this field will equal:
• The sum of the Total Number Of Transactions fields from each partially or completely accepted bulk, and
• The sum of the following DRR Files Sent Header fields, below:
Number Credit Transfers Rejected,
Number Credit Transfers Held,
Number Credit Transfers Cancelled, and
Number Credit Transfers Settled.
Number Credit Transfers Rejected
The number of Credit Transfers that were rejected from partially accepted bulks received from this direct participant.
Bulks for which the STEP2 central system transmits an CVF bulk with the following codes in the Reason code of the CVF bulk are included in this field: B01. The contents of this field will equal the sum of the contents of the Total Number Rejected fields from each such CVF bulk.
Number Credit Transfers Held The number of Credit Transfers from this direct participant accepted for processing by the STEP2 central system but that have been held in the external settlement mechanism (for future use; currently this will always contain zero).
Number Credit Transfers Cancelled
The number of Credit Transfers that were accepted from this direct participant that have been cancelled by the external settlement mechanism and transmitted by the STEP2 central system to this direct participant in a CCF. The contents of this field will equal the sum of the Total Number Cancelled fields from each such CCF.
Number Credit Transfers Settled
The number of Credit Transfers that were accepted from this direct participant that have been processed by the external settlement mechanism and transmitted by the STEP2 central system to the relevant receiving direct participants in SCFs.
Number Returns Sent The number of Returns instructions received in bulks from this direct participant by the STEP2 central system where the bulk was completely or partially accepted.
Bulks for which the STEP2 central system transmits an CVF bulk with the following codes in the File Reject Reason of the CVF bulk header are included in this field: B00 and B01 (there will be Number Bulk Sent – Number bulks Rejected such files).
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 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).
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 127 of 154
Field Name Contents
Number Returns Cancelled The number of Returns that were accepted from this direct participant that have been cancelled by the external settlement mechanism and transmitted by the STEP2 central system to this direct participant in a CCF. The contents of this field will equal the sum of the Total Number Cancelled fields from each such CCF.
Number Returns Settled The number of Returns that were accepted from this direct participant that have been processed by the external settlement mechanism and transmitted by the STEP2 central system to the relevant receiving direct participants in SCFs.
Number PCR Sent The number of PCR instructions received in bulks from this direct participant by the STEP2 central system where the bulk was completely or partially accepted.
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 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:
• 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.
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.
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 128 of 154
Field Name Contents
Value Credit Transfers Sent The value of the Credit Transfers included in the Number Credit Transfers Rejected field of this DRR Files Sent Header.
The 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 Transfers Rejected
The value of the payments included in the Number Credit Transfers Rejected field of this DRR Files Sent Header. The contents of this field will equal the sum of the contents of the Total Value Credit Transfers Rejected fields from the bulk header of each CVF specified in Number Credit Transfers Rejected.
Value Credit Transfers Held The value of the payments included in the Number Credit Transfers Held field of this DRR Files Sent Header.
Value Credit Transfers Cancelled
The value of the payments included in the Number Credit Transfers Cancelled field of this DRR Files Sent Header.
The contents of this field will equal the sum of the Total Value Credit Transfers Cancelled fields from the header of each CCF transmitted to the direct participant.
Value Credit Transfers Settled The value of the payments included in the Number Credit Transfers Settled field of this DRR Files Sent Header.
Value Returns Sent The value of the Returns included in the Number Returns Rejected field of this DRR Files Sent Header.
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.
Value Returns Held The value of the payments included in the Number Returns Held field of this DRR Files Sent Header.
Value Returns Cancelled The value of the payments included in the Number Returns Cancelled field of this DRR Files Sent Header.
The contents of this field will equal the sum of the Total Value Returns Cancelled fields from the header of each CCF transmitted to the direct participant.
Value Returns Settled The value of the payments included in the Number Returns Settled field of this DRR Files Sent Header.
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 129 of 154
Field Name Contents
Value PCR Sent The value of the PCRs included in the Number RFCs Rejected field of this DRR Files Sent Header.
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 Format Value Position
M Record Type 4x "DTSB" 0 M Bulk Reference 35x 4 M Number Credit Transfers Sent 8n 39 M Number Credit Transfers
Rejected 8n
47 M Number Credit Transfers Held 8n 55 M Number Credit Transfers
Cancelled 8n
63 M Number Credit Transfers
Settled 8n
71 M Value Credit Transfers Sent 18d 79 M Value Credit Transfers
Rejected 18d
97 M Value Credit Transfers Held 18d 115 M Value Credit Transfers
Cancelled 18d
133 M Value Credit Transfers Settled 18d 151 M Process Cycle nr 2n 169
Table 4-33 DRR Credit Transfer bulks sent body
The DRR Credit Transfer bulks sent body contains one record for each Credit Transfer bulk that was totally or partially accepted by the STEP2 central system from the direct participant receiving the DRR during the processing of the interbank settlement date to which the DRR relates (if no bulks were sent or all bulks sent were totally rejected then no records will be present). The contents of the fields in each such record are as follows:
Field Name Contents
Bulk Reference The reference of the bulk for which the information in this record relates.
Number Credit Transfers Sent The number of Credit Transfers received by the STEP2 central system in this bulk.
The contents of this field will equal the contents of the Total Number Of Transactions field in the header of this bulk.
Number Credit Transfers Rejected
The number of Credit Transfers from this bulk that were rejected by the STEP2 central system.
A CVF containing these Credit Transfers will have been transmitted to the direct participant and the contents of this field will equal the contents of the Total Number Rejected field in the header of that CVF.
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 130 of 154
Field Name Contents
Number Credit Transfers Held The number of Credit Transfers from this bulk that were accepted for processing by the STEP2 central system but are now held in the external settlement mechanism.
Number Credit Transfers Cancelled
The number of Credit Transfers from this bulk that were accepted by the STEP2 central system but subsequently cancelled by the external settlement mechanism.
A CCF containing these Credit Transfers will have been transmitted to the direct participant and the contents of this field will equal the contents of the Total Number Cancelled field in the header of that CCF Credit Transfers bulk.
Number Credit Transfers Settled
The number of Credit Transfers that were accepted from this bulk, successfully processed by the external settlement mechanism, and transmitted to the relevant receiving direct participants in SCFs bulks.
Value Credit Transfers Sent The value of the Credit Transfers received by the STEP2 central system in this bulk.
The contents of this field will equal the contents of the Sum Of Amounts field in the header of this bulk.
Value Credit Transfers Rejected
The value of the Credit Transfers from this bulk that were rejected by the STEP2 central system.
A CVF containing these payment instructions will have been transmitted to the direct participant and the contents of this field will equal the contents of the Total Value Rejected field in the header of that CVF bulk.
Value Credit Transfers Held The value of the Credit Transfers from this bulk that were accepted for processing by the STEP2 central system but are now held in the external settlement mechanism.
Value Credit Transfers Cancelled
The value of the Credit Transfers from this bulk that were accepted for processing by the STEP2 central system but subsequently cancelled by the external settlement mechanism.
A CCF containing these Credit Transfers will have been transmitted to the direct participant and the contents of this field will equal the contents of the Total Value Cancelled Credit Transfers bulk field in the header of that CCF bulk.
Value Credit Transfers Settled The value of the Credit Transfers from this bulk that were accepted for processing by the STEP2 central system and settled by the external settlement mechanism.
Process Cycle nr The process cycle in which this bulk was processed by STEP2 CS.
Table 4-34 DRR Credit Transfer bulks sent body – field contents
Status Field Name Format Value Position
M Record Type 4x "DRSB" 0 M Bulk Reference 35x 4 M Number Returns Sent 8n 39 M Number Returns Rejected 8n 47 M Number Returns Held 8n 55 M Number Returns Cancelled 8n 63 M Number Returns Settled 8n 71 M Value Returns Sent 18d 79 M Value Returns Rejected 18d 97 M Value Returns Held 18d 115 M Value Returns Cancelled 18d 133 M Value Returns Settled 18d 151 M Process Cycle nr 2n 169
Table 4-35 DRR Return bulks sent body
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 131 of 154
The DRR Return bulks sent body contains one record for each return bulk that was totally or partially accepted by the STEP2 central system from the direct participant receiving the DRR during the processing of the interbank settlement date to which the DRR relates (if no bulks were sent or all bulks sent were totally rejected then no records will be present). The contents of the fields in each such record are as follows:
Field Name Contents
Bulk Reference The reference of the bulk for which the information in this record relates.
Number Returns Sent 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.
Number Returns Cancelled The number of Returns from this bulk that were accepted by the STEP2 central system but subsequently cancelled by the external settlement mechanism.
A CCF containing these Returns will have been transmitted to the direct participant and the contents of this field will equal the contents of the Total Number Cancelled return bulk field in the header of that CCF.
Number Returns Settled The number of Returns that were accepted from this bulk, successfully processed by the external settlement mechanism, and transmitted to the relevant receiving direct participants in SCFs.
Value Returns Sent The value of the Returns received by the STEP2 central system in this bulk.
The contents of this field will equal the contents of the transaction Amounts field in the header of this bulk.
Value Returns Rejected The value of the Returns from this bulk that were rejected by the STEP2 central system.
A CVF containing these payment instructions will have been transmitted to the direct participant and the contents of this field will equal the contents of the Total Value Rejected field in the header of that CVF.
Value Returns Held The value of the Returns from this bulk that were accepted for processing by the STEP2 central system but are now held in the external settlement mechanism.
Value Returns Cancelled The value of the Returns from this bulk that were accepted for processing by the STEP2 central system but subsequently cancelled by the external settlement mechanism.
A CCF containing these Returns will have been transmitted to the direct participant and the contents of this field will equal the contents of the Total Value Cancelled return bulk field.
Value Returns Settled The value of the Returns from this bulk that were accepted for processing by the STEP2 central system and settled by the external settlement mechanism.
Process Cycle nr The process cycle in which this bulk was processed by STEP2 CS.
Table 4-36 DRR Return bulks sent body – field contents
Status Field Name Format Value Position
M Record Type 4x "DCSB" 0 M Bulk Reference 35x 4 M Number PCRs Sent 8n 39
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 132 of 154
Status Field Name Format Value Position
M Number PCRs Rejected 8n 47 M Value PCRs Sent 18d 55 M Value PCRs Rejected 18d 73 M Process Cycle nr 2n 91
Table 4-37 DRR PCR bulks sent body
The DRR PCR bulks sent body contains one record for each PCR bulk that was totally or partially accepted by the STEP2 central system from the direct participant receiving the DRR during the processing of the interbank settlement date to which the DRR relates (if no bulks were sent or all bulks sent were totally rejected then no records will be present). The contents of the fields in each such record are as follows:
Field Name Contents
Bulk Reference The reference of the bulk for which the information in this record relates.
Number PCRs Sent 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
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 133 of 154
Status Field Name Format Value Position
M Record Type 4x "DRIB" 0 M Bulk Reference 35x 4 M Number ROIs Sent 8n 39 M Number ROIs Rejected 8n 47 M Process Cycle nr 2n 55
Table 4-39 DRR ROI bulks sent body
The DRR ROI bulks sent body contains one record for each Resolution of Investigation bulk that was totally or partially accepted by the STEP2 central system from the direct participant receiving the DRR during the processing of the interbank settlement date to which the DRR relates (if no bulks were sent or all bulks sent were totally rejected then no records will be present). The contents of the fields in each such record are as follows:
Field Name Contents
Bulk Reference The reference of the bulk for which the information in this record relates.
Number ROIs Sent 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 Field Name Format Value Position
M Record Type 4x "DFTT” 0
Table 4-41 DRR files/bulks/transactions sent trailer
DRR bulks received
Status Field Name Format Value Position
M Record Type 4x "DBRH" 0 M Number bulks Received 4n 4 M Value bulks Received 18d 8 M Number Credit Transfers
Direct 10n
26 M Number Credit Transfers
Indirect 10n
36 M Number Returns 10n 46 M Number PCR 10n 56 M Number ROI 10n 66 M Value Credit Transfers
Direct 18d
76 M Value Credit Transfers
Indirect 18d
94 M Value Returns 18d 112 M Value PCR 18d 130
Table 4-42 DRR bulks received header
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 134 of 154
Each DRR contains one and only one DRR bulks received header record. The contents of the fields in this record are as follows:
Field Name Contents
Number Bulks Received The number of bulks in SCFs generated by the STEP2 central system for this direct participant during the processing of this interbank settlement date.
Value Bulks Received The sum of the Total Value Settled fields from the header of each SCF generated for this direct participant during the processing of this interbank settlement date.
Number Credit Transfers Direct
The number of Credit Transfers in SCFs generated by the STEP2 central system for this direct participant during the processing of this interbank settlement date where this direct participant is receiving the payment instructions as the beneficiary bank.
Number Credit Transfers Indirect
The number of payment instructions in SCFs generated by the STEP2 central system for this direct participant during the processing of this interbank settlement date where this direct participant is receiving the payment instructions on behalf of an indirect participant as the beneficiary bank.
Number Returns The number of returns in SCFs generated by the STEP2 central system for this direct participant during the processing of this interbank settlement date where this direct participant is receiving the returns.
Number PCR The number of Payment Cancellation Requests in SCFs generated by the STEP2 central system for this direct participant during the processing of this interbank settlement date where this direct participant is receiving the PCR.
Number ROI The number of Resolution of Investigation in SCFs generated by the STEP2 central system for this direct participant during the processing of this interbank settlement date where this direct participant is receiving the ROI.
Value Credit Transfers Direct The value of the payment instructions in identified Number Credit Transfers Direct, above.
Value Credit Transfers Indirect
The value of the payment instructions in identified Number Credit Transfers Indirect, above.
Value Returns The value of the Returns in identified Number Returns, above.
Value PCR The value of the Payment Cancellation Requests in identified Number PCR, above.
Table 4-43 DRR bulks received header – field contents
Status Field Name Format Value Position
M Record Type 4x "DTRB" 0
M Bulk Reference 35x 4 M Number Credit Transfers
Direct 8n
39 M Number Credit Transfers
Indirect 8n
47 M Value Credit Transfers
Direct 18d 55
M Value Credit Transfers Indirect
18d 73
M Settlement Cycle nr 2n 91
Table 4-44 DRR Credit Transfer bulks received body
The DRR Credit Transfer bulks received body contains one record for each SCF Credit Transfer bulk that was sent to the direct participant receiving the DRR by the STEP2 central system during the processing of the interbank settlement date to which the DRR relates (if no SCFs were sent then no records will be present). The contents of the fields in each such record are as follows:
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 135 of 154
Field Name Contents
Bulk Reference The bulk reference of the SCF Credit Transfer bulk to which these statistics relate.
Credit Transfers Direct The number of Credit Transfers in this SCF Credit Transfer bulk where this direct participant is receiving the payment instructions as the beneficiary bank.
Number Credit Transfers Indirect
The number of Credit Transfers in this SCF Credit Transfer bulk where this direct participant is receiving the payment instructions on behalf of an indirect participant as the beneficiary bank.
Value Credit Transfers Direct The value of the Credit Transfers identified in Number Credit Transfers Direct, above.
Value Credit Transfers Indirect
The value of the Credit Transfers identified in Number Credit Transfers Indirect, above.
Settlement Cycle nr The settlement cycle in which this bulk was processed by STEP2 CS.
Table 4-45 DRR Credit Transfer bulks received body – field contents
Status Field Name Format Value Position
M Record Type 4x "DRRB" 0
M Bulk Reference 35x 4 M Number Returns 8n 39 M Value Returns 18d 47 M Settlement Cycle nr 2n 65
Table 4-46 DRR Return bulks received body
The DRR bulks received body contains one record for each SCF that was sent to the direct participant receiving the DRR by the STEP2 central system during the processing of the interbank settlement date to which the DRR relates (if no SCFs were sent then no records will be present). The contents of the fields in each such record are as follows:
Field Name Contents
Bulk Reference The bulk reference of the SCF bulk to which these statistics relate.
Number Returns The number of Returns in this SCF bulk where this direct participant is receiving the payment instructions as returned.
Value Returns The value of the Returns identified in Number Returns, above.
Settlement Cycle nr The settlement cycle in which this bulk was processed by STEP2 CS.
Table 4-47 DRR Return bulks received body – field contents
Status Field Name Format Value Position
M Record Type 4x "DRCB" 0
M Bulk Reference 35x 4 M Number PCR 8n 39 M Value PCR 18d 47
Table 4-48 DRR PCR bulks received body
The DRR PCR bulks received body contains one record for each SCF that was sent to the direct participant receiving the DRR by the STEP2 central system during the processing of the interbank settlement date to which the DRR relates (if no SCFs were sent then no records will be present). The contents of the fields in each such record are as follows:
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 136 of 154
Field Name Contents
Bulk Reference The bulk reference of the SCF bulk to which these statistics relate.
Number PCR The number of Payment Cancellation Requests in this SCF bulk where this direct participant is receiving the PCR.
Value PCR The value of the Payment Cancellation Requests identified in Number PCR, above.
Table 4-49 DRR PCR bulks received body – field contents
Status Field Name Format Value Position
M Record Type 4x "DROB" 0
M Bulk Reference 35x 4 M Number ROI 8n 39
Table 4-50 DRR ROI bulks received body
The DRR ROI bulks received body contains one record for each SCF that was sent to the direct participant receiving the DRR by the STEP2 central system during the processing of the interbank settlement date to which the DRR relates (if no SCFs were sent then no records will be present). The contents of the fields in each such record are as follows:
Field Name Contents
Bulk Reference The bulk reference of the SCF bulk to which these statistics relate.
Number ROI The number of Resolution of Investigation in this SCF bulk where this direct participant is receiving the ROI.
Table 4-51 DRR ROI bulks received body – field contents
Status Field Name Format Value Position
M Record Type 4x "DBRT” 0
Table 4-52 DRR bulks received trailer
F.2.3 DRR settlement transactions sent
Status Field Name Format Value Position
M Record Type 4x "DDBH" 0
M Number Debit Instructions 6n 4
M Number Debit Instructions Cancelled
6n 10
M Value Debit Instructions 18d 16
M Value Debit Instructions Cancelled
18d 34
Table 4-53 DRR settlement transactions sent header
Each DRR contains one and only one DRR settlement transactions sent header record. The contents of the fields in this record are as follows:
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 137 of 154
Field Name Contents
Number Debit Instructions The number of settlement instructions sent to the external settlement mechanism by the STEP2 central system during the processing of the interbank settlement date to which this DRR refers where the direct participant receiving this DRR was the debit party. The DRR settlement payments sent body will contain one record for each such settlement instruction.
Number Debit Instruct Cancelled
The number of settlement instructions identified in Number Debit Instruct, above, that were cancelled by the external settlement mechanism.
Value Debit Instruct The value of the settlement instructions identified in Number Debit Instruct, above.
Value Debit Instruct Cancelled The value of the settlement instructions identified in Number Debit Instruct Cancelled, above.
Table 4-54 DRR settlement payments sent header – field contents
Status Field Name Format Value Position
M Record Type 4x "DDBB" 0
M Settlement Reference 16x 4
M Interbank settlement Date 6!n 20
M Credit Party DP BIC 4!a2!a2!c 26
M Credit Party Settlement BIC 4!a2!a2!c[3!c] 34
M Settlement Amount 18d 45
M Settlement Result 4x 63
M Settlement Cycle nr 2n 67
Table 4-55 DRR transactions sent body
The DRR settlement transactions sent body contains one record for each settlement instruction sent by the STEP2 central system during the processing of the interbank settlement date to which this DRR relates (if no settlement instructions were sent then no records will be present) where the direct participant receiving this DRR was the debit party. The contents of the fields in each such record are as follows:
Field Name Contents
Settlement Reference The unique STEP2 generated reference for this settlement instruction.
Settlement Cycle The STEP2 cycle during which this instruction was transmitted for settlement.
Interbank settlement date The interbank settlement date during which this instruction was sent for settlement.
Credit Party DP BIC The BIC of the direct participant who was the credit party of this settlement instruction.
Credit Party Settlement BIC The BIC used by the direct participant identified in Credit Party Settlement BIC above.
Settlement Amount The amount of this settlement instruction.
Settlement Result The result of processing this settlement instruction, e.g.:
“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 Field Name Format Value Position
M Record Type 4x "DDBT” 0
Table 4-57 DRR settlement transactions sent trailer
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 138 of 154
F.2.4 DRR settlement transactions received
Status Field Name Format Value Position
M Record Type 4x "DCRH" 0
M Number Credit Instruct 6n 4
M Number Credit Instruct Cancelled
6n 10
M Value Credit Instruct 18d 16
M Value Credit Instruct Cancelled
18d 34
Table 4-58 DRR settlement payments received header
Each DRR contains one and only one DRR settlement transactions received header record. The contents of the fields in this record are as follows:
Field Name Contents
Number Credit Instructions The number of settlement instructions sent by the STEP2 central system during the processing of the interbank settlement date to which this DRR refers where the direct participant receiving this DRR was the credit party. The DRR settlement payments received body will contain one record for each such settlement instruction.
Number Credit Instruct Cancelled
The number of settlement instructions identified in Number Credit Instruct, above, cancelled by the external settlement mechanism.
Value Credit Instruct The value of the settlement instructions identified in Number Credit Instruct, above.
Value Credit Instruct Cancelled
The value of the settlement instructions identified in Number Credit Instruct Cancelled, above.
Table 4-59 DRR settlement transactions received header – field contents
Status Field Name Format Value Position
M Record Type 4x "DCRB" 0
M Settlement Reference 16x 4
M Interbank settlement Date 6!n 20
M Debit Party DP BIC 4!a2!a2!c 26
M Debit Party Settlement BIC 4!a2!a2!c[3!c] 34
M Settlement Amount 18d 45
M Settlement Result 4x 63
M Settlement Cycle nr 2n 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:
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 139 of 154
Field Name Contents
Settlement Reference The unique STEP2 generated reference for this settlement instruction.
Settlement Cycle The STEP2 cycle during which this instruction was transmitted for settlement.
Interbank settlement Date The interbank settlement date during which this instruction was sent for settlement
Debit Party DP BIC The BIC of the direct participant who was the debit party of this settlement instruction.
Debit Party Settlement BIC The BIC used by the direct participant identified in Debit Party Settlement BIC.
Settlement Amount The amount of this settlement instruction.
Settlement Result The result of processing of this settlement instruction, e.g.:
“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 Field Name Format Value Position
M Record Type 4x "DCRT” 0
Table 4-62 DRR settlement transactions received trailer
F.2.5 DRR trailer
Status Field Name Format Value Position
M Record Type 4x "TDRR” 0
Table 4-63 DRR trailer
F.2.6 DRR Record table index
Definition Trailer Record
HDRR DRR Header TDRR
DFTH DRR File/Bulk/Transaction sent DFTT
DTSB DRR Credit Transfer bulks sent body
DRSB DRR Return bulks sent body
DCSB DRR Payment Cancellation Request bulk sent body
DRIB DRR Resolution of Investigation bulk sent body
DBRH DRR bulks received header DBRT
DTRB DRR Credit Transfer bulks received body
DRRB DRR Return bulks received body
DRCB DRR Payment Cancellation Request received body
DROB DRR Resolution of Investigation received body
DDBH DRR Settlement transactions sent header DDBT
DDBB DRR Settlement transactions sent body
DCRH DRR Settlement transactions received header DCRT
DCRB DRR Settlement transactions received body
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 140 of 154
F.3 Monthly Statistics Report (MSR)
The monthly statistics report gives direct participants detailed information with which they can:
� Calculate and justify the fees from counterparties for STEP2 services rendered to the counterparty by the direct participant; and � Reconcile the fees being requested by counterparties for STEP2 services delivered by the counterparty to the direct participant. There are two categories of STEP2 service for which the monthly statistics report gives assistance. These are:
� Payments sent; and � Payments received.
F.3.1 MSR header
Status Field Name Format Value Position
M Record Type 4x “HMSR” 0
M Service Identifier 3!a SCT 4
M File Type 3x "MSR" 7
M Sending Institution 4!a2!a2!c 10
M Sender’s File Reference 16!c 18
M Date And Time* 6!n6!n 34
M Test Code 1x "P" / "T" 46
M Receiving Institution 4!a2!a2!c 47
M Reference Date% 6!n 55
M Total Number Records 6n 61
Table 4-64 MSR header
* CET (CEST in the summer). % Reference Date is in YYMMDD format.
F.3.2 MSR body: statistics on transactions sent
Status Field Name Format Value Position
M Record Type 4x "MTSH" 0 M Number Credit Transfers Sent 12n 4 M Number Credit Transfers Rejected 12n 16 M Number Credit Transfers Cancelled 12n 28 M Number Credit Transfers Settled 12n 40 M Number Returns Sent 12n 52 M Number Returns Rejected 12n 64 M Number Returns Cancelled 12n 76 M Number Returns Settled 12n 88 M Number PCRs Sent 12n 100 M Number PCRs Rejected 12n 112 M Number ROIs Sent 12n 124 M Number ROIs Rejected 12n 136 M Value Credit Transfers Sent 18d 148 M Value Credit Transfers Rejected 18d 166 M Value Credit Transfers Cancelled 18d 184 M Value Credit Transfers Settled 18d 202
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 141 of 154
Status Field Name Format Value Position
M Value Returns Sent 18d 220 M Value Returns Rejected 18d 238 M Value Returns Cancelled 18d 256 M Value Returns Settled 18d 274 M Value PCR Sent 18d 292 M Value PCR Rejected 18d 310
Table 4-65 MSR transactions sent header
Status Field Name Format Value Position
M Record Type 4x "MCTB" 0 M Receiving Participant 4!a2!a2!c 4 M Number Credit Transfers
Accepted 12n 12
M Number Credit Transfers Cancelled
12n 24
M Number Credit Transfers Settled
12n 36
M Value Credit Transfers Accepted
18d 48
M Value Credit Transfers Cancelled
18d 66
M Value Credit Transfers Settled 18d 84
Table 4-66 MSR Credit Transfers sent body
Status Field Name Format Value Position
M Record Type 4x "MRTB" 0 M Receiving Participant 4!a2!a2!c 4 M Number Returns Accepted 12n 12 M Number Returns Cancelled 12n 24 M Number Returns Settled 12n 36 M Value Returns Accepted 18d 48 M Value Returns Cancelled 18d 66 M Value Returns Settled 18d 84
Table 4-67 MSR Returns sent body
Status Field Name Format Value Position
M Record Type 4x "MRCB" 0 M Receiving Participant 4!a2!a2!c 4 M Number PCRs Accepted 12n 12 M Value PCRs Accepted 18d 24
Table 4-68 MSR PCRs sent body
Status Field Name Format Value Position
M Record Type 4x "MRIB" 0 M Receiving Participant 4!a2!a2!c 4 M Number ROIs Accepted 12n 12
Table 4-69 MSR ROIs sent body
Status Field Name Format Value Position
M Record Type 4x "MTXT” 0
Table 4-70 MSR transactions sent trailer
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 142 of 154
F.3.3 MSR body: statistics on transactions received
Status Field Name Format Value Position
M Record Type 4x "MTRH" 0
M Number Credit Transfers Received
12n 4
M Number Returns Received 12n 16
M Value Credit Transfers Received
18d 28
M Value Returns Received 18d 46
Table 4-71 MSR transactions received header
Status Field Name Format Value Position
M Record Type 4x "MCRB" 0
M Sending Participant 4!a2!a2!c 4
M Number Credit Transfers Received
12n 12
M Value Credit Transfers Received
18d 24
Table 4-72 MSR Credit Transfers received body
Status Field Name Format Value Position
M Record Type 4x "MRRB" 0
M Sending Participant 4!a2!a2!c 4
M Number Returns Received 12n 12
M Value Returns Received 18d 24
Table 4-73 MSR Returns received body
Status Field Name Format Value Position
M Record Type 4x "MPRB" 0
M Sending Participant 4!a2!a2!c 4
M Number PCR Received 12n 12
M Value PCR Received 18d 24
Table 4-74 MSR PCR received body
Status Field Name Format Value Position
M Record Type 4x "MIRB" 0
M Sending Participant 4!a2!a2!c 4
M Number ROI Received 12n 12
Table 4-75 MSR ROI received body
Status Field Name Format Value Position
M Record Type 4x "MTRT” 0
Table 4-76 MSR transactions received trailer
STEP2 SEPA Credit Transfer Service
21/11/2011 Interface Specification
Version 20111121 (RB5.0) 143 of 154
F.3.4 MSR trailer
Status Field Name Format Value Position
M Record Type 4x "TMSR” 0
Table 4-77 MSR trailer
F.3.5 MSR Record table index
Definition Trailer Record
HMSR MSR Header TMSR
MTSH MSR transactions sent header MTXT
MCTB MSR Credit Transfer sent body
MRTB MSR Return sent body
MRCB MSR Payment Cancellation Request sent body
MRIB MSR Resolution of Investigation sent body
MTRH MSR transactions received header MTRT
MCRB MSR Credit Transfer received body
MRRB MSR Returns received body
MPRB MSR Payment Cancellation Request received body
MIRB MSR Resolution of Investigation received body
21/11/2011
STEP2 SCT
Interface Specifications
Version 20111121 (RB5.0) 144 of 154
APPENDIX G INTERFACES TO SUPPORTED NETWORKS
Information regarding the Network Configuration can be found in the “STEP2 Technical Configuration” document. (Ref. [18]).
21/11/2011
STEP2 SCT
Interface Specifications
Version 20111121 (RB5.0) 145 of 154
APPENDIX H SCT ROUTING TABLE
H.1 The STEP2 SCT Routing Table
The Routing Table is available in two different parts: one for Direct Participants and one for Indirect Participants. It can be downloaded directly from the Central System through the use of the Direct Participant Web Station (DPWS).
H.2 How to read the table
Each entry is one line in either the Direct or Indirect Participant table. By default, all of the entries with a future End date will be present. For entries without an End Date, the default value is 31/12/9999. A user can specify some search criteria to list entries according to specific conditions. The search criteria refer to the options available on the DPWS to display the elements specified by the operator. The “DATE FROM” condition will return all of the entries in the table with Init Date greater than or equal to the inserted value. The “DATE TO” condition will return all of the entries in the table with End Date less than or equal to the inserted value. BIC, NAME and STATUS are self-explanatory.
H.3 Status used in the Routing Table
ENABLED status
The Participant is active in the system and can send and receive transactions as long as they meet the following conditions:
- have a settlement date equal or greater than the Init Date - have a settlement date equal or before the End Date - are within the conditions of payment warehousing.
SUSPENDED status
The Participant is in suspended mode and can no longer send or receive any transaction. Warehoused payments from or to this Participant will still be sent to the settlement mechanism on the settlement date. Suspended is a temporary status used for emergency conditions.
21/11/2011
STEP2 SCT
Interface Specifications
Version 20111121 (RB5.0) 146 of 154
DISABLED status
The Participant is in disabled mode and can no longer send or receive any transaction. This status is automatically given to entry with past DATE TO field.
H.4 Payment Type Allowed
This three letters code is used in the case of pre-defined AOS service usage. The identifier is used to check if the sending and receiving bank is part of the AOS service and thus process the transaction accordingly. Note that a blank Payment Type allowed is used for the default SEPA SCT core service. The following values will be inserted in the “Payment Type Allowed” field for both Direct and Indirect Participant Routing Table in order to specify the adherence of the participant to a specific AOS. BIC Routing Table RTF File
Acc. Date
Rem. Info
ITA Trasf.
Payment Type allowed Physical Representation (HX)
BIC A N N N 1 space char 09 20 09
BIC B Y N N AO1 09 41 4F 31 09
BIC C N Y N AO2 09 41 4F 32 09
BIC D Y Y N AO1 AO2 09 41 4F 31 09 41 4F 32 09
BIC E Y Y Y AO1 AO2 AO3 09 41 4F 31 09 41 4F 32 09 41 4F 33 09
H.5 The Routing Table File (FileAct upload)
The RTF sent to Direct Participant via FileAct follows the exact same layout as the one described in the following sections for the Routing Table available through the DPWS. However, the file format is a tab-separated values file and not an Excel file as for the one obtained through the DPWS.
21/11/2011
STEP2 SCT
Interface Specifications
Version 20111121 (RB5.0) 147 of 154
H.6 SCT Direct Participant Routing Table
H.6.1 Header row
Field name Format Size Description
File Title Text 32x SCT DIRECT PARTICIPANT ROUTING TABLE
H.6.2 Search Criteria header row 1
Field name Format Size Description
Row name Text 15x SEARCH CRITERIA
H.6.3 Search Criteria header row 2
Field name Format Size Description
Header 2 col. A Text 3x BIC
Header 2 col. B Text 4x NAME
Header 2 col. C Text 9x DATE FROM
Header 2 col. D Text 7x DATE TO
Header 2 col. F Text 6x STATUS
Header 2 col. G Text 16x MATCHING RECORDS
H.6.4 Search criteria
Field name Format Size Description
BIC BIC (8) 8x BIC used in search criteria
Name None 50x Bank Name used in search criteria
Date From YYYYMMDD 6x Date From used in search criteria
Date To YYYYMMDD 6x Date To used in search criteria
Status Text 9x Status used in search criteria
Matching Records Integer 4n Number of records returned in search
H.6.5 Results header row 1
Field name Format Size Description
Row name Text 7 RESULTS
21/11/2011
STEP2 SCT
Interface Specifications
Version 20111121 (RB5.0) 148 of 154
H.6.6 Results header row 2
Field name Format Size Description
Header 2 col. A Text 6 BIC
Header 2 col. B Text 7 NAME
Header 2 col. C Text 9 INIT DATE
Header 2 col. D Text 8 END DATE
Header 2 col. F Text 17 SETTLEMENT BIC
Header 2 col. H Text 6 STATUS
Header 2, col. I Text 20 PAYMENT TYPE ALLOWED
H.6.7 Results row
Field name Format Size Description
DP BIC AN BIC (8) BIC(8) format.
DP Name Text 50x Bank name. Free format.
Init Date Date YYYYMMDD Date from which BIC is valid.
End date Date YYYYMMDD Date up to which BIC is valid
Settlement BIC Text BIC (11) The BIC used for settlement of the IP data.
Status Text 9x ENABLED, SUSPENDED, DISABLED
Payment Type Allowed Text See (H.4) A 3-character code indicating the product(s) available to this participant. See (H.4)
The Payment Type Allowed column may repeat up to 10- times for each successive product that the BIC may use. Format is 3 alphanumeric, e.g. A01,A02,A03 etc
21/11/2011
STEP2 SCT
Interface Specifications
Version 20111121 (RB5.0) 149 of 154
H.7 SCT Indirect Participant Routing Table
H.7.1 Header row
Field name Format Size Description
File Title Text 34x SCT INDIRECT PARTICIPANT ROUTING TABLE
H.7.2 Search Criteria header row 1
Field name Format Size Description
Row name Text 15x SEARCH CRITERIA
H.7.3 Search Criteria header row 2
Field name Format Size Description
Header 2 col. A Text 6x IP BIC
Header 2 col. B Text 7x IP NAME
Header 2 col. C Text 9x DATE FROM
Header 2 col. D Text 7x DATE TO
Header 2 col. E Text 6x DP BIC
Header 2 col. F Text 6x STATUS
Header 2 col. G Text 16x MATCHING RECORDS
H.7.4 Search Criteria results
Field name Format Size Description
IP BIC AN BIC (11) BIC(11) format. Ending in XXX is permissible.
IP Name Text 50x Bank name. Free format.
Date From Date YYYYMMDD Date from which BIC is valid.
Date To Date YYYYMMDD Date up to which BIC is valid
DP BIC AN BIC (11) The BIC of the associated Direct Participant.
Status Text 9x ENABLED, SUSPENDED, DISABLED
Matching Rows Integer 4n No. of Search Results rows returned
21/11/2011
STEP2 SCT
Interface Specifications
Version 20111121 (RB5.0) 150 of 154
H.7.5 Results header row 1
Field name Format Size Description
Row name Text 7x RESULTS
H.7.6 Results header row 2
Field name Format Size Description
Header 2 col. A Text 6x IP BIC
Header 2 col. B Text 7x IP NAME
Header 2 col. C Text 9x INIT DATE
Header 2 col. D Text 8x END DATE
Header 2 col. E Text 6x DP BIC
Header 2 col. F Text 17x DP SETTLEMENT BIC
Header 2 col. H Text 6x STATUS
Header 2 col. I Text 20x PAYMENT TYPE ALLOWED
H.7.7 Results row
Field name Format Size Description
IP BIC AN 11x BIC(11) format. Ending in XXX is permissible.
IP Name Text 50x Bank name. Free format.
Init Date Date YYYYMMDD Date from which BIC is valid.
End date Date YYYYMMDD Date up to which BIC is valid
DP BIC AN BIC (8) The BIC of the associated Direct Participant.
DP Settlement BIC Text BIC (11) The BIC used for settlement of the IP data.
Status Text 9x ENABLED, DISABLED
Payment Type Allowed Text See (H.4) A 3-character code indicating the product(s) available to this participant. See (H.4)
The Payment Type Allowed column may repeat up to 10 times for each successive product that the BIC may use. Format is 3 alphanumeric, e.g. A01,A02,A03 etc
21/11/2011
STEP2 SCT
Interface Specifications
Version 20111121 (RB5.0) 151 of 154
APPENDIX I ERROR CODE REFERENCE LIST
I.1 File Level Codes
File error codes are always used in the CVF header as part of the File Reject Reason (FileRjctRsn) field.
Code Description
A00 ICF totally accepted
A01 ICF partially accepted
R01 ICF received on non-Target day
R02 Network file name not compliant
R03 Unknown Service identifier
R04 Direct Participant BIC mismatch (network address)
R06 Invalid file name format
R07 Invalid file extension
R08 Unable to process input file
R09 Decompression failed
R10 Schema validation failed
R11 Invalid Sending Institution
R12 Invalid Receiving Institution
R13 Duplicate ICF
R14 Invalid Test Code
R15 Invalid Sending Institution BIC format
R16 Invalid Receiving Institution BIC format.
R18 Credit Transfer bulk number mismatch
R19 Payment Cancellation Request bulk number mismatch
R20 Returns bulk number mismatch
R21 Resolution of Investigation bulk number mismatch
R23 All bulks rejected
R24 Maximum number of ICF received
21/11/2011
STEP2 SCT
Interface Specifications
Version 20111121 (RB5.0) 152 of 154
I.2 Bulk Error codes
Bulk error codes are always used in the group header of a message as part of either the Code or Proprietary field.
Code Description Type Pacs002S2
B00 Bulk totally accepted PRTRY X
B01 Bulk partially accepted PRTRY X
B02 Maximum number of transactions in a bulk exceeded
PRTRY X
B03 Number of transactions mismatch PRTRY X
B05 Total amount mismatch PRTRY X
B07 Control Sum mismatch PRTRY X
B08 Maximum number of bulks in a file exceeded
PRTRY X
B09 All transactions rejected PRTRY X
B10 Instructing Agent mismatch PRTRY X
B11 Invalid use of Instructed Agent PRTRY X
B12 Invalid Use of Assgnr/Assgne PRTRY X
B13 Zero Settlement Amount PRTRY X
B14 Duplicate MessageID PRTRY X
B15 Invalid Settlement Date PRTRY X
B16 Invalid Settlement Info details PRTRY X
B23 Too many consecutive rejected transactions
PRTRY X
B24 Invalid use of bulk transaction PRTRY X
ED05 Settlement Failed PRTRY X
XT81 Only SEPA core fields are allowed PRTRY X
21/11/2011
STEP2 SCT
Interface Specifications
Version 20111121 (RB5.0) 153 of 154
I.3 Transaction level Error Codes
Transaction error codes are always used at the transaction level as part of either Code or Proprietary field.
Code Description Type
Pacs004
Camt029
Camt056
Pacs002S2
CUST Requested By Customer ISO X
LEGL Legal Decision ISO X
DUPL Duplicate Payment ISO X
TECH Technical Problem PRTRY X
FRAD Fraudulent Original Credit Transfer PRTRY X
AC01 Incorrect Account Number ISO X
AC04 Closed Account Number ISO X
AC04 Closed Account Number PRTRY X
AC06 Blocked Account ISO X
AG01 Transaction Forbidden ISO X
AG02 Invalid Bank Operation Code ISO X
AM01 Zero Amount ISO X
AM02 Not Allowed Amount ISO X
AM04 Insufficient Funds PRTRY X
NOAS No Answer from Customer PRTRY X
NOOR No Original Transaction Received PRTRY X
AM05 Duplication ISO X X
DT01 Invalid Date ISO X
BE04 Missing Creditor Address ISO X
ED05 Settlement Failed ISO X
FOCR Following Cancellation Request ISO X
MD07 End Customer Deceased ISO X
MS02 Not Specified Reason Customer Generated
ISO X
MS03 Not Specified Reason Agent Generated ISO X
RC01 Bank Identifier Incorrect ISO X
21/11/2011
STEP2 SCT
Interface Specifications
Version 20111121 (RB5.0) 154 of 154
Code Description Type
Pacs004
Camt029
Camt056
Pacs002S2
RR01 Not Specified Reason Customer Generated
ISO X
RR02
Missing Debtor Name or Address - Code used by banks to indicate a Return for Regulatory Reason
ISO X
RR03
Missing Creditor Name or Address - Code used by banks to indicate a Return for Regulatory Reason
ISO X
RR04 Regulatory Reason ISO X
ARDT Already Returned Transaction PRTRY X
PY01 Unknown BIC in routing table PRTRY X
XD19 Invalid IBAN format PRTRY X
XT13 Unsupported XML field PRTRY X
XT33 Invalid data format PRTRY X
XT73 Invalid country code PRTRY X
XT74 Invalid original transaction status, action required
PRTRY X
XT75 Invalid original transaction status, action not required
PRTRY X
XT77 Original Amount mismatch PRTRY X
XT81 Only SEPA core fields are allowed PRTRY X
XT85 Invalid Settlement Cycle PRTRY X
CANC Used in PCF file
The PCR was processed before the settlement of the original Credit Transfer. The original CT was not settled.
PRTRY X
RCLL the PCR was processed after the settlement of the original Credit Transfer. The CT has been settled/cancelled and the Recall Request was forwarded to the Beneficiary Bank of the original CT.