Steps 13-16: Set up and send the payment instruction
Now that the Sender has approved the payment, the PSP must set up the Nexus-standard pacs.008 payment instruction which will be submitted to the local IPS.
- 1.The PSP uses the
GET /intermediaryagents/API operation to retrieve the Intermediary Agents, based on the ID of their preferred quote. This information is used in the pacs.008 message to specify the accounts held by the FX Provider in both the Source and Destination country. Funds will be paid into the FXP's account in the Source Country and paid out of their account in the Destination Country.
- 1.The PSP constructs the pacs.008 payment instruction: this will make use of information from the earlier responses to the following APIs:
- 2.The Source PSP should define whether the payment is time-critical or non-time critical, by setting the Instruction Priority (
/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/PmtTpInf/InstrPrty/) as follows:
NORM: default, for all payments that are not urgent or time-critical. This flag will allow the Destination PSP extra time (to be defined in the Nexus scheme rulebook) to complete sanctions screening in the event the payment triggers an alert.
HIGH: for urgent payments and physical point-of-sale payments (where the customer cannot leave the store until the payment is confirmed). If
HIGHis used, the Destination PSP will reject any payments that it cannot immediately accept. Payments marked
HIGHare more likely to be rejected if the Destination PSP does not have real-time sanctions screening systems. They will also be rejected if the payment generates a sanctions alert which the Destination PSP cannot resolve without manual intervention. This means that
HIGHshould not be used unnecessarily.
- 1.Once the Sender has confirmed the payment, the PSP should submit the pacs.008 payment instruction to the Source IPS (using the same secure connection that the PSP normally use to submit domestic payment instructions to the IPS). ]
- 2.Nexus will coordinate the payment between the Source and Destination Countries.
Checking for duplicated or fraudulent 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 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.
- However, 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.
- Nexus does not currently have any fraud prevention tools or transaction monitoring, although this could be added to the roadmap in due course.
The proof of concept uses End2EndId as the unique identifier, but a production version will need to use UETR. This is because we cannot be sure that the End2EndId for a specific payment will be universally unique across all PSPs and all IPSs in Nexus, whereas UETR is by definition universally unique (as it is generated as a Universally Unique Identifier – UUID.)
- 1.If the Source PSP supports the Request for Information (RFI) service, the Source PSP should be prepared to respond to any RFIs relating to this payment. These requests could come from either of the Settlement Account Providers or the Destination PSP. (See Request for Information for further details.)