ISO/FDIS 20022-4

FINAL DRAFT
International
Standard
ISO/TC 68/SC 9
Financial services — Universal
Secretariat: AFNOR
financial industry message
Voting begins on:
scheme —
2025-12-31
Part 4:
Voting terminates on:
2026-02-25
XML Schema generation
Services financiers — Schéma universel de messages pour
l'industrie financière —
Partie 4: Génération de schéma XML
RECIPIENTS OF THIS DRAFT ARE INVITED TO SUBMIT,
WITH THEIR COMMENTS, NOTIFICATION OF ANY
RELEVANT PATENT RIGHTS OF WHICH THEY ARE AWARE
AND TO PROVIDE SUPPOR TING DOCUMENTATION.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO-
LOGICAL, COMMERCIAL AND USER PURPOSES, DRAFT
INTERNATIONAL STANDARDS MAY ON OCCASION HAVE
TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL
TO BECOME STAN DARDS TO WHICH REFERENCE MAY BE
MADE IN NATIONAL REGULATIONS.
Reference number
FINAL DRAFT
International
Standard
ISO/TC 68/SC 9
Financial services — Universal
Secretariat: AFNOR
financial industry message
Voting begins on:
scheme —
Part 4:
Voting terminates on:
XML Schema generation
Services financiers — Schéma universel de messages pour
l'industrie financière —
Partie 4: Génération de schéma XML
RECIPIENTS OF THIS DRAFT ARE INVITED TO SUBMIT,
WITH THEIR COMMENTS, NOTIFICATION OF ANY
RELEVANT PATENT RIGHTS OF WHICH THEY ARE AWARE
AND TO PROVIDE SUPPOR TING DOCUMENTATION.
© ISO 2025
IN ADDITION TO THEIR EVALUATION AS
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO-
LOGICAL, COMMERCIAL AND USER PURPOSES, DRAFT
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
INTERNATIONAL STANDARDS MAY ON OCCASION HAVE
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL
or ISO’s member body in the country of the requester.
TO BECOME STAN DARDS TO WHICH REFERENCE MAY BE
MADE IN NATIONAL REGULATIONS.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland Reference number
ii
Contents Page
Foreword .v
Introduction .vii
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Background . 1
5 ISO 20022 transformation rules for MessageSet . 2
5.1 Preconditions .2
5.2 Transformation constraints .2
5.2.1 General .2
5.2.2 Bare Schema without annotation .3
5.2.3 Full Schema with annotation .3
5.3 Namespaces .6
5.4 Granularity of schemas .7
6 XML MessageInstances . 7
6.1 Encoding .7
6.2 DOCTYPE .7
6.3 Default namespace .7
6.4 SchemaLocation .7
6.5 Abbreviated names .7
6.6 Completeness .7
7 Method . 7
8 Logical Classes . 8
8.1 MessageSet .8
8.2 MessageDefinition .8
8.3 MessageDefinitionIdentifier .9
8.4 MessageBuildingBlock .10
8.5 MessageComponentType .10
8.5.1 General .10
8.5.2 ExternalSchema .10
8.5.3 MessageComponent .11
8.5.4 ChoiceComponent .11
8.6 MessageElement . 12
8.6.1 General . 12
8.6.2 MessageAttribute . 12
8.6.3 MessageAssociationEnd where aggregation is composite . 12
8.6.4 MessageAssociationEnd where aggregation is none or shared . 12
9 User-defined data types .13
9.1 General . 13
9.2 Link data types .14
9.2.1 Pointer .14
9.3 Boolean data types .14
9.3.1 Boolean .14
9.3.2 Indicator . 15
9.4 Sequence data types . 15
9.4.1 Binary . 15
9.4.2 String . 15
9.4.3 Text .16
9.4.4 CodeSet.17
9.4.5 IdentifierSet .18
9.5 Numeric data types .18

iii
9.5.1 Decimal .18
9.5.2 Quantity .18
9.5.3 Rate .19
9.5.4 Amount .19
9.6 Temporal data types . 20
9.6.1 DateTime . 20
9.6.2 Date .21
9.6.3 Time .21
9.6.4 Year .21
9.6.5 Month . . . 22
9.6.6 Day . 22
9.6.7 YearMonth . 22
9.6.8 MonthDay . 23
9.6.9 Duration . 23
Annex A (informative) Generation rule summary .24
Bibliography .28

