ISO 20022 Programme: In-Flow Translation Service Overview

Download as pdf or txt
Download as pdf or txt
You are on page 1of 34
At a glance
Powered by AI
The document describes SWIFT's in-flow translation service which translates ISO 20022 business messages to their equivalent MT messages. It provides an overview of the translation process and details on handling multi-format messages and translation results.

The document describes SWIFT's in-flow translation service from ISO 20022 business messages to their equivalent MT messages. It provides an overview of the translation process and details on handling issues like missing BIC codes, conflicts between codes, and missing field translations.

Some of the translation result codes mentioned are TROK (translation OK), TRNR (translation not possible), TRFR (translation failure), TRNK (translation not known), and TRAK (translation accepted).

ISO 20022 Programme

In-flow Translation Service Overview

This document describes the multi-format ISO 20022 Business Message containing an embedded equivalent MT.

22 February 2022
Table of Contents

Table of Contents
Table of Contents ...............................................................................................................................2
Preface .................................................................................................................................................3
1 Overview of In-flow Translation ..............................................................................................4
2 Translation of Network Messaging Protocol Related Items ................................................5
3 Multi-format MX.........................................................................................................................7
3.1 Mapping to MT Blocks.............................................................................................................8
3.2 Translation Reporting ............................................................................................................12
3.2.1 Translation Result – TROK .........................................................................................13
3.2.2 Translation Result – TRNR .........................................................................................14
3.2.3 Translation Result – TRFR .........................................................................................16
3.2.4 Translation Result – TRNK .........................................................................................18
3.2.5 Translation Result – TRAK .........................................................................................19
3.2.6 Translation Result with Multiple Translation Result codes .........................................19
4 Handling Multi-format MX in Applications ...........................................................................24
5 Pilot Services and Translation ..............................................................................................25
Appendix A........................................................................................................................................26
Appendix B........................................................................................................................................27
Legal Notices ....................................................................................................................................34

22 February 2022 2
Overview of In-flow Translation

Preface
About this document
This document describes the in-flow translation from ISO 20022 Business Messages to their
equivalent MT.
Intended audience
This document describes In-flow translation service. It should be read by:

• users who wish to gain an understanding of the service


• Application implementers, business analysts and the developers who need
background information on the elements of the service.

Related documentation

• ISO 20022 Customer Adoption Support Page


• From FIN to FINplus Getting Started
• Customer Adoption Guide
• FINplus Service Description
• SWIFTNet Service Description
• SWIFTNet Messaging Operations Guide
• SWIFTNet Link Error Codes
• FIN Operations Guide
• SWIFTNet Network Validation Rules for ISO 20022

22 February 2022 3
Overview of In-flow Translation

1 Overview of In-flow Translation


Introduction
SWIFT have implemented the in-flow translation services as a key interoperability measure
to support the implementation of many to many cross-border payments towards ISO 20022
messaging. "In-flow translation" means the translation that happens during the processing
of the message at SWIFT and as an outcome of that translation, multi-format message is
generated. This service enables customers to receive multiformat message i.e. Both FIN MT
and ISO 20022 MX. This approach aims at facilitating integration in the receiver's
application environment in case not all applications can support the ISO 20022 format
during the co-existence period.
In this document, the term translation refers to an activity at SWIFT whereby SWIFT creates
an MT representation derived from the ISO 20022. . Based on the CBPR+ translation rules,
the values from the different tags of the ISO 20022 message are successfully translated in
the equivalent fields of the corresponding MT message.
The document also explains that data truncation and replacement can happen during this
process and how this is indicated.
The term in-flow refers to translation which occurs on the FINplus interact service
during the message exchange, at a moment after the message has been received by
SWIFT and before it is made available for delivery to the receiver. Translation is invoked
before the message is made ready for reception by the receiver. The sender does not need
to be aware that this translation is happening before the message is received by the
receipient. Both, the ISO 20022 MX message, and the translated MT message are expected
to be received by the recipient as part of one SWIFTNet message (MX), also known as the
multi-format message.

In-flow Translation occurs only in one direction that is, ISO20022 MX to MT. These rules are
not further detailed in this document (Refer MyStandards ). This translation happens for the
receiver who has been provisioned for FINplus Interact Service.

22 February 2022 4
Translation of Network Messaging Protocol Related Items

2 Translation of Network Messaging Protocol


Related Items
Overview
ISO 20022 MX shown as Business Message

The ISO 20022 Business Application Header is mandatory in the translation rules specified in
this document.

Block identifier Block name Description

1 Basic header Identifies message and session information

2 Application header Identifies direction of flow, message type, peer


information and network instructions such as
priority

3 User header Contains additional information that is not session


related

4 Text The standardized message

5 Trailers Contains security related information or special


circumstances related to the message handling

The format includes network specific items and information provided by the creator of the
message.
The translation towards a FIN MT is described in section "Multi-format MX".

22 February 2022 5
Translation of Network Messaging Protocol Related Items

Translation scope
The translation scope is the ISO 20022 MX message format only and the source of the
translated messages are based on the CBPR+ usage guidelines (UG). Translation copes
with the CBPR+ UG schemas and rules and the MT formats and rules . The network-related
parts are not translated, except those that are business wise important. This applies to the
session-related information or the retransmission done by SWIFT.

22 February 2022 6
Multi-format MX

3 Multi-format MX
Translation into three XML comments
The three XML comments added by SWIFT at the end of the RequestPayload just before
the closing tag of the RequestPayload are as follows:
• The translated MT in case the translation result is not indicating a failure to translate.
• The translation results.
• The translation version and if the translation result needs further information,
thenadditional information is added, in fields that were truncated.
Example of the multi-format MX (whitespace added for readability purposes):
<SwInt:RequestPayload>
<AppHdr ...>... </AppHdr>
<Document ...>...</Document>
<!--
{1:F01BANKBEBBXXXX0000000000}
{2:O1030840190320SENDBEBBXXXX00000000001903200841U}
{3:{121:uetr value}}
{4:
:20:trn
:32A:190320EUR5000,50
...
-}
{5:{CHK:ABCD12345678}}
-->
<!-- TranslationResult=CODE -->
<!-- TranslationInfo version 1.0.0.1
Other info as applicable (e.g. list of fields that could not be
translated fully) -->
</SwInt:RequestPayload>

