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
  • Revenue model for FXPs
  • Costs incurred by FXPs
  • Ensuring a competitive FX market
Export as PDF
  1. FX Provision

Revenue model for FXPs

This page relates only to third-party FX Providers.

For Source PSPs that provide their own FX, a different process applies. See Payment setup for PSPs who provide their own FX for details.

Revenue model for FXPs

As described in the Nexus Scheme Rulebook, FXPs are not permitted to:

  • make a deduction from the value of a Nexus payment as it flows through the FXP's accounts, or

  • charge a separate fee (“Invoiced Fee”) to PSPs for the FX service they provide.

Therefore FXPs must set the exchange rates they offer via Nexus at a level that provides for all their own costs plus their expected profit margin.

Costs incurred by FXPs

Key costs incurred by FX Providers will include:

  • The initial technical cost incurred by the FXP to integrate with Nexus

  • The costs of acquiring a particular currency (either purchased via wholesale FX markets, or borrowed, for example if the SAP provides the FXP with a line of credit)

  • The costs charged by Settlement Access Providers for account provision (if the FPX is not a member of the IPS in question)

  • All other costs of operation, onboarding PSPs, regulatory compliance etc.

Ensuring a competitive FX market

Nexus is designed to ensure a competitive FX market:

  • FX Providers are in competition with each other to provide the best exchange rates for a given currency pair.

  • PSPs have free choice over which FXP they use (subject to the requirement that the PSP has completed the initial KYC and onboarding process with that FXP - see Onboarding PSPs)

  • When an FXP posts a quote to Nexus, they are informed of the current leading market rate for that corridor (but not the FXP offering that rate), so they can assess whether the rates they offer are competitive against the market as a whole.

To have competitive pricing, there needs to be more than one FX Provider for a specific corridor. Without this, the sole FX Provider will have a monopoly on that corridor. Rates in a monopoly corridor will be less competitive, although users could switch to using other payment methods, so there is still some pressure on the FXP to offer rates broadly in line with the wider FX market.

The API credentials given to third-party FXPs will not allow them to use the GET /quotes/ API and so they are unable to see the full breakdown of rates offered by their competitor FXPs.

FXPs who are also PSPs will have two separate sets of API credentials and must not share the information from the GET /quotes/ response between the payments and FX/Treasury departments.

PreviousObligations & ComplianceNextRates from Third-Party FX Providers

Last updated 8 months ago