iv
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out through
ISO technical committees. Each member body interested in a subject for which a technical committee
has been established has the right to be represented on that committee. International organizations,
governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely
with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of ISO document should be noted. This document was drafted in accordance with the editorial rules of the
ISO/IEC Directives, Part 2 (see www.iso.org/directives).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent
rights in respect thereof. As of the date of publication of this document, ISO had not received notice of (a)
patent(s) which may be required to implement this document. However, implementers are cautioned that
this may not represent the latest information, which may be obtained from the patent database available at
www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 68, Financial services, Subcommittee SC 9,
Information exchange for financial services.
This second edition cancels and replaces the first edition (ISO 20022-4:2013), which has been technically
revised.
The main changes are as follows:
— Annotation is included to benefit users with meaningful information directly in the schema. Schema are
generated into different folders with and without annotation. Annotations include information relevant
to each concept such as full unabbreviated name, definition, identification scheme, unit code, base value,
meaning when true or false and versioning information.
— Minor versions are supported with the addition of optional attributes to indicate the draft, revision and
variation of the MessageDefinition. This metadata benefits users by enabling message writers to include
compatibility of content with minor versions in the same namespace as the major version.
— Identification of message content is supported by permitting an optional "id" attribute on compound
content. These can be referenced by elements for MessageAssocationEnds, and "ref" attributes on
elements for Pointer types. This benefits users by making it simple to reference existing types without
additional modelling of an explicit identifier and enables extension by direct reference of content in the
same message. The previous edition required explicit modelling of identifiers and references.
— CodeSets with Codes are distinguished from those without Codes used to reference other code lists that
are external to the schema.
— If a MessageDefinition has a root element, then a global element and type is generated for it instead of a
global element named for the MessageDefinition.
— MessageBuildingBlock is specified separately to MessageElement.
— Text types can indicate the language of the text, which is useful if it differs from the default. An attribute
“lang” of type “language” added to generation of Text types, if the language use is specified.

v
— Boolean and String are generated, and Integer has been removed, to match Metamodel Metaclasses.
— Binary types are generated as base64 by default, or as hexBinary if a preferred text encoding is specified
in the model.
— Only user defined classes and data types are transformed. XML Schema datatypes are generated for
user-defined DataTypes, but not for the Repository's XML Schema Type Library which has been replaced
by ISO/IEC 11404.
— Regrouping and reordering of metaclass and data type clauses and table entries, instead of English
collation order.
A list of all parts in the ISO 20022 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.

