Why does a field in my MT103 end with a plus sign?

By industry convention a + as the last character means the field was cut when the payment was translated from ISO 20022: the original pacs.008 contains more data than the MT field could hold.

Can I get the full data of a truncated payment?

Yes, from the original MX. Swift’s in-flow translation delivers the MT next to the original pacs.008 in the same envelope, so the full message is available if your interface keeps it. Otherwise ask the sending bank.

Which fields are most often truncated?

Names and addresses in 50F and 59F, remittance information in field 70, and agent instructions in field 72. LEIs, purpose codes and ultimate parties have no dedicated MT103 field at all.

Is converting an MT103 to pacs.008 lossless?

The conversion cannot add data the MT never had: the pacs.008 will have no LEI, no ultimate parties and no structured address beyond what option F carried. Swift converts only at the start of the chain, and only messages that pass its stricter MT validation.

Does truncation matter for sanctions screening?

Yes. A cut name or address can hide a match or create a false one. Screen on the full names and addresses in the MX rather than on the MT copy.

Payments

Why is data truncated when an ISO 20022 payment is translated to MT?

Written and maintained by ZagTrader. Last reviewed 21 October 2026. How this page is sourced and checked

An ISO 20022 pacs.008 can carry longer names, structured addresses, LEIs, ultimate parties, purpose codes and much more remittance data than an MT103 has room for. When a bank or Swift’s in-flow translation turns the MX into an MT, whatever does not fit is cut or left out, and by industry convention a + as the last character of an MT field signals that data was dropped. The full data stays in the original MX, so process from the MX wherever you can.

What it means

Since 22 November 2025, cross-border payment instructions between banks on Swift are exchanged in ISO 20022 (pacs.008, pacs.009 and their variants). Banks that still process MT can receive them through Swift’s in-flow translation, which delivers an MT version embedded next to the original MX in the same message envelope. Swift’s FAQ names truncation, together with MX elements that have no MT equivalent, as the main limit of that translation; the translation rules are those agreed by the CBPR+ group and published on MyStandards.

The size gap is large. In pacs.008.001.08 a party name (Nm) can be 140 characters, a street name 70, a town name 35, and an address can be split into building number, post code, town, country and more. The MT103 gives a party four lines of 35 characters in total (option F: numbered lines of 33 characters after 1/, 2/, 3/). Remittance information in field 70 is 4 lines of 35 characters, 140 in total, while pacs.008 allows structured remittance blocks (RmtInf/Strd) with document references, amounts and invoicer details. References such as InstrId and EndToEndId can be 35 characters, against 16 in MT field 20.

Some pacs.008 data has no dedicated MT103 field at all: the LEI of a party or agent (Id/OrgId/LEI, FinInstnId/LEI), the ultimate debtor and ultimate creditor (UltmtDbtr, UltmtCdtr), the purpose code (Purp/Cd), structured remittance (RmtInf/Strd) and related remittance locations (RltdRmtInf). These are either reduced to free text in a field that has some room or left out of the MT copy.

The convention for marking a cut is a + as the last character of the MT field. J.P. Morgan’s ISO 20022 FAQ describes it as the industry convention and says it adds the + where possible. A + at the end of field 50F, 59F, 70, 72 or 77B is therefore a strong hint that the MX holds more.

The opposite direction loses data too. An MT103 sent after November 2025 is converted by Swift’s contingency processing into a pacs.008, but the converted message can only contain what the MT held: no structured address unless the MT had one in option F, no LEI, no ultimate parties. Conversion happens only once, at the start of the payment chain. J.P. Morgan’s FAQ also notes that from November 2026 any address given for a party in CBPR+ payments must be structured or hybrid, with at least town name and country.

Common causes

