Error Handling

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 and not data quality issues as all payments are checked before being submitted to the bulker. Should the Bulker report 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 clients 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 processing of the whole message will end and the waiting flow will need to be tidied up as well.

The SEPA CT CSM will only be notified by the Debulker that there are components ready to be processed if the input file is successfully debulked and all components are ready for use. There are a number of ways debulking can identify an error (ie duplicate file, invalid xsd validation, corrupt file etc), if debulking fails for any one of these reasons, a system event of type 'ERROR' will be raised and no downstream processing will be triggered. It will be the responsibility of the clients support team to fix the error with the file or debulker and re-trigger debulking of the file. The SEPA CT CSM will be unaware of these errors and will continue to function as normal.

In order 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 transacion/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 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).

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 orginal 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.