Payments Academy
Same payment as MT103 and pacs.008 PAYMENT OPERATIONS STARTED LIVE 01 Same payment as MT103 and pacs.008 - can be written as an MT103 and as a ACTIVE 02 MT103 numbered fields - Field 50K is the ordering customer QUEUED 03 Pacs.008 named elements - field by field mapping shows what was gained QUEUED 04 Field by field mapping and truncation - business analyst who maps MT to MX QUEUED 05 Mapping failures and recovery - If a field is mapped to the wrong element QUEUED 06 Mapping test - Takeaway: the same USD 25,000 payment QUEUED The same payment can be written as an MT103 and as a pacs.008, and comparing the two field by field is the fastest way to understand why ISO 20022 replaced MT. Step 1 of 6 Same payment as MT103 and pacs.008 STARTED Same payment as MT103 and pacs.008 can be written as an MT103 and as a ACTIVE MT103 numbered fields Field 50K is the ordering customer QUEUED Pacs.008 named elements field by field mapping shows what was gained QUEUED Field by field mapping and truncation business analyst who maps MT to MX must QUEUED Mapping failures and recovery If a field is mapped to the wrong element QUEUED Mapping test Takeaway: the same USD 25,000 payment QUEUED The same payment can be written as an MT103 and as a pacs.008, and comparing the two field by field is the fastest way to understand why ISO 20022 replaced MT.
MT103 numbered fields PAYMENT OPERATIONS IN PROGRESS LIVE 01 Same payment as MT103 and pacs.008 - can be written as an MT103 and as a DONE 02 MT103 numbered fields - Field 50K is the ordering customer ACTIVE 03 Pacs.008 named elements - field by field mapping shows what was gained QUEUED 04 Field by field mapping and truncation - business analyst who maps MT to MX QUEUED 05 Mapping failures and recovery - If a field is mapped to the wrong element QUEUED 06 Mapping test - Takeaway: the same USD 25,000 payment QUEUED Field 50K is the ordering customer, with the name and address on lines of 35 characters each. Step 2 of 6 MT103 numbered fields IN PROGRESS Same payment as MT103 and pacs.008 can be written as an MT103 and as a DONE MT103 numbered fields Field 50K is the ordering customer ACTIVE Pacs.008 named elements field by field mapping shows what was gained QUEUED Field by field mapping and truncation business analyst who maps MT to MX must QUEUED Mapping failures and recovery If a field is mapped to the wrong element QUEUED Mapping test Takeaway: the same USD 25,000 payment QUEUED Field 50K is the ordering customer, with the name and address on lines of 35 characters each.
pacs.008 named elements PAYMENT OPERATIONS IN PROGRESS LIVE 01 Same payment as MT103 and pacs.008 - can be written as an MT103 and as a DONE 02 MT103 numbered fields - Field 50K is the ordering customer DONE 03 Pacs.008 named elements - field by field mapping shows what was gained ACTIVE 04 Field by field mapping and truncation - business analyst who maps MT to MX QUEUED 05 Mapping failures and recovery - If a field is mapped to the wrong element QUEUED 06 Mapping test - Takeaway: the same USD 25,000 payment QUEUED The field by field mapping shows what was gained and what was lost in the migration. Step 3 of 6 pacs.008 named elements IN PROGRESS Same payment as MT103 and pacs.008 can be written as an MT103 and as a DONE MT103 numbered fields Field 50K is the ordering customer DONE Pacs.008 named elements field by field mapping shows what was gained ACTIVE Field by field mapping and truncation business analyst who maps MT to MX must QUEUED Mapping failures and recovery If a field is mapped to the wrong element QUEUED Mapping test Takeaway: the same USD 25,000 payment QUEUED The field by field mapping shows what was gained and what was lost in the migration.
Field by field mapping and truncation PAYMENT OPERATIONS IN PROGRESS LIVE 01 Same payment as MT103 and pacs.008 - can be written as an MT103 and as a DONE 02 MT103 numbered fields - Field 50K is the ordering customer DONE 03 Pacs.008 named elements - field by field mapping shows what was gained DONE 04 Field by field mapping and truncation - business analyst who maps MT to MX ACTIVE 05 Mapping failures and recovery - If a field is mapped to the wrong element QUEUED 06 Mapping test - Takeaway: the same USD 25,000 payment QUEUED A business analyst who maps MT to MX must state Step 4 of 6 Field by field mapping and truncation IN PROGRESS Same payment as MT103 and pacs.008 can be written as an MT103 and as a DONE MT103 numbered fields Field 50K is the ordering customer DONE Pacs.008 named elements field by field mapping shows what was gained DONE Field by field mapping and truncation business analyst who maps MT to MX must ACTIVE Mapping failures and recovery If a field is mapped to the wrong element QUEUED Mapping test Takeaway: the same USD 25,000 payment QUEUED A business analyst who maps MT to MX must state
Mapping failures and recovery PAYMENT OPERATIONS IN PROGRESS LIVE 01 Same payment as MT103 and pacs.008 - can be written as an MT103 and as a DONE 02 MT103 numbered fields - Field 50K is the ordering customer DONE 03 Pacs.008 named elements - field by field mapping shows what was gained DONE 04 Field by field mapping and truncation - business analyst who maps MT to MX DONE 05 Mapping failures and recovery - If a field is mapped to the wrong element ACTIVE 06 Mapping test - Takeaway: the same USD 25,000 payment QUEUED If a field is mapped to the wrong element Step 5 of 6 Mapping failures and recovery IN PROGRESS Same payment as MT103 and pacs.008 can be written as an MT103 and as a DONE MT103 numbered fields Field 50K is the ordering customer DONE Pacs.008 named elements field by field mapping shows what was gained DONE Field by field mapping and truncation business analyst who maps MT to MX must DONE Mapping failures and recovery If a field is mapped to the wrong element ACTIVE Mapping test Takeaway: the same USD 25,000 payment QUEUED If a field is mapped to the wrong element
Mapping test for a BA PAYMENT OPERATIONS COMPLETE LIVE 01 Same payment as MT103 and pacs.008 - can be written as an MT103 and as a DONE 02 MT103 numbered fields - Field 50K is the ordering customer DONE 03 Pacs.008 named elements - field by field mapping shows what was gained DONE 04 Field by field mapping and truncation - business analyst who maps MT to MX DONE 05 Mapping failures and recovery - If a field is mapped to the wrong element DONE 06 Mapping test - Takeaway: the same USD 25,000 payment ACTIVE Takeaway: the same USD 25,000 payment is an MT103 with numbered fields and 140 characters of remittance, and a pacs.008 with named elements, structured addresses and structured remittance. Step 6 of 6 Mapping test for a BA COMPLETE Same payment as MT103 and pacs.008 can be written as an MT103 and as a DONE MT103 numbered fields Field 50K is the ordering customer DONE Pacs.008 named elements field by field mapping shows what was gained DONE Field by field mapping and truncation business analyst who maps MT to MX must DONE Mapping failures and recovery If a field is mapped to the wrong element DONE Mapping test Takeaway: the same USD 25,000 payment ACTIVE Takeaway: the same USD 25,000 payment is an MT103 with numbered fields and 140 characters of remittance, and a pacs.008 with named elements, structured addresses and structured remittance.

