Investigation & Enquiry

Investigations may be raised in two scenarios:

1. When no pacs.002 was received to update on the status of a payment

2. 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.

Investigating when no pacs.002 payment status report was received

In 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