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
  • Only ISO 20022 messages are accepted
  • Accepted Message Set
  • Version
  • Backwards compatibility
  • Character Set
  • Message Validation
Export as PDF
  1. Messaging & Translation

General Usage of ISO 20022

PreviousKey PointsNextAdherence to CPMI Harmonised ISO 20022 Data Requirements

Last updated 7 months ago

This guide defines the message standards that consists of message elements:

  • required in the Nexus Scheme Rulebook as business requirements

  • needed for processing by Payment Service Providers (PSPs) and Instant Payment Systems (IPS)

These message elements define the Nexus service and are denoted in the specific ISO 20022 Nexus message guidelines. This section describes the relevant Nexus requirements, such as the use of the message element, its components or the values that must be used. Usage rules, for example, may indicate limits on the number of repetitions, or code value restrictions, while format rules may be used to indicate the allowable combinations of components of a message element.

Only ISO 20022 messages are accepted

Nexus expects and will only accept the Nexus-standard ISO 20022 messages (and JSON APIs as defined by Nexus). These messages are based on the and CBPR+ usage guidelines. The Nexus Usage Guidelines adds additional requirements necessary for processing Nexus payments.

Where an IPS community either (a) does not support ISO 20022 messages, or (b) uses elements differently than defined in the Nexus usage guidelines, then the IPSO is responsible for translating messages to be consistent with the Nexus usage guidelines. See Translation To/From Domestic Message Formatsfor further detail.

Accepted Message Set

With the exception of some JSON API calls, most communication through Nexus is done using messages following the ISO 20022 standard. The following ISO 20022 messages are implemented in the first release of Nexus:

  • FI to FI Customer Credit Transfer

    • This is the basic payment instruction

  • FI to FI Payment Status Report

    • This is the payment status report returned in response to a pacs.008

  • Identification Verification Request

    • Used for proxy resolution and account resolution requests – see Addressing & Proxy Resolution.

  • Identification Verification Response

    • Used for responses to proxy resolution and account resolution requests.

The following messages are not implemented in the first release of Nexus, but are on the roadmap for future releases:

  • pacs.028 FI to FI Payment Status Request

    • Request for an update on the status of a previously sent pacs.008 payment instruction

  • camt.056 FI to FI Payment Cancellation Request

    • In Nexus, this would be used to request the return of a previously completed payment. (It is not possible to request the cancellation of a payment that is currently being processed.)

  • camt.029 Resolution of Investigation

    • This is the positive or negative response sent in reply to a camt.056 Payment Cancellation Request

    • This is a payment instruction used to return an earlier payment. It is very similar to the pacs.008 message structure. A pacs.004 message references the original pacs.008 so that the PSP receiving the returned payment can reconcile it against the original payment.

Version

Nexus uses the 2023 version of the ISO 20022 XML message standards. This is version 11 for the pacs.008 and version 13 for the pacs.002.

Backwards compatibility

Nexus will not support backward compatibility. Any translation between previous versions and the current version will be the responsibility of the IPSO. Nexus will define specific cut-over moments when new versions are introduced.

Character Set

The efficient processing of cross-border payments depends on the use of a common character set so that all participants in the processing chain will be able to understand and interpret the information. Otherwise, payments risk being delayed or even returned.

Following CPMI harmonization requirements, Nexus prescribes the use of a restricted character set in its cross-border payment messages to the currently agreed Latin character set: lower case characters a–z, upper case characters A–Z, numeric characters 0–9, complemented with the following additional characters for a limited selection of data elements:

/ - ? : ( ) . , ’ + ! # & % * = ^ _ ` { | } ~ " ; @ [ \ ] $ > <

References, identifications and identifiers must respect the following:

  • Content is restricted to the Latin character set as defined above

  • Content must not start or end with a forward slash ‘/’

  • Content must not contain a double forward slash ‘//’

Message Validation

Messages sent to Nexus will be validated against the requirements in the Nexus message usage guidelines. Messages will fail validation in the following cases:

  • The message does not conform to the Nexus XSD validation. In this case, Nexus will reject the message with error code FF01.

  • An element that is defined as “Mandatory” in the Nexus usage guidelines is empty or null, or the entire element is missing from the message structure. In this case, Nexus will reject the message with error code CH21.

  • An element that requires a code from the ISO 20022 External Code set in the <Cd> element instead uses the <Prtry> (Proprietary) element. In this case, Nexus will reject the message with error code CH21.

  • An element that requires a code from the ISO 20022 External Code set uses a code that is not in the External Code Set. In this case, Nexus will reject the message with the applicable error code.

Payment Return

CPMI ISO 20022 harmonisation requirements
pacs.008.001.11
pacs.002.001.13
acmt.023.001.03
acmt.024.001.03
pacs.004