Handling CrLF and parsing comments


The MT uses a CrLF as a delimiter. Since XML parsers should do end-of-line handling, the
CrLF are replaced with two specific characters "^" for the Cr and "~" for the LF.
XML parsers may use the "--" within an XML comment as part of a markup of the comment.
To avoid interference with XML parsers each "--" within the translated MT is replaced by "[[".
This can be safely done because the three characters "~", "^" and "[" are not part of any MT
character set.
Example of the RequestPayload that is provided to your messaging interface:

22 February 2022 7
Multi-format MX

<SwInt:RequestPayload>
<AppHdr ...>...</AppHdr>
<Document...>...</Document>
<!--{1:F01BANKBEBBXXXX0000000000}{2:O1030840190320SENDBEBBXXXX00000000001
903200841U}{3:{121:uetr value}}{4:^~:20:trn^~:32A:190320EUR5000,50^~...^~
-}{5:{CHK:ABCD12345678}}-->
<!-- TranslationResult=CODE -->
<!-- TranslationInfo version 1.0.0.1
Other info as applicable (e.g. list of fields that could not be
translated fully) -->
</SwInt:RequestPayload>

The first comment contains the translated MT, while the other comments contain information
about the translation itself.
As shown the whitespace between the markup of the start <!-- and of the end of the
comment --> and the content of the comment should be ignored.
Your messaging interface may interpret these characters and make the resulting MT format
available as it would do for a normally received MT over FIN.
The following sections describe each comment.

3.1 Mapping to MT Blocks


Overview
The mapping from the ISO 20022 MX to the particular fields in the block of the MT is
explained in a set of tables.
Some of the network-related fields are provided as well. In this case, it is explained for
which element from the SnF RequestDescriptor they are coming from.
Since the in-flow translation is done for the receiver, only the output format of the MT is
used.
Block 1 - Basic Header

Field Value Comment


Block identifier {1: A constant indicating block 1
Application identifier F A constant. Only FIN user to user messages
are translated
Service identifier 01 A constant. Only FIN user to user messages
are translated
Logical Terminal address BANKBEBBXABC This is the receiver of the message.
The 9th character is always X
The first 8 and last 3 characters are taken
from the Business Application Header

22 February 2022 8
Multi-format MX

AppHdr/To/FIID/FinInstnId/BICFI. If
this is only 8 characters, then the last 3
characters are equal to XXX.
Session number 0000 A constant, since it is a network
transmission element not translated.
Sequence number 000000 A constant, since it is a network
transmission element not translated.
End of block } A constant.

Note The Logical Terminal Address may be derived differently for pilot services which
translate to FIN Test and Training, see section Pilot services and translation.

Block 2 - Application Header

The output format is used.

Field Value Comment


Block {2: A constant indicating block 2
identifier
Input or O A constant indicating output.
output
identifier
Message 103 3-digit identifier of the MT. It is derived
Type from the ISO 20022 Message.
Input Time 1059 Time in HHMM. It is derived from the
SnFInputTime in the
RequestDescriptor. The time is
translated to the local time of the sender
BIC found in the block 2.
Message 190320SENDBEBBXABC0000000000 First 6 digits are the input date. It is
Input derived from the SnFInputTime in the
Reference RequestDescriptor. The date is
translated to the local date of the sender
BIC found in the Message Input
Reference.
The 12 next characters are the sender.
The 9th character is always X. The first 8
and last 3 are taken from the
AppHdr/Fr/FIID/FinInstnId/BICFI.
If this is only 8 characters, then the last 3
characters are equal to XXX.
The last 10 digits are a constant, since the
output session and sequence are network

22 February 2022 9
Multi-format MX

related transmission elements not


translated.
Output Date 190320 Date of generation of the output message
local to the BIC in block 1
Output Time 1059 Time of generation of the output message
local to the BIC in block 1
Message U Urgent U or normal N. Derived from the
Priority Priority in the RequestHeader.
End of block } A constant

Note The BIC in the Message Input Reference may be derived differently for pilot
services which translate to FIN Test and Training, see section Pilot services and
translation.
Note The output date and time is generated at the time the translation is invoked. The
business wise important timestamp is the input date and time, which is translated
correctly into the block 2 fields, based on the time zone of the sender BIC.

Block 3 - User header

The value contains the field number and an example of a value if applicable.

Field Value Comment


Block identifier {3: A constant indicating block 3
Service Identifier (FIN copy {103:...} Currently not returned in translation
only)
Banking priority {113:...} Currently not returned in translation
Message user reference {108:...} Currently not returned in translation
Validation flag {119:COV} Derived from the ISO 20022 Message as per
Standards definition.
Balance checkpoint date and {423:...} Currently not returned in translation
time
Message input reference {106:...} Currently not returned in translation
Related Reference {424:...} Currently not returned in translation
Service type identifier {111:001} Derived from the ISO 20022 Message as per
Standards definition
UETR {121:...} Derived from the ISO 20022 Message as per
Standards definition
Addressee information [115:...} Currently not returned in translation
Payment release information {165:...} Derived from the appropriate
to receiver ThirdPartyToReceiverInformation in the
RequestDescriptor for SWIFTNet Inform
Ycopy only

22 February 2022 10
Multi-format MX

Screening information for the {433:...} Derived from the appropriate


receiver ThirdPartyToReceiverInformation in the
RequestDescriptor for SWIFTNet Inform
Ycopy only
Payment controls information {434:...} Derived from the appropriate
for the receiver ThirdPartyToReceiverInformation in the
RequestDescriptor for SWIFTNet Inform
Ycopy only
End of block } A constant

Block 4 - text

Field Value Comment