vi
Introduction
The ISO 20022 series defines a scalable, methodical process to ensure consistent descriptions of messages
throughout the financial services industry.
The purpose of the ISO 20022 series is to describe precisely and completely the externally observable aspects
of financial services messaging in a way that can be verified independently against operational messaging.
The trigger for the creation of the ISO 20022 series was the rapid growth in the scale and sophistication
of messaging within financial services during the 1990s using the ISO 15022 series. The financial services
industry (hereafter referred to as "the industry") created the first version of the ISO 20022 series as the
successor to the ISO 15022 series in response to that trigger. Since the ISO 15022 series, the industry has
broadened the scope from securities to the entire industry for the ISO 20022 series.
The ISO 20022 series is based on open technology standards, which historically have evolved more rapidly
than the industry itself. Consequently, the ISO 20022 series adopted a model-driven approach where the
model of the industry's messaging can evolve separately from the evolution of the messaging technology
standards. The period during which the ISO 20022 series has emerged followed the widespread adoption
of the internet for business. The eXtensible Mark-up Language (XML) emerged as the de facto standard for
document representation on the internet and it became the first syntax for the ISO 20022 series.
The modelling process is further refined into three levels which, in addition to the messaging technology
standard, is why the ISO 20022 series is based on four levels: the scope level, the conceptual level, the
logical level and the physical level. This four-level approach is based on the first four levels of the Zachman
[14]
Framework . The remaining two levels of the Zachman Framework are equivalent to the implementations
and the operational levels, respectively.
In ISO 20022-1, the first, second and third levels are described in Unified Modelling Language (UML) because
it is widely supported and supports multiple levels of abstraction. The models created in accordance with
ISO 20022-1 are technology independent in that they do not require any particular physical expression
or implementation. Such models aim to describe all parts of the message exchange. The models form the
definition of the protocol between participants exchanging messages. ISO 20022-1 defines a method that
describes a process by which these models can be created and maintained by the modellers.
The model and the physical level artefacts are stored in an ISO 20022 Repository (hereafter referred to as
"the Repository"). The Repository and physical level artefacts are exposed in a publicly accessible location,
such as a website, serviced by a Registration Authority. The name and contact information of the Registration
Authority for the ISO 20022 series can be found at www.iso.org/maintenance_agencies.
The Repository is organized into two areas:
— a DataDictionary containing the industry model elements likely to have further or repeated use;
— a BusinessProcessCatalogue that contains models describing specific MessageDefinitions and business
processes and physical syntax implementations.
The ISO 20022 series is organized into the following parts:
— ISO 20022-1 describes the metamodel of all the models and the Repository according to ISO/IEC 19502:2005
(MOF).
— ISO 20022-2 covers the UML profile, a grounding of general UML into a specific subset defined for the
ISO 20022 series (to be used when UML is selected to define the models).
— ISO 20022-3 describes a modelling method to produce models for the ISO 20022 series.
— This document covers XML schema generation rules to transform a logical level model into a physical
level description in the syntaxes.
— ISO 20022-5 covers business concept model interoperability, and logical model alignment and reverse
engineering.
vii
— ISO 20022-6 covers message transport characteristics that define the quality of service required by the
business process definitions so that they can operate successfully.
— ISO 20022-7 describes the process of managing the registration of models and physical syntax
implementations.
— ISO 20022-8 gives ASN.1 syntax generation rules to transform a logical level model into a physical level
description in ASN.1.
— ISO 20022-9 describes generic guidelines, which are used to define schema generation rules for any
specific syntax.
viii
FINAL DRAFT International Standard ISO/FDIS 20022-4:2025(en)
Financial services — Universal financial industry message
scheme —
Part 4:
XML Schema generation
1 Scope
This document complements the ISO 20022 Metamodel, as specified in ISO 20022-1, with the XML syntax
transformation rules to be applied by the ISO 20022 Registration Authority in order to translate an ISO 20022
compliant MessageDefinition into an XML Schema for the description and validation of XML Messages.
It specifies the transformation rules from the Logical to the Physical level. It is a deterministic transformation,
meaning that the resulting XML Schema is completely predictable for a given MessageDefinition. There is
neither manual input to the transformation itself nor manual adjustment to the result of the transformation.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
ISO 20022-1, Financial services — Universal financial industry message scheme — Part 1: Metamodel
RFC 5141, A Uniform Resource Name (URN) Namespace for the International Organization for Standardization
(ISO)
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 20022-1 apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org
4 Background
XML is a standard defined by the World Wide Web Consortium (W3C) that is used for the representation (i.e.
the syntax) of standardized ISO 20022 MessageDefinitions. XML leaves a lot of freedom for the exact way it
is used in a particular application. Therefore, merely stating that XML is used is not sufficient to guarantee
predictability; it is also necessary to explain how it will be used.
This document contains a set of XML design rules. These design rules define how a MessageDefinition is
transformed into an ISO 20022 XML Schema, which is used to validate that a message instance, as an XML
document, conforms with the structure, data types and constraints of an ISO 20022 MessageDefinition.
ISO 20022 XML Schema are annotated with documentation and application information to aide operational
staff and software developers to understand messages.

This document also describes how a MessageSet can be converted into XML Schemas by specifying how
a MessageDefinition is transformed into an XML Schema. This XML Schema will then make it possible to
use a validating XML Schema parser to automatically verify that a given XML Instance complies with the
constraints (or a subset of constraints) described in the MessageDefinition.
This document is limited to explaining how a given MessageDefinition will be mapped into XML Schema.
How to model a MessageDefinition can be found in ISO 20022-3.
NOTE Not all logical artefacts have a transformation rule.
5 ISO 20022 transformation rules for MessageSet
5.1 Preconditions
The MessageSet used as input for the transformation is a valid instance of the MessageSet meta-class.
5.2 Transformation constraints
5.2.1 General
An ISO 20022 XML Schema contains a top-level annotation, which contains the following metadata:
— the ISO 20022 Registration Authority (RA) software and its build number;
— the generation date and time;
— edition of the standard;
— the MessageDefinitionIdentifier's area, function, flavour, version;
— the MessageDefinition's draft, revision and variation.
EXAMPLE

Generated by Standards Editor (build:R2.4.0) on 2024 May 08 14:52:39,
ISO 20022 version : 2013


