Payments Academy
Reading an ISO 20022 message NOW Reading an ISO 20022 message Group Header control totals Payment Information batch level Credit Transfer Transaction Information XML syntax rules and validation failures Annotated sample as a test artefact MESSAGE TRACE Reading an ISO 20022 message ISO 20022 is a standard for financial messaging that defines messages in XML, and the best way to learn it is Step 1 of 6 Reading an ISO 20022 message 1 NOW Reading an ISO 20022 message 2 Group Header control totals 3 Payment Information batch level 4 Credit Transfer Transaction Information 5 XML syntax rules and validation failures 6 Annotated sample as a test artefact ISO 20022 is a standard for financial messaging that defines messages in XML, and the best way to learn it is to read a real message, line by line, with each element explained. Step 1 of 6
Group Header control totals Reading an ISO 20022 message NOW Group Header control totals Payment Information batch level Credit Transfer Transaction Information XML syntax rules and validation failures Annotated sample as a test artefact MESSAGE TRACE Reading an ISO 20022 message > Group Header control totals The MsgId must be unique, because it is the reference that the receiving bank uses to detect a duplicate, Step 2 of 6 Group Header control totals 1 Reading an ISO 20022 message 2 NOW Group Header control totals 3 Payment Information batch level 4 Credit Transfer Transaction Information 5 XML syntax rules and validation failures 6 Annotated sample as a test artefact The MsgId must be unique, because it is the reference that the receiving bank uses to detect a duplicate, Step 2 of 6
Payment Information batch level Reading an ISO 20022 message Group Header control totals NOW Payment Information batch level Credit Transfer Transaction Information XML syntax rules and validation failures Annotated sample as a test artefact MESSAGE TRACE Reading an ISO 20022 message > Group Header control totals > Payment Information batch level The Credit Transfer Transaction Information block is the single payment Step 3 of 6 Payment Information batch level 1 Reading an ISO 20022 message 2 Group Header control totals 3 NOW Payment Information batch level 4 Credit Transfer Transaction Information 5 XML syntax rules and validation failures 6 Annotated sample as a test artefact The Credit Transfer Transaction Information block is the single payment Step 3 of 6
Credit Transfer Transaction Information Reading an ISO 20022 message Group Header control totals Payment Information batch level NOW Credit Transfer Transaction Information XML syntax rules and validation failures Annotated sample as a test artefact MESSAGE TRACE Reading an ISO 20022 message > Group Header control totals > Payment Information batch level > Credit Transfer Transaction Information Every amount, date and code must match the schema, which is the formal definition of the message, and a Step 4 of 6 Credit Transfer Transaction Information 1 Reading an ISO 20022 message 2 Group Header control totals 3 Payment Information batch level 4 NOW Credit Transfer Transaction Information 5 XML syntax rules and validation failures 6 Annotated sample as a test artefact Every amount, date and code must match the schema, which is the formal definition of the message, and a schema validation failure rejects the whole message, not just the field, so one bad Step 4 of 6
XML syntax rules and validation failures Reading an ISO 20022 message Group Header control totals Payment Information batch level Credit Transfer Transaction Information NOW XML syntax rules and validation failures Annotated sample as a test artefact MESSAGE TRACE Reading an ISO 20022 message > Group Header control totals > Payment Information batch level > Credit Transfer Transaction Information > XML syntax rules and validation failures A schema error, such as a missing mandatory element or a wrong data type, is reported in a pacs.002 with Step 5 of 6 XML syntax rules and validation failures 1 Reading an ISO 20022 message 2 Group Header control totals 3 Payment Information batch level 4 Credit Transfer Transaction Information 5 NOW XML syntax rules and validation failures 6 Annotated sample as a test artefact A schema error, such as a missing mandatory element or a wrong data type, is reported in a pacs.002 with status RJCT Step 5 of 6
Annotated sample as a test artefact Reading an ISO 20022 message Group Header control totals Payment Information batch level Credit Transfer Transaction Information XML syntax rules and validation failures NOW Annotated sample as a test artefact MESSAGE TRACE Reading an ISO 20022 message > Group Header control totals > Payment Information batch level > Credit Transfer Transaction Information > XML syntax rules and validation failures > Annotated sample as a test artefact Takeaway: a pacs.008 is a Document with a Group Header, a Payment Information block and a Credit Transfer Step 6 of 6 Annotated sample as a test artefact 1 Reading an ISO 20022 message 2 Group Header control totals 3 Payment Information batch level 4 Credit Transfer Transaction Information 5 XML syntax rules and validation failures 6 NOW Annotated sample as a test artefact Takeaway: a pacs.008 is a Document with a Group Header, a Payment Information block and a Credit Transfer Transaction Information block, and each element has a purpose, a format and a rule. Step 6 of 6

