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
  • 2. Destination PSP
  • 3. Nexus -> Source IPS -> Source PSP
Export as PDF
  1. Addressing & Proxy Resolution
  2. Proxy & Account Resolution Process

Step 3: Account Resolution Messaging Sequence

PreviousStep 2: Proxy Resolution Messaging SequenceNextStep 4: Source PSP processes the results

Last updated 7 months ago

At this step, Nexus has access to account details for the Recipient, from one of two sources:

  • An acmt.023 message from the Source PSP, which includes the Account Identification and Financial Institution Identification provided by the Sender, OR

  • An acmt.024 response from the Destination Proxy Directory, which includes the account details associated with the proxy provided by the Sender.

If the Destination PSP is enabled to process acmt.023 requests, Nexus will send an updated acmt.023 to the Destination PSP to get verified information about the Recipient directly from the Destination PSP, as follows.

Supporting account resolution is optional for each PSP, and Nexus would be aware of which PSPs are willing and able to support account resolution requests. Nexus would not send account resolution requests to PSPs that are unable to process them.

1. Nexus

Nexus will:

  • look for the Agent Id in the Agent > FinancialInstitutionId element

  • check whether that Agent is reachable through Nexus

  • check whether the Agent is able to process account resolution requests. (Not all PSPs will be able to; this information will be recorded by Nexus when a new PSP is onboarded.)

  • If the Destination PSP can accept account resolution requests, Nexus will:

    • update the Assignee for the message to the Destination PSP

    • forward the acmt.023 request message to the Destination PSP (via the IPS that is connected to that Agent).

  • If the Destination PSP cannot accept account resolution requests:

    • If the Sender originally provided account details, Nexus will prepare an acmt.024 with the Report > Verification element set to “false” (since account resolution was not possible) and the appropriate Reason code (proposed to be AB08 – Offline Creditor Agent).

2. Destination PSP

The Destination PSP should use the account ID provided to look up the corresponding account.

  • If the account is active, they should prepare an acmt.024 response and add (to the UpdatedPartyAndAccountIdentification block) the following information:

    • 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 in the element UpdatedPartyAndAccountIdentification > Party > Name

    • a display name that can be shown to the Sender to allow them to confirm 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.

      • The Destination PSP is responsible for masking the name.

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

Note: this is a non-standard use of Account > Name, which should normally describe the name of the account rather than the account holder. Unfortunately, the acmt.024 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.

In addition, if the Destination PSP can supply some or all of the following information will support more efficient sanctions screening, with fewer false positive alerts:

  • Address

  • Date and Place of Birth

  • The Destination PSP should now prepare an acmt.024 response and send it to Nexus. The flow diagram below explains how the Destination PSP should prepare the message.

3. Nexus -> Source IPS -> Source PSP

In some jurisdictions, PSPs will be unwilling to share any information about the Recipient/Creditor before a payment is initiated. In this case, an alternative form of verification (often used in Europe) is to ask the Sender to provide information about the Recipient, and then ask the Destination PSP to confirm whether or not that information is accurate. This "comparison" or "matching" process will be developed for Nexus in a future phase of development.

If not, Nexus will prepare an actm.024 with the Report > Verification element set to “false” (since it is not possible to proceed with the payment) and the appropriate Reason code (AGNT, Incorrect Agent – see ).

If the Sender originally provided a proxy, Nexus will forward the acmt.024 that was received from the Destination Proxy Directory in

If the account does not exist or is inactive, they should return an acmt.024 with the Report > Verification element set to “false” and the appropriate Reason code (such as AC01, AC04, AC06 – see ).

Nexus will forward the acmt.024 response (from the Destination PSP) to the Source PSP, via the IPS. See .

Step 2
Step 4
Error codes
Error codes
Account resolution flow diagram (click to expand)
Flow diagram: preparation of acmt.024 response by the Destination PSP