Adherence to CPMI Harmonised ISO 20022 Data Requirements

Nexus is aligned as much as possible with the latest CPMI ISO 20022 Harmonisation Requirements for cross border payments, as well as the CBPR+ guidelines. In case of conflicts, the CPMI Harmonised Data Requirements is considered to overrule the CBPR+ usage guidelines.

Where the Nexus message specification does not specify the usage of a particular element, PSPs should follow CPMI guidelines. If the CPMI guidelines do not specify the usage of a particular element, then CBPR+ guidelines for that element should be followed.

The following table explains how Nexus complies with the CPMI Harmonisation Requirements:

CPMI REQUIREMENT	ADHERENCE IN NEXUS
Requirement 1 – To use the appropriate message for a particular business function	Nexus uses the appropriate ISO 20022 messages for payment exchange and proxy resolution. The first release of Nexus supports the pacs.008, pacs.002, acmt.023 and acmt.024 messages. A future release will add support for the pacs.004 payment return message and the pacs.028 payment status request and camt.029, camt.056 payment recall request messages. Note that the first release of Nexus is not fully compliant with Requirement 1, as it will allow payment returns to be sent using pacs.008, due to local market practice in the countries that initially adopt Nexus. Use of pacs.004 for payment returns will be encouraged in the medium term.
Requirement 2 - To use ISO 20022 externalised codes for payments and payment-related processes	Nexus uses the ISO 20022 External Code set for all status codes, proxy types, purpose codes etc. IPSs may translate domestic codes to/from the ISO 20022 codes, but only ISO 20022 codes are allowed for messages to, from and between the Nexus Gateways.
Requirement 3 – To support/restrict the character set used for ISO 20022 payment messages to current market practice	Nexus has defined its character set in line with the CPMI recommendations.
Requirement 4 – To use a common time convention across all ISO 20022 messages associated with cross-border payments	Nexus uses Universal Time Coordinated (UTC) in all its messages and APIs. This is essential given that many Nexus payments will start and end in different time zones.
Requirement 5 – To include a unique end-to-end reference for all cross-border payments	Nexus uses the Unique End-to-end Transaction Reference (UETR), as defined in the technical standard RFC 4122 (v4) as the unique identification for every cross-border payment.
Requirement 6 – To support transparency on amounts, currency conversions and charges of cross-border payments	Nexus is designed to offer full transparency on the amount that will be debited from the Sender’s account, the effective exchange rate applied, the amount to be credited to the Recipient’s account, as well as any additional fees which will be charged to the Sender as a separate line item on their account. A fee that is deducted by the Destination PSP is calculated in advance and recorded in the payment message, allowing the Sender (Debtor) full transparency on the amount credited to the account of the Recipient (Creditor).
Requirement 7 – To include unique account identifiers to the extent possible	Nexus is designed to enable proxy identifiers to be used to uniquely identify the Creditor (recipient) account , as well as unique account identifiers, such as IBAN or domestic account identifiers.
Requirement 8 – To identify all financial institutions (Fis) involved in cross-border payments in an internationally recognised and standardised way	A Nexus transaction carries all involved Fis in the message, using the business identifier code (BIC) as defined in the ISO 9362 standard, the legal entity identifier (LEI) as defined in the ISO 17442 standard, or a Clearing System Member Id defined by domestic clearing systems.
Requirement 9 – To identify all entities involved in a cross-border payment in a standardised and structured way	Nexus caters for structured address information, as well as the use of BIC and/or LEI for corporate identification, but to mitigate excessive impact at participating PSPs, this is not mandatory in the first release of Nexus.
Requirement 10 – To identify all persons involved in a cross-border payment in a standardised and structured way	Nexus caters for structured address information, but to mitigate excessive impact at participating PSPs, this is not mandatory in the first release of Nexus.
Requirement 11 – To provide a common minimum level of postal address information structured to the extent possible	Nexus uses the latest version of the ISO 20022 message standard, where the key postal address information can be structured in specific elements. Use of the structure postal address elements is recommended but not mandatory, and it is the responsibility of the PSPs and IPSs to provide the information in the correct elements. The Nexus ISO 20022 messages also support unstructured address information.
Requirement 12 – To provide for the transport of customer remittance information across the end-to-end cross-border payment chain by enabling the inclusion of a minimum size of structured or unstructured remittance information with the payment, or to reference such information when sent separately	Nexus caters for both unstructured remittance information up to 140 characters, as well as multiple iterations of structured remittance information.