Flow of the explanation in this lesson.

0:00 / 16:00 Step 1 of 6

ISO 20022 fundamentals with annotated XML samples

ISO 20022 Fundamentals, Lesson 8 of 10, Narration 16:00, D04 Messaging and standards

Remittance informationMarket practiceExecution date

What you will learn

Your objective. By the end of this lesson, you will be able to explain ISO 20022 fundamentals with annotated XML samples. ISO 20022 is a standard for financial messaging that defines messages in XML, and the best way to learn it is to read a real message, line by line, with each element explained.

Why it matters. Takeaway: a pacs.008 is a Document with a Group Header, a Payment Information block and a Credit Transfer Transaction Information block, and each element has a purpose, a format and a rule.

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

  • Reading an ISO 20022 message
  • Group Header control totals
  • Payment Information batch level
  • Credit Transfer Transaction Information
  • XML syntax rules and validation failures
  • Annotated sample as a test artefact

Key terms

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

Market practice: An agreed way of using a message standard in a particular market or community, covering field usage, codes and validation rules.

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

ISO 20022 XML explorer showing ISO 20022 fundamentals with annotated XML samples.

Practise this lesson

Exercise

Read the annotated pacs.008 sample for EUR 10,000 in this lesson and explain each element: Group Header, Payment Information and Credit Transfer Transaction Information.

Use the sample values: MsgId BANKA20261109-001, NbOfTxs 1, CtrlSum 10000, Dbtr Acme Manufacturing SARL, Cdtr Rhine Metals GmbH, EndToEndId INV-2026-1187.

  1. What to do. For each level state what it carries, and explain what happens if the CtrlSum does not match or the MsgId is duplicated.

Correct result. Group Header is the envelope with MsgId, creation date and time, number of transactions and control sum. Payment Information is the batch level with payment method, requested execution date, debtor, debtor account and debtor agent. Credit Transfer Transaction Information is the single payment with end to end identifier, amount, creditor, creditor account, creditor agent and remittance. A wrong CtrlSum rejects the message; a duplicate MsgId is rejected as a duplicate.

Why. The annotated sample is a test artefact, not just a teaching aid.

Check your understanding

Practice question

In a pacs.008, what does the Group Header carry?

Takeaway and next step

What to remember

Takeaway: a pacs.008 is a Document with a Group Header, a Payment Information block and a Credit Transfer Transaction Information block, and each element has a purpose, a format and a rule.

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 "What changes for banks, corporates and operations".

Transcript and full text

Show transcript

