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
  • Cases where the Source PSP can provide their own FX
  • Process when the Source PSP acts as FXP
  • Preparing the pacs.008 payment instruction
Export as PDF
  1. Payment Processing

Payment setup for PSPs who provide their own FX

PreviousSpecial ScenariosNextUnsuccessful Payments (Exceptions)

Last updated 8 months ago

Cases where the Source PSP can provide their own FX

Some Source PSPs may be able to act as an FX Provider to themselves. This is possible where the Source PSP holds an account with a Destination Settlement Access Provider, so that funds can be paid from that account to the Destination PSP.

Specifically, a PSP can act as FXP for a specific payment if:

  • For this specific payment, the Source PSP holds the Destination Currency in an account at a member of the Destination IPS

  • The institution that provides this account is registered as a Settlement Access Provider with Nexus and is able to participate in the payment processing flow (eg receiving and reviewing the pacs.008 from Nexus and then re-submitting it to the Destination IPS) - see Settlement Access Provision.

  • The Source PSP has informed Nexus that it owns that account at the Destination SAP and has authority to issue payment instructions against that account

These conditions apply in three scenarios:

  • The Source PSP holds an account at the Destination SAP, which is a different entity, (Scenario 10 below) OR

  • The Source PSP is also a member of the Destination IPS, and so also acts as Destination SAP to itself. However, the Recipient is a customer of another PSP (so the Destination PSP is a separate entity from the Source PSP) (Scenario 11 below), OR

  • The Source PSP and Destination PSP are actually the same entity (in different countries), and that entity is a member of both local IPS. (Scenario 12 below).

(Note: in the last two scenarios, the Source PSP may be able to bypass Nexus and make the payment directly from their own account in the Destination Country. However this requires building internal systems that perform much the same function as Nexus, so may not be the preferred option for many financial institutions.)

Process when the Source PSP acts as FXP

When the Source PSP wishes to act as FXP to itself:

  • The Source PSP does not need to request a quote from Nexus, and does not need to include a quote ID in the pacs.008 payment instruction.

  • The Source PSP can define any exchange rate they want. (The exchange rate specified will be used to calculate how much will be debited from the Source PSP’s account at the Destination SAP.)

  • The Source PSP MUST ensure that the Sender still has certainty over what will be credited to the Recipient by following the process below.

Preparing the pacs.008 payment instruction

  • The Source PSP will prepare a pacs.008 payment instruction which defines the exchange rate set by the Source PSP. There will be no Nexus FX Quote Id, since the Source PSP is not using a third-party FXP.

    • The Source PSP can define any exchange rate in the pacs.008 payment message. Before the payment is forwarded to the Destination Country, Nexus will apply this exchange rate to the Interbank Settlement Amount (in the Source Currency) to get the Interbank Settlement Amount in the Destination Currency.

Note that Nexus will have no way of validating that the Source PSP entered the intended exchange rate. If the Source PSP enters the exchange rate that they did not mean to, it will still be applied to the currency conversion calculation.

  • The Source PSP must call the GET /fees-and-amounts/ API to establish the amount that will be credited to the Creditor Account at this exchange rate. (Normally the GET /quotes API would calculate these values automatically, but it is not being called in this case.)

The Source PSP must not change the exchange rate after calling the GET /creditor-agent-fee/ API. Doing so will mean that the amount actually credited to the Creditor is different from the amount shown to the Sender before the payment was made.

  • The Source PSP must define the Intermediary Agents in the pacs.008 as follows:

    • Interbank Settlement Amount: set to the sourceSapAmount from the response from the GET /fees-and-amounts/ API

    • Intermediary Agent 1 = The Source PSP themselves

    • Intermediary Agent 1 Account = The Source PSP's internal account number that they use for recording Nexus payments

    • Intermediary Agent 2 = The Destination SAP at which the Source PSP holds an account

    • Intermediary Agent 2 Account = The Source PSP’s account at the Destination SAP

    • Charges Type = “SLEV”

    • Charges Amount = the Charges Amount response from the GET /creditor-agent-fee/ API