Validations, Duplicates & Fraud

Validations by Participants

During the payment process described in Payment Flow (Happy Path) there are a number of validations of the payment:

• The Source PSP will validate whether the Sender has sufficient balance (or an overdraft) on its account to honour the payment

• The Source IPS will validate whether the Source PSP has sufficient funding in its settlement account to cover its settlement obligations to the Source SAP

• The Destination SAP will validate whether the FXP has sufficient balance on its account at the Destination SAP

• The Destination IPS will validate whether the Destination SAP has sufficient funding in its IPS settlement account to cover its settlement obligation to the Destination PSP

Validations by Nexus

When Nexus receives the pacs.008 payment instruction from the Source IPS, it will validate certain details before forwarding it to the Destination IPS.

Validation of Amounts

• Nexus validates that the amount of the payment does not exceed the value limit of the IPSs at two points:

  • firstly, when generating quotes for PSPs (Nexus applies both the Source IPS and Destination IPS value limits)

  • secondly, when Nexus transforms the Interbank Settlement Amount in a pacs.008 before it is forwarded to the Destination IPS (Nexus will only validate the Destination IPS cap, as any payment forwarded by the Source IPS must logically be within the Source IPS’s own cap.)

Validation of Exchange Rates & Intermediary Agent Accounts

The specific validations depend on whether a third-party FXP is used, or whether the Source PSP acts as the FXP.

• Nexus will first check to see if an FX Quote Id is present in the pacs.008 message.

  • If no FX Quote ID is present, the Source PSP is acting as FXP for this payment

  • If a FX Quote ID is present, the Source PSP is using a third-party FX Provider (ie the Source PSP and FXP are separate entities)

  • (See Role of the FX Provider for further detail on the difference between these two scenarios.)

• When a Quote Id is provided, the Source PSP is using a third-party FX Provider. In this case, Nexus will:

  • Extract the FX Quote Id from the pacs.008 payment instruction

  • Look up the corresponding quote and its exchange rate

  • Check that the quote has not expired

  • Validate that the Exchange Rate given in the pacs.008 is correct according to the quote

    • If the Exchange Rate provided in the pacs.008 is different to the rate provided in the original quote, Nexus will reject the instruction with the status reason “AB04” (Aborted Settlement Fatal Error) from the ISO 20022 ExternalStatusReasonCode set. (There is currently no ISO 20022 status reason code for “Invalid Exchange Rate”.)

      • (Nexus cannot correct the Exchange Rate used in the message as this would alter the amount or flow of the payment.)

  • Use the FX Quote Id to retrieve the corresponding Intermediary Agent Accounts

    • Validate that the Intermediary Agent Accounts given in the pacs.008 are correct and belong to the FXP that provided the quote

    • If the Intermediary Agent Accounts specified in the pacs.008 are not recognized or do not belong to the FXP, Nexus will reject the instruction with the status reason RC11 (Invalid Intermediary Agent) from the ISO 20022 ExternalStatusReasonCode set.

• Where no Quote Id is provided, the Source PSP is acting as FXP to themselves. In this case, Nexus will:

  • Accept the exchange rate given by the Source PSP in the pacs.008, without validation

  • Extract the Intermediary Agent 2 account (representing the Source PSP’s account at the Destination SAP) from the pacs.008, and check that the account is registered in Nexus as belonging to the Source PSP

    • If the Intermediary Agent 2 account is not already registered with Nexus as belonging to the Source PSP, Nexus will reject the instruction with the status reason RC11 (Invalid Intermediary Agent) from the ISO 20022 ExternalStatusReason1Code set.

• Finally, Nexus will:

  • Apply the Exchange Rate given in the pacs.008 to the Interbank Settlement Amount, to give a new Interbank Settlement Amount denominated in the Destination Currency

  • Submit this transformed payment instruction to the D-IPS

Checking for duplicated payments

In general, Nexus trusts the Source PSP and assumes that any payment instructions received from the Source PSP are legitimate and should be processed. It is therefore the responsibility of the Source PSP and the IPSO to defend against sending fraudulent payments or payments that were sent in error.

Nexus uses the UETR (Unique End-to-End Transaction Reference) to check whether a payment is unique. Nexus will check whether a payment with the same UETR has already been processed, and will not process duplicates.

When Nexus detects a duplicate UETR in the pacs.008, it will follow the process in Investigation & Enquiry.

Nexus will categorize a transaction as duplicate when the combination of the UETR and the Message ID have occurred before. When the pacs.008 UETR is a duplicate, but the Message ID is not, Nexus will reject the message based on technical errors.

Nexus will not check whether similar payments with different UETRs are possible duplicates. For example, if a Source PSP sends two payments, for the exact same amount, between the same sender and recipient accounts, but with different UETRs, Nexus will assume both payments are intentional and will process both.

Fraud checks

Nexus does not currently have any central fraud prevention tools or transaction monitoring services. PSPs are responsible for preventing fraud. As Nexus payment volumes increase, additional fraud prevention tools will be considered.