Correlation Store
When a Bulk file containing <N> payments (e.g. an IDF containing <N> pacs.003s) has been sent out by the SEPA DD 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 DVF). The SepaDD 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 DD, 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 will no longer be available.
You can use the following configuration key in the ipf.conf file to override the default ttl value:
ipf.csm.sepa-common.correlation-store.ttl-duration = P30DThe format of the provided String value should be a Java Duration as an ISO-8601 representation, for example P30D (30 days).
DVF Processing
When a DVF (Validation File) is received:
-
Perform the shared validation steps described in Correlation Validation.
-
Rejected transactions are marked as cancelled in the correlation store
-
Group-level status is calculated based on rejection state:
-
All transactions rejected → Group status: RJCT Reason Code: CANC
-
Some transactions rejected → Group status: PART Reason Prtry: B01 (partial)
-
No transactions rejected → Normal group status (ACCP)
-
RSF Processing
When an RSF (Settlement File) is received:
-
Perform the shared validation steps described in Correlation Validation.
-
Transaction Filtering: Only active (non-cancelled/non-rejected) transactions are processed for settlement.
-
Exclusions: Cancelled or rejected transactions are excluded, as they have already received a final response (RJCT) during DVF processing.
-
Group-level status is calculated based on cancellation state:
-
All transactions cancelled → Group status: RJCT Reason Code: CANC
-
Some transactions cancelled → Group status: PART Reason Prtry: B01 (partial)
-
No transactions cancelled → Normal group status (ACSC)
-
Correlation Validation
The following logic is applied to both DVF and RSF response processing:
-
The number of records in the correlation store is compared to the
FIToFIPmtStsRptS2.orgnlGrpInfAndSts.orgnlNbOfTxsfield. If a mismatch occurs, processing for that specific message is halted, processing continues on the remaining messages in the file.-
CorrelationStoreLookupFailedEvent: Raised if the mismatch is caused by a failure to read from the database. -
UnexpectedNumberOfCorrelations: Raised when the count retrieved from the store differs from the count specified in the incoming pacs.002 message.
-
Cancellation Support
Overview
When a cancellation request is accepted by EBA, the original pacs.003 transaction correlation is marked as cancelled, and the corresponding CollectAndSettleResponse is updated to reflect the cancellation status.
Cancellation Flag
Each correlation includes an isCancelled boolean flag to track whether a transaction has been cancelled:
-
isCancelled = false(default): Transaction is active and proceeding normally through settlement -
isCancelled = true: Transaction has been rejected via a DVF response or cancelled via an accepted camt.056 request
Matching Criteria
The Scheme pack utilises matching criteria to link cancellation requests with their corresponding pacs.003 transactions. The matching is performed using the following fields:
| Matching criteria | ISO field |
|---|---|
|
pacs.003: |
|
pacs.003: |
|
pacs.003: |
| Correlations are stored for all message types sent to the scheme, the messageType field is used to filter correlation results. E.g. PACS_003 to retrieve only pacs003 correlations |
Cancellation Processing Flow
DVF Processing - Cancellation Accepted
When a DVF (Debit Validation File) is received showing that EBA accepted a camt.056 cancellation request:
-
The system identifies the DVF response as a camt.056 validation result
-
Matching criteria are extracted from the camt.056 message (creditorAgentBicFi, settlementDate, transactionId, messageType)
-
The correlation store is searched for the matching pacs.003 transaction
-
If a matching correlation is found:
-
The correlation is marked as cancelled (
isCancelled = true) -
A CollectAndSettleResponse is immediately sent to the client with status RJCT and reason code CANC (for single transaction messages)
-
The transaction is excluded from subsequent RSF (settlement) processing
-
-
If no matching correlation is found:
-
A system event is raised (see Camt056Pacs003CorrelationFailed)
-
The ExecuteDDCancellationResponse (ACCP/T00) proceeds normally
-
Manual reconciliation may be required
-
DVF Processing - Cancellation Rejected
When a DVF is received showing that EBA rejected a camt.056 cancellation request:
-
The pacs.003 correlation is NOT marked as cancelled
-
The original pacs.003 transaction is subject to normal RSF (Result of Settlement File) processing
-
Final settlement status (ACSC or RJCT) is sent to the client when the RSF is processed
Cancellation-Specific Events
-
CancellationCorrelationFailed– Raised when a camt.056 cancellation is accepted by EBA but the matching pacs.003 correlation cannot be found in the correlation store using the matching criteria. The ExecuteDDCancellationResponse (ACCP/T00) is still sent to the client, but the CollectAndSettleResponse cannot be updated to RJCT/CANC.