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

Key Points

PreviousManaging LiquidityNextAccounts & Relationships

Last updated 8 months ago

This guide describes:

  • how Nexus payments are processed

  • how fees are handled by each participant

  • the obligations for the different participants when sending and receiving Nexus payments

  • what the IPSO must do to process Nexus payments from a Source (sending) as well as a Destination (receiving) perspective

  • how errors and exception scenarios are resolved

60-SECOND SUMMARY

Nexus payments are processed through the domestic instant payment systems in the Sender and Recipient’s countries. All funds movement takes place within the two IPS.

Nexus does not maintain any accounts, hold any funds, track balances or obligations on behalf of PSPs.

Nexus does not connect to or interact with the high-value real-time gross settlement systems of central banks.

Payment Process:

  • Within the Nexus payment flow, a payment is cleared and settled in both the Source Country and the Destination Country sequentially.

  • Failures at any point will lead to the payment being reversed and funds returned to the Source PSP and Sender.

Compatibility with different IPS settlement models:

  • Nexus is compatible with different domestic settlement models, including deferred net settlement and real-time gross settlement in central bank money.

  • Nexus is compatible with both instant payment clearing and settlement processes. (In a 5-leg payment, an additional confirmation of settlement message is sent to the Creditor Agent.)

Ensuring certainty of settlement: In all cases Nexus requires that each IPS ensures settlement certainty, so that:

  • (a) Nexus payments will always be honoured, even in the event of the insolvency of any participant while the payment is being processed, and

  • (b) Nexus payments can be reversed in the case that any participant rejects the payment instruction (for any reason).

Certainty of settlement can be ensured through any effective mechanism, including: immediate transfer of central bank money; pre-funding; funds reservation; or loss-sharing agreements.

Use of ISO 20022: Nexus exclusively uses ISO 20022 standard messages (and APIs) to communicate with IPSs. IPSs who do not use ISO 20022 for domestic messages must translate those messages according to the Nexus guidelines before sending messages to Nexus, and after receiving messages from Nexus. Nexus does not provide a translation service; this must be handled by the IPS. See Messaging & Translation for further detail.

Exceptions and disputes: Nexus provides a Service Desk to help tracking of investigations, recall requests and disputes. In the first release of Nexus, these cases must be managed manually. In a future release, Nexus will add support for the relevant ISO 20022 messages to enable these cases to be processed via automatic communication between each PSP’s systems (although human intervention may still be needed to make decisions based on the information provided through these messages).

Message tracking: Every pacs.008 payment instruction must have a Unique End-to-End Reference (UETR) to allow tracking and investigation of the payment. If the Source PSP does not add this UETR, it must be added by the IPS before the message is sent to Nexus. See

4-step as well as 5-step
Message and instruction identification