ISO 20022 is a standard for financial messaging that defines messages in XML, and the best way to learn it is to read a real message, line by line, with each element explained. The sample below is a pacs.008 customer credit transfer for EUR 10,000, and it is annotated so that a business analyst who has never read XML can follow it. The message starts with a Document element, which holds the whole message, and inside it is a FIToFICstmrCdtTrf element, which is the financial institution to financial institution customer credit transfer, and inside that are the Group Header, the Payment Information and the Credit Transfer Transaction Information, which are the three levels of a pacs.008. Source: ISO 20022, pacs.org; SWIFT, Cross-border Payments and Reporting Plus usage guidelines. The Group Header is the envelope, and it carries the message identifier, the creation date and time, and the number of transactions and the control sum. A sample Group Header reads MsgId with value BANKA20261109-001, CreDtTm with value 2026-11-09T10:00:00, NbOfTxs with value 1, and CtrlSum with value 10000. The MsgId must be unique, because it is the reference that the receiving bank uses to detect a duplicate, and a pacs.008 with a MsgId that has already been seen must be rejected as a duplicate. The NbOfTxs and the CtrlSum are control totals, and if the number of transactions or the sum does not match the transactions that follow, the message is rejected, because a message that does not balance cannot be trusted. The Payment Information block is the batch level, and it carries the payment method, the requested execution date, the debtor, the debtor agent, and the settlement information. A sample reads PmtInfId with value PAYINF-001, PmtMtd with value TRF for a credit transfer, ReqdExctnDt with value 2026-11-09, Dbtr with the name Acme Manufacturing SARL, DbtrAcct with the IBAN FR7630006000011234567890189, and DbtrAgt with the BIC AGRIFRPPXXX. The ReqdExctnDt is the date the debtor agent is asked to execute the payment, and it must be a business day, or the payment will be held. The DbtrAgt is the bank that sends the payment, and its BIC must be valid in the SWIFT BIC directory, or the message will be rejected. The Credit Transfer Transaction Information block is the single payment, and it carries the end to end identifier, the amount, the creditor, the creditor agent and the remittance information. A sample reads EndToEndId with value INV-2026-1187, InstdAmt with currency EUR and value 10000, Cdtr with the name Rhine Metals GmbH, CdtrAcct with the IBAN DE89370400440532013000, CdtrAgt with the BIC COBADEFFXXX, and RmtInf with the unstructured remittance Invoice INV-2026-1187, steel delivery October 2026. The InstdAmt carries the currency as an attribute and the amount as the value, and the amount must have no more than two decimal places for EUR, or the message will be rejected for a format error. The XML syntax itself has rules that a business analyst must understand, even without writing code. Every element opens with a tag, such as Dbtr, and closes with a matching tag, such as the closing Dbtr, and the elements nest inside each other, so a DbtrAcct sits inside a PmtInf, and a CdtrAcct sits inside a CdtTrfTxInf. Every message declares a namespace, which is the version of the standard, such as urn:iso:std:iso:20022:tech:xsd:pacs.008.001. Every amount, date and code must match the schema, which is the formal definition of the message, and a schema validation failure rejects the whole message, not just the field, so one bad field can stop a payment of EUR 10,000. A worked example shows how an annotated sample is used in a project. A business analyst receives a pacs.008 from a corporate customer that was rejected, and the pacs.002 status report says the rejection reason is a schema error in the CdtrAcct block. The analyst opens the annotated sample, compares the customer message with the sample, and finds that the customer sent the IBAN without the country code, so the IBAN is 20 characters instead of 22, and the schema rejects it. The annotated sample is therefore a test artefact, not just a teaching aid, and it belongs in the functional specification as the reference message. Failure in XML is a validation failure, and the recovery is to fix the message and resend it, with a new MsgId, because the old MsgId is now associated with a rejected message, and reusing it would be treated as a duplicate. A schema error, such as a missing mandatory element or a wrong data type, is reported in a pacs.002 with status RJCT and a reason code, and the operations team must be able to read the pacs.002, find the field, and tell the customer what to fix. A business rule error, such as an amount that exceeds a limit or a value date that is a holiday, is also reported in a pacs.002. A namespace error, where the message declares the wrong version, rejects the whole file, and the fix is to upgrade the message version, which is a project change, not a data fix. For a business analyst, product owner or subject matter expert, the test is to read a pacs.008, a pain.001 and a camt.053, and to explain each element, its purpose, its format and its source. Ask how the message identifier is generated, how duplicates are detected, and how the control sum is calculated. Ask how the namespace version is managed, and what happens when the scheme moves to a new version. The ISO 20022 message definitions on iso20022.org are the source for the elements, the schema and the version, and the SWIFT CBPR+ usage guidelines are the source for the market practice rules that sit on top of the schema, and both must be cited in the specification. Takeaway: a pacs.008 is a Document with a Group Header, a Payment Information block and a Credit Transfer Transaction Information block, and each element has a purpose, a format and a rule. The MsgId must be unique, the control sum must balance, the IBAN must be complete, and the namespace must match the expected version. Read the message line by line, compare it with an annotated sample, and fix the field, not the message. Further reading: ISO 20022, pacs.008.001.08 message definition, iso20022.org; SWIFT, Cross-border Payments and Reporting Plus usage guidelines. Last reviewed 7 November 2026.

ISO 20022 is a standard for financial messaging that defines messages in XML, and the best way to learn it is to read a real message, line by line, with each element explained. The sample below is a pacs.008 customer credit transfer for EUR 10,000, and it is annotated so that a business analyst who has never read XML can follow it. The message starts with a Document element, which holds the whole message, and inside it is a FIToFICstmrCdtTrf element, which is the financial institution to financial institution customer credit transfer, and inside that are the Group Header, the Payment Information and the Credit Transfer Transaction Information, which are the three levels of a pacs.008. Source: ISO 20022, pacs.org; SWIFT, Cross-border Payments and Reporting Plus usage guidelines.

