What is ISO 20022 message schema validation?

ISO 20022 message schema validation checks whether a message encoded as XML conforms to the XML Schema Definition (XSD) for the intended ISO 20022 message version. It checks document structure, element order, data types, permitted values and occurrence rules defined by that schema. A passing result confirms structural conformance; separate tests are needed for business rules and a receiving network's usage requirements.

What schema validation checks

ISO 20022 defines financial message models and message definitions. An XSD describes the structure of an XML representation of a message. A validator parses the XML and checks it against that schema, including its namespace and any imported schema components.

Depending on the message definition, checks can cover required or optional elements, element order, cardinality, data types, patterns, length limits and enumerated values. For example, an XSD can reject a date that does not match its declared format or an element placed where the schema does not allow it.

The result depends on using the schema for the intended message type and version. A payment message may be structurally valid against one version and invalid against another. Implementations may also apply a market practice or network usage guideline that narrows the permitted content beyond the base schema.

What schema validation does not establish

A valid XML message may still contain a payment that fails business or operational checks. Schema validation alone cannot confirm that an account exists, that a currency is supported for a particular route, or that the sender is authorised to submit the transaction. Those checks belong in business rule, integration or end-to-end testing, as applicable.

A base ISO 20022 schema may also permit content that a specific market practice or network rejects. Test that profile's additional rules separately. XML schema constraints have limits too: a schema may not express every conditional rule or relationship between values required by the business process.

A practical validation example

Suppose a test sends a pacs.008 credit transfer. The test must use the XSD for the exact message version expected by the receiving interface, along with any schema dependencies. A validator can check whether the XML document conforms to that XSD. Removing a required element, changing the namespace, or supplying an invalid value for a constrained field should produce a validation failure when that condition is prohibited by the selected schema.

For a local XSD file, a command-line check can look like this:

xmllint --noout --schema path/to/pacs.008.xsd payment.xml

The command's exit status and diagnostic output provide the result. Imported schemas must also be available to the validator. In automated tests, keep the schema files and their dependencies under controlled versioning rather than relying on an unpinned remote copy. This makes failures reproducible when schemas or environments change.

A useful test set includes a valid message, malformed XML, a wrong namespace, a missing required element and an invalid constrained value. For each case, assert both the validation result and the application's handling of it. A rejected message should produce the expected error or rejection status, rather than being silently altered or processed.

How to verify the result in a test pipeline

Record which message definition, schema version and profile the test uses. Check that the validator reports the expected outcome for valid and invalid fixtures, and inspect diagnostics when a test fails. Then run separate assertions for business rules and any receiving-system requirements. This keeps a schema validation pass distinct from evidence that the payment workflow itself is correct.