Documentation for a newer release is available. View Latest

Request Processing

The SEPA CT STEP2 CSM Service exposes the Clear And Settle API and Recalls, Returns ROI API. Requests made through these interfaces instruct the CSM Service to carry out required validations at both bulk and transaction level, map the messages to appropriate versions of ISO20022 messages, perform schema check and submit the individual transactions for bulking so they can be added to the files to be sent to the scheme.

Debtor Credit Transfer/Return (pacs.008 and pacs.004)

The following responses are provided:

A Technical acknowledgement of submission of bulk message from the client implementation flows (+ve Ack)
IPF Validation Response (a pacs.002 response in IPF Canonical format)
1. Below values are used for bulk level validation (OrgnlGrpInfAndSts.GrpSts)
  1. ACTC - Entire bulk has passed IPF Validation
  2. RJCT - Entire bulk has failed IPF validation (Appropriate ISO/Proprietary code mapped within OrgnlGrpInfAndSts.StsRsnInf.Rsn). There will not be any further responses sent for this bulk
  3. PART - Some transactions within the bulk failed IPF Validation (Status of all transactions conveyed in the response)
2. Below values are used for Transaction level validation results (TxInfAndSts.TxSts)
  1. ACTC - Transaction passed IPF Validation
  2. RJCT - Transaction failed IPF Validation (Appropriate ISO/Proprietary Code within TxInfAndSts.StsRsnInf.Rsn)
Scheme Validation Response (a pacs.002 response in IPF Canonical format)
1. Scheme Validation results are generated on the back of STEP2 SCT CSM Service receiving the CVF file from the scheme. The CSM Service maps and generates pacs.002 responses in IPF Canonical format.
2. Any transactions that had failed IPF validations, will not be available on the scheme validation response
3. Below values are used for bulk level validation (OrgnlGrpInfAndSts.GrpSts)
  1. ACSP - Entire bulk has passed Scheme Validation and the settlement is in progress
  2. RJCT - Entire bulk has failed Scheme validation (Appropriate ISO/Proprietary code mapped within OrgnlGrpInfAndSts.StsRsnInf.Rsn). The transaction within the bulk will not be settled. There will not be any further responses sent for this bulk
  3. PART - Some transactions within the bulk failed Scheme Validation (Status of all transactions conveyed in the response)
4. Below values are used for Transaction level validation results (TxInfAndSts.TxSts)
  1. ACSP - Transaction passed Scheme Validation
  2. RJCT - Transaction failed Scheme Validation (Appropriate ISO/Proprietary Code within TxInfAndSts.StsRsnInf.Rsn). Transactions that failed scheme validations, will not be settled
Settlement Response (a pacs.002 response in IPF Canonical format)
1. Settlement Responses are provided on the Interbank Settlement Date quoted within the bulk submitted from client implementation flows (GrpHdr.TtlIntrBkSttlmAmt). The settlement responses will be generated after the CGS EOD Cut-Off time has passed (Refer Configurations), accounting for any RSF files received from the scheme.
2. The transactions that had failed scheme validations, will not be included on the Settlement Response
3. Below values are used for bulk level validation (OrgnlGrpInfAndSts.GrpSts)
  1. ACCP - Entire bulk has been settled
  2. RJCT - Entire bulk has failed settlement. (Appropriate ISO/Proprietary code mapped within OrgnlGrpInfAndSts.StsRsnInf.Rsn).
  3. PART - Some transactions within the bulk failed settlement (Status of all transactions conveyed in the response)
4. Below values are used for Transaction level validation results (TxInfAndSts.TxSts)
  1. ACCP - Transaction settled
  2. RJCT - Transaction failed settlement (Appropriate ISO/Proprietary Code within TxInfAndSts.StsRsnInf.Rsn)

Debtor Recall Request/Resolution of Investigation (camt.056 and camt.029)

