Investigation & Enquiry
Investigations may be raised in two scenarios:
When no
pacs.002
was received to update on the status of a paymentWhen 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.
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.008
payment instructionIf no
pacs.008
(with those specific Message ID and UETR elements) was received, respond with apacs.002
with 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.002
with a final status (ie status codesACCC
,RJCT
,BLCK, ACWC
)If yes, resend the
pacs.002
to the Source PSPIf no, resend the
pacs.008
to the next party in the chain. This can occur when:No
pacs.002
was receivedA
pacs.002
was received with a status code ofACWP
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.
Last updated