Payments Training Hub
Data mapping in payments NOW Data mapping in payments Pacs.008 debtor and creditor fields Name truncation rule Scheme message version Data lineage documentation Mapping acceptance criteria MESSAGE TRACE Data mapping in payments Data mapping in payments is the discipline of stating, for every field, where it comes from, where it goes, and Step 1 of 6 Data mapping in payments 1 NOW Data mapping in payments 2 Pacs.008 debtor and creditor fields 3 Name truncation rule 4 Scheme message version 5 Data lineage documentation 6 Mapping acceptance criteria Data mapping in payments is the discipline of stating, for every field, where it comes from, where it goes, and what happens to it on the way. Step 1 of 6
Pacs.008 debtor and creditor fields Data mapping in payments NOW Pacs.008 debtor and creditor fields Name truncation rule Scheme message version Data lineage documentation Mapping acceptance criteria MESSAGE TRACE Data mapping in payments > Pacs.008 debtor and creditor fields A pacs.008 has Dbtr, Cdtr, IntrBkSttlmAmt, IntrBkSttlmDt, and ChrgsInf. Step 2 of 6 Pacs.008 debtor and creditor fields 1 Data mapping in payments 2 NOW Pacs.008 debtor and creditor fields 3 Name truncation rule 4 Scheme message version 5 Data lineage documentation 6 Mapping acceptance criteria A pacs.008 has Dbtr, Cdtr, IntrBkSttlmAmt, IntrBkSttlmDt, and ChrgsInf. Step 2 of 6
Name truncation rule Data mapping in payments Pacs.008 debtor and creditor fields NOW Name truncation rule Scheme message version Data lineage documentation Mapping acceptance criteria MESSAGE TRACE Data mapping in payments > Pacs.008 debtor and creditor fields > Name truncation rule A name longer than 70 characters in the MT103 must be truncated or rejected in the pacs.008, and the Step 3 of 6 Name truncation rule 1 Data mapping in payments 2 Pacs.008 debtor and creditor fields 3 NOW Name truncation rule 4 Scheme message version 5 Data lineage documentation 6 Mapping acceptance criteria A name longer than 70 characters in the MT103 must be truncated or rejected in the pacs.008, and the mapping must state which. Step 3 of 6
Scheme message version updates Data mapping in payments Pacs.008 debtor and creditor fields Name truncation rule NOW Scheme message version Data lineage documentation Mapping acceptance criteria MESSAGE TRACE Data mapping in payments > Pacs.008 debtor and creditor fields > Name truncation rule > Scheme message version When the scheme publishes a new message version, the mapping must be updated. Step 4 of 6 Scheme message version updates 1 Data mapping in payments 2 Pacs.008 debtor and creditor fields 3 Name truncation rule 4 NOW Scheme message version 5 Data lineage documentation 6 Mapping acceptance criteria When the scheme publishes a new message version, the mapping must be updated. Step 4 of 6
Data lineage documentation Data mapping in payments Pacs.008 debtor and creditor fields Name truncation rule Scheme message version NOW Data lineage documentation Mapping acceptance criteria MESSAGE TRACE Data mapping in payments > Pacs.008 debtor and creditor fields > Name truncation rule > Scheme message version > Data lineage documentation The lineage must be documented, and the documentation must be kept up to date as systems change. Step 5 of 6 Data lineage documentation 1 Data mapping in payments 2 Pacs.008 debtor and creditor fields 3 Name truncation rule 4 Scheme message version 5 NOW Data lineage documentation 6 Mapping acceptance criteria The lineage must be documented, and the documentation must be kept up to date as systems change. Step 5 of 6
Mapping acceptance criteria Data mapping in payments Pacs.008 debtor and creditor fields Name truncation rule Scheme message version Data lineage documentation NOW Mapping acceptance criteria MESSAGE TRACE Data mapping in payments > Pacs.008 debtor and creditor fields > Name truncation rule > Scheme message version > Data lineage documentation > Mapping acceptance criteria The acceptance criteria must include a test where a payment is traced from the channel to the pacs.008, field Step 6 of 6 Mapping acceptance criteria 1 Data mapping in payments 2 Pacs.008 debtor and creditor fields 3 Name truncation rule 4 Scheme message version 5 Data lineage documentation 6 NOW Mapping acceptance criteria The acceptance criteria must include a test where a payment is traced from the channel to the pacs.008, field by field, and every field is verified against the mapping. Step 6 of 6

Flow of the explanation in this lesson.

0:00 / 6:46 Step 1 of 6

Data mapping and message mapping: field by field, MT to MX

BA practice depth, Lesson 5 of 8, Narration 6:46, D14 Business analysis and professional practice

ReconciliationCharge bearerPayment hub

