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. FX Provision

Key Points

This section describes:

  • how FX conversion can be provided either by the Source PSP (in certain cases) or by third-party FX Providers (FXPs)

  • how third-party FXPs submit rates to Nexus

  • how Nexus uses these rates to generate quotes and supply those quotes to PSPs

  • the obligations on third-party FX Providers

  • how the FX rate is validated when Nexus processes a payment

60-SECOND SUMMARY

  • Every cross-border, cross-currency payment requires an actor who is willing and able to exchange one currency for another. In Nexus, the entity providing this service plays the role of FX Provider (FXP).

  • In some cases the Source PSP will act as FX Provider for its own payments. This can happen when:

    • the Source PSP is a participant in both the Source IPS and the Destination IPS for a specific corridor, or

    • the Source PSP holds the destination currency in an account with another PSP in the Destination Country, and that PSP is willing to act as Settlement Account Provider (described later) to the Source PSP.

  • When a Source PSP acts as an FX Provider to itself, it can determine the FX rate for each payment and specify this FX rate in the payment instruction. It does not need to inform Nexus of the FX rate in advance.

  • In other cases, the Source PSP will make use of a third-party FX Provider. A third-party FX Provider is any financial institution who provides FX conversion for the payments of another PSP. Source PSPs will need to use third-party FXPs when:

    • the Source PSP is not a participant in the Destination IPS, and

    • the Source PSP does not hold the destination currency in an account in the Destination Country.

  • Third-party FXPs would be regulated financial institutions that are willing to accept the Source Currency from the sender and pay out the Destination Currency to the recipient.

  • A third-party FX Provider must be a licensed and regulated entity but does not necessarily need to be a bank or non-bank Payment Service Provider.

  • Third-party FX Providers must inform Nexus of the current rates at which they are willing to exchange one currency for another.

    • Nexus does not ask third party FXPs to bid on individual payments. Instead, Nexus uses the rates provided by FXPs to generate quotes which are provided to PSPs at the point that a Sender sets up a payment.

    • An FXP may choose to improve their rates for larger payments. For each currency, the FXP will inform Nexus of the tiers and thresholds at which better rates start to apply, and by how much the rate must be improved. Nexus will automatically calculate any improvements for larger payments and apply them to the quote given to the Source PSP.

    • An FXP may choose to improve rates for specific PSPs. The FXP will inform Nexus of the PSPs it wishes to deal with, and by how much rate must be improved for that FXP. Nexus will automatically calculate any improvements applicable to each PSP.

  • Each payments corridor between two countries and currencies must have one or more third-party FX Providers, who are in competition with each other to provide the best rates.

  • Settlement Account Providers (SAPs) are existing PSPs who are willing to provide accounts to:

    • third-party FX Providers who are not members of the IPS, and/or

    • Source PSPs in another country.

  • SAPs are important because they ensure that FX provision in Nexus is not limited to large international banks who are members of two or more instant payment systems. SAPs help to open FX provision in Nexus to a wider range of financial institutions, including non-bank, non-PSP financial institutions who are not eligible to become IPS members.

  • There may be multiple FXPs per IPS and per corridor, and multiple SAPs per IPS. The FXP is responsible for selecting the SAP they wish to use.

  • Scheme adherence: Third-party FX Providers (ie those who provide FX to other PSPs) must be direct participants in the Nexus scheme. (Source PSPs who only provide FX conversion for their own payments – but do not act as a third-party FX Provider to other PSPs – may remain as indirect participants in Nexus, as per any other PSP.)

  • Fees & Costs: Third-party FX Providers need to offer an FX rate that is sufficient to cover all their own costs and required profit margin. FXPs are not permitted to charge a fee or make a deduction from the value of the payment transferred.

    • If the FXP holds accounts at SAPs, it will need to pay fees to those SAP; these fees are negotiated bilaterally between the FXP and the SAP.

  • Communication with Nexus: FXPs communicate with Nexus Gateways directly, sending API requests via HTTPS over the internet.

PreviousOnboarding a Proxy Directory Operator onto NexusNextRole of the FX Provider

Last updated 8 months ago