Error Handling
Where ever possible, the SEPA CT CSM has automated error handling to either resolve issues itself or pass control back to the calling flow with details of the problem. There are, however, a few situations where this is not possible due to the severity and level of the error. This page outlines those situations and how the CSM will handle them.
Errors within the Bulker
The Bulker is a core aspect of IPF, it is configured and deployed with the CSM, but is a separate component. Any errors occurring in the Bulker will be due to technical issues, not data quality issues, since all payments are checked before being submitted to the Bulker. If the Bulker reports an error when a transaction is submitted, the CSM will raise a system event of type 'ERROR'. This event will contain the whole transaction in the payload of the message. The offending Transaction will be removed from the message currently being handled by the CSM, and processing will continue. In doing so, the CSM hands responsibility of the transaction to the client’s support team, as it is unable to pass it to the scheme itself. If there is only one transaction in a message, or all transactions are removed due to errors, the SEPA flow transitions to submission rejected.
Errors within the Debulker
If the input file is successfully debulked and all components are ready, the Debulker will notify the SEPA CT CSM. In case of failure, (e.g., duplicate file, corrupt file), a system event of type ERROR will be raised and a notification will be sent by the SEPA CT CSM Scheme Pack. No downstream processing will be triggered in such cases.
| It will be the responsibility of the client’s support team to fix the issue and re-trigger the debulking process. |
Errors within the Correlation Store
To correlate pacs.002 responses from the scheme with the initial requests sent by the CSM, an external database is used as a Correlation Store. Information about the outbound payments/requests and which message/file they were bulked into, is stored as records in this location. The store is a separately deployed component of the CSM and can report its own errors. Similar to the Bulker, any errors reported by the Correlation Store will result in a System Event of type 'ERROR' and the removal of the transaction/request in question from the message currently being processed. A copy of the whole component and request sent to the Store will be included as the payload in the System Event. With no record of the request in the Store, the CSM will not be able to match the scheme response with the correct request, so the transaction/request will be removed from the local copy of the message being processed by the CSM and responsibility of matching the response will fall to the Clients Support team (as the transaction will be in the next file to be sent to the scheme).
Errors within the pacs.008 Group Header
When transactions are bulked together for delivery to the scheme, the responsibility of constructing the group header falls to the SEPA CT CSM, as the client’s header is removed during internal processing. Construction of this header is fully automated and tested, so it should never contain errors. If, however, the scheme rejects a message with an error code that indicates a problem with the group header, a System Event of type 'ERROR' will be raised and the processing of the response will be stopped. The system event will identify the original outbound message with the error. It will be the responsibility of the support team to access the original outbound message, fix the error and resubmit the payments directly to the scheme. Resubmitted messages, due to group header errors in their originals, will not be identified as duplicates by the scheme; the original MsgId can therefore be used. The SEPA CT CSM will be able to process the new scheme response, matching it to the original message, and normal processing will resume. If these errors are ever encountered, the root cause will need to be investigated and fixed.