Standards MX

General Information

This document describes the Swift Standards MX messages (MXs) and explains the concept of XML for MX messages
and the structure and function of these messages. This document is for customers that use MXs, and software
developers that implement Swift Solutions that use MXs.

15 February 2024

Link to this document: https://www2.swift.com/go/book/bookext049687

Standards MX Table of Contents
General Information

Table of Contents

Preface............................................................................................................................................................... 4

1 Definitions................................................................................................................................................ 5

2 Standards MX Message Concepts......................................................................................................... 8

2.1 Message Definition.................................................................................................................................. 8
2.2 Message Classification and Naming......................................................................................................10
2.3 Message Versions and Maintenance.....................................................................................................19
2.4 ISO 20022 Financial Repository............................................................................................................20

3 XML for Standards MX Messages........................................................................................................ 22

3.1 Introduction to XML................................................................................................................................22
3.2 XML Schemas and Instances................................................................................................................22
3.3 XML Syntax........................................................................................................................................... 24
3.4 XML Document Validation..................................................................................................................... 33
3.5 Swift Standards Supported Character Sets and Encoding Scheme......................................................37
3.6 xs:any.................................................................................................................................................... 41

4 MX Messages and InterAct................................................................................................................... 44

4.1 MX Message Structure.......................................................................................................................... 44
4.2 Message Blocks.....................................................................................................................................45
4.3 Business Usage Definition.....................................................................................................................56
4.4 MX Message..........................................................................................................................................57
4.5 MX Message Identification.....................................................................................................................59

5 MX Messages and FileAct.....................................................................................................................61

5.1 File Structure......................................................................................................................................... 61
5.2 File Header............................................................................................................................................ 61

6 Understanding the Documentation......................................................................................................66

6.1 Standards MX Message Definition Report Part 1.................................................................................. 66
6.2 Standards MX Message Definition Report Part 2.................................................................................. 67
6.3 Messages.............................................................................................................................................. 67
6.4 Message Item Types..............................................................................................................................70

7 The Financial Glossary......................................................................................................................... 71

15 February 2024 2
Standards MX Table of Contents
General Information

Legal Notices................................................................................................................................................... 72

15 February 2024 3
Standards MX Preface
General Information

Preface
About this document
This guide provides a general description of Standards MX (MXs) concepts, as follows:
• Standards MX Message Concepts on page 8 describes general concepts which include
message frameworks, message granularity, message variants and versions, message
classification, message naming, and definitions.
• XML for Standards MX Messages on page 22 describes how MXs use XML. This section
includes information about XML schemas, instances, and syntax, discusses tags and elements,
and describes XML document standards, supported characters, validation, and namespaces.
• MX Messages and InterAct on page 44 describes the structure of an InterAct message and
describes how to use the application header.
• MX Messages and FileAct on page 61 describes the structure of a FileAct message and
describes how to use the file header.
• Understanding the Documentation on page 66 describes how to use the Standards MX
documentation.
For the latest available version of this guide, see Knowledge Centre (User Handbook) .
Audience
Customers that use MXs, and software developers that implement Swift Solutions that use MXs,
are the intended audience for this document.

Reading conventions
This guide contains some terms that are abbreviated as follows:
• Swift Standards XML message is abbreviated to MX
• Swift Standards FIN message, Message Type, is abbreviated to MT

Significant changes
The following table lists the significant changes to the content of the Standards MX General
Information since the previous edition.

New and updated information Location

Update to section "Use of normalised characters" Swift Standards MX-Supported Character Sets on
page 37

Related documentation
• Standards MX Message Definition Reports
• Standards MX Technical Definition Reports
• SwiftNet Service Description
• SwiftNet Messaging Operations Guide
• MyStandards Service Description
• MyStandards User Guide

15 February 2024 4
Standards MX Definitions
General Information

1 Definitions
Application The application header and business document altogether form the business
header message (the payload). The application header always comes first in position. It
has its own message definition.
It gathers together, in one place, data about the message, such as which
organisation has sent the business message, which organisation should be
receiving it, the identity of the message itself, a reference for the message and so
on. It contains more information about the content of the business document than
the technical (network) header. In fact, the former describes the content of the
business document to the receiving business application, whereas the latter
describes the information relevant to SwiftNet for its own internal operations. The
purpose of the application header is to provide a consistent and predictable way
for this data to be conveyed with the message, regardless of implementation
factors such as the choice of network. This does not prevent such data being
conveyed either within the message definition itself, or as part of a network
header. It typically helps to facilitate message routing and/or processing by
intermediate parties in a chain and/or by middleware messaging components,
without the need to scan through the full business document details.

Business The application header developed by the ISO 20022 community.

application
The BAH has its own ISO 20022 message identifier (for example, head.
header (BAH)
001.001.02). Accordingly, it follows similar registration, publication and
maintenance processes versus other ISO 20022 message definitions. Fore more
information about the latest BAH specifications, see iso20022.org.

Cross- Rules between two or more different message elements that can be validated.
element rules Rules that are injected and therefore validated on the Swift Network are in the MX
documentation indicated with a tick symbol (✓) or marked as SwiftNet validation
true on MyStandards.

External code Codes that are not included in the message definition and that can be used in
sets specific elements of the messages. The purpose of externalising these codes is
to be able to update the code sets (for example, add new codes) without
impacting the messages themselves and, hence, without requiring the
development of a new version of the messages that use these code sets.
The official list of external codes is maintained by ISO and published at https://
www.iso20022.org/catalogue-messages/additional-content-messages/external-
code-sets. This list is updated by ISO on a quarterly basis.

Guidelines Guidelines are recommendations given in addition to (textual) rules, but cannot
be validated.

Message The message definition is the message format fully represented by two
definition categories of rules:
• Syntax rules (also called schema rules since always technically represented
by an XML schema): defines the message structure and nesting, including
amongst others the element names and data types, their allowed presence
and character set.

15 February 2024 5
Standards MX Definitions
General Information

• Semantic rules (also called non-schema rules): cross-element rules (for

example, “if element A equals X, element B must equal Y”) as well as
algorithmic rules necessary to describe more complex reference data formats.
A message definition can have usage guidelines. Usage guidelines further add
additional syntax or cross-element restrictions that must not violate the message
definition rules (for example, make an optional element mandatory). The term
message is often used to designate both the message format and the message
instance.
Also called base messages.
The application header, business message and supplementary data extension
have each their own message definition.

Message Instance of a message definition, containing a set of structured information

instance exchanged between parties in the scope of a business transaction. A message
instance is expected to be valid against the related message definition.

Message SwiftNet’s central validation feature. A SwiftNet service administrator can

validation optionally set this feature when defining a Closed User Group. See the SwiftNet
(MVAL) Service Description for more information. Payload content is validated only when
MVAL is activated at the level of the service.

Message An ISO 20022-standardised restriction of an ISO 20022-standard base message

variant definition with a unique MessageDefinitionIdentifier. For example, a variant may
exclude the portions of the global message definition that are rarely used in order
to provide a message definition that is easier to implement and still covers 80% of
the cases. The message definition identifier includes a 3-digit variant number,
which is set to 001 to identify the global message definition and offers the
possibility to identify up to 998 message variants. This explicit identification of
variants allows the easier routing, validation and processing of the instances
using, for example, the variant schemas.
Variants do not replace usage guidelines that describe the specific way of using a
message in a particular context or by a specific community of users.

MX message The XML business usage definition for use in the SwiftNet service (that is, the full
combination of application header, business document and supplemental data
extension message definitions, as well as associated usage guideline restrictions
if any). It can be:
• a base (candidate or registered) ISO 20022 message
• a proprietary message

MX message Instance of an XML message definition used inside an InterAct message.

instance

Payload Also referred to SwiftNet Payload or business message.

The actual data to be transferred in an InterAct message.

15 February 2024 6
Standards MX Definitions
General Information

Schema Technical description of an XML message definition, not taking into account
cross-element rule validation and reference data validation (such as for example
BIC, IBAN, country codes). A schema defines the message structure and nesting,
including amongst others the element names and data types, their allowed
presence and character set.

Textual rules Rules between two or more different message elements that cannot be validated.

Usage A description of how message definitions should be used in certain specific

guidelines business contexts. This notion covers a variety of terms recognised in the
industry: market practice, implementation guideline, formatting rule,
recommendation, functional specification, or template. It complements the base
message definition with additional syntactic and/or semantic restrictions that
cannot violate the base message rules (for example, make an optional element
mandatory). Swift and its customers used MyStandards to publish usage
guidelines. Usage guidelines can also be implemented and validated on MVAL.

Usage Provides a unique identification of the usage guideline when coupled together
identifier with a message definition identifier.
It can be used to unambiguously identify:
• a business usage definition (in which case it designates a usage guideline
covering the full payload)
• a usage guideline set on a (business) application header, business document
or supplementary data extension
The primary purpose of the usage identifier is to provide a practical means of
identifying a particular business usage definition exchanged over the network (for
example, distinguish STP, core versions, Market Infrastructure-specific flavour of
a pacs.008.nnn.nn message instance).
Currently implemented as an editable meta information of a usage guideline
specification in MyStandards, the concept is open: a financial institution is free to
define and publish a usage identifier by its own means.
To ensure uniqueness, the usage identifier is subject to a certain structure
registration process. In particular, it must:
• start with a short name identifier of the usage guideline publishing
organisation, for example, swift
• followed by 1 or more context distinguishers, for example, cbprplus
separated by a dot
• and end with a 2-digit version number, for example, 01
The version must be fixed / increments whenever the usage guideline becomes
effective and evolves on a network. For example, swift.cbprplus.01 used to
designate CBPR+ market practice flavours of the pacs. and camt. messages
exchanged over FINplus.

15 February 2024 7
Standards MX Standards MX Message Concepts
General Information

2 Standards MX Message Concepts

The term message in this section refers to a message definition, that is an application header, the
business document or a supplemental data extension, see Definitions on page 5.

2.1 Message Definition

2.1.1 Message Structure

Structure of a message
A business message definition represents the formal description of the MX structure. The structure
is composed of application header and business document message definitions, each composed of
message components, choice components, and message elements. Each MX has a unique
identifier in the Swift Standards domain. Optionally, the business document may include
supplemental data message definitions.

Example StatementOfAccount message structure

SWIFTNet Payload

Application Header

Document technical
element
Message StatementOfAccount
StatementHeader Date: Page:

Message AccountIdentification Bank Identifier: datatype

item
Bank Account Number:

Message
StatementIdentification Statement Number:
component message
Date: element

Payment Type
(a "choice" between ...)
Choice Cheque / Cash/ Credit Card
component

Card Id / Transaction Id

Transaction Details
Value
Date Amount D/C
D0960008

The StatementOfAccount message example shows the message structure.

15 February 2024 8
Standards MX Standards MX Message Concepts
General Information

Message components
Definition Function

Message item Messages are composed of message items. A message item can be either a
message building block at the first level of a message or a message element. A
message item can appear at any level of nesting in the message definition. The
XML schema of the message defines the message items. Message items appear
as XML tags in the message instance.

Message component Reusable item that is used for assembling a message. Message components
contain specific message elements that are normally linked to a business
component. The financial dictionary contains a complete list of message
components.

Message building block Message item that is specific to a particular message and not defined in the
financial dictionary. A message building block is defined in the XML schema as an
immediate child of a message.

Choice component Represents a choice between several possibilities. An instance of a message can
only contain one of the possibilities.

Message element Characteristic of a message component. Each message element is uniquely

identified in its message component and linked to a business element. Either a
Swift Standards-defined data type or a message component types a message
element.

Technical element Message element that only has a function in the context of a message. It can have
a data type but is not related to a business element.

Data type Specifies the values of a business element or a message element.

Data type representation Group of similar data types.

Related information
XML Schema on page 22

2.1.2 Message Component Reusability

Links between message components and business components
There is a link between the various message components and the underlying business
components and elements. This link promotes the reuse of components and enable customers to
assess the impact of updates and changes to messages. Business concepts are defined by means
of reusable business components.