Block identifier {4: A constant indicating block 4
User-to-user message ^~...^~- The result of the translation of the ISO
20022 MX as defined by Standards
End of block } A constant.

Block 5 - Trailers

Field Value Comment


Block identifier {5: A constant indicating block 5
Checksum {CHK:...} The checksum of the MT before converting
the Cr LF and -- to the "^", "~" and "]". The
same algorithm as in FIN is used.
PAC trailer {PAC:} A constant. Present for SWIFTNet Ycopy in
Bypass mode only. Derived from
CopyStatus in the RequestDescriptor.
Possible Duplicate Emission {PDE:} A constant. Present when PDIndication
is present in the RequestE2EControl
System originated message {SYS:} Never present since no system messages
are translated. For the retrieved message
and copied message this trailer is not
present either.
Training {TNG:} A constant. Present for messages received
on pilot services.
Possible Duplicate Message {PDM:...} Currently not returned in translation since
this is a network transmission related field
Delayed Message {DLM:} Currently not returned in translation since
this is a network transmission related field

22 February 2022 11
Multi-format MX

Message Reference {MRF:...} Never present, since this is a network


transmission related field that cannot be
translated.
End of block } A constant.

Note The list of trailers reflects those that are available at the time of publication of this
document.

3.2 Translation Reporting


Translation result
Since an ISO 20022 MX is highly rich and structured, it is not always possible to fully
translate the ISO 20022 MX.
There are some elements from the Business Application header that are used to translate
fields in the MT blocks 1 and 2, however majority of the translation result is from the ISO
20022 message (Document).
The translation result is composed of four-letter words along with the conditional category
of the severity of the error and six alphanumeric characters codes (if applicable). For e.g.,
"code": "TRNR", "message": "TRUNC_N.T0000T

In total the Translation result could be distinguished under following 5 categories

TROK Success where the full ISO 20022 message is translated

TRAK Almost success where the resulting MT is valid but not all elements of the ISO 20022
message end up in the translated MT
Note: TRAK code will be implemented in Q2 2022.

TRNR Truncation or character replacement occurred in non-reference fields

TRFR Truncation or character replacement occurred in reference fields present in the MT

TRNK Failure to translate

Translation result severity


For each element that has an issue in translation, the translation result details provide four
pieces of information:
• A category indicating the severity of the error
− TRUNC_N: a truncation in a non-reference field or missing non-reference field
− TRUNC_R: a truncation in a reference field or missing reference field
− WARNING: a condition reported on a given field; such conditions are reported as
agreed upon by the community

22 February 2022 12
Multi-format MX

− FAILURE: a fatal error indicating that the translation has stopped and therefore no
comment with the translation itself is present.
• A code indicating the type of issue encountered; the codes start with a letter ‘T’
• The path of the element on which the issue was detected
• A short description of the issue

It is expected that in most cases the code will be TROK, TRAK or TRNR

3.2.1 Translation Result – TROK


In case of ‘TROK’ code, the ISO 20022 message is successfully translated without any errors. Based on
the CBPR+ translation rules, the values from the different tags of the ISO 20022 message are successfully
translated in the equivalent fields of the corresponding MT message. Both, the ISO 20022 MX message,
and the translated MT message are expected to be received by the recipient as part of one SWIFTNet
message (MX), also known as the multi-format message. In certain scenarios ‘TROK’ could be flagged
with severity such as a ‘WARNING’ and six alphanumeric characters codes.

Example of code ‘TROK’

<SwInt:RequestPayload>
<AppHdr ...>...</AppHdr>
<Document...>...</Document>
<!
{1:F01BANKBEBBXXXX0000000000}{2:O1030840190320SENDBEBBXXXX000000000019032
00841U}{3:{121:uetr value}}{4:^~:20:trn^~:32A:190320EUR5000,50^~...^~
}{5:{CHK:ABCD12345678}}-->
<!-- TranslationResult= TROK -->
<!-- TranslationInfo version 1.0.0.1
Other info as applicable (e.g. list of fields that could not be
translated fully) -->
</SwInt:RequestPayload>

Example of code ‘TROK’ with WARNING

<!-- TranslationResult=TROK --><!-- TranslationInfo version 1.0.0.1


{
"errors": [
{
"code": "TROK",
"message": "WARNING.T00025 InstructedAmount is not present.
InterbankSettlementAmount is copied in 33B to make a valid MT.",
"path": "MT103CORE\/Block4\/CcyOrInstructedAmt"
} ] }

22 February 2022 13
Multi-format MX

3.2.2 Translation Result – TRNR

In case of ‘TRNR’ code, the ISO 20022 message has truncation or character replacement for ‘Non-
reference fields. The values from the non-reference fields in the ISO message are either truncated or
replaced by a dot(.) to comply with MT validation rules . For e.g., special character ‘#’ is supported in ISO
20022 MX message but will be replaced by a ‘dot(.)’ while translating to MT as it does not support this
special character.

.In another example, if any one of the’ address’ line element is empty out of the three line elements or if
any of the address line element has spaces then that specific line will be truncated in the translated
MT.(Refer example below)

In the case of a TRNR code, the message description contains path of the element where the error occurred
along with the short description.
Refer TRNR section in Appendix B.
From the translated MT, it is recommended to use the references of field:20 and :21 to reconcile the
messages, in case the translation result code is other than TRFR.
It is not recommended to use the translated MT for the purposes such as compliance checking, since
truncated data may not serve the purpose.
Example of xml message that would trigger code ‘TRNR’ .
• Highlighted yellow field in the below sample indicates “empty spaces”

22 February 2022 14
Multi-format MX