Key points of this lesson, in order.

0:00 / 13:37 Step 1 of 6

MT versus MX worked comparison: the same payment as MT103 and as pacs.008, field by field

ISO 20022 Fundamentals, Lesson 9 of 10, Narration 13:37, D04 Messaging and standards

Remittance informationExecution dateReconciliation

What you will learn

Your objective. By the end of this lesson, you will be able to explain MT versus mx worked comparison: the same payment as MT103 and as pacs.008, field by field. The same payment can be written as an MT103 and as a pacs.008, and comparing the two field by field is the fastest way to understand why ISO 20022 replaced MT.

Why it matters. Takeaway: the same USD 25,000 payment is an MT103 with numbered fields and 140 characters of remittance, and a pacs.008 with named elements, structured addresses and structured remittance.

Chapter objective: Learner explains ISO 20022 structure, including business concepts, message definitions, XML syntax, and the roles of pacs, pain, camt, and admi messages, and navigates the message catalogue confidently. Learner practises this skill on realistic banking cases, explaining the reasoning clearly and using correct terminology throughout the work.

Key learning points

  • Same payment as MT103 and pacs.008
  • MT103 numbered fields
  • pacs.008 named elements
  • Field by field mapping and truncation
  • Mapping failures and recovery
  • Mapping test for a BA

