| Field | Meaning | Required |
|---|---|---|
GrpHdr | The header of the message, holding the message identification, creation date and time, number of transactions and control sum. It identifies the file or message | M |
PmtId | The identification block holding instruction identification, end to end identification and transaction identification. End to end identification stays unchanged | M |
IntrBkSttlmAmt | The amount and currency settled between banks for this payment, for example USD 25,000. It is the amount the debtor agent transfers to the creditor agent. It ma | M |
IntrBkSttlmDt | The date on which settlement between banks takes place. It is the value date for the interbank leg and drives liquidity planning and nostro funding. The date mu | O |
SttlmInf | Information about how settlement will occur, including the settlement method, settlement account and clearing system. Values include INDA for instructed agent s | M |
Dbtr | The customer who ordered the payment, with structured name, postal address and identification. Rich debtor data supports sanctions screening and anti money laun | M |
DbtrAcct | The account of the debtor from which the payment is debited, identified by IBAN or other account identification. It links the payment to the correct customer ac | O |
DbtrAgt | The bank holding the debtor account and sending the payment instruction onward. It is identified by BIC and sometimes by name and address. The debtor agent is r | M |
CdtrAgt | The bank holding the creditor account and receiving the payment for onward credit. It is identified by BIC and sometimes by name and address. The creditor agent | M |
Cdtr | The final beneficiary of the payment, with structured name, postal address and identification. The creditor agent credits this party on receipt of funds. Comple | M |
CdtrAcct | The account of the creditor to be credited, identified by IBAN or other account identification. It tells the creditor agent exactly where to post the funds. A w | O |
ChrgsInf | Details of the charges applied to the payment, including the amount, currency, bearer and the agent that applied each charge. The bearer can be debtor, creditor | O |
Meridian Bank London sends a pacs.008.001.08 for USD 25,000 value 5 November 2026 to Harbour Bank Singapore, with a UETR, full structured debtor and creditor names and addresses, charge bearer SHAR, and remittance reference INV-1187. Harbour Bank screens the payment, credits Bright Logistics, and reports the status in a pacs.002.Valid example from the message catalogue. Scheme rules: pacs.008 is a base ISO 20022 message: the structure and fields below are the base definition, and each scheme adds or restricts elements for its rail. Under CBPR+ the message must carry a UETR for end
The Catalogue at a Glance: pain, pacs, camt, admi and head
What you will learn
Your objective. By the end of this lesson, you will be able to explain catalogue at a glance: PAIN, PACS, CAMT, admi and head. The ISO 20022 catalogue is organised into families, and each family is named by its first four letters.
Why it matters. This matters because the message is the payment instruction. A wrong field, a missing element or a misunderstood format is a failed payment, a return, or a compliance breach.
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
- ISO 20022 catalogue
- Head family
- Message: correct
- Camt family
- Payment: sent in error
- head.001 plus pacs.008
Key terms
ISO 20022: An international standard for financial messaging that defines XML message formats for payments, securities and trade.
pacs.008: An ISO 20022 message for a financial institution to financial institution customer credit transfer. It replaces MT103 in cross border payments and carries structured debtor, creditor, charges and...
pain.001: An ISO 20022 message a customer sends to its bank to instruct one or more credit transfers. It carries payment information, debtor and creditor details, amount, execution date and remittance data.
ISO 20022 XML explorer showing The Catalogue at a Glance: pain, pacs, camt, admi and head.
Practise this lesson
Exercise
Read the ISO 20022 catalogue 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
Which ISO 20022 message is used for a bank to customer account statement?
Takeaway and next step
What to remember
When you see a message described as head.001 plus pacs.008, that means a pacs.008 business message carried inside a head.001 header, and the header is what the receiving system reads first.
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 "Hands-On Exercise: pain.001 to Canonical Model to pacs.008".
Transcript and full text
Show transcript
ISO 20022 is the international standard for financial messaging, and it is the language that modern payments run on. It replaces the SWIFT MT messages with a richer, structured, XML-based format, and it is the standard that the major payment systems and the SWIFT community are migrating to under the CBPR+ programme. The catalogue of ISO 20022 messages is organised into business areas, each identified by a four letter code. The pain messages are customer to bank, the pacs messages are bank to bank, the camt messages are cash management, the admi messages are administration, and the head messages are the business application header. An SME must know the catalogue, because every payment, every status report, and every statement in a modern payment system is carried in one of these messages. The pain messages are the customer to bank messages. pain.001 is the customer credit transfer initiation, the message a corporate sends to its bank to instruct a payment. pain.002 is the customer payment status report, the message the bank sends back to the customer to report the status of each payment. pain.008 is the customer direct debit initiation, the message a creditor sends to its bank to collect a direct debit from a debtor. These three messages are the customer to bank family, and they are the messages a corporate treasury system generates and receives. The pain.001 is the ISO 20022 equivalent of the MT101, and the pain.008 is the equivalent of a direct debit instruction. The pacs messages are the bank to bank messages. pacs.002 is the FI to FI payment status report, the message a bank sends to report the status of a payment. pacs.003 is the FI to FI customer direct debit, the message a bank sends to collect a direct debit from another bank. pacs.004 is the payment return, the message a bank sends to return a payment that was previously credited. pacs.008 is the FI to FI customer credit transfer, the message a bank sends to another bank to carry a customer payment, and it is the ISO 20022 equivalent of the MT103. pacs.009 is the FI to FI payment, the message a bank sends to another bank for its own payment, and it is the equivalent of the MT202. pacs.009 also has a COV variant, the FI to FI payment with cover, which is the equivalent of the MT202 COV. The camt messages are the cash management messages. camt.029 is the resolution of investigation, the message a bank sends to report the outcome of an investigation. camt.052 is the bank to customer account report, the message a bank sends to report the account activity intraday. camt.053 is the bank to customer statement, the message a bank sends to report the account activity for a period, normally daily, and it is the ISO 20022 equivalent of the MT940 and MT950. camt.054 is the bank to customer debit credit notification, the message a bank sends to notify a customer of a single debit or credit. camt.056 is the FI to FI payment cancellation request, the message a bank sends to ask another bank to cancel a payment. camt.060 is the account reporting request, the message a customer sends to ask its bank for a statement or a report. The admi messages are the administration messages, used for system and administration purposes, such as the admi.002 message system event acknowledgement and the admi.004 system event notification. The head messages are the business application header, head.001, which is the envelope that carries the business message, stating the sender, the receiver, the message type, and the creation date and time. The business application header is the wrapper, and the business message is the content. An SME must understand the header, because it is where the message identification, the correlation, and the duplicate detection are carried, and it is the part of the message that the payment system reads first. Each ISO 20022 message has a version, identified by a number such as pacs.008.001.08 or pacs.008.001.10. The version matters, because the fields and the rules change between versions, and a bank must support the version its counterparty uses. The CBPR+ usage guidelines specify which version to use for cross border payments, and they state the market practice rules that narrow the ISO 20022 standard to a specific implementation. A bank that sends a pacs.008.001.10 to a bank that only supports pacs.008.001.08 will have the message rejected, or will have the fields that the older version does not support ignored. The version is therefore a compatibility issue, and it must be agreed between the parties before the first message is sent. The external code sets are the lists of codes that ISO 20022 uses for fields such as the charge bearer, the purpose, the service level, and the status reason. The codes are published by ISO, and they are updated regularly. For example, the charge bearer code set includes DEBT, CRED, SHAR, and SLEV, which correspond to OUR, BEN, SHA, and the service level charges in the MT world. The status reason code set includes AC01, AC04, AC06, AM04, AM05, AG01, MD07, RC01, and FF01, which are the same codes used in the MT world for rejects and returns. An SME must know the code sets, because a message with a wrong code will be rejected, and a message with a code the receiving bank does not recognise will be treated as an error. For a business analyst, the catalogue is the starting point. The analyst must be able to name the message for each business need, state the version, and identify the fields that carry the business data. The analyst must know that a customer payment initiation is a pain.001, that a bank to bank customer payment is a pacs.008, that a payment return is a pacs.004, that a status report is a pacs.002 or a pain.002, and that a statement is a camt.053. The rest of this chapter follows each message family in depth, field by field, with the mapping from the MT world and the practical exercises that turn the catalogue into working knowledge.
ISO 20022 is the international standard for financial messaging, and it is the language that modern payments run on. It replaces the SWIFT MT messages with a richer, structured, XML-based format, and it is the standard that the major payment systems and the SWIFT community are migrating to under the CBPR+ programme. The catalogue of ISO 20022 messages is organised into business areas, each identified by a four letter code. The pain messages are customer to bank, the pacs messages are bank to bank, the camt messages are cash management, the admi messages are administration, and the head messages are the business application header. An SME must know the catalogue, because every payment, every status report, and every statement in a modern payment system is carried in one of these messages.
The pain messages are the customer to bank messages. pain.001 is the customer credit transfer initiation, the message a corporate sends to its bank to instruct a payment. pain.002 is the customer payment status report, the message the bank sends back to the customer to report the status of each payment. pain.008 is the customer direct debit initiation, the message a creditor sends to its bank to collect a direct debit from a debtor. These three messages are the customer to bank family, and they are the messages a corporate treasury system generates and receives. The pain.001 is the ISO 20022 equivalent of the MT101, and the pain.008 is the equivalent of a direct debit instruction.
The pacs messages are the bank to bank messages. pacs.002 is the FI to FI payment status report, the message a bank sends to report the status of a payment. pacs.003 is the FI to FI customer direct debit, the message a bank sends to collect a direct debit from another bank. pacs.004 is the payment return, the message a bank sends to return a payment that was previously credited. pacs.008 is the FI to FI customer credit transfer, the message a bank sends to another bank to carry a customer payment, and it is the ISO 20022 equivalent of the MT103. pacs.009 is the FI to FI payment, the message a bank sends to another bank for its own payment, and it is the equivalent of the MT202. pacs.009 also has a COV variant, the FI to FI payment with cover, which is the equivalent of the MT202 COV.
The camt messages are the cash management messages. camt.029 is the resolution of investigation, the message a bank sends to report the outcome of an investigation. camt.052 is the bank to customer account report, the message a bank sends to report the account activity intraday. camt.053 is the bank to customer statement, the message a bank sends to report the account activity for a period, normally daily, and it is the ISO 20022 equivalent of the MT940 and MT950. camt.054 is the bank to customer debit credit notification, the message a bank sends to notify a customer of a single debit or credit. camt.056 is the FI to FI payment cancellation request, the message a bank sends to ask another bank to cancel a payment. camt.060 is the account reporting request, the message a customer sends to ask its bank for a statement or a report.
The admi messages are the administration messages, used for system and administration purposes, such as the admi.002 message system event acknowledgement and the admi.004 system event notification. The head messages are the business application header, head.001, which is the envelope that carries the business message, stating the sender, the receiver, the message type, and the creation date and time. The business application header is the wrapper, and the business message is the content. An SME must understand the header, because it is where the message identification, the correlation, and the duplicate detection are carried, and it is the part of the message that the payment system reads first.
Each ISO 20022 message has a version, identified by a number such as pacs.008.001.08 or pacs.008.001.10. The version matters, because the fields and the rules change between versions, and a bank must support the version its counterparty uses. The CBPR+ usage guidelines specify which version to use for cross border payments, and they state the market practice rules that narrow the ISO 20022 standard to a specific implementation. A bank that sends a pacs.008.001.10 to a bank that only supports pacs.008.001.08 will have the message rejected, or will have the fields that the older version does not support ignored. The version is therefore a compatibility issue, and it must be agreed between the parties before the first message is sent.
The external code sets are the lists of codes that ISO 20022 uses for fields such as the charge bearer, the purpose, the service level, and the status reason. The codes are published by ISO, and they are updated regularly. For example, the charge bearer code set includes DEBT, CRED, SHAR, and SLEV, which correspond to OUR, BEN, SHA, and the service level charges in the MT world. The status reason code set includes AC01, AC04, AC06, AM04, AM05, AG01, MD07, RC01, and FF01, which are the same codes used in the MT world for rejects and returns. An SME must know the code sets, because a message with a wrong code will be rejected, and a message with a code the receiving bank does not recognise will be treated as an error.
For a business analyst, the catalogue is the starting point. The analyst must be able to name the message for each business need, state the version, and identify the fields that carry the business data. The analyst must know that a customer payment initiation is a pain.001, that a bank to bank customer payment is a pacs.008, that a payment return is a pacs.004, that a status report is a pacs.002 or a pain.002, and that a statement is a camt.053. The rest of this chapter follows each message family in depth, field by field, with the mapping from the MT world and the practical exercises that turn the catalogue into working 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.