Investigation & Enquiry
Last updated
Last updated
Investigations may be raised in two scenarios:
When no pacs.002 was received to update on the status of a payment
When a pacs.002 status 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.
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.008 payment instruction
If no pacs.008 (with those specific Message ID and UETR elements) was received, respond with a pacs.002 with status RJCT, rejecting the payment due to failure in the timestamp validation (<AccptncDtTm> too far in the past). The specific rejection reason to be used is TM01.
If the original message was received:
Check whether the party received a corresponding pacs.002 with a final status (ie status codes ACCC, RJCT, BLCK, ACWC)
If yes, resend the pacs.002 to the Source PSP
If no, resend the pacs.008 to the next party in the chain. This can occur when:
No pacs.002 was received
A pacs.002 was received with a status code of ACWP
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
In a future release of Nexus, support for the pacs.028 payment status investigation message will be introduced to support an automated investigation and enquiry process (without needing to resend a pacs.008), reducing manual intervention by staff.
