| 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
SWIFT MT103 to ISO 20022 pacs.008 Message Mapping
What you will learn
Your objective. By the end of this lesson, you will be able to explain SWIFT MT103 to ISO 20022 pacs.008 message mapping. A mapping document is a table that lists every field in the source message, the matching field in the target message, and the rule that converts one into the other, and it is the single most important deliverable of the.
Why it matters. Mappings fall into three types, and the analyst must label each one.
Chapter objective: Learner completes a capstone project that designs an end-to-end payment solution for a stated business problem, integrating messages, rails, controls, and operations into one coherent proposal. Learner demonstrates this skill using realistic banking examples, explaining each step clearly and using correct terminology throughout.
Key learning points
- Mapping document
- Mappings fall into three types
- Message identification
- Field 50K
- Analyst documents a parsing rule
- Only when the sample passes with zero
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.
Purpose code: A code that states the commercial reason for a payment, such as supplier payment, salary or goods. Purpose codes are taken from an ISO external code list and support regulatory reporting, screening...
SWIFT MT message viewer showing SWIFT MT103 to ISO 20022 pacs.008 Message Mapping.
Practise this lesson
Exercise
Read the MT103 is message described in this lesson and identify its key parts.
Use the message structure, fields and example in this lesson.
- What to do. List the main blocks of the message, name the field that carries the amount, and name the field that identifies the payment.
Correct result. The message is made of blocks, each carrying a part of the payment instruction. The amount field and the identification field are the two a receiving bank checks first, because without them it cannot process or reconcile the payment.
Why. A message is only useful if you can read it. The blocks tell the receiving bank what to do, and the amount and identification fields are what it checks first.
Check your understanding
Practice question
A capstone project asks a learner to design a cross-border payment flow for a fictional bank. The learner designs only the happy path. What is missing, and why does it matter?
Takeaway and next step
What to remember
In pacs.008, the message identification, the instructed amount, the debtor agent and the creditor agent are mandatory, which means the conversion must always produce them or the message fails schema validation.
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 "Capstone Brief: BA on a SWIFT MT to ISO 20022 Migration".
Transcript and full text
Show transcript
A mapping document is a table that lists every field in the source message, the matching field in the target message, and the rule that converts one into the other, and it is the single most important deliverable of the migration. The MT103 is a free-text based message with numbered fields such as 20 for the transaction reference, 32A for the value date, currency and amount, 50K for the ordering customer, 59 for the beneficiary, and 70 for the remittance information. The pacs.008 is a structured XML message with named elements such as Group Header, Payment Information and Credit Transfer Transaction Information, and every MT field must be placed into the right element. Mappings fall into three types, and the analyst must label each one. A direct mapping copies a field unchanged, such as the transaction reference in field 20 going straight into the message identification element. A derived mapping calculates a value from one or more source fields, such as building the instructed amount in pacs.008 from the currency and amount in field 32A. A translated mapping converts a value from one code set to another, such as converting the charge code in field 71A from OUR to DEBT, BEN to CRED, and SHA to SHAR in the charge bearer element of pacs.008. Mandatory and optional fields must be handled differently. In pacs.008, the message identification, the instructed amount, the debtor agent and the creditor agent are mandatory, which means the conversion must always produce them or the message fails schema validation. Fields such as the remittance information and the purpose code are optional, but the bank's policy may make them mandatory for certain corridors, for example purpose codes are required for all payments to India above 50,000 rupees. The mapping document records the pacs.008 requirement and the bank's own rule side by side, so there is no confusion about which one governs. The hardest problem in the migration is the parsing of fields 50K and 59, because both are free-text fields with no fixed structure. Field 50K holds the ordering customer, and a typical value looks like four lines. The account number, the name, and two lines of address, with no labels to say which line is which. Field 59 holds the beneficiary in the same loose format. The conversion engine must split these lines, decide which line is the name and which lines are the address, and place them into the structured debtor and creditor elements of pacs.008, which have separate elements for name, postal address and account identification. The parsing problem gets worse with real data. Some customers write the account number on the first line and some write it on the second, some include a country code and some do not, and some addresses run to three lines while others fit in one. The analyst documents a parsing rule for each pattern found in a sample of 5,000 real messages. If the first line matches the pattern of an account number, treat it as the account, and treat the next line as the name. Messages that do not match any known pattern are sent to a manual repair queue, and the mapping document records the expected repair rate, which the operations team uses to plan staffing. The mapping document is validated by running a sample conversion and checking the results field by field. The team takes 1,000 real MT103 messages, converts them, and compares the pacs.008 output against the mapping rules. Any field that is empty when it should be populated, any amount that does not match, or any name that is truncated is logged as a mapping defect and fixed in the document. Only when the sample passes with zero critical defects does the mapping document go for sign-off, because every downstream deliverable, from user stories to test cases, depends on it being correct.
A mapping document is a table that lists every field in the source message, the matching field in the target message, and the rule that converts one into the other, and it is the single most important deliverable of the migration. The MT103 is a free-text based message with numbered fields such as 20 for the transaction reference, 32A for the value date, currency and amount, 50K for the ordering customer, 59 for the beneficiary, and 70 for the remittance information. The pacs.008 is a structured XML message with named elements such as Group Header, Payment Information and Credit Transfer Transaction Information, and every MT field must be placed into the right element.
Mappings fall into three types, and the analyst must label each one. A direct mapping copies a field unchanged, such as the transaction reference in field 20 going straight into the message identification element. A derived mapping calculates a value from one or more source fields, such as building the instructed amount in pacs.008 from the currency and amount in field 32A. A translated mapping converts a value from one code set to another, such as converting the charge code in field 71A from OUR to DEBT, BEN to CRED, and SHA to SHAR in the charge bearer element of pacs.008.
Mandatory and optional fields must be handled differently. In pacs.008, the message identification, the instructed amount, the debtor agent and the creditor agent are mandatory, which means the conversion must always produce them or the message fails schema validation. Fields such as the remittance information and the purpose code are optional, but the bank's policy may make them mandatory for certain corridors, for example purpose codes are required for all payments to India above 50,000 rupees. The mapping document records the pacs.008 requirement and the bank's own rule side by side, so there is no confusion about which one governs.
The hardest problem in the migration is the parsing of fields 50K and 59, because both are free-text fields with no fixed structure. Field 50K holds the ordering customer, and a typical value looks like four lines. The account number, the name, and two lines of address, with no labels to say which line is which. Field 59 holds the beneficiary in the same loose format. The conversion engine must split these lines, decide which line is the name and which lines are the address, and place them into the structured debtor and creditor elements of pacs.008, which have separate elements for name, postal address and account identification.
The parsing problem gets worse with real data. Some customers write the account number on the first line and some write it on the second, some include a country code and some do not, and some addresses run to three lines while others fit in one. The analyst documents a parsing rule for each pattern found in a sample of 5,000 real messages. If the first line matches the pattern of an account number, treat it as the account, and treat the next line as the name. Messages that do not match any known pattern are sent to a manual repair queue, and the mapping document records the expected repair rate, which the operations team uses to plan staffing.
The mapping document is validated by running a sample conversion and checking the results field by field. The team takes 1,000 real MT103 messages, converts them, and compares the pacs.008 output against the mapping rules. Any field that is empty when it should be populated, any amount that does not match, or any name that is truncated is logged as a mapping defect and fixed in the document. Only when the sample passes with zero critical defects does the mapping document go for sign-off, because every downstream deliverable, from user stories to test cases, depends on it being correct.
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.