Mapping types, direct, split, derived and needs care

SWIFT defines several mapping types to describe how MT and MX fields relate to each other, and understanding those types helps an analyst assess the risk of a given translation. A direct mapping is one where a single MT field maps to a single MX element with no loss of data and no change in meaning, for example the amount in field 32A mapping to the Instructed Amount. Direct mappings are low risk, and they can be tested with simple cases. A split mapping is one where a single MT field is split across multiple MX elements, or where a single MX element is split across multiple MT fields. For example, an MT address field with four lines may be split into street name, town, and country elements in MX. Split mappings are medium risk, because the splitting logic must be correct. A derived mapping is one where the MX element is not directly present in the MT message, but can be derived from other data in the message or from reference data. For example, a purpose code in MX may be derived from the remittance information or from the customer type in MT, even though MT does not have a dedicated purpose code field. Derived mappings are higher risk, because the derivation logic may be wrong or may not apply to all cases. A needs care mapping is one where the mapping is complex, ambiguous, or lossy, and where manual review or additional data is needed. For example, mapping a free text field 70 in MT to structured remittance information in MX is a needs care mapping, because the free text may contain invoice numbers, dates, and other data in an unstructured form that cannot be parsed reliably. An analyst should be able to classify each mapping in a migration project by its type, and to prioritise testing and review accordingly. Direct mappings need basic testing, split mappings need testing with varied data, derived mappings need testing with edge cases, and needs care mappings need manual review and possibly a business decision about how to handle the data. A mapping document that lists every field, its type, its rule, and its test cases is a core deliverable of any migration project, and it is the document that operations teams will use when a translated payment fails. Direct mappings are the easy cases, and there are more of them than people expect. The amount in field 32A maps directly to the instructed amount in a pacs.008, with no loss and no change in meaning. The currency code maps directly to the currency element. Field 20 maps directly to the instruction identification. The value date maps directly to the interbank settlement date. Direct mappings are low risk, and they can be tested with simple cases, because the rule is one field to one element with the same value. Split mappings need more care, because one field becomes several elements or several fields become one element. An MT address in field 50K, with four lines of free text, splits into street name, building number, town name, postcode, and country in the structured postal address of a pacs.008. An MT field 70 with several invoice references splits into unstructured remittance information plus structured references. Going the other way, several MX elements combine into one MT field, which is where truncation happens. Derived mappings are higher risk, because the MX element does not exist in the MT message at all. A purpose code in a pacs.008 may be derived from the remittance information or from the customer type in the MT103, even though MT has no purpose code field. A charge bearer code may be derived from field 71A. A local instrument code may be derived from service level information. The derivation logic is a business rule, not a copy, and it can be wrong for edge cases. Needs care mappings are the ones where the translation is complex, ambiguous, or lossy, and where manual review may be needed. Mapping free text field 70 to structured remittance information is a needs care mapping, because the free text may contain invoice numbers, dates, and notes in an order that cannot be parsed reliably. Mapping field 72 sender to receiver information is needs care, because it often carries bank specific codes that have no MX equivalent. Mapping field 77B regulatory reporting is needs care for the same reason. For each needs care mapping, the analyst should record the business decision, the fallback behaviour, and the manual review path, so that operations knows what to do when the mapping cannot be completed automatically.