A debtor or creditor name longer than the space in 50F or 59F, which is cut at the end of the line.
A structured address (street, building, post code, town, country sub-division) flattened into the 2/ and 3/ lines of option F and cut where it does not fit.
Remittance information longer than the 140 characters of field 70, or structured remittance (invoice lists, amounts) that has no structured place in MT.
LEIs, purpose codes and ultimate debtor or creditor details that have no dedicated MT103 field.
Instructions for agents (InstrForCdtrAgt, InstrForNxtAgt) and regulatory reporting (RgltryRptg) longer than fields 72 and 77B allow.
Characters allowed in CBPR+ names and addresses (such as @, & or #) that the FIN character set of the MT does not support.
In the other direction: an MT103 converted to pacs.008 carries only the unstructured data the MT held, so a receiving bank that needs structured data may reject it.

How to fix it

Check whether your payments arrive as MX with an embedded MT (in-flow translation) or as MT only. If both are delivered, configure your interface so that operations and screening can see the MX.
Look for a + as the last character of 50F, 59F, 70, 72 and 77B, and for fields filled exactly to their maximum length. Either means the MT is incomplete.
For any payment where the MT is truncated, open the original pacs.008 and read the full Dbtr, Cdtr, UltmtDbtr, UltmtCdtr, Purp and RmtInf from there.
Run sanctions screening and beneficiary name checks on the MX data, not on the cut MT copy, so a truncated name does not hide or create a match.
Reconcile and pass on remittance from the MX: an invoice list cut after 140 characters will leave the beneficiary unable to match the payment.
If you still send MT103, fill 50F and 59F in option F with town and country on the 3/ line so the converted pacs.008 has at least a hybrid address, and plan the move to sending pacs.008 directly.

Where a pacs.008.001.08 carries more than an MT103 can hold. Lengths from the ISO 20022 schema and the MT103 format; what happens to the extra data depends on the translation rules used.

pacs.008 element	Size in pacs.008	MT103 field	Room in MT103
`Dbtr/Nm`, `Cdtr/Nm`	up to 140 characters	50F / 59F line `1/`	33 characters per numbered line, 4 lines for the whole party
`Dbtr/PstlAdr`, `Cdtr/PstlAdr` (structured)	street 70, building number 16, post code 16, town 35, country 2, and more	50F / 59F lines `2/` and `3/`	shares the same 4 lines as the name
`RmtInf/Ustrd`	140 characters per occurrence, can repeat	70	4 lines of 35 characters
`RmtInf/Strd`	structured documents, amounts, references	70	free text only
`PmtId/InstrId`, `PmtId/EndToEndId`	35 characters each	20 (and free text in 70)	16 characters in field 20
`Dbtr/Id/OrgId/LEI`, `FinInstnId/LEI`	20 characters	none	no dedicated field
`UltmtDbtr`, `UltmtCdtr`	full party: name, address, identifiers	none	no dedicated field
`Purp/Cd`	four-character external code	none (26T is a different code)	no dedicated field
`InstrForCdtrAgt`, `InstrForNxtAgt`	repeatable codes with text	72	6 lines of 35 characters
`RgltryRptg`	repeatable structured details	77B	3 lines of 35 characters

Example

An MT103 view of a pacs.008 from ZagTrader Test Bank to BANKGB2LXXX, shown in the input layout used across this site. The pacs.008 carried a 61-character debtor name, a structured address, a creditor name of 52 characters and a structured remittance block listing 19 invoices. Every field that could not hold its data ends with +.

{1:F01ZAGTAEADAXXX0000000000}{2:I103BANKGB2LXXXXN}{3:{121:1529a461-c90a-466b-8b0a-0a709f59ad39}}{4:
:20:ZT2610220061
:23B:CRED
:32A:261022GBP48250,00
:33B:GBP48250,00
:50F:/AE070331234567890123456
1/ZAGTRADER INTERNATIONAL COMMODIT+
2/UNIT 4501 LEVEL 45 BURJ DAMAN BU+
3/AE/DUBAI
:59F:/GB42BANK40051587654321
1/NORTH SEA PRECISION INSTRUMENTS +
2/UNIT 7 HARBOUR INNOVATION PARK 2+
3/GB/ABERDEEN
:70:/INV/88412 88413 88414 88415 88416
88417 88418 88419 88420 88421 88422
88423 88424 88425 88426 88427 88428
88429 88430 PO 7781 DELIVERED OCTO+
:71A:SHA
-}

Open this example in the parser

The + at the end of the 1/ and 2/ lines in 50F and 59F shows that the name and address were longer in the pacs.008.

Field 70 is full (4 lines of 35 characters) and ends with +: the rest of the invoice list and order details are only in the MX.

The debtor’s LEI and the purpose code in the pacs.008 have no place in this MT103 at all and do not appear.

Illustration of the + convention; the exact cut points depend on the translation rules applied. BICs, names, IBANs and UETR are made up.

Questions

Why does a field in my MT103 end with a plus sign?: By industry convention a + as the last character means the field was cut when the payment was translated from ISO 20022: the original pacs.008 contains more data than the MT field could hold.
Can I get the full data of a truncated payment?: Yes, from the original MX. Swift’s in-flow translation delivers the MT next to the original pacs.008 in the same envelope, so the full message is available if your interface keeps it. Otherwise ask the sending bank.
Which fields are most often truncated?: Names and addresses in 50F and 59F, remittance information in field 70, and agent instructions in field 72. LEIs, purpose codes and ultimate parties have no dedicated MT103 field at all.
Is converting an MT103 to pacs.008 lossless?: The conversion cannot add data the MT never had: the pacs.008 will have no LEI, no ultimate parties and no structured address beyond what option F carried. Swift converts only at the start of the chain, and only messages that pass its stricter MT validation.
Does truncation matter for sanctions screening?: Yes. A cut name or address can hide a match or create a false one. Screen on the full names and addresses in the MX rather than on the MT copy.

Messages involved

All troubleshooting · Guides · Codes