| 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
Validating an ISO 20022 XML file: schemas, errors and fixes
What you will learn
Your objective. By the end of this lesson, you will be able to explain validating an ISO 20022 XML file: schemas, errors and fixes. An ISO 20022 message is an XML file, and before a bank can process it, the file must be validated.
Why it matters. For a business analyst, validation requirements cover what happens when a file fails.
Chapter objective: How the standard is built, read and validated in real systems
Key learning points
- Well formed versus valid: two questions
- Validation in four steps
- Market practice: scheme rules on top of the schema
- Namespace errors: the whole file fails
- Worked example: fixing a rejected pacs.008
- Schema error versus business rule error
Key terms
Market practice: An agreed way of using a message standard in a particular market or community, covering field usage, codes and validation rules.
Value date: The date on which funds become available to the beneficiary and on which interest starts to accrue. It is the date used for settlement and for nostro posting.
ISO 20022: An international standard for financial messaging that defines XML message formats for payments, securities and trade.
ISO 20022 XML explorer showing Validating an ISO 20022 XML file: schemas, errors and fixes.
Practise this lesson
Exercise
Scenario: you are testing a new ISO 20022 interface. A developer hands you a pacs.008 XML file and says it is ready to send. Validate it. Check it against the pacs.008 XSD schema, check the Business Application Header, and check the business rules: the amount must be positive, the currency must be a valid ISO 4217 code, the debtor and creditor agents must be valid BICs, the end to end identification must be present, and the instruction identification must be unique. Find every error and write the corrected XML fragment for each one.
The pacs.008 as given: GrpHdr MsgId is empty. CreDtTm is 2026-11-10T09:00:00. NbOfTxs is 1. CtrlSum is 25000.00. PmtId InstrId is Instr-001. PmtId EndToEndId is missing. IntrBkSttlmAmt Ccy is EUR and the amount is -25000.00. IntrBkSttlmDt is 2026-11-10. Dbtr Nm is Atlas GmbH. DbtrAcct IBAN is DE89370400440532013000. DbtrAgt BICFI is DEUTDEFF. CdtrAgt BICFI is BNPAFRPPX. Cdtr Nm is Loire Vins SARL. CdtrAcct IBAN is FR1420041010050500013M02606. The Business Application Header has Fr BICFI DEUTDEFF, To BICFI BNPAFRPP, BizMsgIdr MSG-20261110-001, MsgDefIdr pacs.008.001.08, CreDt 2026-11-10T09:00:00.
- What to do. Validate the file in three passes: schema validation, header validation, business rule validation. List every error with the field, the rule it breaks, and the corrected value. Then state whether the file can be sent.
Correct result. Schema errors: GrpHdr MsgId is empty, but MsgId is mandatory and must be 1 to 35 characters, so set it to MSG-20261110-001. PmtId EndToEndId is missing, but EndToEndId is mandatory in pacs.008, so set it to E2E-5520. Business rule errors: IntrBkSttlmAmt is -25000.00, but the amount must be positive, so correct it to 25000.00. CdtrAgt BICFI BNPAFRPPX is 9 characters, but a BIC is 8 or 11 characters, so correct it to BNPAFRPP. Header errors: the Business Application Header To BICFI is BNPAFRPP, which matches the creditor agent, so that is correct. MsgDefIdr pacs.008.001.08 is a valid version. The file cannot be sent as it stands: the empty MsgId and the missing EndToEndId are schema failures, the negative amount is a business rule failure, and the 9-character BIC is invalid. After correcting all four, re-validate against the XSD and re-check the business rules before sending. Worked reasoning: schema validation catches missing mandatory fields and wrong formats, but it does not catch a negative amount or a BIC that is the right length but the wrong bank, so business rule validation is a separate pass. The Business Application Header is validated separately because it identifies the sender and receiver of the message, not the payment itself.
Why. Hint 1: validate in three passes, schema first, header second, business rules third, because each pass catches different errors. Hint 2: a BIC must be 8 or 11 characters; a 9-character BIC is always wrong. Hint 3: an amount that is negative or zero is a business rule failure, not a schema failure, so the XSD alone will not catch it. The worked explanation shows why validation is layered: the XSD checks structure, the header checks routing, and the business rules check that the payment makes sense.
Check your understanding
Practice question
Which of the following best describes validating an ISO 20022 XML file: schemas, errors and fixes?
Takeaway and next step
What to remember
For a business analyst, validation requirements cover what happens when a file fails.
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: The Same EUR 10,000 Payment as pacs.008 Under CBPR+ and SEPA".
Transcript and full text
Show transcript
An ISO 20022 message is an XML file, and before a bank can process it, the file must be validated. Validation answers two questions. Is the file well formed, which means the XML syntax is correct, with every tag closed and every attribute quoted. And is the file valid, which means it follows the rules of its schema, the XSD file that defines the message. A file can be well formed but not valid, for example if it has a missing mandatory element or a wrong data type. A file that is not well formed cannot even be read, and a file that is not valid must be rejected, because the bank cannot trust its contents. Validation happens in four steps. First, the parser reads the XML and checks that it is well formed. If a tag is not closed, the parser stops and reports the line and column where the error is. Second, the schema validator checks the file against the XSD for that message type, for example pacs.008.001.08. It checks that every mandatory element is present, that every element has the right data type, and that every code value comes from the allowed code set. Third, the business rule validator checks rules that the schema cannot express, for example that the instructed amount is greater than zero, or that the value date is not in the past. Fourth, the market practice validator checks the scheme rules, for example that a CBPR+ pacs.008 carries the elements CBPR+ requires. The most common validation errors are easy to recognise once you have seen them. A missing mandatory element, for example a pacs.008 without a creditor agent, fails schema validation with an error that names the missing element. A wrong data type, for example an amount written as words instead of a number, fails with an error that names the element and the expected type. An invalid code, for example a reason code that does not exist in the external code set, fails with an error that names the code. A namespace error, for example a message that declares the wrong namespace for its version, fails the whole file, because the validator cannot match any element to the schema. Each error message names the element and the rule, so the fix is usually clear. A worked example makes the process concrete. A developer sends a pacs.008 for EUR 10,000, and the validator rejects it with the error: element CdtrAgt is missing. The developer opens the message, finds that the creditor agent block was omitted, adds it with the BIC of the beneficiary bank, and resubmits. The file now passes schema validation, but the business rule validator rejects it because the value date is yesterday. The developer corrects the value date to today, resubmits, and the file passes all four steps. The payment is now accepted for processing. The lesson is that validation is iterative: fix one error, resubmit, and fix the next, until the file is clean. For a business analyst, validation requirements cover what happens when a file fails. The system must reject the file, tell the sender exactly which element failed and why, and log the rejection with the message reference so the sender can find it. The system must not partially process a failed file, because a payment that is half processed is worse than a payment that is rejected. And the system must distinguish a schema error, which the sender fixes, from a business rule error, which may need the customer to provide new information. A good validation error message is specific, actionable, and written in plain language, because the person reading it is often a corporate customer, not a developer.
An ISO 20022 message is an XML file, and before a bank can process it, the file must be validated. Validation answers two questions. Is the file well formed, which means the XML syntax is correct, with every tag closed and every attribute quoted. And is the file valid, which means it follows the rules of its schema, the XSD file that defines the message. A file can be well formed but not valid, for example if it has a missing mandatory element or a wrong data type. A file that is not well formed cannot even be read, and a file that is not valid must be rejected, because the bank cannot trust its contents.
Validation happens in four steps. First, the parser reads the XML and checks that it is well formed. If a tag is not closed, the parser stops and reports the line and column where the error is. Second, the schema validator checks the file against the XSD for that message type, for example pacs.008.001.08. It checks that every mandatory element is present, that every element has the right data type, and that every code value comes from the allowed code set. Third, the business rule validator checks rules that the schema cannot express, for example that the instructed amount is greater than zero, or that the value date is not in the past. Fourth, the market practice validator checks the scheme rules, for example that a CBPR+ pacs.008 carries the elements CBPR+ requires.
The most common validation errors are easy to recognise once you have seen them. A missing mandatory element, for example a pacs.008 without a creditor agent, fails schema validation with an error that names the missing element. A wrong data type, for example an amount written as words instead of a number, fails with an error that names the element and the expected type. An invalid code, for example a reason code that does not exist in the external code set, fails with an error that names the code. A namespace error, for example a message that declares the wrong namespace for its version, fails the whole file, because the validator cannot match any element to the schema. Each error message names the element and the rule, so the fix is usually clear.
A worked example makes the process concrete. A developer sends a pacs.008 for EUR 10,000, and the validator rejects it with the error: element CdtrAgt is missing. The developer opens the message, finds that the creditor agent block was omitted, adds it with the BIC of the beneficiary bank, and resubmits. The file now passes schema validation, but the business rule validator rejects it because the value date is yesterday. The developer corrects the value date to today, resubmits, and the file passes all four steps. The payment is now accepted for processing. The lesson is that validation is iterative: fix one error, resubmit, and fix the next, until the file is clean.
For a business analyst, validation requirements cover what happens when a file fails. The system must reject the file, tell the sender exactly which element failed and why, and log the rejection with the message reference so the sender can find it. The system must not partially process a failed file, because a payment that is half processed is worse than a payment that is rejected. And the system must distinguish a schema error, which the sender fixes, from a business rule error, which may need the customer to provide new information. A good validation error message is specific, actionable, and written in plain language, because the person reading it is often a corporate customer, not a developer.
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.