| Field | Meaning | Required |
|---|---|---|
:20: | A unique reference assigned by the sending bank to identify this payment through its whole life. It must not repeat for the same sender within the same business | M |
:23B: | A four character code that tells the receiving bank how to handle the transfer. CRED means a normal credit transfer, SPAY means a SWIFT payment, SSTD means a st | M |
:32A: | The value date on which funds become available to the beneficiary, the three letter ISO currency code and the amount to be paid. For USD 25,000 on 5 November 20 | M |
:33B: | The currency and amount in which the ordering customer instructed the payment, when that differs from the settlement currency in field 32A. It preserves the ori | O |
:50a: | The customer who ordered the payment, identified by account number and name and address. Option K gives account, name and address in free text. Option F gives s | M |
:52a: | The financial institution that ordered the transfer when it is not the sender of the message. It is normally the bank holding the ordering customer account in a | O |
:53a: | The account held by the sender with the receiver, or the correspondent bank through which settlement will occur. It tells the receiving bank where to debit the | O |
:54a: | The account held by the receiver with another bank, used when the receiver does not hold the sender account directly. It identifies the next bank in the settlem | O |
:57a: | The bank where the beneficiary holds an account, when it is not the receiver of the MT103. It directs the receiving bank to forward the payment to the correct a | O |
:59a: | The final recipient of the funds, identified by account number and name and address. Option A gives the account and BIC, option F gives structured name and addr | M |
:70: | Free text information for the beneficiary explaining what the payment is for, such as an invoice number, contract reference or salary month. It is limited to fo | O |
:71A: | A three letter code stating who pays the transfer charges. OUR means the ordering customer pays all charges, BEN means the beneficiary pays all charges, and SHA | M |
Meridian Bank London sends an MT103, reference MER1035521, for USD 25,000 value 5 November 2024 to Harbour Bank Singapore to pay Bright Logistics for invoice INV-1187. This is a pre-migration example, from before coexistence ended on 22 November 2025. Field :71A: is SHA, the beneficiary account is given in :59a:, and the payment settles on the value date.
Valid example from the message catalogue. Scheme rules: MT103 is a SWIFT MT (FIN) message, not a base ISO 20022 message: there is no single global scheme rulebook, and each bank and market practice sets its own format limits and cut-off times on top of the
Translation rules, how MT becomes MX and back
What you will learn
Your objective. By the end of this lesson, you will be able to explain translation rules, how MT becomes mx and back. Translation between MT and MX is governed by mapping rules defined by SWIFT and by the CBPR Plus usage guidelines.
Why it matters. For a business analyst, the translation deliverables were concrete.
Chapter objective: Learner plans an MT to MX migration, explains CBPR+ scope and timelines, and maps MT103, MT202, and MT202COV to pacs.008, pacs.009, and pacs.009 COV equivalents with data gaps noted. Learner demonstrates this skill using realistic banking examples, explaining each step clearly and using correct terminology throughout.
Key learning points
- Translation between MT and MX
- MX message with a full structured address
- Charge bearer, MT to MX
- MT202 becomes a pacs.009
- Validation after translation
- Operations and compliance signed off
Key terms
Remittance information: Information that explains what a payment is for, such as invoice numbers, contract references or salary month.
Charge bearer: A code that states who pays the charges for a payment. In ISO 20022 the values are DEBT for debtor, CRED for creditor, SHAR for shared and SLEV for service level.
Value date: The date on which funds become available to the beneficiary and on which interest starts to accrue. It is the date used for settlement and for nostro posting.
SWIFT MT message viewer showing Translation rules, how MT becomes MX and back.
Practise this lesson
Exercise
Find the field field 32A in the message described in this lesson and explain what it controls.
Use the field description and the example in this lesson.
- What to do. Write down what field 32A carries, what happens if it is wrong, and which system reads it.
Correct result. field 32A carries the value the lesson describes. If it is wrong, the payment is rejected, returned, or misrouted, and the exception must be investigated before the payment can proceed.
Why. Fields are the contract between systems. A wrong field is not a typo, it is a failed payment.
Check your understanding
Practice question
An INR payment from a company in India to a supplier in Singapore must go out today. A colleague suggests sending it as an MT103 because that is how it was always done. What is the correct message under CBPR+ and why?
Takeaway and next step
What to remember
For a business analyst, the translation deliverables were concrete.
Open the message type from this lesson and inspect its fields, then find the field that carries the amount.
Open the ISO 20022 Message Explorer →
Builds on "Why migration was needed, and how coexistence ended".
Transcript and full text
Show transcript
Translation between MT and MX is governed by mapping rules defined by SWIFT and by the CBPR Plus usage guidelines. The rules specify, for each MT field, which MX element or elements it maps to, and for each MX element, which MT field or fields it maps from. Some mappings are straightforward, for example field 32A in an MT103, which contains value date, currency, and amount, maps to the Interbank Settlement Date, the Instructed Amount, and the currency in a pacs zero zero eight. Other mappings are more complex, because the data models are different. An MT field that contains free text may need to be split across several MX elements, or several MT fields may need to be combined into a single MX element. Translation is not just a technical mapping, it is a business decision about what data is preserved and what data is lost. When an MX message with a full structured address is translated to MT, the address must be truncated to fit the 35 character lines of MT, and some detail will be lost. When an MT message with a 140 character remittance field is translated to MX, the remittance information can be carried as unstructured text, but it will not have the structured invoice details that a native MX message would have. The translation rules therefore include rules for truncation, for abbreviation, and for what to do when data cannot be mapped. Those rules must be documented and tested, because they determine what the beneficiary will actually see. Analysts must also understand the difference between translation and transformation. Translation is the mapping of one format to another, while transformation is the change in business meaning that can occur during translation. For example, translating a charge bearer code from MT to MX should preserve the business meaning, but if the code lists are different, the translation may need to use a different code that has a slightly different meaning. That is a transformation risk, and it must be identified and mitigated. Your requirements should list every field that is translated, state the mapping rule, and state the expected behaviour when data cannot be mapped exactly. Walk through the main mappings one by one. An MT103 becomes a pacs.008. Field 20, the transaction reference, maps to the instruction identification. Field 32A splits into the interbank settlement date, the instructed amount, and the currency. Field 50K becomes the debtor, field 59 becomes the creditor, field 70 becomes the remittance information, and field 71A becomes the charge bearer. An MT202 becomes a pacs.009, with field 20 mapping to the instruction identification and field 32A mapping to the settlement date and amount. Translation in the other direction was harder, because MX carries more data than MT can hold. A pacs.008 with a full structured address had to be squeezed into four lines of 35 characters in MT field 50K or 59. Structured remittance information with several invoices had to be squeezed into 140 characters in MT field 70. Purpose codes, structured charges, and the UETR had no natural home in MT, so they were dropped or carried in free text fields where the receiving bank might not look for them. Every one of those squeezes was a place where data could be lost, and the translation rules had to say exactly what to drop and what to keep. Validation after translation was a separate step that teams often underestimated. A translated message had to pass the validation rules of the target format, not just the source format. A pacs.008 produced by translating an MT103 had to pass CBPR Plus validation, and if it failed, the sending bank received a pacs.002 status report with a reject reason code. An MT produced by translating a pacs.008 had to pass SWIFT network validation, and if it failed, the network returned a negative acknowledgement. For a business analyst, the translation deliverables were concrete. The mapping document listed every field, the mapping rule, the mapping type, and the behaviour when data could not be mapped exactly. The test plan covered each mapping with realistic data, including long names, long addresses, and long remittance blocks. Operations and compliance signed off on the truncation behaviour before go live, because they owned the consequences. Those documents are still useful today, because they explain why a historical payment looks the way it does, and because the same discipline applies to any future migration, such as a domestic scheme moving to ISO 20022.
Translation between MT and MX is governed by mapping rules defined by SWIFT and by the CBPR Plus usage guidelines. The rules specify, for each MT field, which MX element or elements it maps to, and for each MX element, which MT field or fields it maps from. Some mappings are straightforward, for example field 32A in an MT103, which contains value date, currency, and amount, maps to the Interbank Settlement Date, the Instructed Amount, and the currency in a pacs zero zero eight. Other mappings are more complex, because the data models are different. An MT field that contains free text may need to be split across several MX elements, or several MT fields may need to be combined into a single MX element.
Translation is not just a technical mapping, it is a business decision about what data is preserved and what data is lost. When an MX message with a full structured address is translated to MT, the address must be truncated to fit the 35 character lines of MT, and some detail will be lost. When an MT message with a 140 character remittance field is translated to MX, the remittance information can be carried as unstructured text, but it will not have the structured invoice details that a native MX message would have. The translation rules therefore include rules for truncation, for abbreviation, and for what to do when data cannot be mapped. Those rules must be documented and tested, because they determine what the beneficiary will actually see.
Analysts must also understand the difference between translation and transformation. Translation is the mapping of one format to another, while transformation is the change in business meaning that can occur during translation. For example, translating a charge bearer code from MT to MX should preserve the business meaning, but if the code lists are different, the translation may need to use a different code that has a slightly different meaning. That is a transformation risk, and it must be identified and mitigated. Your requirements should list every field that is translated, state the mapping rule, and state the expected behaviour when data cannot be mapped exactly.
Walk through the main mappings one by one. An MT103 becomes a pacs.008. Field 20, the transaction reference, maps to the instruction identification. Field 32A splits into the interbank settlement date, the instructed amount, and the currency. Field 50K becomes the debtor, field 59 becomes the creditor, field 70 becomes the remittance information, and field 71A becomes the charge bearer. An MT202 becomes a pacs.009, with field 20 mapping to the instruction identification and field 32A mapping to the settlement date and amount.
Translation in the other direction was harder, because MX carries more data than MT can hold. A pacs.008 with a full structured address had to be squeezed into four lines of 35 characters in MT field 50K or 59. Structured remittance information with several invoices had to be squeezed into 140 characters in MT field 70. Purpose codes, structured charges, and the UETR had no natural home in MT, so they were dropped or carried in free text fields where the receiving bank might not look for them. Every one of those squeezes was a place where data could be lost, and the translation rules had to say exactly what to drop and what to keep.
Validation after translation was a separate step that teams often underestimated. A translated message had to pass the validation rules of the target format, not just the source format. A pacs.008 produced by translating an MT103 had to pass CBPR Plus validation, and if it failed, the sending bank received a pacs.002 status report with a reject reason code. An MT produced by translating a pacs.008 had to pass SWIFT network validation, and if it failed, the network returned a negative acknowledgement.
For a business analyst, the translation deliverables were concrete. The mapping document listed every field, the mapping rule, the mapping type, and the behaviour when data could not be mapped exactly. The test plan covered each mapping with realistic data, including long names, long addresses, and long remittance blocks. Operations and compliance signed off on the truncation behaviour before go live, because they owned the consequences. Those documents are still useful today, because they explain why a historical payment looks the way it does, and because the same discipline applies to any future migration, such as a domestic scheme moving to ISO 20022.
Full lesson text (all scenes)
Completing a lesson updates your progress dashboard on the homepage.
Scene timestamps are estimated by allocating the narration text proportionally across the real audio length. The audio playback position is the source of truth: pause freezes the visual, seeking restores the correct scene, replay restarts the scene animation.