ISO/FDIS 20022-8
(Main)Financial services — Universal financial industry message scheme — Part 8: ASN.1 generation
Financial services — Universal financial industry message scheme — Part 8: ASN.1 generation
ISO 20022-8:2013 describes the transformation rules to generate ASN.1 abstract syntax from an ISO 20022 compliant MessageDefinition. The generated abstract syntax is for the description and validation of Messages. The transformation rules are a transformation from Level 3 to Level 4. It is a deterministic transformation, meaning that the resulting ASN.1 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. ISO 20022-8:2013 is the ASN.1 equivalent of ISO 20022-4:2013. In ISO 20022-4:2013 the abstract syntax generated is XML Schema; in ISO 20022-8:2013 it is ASN.1. In ISO 20022-4:2013 the only encoding supported is UTF-8 XML; in ISO 20022-8:2013 there are multiple encodings supported for ASN.1. These include all the standard encodings, but in addition the ability to register custom encodings in ECN.
Services financiers — Schéma universel de messages pour l'industrie financière — Partie 8: Génération ASN.1
General Information
- Status
- Not Published
- Technical Committee
- ISO/TC 68/SC 9 - Information exchange for financial services
- Drafting Committee
- ISO/TC 68/SC 9 - Information exchange for financial services
- Current Stage
- 5020 - FDIS ballot initiated: 2 months. Proof sent to secretariat
- Start Date
- 31-Dec-2025
- Completion Date
- 31-Dec-2025
Relations
- Effective Date
- 06-Jun-2022
Overview - ISO 20022-8 (ASN.1 generation)
ISO/FDIS 20022-8 defines deterministic transformation rules to generate ASN.1 abstract syntax from an ISO 20022-compliant MessageDefinition (Level 3 → Level 4). The generated ASN.1 artefacts are used for the description and validation of financial messages. This part of the ISO 20022 family is the ASN.1 equivalent of ISO 20022-4 (which generates XML Schema) and supports multiple ASN.1 encodings - including standard encodings and custom encodings that can be registered in ECN and stored in the ISO 20022 Repository.
Key topics and technical requirements
- Deterministic transformation: For a given MessageSet, the resulting ASN.1 is fully predictable; the generation has no manual inputs or post‑generation adjustments.
- Input precondition: The generator accepts a single, valid instance of the MessageSet metaclass as input.
- Repository and registration: ASN.1 is represented in the Repository as a SyntaxScheme; every ISO/IEC 8825 encoding must be registered as an EncodingScheme. Custom encodings can be added via ECN definitions.
- Module structure and granularity: Rules cover module headers, naming, tagging and extensibility environments, and how logical components map to ASN.1 modules.
- Encoding support: Multiple ASN.1 encodings are supported (standard and registered custom encodings). Binary data type representations (base64, base16) are supported.
- Completeness and validation: Generated ASN.1 is designed to be complete for message description and validation; choices and message elements are constrained to prevent empty constructs.
- Metamodel mapping: Detailed mapping rules describe how ISO 20022 metamodel concepts (MessageComponentTypes, DataTypes, associations) translate into ASN.1 artefacts, including support for Pointer, String and Boolean types and optional attributes (revision, variation, draft, id).
- Normative references: Includes ISO 20022-1 (metamodel) and ISO/IEC 8825-5 (ASN.1 / XML schema mapping).
Practical applications and users
Who uses ISO 20022-8:
- Financial institutions (banks, clearinghouses, payment systems) implementing binary ASN.1 message exchanges.
- Message designers and standards implementers who need deterministic, machine‑generable ASN.1 schemas from ISO 20022 models.
- Software vendors and middleware providers building validators, encoders/decoders, and high-performance messaging gateways.
- Registration Authorities and repository managers registering SyntaxSchemes and EncodingSchemes.
Practical uses:
- Automating generation of ASN.1 schemas for interoperability testing and runtime validation.
- Enabling efficient binary encodings for high-throughput payment and securities systems.
- Registering and managing custom encodings via ECN to support proprietary or optimized encodings while remaining standards-compliant.
Related standards
- ISO 20022-1 (Metamodel)
- ISO 20022-4 (XML Schema generation)
- ISO/IEC 8825-5 (ASN.1 / W3C XML Schema mapping)
- ISO 20022 series (message modelling and repository governance)
Keywords: ISO 20022-8, ASN.1 generation, financial messaging, MessageSet, ISO 20022, ASN.1 encodings, ECN, deterministic transformation, message validation.
ISO/FDIS 20022-8 - Financial services — Universal financial industry message scheme — Part 8: ASN.1 generation Released:17. 12. 2025
REDLINE ISO/FDIS 20022-8 - Financial services — Universal financial industry message scheme — Part 8: ASN.1 generation Released:17. 12. 2025
Frequently Asked Questions
ISO/FDIS 20022-8 is a draft published by the International Organization for Standardization (ISO). Its full title is "Financial services — Universal financial industry message scheme — Part 8: ASN.1 generation". This standard covers: ISO 20022-8:2013 describes the transformation rules to generate ASN.1 abstract syntax from an ISO 20022 compliant MessageDefinition. The generated abstract syntax is for the description and validation of Messages. The transformation rules are a transformation from Level 3 to Level 4. It is a deterministic transformation, meaning that the resulting ASN.1 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. ISO 20022-8:2013 is the ASN.1 equivalent of ISO 20022-4:2013. In ISO 20022-4:2013 the abstract syntax generated is XML Schema; in ISO 20022-8:2013 it is ASN.1. In ISO 20022-4:2013 the only encoding supported is UTF-8 XML; in ISO 20022-8:2013 there are multiple encodings supported for ASN.1. These include all the standard encodings, but in addition the ability to register custom encodings in ECN.
ISO 20022-8:2013 describes the transformation rules to generate ASN.1 abstract syntax from an ISO 20022 compliant MessageDefinition. The generated abstract syntax is for the description and validation of Messages. The transformation rules are a transformation from Level 3 to Level 4. It is a deterministic transformation, meaning that the resulting ASN.1 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. ISO 20022-8:2013 is the ASN.1 equivalent of ISO 20022-4:2013. In ISO 20022-4:2013 the abstract syntax generated is XML Schema; in ISO 20022-8:2013 it is ASN.1. In ISO 20022-4:2013 the only encoding supported is UTF-8 XML; in ISO 20022-8:2013 there are multiple encodings supported for ASN.1. These include all the standard encodings, but in addition the ability to register custom encodings in ECN.
ISO/FDIS 20022-8 is classified under the following ICS (International Classification for Standards) categories: 03.060 - Finances. Banking. Monetary systems. Insurance. The ICS classification helps identify the subject area and facilitates finding related standards.
ISO/FDIS 20022-8 has the following relationships with other standards: It is inter standard links to ISO 20022-8:2013. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.
ISO/FDIS 20022-8 is available in PDF format for immediate download after purchase. The document can be added to your cart and obtained through the secure checkout process. Digital delivery ensures instant access to the complete standard document.
Standards Content (Sample)
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 8:
Voting terminates on:
2026-02-25
ASN.1 generation
Services financiers — Schéma universel de messages pour
l'industrie financière —
Partie 8: Génération ASN.1
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 8:
Voting terminates on:
ASN.1 generation
Services financiers — Schéma universel de messages pour
l'industrie financière —
Partie 8: Génération ASN.1
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 .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 ISO 20022 transformation rules for MessageSet . 1
4.1 Registration and Repository .1
4.2 Preconditions .2
4.3 Transformation constraints .2
4.4 Module Header .2
4.4.1 General .2
4.4.2 Module Name .2
4.4.3 Module identification .3
4.4.4 Definition of the tagging environment .3
4.4.5 Definition of the extensibility environment .3
4.5 Granularity of Modules .3
4.6 Encoding Messages .3
4.7 Completeness .3
4.8 Method .4
4.8.1 General .4
4.8.2 Relationship between metamodel concepts and ASN.1 artefacts .4
4.8.3 ISO 20022 DataType transformation to ASN.1 .7
Annex A (informative) Background . 17
Bibliography . 19
iii
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-8:2013), which has been technically
revised.
The main changes are as follows:
— generation of a root element and type, only if specified for the MessageDefinition;
— added optional attributes revision, variation, and draft;
— added optional attribute “id” to MessageComponentTypes to enable internal referencing by non-
compoiste MessageAssociationEnds and Pointers, using the Token type;
— added generation of Pointer, String and Boolean data types, to align with metamodel;
— support for base 64 and base 16 representations of binary data types;
— MessageElements in a ChoiceComponent are required, to prevent empty choices.
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.
iv
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 (from here on 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 Web 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
[24]
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 the
ISO 20022 series 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 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 message definitions 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.
— ISO 20022-4 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.
v
— 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.
— This document 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.
vi
FINAL DRAFT International Standard ISO/FDIS 20022-8:2025(en)
Financial services — Universal financial industry message
scheme —
Part 8:
ASN.1 generation
1 Scope
This document describes the transformation rules to generate ASN.1 abstract syntax from an ISO 20022
compliant MessageDefinition. The generated abstract syntax is for the description and validation of
Messages.
The transformation rules are a transformation from Level 3 to Level 4. It is a deterministic transformation,
meaning that the resulting ASN.1 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.
This document is the ASN.1 equivalent of ISO 20022-4. In ISO 20022-4 the abstract syntax generated is XML
Schema; in this document it is ASN.1. In ISO 20022-4 the only encoding supported is UTF-8 XML; in this
document there are multiple encodings supported for ASN.1. These include all the standard encodings, but
in addition the ability to register custom encodings in ECN.
2 Normative references
The following referenced documents are indispensable for the application 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
ISO/IEC 8825-5:2021, Information technology — ASN.1 encoding rules — Part 5: Mapping W3C XML schema
definitions into ASN.1
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 ISO 20022 transformation rules for MessageSet
4.1 Registration and Repository
ASN.1 is present in the Repository as a SyntaxScheme. Every ISO/IEC 8825 Encoding shall be added to the
Repository as an EncodingScheme for the ASN.1 Syntax Scheme. The Registration Authority may register
additional EncodingSchemes in the Repository for ASN.1 if they can be completely and precisely described in
ECN. The definition in ECN shall be included in the Repository.
4.2 Preconditions
The input parameter to the generation is a single MessageSet.
The MessageSet used as input for the transformation is a valid instance of the MessageSet metaclass.
4.3 Transformation constraints
The generated Abstract Syntax contains a Comment at the start of the document containing metadata about
the generation from the generator, not the MessageSet, including the following:
— the ISO 20022 RA issued release number;
EXAMPLE 1 R6.1.0.2.
— the generation date in ISO 8601 format;
EXAMPLE 2 2009-06-30Z.
— documentation text (optional) (the content of this field is undefined in this document);
EXAMPLE 3 R6.1.0.2 2009-06-30Z.
— edition of the standard.
EXAMPLE 4 ISO 20022-8:2025.
The Abstract Syntax is a syntactical representation of the MessageDefinition. The Abstract Syntax does not
contain the full semantics of a Message. The MessageDefinition is always the definitive description of the
semantics of a Message.
The Abstract Syntax is at Level 4 of the ISO 20022 levels. Information about types such as Message
Components and Message Elements that are common across Message Definitions is lost at Level 4. For
example, the commonality of a single Message Element in two different Message Definitions will be lost
in the Abstract Syntax because they will generate to separate Modules for each Message Definition. The
semantic relationship between PDUs can only be understood at Level 3 and Level 2.
All Types appear in the ASN.1 in alphabetical order, using the ASN.1 Type Name as the sort key.
4.4 Module Header
4.4.1 General
Each item in the Module Header appears on a separate line.
4.4.2 Module Name
The Module Name is the concatenation of "ISO20022-" and the MessageDefinitionIdentifier property.
The resulting Module Name can require alterations to be legal ASN.1:
a) If the first character of the Module Name is not an alphabetic character, then add a prefix of "U".
b) If the first character is a lower case alphabetic character, then convert it to its equivalent upper case
alphabetic character.
c) Any other invalid characters in the name are substituted with hyphens.
NOTE 1 This step is necessary as ASN.1 has tighter requirements for a Module Name than ISO 20022 has for a
Message Definition Identifier.
NOTE 2 If the Module Name ever changes, a) and b) become effective. Until then, they bring no value.
EXAMPLE ISO20022-AccountDetailsConfirmationV02.
4.4.3 Module identification
Each Module is identified by an Object Identifier (OID). The OID comes from the Message Definition's OID
property.
EXAMPLE AccountDetailsConfirmationV02 {iso(1) standard(0) unifi(20022)
accountDetailsConfirmationV02(12345) }.
4.4.4 Definition of the tagging environment
The tagging environment is defined as "XER INSTRUCTIONS" and "AUTOMATIC TAGS".
4.4.5 Definition of the extensibility environment
Within ASN.1 notation, XSD refers to the XSD Module defined by ISO/IEC 8825-5.
All XSD datatypes used in the MessageSet are Imported from OID {joint-iso-itu-t(2) asn1(1) specification(0)
modules(0) xsd-module(2)}.
The Module for XSD is always generated; the name of the document is always XSDv2.asn.
NOTE The name of the document is the filename for a file system. The Imports for the generated Module include
every type from the XSD Module used.
The Imports include any type XSD type used.
4.5 Granularity of Modules
There is one well-formed and valid ASN.1 Module per MessageDefinition.
NOTE 1 The declaration of which types are protocol data units (PDUs) is not declared in an ASN.1 Module. The
generated Module will not indicate which types are PDUs.
NOTE 2 For ISO 20022 any generated ASN.1 Type not referenced by another Type can be considered to be a PDU.
This holds true because this document only generates types referred to directly or indirectly from the Message
Definition.
NOTE 3 The PDU is analogous to the XML Schema generation's global root element, derived from MessageDefinition.
rootElement.
4.6 Encoding Messages
ASN.1 is to be added to the Repository as a SyntaxScheme.
Every ISO/IEC 8825 Encoding is to be added to the Repository as an EncodingScheme for the ASN.1 Syntax
Scheme.
The Registration Authority may register additional EncodingSchemes in the Repository for ASN.1 if they can
be completely and precisely described in ECN. The definition in ECN shall be included in the Repository.
An ISO 20022 Valid Message shall conform with a SyntaxScheme and EncodingScheme in the Repository. No
other SyntaxScheme or EncodingSchemes are valid for ISO 20022.
4.7 Completeness
The list of transformation rules described in this clause is complete, which means that no other
transformation rules are applicable. Therefore, no other information may be added to the ASN.1 outside of
what is allowed by these transformation rules.
The Module is a representation of the MessageDefinition.
4.8 Method
4.8.1 General
1)
A MessageSet is composed of a limited number of distinct modelling patterns (see ISO 20022-1:— , Figure 7
for a depiction of the Message Metamodel).
By defining the transformation rules from those patterns to ASN.1, any MessageSet and its MessageDefinitions
can be transformed into its corresponding ASN.1 Modules.
4.8.2 Relationship between metamodel concepts and ASN.1 artefacts
4.8.2.1 MessageSet
Each MessageSet is transformed into an artefact of MIME type application/zip containing a file for the
MessageDefinition Module and a single file for the XSD Library Module.
4.8.2.2 MessageDefinition
The file name for the MessageDefinition Module is the MessageDefinitionIdentifier with an extension of
".asn".
EXAMPLE 1 camt.001.040.01.asn.
If the Message Definition has a value for the Property rootElement, then the MessageDefinition Module
contains a root element named for the value of Property rootElement, and a root type with the same name
suffixed by "-1" which has a sequence comprising the name and type for the MessageDefinition's name.
Otherwise it contains an element and type for the value of the MessageDefinition's name. The type for the
MessageDefinition is transformed into an ASN.1 SEQUENCE whereby the MessageComponent's Name is the
value of the SEQUENCE name.
— The SEQUENCE includes attributes for minor versioning whose components are:
— revision "[NAME AS "revision"]" and "[ATTRIBUTE]";
— variation "[NAME AS "variation"]" and "[ATTRIBUTE]";
— draft "[NAME AS "draft"]" and "[ATTRIBUTE]".
— The SEQUENCE preserves the order of the MessageElements. The transformation rules for
MessageElements are given in 4.8.2.6, 4.8.2.8 and 4.8.2.9.
— Each Component within the SEQUENCE is followed by a comma, except for the last one.
EXAMPLE 2
/* Generated by SWIFTStandards Workstation (build:R5.1.0.4) on 2006 Sep
08 11:58:39 */
Camt-001-040-01
DEFINITIONS XER INSTRUCTIONS AUTOMATIC TAGS ::= BEGIN IMPORTS
String, Decimal, Date, DateTime
FROM XSD;
Camt-001-040-01-OID OBJECT IDENTIFIER ::= {iso(1) registration-authority(1) unifi(20022) cash-
management(0)}
Document ::= [ELEMENT] Document-1 IDENTIFIED BY
{camt-001-040-01-OID abstract-syntax{1})}
1) Under preparation. Stage at the time of publication: ISO/DIS 20022-1:2025.
Document-1 ::= [NAME AS "Document"] SEQUENCE {
notificationOfInterestV02 [NAME AS " NotificationOfInterestV02"] Camt-001-040-01 }
4.8.2.3 MessageComponent
A MessageComponent is transformed into an ASN.1 SEQUENCE whereby the MessageComponent's Name is
the value of the SEQUENCE name.
— The SEQUENCE includes an identifier attribute for internal cross referencing components is:
— identifier "[NAME AS "id"]" and "[ATTRIBUTE]" of type XSD.Token.
— The SEQUENCE preserves the order of the MessageElements. The transformation rules for
MessageElements are given in 4.8.2.6, 4.8.2.8 and 4.8.2.9.
— Each Component within the SEQUENCE is followed by a comma, except for the last one.
EXAMPLE
AccountIdentification3Choice ::= SEQUENCE {
Id [NAME AS CAPITALIZED] String,
postalAddress [NAME AS CAPITALIZED] PostallAddress1 OPTIONAL
}
4.8.2.4 ChoiceComponent
A ChoiceComponent is transformed into a SEQUENCE comprising an identifier attribute and a CHOICE.
— The SEQUENCE includes an identifier attribute for internal cross-referencing components is:
— identifier "[NAME AS "id"]" and "[ATTRIBUTE]" of type XSD.Token.
Each Alternative within the CHOICE is followed by a comma, except for the last one.
EXAMPLE
PlaceOfTradeIdentification1Choice ::= SEQUENCE {
choice [UNTAGGED] CHOICE {
country [NAME AS CAPITALIZED] CountryCode,
overTheCounter [NAME AS CAPITALIZED] Max35Text
}
}
4.8.2.5 ExternalSchema
ExternalSchema is transformed into a TypeAssignment as follows:
— ExternalSchema Name is transformed into its Typereference.
— Type is transformed into "XSD.AnyType".
EXAMPLE
FIXInstructionType ::= XSD.AnyType.
4.8.2.6 MessageElement
MessageElement in a MessageComponent is transformed into a Component.
MessageElement in a ChoiceComponent is transformed into an Alternative.
MessageElement Name is transformed into the Identifier of the Component or Alternative, whereby the first
character is put in lowercase.
a) If MaximumOccurrence is greater than "1", then the Component or Alternative Identifier is concatenated
with "-list":
1) followed by "[UNTAGGED] SEQUENCE (SIZE (";
2) followed by the value of MinimumOccurrence if part of a MessageComponent, or "1" if part of a
ChoiceComponent;
3) followed by ".".
b) If MaximumOccurrence contains a number followed by the value of MaximumOccurrence.
c) If MaximumOccurrence contains "UNBOUNDED" then followed by "MAX":
1) followed by ")) OF";
2) followed by the Identifier of the Component or Alternative;
3) followed by the XER encoding instruction "[NAME AS ";
4) followed by the result of the abbreviation algorithm for that MessageElement Name, in quotes;
5) followed by "]";
6) followed by the MessageElement Type Name.
d) If it is part of a MessageComponent or MessageBuildingBlock, and MinimumOccurrence is "0" and
MaximumOccurrence is "1", followed by " OPTIONAL":
1) followed by "(CONSTRAINED BY {/*", followed by "NameAndDefinition ", followed by the
concatenation of MessageElement Name, “.”, Newline and MessageElement Definition, followed by
the transformation for each Constraint (see 4.8.2.10), followed by "*/})".
EXAMPLE
postalAddress [NAME ASpstlAddrss] PostallAddress1 OPTIONAL,
(CONSTRAINED BY {/*"NameAndDefinition PostalAdress.
information that locates and identifies a specifi
...
ISO/DISFDIS 20022-8:2025(en)
Second edition
2025-01-07
ISO/TC 68/SC 9
Secretariat: AFNOR
Date: 2025-12-11
Financial services — Universal financial industry message scheme —
—
Part 8:
ASN.1 generation
Services financiers — Schéma universel de messages pour l'industrie financière —
Partie 8: Génération ASN.1
FDIS stage
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication
may be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying,
or posting on the internet or an intranet, without prior written permission. Permission can be requested from either ISO
at the address below or ISO'sISO’s member body in the country of the requester.
ISO Copyright Officecopyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: + 41 22 749 01 11
Email: copyright@iso.org
E-mail: copyright@iso.org
Website: www.iso.orgwww.iso.org
Published in Switzerland.
ICS 03.060
Price based on 25 pages
ii
ISO/DISFDIS 20022-8:2025(en)
Contents Page
Foreword . iv
Introduction . vii
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 ISO 20022 transformation rules for MessageSet . 1
4.1 Registration and Repository . 1
4.2 Preconditions . 2
4.3 Transformation constraints . 2
4.4 Module Header . 2
4.5 Granularity of Modules . 3
4.6 Encoding Messages . 4
4.7 Completeness . 4
4.8 Method . 4
Annex A (informative) Background . 25
Bibliography . 27
Foreword . iv
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Background . 1
5 ISO 20022 transformation rules for MessageSet . 3
5.1 Registration and Repository . 3
5.2 Preconditions . 3
5.3 Transformation constraints . 3
5.4 Module Header . 3
5.4.1 General. 3
5.4.2 Module Name . 3
5.4.3 Module identification . 4
5.4.4 Definition of the tagging environment . 4
5.4.5 Definition of the extensibility environment . 4
5.5 Granularity of Modules . 4
5.6 Encoding Messages . 4
5.6.1 Encoding . 4
5.7 Completeness . 5
5.8 Method . 5
5.8.1 General. 5
5.8.2 Relationship between metamodel concepts and ASN.1 artefacts . 5
5.8.3 ISO 20022 DataType transformation to ASN.1 . 11
Bibliography 25
iii
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-58:2013), which has been technically
revised.
The main changes are as follows:
— — generation of a root element and type, only if specified for the MessageDefinition;
— — added optional attributes revision, variation, and draft;
— — added optional attribute “id” to MessageComponentTypes to enable internal referencing by non-
compoiste MessageAssociationEnds and Pointers, using the Token type;
— — added generation of Pointer, String and Boolean data types, to align with metamodel;
— — support for base 64 and base 16 representations of binary data types;
— — MessageElements in a ChoiceComponent are required, to prevent empty choices.
ICS 03.060
Price based on 25 pages
iv
ISO/DISFDIS 20022-8:2025(en)
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.
v
This document mostly retains the structure of the 2013 edition. This document
can be revised to align with the structure of ISO 20022-4 and ISO 20022-
9.Introduction
ICS 03.060
Price based on 25 pages
vi
ISO/DISFDIS 20022-8:2025(en)
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 (from here on 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 Web 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 Framework. 0 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 the
ISO 20022 series 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 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_agencieswww.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 message definitions and
business processes and physical syntax implementations.
The ISO 20022 series is organized into the following parts:
— — ISO 20022-1 describes in Meta-Object Facility (MOF) 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 this
documentthe ISO 20022 series (to be used when UML is selected to define the models).
vii
— — ISO 20022-3 describes a modelling method to produce models for this documentthe ISO 20022 series.
— — ISO 20022-4 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 of existing message syntaxes.
— — 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.
— — This document gives ASN.1 syntax generation rules to transform a Logicallogical level model into a
Physicalphysical level description in ASN.1.
— — ISO 20022-9 describes generic guidelines which are used to define schema generation rules for any
specific syntax.
ICS 03.060
Price based on 25 pages
viii
DRAFT International Standard ISO/DIS 20022-8:2025(en)
Financial services — Universal financial industry message scheme —
—
Part 8:
ASN.1 generation
1 Scope
This document describes the transformation rules to generate ASN.1 abstract syntax from an ISO 20022
compliant MessageDefinition. The generated abstract syntax is for the description and validation of Messages.
The transformation rules are a transformation from Level 3 to Level 4. It is a deterministic transformation,
meaning that the resulting ASN.1 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.
This document is the ASN.1 equivalent of ISO 20022-4. In ISO 20022-4 the abstract syntax generated is XML
Schema; in this document it is ASN.1. In ISO 20022-4 the only encoding supported is UTF-8 XML; in this
document there are multiple encodings supported for ASN.1. These include all the standard encodings, but in
addition the ability to register custom encodings in ECN.
2 Normative references
The following referenced documents are indispensable for the application 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
ISO/IEC 8825--5:2021, Information technology — ASN.1 encoding rules — Part 5: Mapping W3C XML schema
definitions into ASN.1
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 ISO 20022 transformation rules for MessageSet
4.1 Registration and Repository
ASN.1 is present in the Repository as a SyntaxScheme. Every ISO/IEC 8825 Encoding shall be added to the
Repository as an EncodingScheme for the ASN.1 Syntax Scheme. The Registration Authority may register
Under preparation. Stage at the time of publication: ISO/DIS 20022-1:2025.
additional EncodingSchemes in the Repository for ASN.1 if they can be completely and precisely described in
ECN. The definition in ECN shall be included in the Repository.
4.2 Preconditions
The input parameter to the generation is a single MessageSet.
The MessageSet used as input for the transformation is a valid instance of the MessageSet metaclass.
4.3 Transformation constraints
The generated Abstract Syntax contains a Comment at the start of the document containing metadata about
the generation from the generator, not the MessageSet, including the following.:
— — the ISO 20022 RA issued release number;
EXAMPLE 1 R6.1.0.2.
— — the generation date in ISO 8601 format;
EXAMPLE 2 2009-06-30Z.
— — documentation text (optional) (the content of this field is undefined in this document);
EXAMPLE 3 R6.1.0.2 2009-06-30Z.
— — edition of the standard.
EXAMPLE 4 ISO 20022-8:2025.
The Abstract Syntax is a syntactical representation of the MessageDefinition. The Abstract Syntax does not
contain the full semantics of a Message. The MessageDefinition is always the definitive description of the
semantics of a Message.
The Abstract Syntax is at Level 4 of the ISO 20022 levels. Information about types such as Message
Components and Message Elements that are common across Message Definitions is lost at Level 4. For
example, the commonality of a single Message Element in two different Message Definitions will be lost in the
Abstract Syntax because they will generate to separate Modules for each Message Definition. The semantic
relationship between PDUs can only be understood at Level 3 and Level 2.
All Types appear in the ASN.1 in alphabetical order, using the ASN.1 Type Name as the sort key.
4.4 Module Header
4.4.1 General
Each item in the Module Header appears on a separate line.
ICS 03.060
Price based on 25 pages
ISO/DISFDIS 20022-8:2025(en)
4.4.2 Module Name
The Module Name is the concatenation of "ISO20022-" and the MessageDefinitionIdentifier property.
The resulting Module Name can require alterations to be legal ASN.1:
a) a) ifIf the first character of the Module Name is not an alphabetic character, then add a prefix of
"U";".
b) b) ifIf the first character is a lower case alphabetic character, then convert it to its equivalent
upper case alphabetic character;.
c) c) anyAny other invalid characters in the name are substituted with hyphens.
NOTE 1 This step is necessary as ASN.1 has tighter requirements for a Module Name than ISO 20022 has for a Message
Definition Identifier.
NOTE 2 If the Module Name ever changes, a) and b) become effective. Until then, they bring no value.
EXAMPLE ISO20022-AccountDetailsConfirmationV02.
4.4.3 Module identification
Each Module is identified by an Object Identifier (OID). The Object IdentifierOID comes from the Message
Definition's OID property.
EXAMPLE AccountDetailsConfirmationV02 {iso(1) standard(0) unifi(20022)
accountDetailsConfirmationV02(12345) }.
4.4.4 Definition of the tagging environment
The tagging environment is defined as "XER INSTRUCTIONS" and "AUTOMATIC TAGS".
4.4.5 Definition of the extensibility environment
Within ASN.1 notation, XSD refers to the XSD Module defined by ISO/IEC 8825-5.
All XSD datatypes used in the MessageSet are Imported from OID {joint-iso-itu-t(2) asn1(1) specification(0)
modules(0) xsd-module(2)}.
The Module for XSD is always generated; the name of the document is always XSDv2.asn.
NOTE The name of the document is the filename for a file system. The Imports for the generated Module include
every type from the XSD Module used.
The Imports include any type XSD type used.
4.5 Granularity of Modules
There is one well-formed and valid ASN.1 Module per MessageDefinition.
NOTE 1 The declaration of which types are protocol data units (PDUs (Protocol Data Units) is not declared in an ASN.1
Module. The generated Module will not indicate which types are PDUs.
NOTE 2 For ISO 20022 any generated ASN.1 Type not referenced by another Type can be considered to be a PDU. This
holds true because this document only generates types referred to directly or indirectly from the Message Definition.
NOTE 3 The PDU is analogous to the XML Schema generation's global root element, derived from
MessageDefinition.rootElement.
4.6 Encoding Messages
ASN.1 is to be added to the Repository as a SyntaxScheme.
Every ISO/IEC 8825 Encoding is to be added to the Repository as an EncodingScheme for the ASN.1 Syntax
Scheme.
The Registration Authority may register additional EncodingSchemes in the Repository for ASN.1 if they can
be completely and precisely described in ECN. The definition in ECN shall be included in the Repository.
An ISO 20022 Valid Message shall conform with a SyntaxScheme and EncodingScheme in the Repository. No
other SyntaxScheme or EncodingSchemes are valid for ISO 20022.
4.7 Completeness
The list of transformation rules described in this clause is complete, which means that no other transformation
rules are applicable. Therefore, no other information may be added to the ASN.1 outside of what is allowed by
these transformation rules.
The Module is a representation of the MessageDefinition.
4.8 Method
4.8.1 General
A MessageSet is composed of a limited number of distinct modelingmodelling patterns (see ISO 20022-1:—
2 1)
, , Figure 7 for a depiction of the Message Metamodel).
By defining the transformation rules from those patterns to ASN.1, any MessageSet and its MessageDefinitions
can be transformed into its corresponding ASN.1 Modules.
4.8.2 Relationship between metamodel concepts and ASN.1 artefacts
4.8.2.1 MessageSet
Each MessageSet is transformed into an artefact of MIME type application/zip containing a file for the
MessageDefinition Module and a single file for the XSD Library Module.
Under preparation. Stage at the time of publication: ISO/DIS 20022-1:2025.
1)
Under preparation. Stage at the time of publication: ISO/DIS 20022-1:2025.
ICS 03.060
Price based on 25 pages
ISO/DISFDIS 20022-8:2025(en)
4.8.2.2 MessageDefinition
The file name for the MessageDefinition Module is the MessageDefinitionIdentifier with an extension of ".asn".
EXAMPLE 1 camt.001.040.01.asn.
If the Message Definition has a value for the Property rootElement, then the MessageDefinition Module
contains a root element named for the value of Property rootElement, and a root type with the same name
suffixed by "-1" which has a sequence comprising the name and type for the MessageDefinition's name.
Otherwise it contains an element and type for the value of the MessageDefinition's name. The type for the
MessageDefinition is transformed into an ASN.1 SEQUENCE whereby the MessageComponent's Name is the
value of the SEQUENCE name.
— — The SEQUENCE includes attributes for minor versioning whose components are:
— — revision "[NAME AS "revision"]" and "[ATTRIBUTE]";
— — variation "[NAME AS "variation"]" and "[ATTRIBUTE]";
— — draft "[NAME AS "draft"]" and "[ATTRIBUTE]".
— — The SEQUENCE preserves the order of the MessageElements. The transformation rules for
MessageElements are given in 5.8.2.6, 5.8.2.8 and 5.8.2.9.0, 4.8.2.8 and 4.8.2.9.
— — Each Component within the SEQUENCE is followed by a comma, except for the last one.
EXAMPLE 2
/* Generated by SWIFTStandards Workstation (build:R5.1.0.4) on 2006 Sep
08 11:58:39 */
Camt-001-040-01
DEFINITIONS XER INSTRUCTIONS AUTOMATIC TAGS ::= BEGIN IMPORTS
String, Decimal, Date, DateTime
FROM XSD;
Camt-001-040-01-OID OBJECT IDENTIFIER ::= {iso(1) registration-authority(1)
unifi(20022) cash-management(0)}
Document ::= [ELEMENT] Document-1 IDENTIFIED BY
{camt-001-040-01-OID abstract-syntax{1})}
Document-1 ::= [NAME AS "Document"] SEQUENCE {
notificationOfInterestV02 [NAME AS " NotificationOfInterestV02"] Camt-001-
040-01 }
4.8.2.3 MessageComponent
A MessageComponent is transformed into an ASN.1 SEQUENCE whereby the MessageComponent's Name is
the value of the SEQUENCE name.
— — The SEQUENCE includes an identifier attribute for internal cross referencing components is:
— — identifier "[NAME AS "id"]" and "[ATTRIBUTE]" of type XSD.Token.
— — The SEQUENCE preserves the order of the MessageElements. The transformation rules for
MessageElements are given in 5.8.2.6, 5.8.2.8 and 5.8.2.9.0, 4.8.2.8 and 4.8.2.9.
— — Each Component within the SEQUENCE is followed by a comma, except for the last one.
EXAMPLE
AccountIdentification3Choice ::= SEQUENCE {
Id [NAME AS CAPITALIZED] String,
postalAddress [NAME AS CAPITALIZED] PostallAddress1 OPTIONAL
}
}
4.8.2.4 ChoiceComponent
A ChoiceComponent is transformed into a SEQUENCE comprising an identifier attribute and a CHOICE.
— — The SEQUENCE includes an identifier attribute for internal cross-referencing components is:
— — identifier "[NAME AS "id"]" and "[ATTRIBUTE]" of type XSD.Token.
Each Alternative within the CHOICE is followed by a comma, except for the last one.
EXAMPLE
PlaceOfTradeIdentification1Choice ::= SEQUENCE {
choice [UNTAGGED] CHOICE {
country [NAME AS CAPITALIZED] CountryCode,
overTheCounter [NAME AS CAPITALIZED] Max35Text
}
}
4.8.2.5 ExternalSchema
ExternalSchema is transformed into a TypeAssignment as follows:
— — ExternalSchema Name is transformed into its Typereference.
— — Type is transformed into "XSD.AnyType".
ICS 03.060
Price based on 25 pages
ISO/DISFDIS 20022-8:2025(en)
EXAMPLE
FIXInstructionType ::= XSD.AnyType.
4.8.2.6 MessageElement
MessageElement in a MessageComponent is transformed into a Component.
MessageElement in a ChoiceComponent is transformed into an Alternative.
MessageElement Name is transformed into the Identifier of the Component or Alternative, whereby the first
character is put in lowercase.
a) If MaximumOccurrence is greater than "1"", then the Component or Alternative Identifier is concatenated
with "-list":
1) followed by "[UNTAGGED] SEQUENCE (SIZE (";
2) followed by the value of MinimumOccurrence if part of a MessageComponent, or "1" if part of a
ChoiceComponent;
3) followed by ".".
b) If MaximumOccurrence contains a number followed by the value of MaximumOccurrence.
c) If MaximumOccurrence contains "UNBOUNDED" then followed by "MAX":
1) followed by ")) OF";
2) followed by the Identifier of the Component or Alternative;
3) followed by the XER encoding instruction "[NAME AS ";
4) followed by the result of the abbreviation algorithm for that MessageElement Name, in quotes;
5) followed by "]";
6) followed by the MessageElement Type Name.
d) If it is part of a MessageComponent or MessageBuildingBlock, and MinimumOccurrence is "0" and
MaximumOccurrence is "1", followed by " OPTIONAL":
1) followed by "(CONSTRAINED BY {/*", followed by "NameAndDefinition ", followed by the
concatenation of MessageElement Name, “.”, “.”, Newline and MessageElement Definition, followed
by the transformation for each Constraint (see 5.8.2.10),4.8.2.10), followed by "*/})".
EXAMPLE
postalAddress [NAME ASpstlAddrss] PostallAddress1 OPTIONAL,
(CONSTRAINED BY {/*"NameAndDefinition PostalAdress.
information that locates and identifies a specific address, as defined by postal services"*/})
4.8.2.7 MessageBuildingBlock
See transformation rules for Clause 5.8.2.6.in 0.
4.8.2.8 MessageAssociationEnd where aggregation is composite
See transformation rules for Clause 5.8.2.6.in 0.
4.8.2.9 MessageAssociationEnd where aggregation is none
The transformation rules for Clause 5.8.2.6in 0 apply, except that the MessageElement Type Name is replaced
by XSD.Token.
4.8.2.10 Constraint
A Constraint is translated into an ASN.1 user defined constraint.
Concatenate "Constraint ", Constraint Name and the Constraint Expression.
EXAMPLE Constraint ValidIBAN. The account shall containcontains a valid IBAN number.
4.8.3 ISO 20022 DataType transformation to ASN.1
4.8.3.1 General
There are two kinds of DataTypes: XSD DataTypes and user-defined DataTypes, each with their own set of
transformation rules.
4.8.3.2 XSD DataTypes
An XSD DataType is found in the metamodel in the package TypeLibrary, subpackage XML_Schema.
Each reference to an XSD DataType is transformed into a reference to its equivalent ASN.1 Type according to
ISO/IEC 8825-5.
EXAMPLE Metamodel::DataTypes::MonthDay is transformed to XSD.GMonthDay.
4.8.3.3 User-defined DataTypes
4.8.3.3.1 General
A user-defined DataType is an instance of a DataType metaclass (as specified in ISO 20022-1) that is not one
of the XSD built-in DataTypes. It is based on an XSD DataType.
4.8.3.3.2 Facets
The XSD facets for each user-defined DataType are expressed as Meta-properties, and the. The actual values
for these facets are provided as properties of the derived DataTypes.
a) a) Each facet is transformed by the rules defined in ISO/IEC 8825-5:2021, Clause 12.
ICS 03.060
Price based on 25 pages
ISO/DISFDIS 20022-8:2025(en)
b) b) Each Type that has an ASN.1 User-defined Constraint shall be structured as follows.:
1) — "(CONSTRAINED BY {/* ".
2) — For the facets that are mapped in ISO/IEC 8825-5:2021, Clause 12 into ASN.1 User-defined
Constraints, the following rule applies:
i) — appendAppend the DataType Property Name, followed by ": " followed by the
DataType Property Value that is prefixed and suffixed by a double quotation mark (this rule is
applied repeatedly for each facet, with the results separated by ", ");").
ii) — appendAppend Newline.
3) — Append "NameAndDefinition", followed by the concatenation of DataType, CodeSet,
IdentifierSet Name or the concept on which the facets are defined, “.”, Newline and MessageElement
Definition, followed by the transformation for each Constraint (see 5.8.2.10)4.8.2.10) ensuring
numbers are preceded and followed by ".
4) — Append " */})".
EXAMPLE
(CONSTRAINED BY {/* fractionDigits: "5", totalDigits: "18" */}).
Table 1 — Permissible DataType facets
minI maxI minE maxE fracti
patte lengt minL maxL total
nclus nclus xclusi clusiv onDig
rn h ength ength Digits
ive ive ve e its
Boolean x
Indicator x
Binary x x x x
String x x x x
Text x x x x
CodeSet x x x x
IdentifierSet x x x x
Decimal x x x x x x x
Rate x x x x x x x
Quantity x x x x x x x
Amount x x x x x x x
Duration x x x x x
DateTime x x x x x
Date x x x x x
Time x x x x x
Year x x x x x
Month x x x x x
Day x x x x x
minI maxI minE maxE fracti
patte lengt minL maxL total
nclus nclus xclusi clusiv onDig
rn h ength ength Digits
ive ive ve e its
YearMonth x x x x x
MonthDay x x x x x
Pointer
4.8.3.3.3 DataType Amount
Amount Name is transformed into the Typereference Name.
Amount is transformed into a new Type that contains an ASN.1 SEQUENCE whereby the Amount's Name is the
value of the SEQUENCE name. Amount's Name is the name of the Identifier. The SEQUENCE contains the
following Components:.:
— — If not empty, Property CurrencyIdentification is the first Component. It has the CurrencyIdentifierSet
as the Identifier and the XER instructions "[NAME AS "Ccy"]" and "[ATTRIBUTE]".
— — The second Component's Name is "base" and has XSD.DECIMAL as the Identifier and the XER
instruction " [UNTAGGED]".
The Properties as defined in Table 10 are transformed according to the facet transformations specified in
4.8.3.3.2.
Properties are only transformed if their value is not empty.
If no Properties are transformed, then append "(CONSTRAINED BY {/*".
Append "NameAndDefinition", followed by the concatenation of MessageElement Name, “.”, Newline and
MessageElement Definition, followed by the transformation for each Constraint (see 4.8.2.10).
If no Properties are transformed, then append "*/})".
EXAMPLE
ActiveCurrencyAndAmount ::= SEQUENCE {
CurrencyIdentification [NAME AS "Ccy"] [ATTRIBUTE]
ActiveCurrencyCodeSet
base [UNTAGGED] XSD.DECIMAL
(CONSTRAINED BY {/* fractionDigits="5.8.3.3.2" totalDigits="18" minInclusive ="0" "
NameAndDefinition ActiveCurrencyAndAmount.
A number of monetary units specified in an active currency where the unit of
currency is explicit and compliant with ISO 4217" */})
}
ICS 03.060
Price based on 25 pages
ISO/DISFDIS 20022-8:2025(en)
4.8.3.3.4 DataType Quantity
Quantity is transformed into a new Type.
Quantity::name is used as the Typereference Name.
The Type is a subtype of XSD.Decimal.
The Properties as defined in 0 are transformed according to the facet transformations specified in 4.8.3.3.2.
Properties are only transformed if their value is not empty.
If no Properties are transformed, then append "(CONSTRAINED BY {/*".
Append "NameAndDefinition", followed by the concatenation of MessageElement Name, “.”, Newline and
MessageElement Definition, followed by the transformation for each Constraint (see 5.8.2.10).4.8.2.10).
If no Properties are transformed, then append "*/})".
EXAMPLE
ActiveCurrencyAndAmount ::= SEQUENCE {
CurrencyIdentification [NAME AS "Ccy"] [ATTRIBUTE] ActiveCurrencyCodeSet
base [UNTAGGED] XSD.DECIMAL
(CONSTRAINED BY {/* fractionDigits="5" totalDigits="18" minInclusive ="0"
" NameAndDefinition ActiveCurrencyAndAmount.
A number of monetary units specified in an active currency where the unit of
currency is explicit and compliant with ISO 4217" */})
}
4.8.3.3.41.1.1.1.1 DataType Quantity
Quantity is transformed into a new Type.
Quantity::name is used as the Typereference Name.
The Type is a subtype of XSD.Decimal.
The Properties as defined in Table 1 are transformed according to the facet transformations specified in
5.8.3.3.2.
Properties are only transformed if their value is not empty.
If no Properties are transformed, then append "(CONSTRAINED BY {/*".
Append "NameAndDefinition", followed by the concatenation of MessageElement Name, “.”, Newline and
MessageElement Definition, followed by the transformation for each Constraint (see 5.8.2.10).
If no Properties are transformed, then append "*/})".
EXAMPLE
DecimalNumber::= XSD.Decimal (CONSTRAINED BY {/* fractionDigits="17" totalDigits="17" "
NameAndDefinition DecimalNumber.
Number of objects represented as decimal number, e.g. 0,75 or 45,6"*/}).
Number of objects represented as decimal number, e.g. 0,75 or 45,6"*/}).
4.8.3.3.5 DataType CodeSet
CodeSet is transformed into an ENUMERATED Type.
CodeSet::name is used as the Typereference Name.
The Properties as defined in Table 10 are transformed according to the facet transformations specified in
5.8.3.3.2.4.8.3.3.2.
Properties are only transformed if their value is not empty.
If no Properties are transformed, then append "(CONSTRAINED BY {/*".
Append "NameAndDefinition", followed by the concatenation of MessageElement Name, “.”, Newline and
MessageElement Definition, followed by the transformation for each Constraint (see 4.8.2.10).
If no Properties are transformed, then append "*/})".
EXAMPLE
Properties are only transformed if their value is not empty.
If no Properties are transformed, then append "(CONSTRAINED BY {/*".
Append "NameAndDefinition", followed by the concatenation of MessageElement Name, “.”, Newline and
MessageElement Definition, followed by the transformation for each Constraint (see 5.8.2.10).
If no Properties are transformed, then append "*/})".
EXAMPLE
DeliveryReceiptType2CodeSet ::= ENUMERATED {FREE, APMT} (CONSTRAINED BY {/*" NameAndDefinition
DeliveryReceiptType2CodeSet.
Specifies how the transaction is to be settled"*/}).
Specifies how the transaction is to be settled"*/}).
4.8.3.3.6 DataType IdentifierSet
IdentifierSet is transformed into a new Type.
IdentifierSet::name is used as the Typereference Name.
The Type is a subtype of XSD.String.
ICS 03.060
Price based on 25 pages
ISO/DISFDIS 20022-8:2025(en)
The Properties as defined in Table 10 are transformed according to the facet transformations specified in
5.8.3.3.2.4.8.3.3.2.
Properties are only transformed if their value is not empty.
If no Properties are transformed, then append "(CONSTRAINED BY {/*".
Append "NameAndDefinition", followed by the concatenation of MessageElement Name, “.”, Newline and
MessageElement Definition, followed by the transformation for each Constraint (see 4.8.2.10).
If no Properties are transformed, then append "*/})".
EXAMPLE
Properties are only transformed if their value is not empty.
If no Properties are transformed, then append "(CONSTRAINED BY {/*".
Append "NameAndDefinition", followed by the concatenation of MessageElement Name, “.”, Newline and
MessageElement Definition, followed by the transformation for each Constraint (see 5.8.2.10).
If no Properties are transformed, then append "*/})".
EXAMPLE
CUSIPIdentifierSet::= XSD.String (CONSTRAINED BY {/*" NameAndDefinition
CUSIPIdentifierSet.
Committee on Uniform Securities and Identification Procedures (CUSIP). The standards body that
created and maintains the securities classification system in the US. Non-US securities have a
similar number called the CINS number"*/})
4.8.3.3.7 DataType Rate
Rate is transformed into a new Type.
Rate::name is used as the Typereference Name.
The Type is a subtype of XSD.Decimal.
The Properties as defined in Table 10 are transformed according to the facet transformations specified in
5.8.3.3.2.4.8.3.3.2.
Properties are only transformed if their value is not empty.
If no Properties are transformed, then append "(CONSTRAINED BY {/*".
Append "NameAndDefinition", followed by the concatenation of MessageElement Name, “.”, Newline and
MessageElement Definition, followed by the transformation for each Constraint (see 4.8.2.10).
If no Properties are transformed, then append "*/})".
EXAMPLE
Properties are only transformed if their value is not empty.
If no Properties are transformed, then append "(CONSTRAINED BY {/*".
Append "NameAndDefinition", followed by the concatenation of MessageElement Name, “.”, Newline and
MessageElement Definition, followed by the transformation for each Constraint (see 5.8.2.10).
If no Properties are transformed, then append "*/})".
EXAMPLE
PercentageRate::= XSD.Decimal (CONSTRAINED BY {/* fractionDigits="10"
totalDigits="11" " NameAndDefinition PercentageRate.
Rate expressed as a percentage, i.e. in hundredths, e.g. 0,7 is 7/10 of a percent, and 7,0 is
7 %"*/}).
4.8.3.3.8 DataType Indicator
Indicator is transformed into a new Type.
Indicator::name is used as the Typereference Name.
The Type is a subtype of XSD.Boolean.
The Properties as defined in Table 10 are transformed according to the facet transformations specified in
5.8.3.3.2.4.8.3.3.2.
Properties are only transformed if their value is not empty.
If no Properties are transformed, then append "(CONSTRAINED BY {/*".
Append "NameAndDefinition", followed by the concatenation of MessageElement Name, “.”, Newline and
MessageElement Definition, followed by the transformation for each Constraint (see 4.8.2.10).
If no Properties are transformed, then append "*/})".
EXAMPLE
Properties are only transformed if their value is not empty.
If no Properties are transformed, then append "(CONSTRAINED BY {/*".
Append "NameAndDefinition", followed by the concatenation of MessageElement Name, “.”, Newline and
MessageElement Definition, followed by the transformation for each Constraint (see 5.8.2.10).
If no Properties are transformed, then append "*/})".
EXAMPLE
ICS 03.060
Price based on 25 pages
ISO/DISFDIS 20022-8:2025(en)
YesNoIndicator::= XSD.Boolean (CONSTRAINED BY {/*" NameAndDefinition
YesNoIndicator.
Indicates a "yes" or "no" type of answer for an element"*/}).
4.8.3.3.9 DataType Text
Text is transformed into a new Type.
T
...














Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...