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
  • 1. Nexus (Message Transformation)
  • 2. Nexus -> Destination Proxy Directory
Export as PDF
  1. Addressing & Proxy Resolution
  2. Proxy & Account Resolution Process

Step 2: Proxy Resolution Messaging Sequence

PreviousStep 1: Sender inputs proxy or account detailsNextStep 3: Account Resolution Messaging Sequence

Last updated 5 months ago

Following on from , assuming the Sender entered a proxy, the Source PSP will send Nexus an ISO 20022 message that includes the proxy details.

1. Nexus (Message Transformation)

Nexus will:

  • look for the Country Code in the Assignee > Agent > PostalAddress > Country element

  • identify the relevant proxy directory in that country, and

  • update the Assignee to the BIC of the proxy directory (or its parent IPS Operator). This is the only change that is made to the message.

2. Nexus -> Destination Proxy Directory

Nexus will send the proxy resolution request to the Destination Proxy Directory Operator.

The message will be formatted as an ISO 20022 acmt.023 message. The PDO must be able to accept the message in this format. If the domestic proxy resolution message format is different, the IPSO is responsible for translating the message from the Nexus acmt.023 to the domestic format message before processing the proxy resolution request (See Messaging & Translation for further details.)

Scenario 1: No associated proxy

The Destination Proxy Directory should first check if the proxy is associated with an account.

Scenario 2: Proxy successfully resolved

If the proxy successfully maps to an account, the proxy directory should prepare and return an acmt.024 response message that contains, at a minimum:

  • Account details, in the form of either:

    • an IBAN, OR

    • the Financial Institution Identification (eg BIC) AND the Account Identification of the linked account

  • the real name associated with the account (wherever possible) – this will be used by the Source PSP when sanctions screening the Recipient.

    • This should be stored in the element UpdatedPartyAndAccountIdentification > Party > Name.

    • Note that wherever possible, the full real name should be returned, as this information supports accurate and automated sanctions screening.

  • a display name that can be shown to the Sender to allow them to confirm that the account holder is the intended Recipient. This could be the full name (where privacy and data protection rules allow this to be shown to the Sender) or a partially obscured name, depending on the proxy service.

    • This value should be in the element UpdatedPartyAndAccountIdentification > Account > Name

Note: this is a non-standard use of the Account > Name element, which should normally describe the name of the account rather than the name of the account holder. Unfortunately, the acmt.024 message structure does not currently have a dedicated element for a display name that can be shown to the Sender but which may be different from the real account holder name.

The proxy directory should send this response back to the Nexus.

If there is no associated account, the proxy directory should respond with an acmt.024 response including the appropriate error code in the Report > Verification > Reason > Code element. (See for further information.)

See below for details on how Nexus will handle this response.

Step 3
Step 1
acmt.023
Error codes
Proxy resolution flow diagram