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
  • Possible approaches to translations in a jurisdiction
  • Option 1: Enhance & Translate the Domestic Message
  • Option 2: Dual formats in parallel
  • Option 3: Full migration
  • Pros and cons of different approaches
  • Translating the message body
Export as PDF
  1. Messaging & Translation

Translation To/From Domestic Message Formats

All messages sent to Nexus or sent from Nexus must be in ISO 20022 format and must comply with the relevant Nexus usage guidelines.

However, not all IPSs use ISO 20022 for domestic payments. Where an IPS does not currently use ISO 20022 (or uses another message type or variation from Nexus), it must translate messages to be compliant with the Nexus Usage Guidelines before it sends the message to Nexus.

Nexus does not provide a message translation service; this must be handled by the IPS.

Possible approaches to translations in a jurisdiction

There are three broad approaches to translation, with pros and cons (which are discussed below).

Option 1: Enhance & Translate the Domestic Message

In most cases it will be necessary to enhance the domestic message format to allow it to carry the additional data required for a Nexus message. This additional data includes the Intermediary Agents (Source and Destination SAP), exchange rate, quote ID and (possibly) the UETR.

The IPS would then need to provide a translation service that translates message from the domestic message format to the Nexus message format, and vice versa.

Option 2: Dual formats in parallel

In this case, the IPSO would adapt the IPS and proxy directory to accept Nexus ISO 20022 messages for cross-border proxy resolution, account resolution and payments, while continuing to accept the domestic message format for domestic payments.

The IPSO would adapt its system to also accept pacs.008 requests and generate pacs.002 responses for Nexus cross-border payments. The Proxy Directory Operator would adapt the proxy directory to accept acmt.023 messages and respond with acmt.024.

PSPs who wish to make cross-border payments through Nexus would need to build in support for pacs.008/pacs.002, but could continue to use the domestic messages for domestic payments. PSPs who did not want to make payments through Nexus would not need to support pacs.008/pacs.002.

PSPs who wish to make cross-border proxy or account resolution requests through Nexus would need to build in support for acmt.023/024, but could continue to use the domestic messages for domestic proxy resolutions. PSPs who did not want to make payments through Nexus would not need to support acmt.023/024.

Option 3: Full migration

The IPSO could mandate that all PSPs migrate to using the ISO 20022 messages for both domestic and cross-border proxy resolution, account resolution and payment instructions.

At some point the domestic proxy resolution messages would be retired/disabled. There may be a coexistence period when both message types are accepted.

Pros and cons of different approaches

There are pros and cons of each approach, as outlined below.

APPROACH

PROS

CONS

Option 1: Full translation of enhanced domestic format

  • Minimises changes for domestic PSPs, who can continue to use the existing domestic messages

  • Translation can be done by the IPSOs, so that individual PSPs do not need to handle translation

  • Changes may still need to be made to the domestic message to support cross-border proxy resolution. If significant changes are needed, it may be better long-term to consider option 3.

Option 2: Dual formats in parallel

  • Changes only need to be made by PSPs when they onboard to Nexus, and do not affect PSPs who do not intend to use the service.

  • PSPs need to support two message types and apply logic to understand which type of message to send depending on the type of payment

Option 3: Full migration

  • Supports move to standardized ISO 20022 messages rather than bespoke ISO 20022-like messages; aligned with the wider payments industry migration to ISO 20022.

  • PSPs who are present in multiple countries only have to support one message type for each function, rather than multiple non-standard domestic formats

  • Requires a significant domestic change program and testing to manage the migration

Translating the message body

Each message will have 2 translation points:

  • Outbound (from domestic format to Nexus format)

  • Inbound (from Nexus format to domestic format)

The table below shows the translation points for each message type currently supported in Nexus:

MESSAGE TYPE

OUTBOUND From Domestic > To Nexus

INBOUND From Nexus > To Domestic

pacs.008

Source IPS > Nexus

Nexus > Destination IPS

pacs.002

Destination IPS > Nexus

Nexus > Source IPS

acmt.023

Source IPS > Nexus

DNexus > Destination IPS

acmt.024

Destination IPS > Nexus

Nexus > Source IPS

For each translation point, the IPSO must define a translation map.

PreviousMESSAGE: camt.054 Bank to Customer Debit Credit NotificationNextTranslating To/From ISO 20022 Codes

Last updated 8 months ago