An ISO 20022 XML Schema is an implementation of the MessageDefinition. The MessageDefinition is always
the definitive source.
The schema design approach exhibits the “Venetian blind” pattern. XML Schema Definition (XSD) elements
are locally defined within their global complexType, except for two unreferenced global elements:
— A global element named for the MessageDefinition’s abbreviated name excluding the version. Its type is
the complexType for the MessageDefinition.
— A global element named for the MessageDefinition’s rootElement property. Its type is a complexType, also
named for the rootElement property, which contains one local element named for the MessageDefinition’s
abbreviated name excluding the version. The type of the local element is the complexType for the
MessageDefinition.
All aspects of dictionary management (e.g. reuse and pointers) are managed at the level of the
MessageDefinition. These aspects, among others, are covered in ISO 20022-3.
All complexType and simpleType elements in the XML Schema appear after the root element, in alphabetical
order, using the type "name" attribute as sort key.

For each MessageDefinition, an XML Schema is generated with annotation in a folder named “full” that
includes the definition of each generated repository concept, its full name if abbreviated and additional
metadata about the type. Annotation is then stripped to produce another XML Schema without annotation
in a folder named “bare”.
5.2.2 Bare Schema without annotation
Apart from the RA administered XML comment line, a bare ISO 20022 XML Schema without annotation
contains only information relevant for the validation of XML Instances by an XML Schema parser. For
example, it does not contain documentation (definitions, etc.) or implementation information (relationships
between similar Components, etc.).
EXAMPLE




maxOccurs="unbounded" minOccurs="0" />





5.2.3 Full Schema with annotation
A full ISO 20022 XML Schema with annotation contains documentation and metadata about each generated
concept, in addition to information relevant for the validation of XML Instances by an XML Schema parser.
The annotation directly benefits users, including software developers and operational staff, by providing
them direct access in the schema to the unabbreviated names, definitions and meaning of concepts, along
with constraints and metadata such as the units, referenced type and identification scheme.
Each Repository Concept (e.g. MessageElement, MessageComponentType or DataType) that is generated
into an XML Schema component (e.g. element, complexType or simpleType) is annotated with the concept’s
definition, full name if abbreviated and additional metadata. The benefit of this is that people working with
the schema can associate the name with its abbreviation and read the definition, without having to refer to
other documentation. Including documentation saves considerable time and money in development, without
affecting the speed of validation performance.
Each generated RepositoryConcept is annotated with an XML Element "xs:annotation" that contains:
— an XML Element “xs:documentation” for descriptive text properties, comprising:
— the unabbreviated “name” of the concept, important understanding MessageElement and Code;
— the “definition”.
— an XML Element "xs:appinfo" for other properties:
— with attributes named for each source property which contain the value of the property, qualified by
a namespace for annotations "urn:iso:std:iso:20022:tech:annotation";
— "name" for all concepts;
— "meaningWhenFalse" and "meaningWhenTrue" for Indicator;
— "unitCode" for Quantity;
— "baseUnitCode", "baseValue" for Rate;
— "identificationScheme" for IdentifierSet and Code Set;

— "reference" for Code Set;
— a "constraint" element for each constraint, which contains the value of the constraint’s
"expression" property; with an XML Attribute "lang" that has the escaped value of the constraint’s
"expressionLanguage" property if not empty.
Amounts with non-empty CurrencyIdentifierSet generate an additional simple type for the quantity which
has documentation "Quantity of " appended by the name of the Amount type.
Each MessageComponentTypes that is referenced by non-composite Message Association Ends generates an
additional reference type, with “xs: documentation” containing "Reference to " appended by the name of the
Message Component Type and an “xs: appInfo” with an attribute:
— "type", which contains the value of the concept’s "name" property.
MessageDefinition also contains appInfo attributes:
— "area", "function", "flavour" and "version" for the properties of "messageDefinitionIdentifier";
— "revision", "variant" and "draft" for minor version properties of MessageDefinition.
— "RepoDate", "Generator" and "Generated" for the date of the repository, date time the schema was
generated and the identity of the generator software.
— "RegistrationStatus" for its registration status in the repository, its revision and variant.
Amounts with non-empty CurrencyIdentifierSet generate an additional simple type for the quantity which
has documentation "Quantity of " appended by the name of the Amount type.
For each constraint on the Repository Concept, it also contains:
— "constraint" which contains the value of the constraint’s "expression" property; with an XML Attribute
"xml: lang" that has the escaped value of the constraint’s "expressionLanguage" property if not empty.
EXAMPLE 1 Partial schema showing annotations for a MessageDefinition:
xmlns="urn:iso:std:iso:20022:tech:xsd:auth.030.001.04"
xmlns:a="urn:iso:std:iso:20022:tech:annotation"
xmlns:xs="https://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
targetNamespace="urn:iso:std:iso:20022:tech:xsd:auth.030.001.04">

