End of Day Processing

Should there be any failures in the settlement of payments that were due to be settled during the day that has just ended, the scheme uses the "Result of Settlement File" (RSF) to report these failures to each bank. The RSF will contain a pacs.002 for each failed payment. The absence of pacs.002 in the file indicates that the payment was successful. If there are no settlement failures at all, no RSF will be delivered.

In order to report the state of the payment at the end of the day, the SEPA CT CSM will send a pacs.002 for every payment that was due to the settled on the day that just ended. The final state for successful payments will be ACCP to show that it was fully accepted (having previously been ACSP - Accepted Settlement in Progress). Failed payments will have a state of RJCT with the reason for the failure. The time at which these final pacs.002 messages are sent can be configured using the ipf.csm.sepa-ct.la.cgs-eod-output-delivery-buffer config item. Individual clients can configure this value to be an appropriate time, after the final LAC of the day, sufficient for their systems to be able to receive an RSF file, have it delivered to the SEPA CSM for processing and the CSM to update the appropriate pacs.002 that is waiting to be triggered for delivery.

The behaviour of a camt.056 message will depend on the progress of the pacs.008 it is referring to. If both messages are with the scheme at the same time, the camt.056 will cancel the pacs.008 without the need to send it to the creditor bank, however, if the pacs.008 has already been included in a Settled Credit File (SCF) the camt.056 will need to be forwarded to the destination bank in the next SCF. A client bank will either need to manually investigate the outcome of the camt.056 via the STEP2 portal, or subscribe to the Payment Cancellation File (PCF). Icon recommend the use of the PCF, the CSM has been designed to process the file, but will work without it.

If subscribed to receive the PCF, the client should configure their EOD processing of the RSF to occur after the last PCF of the day has been processed. The CSM will parse the PCF and find the details of the pacs.008 being cancelled. If the EOD processing on the settlement date of the pacs.008 has not passed, the CSM will update the waiting pacs.002 with the outcome of the camt.056, so that the flow processing the pacs.008 knows the payment’s outcome. If the EOD pacs.002 has already been sent to the client implementation (i.e. because the settlement date was a previous day), the clients camt.056 flow will receive the pacs.002 with the outcome of the camt.056 scheme processing. These responses to will contain one transaction per pacs.002.

The SEPA CT scheme works on the bases of implied success. If a pacs.008 is sent out and no response is received in a CVF, it can be assumed that the payment has worked. In this situation the customer is debited and responsibility of crediting the recipient is with the other bank, if they are not, a claim for non-receipt (camt.027) can be raised via exception processing.

The SEPA CSM service will take this processing one step further, if no CVF is received to trigger the completion of the pacs.008 processing, at EOD all outstanding pacs.008 messages that have not received a response in a CVF will have a pacs.002 indicating success auto-generated. If the payment is investigated, the fact it was triggered by EOD processing and not a CVF will be recorded by the lack of Debulker events emitted and the resulting flows in the CSM service not having been triggered from Debulker.

It is possible and has happened in the past, that the scheme will contact all Direct Participants to inform them that there will be a delay to EOD processing. In the event of this happening, all the processes outlined above will need to be delayed by the time communicated by the scheme. This can be done by updating the ipf.csm.sepa-ct.lac.cgs-eod-cutoff config item to reflect the new EOD time. Once this has been updated the SEPA CT service will need to be restarted in order for the new value to take effect.

This config item will be accessible via Dynamic Configuration in a future release, which will mean a restart will no longer be required when updating the cutoff.