| 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
Mandatory, Optional and Conditional Fields, Schema Validation, External Code Sets, Version Management and Market Practice Rules
What you will learn
Your objective. By the end of this lesson, you will be able to explain mandatory, optional and conditional fields, schema validation, external code sets, version management and market practice rules. Every field in an ISO 20022 message has a usage rule, mandatory, optional, or conditional.
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
- Field in an ISO 20022 message
- Schema validation
- Business validation
- Version management
- Market practice rules
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.
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 XML explorer showing Mandatory, Optional and Conditional Fields, Schema Validation, External Code Sets, Version Management and Market Practice Rules.
Insights and practice scenarios
Worked insights and practice scenarios for this lesson. Each one is a reusable PaymentForge case, so the same case may appear in more than one lesson.
Practise this lesson
Exercise
Find the field BIC in the message described in this lesson and explain what it controls.
Use the field description and the example in this lesson.
- What to do. Write down what BIC carries, what happens if it is wrong, and which system reads it.
Correct result. BIC carries the value the lesson describes. If it is wrong, the payment is rejected, returned, or misrouted, and the exception must be investigated before the payment can proceed.
Why. Fields are the contract between systems. A wrong field is not a typo, it is a failed payment.
Check your understanding
Practice question
Which of the following best describes mandatory, optional and conditional fields, schema validation, external code sets, version management and market practice rules?
Takeaway and next step
What to remember
A mandatory field must always be present, such as the message identifier in the group header and the instructed amount in a pacs.008 transaction.
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 "Message Identification, Correlation, Group Header vs Transaction Info, and the Business Application Header".
Transcript and full text
Show transcript
Mandatory, optional, and conditional fields are the three statuses a field can have in an ISO 20022 message. A mandatory field must always be present, and a message without it will be rejected by the schema validation. An optional field may be present or absent, and the receiving bank must accept the message either way. A conditional field must be present if a stated condition is true, and must be absent if the condition is false. For example, in a pacs.008, the instructed amount, InstdAmt, is mandatory, the equivalent amount, EqvtAmt, is optional, and the exchange rate, XchgRate, is conditional, it must be present if the instructed amount is in a different currency from the equivalent amount, and it must be absent if the two amounts are in the same currency. An SME must know the status of each field, because a message with a missing mandatory field will be rejected, and a message with a conditional field that should not be present will also be rejected. Schema validation is the process by which a system checks a message against the XML schema definition, XSD, for that message type and version. The XSD defines the structure, the fields, the data types, and the allowed values. A message that does not conform to the XSD, for example because a field is missing, because a field has the wrong data type, or because a field has a value that is not in the allowed list, will fail schema validation and will be rejected. Schema validation is the first check a receiving bank performs, before it applies any business validation. A message that fails schema validation is not processed, and the sending bank receives a rejection, normally with a pacs.002 status of RJCT and a reason code of FF01, invalid file format, or a reason code that states the specific schema error. External code sets are the lists of codes that ISO 20022 uses for fields such as the charge bearer, the purpose, the service level, the local instrument, the category purpose, and the status reason. The codes are published by ISO in the external code sets, and they are updated regularly. For example, the charge bearer code set includes DEBT, CRED, SHAR, and SLEV. The purpose code set includes SUPP for supplier payment, SALA for salary payment, RENT for rent payment, and TAXS for tax payment. The service level code set includes SEPA, URGP for urgent payment, and SDVA for same day value. The status reason code set includes AC01, AC04, AC06, AM04, AM05, AG01, MD07, RC01, and FF01. An SME must know the code sets, because a message with a code that is not in the code set will fail schema validation, and a message with a code the receiving bank does not recognise will be treated as an error, even if the code is valid. Version management is the process of managing the different versions of a message, and it is a significant issue in ISO 20022, because the standard evolves and the versions change. A pacs.008.001.08 and a pacs.008.001.10 are different versions, and they have different fields and different rules. The CBPR+ usage guidelines specify which version to use for cross border payments, and they state the market practice rules that narrow the standard. A bank must support the version its counterparty uses, and it must handle the migration from one version to another. The migration is normally done on a big bang date, when all banks move to the new version at the same time, or on a phased basis, when the banks move in groups. An SME must know the version in use, and must plan for the migration, because a message in the wrong version will be rejected. Market practice rules are the rules that a community, such as the CBPR+ community, or a scheme, such as SEPA, adds to the ISO 20022 standard, to narrow it to a specific implementation. The standard allows many options, and the market practice rules state which options to use. For example, the ISO 20022 standard allows the charge bearer to be DEBT, CRED, SHAR, or SLEV, but the CBPR+ market practice rules may state that only DEBT, CRED, and SHAR are allowed, and that SLEV is not used. The standard allows the remittance information to be structured or unstructured, but the market practice rules may state that only unstructured remittance information is used, and that it is limited to 140 characters. An SME must know the market practice rules for the community it works in, because a message that conforms to the standard but not to the market practice rules will be rejected by the receiving bank. Truncation is a specific issue in the migration from MT to ISO 20022. The MT messages have fixed length fields, for example field 70 remittance information is 4 lines of 35 characters, a total of 140 characters. The ISO 20022 messages have longer fields, for example the unstructured remittance information is 140 characters, but the structured remittance information can be much longer. When a bank converts an MT103 to a pacs.008, it must map the MT fields to the ISO 20022 fields, and it must handle the cases where the MT field is longer than the ISO 20022 field, or where the ISO 20022 field is longer than the MT field. The CBPR+ usage guidelines state the truncation rules, and the bank must follow them, because a truncated field can lose information, and a lost remittance reference can cause the beneficiary to be unable to match the payment to an invoice. For a business analyst, the field status and validation requirement must state the mandatory, optional, and conditional fields, the schema validation, the code sets, the version, and the market practice rules. The requirement should say that the system validates each message against the XSD before sending it, that it uses only the codes in the external code sets, that it uses the version specified in the CBPR+ usage guidelines, and that it follows the market practice rules for the community. A system that does not validate against the XSD will send invalid messages, and a system that does not follow the market practice rules will have its messages rejected by the receiving bank, even if they are valid against the standard.
Mandatory, optional, and conditional fields are the three statuses a field can have in an ISO 20022 message. A mandatory field must always be present, and a message without it will be rejected by the schema validation. An optional field may be present or absent, and the receiving bank must accept the message either way. A conditional field must be present if a stated condition is true, and must be absent if the condition is false. For example, in a pacs.008, the instructed amount, InstdAmt, is mandatory, the equivalent amount, EqvtAmt, is optional, and the exchange rate, XchgRate, is conditional, it must be present if the instructed amount is in a different currency from the equivalent amount, and it must be absent if the two amounts are in the same currency. An SME must know the status of each field, because a message with a missing mandatory field will be rejected, and a message with a conditional field that should not be present will also be rejected.
Schema validation is the process by which a system checks a message against the XML schema definition, XSD, for that message type and version. The XSD defines the structure, the fields, the data types, and the allowed values. A message that does not conform to the XSD, for example because a field is missing, because a field has the wrong data type, or because a field has a value that is not in the allowed list, will fail schema validation and will be rejected. Schema validation is the first check a receiving bank performs, before it applies any business validation. A message that fails schema validation is not processed, and the sending bank receives a rejection, normally with a pacs.002 status of RJCT and a reason code of FF01, invalid file format, or a reason code that states the specific schema error.
External code sets are the lists of codes that ISO 20022 uses for fields such as the charge bearer, the purpose, the service level, the local instrument, the category purpose, and the status reason. The codes are published by ISO in the external code sets, and they are updated regularly. For example, the charge bearer code set includes DEBT, CRED, SHAR, and SLEV. The purpose code set includes SUPP for supplier payment, SALA for salary payment, RENT for rent payment, and TAXS for tax payment. The service level code set includes SEPA, URGP for urgent payment, and SDVA for same day value. The status reason code set includes AC01, AC04, AC06, AM04, AM05, AG01, MD07, RC01, and FF01. An SME must know the code sets, because a message with a code that is not in the code set will fail schema validation, and a message with a code the receiving bank does not recognise will be treated as an error, even if the code is valid.
Version management is the process of managing the different versions of a message, and it is a significant issue in ISO 20022, because the standard evolves and the versions change. A pacs.008.001.08 and a pacs.008.001.10 are different versions, and they have different fields and different rules. The CBPR+ usage guidelines specify which version to use for cross border payments, and they state the market practice rules that narrow the standard. A bank must support the version its counterparty uses, and it must handle the migration from one version to another. The migration is normally done on a big bang date, when all banks move to the new version at the same time, or on a phased basis, when the banks move in groups. An SME must know the version in use, and must plan for the migration, because a message in the wrong version will be rejected.
Market practice rules are the rules that a community, such as the CBPR+ community, or a scheme, such as SEPA, adds to the ISO 20022 standard, to narrow it to a specific implementation. The standard allows many options, and the market practice rules state which options to use. For example, the ISO 20022 standard allows the charge bearer to be DEBT, CRED, SHAR, or SLEV, but the CBPR+ market practice rules may state that only DEBT, CRED, and SHAR are allowed, and that SLEV is not used. The standard allows the remittance information to be structured or unstructured, but the market practice rules may state that only unstructured remittance information is used, and that it is limited to 140 characters. An SME must know the market practice rules for the community it works in, because a message that conforms to the standard but not to the market practice rules will be rejected by the receiving bank.
Truncation is a specific issue in the migration from MT to ISO 20022. The MT messages have fixed length fields, for example field 70 remittance information is 4 lines of 35 characters, a total of 140 characters. The ISO 20022 messages have longer fields, for example the unstructured remittance information is 140 characters, but the structured remittance information can be much longer. When a bank converts an MT103 to a pacs.008, it must map the MT fields to the ISO 20022 fields, and it must handle the cases where the MT field is longer than the ISO 20022 field, or where the ISO 20022 field is longer than the MT field. The CBPR+ usage guidelines state the truncation rules, and the bank must follow them, because a truncated field can lose information, and a lost remittance reference can cause the beneficiary to be unable to match the payment to an invoice.
For a business analyst, the field status and validation requirement must state the mandatory, optional, and conditional fields, the schema validation, the code sets, the version, and the market practice rules. The requirement should say that the system validates each message against the XSD before sending it, that it uses only the codes in the external code sets, that it uses the version specified in the CBPR+ usage guidelines, and that it follows the market practice rules for the community. A system that does not validate against the XSD will send invalid messages, and a system that does not follow the market practice rules will have its messages rejected by the receiving bank, even if they are valid against the standard.
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.