Key terms

Remittance information: Information that explains what a payment is for, such as invoice numbers, contract references or salary month.

Execution date: The date on which the bank executes a payment instruction, debiting the debtor account and sending the message onward.

Reconciliation: The process of comparing records from two sources, such as a bank statement and an internal ledger, to confirm they agree.

SWIFT MT message viewer showing MT versus MX worked comparison: the same payment as MT103 and as pacs.008, field by field.

Insights and practice scenarios

Worked insights and practice scenarios for this lesson. Each one is a reusable PaymentForge case, so the same case may appear in more than one lesson.

Practise this lesson

Exercise

Take the USD 25,000 payment in this lesson and map it field by field from MT103 to pacs.008, stating the mapping type for each field.

Use the mapping: field 20 to MsgId and EndToEndId, field 32A split into execution date, settlement date and amount, field 50K to structured debtor, field 70 to structured remittance.

  1. What to do. For each field state whether the mapping is direct, split, derived or needs care, and what is gained or truncated.

Correct result. Field 20 maps directly to MsgId and EndToEndId, with two references where MT103 carried one. Field 32A splits into ReqdExctnDt, Interbank Settlement Date and InstdAmt. Field 50K becomes a structured debtor with a structured address, richer than 35-character lines. Field 70 becomes structured remittance, carrying all five invoices instead of 140 characters of free text. Field 71A maps to ChrgBr, SHA to SHAR. Truncation risk sits in long beneficiary names mapped to structured addresses.

Why. State the mapping type for every field and test it with a real payment.

Check your understanding

Practice question

In the MT103 to pacs.008 mapping, what happens to field 32A?

Takeaway and next step

What to remember

Takeaway: the same USD 25,000 payment is an MT103 with numbered fields and 140 characters of remittance, and a pacs.008 with named elements, structured addresses and structured remittance.

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 "ISO 20022 fundamentals with annotated XML samples".

Transcript and full text

Show transcript

