Session 14- Mapping and translation guidelines during coexistence of MT and MX/ISO20022

 Session 14- Mapping and translation guidelines during coexistence of MT and MX/ISO20022 

Basic principles for mapping & translation

Whenever mapping / translating between the various format options during the coexistence phase, the PMPG recommends to apply the mapping scheme as highlighted in the illustration below and the detailed mapping rules described in the following sub-chapters. ISO20022 provides more structured and granular data for the identification of a “party” in the name & address component than the SWIFT FIN F option. Therefore, mapping from MX/ISO20022 to MT address details will naturally lead to a loss of data structure. 

The name and address data for creditor and debtor in ISO20022 use the complex data type PartyIdentification135_2 which is comprised of the simple data type Name, the complex data types Postal Address (PostalAddress24_1) and Identification Party38Choice_2. 

The account details for debtor and creditor are expressed as the complex data type CashAccount38_2. The max number of characters including the account number that this data structure can contain is 819. The current fields 50 & 59 in the MT103 message allow a maximum of 175. In the F option, the number of usable characters without counting the delimiters is 166 (34x for the account number and 4 * 33x for name/address). 

This means the MX party fields can contain 4 times more characters than the corresponding MT fields. This will require field and content prioritization rules when mapping the party content from a source MX message into MT. These mapping rules will apply and truncation issues will occur during the co-existence period only. SWIFT will always deliver the original message to the receiver, however, to facilitate in-house processing, tools will be available to utilize the (central or onsite) translation for the provision of the SWIFT MT equivalent in addition. This will allow the receiver to consult the original ISO20022 message in case data was truncated during the conversion to the SWFIT FIN message.

Mapping table during coexistence of MT and MX/ISO20022

1. Structured MX/ISO20022 > Structured SWIFT FIN

Field mapping from structured MX/ISO20022 to structured MT

Market Practice Guideline #7: Structured customer data elements in MX/ISO20022 should be mapped to the respective sub-field of structured option F of SWIFT FIN. This will allow to preserve a certain level of structure (1/name, 2/address, 3/country/town). 

During this mapping from MX to MT, the data elements belonging to the "Address" and "Town" group will be consolidated, leading to the loss of certain granularity of data. Furthermore, not all data available in the various ISO20022 address elements may fit into the 4*35 lines of the SWIFT FIN format.

 During this mapping from MX to MT, the data elements belonging to the "Address" and "Town" group need to be consolidated, leading to the loss of certain granularity of data. Furthermore, not all data available in the various ISO20022 address elements may fit into the 4*35 lines of the SWIFT FIN format. Whenever data is truncated during this mapping due to space limitation, the indicator "+" must be added by the translation tool at the end of the respective line/data element

– Example for field mapping from structured MX/ISO20022 to structured MT

The mapping will be done based as per the following steps and prioritization of data (see previous page): 

• Step 1: Map XML fields into the appropriate subfields of the F option if no BIC present as per the column "Position in subfield". Use the comma ("," without space) as a delimiter so separate the various available data elements in the sub-fields 2/… (address) and 3/XY/… (town). 

• Step 2: If LEI is present do not use second line for name, truncate if needed using the ‘+’ character at as the last character. Truncate any other line the same way. Mapping rules for LEI element:

o Place LEI on last line of 50F or 59F, if space allows.

o For 50F, insert a 6/XY/LEIC/ before LEI. XY is the country code of the debtor. 

o For 59F, insert a 3/XY/LEIC/ before LEI. XY is the country code of the creditor. 

• Step 3: If LEI not present use two lines for the name and truncate any other line, indicating truncation with the + character 

• Step 4: If no LEI and single line name use two lines for the Country, town etc. 

• Step 5: If no second line for any other field use two lines for the street and building

Example without LEI for 50F:

Example with LEI for 50F:

