Table of contents
What is in-flow translation and why is it important?
As part of the migration to ISO 20022 for cross-border payments and reporting (CBPR+), Swift provides the In-flow translation service to allow for the receipt of both FIN MT and ISO 20022 MX, also referred to as multi-format.
This approach aims to facilitate the integration in the receiver's application environment in cases where not all applications can (yet) support the ISO 20022 MX format.
What is the difference between the In-flow translation service, Transaction Manager, and local translations with Swift Translator?
The in-flow translation service allows for the receipt of both FIN MT and ISO 20022 MX, also referred to as multi-format. This approach aims to facilitate the integration in the receiver's application environment in cases where not all applications can (yet) support the ISO 20022 MX format. In-flow translation refers to the translation done centrally at Swift. The outcome of such translation is a multi-format MX message delivered to the receiver. Note that in-flow translation is a point-to-point service, designed to translate from MX to MT format, not the other way around.
The In-flow translation service will continue to include the MT translation as part of multi-format MX messages that are delivered through Transaction Manager.
Transaction Manager will introduce end-to-end transaction management features on top of Swift's messaging services. It introduces a system of records by maintaining a transaction copy and applies business rules across messages related to the same transaction using the same UETR. It mediates between users of different protocols and formats to protect the end-to-end integrity of transaction data – even when intermediaries that still rely on MT are part of an ISO 20022-originated transaction.
Swift Translator is a light-footprint solution for validation and mapping to and from any Swift and non-Swift format. You can find more information here.
What are the messages in scope of the In-flow Translation service?
The messages listed in the table below are in scope of the In-flow Translation service. In-flow translation is gradually made available on FINplus services as per below schedule:
- Pilot future: November 2021
- Pilot current: August 2022
- Live: August 2022 (on an opt-in basis), 20 March 2023 for all FINplus users.
Refer to "Appendix A" from the "In-Flow service overview document.
Note
All translation rules from ISO 20022 to MT approved by the CBPR+ working group are available and published on MyStandards.
Will in-flow translation for CBPR+ be provided after November 2025?
Swift is providing central translation via the In-flow Translation service to ensure interoperability during the coexistence period, starting on 20 March 2023 and ending in November 2025. This enables banks to adopt ISO 20022 at their own pace while early adopters (and their customers) can fully benefit from richer and more structured data.
The MT category 1, 2, and 9 messages supporting cross-border payments and reporting flows will be retired in November 2025. There is currently no plan for Swift to provide the In-flow Translation service beyond November 2025. If at that point, your business requires an extension of translation services to accommodate a longer coexistence of legacy systems, an on-premise translation service could be considered.
Can I opt out of the in-flow translation service when my back office is ISO 20022 native?
You can disable (and re-enable) in-flow translation per FINplus service (that is, Pilot Current, Pilot Future or Live) and for the different eligible CBPR+ messages. For example, you can decide to disable only in-flow translation for reporting messages, or FINplus Pilot Future only.
Remember, in-flow translation is enabled by default. The standard provisioning lead times apply for changing such configuration.
What are the constraints of MX to MT mapping?
The main constraint when translating MX to MT is either data truncation, with data being lost in the translation process as it’s stored in too short a location to hold its entire length, or loss of data because the MX elements have no corresponding fields in the MT message.
The In-flow Translation service provides translation results and indicators to identify where data are truncated due to size limitation (e.g. structured remittance information) or not translated due to lack of field equivalence in MT (e.g. ultimate debtor/creditor)
Will there be data truncation from in-flow translation from camt.053 to MT 940/950? If yes, how to avoid data loss before 2025?
Yes, there will be data truncation from camt.053 to MT940/950 as camt.053 provides room for more data and the current MT format cannot accommodate the same richness. The translation is available only for the basic key elements from Camt.053 to MT940/950.
Please refer to the link here and click on the "Download documentation" button for detailed translation rules. In-flow Translation service provides the multiformat message where the truncated data can be identified from the MX message. Refer to Appendix B of this document.
How can we access the rich data when the data truncation indicator “+” is provided by the in-flow translation service?
For messages originating with rich ISO content (e.g. Structure Address, Remittance…) the inflow translation service will indicate truncation with a “+” sign located at the end of the element or the field where data is truncated. In case an intermediary agent relays the payment with legacy format (MT) the rich content will be truncated.
To support banks’ implementation of the Data Integrity Market Practice Guidance and enable a consistent approach to access additional rich data that might not be transported in legacy format payments, Swift has developed a “Rich Data Access” feature as an enhancement of its Case Management solution and has made it universally available to all relevant Swift users that may require access to rich ISO 20022 data.
Link to Rich Data Access Feature Overview
How the industry is approaching the risk of data truncation during the coexistence period?
To support banks’ implementation and limit the risk of data truncation due to market infrastructures or intermediaries operating with the legacy format, a CBPR+ Data Integrity Market Practice Guidance has been published to identify essential data truncated, defined roles and responsibilities and a format of exchange until Transaction Manager is fully ramped-up.
What is the multi-format MX provided by the In-flow Translation service?
The In-flow Translation service enables customers to receive FIN MT and ISO 20022 MX. The user receives, in the same SwiftNet message, both the ISO 20022 MX and the translated MT: it’s therefore known as a multi-format message. The multi-format is the standard delivery format provided by Swift. Customer can manage preferences (receive the translation yes or no) via a new e-form with granularity per service (FINplus pilot current, pilot future or live) BIC8 or request type. The changes in configuration will follow the standard Swift provisioning cycle and will thus be applied in the next available Swift Maintenance Window. A new e-form will be made available by end of 2022.
The in-flow translation documentation indicates that the translation result code “TRAK” is issued for failure to translate optional ISO 20022 fields as per CBPR+, what is the translation code error or warning associated with failure to translate mandatory fields?
Without the mandatory element, the ISO 20022 MX message will not pass successfully over the network as multiple validations (Message validation, Interface level validation etc.) are in place. An ISO20022 MX message is invalid without the presence of a mandatory element.
Hence in the translation rules all the mandatory elements are accommodated in MT. Also, TRAK is not a code issued in case of failure. It’s a translation result indicating "Translation Almost OK" with a few optional elements dropped as per the definition.
Why is the translation of camt.053 limited to MT 940 and excluding translation to MT 950 is not in scope of the translation service?
Camt.053 to MT540 is in scope of central translation service, It is however not possible to identify if the message must be translated to one or the other MT (nothing in the camt.053 allows that distinction) and since the MT950 is mostly used by Market Infrastructures he CBPR+ working group agreed to only translate the MT940.
