| Aspect | Detail |
|---|---|
| Four identifiers do most of the | A common source of errors |
| Group header | The first block in most ISO 20022 messages |
| Transaction information | The block that describes one payment inside the message |
| The business application | The business application header, head.001, wraps the business message with routing |
| Correlation follows a | Correlation follows a payment through its whole life by matching identifiers across |
Message Identification, Correlation, Group Header vs Transaction Info, and the Business Application Header
What you will learn
Your objective. By the end of this lesson, you will be able to explain message identification, correlation, group header vs transaction info. Four identifiers do most of the work in ISO 20022, and confusing them is a common source of errors.
Why it matters. An operations analyst who can follow those identifiers across five messages can answer a customer query in minutes, while an analyst who searches only by amount may find several payments of EUR 8,750.00 and choose the wrong one.
Chapter objective: Learner navigates the complete ISO 20022 catalogue, selecting the right message for each business scenario across payments, cash management, securities, and reporting. Learner practises this skill on realistic banking cases, explaining the reasoning clearly and using correct terminology throughout the work.
Key learning points
- Four key identifiers
- Group header
- Transaction information
- Business application header
- Payment correlation across messages
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.
ISO 20022: An international standard for financial messaging that defines XML message formats for payments, securities and trade.
Comparison table showing Message Identification, Correlation, Group Header vs Transaction Info, and the Business Application Header.
Practise this lesson
Exercise
Scenario: you are a payments BA writing a mapping specification. A corporate customer sends a pain.001 credit transfer initiation for EUR 25,000 from Munich to a supplier in Lyon. Your bank must convert it into a pacs.008 customer credit transfer to send through STEP2. Map the pain.001 to the pacs.008 field by field. For each pacs.008 field, state the source pain.001 field, the value, and any transformation needed.
The pain.001 contains: Group Header (message identification MSG-20261110-001, creation date and time 2026-11-10T09:00:00, number of transactions 1, control sum 25000.00, initiating party Atlas GmbH). Payment Information (payment information identification PmtInf-001, payment method TRF, requested execution date 2026-11-10, debtor Atlas GmbH, debtor account DE89370400440532013000, debtor agent DEUTDEFF, charge bearer SLEV). Credit Transfer Transaction (instruction identification Instr-001, end to end identification E2E-5520, instructed amount EUR 25000.00, creditor agent BNPAFRPP, creditor Loire Vins SARL, creditor account FR1420041010050500013M02606, remittance information INV-5520).
- What to do. Build a mapping table with four columns: pacs.008 field, pain.001 source field, value, transformation or rule. Cover at minimum GrpHdr, PmtId, IntrBkSttlmAmt, IntrBkSttlmDt, SttlmInf, Dbtr, DbtrAcct, DbtrAgt, CdtrAgt, Cdtr, CdtrAcct, ChrgsInf and RmtInf. Then state which pain.001 fields have no pacs.008 equivalent and what happens to them.
Correct result. Mapping: GrpHdr MsgId comes from pain.001 GrpHdr MsgId MSG-20261110-001. PmtId InstrId comes from CdtTrfTxInf PmtId InstrId Instr-001. PmtId EndToEndId comes from CdtTrfTxInf PmtId EndToEndId E2E-5520. IntrBkSttlmAmt EUR 25000.00 comes from CdtTrfTxInf Amt InstdAmt EUR 25000.00, no transformation. IntrBkSttlmDt 2026-11-10 comes from PmtInf ReqdExctnDt. SttlmInf SttlmMtd CLRG comes from the bank routing decision (STEP2 clearing), not from the pain.001. Dbtr Nm Atlas GmbH comes from PmtInf Dbtr Nm. DbtrAcct IBAN DE89370400440532013000 comes from PmtInf DbtrAcct Id IBAN. DbtrAgt FinInstnId BICFI DEUTDEFF comes from PmtInf DbtrAgt. CdtrAgt FinInstnId BICFI BNPAFRPP comes from CdtTrfTxInf CdtrAgt. Cdtr Nm Loire Vins SARL comes from CdtTrfTxInf Cdtr Nm. CdtrAcct IBAN FR1420041010050500013M02606 comes from CdtTrfTxInf CdtrAcct. ChrgsInf ChrgsBr SLEV comes from PmtInf ChrgsBr SLEV, mapped to the pacs.008 charge bearer code SLEV. RmtInf Ustrd INV-5520 comes from CdtTrfTxInf RmtInf Ustrd. Fields with no pacs.008 equivalent: the pain.001 Payment Information identification PmtInf-001 is not carried into pacs.008; it is kept in the bank system for reconciliation. The control sum is a pain.001 group-level check and is not carried into pacs.008. Worked reasoning: the debtor and creditor agents are BICs in both messages, so they copy across unchanged. The amount and currency copy across unchanged. The settlement method CLRG is a bank decision, not a customer instruction, so it is added by the bank. The charge bearer SLEV means the charges follow the service level agreement, and the pacs.008 carries the same code.
Why. Hint 1: start from the pacs.008 fields and work backwards to the pain.001; do not start from the pain.001 and guess where each field goes. Hint 2: the debtor agent and creditor agent are BICs in both messages, so they copy unchanged. Hint 3: settlement method and clearing system are bank decisions, not customer data, so they are added during conversion. The worked explanation shows the mapping discipline: every pacs.008 field must have a named source or an explicit rule for how it is derived, and any pain.001 field with no pacs.008 equivalent must be recorded as dropped or retained in the bank system.
Check your understanding
Practice question
Which of the following best describes message identification, correlation, group header vs transaction info?
Takeaway and next step
What to remember
An operations analyst who can follow those identifiers across five messages can answer a customer query in minutes, while an analyst who searches only by amount may find several payments of EUR 8,750.00 and choose the wrong one.
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 "Cash Management: camt.029, camt.052, camt.053, camt.054, camt.056 in Depth".
Transcript and full text
Show transcript
Message identification in ISO 20022 is carried in the message identification element, MsgId, in the group header. MsgId is a reference the sender gives the message, and it must be unique for the sender. It is normally a combination of the sender identifier, the date, and a sequence number, for example BANKGB22-20260512-000001. The receiving bank uses MsgId to detect duplicates. If it receives two messages with the same MsgId from the same sender, it will treat the second as a duplicate and reject it, or it will query the sender. The MsgId is therefore a control, and it must be generated correctly. A system that reuses a MsgId, or that generates a MsgId that is not unique, will cause duplicate rejections and will confuse the reconciliation. Correlation is the linking of a message to the message it responds to, or to the original instruction. Correlation is carried in the original references. A pacs.002 status report carries the original message identification, OrgnlMsgId, and the original instruction identification, OrgnlInstrId, and the original end to end identification, OrgnlEndToEndId, so the receiving bank can match the status report to the original payment. A pacs.004 return carries the original instruction identification and the original end to end identification, so the sending bank can match the return to the original payment. A camt.029 resolution carries the original message identification, so the requesting bank can match the resolution to its investigation. Without correlation, a status report or a return is an orphan, and the bank cannot process it. The unique end to end transaction reference, UETR, is the identifier that follows a payment from end to end, across all banks and all messages. The UETR is a UUID, a 36 character identifier in the format 8-4-4-4-12, for example 123e4567-e89b-12d3-a456-426614174000. It is generated by the first bank in the chain, and it is carried in every message that relates to the payment, in the pacs.008, the pacs.002, the pacs.004, and the camt.054. The UETR is the key to SWIFT gpi tracking, because the gpi tracker uses the UETR to follow the payment across banks and to report its status to the customer. An SME must know that the UETR is generated once, by the first bank, and that it must not be changed by any bank in the chain. A bank that generates a new UETR for a payment that already has one will break the tracking, and the customer will lose visibility. The group header versus the transaction information is the structural distinction in ISO 20022. The group header, GrpHdr, carries the information about the message as a whole, the MsgId, the CreDtTm, the NbOfTxs, the CtrlSum, the settlement information, and the instructing and instructed agents. The transaction information block, for example CdtTrfTxInf in a pacs.008, carries the information about one payment, the PmtId, the amount, the debtor, the creditor, and the remittance information. A message with 40 payments has one group header and 40 transaction information blocks. The group header is the control, and the transaction information is the payment. An SME must keep them apart, because a field in the group header applies to the whole message, and a field in the transaction information applies to one payment only. The business application header, head.001, is the envelope that carries the business message. It is a separate message, wrapped around the business message, and it carries the sender, Fr, the receiver, To, the business message identifier, BizMsgIdr, the message definition identifier, MsgDefIdr, which states the message type and version, for example pacs.008.001.08, the business service, BizSvc, which states the service, for example swift.cbprplus.02, and the creation date and time, CreDt. The head.001 is the wrapper, and the business message is the content. The payment system reads the head.001 first, to determine the message type, the sender, and the receiver, and then it processes the business message. An SME must understand the head.001, because it is where the message type and version are stated, and it is the part of the message that the system uses for routing and for duplicate detection. Duplicate detection uses the BizMsgIdr in the head.001, combined with the MsgId in the group header. The receiving bank stores the BizMsgIdr for each message it receives, and if it receives a message with a BizMsgIdr it has already seen, it will treat it as a duplicate and reject it. The BizMsgIdr must therefore be unique, and it must be generated correctly. A system that reuses a BizMsgIdr, or that generates a BizMsgIdr that is not unique, will cause the receiving bank to reject a legitimate message as a duplicate, or to accept a duplicate as a new message. Both are serious errors. The BizMsgIdr is normally the same as the MsgId, or it is derived from it, and the system must ensure that it is unique for the sender. For a business analyst, the identification and correlation requirement must state the MsgId generation rule, the UETR generation rule, the BizMsgIdr generation rule, and the correlation fields. The requirement should say that the system generates a unique MsgId for each message, that it generates a UETR for each payment and carries it in every related message, that it generates a unique BizMsgIdr, and that it carries the original references in every status report, return, and resolution, so that each message can be matched to the original payment. A system that cannot correlate a pacs.002 to its pacs.008 cannot report the status of a payment, and a system that cannot generate a unique UETR cannot support gpi tracking.
Message identification in ISO 20022 is carried in the message identification element, MsgId, in the group header. MsgId is a reference the sender gives the message, and it must be unique for the sender. It is normally a combination of the sender identifier, the date, and a sequence number, for example BANKGB22-20260512-000001. The receiving bank uses MsgId to detect duplicates. If it receives two messages with the same MsgId from the same sender, it will treat the second as a duplicate and reject it, or it will query the sender. The MsgId is therefore a control, and it must be generated correctly. A system that reuses a MsgId, or that generates a MsgId that is not unique, will cause duplicate rejections and will confuse the reconciliation.
Correlation is the linking of a message to the message it responds to, or to the original instruction. Correlation is carried in the original references. A pacs.002 status report carries the original message identification, OrgnlMsgId, and the original instruction identification, OrgnlInstrId, and the original end to end identification, OrgnlEndToEndId, so the receiving bank can match the status report to the original payment. A pacs.004 return carries the original instruction identification and the original end to end identification, so the sending bank can match the return to the original payment. A camt.029 resolution carries the original message identification, so the requesting bank can match the resolution to its investigation. Without correlation, a status report or a return is an orphan, and the bank cannot process it.
The unique end to end transaction reference, UETR, is the identifier that follows a payment from end to end, across all banks and all messages. The UETR is a UUID, a 36 character identifier in the format 8-4-4-4-12, for example 123e4567-e89b-12d3-a456-426614174000. It is generated by the first bank in the chain, and it is carried in every message that relates to the payment, in the pacs.008, the pacs.002, the pacs.004, and the camt.054. The UETR is the key to SWIFT gpi tracking, because the gpi tracker uses the UETR to follow the payment across banks and to report its status to the customer. An SME must know that the UETR is generated once, by the first bank, and that it must not be changed by any bank in the chain. A bank that generates a new UETR for a payment that already has one will break the tracking, and the customer will lose visibility.
The group header versus the transaction information is the structural distinction in ISO 20022. The group header, GrpHdr, carries the information about the message as a whole, the MsgId, the CreDtTm, the NbOfTxs, the CtrlSum, the settlement information, and the instructing and instructed agents. The transaction information block, for example CdtTrfTxInf in a pacs.008, carries the information about one payment, the PmtId, the amount, the debtor, the creditor, and the remittance information. A message with 40 payments has one group header and 40 transaction information blocks. The group header is the control, and the transaction information is the payment. An SME must keep them apart, because a field in the group header applies to the whole message, and a field in the transaction information applies to one payment only.
The business application header, head.001, is the envelope that carries the business message. It is a separate message, wrapped around the business message, and it carries the sender, Fr, the receiver, To, the business message identifier, BizMsgIdr, the message definition identifier, MsgDefIdr, which states the message type and version, for example pacs.008.001.08, the business service, BizSvc, which states the service, for example swift.cbprplus.02, and the creation date and time, CreDt. The head.001 is the wrapper, and the business message is the content. The payment system reads the head.001 first, to determine the message type, the sender, and the receiver, and then it processes the business message. An SME must understand the head.001, because it is where the message type and version are stated, and it is the part of the message that the system uses for routing and for duplicate detection.
Duplicate detection uses the BizMsgIdr in the head.001, combined with the MsgId in the group header. The receiving bank stores the BizMsgIdr for each message it receives, and if it receives a message with a BizMsgIdr it has already seen, it will treat it as a duplicate and reject it. The BizMsgIdr must therefore be unique, and it must be generated correctly. A system that reuses a BizMsgIdr, or that generates a BizMsgIdr that is not unique, will cause the receiving bank to reject a legitimate message as a duplicate, or to accept a duplicate as a new message. Both are serious errors. The BizMsgIdr is normally the same as the MsgId, or it is derived from it, and the system must ensure that it is unique for the sender.
For a business analyst, the identification and correlation requirement must state the MsgId generation rule, the UETR generation rule, the BizMsgIdr generation rule, and the correlation fields. The requirement should say that the system generates a unique MsgId for each message, that it generates a UETR for each payment and carries it in every related message, that it generates a unique BizMsgIdr, and that it carries the original references in every status report, return, and resolution, so that each message can be matched to the original payment. A system that cannot correlate a pacs.002 to its pacs.008 cannot report the status of a payment, and a system that cannot generate a unique UETR cannot support gpi tracking.
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.