<SwInt:RequestPayload>
<AppHdr ...>...</AppHdr>
<Document...>…..
<Dbtr>
<Nm>ABC COMPANY INC</Nm>
<PstlAdr>
<AdrLine>CANARY WHARF </AdrLine>
<AdrLine> </AdrLine>
<AdrLine> GB</AdrLine>
</PstlAdr>
</Dbtr>
<Cdtr>
<Nm>XYZ EXPORTS INC </Nm>
<PstlAdr>
<BldgNb>7</BldgNb>
<BldgNm>TIMES SQUARE BUILDING</BldgNm>
<Flr>45</Flr>
<PstCd>NY 10036</PstCd>
<TwnNm>MANHATTAN</TwnNm>
<Ctry>US</Ctry>
</PstlAdr>
</Cdtr>
<RmtInf>
<Strd>
<RfrdDocInf>
<LineDtls>
<Id></Id>
</LineDtls>
</RfrdDocInf>
</Strd>
</RmtInf>
….</Document>

Based upon the above xml message, the multiformat message resulted with TRNR error code:

22 February 2022 15
Multi-format MX

<!--
{1:F01CCLAUS30XIFT0000000000}{2:O1030912220204CCLAUS30XIFT00000000002202040912N}{3:{111:001}{1
21:ccf4b192-1f7b-4241-940f-
9fb62972c827}}{4:^~:20:TEST/CAM/26/001^~:23B:CRED^~:32A:210826EUR3000,^~:33B:EUR3000,^~:50K:/0
938409834093843^~ABC COMPANY INC^~CANARY
WHARF ^~ GB^~:52A:CCLAUS33^~:57A:CCLAUS33^~:59F:/324349849854^~1/XYZ EXPORTS INC^~2/7,TIMES
SQUARE BUILDING,45^~3/US/MANHATTAN,NY
10036^~:70:/ROC/E21TEST/CAM/26/001///SRI/+^~:71A:OUR^~:71G:EUR450,^~-
}{5:{CHK:54DDC5E310BB}{TNG:}} -->

<!-- TranslationResult=TRNR -->

<!-- TranslationInfo version 1.0.0.1


{
"errors": [
{
"code": "TRNR",
"message": "TRUNC_N.T1000E Empty line is removed as it would create a validation error. Empty
lines are caused by leading or trailing spaces in the input data.",
"path": "MT103CORE/Block4/OrderingCustomer/OptionK/NameAndAddress"
},
{
"code": "TRNR",
"message": "TRUNC_N.T0000M Input content is not mapped to target message.\r\nValue
'<pacs:Strd><pacs:RfrdDocInf><pacs:LineDtls><pacs:Id><pacs:Tp><pacs:CdOrPrtry><pacs:Cd>CINV</p
acs:Cd></pacs:CdOrPrtry></pacs:Tp><pacs:Nb>103476</pacs:Nb><pacs:RltdDt>2021-08-
24</pacs:RltdDt></pacs:Id></pacs:LineDtls></pacs:RfrdDocInf></pacs:Strd>' has been dropped.",
"path": "MT103CORE/Block4/RemittanceInfo"
}
]
}
-->

3.2.3 Translation Result – TRFR

In case of ‘TRFR’ code, the ISO 20022 message has truncation or character replacement for ‘Reference
fields’. The values from the reference fields in the ISO message are either truncated or replaced by a
dot(.) to comply with MT validation rules . Truncated fields contain as last character a "+“ (plus).
For e.g., special character ‘#’ is supported in ISO 20022 MX message but will be replaced by a ‘dot(.)’
while translating to MT as it does not support this special character.
In the case of a TRFR code, the message description contains path of the element where the error occurred
along with the short description.

22 February 2022 16
Multi-format MX

It is not recommended to perform reconciliation based on the translated MT for ‘TRFR’ codes. This is not
an issue for the messaging interface as such since all reconciliation is based on the ISO 20022 MX and
not on the translated MT.
Example of xml message that would trigger code ‘TRFR’

<SwInt:RequestPayload>
<AppHdr ...>...</AppHdr>
<Document...>…..
<PmtId>
<InstrId>instrpacs009-001</InstrId>
<EndToEndId>e2eidentificationpacs009-001-120122</EndToEndId>
<UETR>9d96eb82-07a0-4dbf-be11-ad0b81c21f4a</UETR>
</PmtId>
…………..
</Document>

Based upon the above xml message, the multiformat message resulted with ‘TRFR’ error code:

<!--
{1:F01CCLAUS30XIFT0000000000}{2:O2021626220112CCLAUS30XIFT00000000002201121626N}{3:
{121:9d96eb82-07a0-4dbf-be11-ad0b81c21f4a}}{4:^~:20:instrpacs009-
001^~:21:e2eidentificati+^~:32A:220110EUR5678,^~:52A:CCLAUS33^~:58A:CCLAUS33^~-
}{5:{CHK:BF2EA40CE21C}{TNG:}} -->
<!-- TranslationResult=TRFR -->
<!-- TranslationInfo version 1.0.0.1
{
"errors": [
{
"code": "TRFR",
"message": "TRUNC_R.T0000T Field content has been truncated.\r\nValue
'e2eidentificationpacs009-001-120122' has been altered.",
"path": "MT202/Block4/RelatedReference"
}
]
}
-->

22 February 2022 17
Multi-format MX

3.2.4 Translation Result – TRNK

In case of ‘TRNK’ code, the ISO 20022 message has not successfully translated into MT message. The
typical reason for the code TRNK could be the fact that the preconditions or the schema is not as per the
usage guidelines. For examples such as
a.) ISO 20022 message containing more than one transaction
b.) amount field has more than 14 digits which is not MT compatible
c.) usage of commodities currency like XAU, XAG, XPD,XPT etc. in ISO 20022 message.
Example of xml message that would trigger code ‘TRNK’

<SwInt:RequestPayload>
<AppHdr ...>...</AppHdr>
<Document...>…..
<ChrgsInf>
<Amt Ccy="EUR">99999999999999.</Amt>
<Agt>
<FinInstnId>
<BICFI>CCLAUS33</BICFI>
</FinInstnId>
</Agt>
</ChrgsInf>
………
</Document>

Based upon the above xml message, the multiformat message resulted with TRNK error code:

22 February 2022 18
Multi-format MX

