Investigation & Enquiry
Investigations may be raised in two scenarios:
When no
pacs.002was received to update on the status of a paymentWhen a
pacs.002status was received, but the customer disagrees with the status.
In the second case, the Source PSP should raise an investigation via the Nexus Service Desk, referencing the UETR of the payment and tagging the Destination PSP.
In the first case, PSPs can resend the pacs.008 using the process below.
Investigating when no pacs.002 payment status report was received
pacs.002 payment status report was receivedIn the scenario where the Source PSP hasn’t received a response after the after the timeout defined in the Nexus Scheme Rulebook, the Source PSP is allowed to request an update by resending the pacs.008. This is an optional process which can be used by the Sending PSP to retrieve the status of a payment.
Each party must respond to a re-sent pacs.008 as follows:
Check if they received the original
pacs.008payment instructionIf no
pacs.008(with those specific Message ID and UETR elements) was received, respond with apacs.002with statusRJCT, rejecting the payment due to failure in the timestamp validation (<AccptncDtTm> too far in the past). The specific rejection reason to be used isTM01.If the original message was received:
Check whether the party received a corresponding
pacs.002with a final status (ie status codesACCC,RJCT,BLCK, ACWC)If yes, resend the
pacs.002to the Source PSPIf no, resend the
pacs.008to the next party in the chain. This can occur when:No
pacs.002was receivedA
pacs.002was received with a status code ofACWP
This results in the following sequence diagram:
The chain of parties is as follows:
Source PSP (requestor)
Source IPS
Nexus Gateway(s)
Destination IPS
Destination PSP

Last updated
