XML structure, how an ISO 20022 message is built

An ISO 20022 message is an XML document with a clear, hierarchical structure. At the top level, there is a Document element that contains the message itself, for example a FIToFICstmrCdtTrf element for a pacs zero zero eight. Inside the Document, there is a Group Header, which contains information about the message as a whole, such as the message identification, the creation date and time, and the number of transactions. After the Group Header, there are one or more Payment Information blocks, each of which contains information about a batch of payments, such as the debtor, the debtor agent, and the payment method. Inside each Payment Information block, there are one or more Credit Transfer Transaction Information blocks, each of which describes a single payment to a single creditor. Each element in the XML has a descriptive name, such as Dbtr for debtor, Cdtr for creditor, InstdAmt for instructed amount, and RmtInf for remittance information. The names are abbreviated, but they are consistent across messages, so once you learn them, you can read any ISO 20022 message. The XML also uses attributes and nested elements to represent structure, for example an address is represented as a PstlAdr element with sub elements for street name, town, and country. This structure allows for far more detail than MT, but it also means that messages are larger and require XML parsing rather than simple text parsing. A business analyst does not need to be an XML developer, but must be able to read an ISO 20022 message, identify the key elements, and explain what each element means. You should be able to open a pacs zero zero eight, find the Group Header, find the Payment Information, find the transaction, and trace the debtor to the creditor. You should also understand the difference between mandatory and optional elements, and between elements that are defined by the ISO standard and elements that are defined by a specific scheme usage guideline. The usage guideline is the scheme specific profile that tells banks exactly which elements to populate and how, and it is the document that drives implementation. Worked example with real numbers: a pacs.008 for EUR 10,000 carries a Group Header with MsgId BANKA20261109-001, NbOfTxs 1 and CtrlSum 10000, a Payment Information block with PmtInfId PAYINF-001 and Dbtr Acme Manufacturing SARL, and a Credit Transfer Transaction Information block with EndToEndId INV-2026-1187, InstdAmt EUR 10000, Cdtr Rhine Metals GmbH and RmtInf Invoice INV-2026-1187. If the CtrlSum were EUR 9,000, the message would be rejected, because the control sum does not match the transaction amount, and the sender must correct it and resend with a new MsgId. The XML structure is therefore not decoration, it is the control that proves the message is complete and reconcilable. Failure and recovery: a schema error, such as a missing mandatory element or a wrong data type, rejects the whole message, and the recovery is to fix the field and resend with a new MsgId, because reusing the old MsgId would be treated as a duplicate. A namespace error, where the message declares the wrong version, rejects the whole file, and the recovery is to upgrade the version, which is a project change. A business rule error, such as an amount with three decimal places for EUR, is rejected with a pacs.002 and a reason code, and the fix is in the business data. Each failure is reported in a pacs.002, and the operations team must be able to read the reason code and tell the customer which field to fix. For a business analyst, product owner or subject matter expert, the test is to read a pacs.008 and to explain the three levels, Group Header, Payment Information and Credit Transfer Transaction Information, and what each level carries, without a dictionary. The Group Header is the envelope, the Payment Information is the batch, and the Credit Transfer Transaction Information is the single payment, and the requirement must state which level each field belongs to, because a field in the wrong level will be rejected. The annotated XML samples in ch6s8 are the reference for this lesson, and a requirement that describes a message without an annotated sample will be interpreted differently by every developer, and the product will fail its first schema test.