<!-- -->
<!-- TranslationResult=TRNK -->
<!-- TranslationInfo version 1.0.0.1
{
"errors": [
{
"code": "TRNK",
"message": "FAILURE.T13005 Length of total charges in ChargesInformation/Amount
exceeds 14 digits. 71G is not translated to the target message.",
"path": "MT103CORE/Block4"
}
]
}
-->

3.2.5 Translation Result – TRAK

In case of ‘TRAK’ code (Translation almost, OK), the ISO 20022 MX message has successfully
translated to MT but not all elements of the ISO messages are translated to MT.
In an ISO 20022 message, if an optional data element is populated according to the CBPR+ usage
guidelines and that can never be translated into an MT due to the absence of an equivalent field, then
the TRAK code will be generated in the translation result. For e.g. In ISO 20022 Message
"DebtorAccountType" is an optional field but this field doesn’t have an equivalent field in MT.
There will NOT be any TRAK code generated for the mandatory element in ISO 20022 message which
has no equivalent field in MT. For e.g., Field element " no. of transaction" is mandatory in MX but it will
never translate into MT and neither it will generate a TRAK code.

TRAK code will be implemented in Q2 2022.

3.2.6 Translation Result with Multiple Translation Result codes

There is a possibility where in a single ISO 20022 MX message there could be multiple translation
result codes For example, TRNR, TRNK. In this case, priority should be given to the codes listed in the
below order:

TRNK – Translation failure.

22 February 2022 19
Multi-format MX

TRFR – Truncation/ Character replacement of ‘Reference’ fields


TRNR - Truncation/ Character replacement of ‘Non- Reference’ fields
TROK – Translation OK with a warning message.
TROK - Translation OK

To summarise, if the translation code results as ‘TRFR’ and ‘TRNK’ in the same message then the
priority should be given to ‘TRNK’, and the embedded MT should not be considered for further
processing.
a.) Example of xml message that would trigger multiple translation result codes - TRNK and TRFR:

<SwInt:RequestPayload>
<AppHdr ...>...</AppHdr>
<Document...>…..
<CdtTrfTxInf>
<PmtId>
<InstrId>instrpacs009-001</InstrId>
<EndToEndId>e2eidentificationpacs009-001</EndToEndId>
<UETR>a5d94492-9ee4-46ba-baba-9cc74c51c589</UETR>
</PmtId>
<IntrBkSttlmAmt Ccy="EUR">5678.</IntrBkSttlmAmt>
<IntrBkSttlmDt>2061-02-09+01:00</IntrBkSttlmDt>
………
</Document>

Based upon the above xml message, the multiformat message resulted with two translation result codes
such as TRNK and TRFR:

22 February 2022 20
Multi-format MX

<!-- -->

<!-- TranslationResult=TRNK -->


<!-- TranslationInfo version 1.0.0.1
{
"errors": [
{
"code": "TRFR",
"message": "TRUNC_R.T0000T Field content has been truncated.\r\nValue
'e2eidentificationpacs009-001' has been altered.",
"path": "MT202/Block4/RelatedReference"
},
{
"code": "TRNK",
"message": "T50 Year not in range 01 - 60",
"path": "MT202/Block4/ValueDateCcyCodeAmt/Date"
}
]
}
-->

b.) In another example, if the translation code results as ‘TRFR’ and ‘TRNR’ in the same message
then the priority should be given to ‘TRFR’

Example of xml message that would trigger multiple translation result codes- TRFR and TRNR:

22 February 2022 21
Multi-format MX

<SwInt:RequestPayload>
<AppHdr ...>...</AppHdr>
<Document...>…..
<GrpHdr>
<MsgId>Msgidentification001</MsgId>
<CreDtTm>2022-01-07T11:04:48+01:00</CreDtTm>
</GrpHdr>
<TxInfAndSts>
<OrgnlGrpInf>
<OrgnlMsgId>OrgMsgidentification001</OrgnlMsgId>
<OrgnlMsgNmId>pacs.008.001.08</OrgnlMsgNmId>
</OrgnlGrpInf>
……..
</Document>

Based upon the above xml message, the multiformat message resulted with two translation result codes
such as TRFR and TRNR

<!--
{1:F01CCLAUS30XIFT0000000000}{2:O1991050220113CCLAUS30XIFT00000000002201131050N}{3:
{121:c332bcb5-39e8-4880-8a83-
da309c1fe32f}}{4:^~:20:Msgidentificati+^~:21:OrginstrId001^~:79:/REJT/99^~/AC04/^~/
MREF/OrgMsgidentific+^~/TREF/Orge2eid001^~/TEXT//UETR/c332bcb5-39e8-4880-8a83-
da309c1fe32f^~-}{5:{CHK:10707D1565B2}{TNG:}} -->
<!-- TranslationResult=TRFR -->
<!-- TranslationInfo version 1.0.0.1
{
"errors": [
{
"code": "TRFR",
"message": "TRUNC_R.T0000T Field content has been truncated.\r\nValue
'Msgidentification001' has been altered.",
"path": "MT199/Block4/TxnRefNum"
},
{
"code": "TRNR",
"message": "TRUNC_N.T0000T Field content has been truncated.\r\nValue
'OrgMsgidentification001' has been altered.",

22 February 2022 22
Multi-format MX

"path": "MT199/Block4/Narrative"
}
]
}
-->

The result details are in a JSON format as illustrated in the above examples.
A messaging interface may use the translation result details to offer some functionality to its users. As a
minimum the information must be stored together with the message and be available to allow for correct
interpretation and appropriate processing of the translated MT.
The list of codes is published in the SWIFTNet Link Error Codes.

22 February 2022 23
Handling Multi-format MX in Applications

4 Handling Multi-format MX in Applications


For detailed specifications and guides either reach out your vendor or for SWIFT Interface product, refer
• Alliance Access
• Alliance Messaging Hub
• Alliance Cloud
• Alliance Lite2

22 February 2022 24
Pilot Services and Translation

5 Pilot Services and Translation


