Translating To/From ISO 20022 Codes

Even countries that use ISO 20022 for domestic payments may make use of proprietary code sets for status reasons, proxy types, category purpose codes etc. These will need to be translated to the relevant code from the ISO 20022 External Code Set.

Nexus messages must only use codes from the ISO 20022 External Code Set.

Nexus will reject codes that are not listed in the ISO 20022 External Code Set.

When the domestic message format uses proprietary codes, an IPSO has three options:

1. The proprietary codes can be translated to/from the ISO 20022 External Code Set codes, OR

2. The domestic message format can be updated to allow use of the ISO 20022 External Code Set codes, in parallel to proprietary codes, OR

3. The country can migrate to using the External Code Set (this supports cross-border interoperability beyond Nexus)

Code sets to translate

For the currently supported message set, the code sets that may need to be translated to domestic proprietary codes (and vice versa) are:

• ExternalProxyAccountType1Code

• ExternalStatusReason1Code

• ExternalVerificationReason1Code

• ExternalClearingSystemIdentification1Code

• ExternalCategoryPurpose1Code

• ExternalPurpose1Code.

Defining the code translation maps

For each code set, two types of translation map are required:

• Inbound, from the ISO 20022 code list to the domestic equivalent

• Outbound, from the domestic code list to the ISO 20022 code list equivalent

The mapping rules are as follows:

• Rule 1: Every code in the input list must unambiguously map to one (and only one) code in the output list.

  • Consequently, a specific code in the input list cannot map to multiple codes in the output list. This rule is to prevent ambiguity about how the code should be translated.

• Rule 2: Multiple codes in the input list can map to the same code in the output list

• Rule 3: Not every code in the output list needs to have a corresponding code on the input list. (See “Restricting a code set” below.)

The diagram below shows examples of each of these cases.

Rules for mapping ISO 20022 code sets to domestic code sets, and vice versa

When doing this mapping, efforts should be made to maintain the level of specificity and granularity between the domestic and ISO 20022 code list.

Restricting the code set

OUTBOUND translation map (Domestic Format > Nexus ISO 20022)

• The domestic list (input list) may be restricted to a subset of the full list

  • PSPs in a jurisdiction can be instructed to use only the relevant subset of domestic codes that are likely to apply to Nexus payments

• The ISO 20022 list (output list) may be restricted

  • It is not necessary to use every code in the ISO 20022 code list. This means that some ISO 20022 output codes will have no corresponding domestic input code (in the outbound translation map).

INBOUND translation map (ISO 20022 > Domestic)

• The ISO 20022 External Codes list (input list) must not be restricted

  • Every ISO 20022 input code in the required code set must be mapped to an output code in the domestic list

    • This is because Nexus cannot restrict other jurisdictions’ use of the full ISO 20022 code set, and so it is possible that an inbound payment could use any of the ISO 20022 codes in a particular code set

  • It is acceptable to manually map the codes most applicable to Nexus payments, and then select a default “other” code for all other ISO 20022 codes.

• The domestic code list (output list) may be restricted

  • It is not necessary to use every code in the domestic list. So some output codes will have no corresponding input code.

  • The domestic list could be restricted to codes that are relevant to Nexus use cases.

Specific issues: translating Proxy codes

Nexus acmt.023 and acmt.024 messages uses codes from the ISO 20022 External Code Set. For example, the ExternalProxyAccountType1Code for mobile phone number is “MBNO”. (Domestically, some countries use “MSISDN” (the technical term used in telecoms for a mobile number) or a numerical code such as “01”.)

• For the Inbound Proxy Resolution Request (ie. a proxy resolution request initiated in another country, relating to a Recipient in your country), the ExternalProxyAccountType1Code can be translated to your domestic equivalent. For example, MBNO could be translated to the domestic “MSISDN” so that it can be understood by the Domestic Proxy Directory.

  • (Alternatively the Domestic Proxy Directory could be adapted to understand that MBNO and MSISDN are the same type of proxy.)

• However, special care is required for the Outbound Proxy Resolution Request (a request initiated by a Sender/Debtor in your country relating to a Creditor in another country):

  • The Source PSP will use the Nexus APIs to retrieve the full list of proxy types available in the Destination Country; this API will return the proxy types with associated ExternalProxyAccountType1Codes.

  • These codes should not be translated to the domestic equivalent. This is because the Destination Country may support proxy types that are not supported in your country, and therefore there will be no domestic equivalent to translate to.

The domestic message format must support the full set of ISO 20022 ExternalProxyAccountType1Codes: This means that the domestic message format must be adapted to allow all ExternalProxyAccountType1 codes as valid values.

Example

Email addresses can be used as proxies in Indonesia, but not Singapore.

If a Singaporean wishes to send a payment to Indonesia using the Recipient's email address, the Singaporean IPS must accept the ExternalProxyAccountType1Code EMAL as a valid proxy type, even though they would not recognise it as a valid proxy code for domestic payments. The Source PSP must ensure that it does not reject the email address given as an invalid proxy.

Specific issues: translating Purpose Codes

If a country uses domestic Purpose or Category Purpose (P/CP) codes, these codes must be mapped and translated to the ISO 20022 External Code Set.

Regulator-led definition of translation maps

Nexus strongly recommends that the mapping for both the Category Purpose Code and the Purpose Code to the domestic purpose code list should be defined by - or at least approved by - the local regulator, to:

• ensure standardization of the mapping across all domestic PSPs

• avoid duplication of effort by domestic PSPs

• alleviate worry by PSPs and/or the IPS about misjudging equivalence of domestic and ISO 20022 codes.

A standard mapping provided by the regulator is also useful for other non-Nexus cross-border payments and could lower costs of migration to ISO 20022 across the industry.