What you will learn

Your objective. By the end of this lesson, you will be able to explain data mapping and message mapping: field by field, MT to mx and apply it to a real banking scenario.

Why it matters. For a business analyst, the mapping document is judged by whether a developer can build from it and a tester can test from it.

Chapter objective: Gherkin, traceability, SIT and UAT design, negative testing, defect management, root cause analysis

Key learning points

  • Data mapping in payments
  • Pacs.008 debtor and creditor fields
  • Name truncation rule
  • Scheme message version updates
  • Data lineage documentation
  • Mapping acceptance criteria

Key terms

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

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.

Payment hub: A central system in a bank that receives payment instructions from all channels, validates them, applies screening and routing rules, and sends them to the correct clearing system or correspondent.

Data mapping view showing Data mapping and message mapping: field by field, MT to MX.

Practise this lesson

Exercise

Read the pacs.008 message described in this lesson and identify its key parts.

Use the message structure, fields and example in this lesson.

  1. What to do. List the three levels of the message and name the field that carries the amount and the field that carries the end-to-end reference.

Correct result. The amount is carried in the instructed amount element and the reference in the end-to-end identification. The three levels are the group header, the payment information, and the credit transfer transaction information.

Why. A message is only useful if you can read it. The group header identifies the message, the payment information identifies the batch, and the transaction information carries the single payment.

Check your understanding

Practice question

Which of the following best describes data mapping and message mapping: field by field, MT to mx?

Takeaway and next step

What to remember

For a business analyst, the mapping document is judged by whether a developer can build from it and a tester can test from it.

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 "Process mapping and BPMN: drawing the payment flow so everyone agrees".

Transcript and full text

Show transcript

Data mapping in payments is the discipline of stating, for every field, where it comes from, where it goes, and what happens to it on the way. A mapping document has a row for each field, with the source system, the source field, the target system, the target field, the transformation rule, and the validation rule. For a payment, the source might be the channel, the target might be the pacs.008 message, and the transformation might be to convert the internal customer identifier to the debtor name and IBAN. A mapping without the transformation rule is incomplete, because the transformation is where the defects happen. Message mapping from MT to MX is the most important mapping in payments today. An MT103 has field 50a for the ordering customer, field 59a for the beneficiary, field 32A for the value date and amount, and field 71A for the charges. A pacs.008 has Dbtr, Cdtr, IntrBkSttlmAmt, IntrBkSttlmDt, and ChrgsInf. The mapping must state, for each MT field, which pacs.008 element it maps to, and what the transformation is. Field 50a option K, which carries a name and address in free text, maps to Dbtr with a structured address, and the mapping must state how the free text is parsed. Field 71A OUR maps to ChrgsInf with the code DEBT, and the mapping must state that. Transformation rules are where the defects hide. A date in the MT103 is in YYMMDD format, and in the pacs.008 it is in YYYY-MM-DD format, and the transformation must handle the century correctly. An amount in the MT103 is in the currency and amount format of field 32A, and in the pacs.008 it is a decimal with the currency as an attribute, and the transformation must preserve the exact value. A name longer than 70 characters in the MT103 must be truncated or rejected in the pacs.008, and the mapping must state which. Each transformation rule must have a test case that proves it works. Validation rules are the other half of the mapping. Each target field has a validation: the IBAN must pass the MOD 97 check, the BIC must be 8 or 11 characters, the amount must be positive, the value date must not be in the past, and the charge bearer must be one of the allowed codes. The mapping must state the validation for each field, the error code if it fails, and what happens to the payment: is it rejected, is it held, or is it corrected. A mapping without validation rules will produce messages that are rejected by the clearing system. The mapping document is a living document, not a one-time deliverable. When the scheme publishes a new message version, the mapping must be updated. When the bank adds a new payment type, the mapping must be extended. When a defect is found in production, the mapping must be checked first, because the defect is usually a mapping error. The mapping must be version controlled, and each version must state which message version it applies to, because a mapping for pacs.008.001.08 is different from a mapping for pacs.008.001.10. Data lineage is the extension of mapping to the whole payment journey. Lineage states, for every data element, every system it passes through, from the channel to the payment hub to the clearing system to the ledger to the data warehouse. Lineage matters for GDPR, because the bank must know where personal data is held, and for reconciliation, because the bank must know where a break occurred. The lineage must be documented, and the documentation must be kept up to date as systems change. A worked mapping shows one payment end to end. The MT103 carries field 50K with the value ACME Manufacturing Ltd, 12 Industrial Way, Frankfurt, field 59A with the beneficiary IBAN DE89370400440532013000, field 32A with 261107EUR12500,00, and field 71A with OUR. The pacs.008 maps 50K to Dbtr with the name and the structured address, 59A to Cdtr with the IBAN, 32A to IntrBkSttlmAmt EUR 12500.00 with IntrBkSttlmDt 2026-11-07, and 71A OUR to ChrgsInf with the code DEBT. One transformation is the date, 261107 to 2026-11-07, and one validation failure is an IBAN that fails the MOD 97 check, which rejects the payment with code AC01. For a business analyst, the mapping document is judged by whether a developer can build from it and a tester can test from it. The acceptance criteria must include a test where a payment is traced from the channel to the pacs.008, field by field, and every field is verified against the mapping. Last reviewed 7 November 2026. Further reading: the SWIFT CBPR+ usage guidelines; the ISO 20022 message definitions; the EPC SEPA message implementation guidelines; the International Institute of Business Analysis, A Guide to the Business Analysis Body of Knowledge.