Difference between FIN Test and Training and SnF pilot services
FIN Test and Training use the concept of a Test and Training BIC to clearly separate Test
and Training traffic from live traffic. The Test and Training BICs are part of the signed data.
SWIFTNet InterAct, and all other SWIFTNet messaging services, use the concept of a pilot
or Test and Training service to identify and separate test traffic from live traffic. Separation
is done by the service and the fact that pilot traffic must go to different pilot SnF queues than
live traffic. The service is part of the signed data.
To ensure that the approach used for FIN also applies to translated MT and that the same
concepts can be used for tests related to all MT, independent on where these MT are
coming from, it is essential that the translated MT for ISO 20022 MX uses Test and Training
BIC within the block 1 and block 2.
Deriving the Test and Training BIC from the ISO 20022 MX
The Business Application Header To and Fr are used to populate the MT block 1 and 2.
Only when the BICFI is a live BIC a mechanism is needed to derive the corresponding Test
and Training BIC.
The Test and Training BIC for both MT block 1 and block 2 are derived in two attempts
performed in the following order
• If To or Fr contain a Test and Training BIC, then this Test and Training BIC is used.
• Else the default Test and Training BIC corresponding to the live BIC is used.
The default Test and Training BIC is in most cases the same as the live BIC but with a 0 in
the 8th position.
Testing on ITB
The ITB (Integration Test Bed) is an independent testbed made available by SWIFT for
vendors to test out the implementation of the vendor software. This allows vendors to verify
their software prior to deploying their product at their customers premises.
For the in-flow translation testing, a naming convention is used to distinguish a service on
which a live translation rule set is deployed from a service on which a test translation rule
set is deployed.
As a reminder, services on ITB contain always a "!x" in the service name.
The naming convention used is simple. Services with a "!xp" in their service name use the
pilot translation rules. These are therefore always using a Test and Training BIC within the
MT block 1 and block 2. Services that contain an "!x" but no "!xp" use the live translation
rules.

22 February 2022 25
Pilot Services and Translation

Appendix A

Messages in scope of the in-flow translation


The following list of messages will be in scope of the in-flow translation service for the pilot
service from November 2021 and live service in August 2022 prior the general availability of
the transaction manager in November 2022. For more details, see the FINplus Service
Description.

Note All translation rules from ISO to FIN approved by the CBPR+ working group are
available and published on MyStandards

22 February 2022 26
Pilot Services and Translation

Appendix B
In-flow Translation related Sample Messages
The purpose of the following sample messages is to facilitate application testing and to provide a
further understanding of the structure of ISO 20022 messages and conditions that would trigger
certain types of translation results.

This selection of samples is arranged in order of the Translation result and error codes as per the
table below and also available to download from Mystandards portal in samples library under
MT/ISO 20022 Translation section CBPR+ Landing page Each zip file aligns to the Translation
result and error codes, and contains the message samples as a Sender and a Receiver.

The naming convention is as follows:

“In-flowTranslationResultCode_error/warning_code_messagetype.txt”
For example, TRNK_T1000E_pacs.008.txt

The message will not work “as is” in the Readiness Portal or in the FINplus Pilot future environment.
In order to test in FINplus Pilot future environment with other Bank(s) or to conduct loop back testing
with self, it is essential that users replace the DUMMY BIC in the samples provided with their own
BICs in the Application Header and Document section as a ‘Sender’ of messages. The samples
don’t include request header and cryptography/signatures added by the messaging interface.

You will need an editor to view the txt file, such as NotePad, NotePad++ or you can use a web
browser.
This selection of Translation result and error codes will increase as the In-flow Translation service
evolves; and new samples will be added if applicable.

TRNK - Failure to translate

Translation Error Description Impacted


result Code Message
Types

TRNK T13005 FAILURE/Length of total charges in ChargesInformation/Amount exceeds 14 pacs.008


digits. 71G is not translated to the target message.

TRNK T20038 FAILURE/Entry Status is not "booked". Translation is not foreseen. STOP camt.054
Translation.

22 February 2022 27
Pilot Services and Translation

TRNK T20056 FAILURE/Transaction Status is different from "rejected". Translation is not pacs.002
foreseen. STOP Translation

TRNK T20078 FAILURE/Notification/Entry/ValueDate IsAbsent AND camt.054


Notification/Entry/EntryDetails/TransactionDetails/RelatedDates/
InterbankSettlementDate IsAbsent. Not possible to create 32A/ValueDate.

TRNK T20103 FAILURE/Both LegalSequenceNumber and ElectronicSequenceNumber are camt.052,


absent or have more than 5 digits. Impossible to generate 28C. camt.053,
camt.054

TRNK T20104 FAILURE/Either the opening booked balance (OPBD) is missing or more camt.053
than one occurrence of OPBD on the page.

TRNK T20105 FAILURE/Intermediate opening booked balance (OPBD/INTM) is not camt.053


expected on the first page.

TRNK T20106 FAILURE/Balance SubType code INTM is missing to indicate it is an camt.053


intermediate opening booked balance.

TRNK T20107 FAILURE/Either the closing booked balance (CLBD) is missing or more than camt.053
one occurrence of CLBD on the page

TRNK T20108 FAILURE/Intermediate closing booked balance (CLBD/INTM) is expected if camt.053


LastPageIndicator is "false"

TRNK T20109 FAILURE/Intermediate closing booked balance (CLBD/INTM) is NOT camt.053


expected if LastPageIndicator is "true"

TRNK T20110 FAILURE/Number of Entries is over the maximum allowed to guarantee camt.052,
smooth translation to MT. camt.053

TRNK T20111 FAILURE/The first two characters of the three character currency code in camt.053
fields 60a, 62a, 64 and 65 must be the same for all occurrences of these
fields. Source message is not compliant with the network validation rule
defined on the target message.

TRNK T20112 FAILURE/MX Balance contains more than 14 digits camt.053

TRNK T20113 FAILURE/MX Entry amount has more than 14 digits. camt.052,
camt.053

