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
  • Structure of the acmt.024 Identification Verification Response V03
  • acmt.024 for Proxy Resolution
  • acmt.024 for Account Resolution
  • Message transformation by Nexus
  • Error codes
Export as PDF
  1. Messaging & Translation

MESSAGE acmt.024 Identification Verification Report

PreviousMESSAGE acmt.023 Identification Verification RequestNextMESSAGE: pacs.008 FI to FI Customer Credit Transfer

Last updated 7 months ago

The acmt.024 is the response to the acmt.023 proxy resolution or account resolution request.

For further detail on each element in the acmt.023 and acmt.024, please refer to the Message Guidelines (Excel).

Structure of the acmt.024 Identification Verification Response V03

The acmt.024 is also split into two blocks:

  • Similarly to the acmt.023 message, the acmt.024 the Assignment block contains information about who is making the request and providing the response

    • Creator remains the same as the acmt.023, describing the Sender who made the original proxy or account resolution request

    • First Agent remains the same as the acmt.023, describing the Source PSP

    • Assigner changes to the Destination Proxy Directory Operator

    • Assignee changes to the Source PSP (ie is the same as First Agent)

  • The Report block contains the information about the Recipient:

    • Verification is either true (if the payment can proceed) or false (if any error means that the payment cannot proceed)

    • Reason will only be filled if Verification is false, and will contain an error code explaining why the verification failed (eg proxy not registered). (See Error codes below).

    • OriginalPartyAndAccountIdentification is an exact copy of the “PartyAndAccountIdentification” from the acmt.023

    • UpdatedPartyAndAccountIdentification is where the updated information (from either the Proxy Directory or the Destination PSP) is provided

acmt.024 for Proxy Resolution

For a proxy resolution request, the Destination PSP should add the following information to the UpdatedPartyAndAccountIdentification block:

  • … > Party > Name – this is the verified name of the account holder, in full. It can be used by the Source PSP for sanctions screening.

  • … > Account > Identification > IBAN or Account > Identification > Other > Identification - this identifies the specific account of the Recipient/Creditor

  • … > Account > Name (in Nexus this is the display name of the Recipient, which can be shown to the Sender)

  • … > .Agent > FinancialInstitutionIdentification > BICFI (or Agent > FinancialInstitutionIdentification > ClearingSystemMemberIdentification > MemberIdentification, for non-BIC IDs)

acmt.024 for Account Resolution

For an account resolution, the Destination PSP should add the following information added to the UpdatedPartyAndAccountIdentification block:

  • … > Party > Name

  • … > Party > PostalAddress

  • (Optional) Party > Identification > PrivateIdentification > DateAndPlaceOfBirth

    • This is optional but can help to reduce false alerts against sanctions screening lists

  • Account > Name

    • To be used as the display name shown to the Sender, to enable confirmation of payee. This display name can be partially masked.

Message transformation by Nexus

When an acmt.024 travels through Nexus, Nexus will update the Assignee to the Id of the Source PSP. This is the only change.

Error codes

If there is an error either with proxy resolution or account resolution, an acmt.024 should be sent:

  • The element … > Report > Verification should be set to false

  • The element … > Report > Reason > Code should be set to the appropriate error code from the table below

Error codes are taken from the ISO 20022 External Code Set.

The standard acmt.024 Message Guidelines (Excel) specify that error codes must be from the ExternalVerificationReason1Code set, but there are only 3 codes in this set and they are insufficient. For that reason, we propose to also permit codes from the ExternalStatusReason1Code set, with the following limited code set:

Table: ISO 20022 Error Codes for use in Nexus acmt.024

Code Type

Code Value

Code Name

Nexus-specific meaning

Proxy / Account Resolution

ExternalVerificationReason1Code

AC01

Incorrect Account Number

Account number provided does not match any account held by the Creditor Agent

Account

ExternalStatusReason1Code

AC04

Closed Account Number

Account number specified has been closed on the Receiver’s books

Account

ExternalStatusReason1Code

AC06

Blocked Account

Account specified is blocked, prohibiting posting of transactions against it.

Account

ExternalVerificationReason1Code

AGNT

Incorrect Agent

The PSP exists but is not onboarded with Nexus, so cannot receive Nexus payments. Alternative payment rails may work. (Contrast to RC07 Invalid Creditor BIC)

Both

ExternalStatusReason1Code

AB08

Offline Creditor Agent

Creditor Agent is not able to respond to account resolution requests, either permanently (they don’t have the capability) or temporarily (they are offline or have a technical issue).

Account

ExternalStatusReason1Code

BE23

Account Proxy Invalid

Proxy is not registered (No account is associated with the proxy provided)

Proxy

ExternalStatusReason1Code

DUPL

Duplicate Request

Both

ExternalStatusReason1Code

FRAD

Fraudulent Origin

Proxy directory, IPSO or Destination PSP suspects abuse of the proxy resolution service by the Sender and is refusing additional requests from this Sender.

Both

ExternalStatusReason1Code

MD07

End Customer Deceased

Both

ExternalStatusReason1Code

RC06

Invalid Debtor BIC Identifier

BIC provided is not a valid BIC.

Both

ExternalStatusReason1Code

RC07

Invalid Creditor BIC Identifier

The FI ID is not valid or blank. Could be used for account resolution or proxy resolution where the Creditor Agent BIC is required, such as the Philippines. (In contrast to AGNT, RC07 means that the FI ID is incorrect and the PSP is not found.)

Both

ExternalStatusReason1Code

RR01

Missing Debtor Account Or Identification

The Destination Country requires further information about the Sender in order to pre-screen the Sender.

Both

ExternalStatusReason1Code

RR02

Missing Debtor Name Or Address

The Destination Country requires further information about the Sender in order to pre-screen the Sender.

Both

At least Country and Town Name should be provided here, to support with sanctions screening and other compliance checks and to ensure alignment with the .

CPMI’s ISO 20022 harmonization requirements
Main blocks of the acmt.024 Identification Verification Request