| 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
Reading an ISO 20022 Schema: XSD Patterns
What you will learn
Your objective. By the end of this lesson, you will be able to explain reading an ISO 20022 schema: xsd patterns. An XSD, or XML Schema Definition, is a formal description of what a valid message may contain.
Why it matters. A business analyst must know the difference between schema mandatory and business rule mandatory, because a message can pass schema validation and still be rejected by the scheme.
Chapter objective: How the standard is built, read and validated in real systems
Key learning points
- XSD: formal description
- Schema reuses types
- Reading: following these types
- Charge bearer with 0..1
- Message: expected
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.
ISO 20022 XML explorer showing Reading an ISO 20022 Schema: XSD Patterns.
Practise this lesson
Exercise
Read the ISO 20022 schema 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
A project team is migrating a payment flow to ISO 20022 and a developer proposes using the pacs.008 version from five years ago because it is already in the codebase. What should the BA say?
Takeaway and next step
What to remember
The schema reuses types, and that reuse is the key to reading 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 "Worked Example: A EUR 180,000 Machinery Export and a EUR 12,000 Spare Parts Collection".
Transcript and full text
Show transcript
An XSD, or XML Schema Definition, is a formal description of what a valid message may contain. It names each element, states its type, and says whether it is mandatory or optional and how many times it may appear. An ISO 20022 schema for pacs.008.001.08, for example, defines a document element, inside which sits the customer credit transfer initiation or the financial institution credit transfer, and inside that sit the group header, the payment information, and the transaction information. Each level nests inside the one above it, like boxes inside boxes, and the schema is the rule book for which boxes are allowed and in what order. The schema reuses types, and that reuse is the key to reading it. A type such as ActiveOrHistoricCurrencyAndAmount is used wherever an amount appears, and it carries a currency attribute and a decimal value. A type such as PartyIdentification135 is used wherever a party appears, and it carries a name, a postal address, and an identification block. When you see the same type name in two places, the structure is the same in both places, which means you learn it once and recognise it everywhere. The schema also uses choice blocks, where only one of several options may appear, and sequences, where elements must appear in a fixed order. Reading a schema means following these types and choices, not memorising every element. Cardinality is the rule that says how many times an element may appear, and it is written as a pair such as 0..1 or 1..n. The first number is the minimum, so 0 means optional and 1 means mandatory, and the second number is the maximum, so 1 means at most once and n means any number. A debtor name with cardinality 1..1 must appear exactly once, while a remittance information block with cardinality 0..1 may appear once or not at all. A charge bearer with 0..1 is optional, but if the scheme requires it, a business rule makes it mandatory even though the schema does not. A business analyst must know the difference between schema mandatory and business rule mandatory, because a message can pass schema validation and still be rejected by the scheme. Schema validation is the automatic check that a message matches its XSD, and it is the first gate a message must pass. The validator checks that every element is in the right place, that the order is correct, that the types are right, and that the cardinality rules are met. If a message carries a letter where a number is expected, or a mandatory element is missing, the validator rejects the whole message and returns an error naming the element and the rule. The receiving system usually replies with a pacs.002 or an admi.002 message status report, so the sender knows the message failed. A message that fails schema validation is never processed further, which is why the sender must validate before sending, not after. When validation fails, the team reads the error, finds the offending element, and decides whether the source data or the mapping was wrong before resending.
An XSD, or XML Schema Definition, is a formal description of what a valid message may contain. It names each element, states its type, and says whether it is mandatory or optional and how many times it may appear. An ISO 20022 schema for pacs.008.001.08, for example, defines a document element, inside which sits the customer credit transfer initiation or the financial institution credit transfer, and inside that sit the group header, the payment information, and the transaction information. Each level nests inside the one above it, like boxes inside boxes, and the schema is the rule book for which boxes are allowed and in what order.
The schema reuses types, and that reuse is the key to reading it. A type such as ActiveOrHistoricCurrencyAndAmount is used wherever an amount appears, and it carries a currency attribute and a decimal value. A type such as PartyIdentification135 is used wherever a party appears, and it carries a name, a postal address, and an identification block. When you see the same type name in two places, the structure is the same in both places, which means you learn it once and recognise it everywhere. The schema also uses choice blocks, where only one of several options may appear, and sequences, where elements must appear in a fixed order. Reading a schema means following these types and choices, not memorising every element.
Cardinality is the rule that says how many times an element may appear, and it is written as a pair such as 0..1 or 1..n. The first number is the minimum, so 0 means optional and 1 means mandatory, and the second number is the maximum, so 1 means at most once and n means any number. A debtor name with cardinality 1..1 must appear exactly once, while a remittance information block with cardinality 0..1 may appear once or not at all. A charge bearer with 0..1 is optional, but if the scheme requires it, a business rule makes it mandatory even though the schema does not. A business analyst must know the difference between schema mandatory and business rule mandatory, because a message can pass schema validation and still be rejected by the scheme.
Schema validation is the automatic check that a message matches its XSD, and it is the first gate a message must pass. The validator checks that every element is in the right place, that the order is correct, that the types are right, and that the cardinality rules are met. If a message carries a letter where a number is expected, or a mandatory element is missing, the validator rejects the whole message and returns an error naming the element and the rule. The receiving system usually replies with a pacs.002 or an admi.002 message status report, so the sender knows the message failed. A message that fails schema validation is never processed further, which is why the sender must validate before sending, not after. When validation fails, the team reads the error, finds the offending element, and decides whether the source data or the mapping was wrong before resending.
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.