15 February 2024 9
Standards MX Standards MX Message Concepts
General Information

Example of a message component derived from a reusable business component

This example shows that the message component Account1 is derived from the generic reusable
business component Account. Account1 contains a subset (Identification and Account Service) of
the four elements that characterise an Account.

Account

Business Component Identification

Name
Status
Account Servicer

D0960013
Account 1

Message Component
Identification
Account Servicer
D0690014

Related information
ISO 20022 Financial Repository on page 20

2.2 Message Classification and Naming

Each message definition has a message name and a message identifier. The message name is
human-readable. The message identifier is a unique structured computer-readable identifier for use
by systems and applications.
A message name and its identifier must be considered in the context of its business area.
Related information
Business Area on page 10
Message Identifier on page 18

2.2.1 Business Area

Definition of a business area
A business area is the business domain in which an MX is exchanged. A business area is
composed of a set of strongly related activities, for example, payments clearing and settlement, or
securities settlement. Each message is associated with a business area. It is important that
customers identify any messages that belong to the same message area when they develop new
applications. This is because the message area can be used to route messages.

15 February 2024 10
Standards MX Standards MX Message Concepts
General Information

2.2.2 Business Area Codes

The following table lists business areas that cover the FIN domains, the related codes, and the
existing Swift Standards MX messages. The FIN MTs are examples only, to clarify the business
area. The examples are not exhaustive, and there is no intention to imply that there are current
plans to create equivalent messages in XML. The development of new XML messages in a
particular business area requires the approval of the Swift Board of Directors.
For further information about ISO 20022 business areas, see ISO 20022 Business Areas.
Payments and Cash Management: cash

Examples of MTs
Business
Business area Description in specified
area code
business area

Messages that support the reporting and 210, 400, 900,

advising of the cash side of any financial 910, 920, 935,
transactions, including cash movements, 940-2, 950, 97n,
camt Cash Management
transactions and balances, plus any 990-2, 995-6,
exceptions and investigations related to 190-2, 195-6,
cash transactions. 290-2, 295-6

Messages that support the clearing and

Payments Clearing and 102-4, 107, 200-5,
pacs settlement processes for payment
Settlement 400
transactions between financial institutions.

Messages that support the initiation of a

payment from the ordering customer to a
pain Payments Initiation 101, 104(RFDD)
financial institution that services a cash
account and reporting its status.

remt Payments Remittance Messages that support communication

Advice between creditors and debtors regarding
remittance details associated with
payments.

Trade Services: trad

Examples of MTs
Business
Business area Description in specified
area code
business area

Messages that support the request for a

trade service, including any related
tsin Trade Services Initiation
application, instruction, request,
acknowledgement, or advice.

Messages that support ancillary

commercial trade services functions,
420, 422, 490-2,
including checking, matching and
tsmt Trade Services Management 495-6, 750, 769,
reporting, plus any exceptions and
790-2, 795-6
investigations related to trade services
transactions.

15 February 2024 11
Standards MX Standards MX Message Concepts
General Information

Examples of MTs
Business
Business area Description in specified
area code
business area

Messages that support the issuance of a 410, 412, 416,

trade services instrument, execution 430, 700, 701,
and/or settlement of a trade transaction, 705, 707, 710,
including any related reimbursement, 711, 720, 721,
tsrv Trade Services
acceptance, authorisation, claims, 730, 732, 734,
enquiries, invoicing, financing, or other 740, 742, 747,
undertaking. 752, 754, 756,
760, 767, 768

Securities: secs

Examples of MTs
Business
Business area Description in specified
area code
business area

Messages that support collateral 503-7, 527, 558,

colr Collateral
management actions. 569, 581

Messages that support the clearing

process for securities, including
management of post-trading, pre-
secl Securities Clearing 516, 526
settlement credit exposure, netting,
margining, borrowing, conformance with
market settlement rules.

Messages that support asset servicing,

seev Securities Events including proxy voting, income and 564-8
corporate actions

Messages that support the process of

seis Securities Issuance
issuing (issuance/creation) securities.

Messages that support post-settlement

processes for securities (including
reporting on securities movements, trades, 508, 524, 535-8,
and balances), the processes required to 575, 549, 500-1,
semt Securities Management
protect beneficial owner's rights throughout 510, 519, 586,
settlement, plus any exceptions and 590-2, 595-6
investigations related to securities
transactions.

Messages that support the settlement

sese Securities Settlement process for securities and report its status 530, 540-9, 578
and confirmation.

Messages that support the process of

trade initiation, including indication of
seti Securities Trade Initiation
interest in buying or selling a security and
the related quoting process.

15 February 2024 12
Standards MX Standards MX Message Concepts
General Information

Examples of MTs
Business
Business area Description in specified
area code
business area

Messages that support trade and post-

trade processes for securities, including
502, 509, 513-5,
setr Securities Trade order to buy or sell, trade execution,
517-8, 576
affirmation, confirmation, allocation, and
notification.

Foreign Exchange: forx

Examples of MTs
Business
Business area Description in specified
area code
business area

Messages that support management

processes for foreign-exchange contracts,
Foreign Exchange including reporting on trades and
fxmt 390-2, 395-6
Management balances, plus any exceptions and
investigations related to foreign-exchange
contracts.

Messages that support the process of

trade initiation, including indication of
Foreign Exchange Trade
fxti interest in buying or selling a foreign-
Initiation
exchange contract and the related quoting
process.

Messages that support trade and post-

trade processes for foreign-exchange
fxtr Foreign Exchange Trade contracts, including order to buy or sell, 300, 304, 380-1
execution, affirmation, confirmation,
allocation, and notification.

Bank Loan/Deposit: bklo

Examples of MTs
Business
Business area Description in specified
area code
business area

Messages that support management

processes for bank loans and deposits,
including reporting on trades and
blmt Bank Loan Management 390-2, 395-6
balances, plus any exceptions and
investigations related to bank loans and
deposits.

Messages that support the process of

trade initiation, including indication of
blti Bank Loan Trade Initiation
interest in buying or selling a bank loan or
deposit and the related quoting process.

15 February 2024 13
Standards MX Standards MX Message Concepts
General Information

Examples of MTs
Business
Business area Description in specified
area code
business area

Messages that support trade and post-

trade processes for bank loans and
bltr Bank Loan Trade deposits, including order to buy or sell, 320-1, 330, 350
execution, affirmation, confirmation,
allocation, and notification.

Derivatives: deri

Examples of MTs
Business
Business area Description in specified
area code
business area

Messages that support management

processes for derivative contracts,
including reporting on trades and
demt Derivatives Management 390-2, 395-6
balances, plus any exceptions and
investigations related to derivative
contracts.

Messages that support the process of

trade initiation, including indication of
deti Derivatives Trade Initiation
interest in buying or selling a derivative
contract and the related quoting process.

Messages that support trade and post-

trade processes for derivative contracts,
305-6, 340-1,
detr Derivatives Trade including order to buy or sell, trade
360-2, 364-5
execution, affirmation, confirmation,
allocation, and notification.

Commodities: comm

Examples of MTs
Business
Business area Description in specified
area code
business area

Messages that support management

processes for commodities, including
604-8, 690-2,
comt Commodities Management reporting on trades and balances, plus any
695-6
exceptions and investigations related to
commodities.

Messages that support the process of

trade initiation, including indication of
coti Commodities Trade Initiation
interest in buying or selling a commodity
and the related quoting process.

Messages that support trade and post-

trade processes for commodities, including
cotr Commodities Trade 600-1, 620
order to buy or sell, execution, affirmation,
confirmation, allocation, and notification.

15 February 2024 14
Standards MX Standards MX Message Concepts
General Information

Syndicated Loans: sylo

Examples of MTs
Business
Business area Description in specified
area code
business area

Messages that support the process of

initiation, including indication of interest in
syin Syndicated Loan Initiation
buying or selling a syndicated loan and the
related quoting process.

Messages that support management

processes for syndicated loans, including
Syndicated Loan notices between the agent bank and
symt 690-2, 695-6
Management lenders to manage drawdowns, rate set,
and interest and fee payments related to
syndicated loans.

Messages that support post-trade

processes for syndicated loans, including
synd Syndicated Loan
execution, affirmation, confirmation,
allocation, and notification.

Card Payments: card

Examples of MTs
Business
Business area Description in specified
area code
business area

Messages that support any card payment-

related transactions and services between
Acceptor to Acquirer Card a card acceptor and a card transaction
caaa
Transactions acquirer. It includes the authorisation, the
cancellation, and the capture of card
transactions.

Messages that support any card-related

caad Card Administration administrative services between financial
institutions and their agents.

Messages that support card-related

terminal management services between an
caam ATM Management
Automated Teller Machine (ATM) and an
acquirer.

Messages that support the reporting and

advising of card payment transactions,
cafc Fee Collection
including the collection of fees and the
processing of charge-backs.

Messages that support file management

services in a card payment environment
cafm File Management
between financial institutions and/or their
agents.

15 February 2024 15
Standards MX Standards MX Message Concepts
General Information

Examples of MTs
Business
Business area Description in specified
area code
business area

Messages that support card payment-

Fraud Reporting and related fraud reporting and disposition
cafr
Disposition services between financial institutions and
their agents.

Messages that support any card payment-

related transactions and services between
Acquirer to Issuer Card a card transaction acquirer and a card
cain
Transactions issuer. It includes the authorisation,
reversal, and financial presentment of card
transactions.

Messages that support network

management services in a card payment
canm Network Management
environment between financial institutions
and/or their agents.

Messages that support any card-related

Sale to POI Card transactions and services between a sale
casp
Transactions system and a Point of Interaction (POI)
system.

Messages that support card payment-

related settlement reporting services
casr Settlement Reporting
between financial institutions and their
agents.

Messages that support card-related

terminal management services between a
catm POI Management
Terminal Management System (TMS) and
a Point of Interaction (POI).

Messages that support any card-related

Automated Teller Machine (ATM)
transactions and services between an ATM
catp ATM Card Transactions equipment and an ATM acquirer. These
services include cash withdrawals, kiosk
functions and card account management
transactions.

Messages that support card payment

Payment Token tokenisation management and
tokm
Management administrative services between a Token
Service Provider and a Token Requestor.

15 February 2024 16
Standards MX Standards MX Message Concepts
General Information

Miscellaneous/Other/Generic: misc

Examples of MTs
Business
Business area Description in specified
area code
business area

Messages that support the management of

account related activities, such as the
acmt Account Management
opening and the maintenance of an
account.

Generic messages (for example, system

admi Administration
event notifications and generic rejections)

Messages that support the provision of

miscellaneous financial information to
auth Authorities authorities (for example, regulators, police,
customs, tax authorities, enforcement
authorities, ministries).

Messages that support the communication

of reference data related to financial
reda Reference Data instruments, parties, accounts, prices, and
other business information required to
support financial activities.

trck Tracking Messages that support the communication 199, 299

of transaction information to a Tracking
Facility allowing such transaction to be
tracked and its information to be shared
with other relevant parties involved in the
business transaction.

Others (non-ISO)

Examples of MTs
Business
Business area Description in specified
area code
business area

(derivatives fpml on Swift) Used for fpml messages n the Swift

defp
network

Market Infrastructure Messages specifically used by Swift’s

mirs
Resiliency Service (MIRS) MIRS service.

Used for SEDA (SEPA-compliant

Electronic Database Alignment)
prev messages. The Italian Banking Association
might submit the business area code and
messages to ISO for approval.

Message received by third party in case of (similar to FIN

xcop Partial copied message
SwiftNet InterAct partial copy 096)

Swift system messages for Relationship Management Application

xrma
RMA system messages.

15 February 2024 17
Standards MX Standards MX Message Concepts
General Information

Examples of MTs
Business
Business area Description in specified
area code
business area

System messages for use on the Swift (similar to FIN

xsys Swift system messages
network. system messages)

Data (for example, reports) sent from