The same payment can be written as an MT103 and as a pacs.008, and comparing the two field by field is the fastest way to understand why ISO 20022 replaced MT. The payment in this lesson is a customer payment of USD 25,000 from a customer of Bank A in London to a supplier at Bank B in New York, with the remittance reference for invoice INV-2026-3045, and the charge arrangement SHA, so the charges are shared. The MT103 is the SWIFT MT message that carried this payment before the CBPR+ migration, and the pacs.008 is the ISO 20022 message that carries it now, after the end of coexistence on 22 November 2025 for in-scope FI to FI payment instructions. Source: SWIFT, MT103 message definition and CBPR+ usage guidelines; ISO 20022, pacs.008.001.08; SWIFT, end of coexistence 22 Nov 2025. In the MT103 the payment is written as a series of numbered fields, each with a short tag and a compact format. Field 20 is the transaction reference, with value PAY20261109-001. Field 32A is the value date, currency and amount, with value 261109USD25000, which is the date 9 November 2026, the currency USD and the amount 25,000. Field 50K is the ordering customer, with the name and address on lines of 35 characters each. Field 59 is the beneficiary customer, with the name and account on lines of 35 characters each. Field 71A is the details of charges, with value SHA, and field 71F is the sender charges, if any. The MT103 is compact, it fits on a page, and it is hard to read without knowing the field tags, because the tags are numbers, not names. In the pacs.008 the same payment is written as named XML elements, each with a descriptive name and a structured value. The Group Header carries MsgId with value BANKA20261109-001, CreDtTm with value 2026-11-09T10:00:00, NbOfTxs with value 1, and CtrlSum with value 25000. The Credit Transfer Transaction Information carries EndToEndId with value INV-2026-3045, InstdAmt with currency USD and value 25000, Cdtr with the full name and a structured address, CdtrAcct, CdtrAgt, ChrgBr with value SHAR, and RmtInf with the structured remittance, including the invoice number as a structured reference. The pacs.008 is longer, it is self-describing, and it can be read without a field dictionary, because the element names say what the data is. The field by field mapping shows what was gained and what was lost in the migration. Field 20, the transaction reference, maps to the MsgId and the EndToEndId in the pacs.008, and the mapping is direct, because both are references, but the pacs.008 separates the execution date from the settlement date, while the MT103 combined them. Field 50K, the ordering customer, maps to the Dbtr and the DbtrAcct, and the mapping is richer, because the pacs.008. Field 70, the remittance information, maps to the RmtInf, and the mapping is richer, because the pacs.008 can carry structured remittance with invoice numbers and amounts, while the MT103 was limited to 140 characters of free text. The mapping also shows what was lost or truncated, and truncation is the risk that the migration had to manage. Field 71A, the charge arrangement, maps to the ChrgBr element, and the values map as OUR to DEBT, SHA to SHAR and BEN to CRED, so the mapping is direct, but the pacs.008 also carries the charge amount in a separate element, which the MT103 carried only in field 71F. A business analyst who maps MT to MX must state, for each field, whether the mapping is direct, split, derived or needs care, and must test the mapping with a real payment, because a mapping that looks direct on paper can truncate in practice. A worked example shows the mapping in a project. A bank migrates a corporate customer from MT103 to pacs.008, and the customer sends a payment with a remittance of 200 characters, listing five invoices. In the MT103 the remittance was truncated to 140 characters, so the beneficiary could reconcile only three invoices, and the other two were reconciled manually. In the pacs.008. The business case for the migration is therefore not just a technical change, it is a reconciliation saving, and the analyst must quantify it: five invoices reconciled automatically, instead of three, saves the beneficiary 30 minutes per payment, and at 100 payments per month, that is 50 hours per month. The mapping is the evidence, and the worked example is the business case. Failure in the comparison is a mapping failure, and the recovery is to fix the mapping, not the payment. If a field is mapped to the wrong element, for example the ordering customer mapped to the creditor, the payment will be sent to the wrong party, and the fix is a recall with a camt.056, which can take days. If the charge arrangement is mapped wrongly, for example SHA mapped to DEBT, the beneficiary will receive the wrong amount, and the fix is a second payment for the shortfall, with a second fee. Each mapping error is found by testing the mapping with a real payment, field by field, before the migration goes live. For a business analyst, product owner or subject matter expert, the test is to take any MT103 and to write the equivalent pacs.008, field by field, and to state the mapping type for each field. Ask how the end to end reference is preserved, how the structured address is built from the 35-character lines, and how the remittance is carried. Ask how the mapping is tested, with which payments, and what the acceptance criteria are. The SWIFT CBPR+ usage guidelines and the ISO 20022 pacs.008 message definition are the sources for the mapping, and the MT103 message definition is the source for the MT fields, and all three must be cited in the migration specification. Takeaway: the same USD 25,000 payment is an MT103 with numbered fields and 140 characters of remittance, and a pacs.008 with named elements, structured addresses and structured remittance. Field 20 maps to MsgId and EndToEndId, field 32A splits into execution date, settlement date and amount, field 50K becomes a structured debtor, and field 70 becomes a structured remittance. State the mapping type for every field and test it with a real payment. Further reading: SWIFT, MT103 message definition and CBPR+ usage guidelines; ISO 20022, pacs.008.001.08; SWIFT, end of coexistence 22 Nov 2025. Last reviewed 7 November 2026.

The same payment can be written as an MT103 and as a pacs.008, and comparing the two field by field is the fastest way to understand why ISO 20022 replaced MT. The payment in this lesson is a customer payment of USD 25,000 from a customer of Bank A in London to a supplier at Bank B in New York, with the remittance reference for invoice INV-2026-3045, and the charge arrangement SHA, so the charges are shared. The MT103 is the SWIFT MT message that carried this payment before the CBPR+ migration, and the pacs.008 is the ISO 20022 message that carries it now, after the end of coexistence on 22 November 2025 for in-scope FI to FI payment instructions. Source: SWIFT, MT103 message definition and CBPR+ usage guidelines; ISO 20022, pacs.008.001.08; SWIFT, end of coexistence 22 Nov 2025.

In the MT103 the payment is written as a series of numbered fields, each with a short tag and a compact format. Field 20 is the transaction reference, with value PAY20261109-001. Field 32A is the value date, currency and amount, with value 261109USD25000, which is the date 9 November 2026, the currency USD and the amount 25,000. Field 50K is the ordering customer, with the name and address on lines of 35 characters each. Field 59 is the beneficiary customer, with the name and account on lines of 35 characters each. Field 71A is the details of charges, with value SHA, and field 71F is the sender charges, if any. The MT103 is compact, it fits on a page, and it is hard to read without knowing the field tags, because the tags are numbers, not names.