TRNK T20114 FAILURE/At least the following must be present: Report/Entry is present OR camt.052
-Report/TransactionsSummary/TotalCreditEntries/(NumberOfEntries AND
SUM) is present OR -
Report/TransactionsSummary/TotalDebitEntries/(NumberOfEntries AND
SUM) is present Translation camt.052 to MT941 is out of scope (ie., no
balance translation).

TRNK T20116 FAILURE/All entry amounts must be expressed in Account Currency camt.052,
camt.053

22 February 2022 28
Pilot Services and Translation

TRNK T20125 FAILURE/Intermediate closing booked balance (CLBD/INTM) is NOT camt.052


expected if LastPageIndicator is "true"

TRNK T20197 FAILURE/Not expected scenario. Investigation needed. Option B or C is not pacs.008,
allowed to translate the ClearingSystemMemberID or Account in absence of pacs.009,
BIC and Name and Address. pacs.004,
camt.054,
camt.057

TRNR- Truncation or character replacement occurred in non-reference fields


TRFR - Truncation or character replacement occurred in reference fields present in the MT

Translation Error Description Impacted Message


result Code Types

TRNR / T0000M Input content is not mapped to target message. pacs.008, pacs.009,
TRFR
Incompatible=Field content is not copied as it is pacs.002, pacs.004,
incompatible camt.029,camt.056,
camt.052,camt.053,
camt.054, camt.057

TRNR / T0000R Illegal characters have been replaced pacs.008, pacs.009,


TRFR
pacs.002, pacs.004,
camt.029,camt.056,
camt.052,camt.053,
camt.054,camt.057

TRNR / T0000S Leading or trailing spaces are trimmed pacs.008, pacs.009,


TRFR
pacs.002, pacs.004,
camt.029,camt.056,
camt.052,camt.053,
camt.054, camt.057

TRNR / T0000T Field content has been truncated. pacs.008, pacs.009,


TRFR
pacs.002, pacs.004,
camt.029,camt.056,
camt.052,camt.053,
camt.054, camt.057

TRNR / T1000E TRUNC_X/Empty line is removed as it would create a pacs.008, pacs.009,


TRFR
validation error. Empty lines are caused by leading or pacs.002, pacs.004,
trailing spaces in the input data. camt.029,camt.056,

22 February 2022 29
Pilot Services and Translation

camt.052,camt.053,
camt.054, camt.057

TROK - Success where the full ISO 20022 message is translated

Translation Code Description Impacted Message


result Types

TROK T11005 WARNING/As per SWIFT User Handbook, Message pacs.008, pacs.009,
Reference Guides for Category 1 and Category 2, a Fedwire pacs.004, camt.054,
Routing Number in combination with a BIC (option A) must camt.057
be used without the 9-digit code. As the Clearing channel
has no impact on the agent or has a value different from
"RTGS", translation to "//FW" might be misleading. So the
ClearingSystemMemberID is not translated.

TROK T11006 WARNING/As per SWIFT User Handbook, Message pacs.008, pacs.009,
Reference Guides for Category 1 and Category 2, for some pacs.004, camt.054,
clearing systems the use of a clearing identification in camt.057
combination with a BIC (MT option A) is not allowed: CHIPS
Participant Identifier (“CP”), Russian Central Bank
Identification Code (“RU”), Swiss Clearing Code (“SW”). For
that reason if the ClearingSystemMemberIdentifier is
present, it is not translated to MT.

TROK T11007 WARNING/If the Clearing Channel is "RTGS" and BIC is pacs.008, pacs.009,
present, then ClearingSystemMemberId, if present, is not pacs.004,camt.054,
translated. Only the Clearing Channel resulting in "//RT". camt.057

TROK T12001 WARNING/Not possible to create a valid FATF ID because pacs.008, pacs.009,
the country of the issuer is missing. Dummy value is pacs.004, camt.054,
provided in Subfield1. Country from the address is used camt.057
instead of country of issuer.

TROK T12002 WARNING/Not possible to create a valid FATF ID because pacs.008, pacs.009,
the country of the issuer is missing. Dummy value is pacs.004, camt.054,
provided in Subfield1. Country of residence is used instead camt.057
of country of issuer

22 February 2022 30
Pilot Services and Translation

TROK T12003 WARNING/Not possible to create a valid FATF ID because pacs.008, pacs.009,
PrivateIdentification/Other/SchemeName/Code is not in pacs.004, camt.054,
the list of codes allowed in Party Identifier (50F subfield 1). camt.057

TROK T12004 WARNING/Not possible to create a valid FATF ID. Dummy pacs.008, pacs.009,
value provided in Subfield1. pacs.004, camt.054,
camt.057

TROK T12005 WARNING/Not possible to create a valid FATF ID for option pacs.008, pacs.009,
F Subfield2 Line 6/ or 7/. Information not translated from pacs.004, camt.054,
PrivateIdentification/Other. camt.057

TROK T12007 WARNING/ClearingSystemMemberIdentification is pacs.004, camt.054,


translated to 50K/NameAndAddress or 50NoLetter. camt.057

TROK T12008 WARNING/ClearingSystemMemberIdentification is pacs.004


translated to 59/NameAndAddress.

TROK T12009 WARNING/Party's name is missing. Dummy value pacs.008, pacs.009,


"NOTPROVIDED" is used. pacs.004, camt.054,
camt.057

TROK T13003 WARNING/InstructedAmount is not present. pacs.008, pacs.009


InterbankSettlementAmount is copied in 33B to make a
valid MT.

TROK T13004 WARNING/71G/Currency is not equal to 32A/Currency. pacs.008, pacs.009


This generates an invalid MT. 71G is not translated to the
target message.

TROK T13006 WARNING/Charges with different currencies. Sum of pacs.004


charges cannot be calculated.

TROK T14001 WARNING/Invalid data to fill MT Reference. Dummy value pacs.008, pacs.009,
provided. pacs.002, pacs.004,
camt.029,camt.056,
camt.052,camt.053,
camt.054,camt.057

TROK T14002 WARNING/Invalid original payment identification pacs.004