xoom Swift-to-user traffic
SwiftNet Online Operations Manager.

Obsolete - to be withdrawn (non-ISO)

Examples of MTs
Business
Business area Description in specified
area code
business area

To be replaced by Foreign Exchange and

trea (treasury)
Bank Loan/Deposit business domains.

2.2.3 Message Name

Structure of a message name
The structure of the message name is as follows.

Structure Definition

Message Definition Specifies the function of the message in the business area.

Version The version number is identified explicitly in the message name.

Example message name structure

Structure Example

Message Definition + Version Identifier BulkCreditTransferV01

2.2.4 Message Identifier

Structure of a message identifier
A message identifier is a unique identification of a message definition within the ISO 20022
namespace, identifying the business area to which the message definition belongs, the message
functionality it covers, its variant and its version. The message identifier is always embedded within
the namespace declaration of the XML schema it relates to. For example, the namespace for the
pacs.008.001.10 message is urn:iso:std:iso:20022:tech:xsd:pacs.008.001.10.

The term message inside message identifier must not be confused with the message transmitted
over the network. The latter typically may contain more than 1 message definition(s), for example,
the BAH, the business document, and possibly supplementary data extension(s), further
complemented with network-proprietary headers and/or trailers

15 February 2024 18
Standards MX Standards MX Message Concepts
General Information

Format Function

MX Stands for XML message type.

MX is omitted when the message identifier is used in applications or in the SwiftNet Request
Header.

4!a Mandatory code that identifies the business area. For example, pacs stands for Payments
Clearing and Settlement.
This code has a fixed length of 4 alphabetic characters. See Business Area Codes on page 11.

3!c Mandatory element that identifies the message number.

This element has a fixed length of 3 alphanumeric characters.

3!n Mandatory element that identifies a variant.

This element has a fixed length of 3 numeric characters.

2!n Mandatory element that identifies the version number.

The version number is always incremented starting from version 01.
This element has a fixed length of 2 numeric characters.

Example message identifier structure

Structure Examples

[MX] 4!a.3!c.3!n.2!n pacs.001.001.01

head.001.001.02
supl.001.001.01

2.3 Message Versions and Maintenance

2.3.1 Message Versions

Definition of message versions
The latest version of (ISO 20022) message definitions can be updated on a yearly basis provided
changes are requested by the users and approved through the maintenance process. A new
message version can be created when users have a need to include new business or technical
requirements in an existing message definition..
A new version of a message definition has a version number that is part of the MX name and an
identifier increment. Swift supports coexistence of two versions of the same message for a limited
time. At an agreed date, Swift no longer supports the older version of the message. Some Swift
solutions may only support one version of a message in the Live environment.
Note The difference between message variants and message versions is that message
variants exist concurrently and independently of one another. Message versions
enable customers to switch from one use for a message to another use of the
message to accommodate a change in business requirements.

15 February 2024 19
Standards MX Standards MX Message Concepts
General Information

Example of message versions

When it is mandatory to include the IBAN in the message, a new version of the message is
created.

2.3.2 Maintenance Process

MX maintenance
The Standards MX Development and Maintenance Process document describes the creation and
maintenance process used by the Swift Standards Department to create and maintain MX
message standards.

ISO 20022 maintenance

In most of the cases when there is a maintenance to an ISO 20022 message, Swift follows the ISO
maintenance process.

Related information
For more information about the ISO 20022 maintenance process, see
iso20022.org > Registration Process

2.4 ISO 20022 Financial Repository

The items in the ISO 20022 Financial Repository can be classified in the following three categories:
business concepts, data types, and message concepts.

15 February 2024 20
Standards MX Standards MX Message Concepts
General Information

The following diagram shows the conceptual structure of the ISO 20022 Financial Repository. This
diagram shows all the types of dictionary items and the relationships between them.

The ISO 20022 Financial Repository

Financial Dictionary

Business concepts Data types Message concepts

Business association

relates

is based on Message components

Business component

Business element is based on Message element

Rule Code Rule

is value of is of type
is of type
Business actor Data type
plays role is based on

Business role
Data type representation

D0960010
Business concept Dictionary item with a business The following items are part of this category:
semantic meaning business associations, business components,
rules, business elements, and business actors/
roles.

Data type Dictionary item that Data types are grouped into representation
unambiguously specifies a set of classes by characteristics that are common to a
values for a business element or a number of data types.
message element

Message concept Dictionary item used for message The following items are part of this category:
definitions message components, rules, and message
elements.

Related information
For more information about international financial message standards, see
www.iso20022.org
.

15 February 2024 21
Standards MX XML for Standards MX Messages
General Information

3 XML for Standards MX Messages

3.1 Introduction to XML

Swift uses eXtensible Markup Language (XML) to represent its Standards MX messages (MXs).
XML is a standard of the World Wide Web Consortium (W3C). XML is a formal, machine-
processable language understood by computers. XML facilitates data exchange by ensuring that
data is defined clearly and interpreted in the same way by both the sending and the receiving
parties. This enables users to transport structured information using XML. XML can also specify the
structure of the message, for example, the sequence and format of elements.

3.2 XML Schemas and Instances

3.2.1 XML Schema

Functions of an XML schema
The XML schema is a formal, machine-processable language used for defining, describing and
constraining the structure, contents, and semantics of XML documents. An XML document that
conforms with its corresponding schema is known as a valid XML instance of the schema.

Standards MX schema
The MX schema defines the formal MX structure including the data and values allowed in an MX
instance.

Standards XML Schema namespaces

There are several namespace declarations used in the XML schema.
• The targetNamespace
The URN consists of a fixed part that consists of the URN of the namespace for ISO
documents: urn:iso:std:iso:20022:tech:xsd or URN of the namespace for Swift documents:
urn:swift:xsd.
Note The BusinessService$ part is used for older services. The schemas are
decoupled from the service in which they are used. Most XML schemas only
contain the MessageIdentifier.
• The XML schema namespace, that uses the namespace prefix 'xs'
• The namespace to which all MX elements and types belong. This is the default namespace,
which is the same as the TargetNamespace.

Example of namespace declarations in an MX schema

xs:schema xmlns="urn:iso:std:iso:20022:tech:xsd:pacs.008.001.08"
xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:iso:std:iso:
20022:tech:xsd:pacs.008.001.08" elementFormDefault="qualified">

Example MX Schema snippet

...
<xs:complexType name="CaseAssignment3">
<xs:sequence>
<xs:element name="Id" type="Max35Text"/>
<xs:element name="Assgnr" type="Party12Choice"/>

15 February 2024 22
Standards MX XML for Standards MX Messages
General Information

<xs:element name="Assgne" type="Party12Choice"/>

<xs:element name="CreDtTm" type="ISODateTime"/>
</xs:sequence>
</xs:complexType
...

MX message tree structure

Swift Standards documentation represents MX schema content, properties, and hierarchy as a
structure called the message tree structure.
This structure resembles the Format Specifications Table for Swift Standards MT messages (MTs).

3.2.2 XML Instance

Relationship between schemas and instances
An MX Schema describes what the allowed, valid MX instances can be. An MX instance refers to
the XML Schema to which it complies.

Example of an extract from the AdditionalPaymentInformation message instance

...
<Assgnmt>
<Id>REF-0001</Id>
<Assgnr>

15 February 2024 23
Standards MX XML for Standards MX Messages
General Information

<Pty>
<Id>
<OrgId>
<AnyBIC>CORPGB22</AnyBIC>
</OrgId>
</Id>
</Pty>
</Assgnr>
<Assgne>
<Pty>
<Id>
<OrgId>
<AnyBIC>PEFIUS33</AnyBIC>
</OrgId>
</Id>
</Pty>
</Assgne>
<CreDtTm>2014-05-21T10:30:00</CreDtTm>
</Assgnmt>
...

3.3 XML Syntax

3.3.1 XML Tags and Data

XML Tags
XML tags are used in nested pairs, with matching start-tags and end-tags that enclose pieces of
data. These are called XML elements (see Elements on page 24). The tags define the structure
and meaning of the data that they enclose. XML tags are case sensitive and are written using
abbreviated upper CamelCase.

Swift Standards XML tags

Swift uses abbreviated XML tags in schemas and instances.

Example abbreviated XML tags

<FinInstnId>
<ClrSysMmbld>

3.3.2 XML Elements

Elements
An XML instance or document contains data in elements and nested elements corresponding to
the hierarchy imposed by the XML schema.

Naming conventions
An XML element is named according to the following rules:
• The name can contain letters, numbers, and other characters, but must not start with a number
or punctuation mark.
• The name must not start with XML, xml, or Xml.
• The name must not contain any spaces.

15 February 2024 24
Standards MX XML for Standards MX Messages
General Information

MX naming conventions
There are some generic naming rules that apply to most items in the database.
• The names of all items in the database use the upper CamelCase convention, as follows:
- Each word starts with a capital letter.
- There are no white spaces between words.
• A name may be made up of multiple words, each consisting of alphanumeric characters.
• Words use British English vocabulary.
• All names must start with an alphabetic character.
• All characters that follow the first characters must be letters or numbers.

MX message element properties

An MX message element can specify cardinality using minOccurs maxOccurs. minOccurs=1 is the
default value, and maxOccurs=unbounded is the unlimited value. This corresponds to the message
item multiplicity or the cardinality.

Example of an optional message element

<xs:element name="StrtNm" type="Max70Text" minOccurs="0" maxOccurs="1"/>
Example in an instance
<StrtNm>OxfordStreet</StrtNm>

3.3.3 XML Element Types

XML element types
All message elements have a type. The XML schema describes the XML types. XML types define
the content and value of XML elements. Types can be either complex, simple, or primitive. Simple
types are based on primitive types.

Swift Standards XML complex types

Complex types are specified in the schema by complexType. Complex types provide the structure
of an XML element.
Each message component or choice component corresponds to a complex type in the MX schema.
A Swift Standards-defined complex type uses the following XML schema features:
• sequence
• choice

Example of a complex type that corresponds to a message component in a schema extract

This schema extract shows a complex type that corresponds to a message component in the ISO
20022 Financial Repository.
<xs:complexType name="SecuritiesAccount13">
<xs:sequence>
<xs:element name="Id" type="Max35Text"/>
<xs:element maxOccurs="1" minOccurs="0" name="Tp"
type="GenericIdentification20"/>
<xs:element maxOccurs="1" minOccurs="0" name="Nm" type="Max70Text"/>
</xs:sequence>
</xs:complexType>

15 February 2024 25
Standards MX XML for Standards MX Messages
General Information

This message component is represented in the ISO 20022 Financial Repository, as follows.

Example of a complex type that corresponds to a choice component in a schema extract

This complex type corresponds to a choice component in the ISO 20022 Financial Repository.
The property choice indicates that only one of the following elements can appear in an instance:
<xs:complexType name="CashAccountIdentification5Choice">
<xs:choice>
<xs:element name="IBAN" type="IBAN2007Identifier"/>
<xs:element name="Prtry" type="Max34Text"/>
</xs:choice>
</xs:complexType>
This choice component is represented in the ISO 20022 Financial Repository, as follows.

XML schema-defined primitive types

An XML schema-defined primitive type specifies the set of data and the set of operations that can
be performed on the data specified in the schema.
XML Schema Data Types are encoded as defined by the World Wide Web Consortium (W3C),
www.w3.org.

Standards MX defined data types

Standards MX defined data types have the following characteristics:
• They use primitive data types.
• They are grouped into representation classes.
All the data types in the representation class inherit the characteristics of that representation
class.
• They can be constrained using facets and by rules.
• They are globally unique across MXs.
• They have names that are suffixed by the representation class name, for example Max128Text.

15 February 2024 26
Standards MX XML for Standards MX Messages
General Information

Swift-supported XML schema data types

XML name Used by Swift Description

Standards

string Yes A finite sequence of UTF-8 characters.

boolean Yes Has a value space for Boolean constants TRUE or FALSE.

decimal Yes Has precise decimal numbers.

date Yes The date in ISO 8601 format.

