Correlation Store

When a Bulk file containing <N> payments (e.g. an ICF containing <N> pacs.008s) has been sent out by the SEPA CT CSM Service, after a period of time, it will then receive a response for a subset of these payments in another Bulk file (e.g. pacs.002s in a CVF). The sepact-csm-service needs to be able to find and link the payments in this received response to the original outbound payments.

The Correlation Store module provides a correlation store that is used to persist the Transaction ID of the transaction passed to the bulker and the unique Bulk ID of the Bulk it is stored in. This ensures that when a pacs.002 is received from SEPA CT, it is possible to identify all the associated transaction IDs.

The Correlation Store is used in this way during the processing of all message types, to link scheme responses to their original request.

Time To Live

The store is implemented via MongoDB. By default it will persist correlation entries for 30 days based on the createdAt field. It does this by creating a TTL on the MongoDB collection. Once the time has expired entries will be evicted from the collection and no longer available.

If you want to override the default value, you can include your value in the ipf.conf file:

ipf.csm.sepa-common.correlation-store.ttl-duration = P30D

The format of the provided String value should be a Java Duration as an ISO-8601 representation, for example P30D (30 days).

Handling unexpected results from the Correlation Store

The corresponding transaction/request will be removed from the local copy of the message being processed, and the Client Support team will be responsible for manual reconciliation and investigation.

Two specific System Events may be raised during this process:

  • CorrelationStoreLookupFailedEvent – Raised when the Correlation Store returns zero results for a lookup (i.e., no matching record is found)

  • UnexpectedNumberOfCorrelations – Raised when the Correlation Store returns an unexpected number of results, differing from the expected OrgnlNbOfTxs

Both of these events are logged in the application logs and indicate that an investigation is required to determine why the correlation failed.

As soon as a pacs.002 is received, any related implicit End-of-Day (EOD) pacs.002 that could be associated with it will be cancelled. This ensures that duplicate or redundant EOD triggers are not processed unnecessarily.