(OriginalInstructionID OR OriginalMessageID) to fill MT
Reference. Dummy value provided.

22 February 2022 31
Pilot Services and Translation

TROK T2S001 WARNING/Runtime context parameter 'SN.Requestor' DN pacs.008, pacs.009,


is invalid. It's not used to derive the sender's address. pacs.002, pacs.004,
camt.029, camt.056,
camt.052, camt.053,
camt.054, camt.057

TROK T2S002 WARNING/Runtime context parameter 'SN.Responder' DN pacs.008, pacs.009,


is invalid. It's not used to derive the sender's address. pacs.002, pacs.004,
camt.029, camt.056,
camt.052, camt.053,
camt.054, camt.057

TROK T2S003 WARNING/Runtime context parameter pacs.008, pacs.009,


'SN.SnFInputTime' is invalid. It's not used to set the input pacs.002, pacs.004,
time and MIR. camt.029, camt.056,
camt.052, camt.053,
camt.054, camt.057

TROK T2S004 WARNING/Runtime context parameter pacs.008, pacs.009,


'SN.SnFOutputTime' is invalid. It's not used to set the pacs.002, pacs.004,
output date and time. camt.029, camt.056,
camt.052, camt.053,
camt.054, camt.057

TROK T20027 WARNING/Invalid BIC in /FIN53/. Code /FIN53/ not pacs.008, pacs.009
translated.

TROK T20072 WARNING/Missing OriginalInstructionID. Dummy value is pacs.002, camt.056


provided to get a valid MT Message

TROK T20083 WARNING/Original Message Name Identification value is camt.029, camt.056


not expected. Dummy value "202" is translated.

TROK T20092 WARNING/Target message is uncertain. Translation to pacs.002, camt.029,


Category 2 as default. camt.056

TROK T30001 WARNING/No BIC found in tag AppHdr/Fr (business camt.029, camt.052,
application header). Please specify the BIC in the business camt.053
application header (BAH). Dummy values are used instead

22 February 2022 32
Pilot Services and Translation

TROK T30002 WARNING/No BIC found in tag AppHdr/To (business camt.029, camt.052,
application header). Please specify the BIC in the business camt.053, camt.054,
application header (BAH). Dummy values are used instead camt.056

TROK T30001 WARNING/No BIC found in tag AppHdr/Fr (business pacs.008, pacs.009,
application header). Please specify the BIC in the business pacs.002, pacs.004,
application header (BAH). Dummy values are used instead camt.054,camt.057

TROK T30002 WARNING/No BIC found in tag AppHdr/To (business pacs.008, pacs.009,
application header). Please specify the BIC in the business pacs.002, pacs.004,
application header (BAH). Dummy values are used instead camt.054,camt.057

TROK T15002 WARNING/"SDVA" code in ServiceLevel and "HOLD" or pacs.008, pacs.009


"CHQB" code in InstructionForCreditorAgent generates an
invalid MT. Code in conflict with SDVA (HOLD or CHQB) is
deleted and therefore missing in translated message.

TROK T15003 WARNING/"INTC" code or "CORT" code in pacs.008, pacs.009


CategoryPurpose and "HOLD" or "CHQB" code in
InstructionForCreditorAgent generates an invalid MT. Code
in conflict with INTC or CORT (HOLD or CHQB) is deleted
and therefore missing in translated message.

TROK T20064 WARNING/Not possible to translate 52a. So 52a camt.054


information is missing.

22 February 2022 33
Legal Notices

Legal Notices
Copyright
S.W.I.F.T. SC ("SWIFT") or its licensors © 2022. All rights reserved.

Restricted Distribution
Do not distribute this publication outside your organisation unless your subscription or order
expressly grants you that right, in which case ensure you comply with any other applicable
conditions.

Disclaimer and limitation of liability


The information in this publication may change from time to time. You must always refer to the
latest available version.
This publication may depict fictitious examples and is made available "as is" for information
purposes only. SWIFT assumes no liability for any errors, inaccuracies or incompleteness
contained this publication. SWIFT MAKES NO REPRESENTATIONS OR WARRANTIES, EITHER
EXPRESS OR IMPLIED, OF ANY KIND RELATED TO THIS PUBLICATION OR THE
INFORMATION IN THIS PUBLICATION, AND HEREBY DISCLAIMS ALL SUCH
REPRESENTATIONS AND WARRANTIES, CREATED BY LAW, CONTRACT OR OTHERWISE,
INCLUDING WITHOUT LIMITATION THE WARRANTIES OF MERCHANTABILITY, FITNESS
FOR A PARTICULAR PURPOSE, TITLE OR NON-INFRINGEMENT. TO THE FULLEST EXTENT
PERMITTED UNDER APPLICABLE LAW, SWIFT SHALL NOT BE LIABLE FOR DAMAGES OF
ANY KIND ARISING FROM USE OF THIS PUBLICATION OR ANY INFORMATION IN THIS
PUBLICATION, INCLUDING WITHOUT LIMITATION ANY LIABILITY FOR DIRECT, INDIRECT,
SPECIAL, CONSEQUENTIAL OR INCIDENTAL LOSS OR DAMAGE, EVEN IF SWIFT WAS
AWARE OF THE POSSIBILITY OF SUCH LOSS OR DAMAGE.

The laws of Belgium shall govern the terms and conditions for the use of this publication,
and the courts of Brussels shall have exclusive jurisdiction over any disputes arising from
or in connection with the use of or any information in this publication.
The English version of SWIFT documentation is the only official and binding version.

Trademarks
SWIFT is the trade name of S.W.I.F.T. SC. The following are registered trademarks of SWIFT:
3SKey, Innotribe, MyStandards, Sibos, SWIFT, SWIFTNet, SWIFT Institute, the Standards Forum
logo, the SWIFT logo, SWIFT gpi with logo, the SWIFT gpi logo, and UETR. Other product,
service, or company names in this publication are trade names, trademarks, or registered
trademarks of their respective owners.

22 February 2022 34

You might also like