Format: CCYY-MM-DD
Example: 10 June 2006 is 2006-06-10

time Yes The time in ISO 8601 format.

The recommended format is the following: (1)HH:MM:SSZ.
Example: 12:34:23Z

dateTime Yes Corresponds to a date and a time in ISO 8601 format. The letter
T separates the date and time. hh represents the hours, mm
represents the minutes, and ss represents the seconds.
Additional digits can be used to increase the precision of
fractional seconds if required. The format ss.sss... with any
number of digits after the decimal point is supported, but the
fractional seconds are optional. Other parts of the lexical form
are not optional.
This dateTime representation can be immediately followed by
a (1)Z to indicate Coordinated Universal Time (UTC). The time
zone is represented as the difference between the local time and
UTC immediately followed by a plus or minus sign (+ or -). It is
then followed by the difference from UTC represented as hh:mm.
Note: If the time zone is included, then both hours and minutes
must be present.
See the ISO 8601 Date and Time Formats for details about the
legal values used in the various elements.
In general, the order relation on dateTime is a partial order
since there is an ambiguous relationship between certain
instants. For example, there is no determinate ordering between:
1. 2000-01-20T12:00:00
2. 2000-01-20T12:00:00Z
Based on time zones currently in use, (c) can vary from
2000-01-20T12:00:00+12:00 to
2000-01-20T12:00:00-13:00.
Format: (1)CCYY-MM-DDTHH:MM:SSZ+- offset to UTC
This is the recommended format: CCYY-MM-DDTHH:MM:SSZ
Example: 2006-11-01T11:34:00Z

15 February 2024 27
Standards MX XML for Standards MX Messages
General Information

XML name Used by Swift Description

Standards

duration No A period of time in ISO 8601 format.

Format: PnYnMnDTnHnMnS

gMonthDay No A set of 1-day long, annually periodic instances (for example, a

birthday).
The time zone must be UTC.
Format: --MM-DD
Example: 25 August is --08-25

gMonth No A specific month from midnight on the first day till midnight on
the Last Day.
Format: --MM--
Example: February is --02--

gYear Yes A time period that starts at the midnight that starts the first day of
the year. This time period ends at the midnight that ends the
Last Day of the year.
This is a set of one-year long, non-periodic instances.
Format: CCYY
Example: 2006

gDay No A set of 1-day long, monthly periodic instances.

The time zone must be UTC.
Format: ---DD
Example: 29th is ---29

gYearMonth Yes A specific month in a specific year in the UTC time zone.
Format CCYY-MM
Example: February 2006 is 2006-02

base64Binary No Base64-encoded arbitrary binary data.

(1) The Z indicates a Universal Time Code (UTC) time. +hh:mm or +hh indicates a local time ahead of UTC. -hh:mm or -hh
indicates a local time behind UTC.

How to use dates and times

Users can select from several different data types to express a time. Examples of these data types
are ISODateTime, ISOTime, and ISODate.
• UTC time
This is a moment in time expressed as Co-ordinated Universal Time (UTC). If a user opts to use
UTC time, then the user generates an unambiguous timestamp.

15 February 2024 28
Standards MX XML for Standards MX Messages
General Information

Data type Format Example

ISOTime hh:mm:ss.sssZ 13:20:00.5Z

ISODateTime YYYY-MM-DDThh:mm:ss.sssZ 2007-10-10T17:00:00Z

• Local time and UTC offset

This is a moment in time expressed in local time with either a plus (+) or a minus (-). A plus (+)
indicates a positive time difference from UTC. A minus (-) indicates a negative time difference
from UTC. If a user opts to use a combination of local time and UTC offset, then the user
generates an unambiguous timestamp.

Data type Format Example

ISOTime hh:mm:ss.sss+/-hh:mm 13:20:00-05:00

ISODateTime YYYY-MM-DDThh:mm:ss.sss+/-hh:mm 2007-10-10T12:00:00.001-05:00

• Local time
This is a moment in time expressed in local time without an explicit indication of the time zone. If
a user opts to use local time, then the user generates an ambiguous timestamp unless all the
parties involved know about the time zone.

Data type Format Example

ISOTime hh:mm:ss.sss 15:28:30.05

ISODateTime YYYY-MM-DDThh:mm:ss.sss 2007-09-17T16:30:00

Note 1. 00:00:00 is the beginning of a calendar day.

24:00:00 is the end of a calendar day.
2. Users can include decimal fractions of a second. All the parties involved must
agree the number of digits that are allowed.

Data type representation class

Swift Standards data types are grouped into representation classes. Representation classes group
characteristics that are common to a number of data types. All the data types that use that
representation class inherit the characteristics of that representation class.

Class name Definition Data type

Identifier A character string used to distinguish uniquely one instance of an string

object within an identification scheme from all other instances of the
objects within the same scheme.

Code A list of all coded values for a particular element and the meanings string
they represent.

Indicator 2 alternative values that indicate a condition. boolean

15 February 2024 29
Standards MX XML for Standards MX Messages
General Information

Class name Definition Data type

Text A finite set of characters. string

Quantity A number of non-monetary units. decimal

Amount A number of monetary units specified in a currency where the decimal

currency is explicit or implied.

DateTime Describes a time measurement. date

For more information about dateTime formats, see Swift-supported time
XML schema data types on page 27.
dateTime
gDay
gMonth
gYear
gMonthday
duration

Rate A quantity or amount specified with respect to another quantity or decimal

another amount, or a fixed or appropriate charge, cost, or value.

Example of an MX schema extract that shows a Swift Standards-defined data type

Data type of representation

class 'Identifier'

<xs:simpleType name="AnyBICIdentifier">
<xs:restriction base="xs:string">
<xs:pattern value="[A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}"/>
</xs:restriction>
</xs:simpleType>

Primitive type 'string'

Data type restriction based on a string

or type format
D0960018

15 February 2024 30
Standards MX XML for Standards MX Messages
General Information

Example of a Standards MX defined data type in the ISO 20022 Financial Repository

Example of message element typed by the AnyBICIdentifier data type in an MX message

instance
<AnyBIC>CHASUS33C</AnyBIC>

15 February 2024 31
Standards MX XML for Standards MX Messages
General Information

3.3.4 XML Document

Swift XML document or MX instance example

XML prolog Root element

Namespace

<?xml version="1.0" encoding="UTF-8"?>

<Document xmlns="urn:iso:std:iso:20022:tech:xsd:sese.023.001.04"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SctiesSttlmTxInstr>
<TxId>ABC-111111</TxId>
<SttlmTpAndAddtIParams>
<SctiesMvmntTp>DELI</SctiesMvmntTp>
<Pmt>APMT</Pmt>
</SttlmTpAndAddtIParams>
<TradDtls>
<SttlmDt>
<Dt>
<Dt>2014-03-10</Dt>
</Dt>
</SttlmDt> Child element
</TradDtls> of root
<FinInstrmld>
<ISIN>GB1234567890</ISIN></FinInstrmld>
<QtyAndAcctDtls>
<SttlmQty>
<Qty>
<Unit>4000</Unit>
</Qty>
</SttlmQty>
<SfkpgAcct>
<Id>11111111</Id>
</SfkpgAcct>
<QtyAndAcctDtls>
...
<SctiesSttlmTxInstr>

</Document>
D0960019

End of root element

XML prolog
The first line of the document or message instance defines the XML version and the character
encoding used in the document. This declaration is not an XML element and not part of the XML
document or message instance. The XML prolog does not have a closing tag.

Root element
All XML documents must have a root element. The root element is at the top of the XML element
hierarchy. The root element of an XML instance is <Document>. The last line of the document
defines the end of the root element </Document>.

15 February 2024 32
Standards MX XML for Standards MX Messages
General Information

Namespace
A namespace is a container that provides context for the XML elements and XML attributes that it
qualifies and allows XML elements and attributes that have the same name to be easily
distinguished.

Namespace Definition
prefix

xsi The XML schema instance namespace.

absent The namespace to which all XML elements of this MX instance belong that are defined in the
(default) corresponding MX Schema. It defines all XML elements and attributes that do not belong to
or defined the xsi namespace.
by the
Sender

3.3.5 DOCTYPE
The document must not contain a DOCTYPE declaration as per the ISO 20022 standard.

3.4 XML Document Validation

MX message validation is performed in the following parts:
• schema validation
• extended validation
• usage guideline validation

3.4.1 Schema Validation

Schema validation
Schema validation is performed in two parts:
• the MX instance is well-formed XML
• the MX instance is valid

Well-formed XML
The schema verifies that the document is well formed. An XML instance or XML document with
correct syntax is called a well-formed XML document.
Well-formed XML has the following characteristics:
• Each XML document must be a single-rooted hierarchical structure of elements.
• All elements are correctly paired.
• The element opening tag and closing tag are the same.
• Element names must start with an alphabetic character. Subsequent characters may be
alphanumeric.

15 February 2024 33
Standards MX XML for Standards MX Messages
General Information

Examples of well-formed XML

Well-formed Not well-formed Option

<Ref>1234</Ref>

<Ref>1234<Ref> end tag / is missing

<R@f>1234</R@f> element name contains illegal character @

Valid schema
The schema checks the validity of the XML instance. An instance validated against its
corresponding schema is called a valid XML instance.

MX structure
The schema validates the following items:
• the MX structure starting from the root element (top level element)
• the allowed elements, and the order in which they must be used (sequence)
• simple XML element relations, for example, parent-child and siblings
• the cardinality of the XML elements, for example, mandatory or optional, or the number of
occurrences allowed
• choices among XML elements

XML element content

The schema verifies the allowed content of the following elements:
• the allowed values within the elements
• the allowed format
• the allowed characters (character set)

3.4.2 Non-Schema Validation

Extended validation
Extended validation ensures that Standards MX messages are validated to the same standards as
Standards MT messages. Extended validation can be performed when the XML schema does not
validate the document completely. A user can also decide to perform some validation tasks
separately, for example, Business Identifier Code (BIC) validation.
Rules for extended validation

Type of Example
validation rule

Cross-element The element Entry Date must only be present if entry status has the value booked.

Intra-element The fractional part of an amount is checked against its currency.

15 February 2024 34
Standards MX XML for Standards MX Messages
General Information

Type of Example
validation rule

Reference data Reference data validation may involve look-up in external tables.
validation
Example of calculations or derived elements:
The comparison of 2 dates or the comparison of 2 amounts.
International Bank Account Number (IBAN) validation of the check digits.
For more information about IBANs, see Example of calculation validation on page 35.

Example of external tables:

Currency codes (ISO 4217).
Country codes (ISO 3166).
For more information about country codes, see Example of external table validation on
page 35.
Business Identifier Code (BIC)

Example of calculation validation

Definition An identifier used internationally by financial institutions to identify the account of a customer at
a financial institution. This is described in the ISO 13616 standard, Banking, and related
financial services International Bank Account Number (IBAN).

Format [a-zA-Z]{2,2}[0-9]{2,2}[a-zA-Z0-9]{1,20}]

Rules IBAN
A valid IBAN consists of all 3 components, the Country Code, check digits and Basic
Bank Account Number (BBAN).
(fatal) error code: sw.Stds.D000003

Example AT611904300234573201

Example of external table validation

Definition This code identifies a country, a dependency, or another area of particular geopolitical interest.
This code is based on the list of country names obtained from the United Nations (ISO 3166
alpha-2 code).

Format [A-Z]{2,2}

Rules Country
The code is checked against the list of country names obtained from the United Nations
(ISO 3166. Alpha-2 code).
(fatal) error code: Sw.Stds.D00004

Example BE

15 February 2024 35
Standards MX XML for Standards MX Messages
General Information

Non-validated rules
It is not always possible to validate some rules. These rules are known as non-validated rules. A
non-validated rule usually occurs when the infrastructure does not have enough information to be
able to validate the rule correctly. This does not mean that these rules cannot be followed.
Swift only maintains a limited set of code and identifier lists. Most other identifier lists are referred
to by the standard. In these cases, SwiftNet cannot verify that a value (such as ISIN, CUSIP,
SEDOL, or RIB) taken from such list, is correct.

