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
Export as PDF
  1. Payment Processing
  2. Payment Flow (Happy Path)

Detailed Flow in Source Country (Sending)

PreviousPayment Flow (Happy Path)NextDetailed Flow in Destination Country (Receiving)

Last updated 7 months ago

The sending payment process follows the following steps:

#

Process Step

Specific Requirements

1

The Sender initiates and authorizes a Nexus cross-border payment.

The Sender has full transparency on the amount to be credited to the Recipient.

2

The Source PSP debits the Sender’s account or reserves the funds against the Sender's account balance.

The Source PSP must ensure the Sender has sufficient funds and must ensure the payment will be honoured, either by debiting the Sender’s account or by making a reservation of the funds on the account.

3

The Source PSP sends the payment instruction to the Source IPS.

4

5

The Source IPS sends the payment instruction to the Source SAP for validation.

6

The Source SAP reviews the payment instruction. As this is a cross-border payment, it may need to also apply sanctions screening, if required by local legislation. If the Source SAP is happy to accept the payment on behalf of the FXP (its customer), the Source SAP will respond with a payment status message to confirming that it will accept the payment.

Nexus does not prescribe the format of the domestic payment status confirmation message.

The IPS will monitor the response times of the Source SAP to ensure the response falls within the SLA.

In case of a reject, the IPS will reverse the settlement and/or undo the reservation and confirm the reject to the Source PSP.

7

The Source IPS sends a Nexus pacs.008 payment instruction message to Nexus.

Unlike a domestic payment, the Source IPS would not send a confirmation to the Source PSP or Source SAP yet. Instead, it waits to receive the response from Nexus.

Some IPSs may still choose to send a pacs.002 with a status code that informs the PSP that the payment has successfully been sent to Nexus. This would be at the discretion of the IPS and is not required or specified by Nexus. If the Source IPS does not use the Nexus ISO 20022 messages domestically, it may translate them at this point.

8

The Nexus validates and transforms the payment instruction to prepare it for the second leg by:

  • changing the instructing and instructed agents to the Destination SAP and Destination PSP respectively

  • validating the quote that is referenced, updating the currency and applying the currency conversion to the “Interbank Settlement Amount”.

Nexus then forwards the payment instruction to the Destination IPS.

9

The Nexus pacs.008 is processed on the Destination side

10

The Destination Nexus Gateway sends the result from the Destination IPS processing in a Nexus pacs.002 payment status report to the Source Nexus Gateway

11

The Source Nexus Gateway forwards the pacs.002 payment status report message to the Source IPS.

If the Source IPS does not use ISO 20022 to communicate with its participants, it may translate the pacs.002 at this point.

12

In case of a reject, the Source IPS will undo the reservation, or, in the case of a 4-step settlement model, return the transaction by reversing the settlement obligations.

13

5-step settlement only The Source IPS will send the Source SAP a confirmation that the payment has been successful or rejected.

14

The Source IPS will send the Source PSP a confirmation that the payment has been successful or rejected.

16

The Source PSP can now inform their Sender that the payment is complete (either confirmed or rejected).

17

Finally, the Source Gateway informs the FXP that a payment has been processed using their quote; this is important to enable the FXP to keep track of their liquidity.

The FXP may also be separately updated of their account balances by the Source SAP and Destination SAP.

There are no Nexus requirements on the format of the domestic payment message. The IPS must ensure the used payment message format contains sufficient data to cater for a Nexus payment message to be sent to the Nexus gateway. This includes elements such as the Source and Destination SAP (Intermediary Agents), the accounts of the FXP and the exchange rate. For full details of the Nexus requirements, see

The Source IPS either updates the settlement obligations () or ensures settlement (by reserving the pre-funded balance of the Source PSP or otherwise) in a .

The Source IPS must ensure settlement certainty. There is no requirement for Nexus how to do this (either by settling the transaction, making a reservation against a prefund or otherwise). (See .)

The Source IPS will also need to ensure a potential reject can be processed, even in the case of a settled transaction () in case of issues with other participants (eg lack of funds at the Source SAP, default of one of the participants, etc).

(See below for more details.)

only The Source IPS will finalise the payment between the Source PSP and Source SAP by updating the settlement obligations.

Messaging & Translation
Ensuring settlement certainty
Detailed Flow in Destination Country (Receiving)
4-leg settlement process
5-leg settlement process
4-leg settlement model
5-step settlement