Example Schema for auth.030.001.04-DerivativesTradeReportV04 xs:documentation>
a:name="DerivativesTradeReportV04"
a:area="auth"
a:function="030"
a:flavour="001"
a:version="04"
a:revision="1"
a:Generated="2024-11-02T20-04-31Z"
a:RepoDate="20240729"
a:Generator="iso20022.plus generator 20241102"/>



DerivativesTradeReportV04
The DerivativesTradeReport message is sent by the report submitting entity to the trade
repository (TR) to report on the derivative transactions or sent by the trade repository (TR)
to the authority or made available by the trade repository (TR) to the report submitting
entity and the reporting counterparty as well as the entity responsible for reporting, if
applicable.
a:id="_3L9iYY0PEe65bovx6QuVaA"
a:name="DerivativesTradeReportV04"

/>




ReportHeader
Header information related to metadata of report message.





TradeData
Data concerning the reporting trade.



maxOccurs="unbounded"
minOccurs="0"
name="SplmtryData"
type="SupplementaryData1">

SupplementaryData
Additional information that cannot be captured in the structured fields and/or any other
specific block.








EXAMPLE 2 Partial schema showing annotations for a CodeSet:


TradingCapacity7Code
Specifies the role of a trading party in a transaction.
a:id="_w9KyoPP1EeS_qLctCs2aRQ"
a:name="TradingCapacity7Code"
a:sourceCodeSet="_YqqBBtp-Ed-ak6NoX_4Aeg_-1705783512"
a:sourceCodeSet_name="TradingCapacityCode"/>




Agent
Trading as Agent on behalf of a customer.





Principal
Trading as Principal.





EXAMPLE 3 Partial schema showing annotations for an Indicator:


GroupCancellationIndicator
Indicates whether or not it is a group cancellation.

a:name="GroupCancellationIndicator"
a:meaningWhenTrue="Indicates that the cancellation applies to the complete group."
a:meaningWhenFalse="Indicates that the cancellation applies to individual items within the
group."/>



EXAMPLE 4 Partial schema showing annotations for a Rate:


PercentageBoundedRate
Rate expressed as a percentage, ie, in hundredths, eg, 0.7 is 7/10 of a percent, and 7.0 is
7%.









5.3 Namespaces
There are several namespace declarations used in the XML Schema:
a) The targetNamespace, which is the namespace to which all XSD Elements and Types belong. The URN,
which shall be in accordance with RFC 5141, consists of:
1) a fixed part comprising the simple ISO URN for this series of documents (the originator, type and
document number without the part number), i.e. “urn: iso: std: iso: 20022”;
2) followed by the technical committee defined string for XML Schema. i.e. “:tech: xsd:”;
3) appended by a part unique to each schema, its MessageDefinitionIdentifier as defined in 8.3. e.g.
“camt.007.001.01”.
b) The XML Schema namespace as defined by Reference [4], with a prefix of "xs".
c) The default namespace, which is the same as the TargetNamespace.
d) A namespace for annotations "urn: iso: std: iso: 20022: tech: annotation", with a prefix of "a".
EXAMPLE 1 Namespace declarations in an ISO 20022 XML Schema:
targetNamespace="urn:iso:std:iso:20022:tech:xsd:camt.007.001.01"
xmlns="urn:iso:std:iso:20022:tech:xsd:camt.007.002.01"
xmlns:a="urn:iso:std:iso:20022:tech:annotation"
xmlns:xs="https://www.w3.org/2001/XMLSchema">

EXAMPLE 2 Namespace declarations in an ISO 20022 XML Instance:


Or, in case the Sender decides to use the default namespace:


NOTE The MessageDefinitionIdentifier distinguishes the target namespace of the schema. This ensures that only
message instances of this specific flavour and version of the message can be validated with this schema. Different
flavours and other versions of the same business area and functionality cannot be validated by this schema, even if
they are structurally compatible. Users can define restrictions on the base schema for their own implementation as
long as the instances can be validated with the base schema as registered with the ISO 20022 series. These variants
a
...