The Group Header is the envelope, and it carries the message identifier, the creation date and time, and the number of transactions and the control sum. A sample Group Header reads MsgId with value BANKA20261109-001, CreDtTm with value 2026-11-09T10:00:00, NbOfTxs with value 1, and CtrlSum with value 10000. The MsgId must be unique, because it is the reference that the receiving bank uses to detect a duplicate, and a pacs.008 with a MsgId that has already been seen must be rejected as a duplicate. The NbOfTxs and the CtrlSum are control totals, and if the number of transactions or the sum does not match the transactions that follow, the message is rejected, because a message that does not balance cannot be trusted.

The Payment Information block is the batch level, and it carries the payment method, the requested execution date, the debtor, the debtor agent, and the settlement information. A sample reads PmtInfId with value PAYINF-001, PmtMtd with value TRF for a credit transfer, ReqdExctnDt with value 2026-11-09, Dbtr with the name Acme Manufacturing SARL, DbtrAcct with the IBAN FR7630006000011234567890189, and DbtrAgt with the BIC AGRIFRPPXXX. The ReqdExctnDt is the date the debtor agent is asked to execute the payment, and it must be a business day, or the payment will be held. The DbtrAgt is the bank that sends the payment, and its BIC must be valid in the SWIFT BIC directory, or the message will be rejected.

The Credit Transfer Transaction Information block is the single payment, and it carries the end to end identifier, the amount, the creditor, the creditor agent and the remittance information. A sample reads EndToEndId with value INV-2026-1187, InstdAmt with currency EUR and value 10000, Cdtr with the name Rhine Metals GmbH, CdtrAcct with the IBAN DE89370400440532013000, CdtrAgt with the BIC COBADEFFXXX, and RmtInf with the unstructured remittance Invoice INV-2026-1187, steel delivery October 2026. The InstdAmt carries the currency as an attribute and the amount as the value, and the amount must have no more than two decimal places for EUR, or the message will be rejected for a format error.

The XML syntax itself has rules that a business analyst must understand, even without writing code. Every element opens with a tag, such as Dbtr, and closes with a matching tag, such as the closing Dbtr, and the elements nest inside each other, so a DbtrAcct sits inside a PmtInf, and a CdtrAcct sits inside a CdtTrfTxInf. Every message declares a namespace, which is the version of the standard, such as urn:iso:std:iso:20022:tech:xsd:pacs.008.001. Every amount, date and code must match the schema, which is the formal definition of the message, and a schema validation failure rejects the whole message, not just the field, so one bad field can stop a payment of EUR 10,000.

A worked example shows how an annotated sample is used in a project. A business analyst receives a pacs.008 from a corporate customer that was rejected, and the pacs.002 status report says the rejection reason is a schema error in the CdtrAcct block. The analyst opens the annotated sample, compares the customer message with the sample, and finds that the customer sent the IBAN without the country code, so the IBAN is 20 characters instead of 22, and the schema rejects it. The annotated sample is therefore a test artefact, not just a teaching aid, and it belongs in the functional specification as the reference message.

Failure in XML is a validation failure, and the recovery is to fix the message and resend it, with a new MsgId, because the old MsgId is now associated with a rejected message, and reusing it would be treated as a duplicate. A schema error, such as a missing mandatory element or a wrong data type, is reported in a pacs.002 with status RJCT and a reason code, and the operations team must be able to read the pacs.002, find the field, and tell the customer what to fix. A business rule error, such as an amount that exceeds a limit or a value date that is a holiday, is also reported in a pacs.002. A namespace error, where the message declares the wrong version, rejects the whole file, and the fix is to upgrade the message version, which is a project change, not a data fix.

For a business analyst, product owner or subject matter expert, the test is to read a pacs.008, a pain.001 and a camt.053, and to explain each element, its purpose, its format and its source. Ask how the message identifier is generated, how duplicates are detected, and how the control sum is calculated. Ask how the namespace version is managed, and what happens when the scheme moves to a new version. The ISO 20022 message definitions on iso20022.org are the source for the elements, the schema and the version, and the SWIFT CBPR+ usage guidelines are the source for the market practice rules that sit on top of the schema, and both must be cited in the specification.

Takeaway: a pacs.008 is a Document with a Group Header, a Payment Information block and a Credit Transfer Transaction Information block, and each element has a purpose, a format and a rule. The MsgId must be unique, the control sum must balance, the IBAN must be complete, and the namespace must match the expected version. Read the message line by line, compare it with an annotated sample, and fix the field, not the message. Further reading: ISO 20022, pacs.008.001.08 message definition, iso20022.org; SWIFT, Cross-border Payments and Reporting Plus usage guidelines. 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.