ISO 20022-8:2026

Financial services — Universal financial industry message scheme — Part 8: ASN.1 generation

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 Encoding Control Notation (ECN).

Services financiers — Schéma universel de messages pour l'industrie financière — Partie 8: Génération ASN.1

General Information

• Status: Published
• Publication Date: 12-Apr-2026
• ICS: 03.060 - Finances. Banking. Monetary systems. Insurance
• 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: 6060 - International Standard published
• Start Date: 13-Apr-2026
• Due Date: 23-Dec-2025
• Completion Date: 13-Apr-2026

Relations

• Revises: ISO 20022-8:2013 - Financial services — Universal financial industry message scheme — Part 8: ASN.1 generation
• 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.

Standards Content (Sample)

International
Standard
ISO 20022-8
Second edition
Financial services — Universal
2026-04
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
Reference number
© ISO 2026
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’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
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
[25]
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
International Standard ISO 20022-8:2026(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 Encoding Control Notation (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:2026.
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
A MessageSet is composed of a limited number of distinct modelling patterns (see ISO 20022-1:2026, 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})}

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 specific address, as defined by postal services"*/})

4.8.2.7 MessageBuildingBlock
See transformation rules in 4.8.2.6.
4.8.2.8 MessageAssociationEnd where aggregation is composite
See transformation rules in 4.8.2.6.
4.8.2.9 MessageAssociationEnd where aggregation is none
The transformation rules in 4.8.2.6 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 contains a valid IBAN number.

4.8.3 ISO 20022 DataType transformation to ASN.1
4.8.3.1 General
There are
...