This differs from the pacs.008 / pacs.004 clear and settle request because there is no actual settlement of a camt.056 or camt.029 - transaction will move to either ACCP or RJCT - there is no ACSP response provided.

The following responses are provided:

A Technical acknowledgement of submission of bulk message from the client implementation flows (+ve Ack)
IPF Validation Response (a pacs.002 response in IPF Canonical format)
1. Below values are used for bulk level validation (OrgnlGrpInfAndSts.GrpSts)
  1. ACTC - Entire bulk has passed IPF Validation
  2. RJCT - Entire bulk has failed IPF validation (Appropriate ISO/Proprietary code mapped within OrgnlGrpInfAndSts.StsRsnInf.Rsn). There will not be any further responses sent for this bulk
  3. PART - Some transactions within the bulk failed IPF Validation (Status of all transactions conveyed in the response)
2. Below values are used for Transaction level validation results (TxInfAndSts.TxSts)
  1. ACTC - Transaction passed IPF Validation
  2. RJCT - Transaction failed IPF Validation (Appropriate ISO/Proprietary Code within TxInfAndSts.StsRsnInf.Rsn)
Scheme Validation Response (a pacs.002 response in IPF Canonical format)
1. Scheme Validation results are generated on the back of STEP2 SCT CSM Service receiving the CVF/QVF file from the scheme. The CSM Service maps and generates pacs.002 responses in IPF Canonical format.
2. Any transactions that had failed IPF validations, will not be included on the scheme validation response
3. Below values are used for bulk level validation (OrgnlGrpInfAndSts.GrpSts)
  1. ACCP - Entire bulk has passed Scheme Validation
  2. RJCT - Entire bulk has failed Scheme validation (Appropriate ISO/Proprietary code mapped within OrgnlGrpInfAndSts.StsRsnInf.Rsn). There will not be any further responses sent for this bulk
  3. PART - Some transactions within the bulk failed Scheme Validation (Status of all transactions conveyed in the response)
4. Below values are used for Transaction level validation results (TxInfAndSts.TxSts)
  1. ACCP - Transaction passed Scheme Validation
  2. RJCT - Transaction failed Scheme Validation (Appropriate ISO/Proprietary Code within TxInfAndSts.StsRsnInf.Rsn). Transactions that failed scheme validations, will not be settled

In the case of a camt.056, the ACCP response shows that the scheme have received and validated the message. It does not give an indication of the outcome of the processing of the camt.056. If the camt.056 is recieved before the corresponding pacs.008 is sent to the destination bank the scheme will cancel the pacs.008 and it will not be processed further. If the pacs.008 has already been forwarded on, the camt.056 will also be forwarded and either a pacs.004 or camt.029 message can be expected later. In order to know which of these outcomes will happen, the (optional) Payment Cancellation File (PCF) must be processed.

Once recieved and processed there are a number of behaviours that the CSM will follow:

Pacs.008 is cancelled - If the pacs.002 response in the PCF indicated that the scheme has cancelled the original pacs.008, the CSM will look-up the pending EOD pacs.002 for the pacs.008 and update its status to reflect that it was cancelled (Status "RJCT", Reason "CANC"). No pacs.002 will be sent updating the original camt.056 status (ACCP).
Camt.056 forwarded to destination - If the pacs.002 response in the PCF indicates that the camt.056 has been forwarded to the destination bank, the pending EOD pacs.002 for the pacs.008 is updated to reflect that outcome of the Recall is pending action by the destination bank (Status "ACCP", Reason "RCLL"). No pacs.002 will be sent updating the original camt.056 status (ACCP).
Updates post EOD - If the response to the camt.056 is received after the EOD cutoff for the original pacs.008, there will be no EOD pacs.002 waiting to be updated. The payment for which the pacs.008 was for will have settled and the bank has to expect either a pacs.004 or camt.029 from the destination bank. In this situtation a pacs.002 for each transaction in the original camt.056 will be sent back as a response to the camt.056 with the Status of "PDNG" and the Reason "RCLL".