Guidelines
An MX can also have guidelines in addition to validated and non-validated rules.

Important Unlike validated and non-validated rules, guidelines are not mandatory.

Guidelines cannot be imposed in the same way as rules because there are rare cases when a
guideline cannot be followed. For example, there is a guideline that advises a user to use an
International Securities Identification Number (ISIN). This is a guideline not a rule because some
securities do not have an ISIN or are not uniquely identified. This also applies to the guideline to
use a BIC to identify a party. There are some financial institutions or business entities that do not
have a BIC.

3.4.3 Usage Guideline Validation

The schema and non-schema validation rules described above describe the ISO 20022 base
message definition (referred as the Base Standard).
Message definitions can be further tailored to specific business contexts with the addition of
restrictions. These restrictions must not make the messages invalid against the Base Standard
definition. For example, the restrictions must not:
• introduce a new code word in an existing (validated) code list
• make a mandatory field optional
• extend the maximum allowed set of characters
Those tailored message definitions are referred as the Usage Guidelines. The MyStandards
platform offers dedicated features to create, edit, publish and compare the Usage Guidelines.
The Usage Guideline validation refers to the validation of those restrictions.

Type of restrictions Description

Syntactic restriction Syntactic restrictions include any change supported by the XML schema
language which does not conflict with the base message rules, notably:
• Make the optional element mandatory.
• Restrict the length of individual elements to a lower number of
characters.
• Disallow some code values in a code list.
• Restrict allowed character set (the ISO 20022 base message
generally supports UTF-8, which is generally too wide for specific
business communities).

15 February 2024 36
Standards MX XML for Standards MX Messages
General Information

Type of restrictions Description

Formal semantic restriction Formal semantic restrictions include cross-element rules (not supported
by the XML schema), which do not conflict with the base message rules.
They are recognisable through the presence of logical operators in
capital letters within the rule definition (for example, 'OR', 'AND').

Textual restriction Textual rules are recognisable by the fact that they are expressed in
English text without the use of logical operators in capital letters.
These rules generally cannot be validated in a deterministic way, either
because they rely on parameters inaccessible to Swift or because they
are too complex to encode with existing MyStandards editor capabilities.

Note MyStandards does not support setting such as usage guideline restrictions that would
induce calculation on derived elements (for example, compare 2 dates and/or
amounts) or a look-up in external tables. Accordingly, MVAL does not support setting
usage guideline restrictions either. Message validation only supports the reference
data checks (for example, BIC, IBAN, currency code) embedded within the ISO 20022
base message specifications.

3.4.4 Error Codes

Generic error codes
The errors that are produced during XML schema validation generate and display generic error
codes. Any payload can generate these errors.
Note The XML schema validation engine uses third-party software to generate error codes.
Swift recommends that customers do not include these error codes in any customer
programs since the error codes may change without notice.

Possible instance validation errors

The placeholders in these error messages ("_TypeName", "_Value_", "_ElementName_") must be
replaced with values specific to the error context at runtime.
For the latest list of generic error codes, see the SwiftNet Link Error Codes.
MX or message component-specific errors
Refer to the message description in the relevant Standards MX Message Reference Guide for the
description and error code for a specific error.

3.5 Swift Standards Supported Character Sets and

Encoding Scheme

3.5.1 Swift Standards MX-Supported Character Sets

Character sets list
The default rule for MX-supported characters and languages is that the user must always use
English and Basic Latin, except if a Closed User Group is set up in which other principles are

15 February 2024 37
Standards MX XML for Standards MX Messages
General Information

agreed. This mechanism allows any user to decide whether the user wants to be part of the Closed
User Group or not. It reduces the risk that local languages / character sets are sent by accident to a
wrong destination. If the base message validation applies and if the service description of a Closed
User Group does not specify language or character set, then it means that the user must only use
English and Basic Latin within that Closed User Group. If the user must use other characters (for
example, Cyrillic), then this must be explicitly mentioned within the service description of that
Closed User Group. Alternatively, the service description shall explicitly mention the usage
guideline rules applicable for each request type (in which case service participants can infer
applicable character set restrictions out of the usage guideline specifications in MyStandards)
The following table includes the most relevant characters used in Basic Latin, compared to the FIN
character sets X, Y and Z.
Non-latin characters are also supported.
Basic Latin character set

MT MX

X Y Z Basic Latin Character Description

* * * a - z 26 lower case letters of the Latin alphabet

* * * * A - Z 26 upper case letters of the Latin alphabet

* * * * 0 - 9 10 numerical characters

* * * * / slash

* * * * - hyphen

* * * * ? question mark

* * * * : colon

* * * * ( open parentheses

* * * * ) close parentheses

* * * * . full stop

* * * * , comma

