If a participant (IPS, SAP or PSP) is not able to accept the payment for any of the reasons given below, it must respond to the payment instruction with a rejection:

• If the rejection takes place during in the Source leg of the transaction, the transaction will be rejected before the message reaches the Nexus Gateway. This rejection can be handled by the Source IPS; the Source IPS does not need to inform Nexus of this rejected transaction.

• If the rejection takes place after Nexus has received the transaction, the Destination IPS must report this rejected transaction to the Nexus Gateway using a pacs.002 message with the status code RJCT and an appropriate reason code. See MESSAGE pacs.002 Payment Status Report for more details, including the ISO 20022 error codes supported by Nexus.

Causes of Rejection

A number of events can cause the payment to be unsuccessful (including due to technical timeouts). For example:

• The Source SAP, Destination SAP or Destination PSP applies sanctions screening (if required by local legislation) and decides it does not want to process the payment, due to concerns about either the Sender or the Recipient

• The Source PSP has insufficient funds in their IPS settlement account to make the payment

• The Destination SAP checks the balance of the FXP’s account and finds it is insufficient to cover this payment

• The Destination SAP’s own settlement account at the IPS has insufficient funds to make the payment to the Destination PSP

• The Destination PSP finds that the Recipient’s account is closed, dormant or frozen

A full list of reject reasons is included in MESSAGE pacs.002 Payment Status Report. The Message Guidelines (Excel) further stipulates which error codes can be used by which party.

Nexus Service Desk

Nexus will provide a Service Desk which will contain a directory of every PSP in the Nexus network, along with the relevant operations, compliance and dispute officers for each PSP. The service desk will support the creation of tickets that can be assigned by one PSP to another PSP. This is a more reliable way of tracking and processing exceptions than manual communication channels such as email or telephone (although the directory will also contain contact details for the relevant officers).

Nominated staff of each PSP will be able to log into the Nexus Service Desk to register investigations, enquiries, recall requests and disputes. Once a case is created the service desk will automatically send a notification to the relevant officer at the relevant PSP.

In general, cases PSPs should work to resolve cases bilaterally, without involving the staff of the Nexus Scheme Organization. However, the NSO may monitor the average age and status of cases in the system and engage with PSPs who consistently fall below the expectations for responsiveness and resolution.

Logging Disputes

Disputes should be logged in the Nexus Service Desk. The timelines for resolving disputes are defined in the Nexus Scheme Rulebook. Disputes can be raised by both the Sender and the Recipient of a transaction.

According to the Nexus Scheme Rulebook, some disputes may be escalated to the NSO. A PSP must request an escalation through the Service Desk.

Nexus will provide the IPSO two options for retrieving reconciliation reports.

1. Via API

Nexus will provide an API which reports on all transactions send and received by the requesting IPSO. The IPSO can apply filters to the API, for example on payment status (all completed payments, all rejected payments, etc), specify a custom date and time range), and/or specific financial institutions. This will allow the IPSO to reconcile the transactions in its system with the transactions processed by Nexus.

The transactions reported in the API contain the UETR. It is recommended by Nexus that PSPs use the UETR to reconcile the transactions and their status in the API with their own systems.

1. Periodic report

Nexus will also periodically provide a machine-readable reconciliation report with all transactions with a final status code ACCC, RJCT, BLCK or ACWCto allow for reconciliation by the IPSO. The report will contain all new transactions since the last report, ensuring the PSP is able to verify reception of all transactions. The transactions included in the report contain the UETR. It is recommended by Nexus that PSPs use the UETR to reconcile the transactions and their status with their own administration using the UETR.

The report is in the ISO20022 camt.054.001.11 format.

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

This section considers the various exception scenarios when a payment cannot be successfully processed:

• - when a payment is rejected whilst it is being processed

• - when the Source PSP asks for the funds transferred in an earlier successful payment to be returned

• - when the Destination PSP agrees to send the funds back to the Source PSP

• - when the Source PSP challenges details of the payment

• - for establishing the status of payments where no confirmation was received (rare)

It is not possible for the Source PSP to stop the processing of a payment that has been submitted to Nexus. Unless the payment fails for any other reason, the funds will be credited to the Recipient’s account. If the Nexus payment is confirmed by the D-IPS, the payment is deemed final for Nexus (see the Nexus Scheme Rulebook for specifics on finality) and cannot be recalled.

In case the Source PSP needs to request the return of a payment, the following process must be followed:

1. The Source PSP must log a “Payment Recall Request” in the Nexus Service Desk, and assign the case to the Destination PSP.

2. The Destination PSP must review the case within the SLA defined in the Nexus Scheme Rulebook.

3. If the Destination PSP wishes to reject/refuse the request, it must update the case with the relevant reason for rejection.

4. If the Destination PSP accepts the request, it will:

   1. update the case and then trigger a new Nexus payment back to the Source PSP, with the Sender’s account defined as the creditor. See .