In the pacs.008 the same payment is written as named XML elements, each with a descriptive name and a structured value. The Group Header carries MsgId with value BANKA20261109-001, CreDtTm with value 2026-11-09T10:00:00, NbOfTxs with value 1, and CtrlSum with value 25000. The Credit Transfer Transaction Information carries EndToEndId with value INV-2026-3045, InstdAmt with currency USD and value 25000, Cdtr with the full name and a structured address, CdtrAcct, CdtrAgt, ChrgBr with value SHAR, and RmtInf with the structured remittance, including the invoice number as a structured reference. The pacs.008 is longer, it is self-describing, and it can be read without a field dictionary, because the element names say what the data is.

The field by field mapping shows what was gained and what was lost in the migration. Field 20, the transaction reference, maps to the MsgId and the EndToEndId in the pacs.008, and the mapping is direct, because both are references, but the pacs.008 separates the execution date from the settlement date, while the MT103 combined them. Field 50K, the ordering customer, maps to the Dbtr and the DbtrAcct, and the mapping is richer, because the pacs.008. Field 70, the remittance information, maps to the RmtInf, and the mapping is richer, because the pacs.008 can carry structured remittance with invoice numbers and amounts, while the MT103 was limited to 140 characters of free text.

The mapping also shows what was lost or truncated, and truncation is the risk that the migration had to manage. Field 71A, the charge arrangement, maps to the ChrgBr element, and the values map as OUR to DEBT, SHA to SHAR and BEN to CRED, so the mapping is direct, but the pacs.008 also carries the charge amount in a separate element, which the MT103 carried only in field 71F. A business analyst who maps MT to MX must state, for each field, whether the mapping is direct, split, derived or needs care, and must test the mapping with a real payment, because a mapping that looks direct on paper can truncate in practice.

A worked example shows the mapping in a project. A bank migrates a corporate customer from MT103 to pacs.008, and the customer sends a payment with a remittance of 200 characters, listing five invoices. In the MT103 the remittance was truncated to 140 characters, so the beneficiary could reconcile only three invoices, and the other two were reconciled manually. In the pacs.008. The business case for the migration is therefore not just a technical change, it is a reconciliation saving, and the analyst must quantify it: five invoices reconciled automatically, instead of three, saves the beneficiary 30 minutes per payment, and at 100 payments per month, that is 50 hours per month. The mapping is the evidence, and the worked example is the business case.

Failure in the comparison is a mapping failure, and the recovery is to fix the mapping, not the payment. If a field is mapped to the wrong element, for example the ordering customer mapped to the creditor, the payment will be sent to the wrong party, and the fix is a recall with a camt.056, which can take days. If the charge arrangement is mapped wrongly, for example SHA mapped to DEBT, the beneficiary will receive the wrong amount, and the fix is a second payment for the shortfall, with a second fee. Each mapping error is found by testing the mapping with a real payment, field by field, before the migration goes live.

For a business analyst, product owner or subject matter expert, the test is to take any MT103 and to write the equivalent pacs.008, field by field, and to state the mapping type for each field. Ask how the end to end reference is preserved, how the structured address is built from the 35-character lines, and how the remittance is carried. Ask how the mapping is tested, with which payments, and what the acceptance criteria are. The SWIFT CBPR+ usage guidelines and the ISO 20022 pacs.008 message definition are the sources for the mapping, and the MT103 message definition is the source for the MT fields, and all three must be cited in the migration specification.

Takeaway: the same USD 25,000 payment is an MT103 with numbered fields and 140 characters of remittance, and a pacs.008 with named elements, structured addresses and structured remittance. Field 20 maps to MsgId and EndToEndId, field 32A splits into execution date, settlement date and amount, field 50K becomes a structured debtor, and field 70 becomes a structured remittance. State the mapping type for every field and test it with a real payment. Further reading: SWIFT, MT103 message definition and CBPR+ usage guidelines; ISO 20022, pacs.008.001.08; SWIFT, end of coexistence 22 Nov 2025. Last reviewed 7 November 2026.

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.