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
  • Returns via pacs.008 (No support yet for pacs.004)
  • Processing returns via a pacs.008 (Interim measure)
  • Referencing the original payment
  • Defining the amount to be returned
  • Compensation for processing returns
Export as PDF
  1. Payment Processing
  2. Unsuccessful Payments (Exceptions)

Returns

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

<RmtInf>
    <Strd>
        <AddtlRmtInf>
NexusOrgnlUETR:91398cbd-0838-453f-b2c7-536e829f2b8e
        </AddtlRmtInf>
    </Strd>
</RmtInf>

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.

PreviousRecall RequestsNextInvestigation & Enquiry

Last updated 8 months ago