BIS Innovation Hub
Nexus - Short ReportAbout the BIS Innovation Hub
  • Introduction
    • Nexus Overview
    • How to use this site
    • Overview Report
    • Terminology
  • Payment Setup
    • Key Points
    • Scope of Nexus payments
    • Steps 1-2: Country, Currency & Amount
    • Steps 3-6: Exchange Rates
    • Steps 7-9: Addressing, Proxy Resolution & Confirmation of Payee
    • Steps 10-11: Sanctions screening
    • Step 12: Ask the Sender for approval
    • Step 13-16: Set up and send the payment instruction
    • Step 17: Accept the confirmation and notify Sender
  • Addressing & Proxy Resolution
    • Key Points
    • Overview of Payment Addressing in Nexus
      • Addressing via Proxies (Aliases)
      • Addressing via Account Details
    • Address Types & Inputs
      • Address Types
      • Address Inputs
      • Financial Institution Identification
      • List of PSPs
      • Examples
    • Proxy & Account Resolution Process
      • Step 1: Sender inputs proxy or account details
      • Step 2: Proxy Resolution Messaging Sequence
      • Step 3: Account Resolution Messaging Sequence
      • Step 4: Source PSP processes the results
      • Masking of Display Names
    • Role of the Proxy Directory Operator (PDO)
      • Obligations on the Proxy Directory Operator
      • Obligations of PSPs using the Proxy Directory
      • Onboarding a Proxy Directory Operator onto Nexus
  • FX Provision
    • Key Points
    • Role of the FX Provider
    • How Third-Party FX provision works in Nexus
    • Joining Nexus as a third-party FXP
    • Accessing Instant Payment Systems
    • Onboarding PSPs
    • Obligations & Compliance
    • Revenue model for FXPs
    • Rates from Third-Party FX Providers
      • Improving rates for larger transactions
      • Improving rates for specific PSPs
    • Quotes
    • Managing Liquidity
  • Payment Processing
    • Key Points
    • Accounts & Relationships
    • Maximum value of a Nexus payment
    • Payment Flow (Happy Path)
      • Detailed Flow in Source Country (Sending)
      • Detailed Flow in Destination Country (Receiving)
      • Booking flow for Source PSPs
      • Notifying FXPs of completed payments
    • Validations, Duplicates & Fraud
    • Time critical vs non-time critical payments
    • Special Scenarios
    • Payment setup for PSPs who provide their own FX
    • Unsuccessful Payments (Exceptions)
      • Rejects
      • Recall Requests
      • Returns
      • Investigation & Enquiry
      • Disputes
      • Reconciliation reports
    • Fees
    • Role and responsibilities of the Instant Payment System Operator (IPSO)
    • Ensuring settlement certainty
    • Annex: 4-step vs 5-step Processes in Domestic Clearing and Settlement
    • Annex: Sponsoring PSPs and Sponsored Entities
  • Settlement Access Provision
    • Key Points
    • Role of the Settlement Access Provider (SAP)
    • Joining Nexus as an SAP
    • SAP onboarding of FXPs (or foreign PSPs)
    • Costs and Revenue for SAPs
    • Obligations on the SAP
    • Processing payments as an SAP
      • Payment Process for the Source SAP
      • Payment Process for the Destination SAP
      • How the Destination IPS initiates the payment via the Destination SAP
    • Managing Liquidity as an SAP
  • Messaging & Translation
    • Key Points
    • General Usage of ISO 20022
      • Adherence to CPMI Harmonised ISO 20022 Data Requirements
    • Compatibility with Instant Payments Plus (IP+)
    • Message transformation by Nexus
    • Specific Message Elements
    • Purpose Codes
    • Message Guidelines (Excel)
    • MESSAGE acmt.023 Identification Verification Request
    • MESSAGE acmt.024 Identification Verification Report
    • MESSAGE: pacs.008 FI to FI Customer Credit Transfer
      • pacs.008 Differences from CPMI Harmonisation Requirements
    • MESSAGE pacs.002 Payment Status Report
      • pacs.002 Differences from CPMI/CBPR+ Guidelines
    • MESSAGE: pacs.004 Payment Return (Not yet supported)
    • MESSAGE: camt.054 Bank to Customer Debit Credit Notification
    • Translation To/From Domestic Message Formats
    • Translating To/From ISO 20022 Codes
  • APIs
    • Overview
    • Countries
    • Currencies
    • Address Types and Inputs
    • Financial Institutions
    • Fees and Amounts
    • Intermediary Agents (SAPs)
    • Quotes
    • ISO 20022 Messages
  • About
    • Contact the Nexus Team
  • LEGAL
    • Terms and Conditions of Use
    • Privacy Notice
    • Cookies Notice
Powered by GitBook
On this page
  • Step 13: Retrieve the Intermediary Agents (FXP’s accounts)
  • Step 14: Construct the Nexus pacs.008 payment instruction
  • Step 15: Send the pacs.008 to the Source IPS
  • [ON ROADMAP] Step 16: Be ready to respond to any Requests for Information from the Destination PSP
Export as PDF
  1. Payment Setup

Step 13-16: Set up and send the payment instruction

PreviousStep 12: Ask the Sender for approvalNextStep 17: Accept the confirmation and notify Sender

Last updated 7 months ago

Now that the Sender has approved the payment, the PSP must set up the Nexus-standard pacs.008 payment instruction (or domestic equivalent) and submit it to the local IPS.

Step 13: Retrieve the Intermediary Agents (FXP’s accounts)

  1. The PSP uses the API operation GET /quotes/{quoteId}/intermediary-agents to retrieve the Intermediary Agents, based on the FX Quote 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 the FXP's account in the Destination Country.

Step 14: Construct the Nexus pacs.008 payment instruction

  1. The PSP constructs the pacs.008 payment instruction: this will make use of information from the earlier responses to:

    1. GET /quotes

    2. The acmt.023 proxy or account resolution request

    3. GET /quotes/{quoteId}/intermediary-agents

  2. The Source PSP should define whether the payment is by setting the Instruction Priority (/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/PmtTpInf/InstrPrty/) as follows:

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

    2. HIGH: for urgent payments and physical point-of-sale payments (eg where the customer cannot leave the store until the payment is confirmed). If HIGH is used, the Destination PSP must reject any payments that it cannot immediately accept. Payments marked HIGH are 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 HIGH should not be used unnecessarily.

See MESSAGE: pacs.008 FI to FI Customer Credit Transfer for further details.

Step 15: Send the pacs.008 to the Source IPS

  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. The Source IPS will process the payment and then forward it to Nexus, following the process in Payment Processing.

Checking for duplicated or fraudulent payments

  • In general, Nexus expects the Source PSP to ensure that any payment instructions it sends to Nexus are legitimate, non-fraudulent and compliant with all applicable regulations, and should therefore 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.

[ON ROADMAP] Step 16: Be ready to respond to any Requests for Information from the Destination PSP

The Request for Information process will use ISO 20022 messages to allow any PSP to request further (or corrected) information relating to an existing pacs.008 payment instruction. Relevant ISO 20022 messages exist but the process has not yet been designed in full for Nexus, and is currently on the roadmap.

  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.

time-critical or non-time critical