* * * * ` apostrophe

* * * * + plus

* * * * space

* * * = equals

* * * ! exclamation mark

* * * " quotation mark

* * * % percent

15 February 2024 38
Standards MX XML for Standards MX Messages
General Information

MT MX

X Y Z Basic Latin Character Description

* * * And ampersand

* * * * asterisk

* * * < less than

* * * > more than

* * * ; semi-colon

* * @ at

* * # hash

* * $ dollar

* * * { open curly bracket

* * * } close curly bracket

* * * * CR carriage return

* * * * LF line feed

* [ left square bracket

* ] right square bracket

* \ back slash

* _ under score

* ^ circumflex

* ‘ grave accent

* | vertical line

* ~ tilde

* control character

Unicode text-based data types

This is a non-exhaustive list of the data types that currently support the Unicode character set.

Max3Text Max16Text Max128Text Max1025Text

Max6Text Max35Text Max140Text Max2000Text

Max8Text Max70Text Max256Text Max20000Text

15 February 2024 39
Standards MX XML for Standards MX Messages
General Information

Max10Text Max105Text Max350Text Max1MText

Use of normalised characters

When an application creates an XML instance, characters must not be represented as character
entities. Except for two mandatory characters which must be normalised, and three optional
characters which may be represented as shown in the following table. For more information, see
the XML 1.0 Specification - Section 2.4 Character Data and Markup.

Special character XML representation

Mandatory

< &lt;

& &amp;

Optional

" &quot; (or ")

` &apos; (or `)

> &gt; (or >)

Important This method for handling special characters applies irrespective of whether the full
Unicode character set, or only the restricted Basic Latin character set, is used.

Even characters that are shorter when represented as a character entity must use UTF-8 encoding.
This includes all the UTF-8 encoded characters that use more than 4 bytes. For example, CrLf
must be normalised into Lf (#xA). For more information, see the XML 1.0 Specification - Section
2.11 End-of-Line Handling.

Example of normalised characters

XML entities are stored in computer files which are organised into lines. Typically these lines use a
combination of the carriage-return (#xD) characters and line-feed (#xA) characters to separate each
line.
These end-of-line characters can be normalised. The 2-character sequence #xD #xA, and any #xD
that is not followed by #xA, are translated into a single #xA character.

Action performed Character sequence Normalised to

carriage-return, line-feed #xD #xA #xA (line-feed)

carriage-return #xD #xA (line-feed)

3.5.2 Use of the UTF-8 Encoding Scheme

UTF-8 encoding is a technical implementation in XML schemas that can specify almost any
character. The schema is based on Unicode and the Universal Character Set (ISO 10646). UTF-8

15 February 2024 40
Standards MX XML for Standards MX Messages
General Information

encoding represents any Unicode character (or any character of the Universal Character Set) as a
sequence of bytes.

Important XML instances based on MX schemas must be encoded in UTF-8.

3.6 xs:any
Function of xs:any
The XML schema function xs:any allows Standards MX message instances to contain additional
information while retaining as much control as possible over the content. Customers can use this
function to insert a copy of a message into another message.
When the xs:any schema function is used, there are two XML schemas. The parent schema must
be an MX schema. The parent schema declares the open content by using xs:any. The child
schema describes the contents of xs:any.

Parent and child schemas

XML Document

MX Message Instance

Message items
defined in schema 1

<container>
xs: any defined in ...
schema 2 <container>

D0960011

A valid XML document must be valid for both the parent schema (for the part outside the <any>)
and the child schema (for the part inside the <any>). The parent schema can use the parameter
processContents to set the validation level inside xs:any. For more information about the
processContents parameter, see processContents parameter on page 42.

Namespace parameter
The value of the namespace parameter specifies the type of element content permitted in the
namespace. The message instance must specify either one namespace from a list of namespaces,
or a predefined parameter value.

Namespace parameter Permitted contents of the element

value

##any Any well-formed XML from any namespace. This is the default parameter
value.

15 February 2024 41
Standards MX XML for Standards MX Messages
General Information

Namespace parameter Permitted contents of the element

value

##other Any well-formed XML from a namespace other than the target namespace of
the type being defined. Unqualified elements are not allowed.

##targetNamespace Any well-formed XML belonging to any namespace in list.

##targetNamespace represents the target namespace being defined.

processContents parameter
The parent schema can use the parameter processContents to set the validation level for xs:any.

processContents Effect on validation

parameter value

strict The sender must specify the schema used by xs:any in the XML document. If
the receiver cannot locate the schema specified in the document, then the
document fails validation.

lax Any xs:any elements that are defined in the matching schema are validated.
Elements in the parent schema that are not defined in the matching schema
are allowed to pass through unvalidated.

skip xs:any content is not validated.

Extensible messages with Straight-Through Processing (STP)

If the processContents parameter is set to strict, then the receiver of the message can
understand and process the extension. This specifies that only XML schemas known to the
receiver can be used.

Extensible message with less or without STP

If the processContents parameter is set to lax or skip, then the receiver may or may not be able
to process the document. Documents with XML schemas unknown to the receiver still pass
validation.

Example
A user wants to extend the ISO 20022 message , using the SupplementaryData component from
the ISO 20022 message, to add a "Related Transaction Identification" element missing in the ISO
20022 message:
<Document
<Schema1>
....
contains the structure of the ISO 20022 message, including the last element as
SupplementaryData
....
<SplmtryData>
<PlcAndNm>"Xpath to where the element must be added in the ISO 20022 message"</
PlcAndNm>
<Envlp>
<Sup:Document xmlns:Sup="<schema2 namespace>"
<Sup:Schema2>
<Sup:RltdTxId>Id12345</Sup:RltdTxId>
</Sup:Schema2>

15 February 2024 42
Standards MX XML for Standards MX Messages
General Information

</Sup:Document>
</Envlp>
</SplmtryData>
</Schema1>
</Document>

15 February 2024 43
Standards MX MX Messages and InterAct
General Information

4 MX Messages and InterAct

4.1 MX Message Structure

InterAct MX message blocks with Application Header

Exchange Request

Request SWIFTNet Headers

RequestHeader

Envelope - container for the business

RequestPayload message
Application
Application Header
Header The business message comprises the
application header and ‘business’
document
Document

Supplementary Data The ‘business’ document optionally

Extension(s) contains Supplementary Data
Extension(s)

Crypto

D0960015
InterAct MX message blocks with Business Application Header

Exchange Request

Request SWIFTNet Headers

RequestHeader

Envelope - container for the business

RequestPayload message
Business Application The business message comprises the
Header (BAH) BAH and ‘business’ document

Document

Supplementary Data The ‘business’ document optionally

Extension(s) contains Supplementary Data
Extension(s)

Crypto
D0960023

15 February 2024 44
Standards MX MX Messages and InterAct
General Information

SwiftNet Headers Among others, SwiftNet headers include RequestControl,

RequestResponse, ExchangeRequest, Request and
RequestHeader.

RequestPayload The RequestPayload consists of the business application header or the

application header (optional) and the document (MX message instance).

BusinessApplicationHeader The ApplicationHeader or a version of the ISO 20022

BusinessApplicationHeader. This is defined by an XML schema, for
example BusinessApplicationHeaderV01 head.001.001.01 or
BusinessApplicationHeaderV02 head.001.001.02

Business document A business document (message body). This is defined by an XML schema,
for example, CustomerCreditTransferInitiationV05 pain.001.001.05 or
SubscriptionOrderV03 setr.010.001.03 which defines the MX XML or
ISO 20022 structure. The MX message instance has a maximum payload
of 100 000 bytes.

Crypto Crypto contains any message signature and verification information.

4.2 Message Blocks

4.2.1 Message Headers

Introduction
This section contains general information applicable to any MX. For more information about the
specific usage of the application header in the context of a service, see the relevant service
description or message usage guidelines.

What are headers?

Applications use headers to manipulate messages. A header enables an application to process
messages regardless of their content.
There can be several headers, each addressing a different application that processes part of the
message:
• Business header
The business header contains information that is relevant to the customer business applications
that route and process the business message. This information is required before opening the
actual message so that the business application can process the content properly.
There are three business headers but only one is used in a message at any one time:
- The business application headers (BAH) which are ISO 20022 approved. There are
currently two but this can evolve over time.
▪ head.001.001.xx (ISO 20022 business application header version 1)
▪ head.001.001.xy (ISO 20022 business application header version 2 used notably by
FINplus)
- The Swift application header: $ahV10

15 February 2024 45
Standards MX MX Messages and InterAct
General Information

Note The application header is replaced by the business application header and it is
expected that there will be no new implementations using the application
header. Those services or solutions using the application header will remain
using it until it is agreed they should replace it with the business application
header.
• Network headers
The network headers contain information that is relevant for the networking application
transporting the messages. For example, the Distinguished Name (DN) of the sender and
receiver is specified in the RequestHeader and is used to deliver the message on SwiftNet.
• Security header
The security header contains information that is relevant to the application in charge of the
encryption or the signature of the messages.

ISO 20022 business application header or application header?

The ISO 20022 business application header (BAH) is replacing the application header (AppHdr)
mandated by SwiftNet.
The deployment principles for the business application header are as follows:
• The business application header is deployed on a service by service basis, and if necessary, on
a message by message basis.
• The decision on when a service starts using the new business application header is driven by
the user community of that service.
Note For existing Swift Solutions, a duplication of information between the business
application header and the MX message is possible. In a future release of the MX
messages set, the relevant message elements will be removed to avoid any
duplication. The decision to remove duplicated message elements is made on a
service by service basis, and if necessary, on a message by message basis.

15 February 2024 46
Standards MX MX Messages and InterAct
General Information

4.2.1.1 ISO 20022 Business Application Header

Structure of the ISO 20022 business application header
The diagram below is an overview of the structure of the business application header.

Components of the ISO 20022 business application header

Element XML tag Purpose

CharacterSet <CharSet> The additional character set(s) that some of the text-based
elements may contain.
Example: Basic Latin

From <Fr> The sending business application that has created this
business message for the receiving business application
that will process this business message.

15 February 2024 47
Standards MX MX Messages and InterAct
General Information

Element XML tag Purpose

To <To> The business application designated by the sending

business application to be the recipient who will ultimately
process this business message. Note the receiving
business application might be different from the receiving
address potentially contained in the transport header (as
defined in the transport layer).

BusinessMessageIdentifier <BizMsgIdr> The identification of the business message, unique to the

SendingBusinessEntity.
Example: ref0001.

MessageDefinitionIdentifier <MsgDefIdr> The identification of message definition.

Example: camt.001.001.01

BusinessService <BizSvc> The business service (Swift's Solutions or non-Swift

service) agreed between the two business applications
under which rules this business message is exchanged. To
be used when there is a choice of processing services or
processing service levels.
Example for a Swift's Solution such as Exceptions and
Investigations: swift.eni

CreationDateTime <CreDt> The date and time when this business message (header)
was created. Times must be normalised, using the Z
annotation.

CopyDuplicate <CpyDplct> Indicates whether the business message is a copy, a

duplicate or a copy of a duplicate of a previously sent
business message.

PossibleDuplicate <PssblDplct> Flag indicating if the business message exchanged

between the business applications is possibly a duplicate.
If the receiving MessagingEndpoint did not receive the
original, then this business message should be processed
as if it were the original. If the receiving
MessagingEndpoint did receive the original, then it should
perform necessary actions to avoid processing this
business message again. This guarantees business
idempotent behaviour.

Priority <Prty> Relative indication of the processing precedence of the

message over a (set of) business messages with assigned
priorities.

Signature <Sgntr> The digital signature of the business entity authorised to

sign this business message.

Related <Rltd> The business application header of a related business

message.

15 February 2024 48
Standards MX MX Messages and InterAct
General Information

Related information
The ISO 20022 BusinessApplicationHeader XML schema, the Message Definition Report and the
Message Usage Guide are available at
iso20022.org > Catalogue of ISO 20022 Messages
The ISO 20022 BusinessApplicationHeader XML schema and document is available on
MyStandards > Base Standards > MX > Business Area > Business Application Header
The ISO 20022 BusinessApplicationHeader XML enriched schema and MS Excel representation
are part of
MyStandards > Base Standards > Base Libraries > MX Enriched Schema Library and MX Enriched
Spreadsheet Library

4.2.1.2 Swift Application Header - $AhV10

Structure of the Swift application header

Overview of the structure of the Swift application header

Type
<Type>
From Max4Text
<From>
EntityIdentification EntityIdentifier
<Id>
Max30Text

Type
<Type>
To Max4Text
<To>
EntityIdentification EntityIdentifier
<Id>
Max30Text

ServiceName
<SvcName>
Max30Text
AppHdr
MessageName
<AppHdr> <MsgName>
Max30Text

MessageReference
<Ref>
Max30Text

CreationDateTime
<CrDate>
ISODateTime

Reference
<Ref>
Duplicate Max30Text
<Dup>
DuplicateIndication Justification
<Info>
D0960005

Max40Text

Components of the Swift application header

Element XML tag Purpose

Business application <From> Identifies the application that has created the document.
from which the document
is received

15 February 2024 49
Standards MX MX Messages and InterAct
General Information

Element XML tag Purpose

Business application to <To> Identifies the receiving application for which the document is
which the document is created.
sent

Service name <SvcName> Identifies the SwiftNet service to which the message belongs.

Message identifier <MsgName> A unique structured identifier that identifies the message.

Message reference <MsgRef> The sending application defines this unique identifier for the
message.

Creation date <CrDate> Date and time at which the message was created.

Duplicate <Dup> Used when the sending application has already tried to send
the document to the receiving application.

15 February 2024 50
Standards MX MX Messages and InterAct
General Information

The Swift application header schema

Swift application header scenarios

This section contains a number of examples of how the Swift application header is used to route an
MX within an institution in different scenarios, as follows:
• Scenario one: the default Swift application header on page 52.
• Scenario two: a SwiftNet service bureau header on page 53.
• Scenario three: a Member-Administered Closed User Group header on page 53.
• Scenario four: a relay header on page 54.

15 February 2024 51
Standards MX MX Messages and InterAct
General Information

Scenario one: the default Swift application header

A generic messaging application, at bank A in London, sends an MX to business application B, at
bank B in Paris.
Note The application header From and To elements may specify the business entity such as
a BIC, NAME, Universal Resource Identifier (URI), DN.

BNKAGB2L BNKBFRPP
Bank A, London Bank B, Paris

SWIFTNet
message A

RequestHeader

<RequestHeader>
<Requestor>o=bnkagb2l,o=swift</Requestor>
<Responder>o=bnkbfrpp,o=swift</Responder>
...
</RequestHeader>
<RequestPayload>
<AppHdr>
<MsgRef>ID1</MsgRef>
ApplicationHeader <CrDate>2014-03-31T09:00:00</CrDate>
<To>
<Tp>NAME</Tp>
<Id>Application B</Id>
</To>
Application B </AppHdr>

D0960003

15 February 2024 52
Standards MX MX Messages and InterAct
General Information

Scenario two: a SwiftNet service bureau header

Application A, at corporation A, sends an MX to bank B in Paris. Corporate A is not directly
connected to SwiftNet, so it sends the MX through a service bureau.

CRPAGB2L BNKBFRPP
Service Bureau Bank B, Paris
Corporate A

Private SWIFTNet
network message

<RequestHeader>
<Requestor>o=crpagb2l,o=swift</Requestor>
<Responder>o=bnkbfrpp,o=swift</Responder>
…
</RequestHeader>
<Request Payload>
<AppHdr>
Application A <MsgRef>ID2</MsgRef>
<CrDate>2014-03-31T10:00:00</CrDate>
<From>
<Tp>NAME</Tp>
<Id>Application A</Id>
</From>
<To>
<Tp>BIC</Tp>
<Id>BNKBFRPP</Id>

D0960004
</To>
</AppHdr>

Scenario three: a Member-Administered Closed User Group header

Corporate A is part of a Member-Administered Closed User Group administered by MCUGNL2A. A
person in corporate A sends a message to application B, at bank B, in Paris. MCUGNL2A only
forwards the contents of the <RequestPayload> part of the message without processing it.

15 February 2024 53
Standards MX MX Messages and InterAct
General Information

<RequestPayload> remains unchanged between corporate A and bank B. The Swift application
header contains no reference to MCUGNL2A. MCUGNL2A does appear in the request header.

BNKBFRPP
MACUG
Corporate A Bank B, Paris
MCUGNL2A

SWIFTNet SWIFTNet
message A message B

John Smith Application B

<RequestHeader>
<Requestor>o=crpagb2l,o=swift</Requestor>
<RequestHeader> <RequestHeader>
<Responder>o=mcugnl2a,o=swift</Responder>
<Requestor>o=crpagb2l,o=swift</Requestor> <Requestor>o=mcugnl2a,o=swift</Requestor>
… <Responder>o=mcugnl2a,o=swift</Responder> <Responder>o=bnkbfrpp, o=swift</Responder>
</RequestHeader>
… ...
...</RequestHeader> </RequestHeader>
<Payload>
<RequestPayload> <RequestPayload>
<AppHdr>
<AppHdr> <AppHdr>
<MsgRef>ID1</MsgRef>
<MsgRef>ID3</MsgRef> <MsgRef>ID4</MsgRef>
<CrDate>2005-02-16T09:00:00</CrDate>
<CrDate>2014-03-31T09:00:00</CrDate> <CrDate>2014-03-31T09:04:00</CrDate>
<From>
<From> <From>
<Tp>NAME</Tp>
<Tp>NAME</Tp> <Tp>NAME</Tp>
<Id>John Smith</Id>
<Id>John Smith</Id> <Id>John Smith</Id>
</From>
</From> </From>
<To><To> <To>
<Tp>NAME</Tp>
<Tp>NAME</Tp> <Tp>NAME</Tp>
<Id>Application B</Id>B</Id>
<Id>Application <Id>Application B</Id>
</To></To> </To>
...
</AppHdr> </AppHdr>

D0960002
</AppHdr>

Scenario four: a relay header

Corporate A sends a message to application B, at bank B, in Paris. Corporate A is not connected to
SwiftNet, so it sends the message though RLAYN2A which is a relay institution. RLAYN2A forwards
the contents of the <RequestPayload> section of the message. <RequestPayload> remains

15 February 2024 54
Standards MX MX Messages and InterAct
General Information

unaltered between corporate A and bank B. Corporate A creates the Swift application header. The
relay institution does not change the Swift application header.

BNKBFRPP
Corporate A RLAYNL2A Bank B, Paris

non-SWIFTNet SWIFTNet
message message

<RequestHeader>
<Requestor>o=rlaynl2a,o=swift</Requestor>
<Responder>o=bnkbfrpp,o=swift</Responder>
…
</RequestHeader>
<RequestPayload> Application B
<AppHdr>
<MsgRef>ID4</MsgRef>
<CrDate>2014-03-31T09:00:00</CrDate>
<From>
<Tp>NAME</Tp>
<Id>Corporate A</Id>
</From>
<To>
<Tp>NAME</Tp>
<Id>Application B</Id>
</To>
</AppHdr>
<Document>
…
</Document>

D0960001
</RequestPayload>

4.2.1.3 From and To

In the Application Header and the Business Application Header, there are optional From and To
elements:

Application Header Business Application Header

Element Data Element Data

From May contain, for example, From May contain, for example,
a name, BIC or Uniform a name, postal address,
To Resource Identifier (URI) To BIC, proprietary
and so on. (Max30Text) identification, contact
details (and so on).
(OrganisationIdentificatio
n or
FinancialInstitutionIdentifi
cation)

Whilst the From and To elements have different definitions and the elements in the Business
Application Header are specified in structured elements and sub-elements, the intent of the From
and To elements in both headers is the same. The From element is used for the identification of
the sender, whether as a BIC, a name and address, a proprietary identification or a Uniform
Resource Identifier (URI). The To element is used for identification of the receiver, whether as a
BIC, a name and address, a proprietary identification or a Uniform Resource Identifier (URI). The
usage guidelines of the To and From elements may differ in the context of the different services,
for more information see MyStandards.

15 February 2024 55
Standards MX MX Messages and InterAct
General Information

Important It is NOT recommended that the From or To elements repeat the Distinguished Name
(DN) from the RequestHeader. Typically, the DN in the RequestHeader generically
identifies the SwiftNet recipient and sender, whereas a DN in the Application Header
or Business Application Header identify the business application within the institution.
This may be specified in the Name element of the Business Application Header
(From/FinancialInstitutionIdentification/Name),which allows up to 140 characters, or in
the From/EntityIdentifier element of the application header, which allows up to 30
characters.

4.2.2 Business Document

The business document represents the main data to be transferred in a message. It carries the
business/transactional information which the message’s function is meant for. Generally preceded
by the (business) application header, both form altogether the business message (payload). It
could optionally include one or more supplementary data extensions.
The business document ISO 20022 message identifier (for example, pacs.008.001.01) is often
used to designate the full business message, even though it does not say anything about what
(business) application header version is used. Swift relies on additional meta info (such as the
SwiftNet service name or the request subtype inside the network header) to derive the applicable
application header.
For more information about service name and request subtype, see the SwiftNet Messaging
Operations Guide.

4.2.3 Supplementary Data Extension

Supplementary component that can be used by communities of users to add information to a
message that is not catered for by other components of the message definition. The supplementary
data component is made of two elements
• a location element, allowing the supplementary data to be targeted at a specific point in the
message
• a structured data element, which allows the identification of a separate ISO 20022 compliant
schema and the inclusion of data that conforms to that schema
Supplementary data extensions have their own ISO 20022 message identifier (for example, supl.
001.001.01). Accordingly, they follow similar registration, publication and maintenance processes
as other ISO 20022 message definitions.

4.3 Business Usage Definition

The business content transported over the Swift network (the InterAct payload) consists of the
combination of an application header, a business document and supplementary data blocks if any.
Each of them must conform to their own ISO 20022 base message rules (including both schema
and non-schema rules) as well as usage guideline restrictions if any. Combined together, they form
the Business Usage Definition.
The business usage definition identifies the complete set of base message rules and restrictions
applicable to a given business message (= payload). It typically includes:
• the base message rules of the (business) application header, if present
• the base message rules of the business document

15 February 2024 56
Standards MX MX Messages and InterAct
General Information

• the base message rules of the supplementary data extension(s), if present

• the usage guideline restrictions applicable on each above elements
• additional complex cross-element usage guideline restrictions between elements belonging to
separate blocks, for example, rule between business application header and business
document elements

4.4 MX Message
The following diagram shows the structure of an MX message. Each block has its own message
definition and schema..

Exchange Request

Request

RequestHeader Message Definition

RequestPayload or Business Physical representation

Application
Application Header Header
Schema
Document
Validation
Supplementary Data
Extension(s)

Crypto

D0960016

15 February 2024 57
Standards MX MX Messages and InterAct
General Information

Example of a pacs.008.001.08 message sent in the scope of the Swift Exceptions and
Investigations solution with InterAct:

<?xml version=”1.0” encoding=”UTF-8”?>

<SwInt:ExchangeRequest>
<SwSec:AuthorisationContext>
<SwSec:UserDN>cn=nat,0=swhqbebb,0=swift</SwSec:UserDN>
</SwSec:AuthorisationContext>
<SwInt:Request>
<SwInt:RequestControl>
<SwInt:RequestCrypto>TRUE</SwInt:RequestCrypto>
</SwInt:RequestControl>
<SwInt:RequestHeader>
<SwInt:Requestor>ou=swhqbebb,0=swift</SwInt:Requestor>
<SwInt:Responder>ou=swhqbebb,0=swift</SwInt:Responder>
<SwInt:Service>swift.eni</SwInt:Service>
<SwInt:RequestType>pacs.008.001.08</SwInt:RequestType>
</SwInt:RequestHeader>
<SwInt:RequestPayload>
<AppHdr xmlns:Ah=”urn:swift:xsd:$ahV10”
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<MsgRef>123456</MsgRef>
<CrDate>2014-05-17T10:32:00</CrDate>
</AppHdr>
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pacs.008.001.08"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<AddtlPmtInf>
<Assgnmt>
<Id>REF-0001</Id>
<Assgnr>
<Pty><Id>
<OrgId>
<AnyBIC>CORPGB22</AnyBIC>
</OrgId>
</Id></Pty>
</Assgnr>
<Assgne>
<Pty><Id>
<OrgId>
<AnyBIC>PEFIUS33</AnyBIC>
</OrgId>
</Id></Pty>
</Assgne>
<CreDtTm>2014-05-21T10:30:00</CreDtTm>
</Assgnmt>
….
</AddtlPmtInf>
</Document>
</SwInt:RequestPayload>
<SwSec:Crypto>
<SwSec:CryptoControl>
<SwSec:MemberRef>RequestPayload</SwSec:MemberRef>
<SwSec:SignDN>cn=nat,0=swhqbebb,0=swift</SwSec:SignDN>
</SwSec:CryptoControl>
</SwSec:Crypto>
</SwInt:Request>
D0960017

</SwInt:ExchangeRequest>

15 February 2024 58
Standards MX MX Messages and InterAct
General Information

4.5 MX Message Identification

The Business Usage Definition is uniquely identified by the Business Document’s message
definition identifier together with the usage identifier (respectively seev.001.001.07 and swift.srdii.
01 in the example that follows).
Note Existing business usage definitions do not include extensions, since MyStandards
does not support the full combination yet.

The first gives general information on the message’s function, whereas the second offers a
practical means to identify the message’s specificities driven by the business context in which it is
used. Those include:
• application header and supplementary data extension(s) presence and message definition
• usage guideline restrictions on or across application header, business document or
supplementary data extensions if any (for example, to help distinguish STP versus Core or
more Market Infrastructure-specific flavours)
Both values are either located:
• within Swift's network header
Request type and request subtype in the InterAct header respectively carry both values. They
enable Swift to validate the message without the need to scan through the full payload details.
The request subtype field is optional. Swift may derive the validation rules solely based on the
service name and request type combination in some cases. For more information, see the
SwiftNet Messaging Operations Guide.
• within the payload under the Business Application Header (BAH), unless dictated
otherwise by the Market Infrastructure's standards specifications:
CBPR+ usage guidelines (FINplus) impose the Business Application Header to contain both values
respectively in the MsgDefIdr and BizSvc elements, to make both values available end-to-end
throughout the transaction, in a predictable manner. This allows:
• to provide a simple means for back-office applications to process and route the message
without the need to look into the Business Document details
• to enable differentiated routing, compliance, visualisation at the sending and receiving of
SwiftNet interfaces
• to enable differentiated central validation, translation, copy on SwiftNet and/or FINplus central
services

15 February 2024 59
Standards MX MX Messages and InterAct
General Information

Any other identification mechanism would force back-office applications and interfaces to bridge
the two different identification mechanisms through manual customisations, adding unnecessary
complexity and opposing agility towards change.
Therefore, Swift strongly recommends Publishing organisations to impose similar restrictions in
their usage guidelines.

Usage identifier
The usage identifier is currently implemented as an editable meta information of a usage guideline
specification in MyStandards. It is assigned and published with the Business Usage specification
on MyStandards to facilitate coordination across all these domains.
The concept is open: any financial institution is free to define and publish a usage identifier by its
own means.
To ensure uniqueness, the usage identifier must respect the following format:

swift a short name identifier of the usage guideline publishing organisation

cbprplus 1 or more context distinguishers separated by a dot

01 a 2-digit version numbe

The length of each element can vary up to maximum 10 characters.

The total length of the usage identifier must not exceed 35 characters.
Only lowercase alphanumerical characters are allowed.
The version must be fixed / increments whenever the usage guideline becomes effective and
evolves on a network.
Example
swift.cbprplus.01 used to designate CBPR+ market practice flavours of the pacs and camt
messages exchanged over FINplus.

15 February 2024 60
Standards MX MX Messages and FileAct
General Information

5 MX Messages and FileAct

SwiftNet uses dedicated XML structures in the header of the FileAct file transfer primitives to allow
customers to specify key parameters. This also allows the SwiftNet central systems or the
receiver's applications, or both to act upon them.

5.1 File Structure

A message sent using the FileAct messaging service is either referred to as a FileAct message or
a File.

SWIFTNet Headers
HeaderInfo

Payload

D0960020

Other (for example, security,...)

SwiftNet Headers Among others, SwiftNet headers include information elements that are
necessary to perform the file transfer (for example requestor, responder, or
service).

HeaderInfo The HeaderInfo is an optional XML element of the SwiftNet headers.

Payload The content of the file transfer.

Other Other elements such as message signature and verification information.

5.2 File Header

The FileAct HeaderInfo element may be structured according to several service profiles. The term
service profile describes the rules that apply in the context of a specific Swift Solution. This
includes the documentation and XML schemas used in the HeaderInfo XML structure.
The following common service profiles are available:
• Service profile 1 - Transaction Count
• Service profile 2 - Payment File Summary
Other service profiles specific to Swift Solutions are available. For more information, see the
relevant service description.

15 February 2024 61
Standards MX MX Messages and FileAct
General Information

5.2.1 Service Profile 1 - Transaction Count

Customer requirements
Customers implement this data structure when there is a need to identify only the number of items
(for example, payments) in a file. Swift can require this for example to benefit from a pricing per
transaction offered in some FileAct-based services.

Technical requirements
Applications that send files must obtain the number of transactions in each file and specify this in
the TotalNumberOfTransactions data element for each file.

Data elements
The following elements and characteristics are available in this service profile.

Element Cardinalit XML Tag Data type Description Comment

Name y

TotalNumberO [1..1] <TtlNbOfTxs> Max15 Total number of Swift also centrally

fTransactions Numeric Text individual uses this element to
transactions apply the pricing.
contained in the file

Example
<ApplSpcfc xmlns="urn:swift:xsd:ApplSpcfc.TxsCntr.01">
<TxsCntr>
<TtlNbOfTxs>12345678</TtlNbOfTxs>
</TxsCntr>
</ApplSpcfc>
Schema
<?xml version="1.0" encoding="UTF-8" ?>
<xs:schema xmlns="urn:swift:xsd:ApplSpcfc.TxsCntr.01" xmlns:xs="http://
www.w3.org/2001/XMLSchema" targetNamespace="urn:swift:xsd:ApplSpcfc.TxsCntr.01"
elementFormDefault="qualified">
<xs:element name="ApplSpcfc" type="ApplSpcfc" />
<xs:complexType name="ApplSpcfc">
<xs:sequence>
<xs:element name="TxsCntr"
type="FileTransferHeaderTransactionsCounter1" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="FileTransferHeaderTransactionsCounter1">
<xs:sequence>
<xs:element name="TtlNbOfTxs" type="Max15NumericText" />
</xs:sequence>
</xs:complexType>
<xs:simpleType name="Max15NumericText">
<xs:restriction base="xs:string">
<xs:pattern value="[0-9]{1,15}" />
</xs:restriction>
</xs:simpleType>
</xs:schema>

15 February 2024 62
Standards MX MX Messages and FileAct
General Information

5.2.2 Service Profile 2 - Payment File Summary

Customer requirement
This profile allows a third party to the file exchange to receive a copy, for information or for
authorisation, of information related to the business content and value of the file being transmitted.
The following scenarios are possible:
• the authorisation by the head office of disbursement files sent by subsidiaries (risk
management)
• the authorisation by corporate treasurer of a file of salary payments sent by its HR department
to the bank (confidential details not to be shared with treasury employees)
• the copy for information of the proceeds of the file for audit, tracking, or recovery purposes
The copied information needs to contain the main characteristics of the content of the file, including
for example file identification, amount, value date, or number of transactions.
Note If other elements are required in the context of some Swift Solutions or specific
situations, then the service administration will need to use (or create) a different
service profile.

Technical requirement
The information that need to be copied to the third party must be included in the FileAct HeaderInfo
element because the file content itself is not copied to a third party.
It is assumed that the business sender and receiver of the file are the requestor and responder
indicated in the FileAct file headers.

Business applications
The Payment File Summary service profile is available for use by communities exchanging low-
value payments.

Data elements
The following elements and characteristics are available in this service profile.

Element Name Cardinal XML Tag Data type Description Comment

ity

InterbankSettlem [1..1] <TtlIntrBkStt Currency Total amount of Total amount

entAmount lmAmt> and money transferred (arithmetic sum) of
Amount between instructing the Credit Transfers
agent and instructed (CT) or Direct Debit
agent. (DT) items, or both in
the file.
Payments files
exchanged between
the members are
exclusively single
currency.

TotalNumberOfTr [1..1] <TtlNbOfTxs> Max15 Total number of

ansactions Numeric individual
Text transactions
contained in the file.

15 February 2024 63
Standards MX MX Messages and FileAct
General Information

Element Name Cardinal XML Tag Data type Description Comment

ity

CreditDebitCode [1..1] <CdtDbtInd> CRDT or Specifies whether a This element

DBIT transaction is an specifies the amount
increase (credit) or a as being a debit
decrease (debit). amount or a credit
amount.

InterbankSettlem [1..1] <IntrBkSttlmD ISODate Date on which the Date on which the
entDate t> amount of money settlement takes
ceases to be place.
available to the agent
that owes it and
when the amount of
money becomes
available to the agent
to which it is due.

BankOperationTy [0..1] <BkOprTp> Max35Text Textual information or

This code can for
pe code indicating the example specify a
nature of the specific operation
instrument. type used in a given
community or in
Usage: the code may
between specific
only appear once,
partners (for
and is valid for the
example, SEPA
entire file. This
AOS).
optional element
allows senders to
further define the
nature of the
transactions by
means of a code.

FileIdentification [1..1] <FileId> Max35Text Point to point Reference of the file,

reference assigned which is assigned by
by the instructing the sender.
party and sent to the
Usage: the
next party in the
instructing party has
chain to
to make sure that
unambiguously
FileIdentification is
identify the file.
unique per instructed
party for a pre-
agreed period.

Service Level [0..1] <SvcLvl> Max35Text Proprietary

identification of a pre-
agreed level of
service between the
parties.

Example
<ApplSpcfc xmlns="urn:swift:xsd:ApplSpcfc.PmtSummry.01">
<PmtSummry>
<TtlIntrBkSttlmAmt Ccy="EUR">1912000.00</TtlIntrBkSttlmAmt>
<TtlNbOfTxs>12345678</TtlNbOfTxs>
<CdtDbtInd>CRDT</CdtDbtInd>
<IntrBkSttlmDt>2007-07-14</IntrBkSttlmDt>

15 February 2024 64
Standards MX MX Messages and FileAct
General Information

<FileId>6</FileId>
</PmtSummry>
</ApplSpcfc>
Schema
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns="urn:swift:xsd:ApplSpcfc.PmtSummry.02" xmlns:xs="http://
www.w3.org/2001/XMLSchema" targetNamespace="urn:swift:xsd:ApplSpcfc.PmtSummry.
02" elementFormDefault="qualified">
<xs:element name="ApplSpcfc" type="ApplSpcfc"/>
<xs:complexType name="ApplSpcfc">
<xs:sequence>
<xs:element name="PmtSummry"
type="FileTransferHeaderPaymentSummary2"/>
</xs:sequence>
</xs:complexType>
<xs:simpleType name="CreditDebitCode">
<xs:restriction base="xs:string">
<xs:enumeration value="CRDT"/>
<xs:enumeration value="DBIT"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="CurrencyAndAmount_SimpleType">
<xs:restriction base="xs:decimal">
<xs:minInclusive value="0"/>
<xs:fractionDigits value="5"/>
<xs:totalDigits value="18"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="CurrencyAndAmount">
<xs:simpleContent>
<xs:extension base="CurrencyAndAmount_SimpleType">
<xs:attribute name="Ccy" type="CurrencyCode" use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:simpleType name="CurrencyCode">
<xs:restriction base="xs:string">
<xs:pattern value="[A-Z]{3,3}"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="FileTransferHeaderPaymentSummary2">
<xs:sequence>
<xs:element name="TtlIntrBkSttlmAmt" type="CurrencyAndAmount"/>
<xs:element name="TtlNbOfTxs" type="Max15NumericText"/>
<xs:element name="CdtDbtInd" type="CreditDebitCode"/>
<xs:element name="IntrBkSttlmDt" type="ISODate"/>
<xs:element name="FileId" type="Max35Text"/>
<xs:element maxOccurs="1" minOccurs="0" name="BkOprTp"
type="Max35Text"/>
<xs:element maxOccurs="1" minOccurs="0" name="SvcLvl"
type="Max35Text"/>
</xs:sequence>
</xs:complexType>
<xs:simpleType name="ISODate">
<xs:restriction base="xs:date"/>
</xs:simpleType>
<xs:simpleType name="Max15NumericText">
<xs:restriction base="xs:string">
<xs:pattern value="[0-9]{1,15}"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="Max35Text">
<xs:restriction base="xs:string">
<xs:minLength value="1"/>
<xs:maxLength value="35"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>

15 February 2024 65
Standards MX Understanding the Documentation
General Information

6 Understanding the Documentation

Base Standards MX documentation
This chapter describes how to navigate around the Standards MX documentation. The diagrams
show extracts from the Payments Clearing and Settlement documentation. All the Standards MX
Message Definition Reports share the same structure, layout, and navigation methods.
The documentation set contains the following publications:
• the Message Definition Report Part 1
• the Message Definition Report Part 2 (not included with the Advance Information publication)
• the XML schemas (xsd files)
Note When available, Swift publishes the advance information documentation set around
the January time frame.

Additional specific usage guidelines available in MyStandards

MyStandards is the collaborative web platform for users of Swift MT, MX and ISO 20022 standards.
It provides easy access to publicly available base standards definitions and any usage guidelines
publishers have shared in the context of a specific service.

6.1 Standards MX Message Definition Report Part 1

The Standards MX Message Definition Report Part 1 contains the following sections:
• the scope and functionality of the messages contained in the document set
• the different messages contained in the document set
• the business roles and participants of the senders and receivers of the messages
• business processes covered by the message set
• business transactions (also known as sequence diagrams)
The document may also contain business examples, that is, a description of a scenario and the
XML message that would be sent.

15 February 2024 66
Standards MX Understanding the Documentation
General Information

6.2 Standards MX Message Definition Report Part 2

The Standards MX Message Definition Report Part 2 contains the following sections:
• Overview
• Messages
- Message Definition Functionality
- Structure
- Constraints
- Message Building Blocks
• Message Items Types
- Message Components
- Message Datatypes

6.3 Messages
Message definition functionality
This section describes message scope, structure, and content for each message. It also provides
relevant business examples.

15 February 2024 67
Standards MX Understanding the Documentation
General Information

Structure
This section describes the message structure and hierarchy.

Message structure options

Or Indicates whether the message element or building block is part of a choice. { indicates
the start of the choice. } indicates the end of the choice.

Message Element / Part of a message. It can be a message element or a building block. (A message
Building Block element can be compared to a field in a Swift Standards MT message.) Each message
element or building block is completed with a Type. Individual message items are
described in the Message Item Description section.

15 February 2024 68
Standards MX Understanding the Documentation
General Information

XML Tag Short reusable name for the message element which appears in the XML schemas and
XML instances.

Multiplicity Indicates whether a message element or building block is optional or mandatory and
how many times the element can be repeated. The multiplicity is shown in square
brackets.
For example:
• [0..1]
The element or block can be present either 0 times or 1 time. The element or block
is optional and not repeatable.
• [1..1]
The element or block must be present 1 time.
• [1..n]
The element or block must be present 1 time and can be repeated n times.

Type This resembles the Content or Option column in SwiftNet FIN format.
If the cell contains one of the data type representations, then the type consists of a data
type. This is the lowest level of type. The data type specifies the possible values that a
message element can have. This can be a format specification such as the date
format .-MM-DD, or an enumeration that lists all possible codes. A data type
representation can be an Identifier, Code, Text, Rate, DateTime, Amount, Quantity, or
Indicator.
If the cell is shaded grey, then the type consists of a message component. Message
components are composed of message elements. Message elements appear at the
next nesting level in the message element column.
If a cell contains a plus sign, then types consist of a frequently reused message
component such as PartyChoice. This message component is fully described in the
Message Items Types section.

Constraint Number Reference to the rule or the guideline in the rules section of the message
documentation.

Page Page number

Message Element/Building Block description

15 February 2024 69
Standards MX Understanding the Documentation
General Information

Message Element/Building Block options

Presence Indicates whether a message element or building block is optional or mandatory and how
many times the element can be repeated. The multiplicity is shown in square brackets.
For example:
• [0..1]
The element or block can be present either 0 times or 1 time. The element or block is
optional and not repeatable.
• [1..1]
The element or block must be present 1 time.
• [1..n]
The element or block must be present 1 time and can be repeated n times.

Definition Contains the definition of the message, message building block, or message element.

Usage When relevant, provides additional usage information about the message element or
building block.

Data Type Provides a link to a description of the datatype. This is turn, provides information about how
to complete the message element. The type can be either a data type or a message
component. Message components are composed of further message elements.

Constraints
This section lists all the rules applied to the message. Applicable rules are also repeated at the
level of the message building block.

Message building blocks and message elements

This section describes the message building blocks and message elements of the message
definition.

6.4 Message Item Types

Message components
This section describes, in detail, the message components. They are organised by the type of
information they define.

Message datatypes
This section describes the data types, such as amounts, code sets and dates. The data types are
classified by representation.

15 February 2024 70
Standards MX The Financial Glossary
General Information

7 The Financial Glossary

See http://www.iso20022.org/financial_repository.page.

15 February 2024 71
Standards MX Legal Notices
General Information

Legal Notices
Copyright
Swift © 2024. All rights reserved.

Restricted Distribution
Do not distribute this publication outside your organisation unless your subscription or order
expressly grants you that right, in which case ensure you comply with any other applicable
conditions.

Disclaimer
The information in this publication may change from time to time. You must always refer to the
latest available version.

Swift Standards Intellectual Property Rights (IPR) Policy - End-User License Agreement
Swift Standards are licensed subject to the terms and conditions of the Swift Standards IPR Policy
- End-User License Agreement, available at www.swift.com > About Us > Legal > IPR Policies >
Swift Standards IPR Policy.
Translations
The English version of Swift documentation is the only official and binding version.

Trademarks
Swift is the trade name of S.W.I.F.T. SC. The following are registered trademarks of Swift: 3SKey,
Innotribe, MyStandards, Sibos, Swift, SwiftNet, Swift Institute, the Standards Forum logo, the Swift
logo, Swift GPI with logo, the Swift GPI logo, and UETR. Other product, service, or company
names in this publication are trade names, trademarks, or registered trademarks of their respective
owners.

15 February 2024 72