The ISO country code preceding the "/LEIC/LEI identifier" is not meaningful in this particular context as it is a repetition of the country of the domicile of debtor or creditor. Nevertheless it is aligned with FATF 16 recommendation implementation and allows to maintain a standard interpretation of the field and an automated processing / validation of the payment message. For more information about the LEI ("Legal Entity Identifier), please refer to the discussion papers and industry updates that the PMPG published in this context3 . 

Source - 3 Link to PMPG document centre: https://www.swift.com/about-us/community/swift-advisory-groups/payments-market-practicegroup/document-centre/document-centre 

Field from mapping from structured MT to unstructured MX/ISO20022

The challenge to map structured customer data from structured SWIFT FIN F option to ISO20022 is that the FIN fields are not as granular as the data elements in ISO20022. As a consequence, the data in the FIN subfield "Address" (2/…) and "Town" (3/XY/…) may contain richer content than the target element in ISO20022. For instance, subfield "Address" could contain street name, street number, building name, floor number and many more. A similar challenge exists for the subfield “Town" (data after 3/XY/…) that could contain data such as postal code, district name, country sub-division etc. Therefore, the mapping from structured SWIFT FIN to structured ISO20022 comes with the risk that the data mapped to the designated elements may be polluted by the inclusion of additional data, as shown in the following diagram (not allowed):

Structured customer data in SWIFT FIN (F option) should therefore be mapped into "Name (Nm)" and unstructured "Address line (AdrLine)" elements in MX/ISO20022. In order to keep the transparency and the benefits of the original FIN structure, the mapping of the SWIFT FIN subfields should apply the same structure and include the original qualifiers 2/ for address and 3/ for country and town. Those should be copied and included at the beginning of the respective (two or three occurrences of) AdrLine in ISO.

Mapping rules if LEI can be located in field 50F or field 59F of SWIFT FIN message:

• Field 50F: Locate LEI after 6/XY/LEIC/… and map it to the LEI element in MX/20022 (the information before the LEI can be dropped)

 • Field 59F: Locate LEI after 3/XY/LEIC/… and map it to the LEI element in MX/20022 (the information before the LEI can be dropped

Map unstructured MX/ISO20022 with 2/ and 3/ qualifiers to structured SWIFT FIN

Market Practice Guideline #10: In case not all occurrences of "AdrLine" in the ISO20022 message start with 2/ or 3/, the target format should be the unstructured SWIFT FIN format (K- or no letter option). The mapping of the fields will be as follows: 

• Name: Map to element "Nm" (Name) to line 1 of MT FIN field 50 / 59 option (K- or no letter option) • Address: Map all occurrences of "AdrLine" to the residual lines of MT FIN field 50 / 59

A potential space issue will occur if the data of the ISO20022 business component Debtor or Creditor exceeds the capacity of 4*35 characters in total. Although CBPR+ is restricted to max. 3 occurrences of AdrLine, there could be Market Infrastructures allowing 4 or more occurrences. If the data mapped from unstructured ISO20022 does not fit into unstructured SWIFT FIN, this will be indicated with a truncation sign "+" at the last line of the truncated element/line. The user of the MT message must ensure procedures are in place how to deal with truncated data available in the original MX message.

 
Map unstructured SWIFT FIN to unstructured MX/ISO20022

The mapping of unstructured data from ISO20022 to SWIFT FIN is relatively straight-forward. The main challenge of mapping unstructured customer data from SWIFT FIN to ISO20022 is that the ISO20022 message has a dedicated data element for the Name, even in the unstructured format.

• Name: Map line 1 of MT FIN field 50 / 59 to element "Nm" (Name) 

• Address: Map line by line, 2, 3 and 4 of the SWIFT FIN field 50 / 59 to 

ISO20022 element "AdrLine" (line 2 to first occurrence of AdrLine, line 3 to second occurrence of AdrLine, etc.) Note: There are cases where the name exceeds one line. The above described mapping could therefore lead to the result that a part of the name information will be mapped to the element "AdrLine".