Data mapping in payments is the discipline of stating, for every field, where it comes from, where it goes, and what happens to it on the way. A mapping document has a row for each field, with the source system, the source field, the target system, the target field, the transformation rule, and the validation rule. For a payment, the source might be the channel, the target might be the pacs.008 message, and the transformation might be to convert the internal customer identifier to the debtor name and IBAN. A mapping without the transformation rule is incomplete, because the transformation is where the defects happen.

Message mapping from MT to MX is the most important mapping in payments today. An MT103 has field 50a for the ordering customer, field 59a for the beneficiary, field 32A for the value date and amount, and field 71A for the charges. A pacs.008 has Dbtr, Cdtr, IntrBkSttlmAmt, IntrBkSttlmDt, and ChrgsInf. The mapping must state, for each MT field, which pacs.008 element it maps to, and what the transformation is. Field 50a option K, which carries a name and address in free text, maps to Dbtr with a structured address, and the mapping must state how the free text is parsed. Field 71A OUR maps to ChrgsInf with the code DEBT, and the mapping must state that.

Transformation rules are where the defects hide. A date in the MT103 is in YYMMDD format, and in the pacs.008 it is in YYYY-MM-DD format, and the transformation must handle the century correctly. An amount in the MT103 is in the currency and amount format of field 32A, and in the pacs.008 it is a decimal with the currency as an attribute, and the transformation must preserve the exact value. A name longer than 70 characters in the MT103 must be truncated or rejected in the pacs.008, and the mapping must state which. Each transformation rule must have a test case that proves it works.

Validation rules are the other half of the mapping. Each target field has a validation: the IBAN must pass the MOD 97 check, the BIC must be 8 or 11 characters, the amount must be positive, the value date must not be in the past, and the charge bearer must be one of the allowed codes. The mapping must state the validation for each field, the error code if it fails, and what happens to the payment: is it rejected, is it held, or is it corrected. A mapping without validation rules will produce messages that are rejected by the clearing system.

The mapping document is a living document, not a one-time deliverable. When the scheme publishes a new message version, the mapping must be updated. When the bank adds a new payment type, the mapping must be extended. When a defect is found in production, the mapping must be checked first, because the defect is usually a mapping error. The mapping must be version controlled, and each version must state which message version it applies to, because a mapping for pacs.008.001.08 is different from a mapping for pacs.008.001.10.

Data lineage is the extension of mapping to the whole payment journey. Lineage states, for every data element, every system it passes through, from the channel to the payment hub to the clearing system to the ledger to the data warehouse. Lineage matters for GDPR, because the bank must know where personal data is held, and for reconciliation, because the bank must know where a break occurred. The lineage must be documented, and the documentation must be kept up to date as systems change.

A worked mapping shows one payment end to end. The MT103 carries field 50K with the value ACME Manufacturing Ltd, 12 Industrial Way, Frankfurt, field 59A with the beneficiary IBAN DE89370400440532013000, field 32A with 261107EUR12500,00, and field 71A with OUR. The pacs.008 maps 50K to Dbtr with the name and the structured address, 59A to Cdtr with the IBAN, 32A to IntrBkSttlmAmt EUR 12500.00 with IntrBkSttlmDt 2026-11-07, and 71A OUR to ChrgsInf with the code DEBT. One transformation is the date, 261107 to 2026-11-07, and one validation failure is an IBAN that fails the MOD 97 check, which rejects the payment with code AC01.

For a business analyst, the mapping document is judged by whether a developer can build from it and a tester can test from it. The acceptance criteria must include a test where a payment is traced from the channel to the pacs.008, field by field, and every field is verified against the mapping. Last reviewed 7 November 2026. Further reading: the SWIFT CBPR+ usage guidelines; the ISO 20022 message definitions; the EPC SEPA message implementation guidelines; the International Institute of Business Analysis, A Guide to the Business Analysis Body of Knowledge.

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.