In a future release of Nexus, support will be added for the following ISO 20022 messages:

• the camt.056 FI to FI Payment Cancellation Request message, which references the original payment and describes a reason for the return request

• the camt.029 Resolution of Investigation message, which informs the Source PSP whether the Destination PSP intends to reject or accept the request, and the reasons for that decision

• the pacs.004 Payment Return message (see )

These messages will allow payment recalls to be processed automatically without manual use of the Nexus Portal.

Returns via pacs.008 (No support yet for pacs.004)

The first release of Nexus will not support a dedicated payment return process. Instead, the Destination PSP must initiate a new Nexus payment to the Source PSP and Sender.

The Destination PSP can (but is not required to) reference the original payment in the payment message in the Structured Remittance information elements. Nexus will not try to correlate this against the original payment instruction from the Source PSP.

Note that typically, a Nexus payment is processed instantly. Returns should therefore be an exceptional case.

Processing returns via a pacs.008 (Interim measure)

Currently, when a payment needs to be returned to the Sender, the Destination PSP must request a new quote and then create a new Nexus payment. The return payment does not have to use the same FX Provider as the original payment, nor does it need to follow the same route (i.e. use the same Settlement Access Providers).

The Source IPS should submit the return payment as a Nexus pacs.008 message. For Nexus, this is treated as a new payment, including for all validations and fees.

Referencing the original payment

When the Destination PSP wants to reference an earlier transaction, the original UETR can be included in the Additional Remittance Information prefixed with "NexusOrgnlUETR:" (in addition to a separate instance containing the new NexusFXQuoteId).

Up to three recurrences of the Additional Remittance Information element are allowed in a Nexus message.

Defining the amount to be returned

In most cases, the exchange rates available in Nexus would have changed since the Source PSP sent the original payment instruction. This will result in either the Source PSP or Destination PSP making a loss or gain as a result of the change in FX rates.

To ensure fairness, this must be handled as follows:

Scenario 1: Source PSP at fault

• The Source PSP may be at fault if (for example) the payment was sent in error, fraudulent, or the Sender requested the return.

• In this case, the Source PSP takes the FX risk

• The Destination PSP should send back exactly the amount they received in the Destination Currency.

  • The D-PSP is allowed to deduct a reasonable amount as administrative fee from the amount to be returned.

  • The Destination PSP can do this by requesting a quote from the Nexus Quotes API, specifying the amount to return denominated in the Destination currency.

• The amount requested should be the same as the Destination PSP originally received from the Destination SAP (ie the Interbank Settlement Amount in the pacs.008 processed by the Destination IPS, in the Destination Currency), minus any fee that the D-PSP charges for processing the return

• The Destination PSP must debit the Creditor by the full amount originally credited to the Creditor’s account.

• The Source PSP may receive more or less than it originally sent to the Destination PSP, due to the change in exchange rates.

• Because the return is using a normal pacs.008 payment instruction:

  • The original Source PSP becomes the new Destination PSP and must deduct the D-PSP fee (according to the standard formula in Nexus)

  • The original Source PSP may not recognize that the payment is a return, and so may process it as per a normal payment

• The Source PSP may choose to reimburse (credit) the Sender for the amount originally debited from their account (ie the Source PSP absorbs the FX risk, whether losses or gains)

  • Alternatively the Source PSP may choose to credit the Sender the amount actually received in the return payment (ie passing the FX risk onto the Debtor).

Scenario 2: Destination PSP at fault

• The Destination PSP may be at fault if (for example) they accepted a payment but then later decided that they should have rejected it, or if the Recipient refuses the payment.

• In this case the Destination PSP must take the FX risk

• The Destination PSP must return exactly the amount the Source PSP sent, in the Source currency

• The Destination PSP can do this by requesting a quote from the Nexus Quotes API, specifying the amount to return denominated in the Source currency

  • The amount to request can be calculated by taking the Interbank Settlement Amount (in Destination Currency) from the original pacs.008 and dividing it by the Exchange Rate.

• The amount the Destination PSP needs to return to the Source PSP may be more or less than the amount originally received from the Source PSP, due to changes in FX rates.

• The Destination PSP must debit the Creditor by the full amount originally credited to the Creditor’s account.

• The Destination PSP (and not the Creditor) takes any FX risk if the amount that must be returned to the Source PSP is greater than the amount that was originally received from the Source PSP.

Compensation for processing returns

When a return is initiated by the Destination PSP, the payment must be returned including the Destination PSP fee.

When a return is the result of a request by the Source PSP, the Destination PSP is allowed to deduct a reasonable amount as administrative fee from the amount to be returned. It is up to the Source PSP whether they pass the return fees onto the end-customer or reimburse the customer fully.

Note that the party that takes the FX risk may in fact benefit if the exchange rate has moved in their favour. Over a number of return payments (which are themselves rare) the losses and gains are likely to net out and any overall loss will be negligible.