ISO 20022 MasterClass January 2021

Masterclass
ISO 20022 and SWIFT MX

for Payments
<xml>ISO 20022</xml>
MVL Consulting Private Limited

Makarand Lonkar
Course learning objectives
• Overview of SWIFT Standards MX, CPBR+, HVPS+ and RTPG

• Adoption of ISO 20022
• Important fields/tags/elements of ISO 20022/MX messages
• XML schema, XML instances, schema validation and extended non schema validations
• How serial and cover payments are made using ISO 20022
• “R” messages in ISO 20022
• Exception and investigation management using ISO 20022
• ISO 20022 implementation by US and European payment systems
2
Agenda
• Module 01 : Introduction to XML for ISO 20022 XSD

• Module 02 : Introduction to SWIFT Standards MX
• Module 03 : Adoption of ISO 20022 for cross border payments
• Module 04 : Using ISO 20022 for domestic and cross border payments
3
Introduction to XML for ISO 20022 XSD
4
Module 1 : Introduction to XML for ISO 20022 XSD
• XML Basics : tags, elements and element types (sequence/choice), data types
(simple/complex), patterns
• External codes/bank transaction/proprietary codes and data source schemes
• Structure and format of ISO 20022 message
• Business Application Header and Document
• XML schema and XML instance
• Schema embedded codes and external codes
• XML schema validation, non-schema extended validation
5
About XML
6
What is XML?
• XML stands for Extensible Markup Language and is a text-based markup language derived
from Standard Generalized Markup Language (SGML).
• Extensible Markup Language (XML) is a markup language that defines a set of rules for
encoding documents in a format that is both human-readable and machine-readable. The
World Wide Web Consortium's XML 1.0 Specification of 1998 and several other related
specifications—all of them free open standards—define XML.
• XML stores data in plain text format and it is platform independent.
• 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.
• SWIFT uses eXtensible Markup Language (XML) to represent its Standards MX messages
(MXs).
7
Characteristics of XML
• There are three important characteristics of XML that make it useful in a variety of systems
and solutions −
– XML is extensible − XML allows you to create your own self-descriptive tags, or
language, that suits your application.
– XML carries the data, does not present it − XML allows you to store the data
irrespective of how it will be presented.
– XML is a public standard − XML was developed by an organization called the World
Wide Web Consortium (W3C) and is available as an open standard.
• XML is a markup language that defines set of rules for encoding documents in a format that
is both human-readable and machine-readable.
• Markup is information added to a document that enhances its meaning in certain ways, in
that it identifies the parts and how they relate to each other. More specifically, a markup
language is a set of symbols that can be placed in the text of a document to demarcate and
label the parts of that document.
8
XML tags
XML Tags
– An XML file is structured by several XML-elements, also called XML-nodes or XML-tags.
– XML tags define the meaning and the structure of the data they enclose.
• A tag always starts with a left angle bracket “<“ and ends with a right angle bracket “>”
• Example : <FinInstnId>
• XML tags are used in nested pairs, with matching start-tags and end-tags that enclose
pieces of data.
• Example <StrtNm>OxfordStreet</StrtNm>
• 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.
9
XML tag syntax rules
• XML tags have to follow a certain

syntax rules.
• Additionally an XML tag in MX
follows these syntax rules.
10
XML tag syntax rules
• XML tags have to follow a certain

syntax rules.
• Additionally an XML tag in MX
follows these syntax rules.
11
XML elements
• Elements
– An XML instance or document
contains data in elements and
nested elements corresponding to
the hierarchy imposed by the XML Parent <CustomerAddress>
element
schema.
<Address category = “Office”>
– An XML element includes <Country>India</Country>
everything from the start <TAG> to Child <City>Bombay</City>
element
end </TAG>. </Address>
<Address category = “Home”>
– An XML element can contain text,
Child <Country>India</Country>
attributes, other elements or a mix element <City>Bombay</City>
of these. </Address>
– Nested element, parent element
</CustomerAddress>
and child element
12
XML elements
• Elements
– An XML instance or document
contains data in elements and
nested elements corresponding to
the hierarchy imposed by the XML When an element appears <CustomerAddress>
within another element, it is
schema. said that the inner element
is “nested”.
<Address category = “Office”>
– An XML element includes <Country>India</Country>
In this example, the
everything from the start <TAG> to elements <Country> and
<City>Bombay</City>
end </TAG>. <City> are nested. </Address>
<Address category = “Home”>
– An XML element can contain text, <Address> is the parent
element and <Country> and <Country>India</Country>
attributes, other elements or a mix <City> are child elements.
<City>Bombay</City>
of these. </Address>
– Nested element, parent element
</CustomerAddress>
and child element
13
XML element types
• XML Element Types

– All message elements have a type. The XML
schema describes the XML types.
– Types can be either simple or complex.
• Simple XML element
– An element of simple type can contain only text.
It cannot contain any other elements or
attributes.
– The text can be of many different types. It can be
one of the types included in the XML Schema
definition (boolean, string, date, etc.), or it can be
a custom type that you can define yourself.
• Complex XML element
– A complex element is an XML element that
contains other elements and/or attributes.
14
MX elements : Sequence or Choice
• The Standards MX-defined

complex types use
following schema features:
• The XML sequence
element specifies that the
child elements must occur
in sequence.
• The XML Choice element
allows only one of the
elements in the <choice>
declaration to be present
15
MX elements : Sequence or Choice
• The Standards MX-defined

complex types use
following schema features:
• The XML sequence
element specifies that the
child elements must occur
in sequence.
• The XML Choice element
allows only one of the
elements in the <choice>
declaration to be present
16
XML patterns
• Pattern
– Defines the exact sequence of characters identified by the pattern that are acceptable.
• Examples
• [A-Za-z]{9,9} : Exactly 9 letters (characters between A and Z or a and z)
• [0-9]{0,2} : Between 0 and 2 numbers (characters between 0 and 9)
• [A-Z]{2,2}|[0-9]{2,2} : Exactly two capital letters or exactly two numbers
• [A-Z]{6,6}([0-9]{3,3}){0,1} : Six capital letters followed by 3 optional numbers (either the 3
numbers are present, either none)
17
XML patterns
• Pattern
– Defines the exact sequence of characters identified by the pattern that are acceptable.
• Examples
• [A-Za-z]{9,9} : Exactly 9 letters (characters between A and Z or a and z)
• [0-9]{0,2} : Between 0 and 2 numbers (characters between 0 and 9)
• [A-Z]{2,2}|[0-9]{2,2} : Exactly two capital letters or exactly two numbers
• [A-Z]{6,6}([0-9]{3,3}){0,1} : Six capital letters followed by 3 optional numbers (either the 3
numbers are present, either none)
18
Restrictions
• Restrictions are used to define

acceptable values for XML elements or
attributes.
• Restrictions on XML elements are

called facets.
19
Restrictions
• Restrictions are used to define

acceptable values for XML elements or
attributes.
• Restrictions on XML elements are

called facets.
20
XML schema
21
XML message representation
Sample Tree Structure

– Root
• Parent
– Child1
– Child2
– Child n….
XML Representation
– <Root>
• <Parent>
– <Child1>content</Child1>
– <Child2>content</Child2>
– <Childn>content</Childn>
• </Parent>
– </Root>
22
XML schema
• XML Schema is commonly known as XML Schema Definition (XSD). It is used to describe and
validate the structure and the content of XML data. XML schema defines the elements, attributes
and data types.
• XML “schemas” describe the permitted structure of an XML document (or message).
• The schema has an “XSD” file extension and not an “XML” extension; though the schema itself is in
fact an XML file. XML schemas define, among other things, which elements are allowed in the
document, the order in which they should appear, which are mandatory and which are optional, as
well as information on data formats (field lengths, codes, character sets).
• A software tool can validate the XML file against the specified XSD schema to check whether a
message conforms to its definition and can reduce the risk of sending or receiving incorrect data.
23
XML Schema and instance
• 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.
• MX message tree structure
– SWIFT Standards documentation represents MX schema
content, properties, and hierarchy as a structure called
the message tree structure.
24
XML Schema and instance
• 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.
• MX message tree structure
– SWIFT Standards documentation represents MX schema
content, properties, and hierarchy as a structure called
the message tree structure.
25
MX Message
• All data transmitted in XML ISO2022 messages are organised in components and elements.
• A message component is a collection of related data elements. Both component and element is
identified by an opening and closing tags.
• The combination of opening and closing tags with the data is called an element.
• Company “Oracle”, postal address “Nirlon Compound, 123, Mumbai, India,” is expressed in
ISO 20022 XML as follows:
<Nm>Oracle</Nm>
<PstlAdr>
<StrtNm>NIRLON COMPOUND</StrtNm>
<BldgNb>123</BldgNb>
<TwnNm>Mumbai</TwnNm>
<Ctry>IN</Ctry>
</PstlAdr>
26
MX Message
• All data transmitted in XML ISO2022 messages are organised in components and elements.
• A message component is a collection of related data elements. Both component and element is
identified by an opening and closing tags.
• The combination of opening and closing tags with the data is called an element.
• Company “Oracle”, postal address “Nirlon Compound, 123, Mumbai, India,” is expressed in
ISO 20022 XML as follows:
<Nm>Oracle</Nm>
<PstlAdr>
<StrtNm>NIRLON COMPOUND</StrtNm>
<BldgNb>123</BldgNb>
<TwnNm>Mumbai</TwnNm>
<Ctry>IN</Ctry>
</PstlAdr>
27
Complete MX message
InterAct
28
XML prolog and xml namespace
• XML prolog
– The first line of an xml document
or message defines the XML
version and character
encoding. It’s optional.
• XML target namespace
– An XML namespace is the
container that sets the context for
the XML elements and XML
attributes that it qualifies.
– Namespaces are used to group
elements and attributes that relate
to each other in some special
way.
29
XML prolog and xml namespace
• XML prolog
– The first line of an xml document
or message defines the XML
version and character
encoding. It’s optional.
• XML target namespace
– An XML namespace is the
container that sets the context for
the XML elements and XML
attributes that it qualifies.
– Namespaces are used to group
elements and attributes that relate
to each other in some special
way.
30
Schema validation
31
Well formed and valid XML document
• XML Schema Definition, commonly known as XSD, is a way to describe precisely the XML
language. XSD checks the validity of structure and vocabulary of an XML document against
the grammatical rules of the appropriate XML language.
• An XML document can be defined as −
– Well-formed − If the XML document adheres to all the general XML rules such as tags
must be properly nested, opening and closing tags must be balanced, and empty tags
must end with '/>', then it is called as well-formed.
– and
– Valid − An XML document said to be valid when it is not only well-formed, but it also
conforms to available XSD that specifies which tags it uses, what attributes those tags
can contain, and which tags can occur inside other tags, among other properties.
32
SWIFT Standards MX : XML Schema Validation
• Schema validation
• Schema validation is performed in the following two parts:
– the MX instance is well-formed XML. An XML instance or XML document with correct
syntax is called a well-formed XML.
– the MX instance is valid. An instance validated against its corresponding schema is
called a valid XML instance.
33
XML Non- Schema Validation
• Non-Schema 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, Country Code or Currency Code.
34

35

36
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.
37
Codes in ISO 20022 / SWIFT Standards MX
38
External codes
• Many ISO 20022 message use data elements represented by codes, such codes are often
externalised from the message itself.
• The external code sets which are validated and approved by the SEGs. The code sets are
maintained on a quarterly basis.
• Unlike other ISO 20022 code sets, the external codes are not included in the message
schema with the message element.
• 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.
39
External Codes list : Types
• The code sets are published in two sets of documents:

– the External code Sets and
– the Bank Transaction Code Combinations.
40
Data Source Scheme (DSS) and Proprietary Codes
• A Data Source Scheme (DSS) is a mechanism which allows an industry body to specify the
use a proprietary code set that is not owned nor managed by ISO 20022, and that replaces a
standard code set (either a specific ISO 20022 managed code set or another ISO standard
code set, e.g. BICs or ISINs) in specific ISO 20022 Message Components, where the use of
such DSS has been approved.
• The DSS consists of the following parts:
– a mandatory 'data source issuer' which identifies the institution or organization issuing the
proprietary code set,
– an optional 'data source scheme name' which identifies the code set in case a data source
issuer issues more than one code set for the same business purpose, e.g., two code schemes for
identification of parties, and the actual proprietary code value.
• Proprietary Codes may also be available for certain data elements, these are typically
inherited from legacy formats and require definitions in user documentation as these are not
captured in the baseline ISO 20022 standard.
41
Data Source Scheme (DSS) and Proprietary Codes
• A Data Source Scheme (DSS) is a mechanism which allows an industry body to specify the
use a proprietary code set that is not owned nor managed by ISO 20022, and that replaces a
standard code set (either a specific ISO 20022 managed code set or another ISO standard
code set, e.g. BICs or ISINs) in specific ISO 20022 Message Components, where the use of
such DSS has been approved.
• The DSS consists of the following parts:
– a mandatory 'data source issuer' which identifies the institution or organization issuing the
proprietary code set,
– an optional 'data source scheme name' which identifies the code set in case a data source
issuer issues more than one code set for the same business purpose, e.g., two code schemes for
identification of parties, and the actual proprietary code value.
• Proprietary Codes may also be available for certain data elements, these are typically
inherited from legacy formats and require definitions in user documentation as these are not
captured in the baseline ISO 20022 standard.
42
Data type : Point to Point and End to End
• Point to Point
– Point-to-point refers to data passed within a message from one party to the next. This
data will not necessarily be passed in subsequent messages.
– For example: the Instruction Identification element contains a reference meaningful to
the party sending a message, subsequent messages in a payment transaction chain can
expect the Instruction Identificationto be replaced by a reference meaningful to the party
sending that message leg.
• End to End
– End-to-end refers to data passed throughout the transaction life cycle i.e. within a
message from one party to the next, and continued in subsequent messages.
– For example: the UETR element contains a Unique End-to-end Transaction Reference
in accordance to the UUID version 4 standards. This same reference is used in all
messages related to the payment transaction.
43
Examples of important codes in
SWIFT Standards MX for payments
Settlement Method
Embedded code
44
Examples of important codes in
SWIFT Standards MX for payments
Settlement Method
Embedded code
45
Error Codes
• Generic error codes

• The errors that are produced during XML schema validation generate and display generic
error codes.
• MX or message component-specific errors
• Errors due to incorrect usage of the message component.
46
Character sets
47
SWIFT Standards MX-Supported Character Sets
ISO 10646 : Unicode Transformation Format UTF-8
• 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 agreed.
• 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.
48
MX character set for CBPR +
• All SWIFT ISO MX message elements (fields) which are defined (by data Type) as text are
restricted to FIN X Character set.
• The character set is as follows:
– abcdefghijklmnopqrstuvwxyz
– ABCDEFGHIJKLMNOPQRSTUVWXYZ
– 0123456789
– /-?:().,'+
– CrLf Space
• Special characters are additionally allowed in: (a) All party (agents and non-agents) Name and
Address elements (b) The Related Remittance Information elements (c) The Remittance
Information (structured & unstructured) elements : !#&%*=^_’{|}~";@[\]
• Additionally special characters $ and > < signs are enabled for the Email Address elements.
• Translation of any special character: !#&%*=^_’{|}~";@[\]$ >< into MT messages will be
represented by a . (Full Stop)
49
Introduction to SWIFT Standards MX
50
Module 2 : Introduction SWIFT Standards MX
• What is Standards MX
• Payments Group e.g. CBPR+, HVPS+, RTPG
• Introduction to SWIFTNet InterAct, FileAct, FINplus and SWIFT Instant
• Structure and format of MX message
• Business Application Header and Document
• MX message with SWIFTNet InterAct/SWIFTNet FileAct, FINplus
51
Standard MX concepts
• Standard MX is a financial messaging standard.

• Most MX messages are designed according to the ISO 20022
ISO 20022 methodology and are ISO registered. Registered
Messages
• Other MX messages are designed following the
ISO 20022 methodology but are NOT ISO
registered. For instance messages which are
used for SWIFT proprietary services or those used Non
in specific markets. registered
ISO 20022
• All MX messages are represented in
Messages
eXtensible Markup Language (XML).
52
Standard MX concepts
• Standard MX is a financial messaging standard.

• Most MX messages are designed according to the ISO 20022
ISO 20022 methodology and are ISO registered. Registered
Messages
• Other MX messages are designed following the
ISO 20022 methodology but are NOT ISO
registered. For instance messages which are
used for SWIFT proprietary services or those used Non
in specific markets. registered
ISO 20022
• All MX messages are represented in
Messages
eXtensible Markup Language (XML).
53
SWIFT and Payment Groups
54
Market Practice and Usage Guidelines
• ISO 20022 message definitions are often complex, to adapt to a variety of use cases. For
example, the ISO 20022 pacs.008 Customer Credit Transfer may be used for domestic batch
payments, instant payments, high value payments and international payments.
• For each scenario it is necessary to define a set of market practice rules and usage
guidelines that define how the message is to be used and interpreted. Without such rules to
constrain and define the use of the standard, efficient interoperability between market
participants cannot be achieved.
• The SWIFT messaging platform for ISO 20022 provides validation services that can
check adherence to the base standard, and to usage guidelines. Different guidelines can
be provisioned for a given message in different business contexts, so it is possible to ensure,
for example, that all messages used for cross-border/international payments conform to
agreed market practice for that use-case, and that messages that include Chinese
characters are only sent to receivers with the declared ability to process them.
55
Payment Group Guidelines
• Cross Border Payments and Reporting Plus (CBPR+) working group

– In 2021 SWIFT will begin migrating all cross-border and many-to-many payments onto ISO 20022.
– In tandem with the Payments Market Practice Group (PMPG), SWIFT has created the Cross-Border Payments
and Reporting Plus (CBPR+) working group to develop global usage guidelines.
• High Value Payment Systems Plus (HVPS+) working group

– SWIFT, along with major global banks and market infrastructures formed the HVPS+ market practice task force.
– Since August 2016, the HVPS+ task force has worked with the industry to define and refine global
implementation standards and to ensure that the industry realises quantifiable benefits in terms of automation,
increased transparency and richer payments data.
• Real Time Payments Group

– The ISO 20022 Real-Time Payments Group (RTPG) was created with the objective of bringing the international
community of users together to focus on market practice.
– It will deliver an initial set of message usage guidelines for the creation of a Global Market Practice for ISO
20022 in a retail real-time system; it will then establish a consolidated view of local market practices. It will
remain neutral to implementation, system design and use cases as per community decision
56
Comparative example : ISO 20022 and CBPR+
57
Common Global Implementation (CGI) Market
Practice (MP) Group
• The Common Global Implementation (CGI) initiative aims to simplify

various payment related corporate-to-bank implementations by
promoting the wider acceptance of ISO 20022 XML.
• The initiative provides a forum for banks, bank associations,
corporates, corporate associations, vendors and market infrastructures.
• The CGI group works to achieve its goals through consultation,
collaboration and agreement on common implementation templates for
various ISO 20022 financial messages. By publishing and promoting
these messages, the group aims to attain their widespread recognition
and adoption.
• It focuses on the general message structure and successful creation of
individual transactions that can be executed by participating banks.
• A corporate can use the same message structure for all their payments
with all of their transaction banks reaching any payment system across
the globe.
58
Summary of ISO 20022
Domestic Regional Cross border
High value Bulk Instant
Fedwire CHIPS TARGET2 Others… RTP NPP RT1 Others…
CBPR+ HVPS+ RTPG
ISO 20022
As ISO 20022 implementations proliferate, the variability in the ways in which the standard is deployed, in
terms of message versions, market practice rules and release cycles, threatens to undermine its value as
a means to reduce industry cost and operational risk and enable interoperability.
59
SWIFT connectivity for MX messaging
60
SWIFTNet InterAct and SWIFTNet FileAct
• Currently, the banks use SWIFTNet InterAct and SWIFTNet FileAct to create and send MX
messages to CSM.
• A InterAct exchange consists of a InterAct request followed by a InterAct response.
• A FileAct exchange consists of a FileAct negotiation request and response, automatically followed
by the transfer of the file content.
61
62
63
SWIFTNet FINplus
64
Shift from FIN to InterAct / FINPlus
• There will be a migration from FIN

messaging service used for Standards
MT to InterAct messaging service for
Standards MX messages.
• SWIFT will create a general access
SWIFTNet InterAct Store-and-Forward
service for ISO 20022 that will be
available on an opt-in basis.
• The new FINplus messaging service will
start at the end of 2022.
• All users will be automatically enrolled in
time for the start of migration in
November, 2021.
65
More on FINplus
• FINplus will enable its users to exchange a large span of ISO 20022 request types, including
payment and securities market financial messages:
– In the scope of the ISO 20022 adoption, FINplus will enable the exchange of payment messages
compliant with the Cross-Border Payments and Reporting Plus (CBPR+) market practices.
– FINplus supports the exchange of ISO 20022 Universal Confirmation messages to and from
the GPI platform.
– FINplus enables the exchange of a broad span of Securities transactions related messages,
including Corporate Actions, Securities Settlement Instructions, and Collateral Management. For
Securities messages, the FINplus service will support the exchange of messages which comply
with the plain ISO 20022 format or with specific usage guidelines.
• Proposed time lines:
– November 2021: Universal Confirmation messages and Securities S&R-CA messages
– November 2022: Cross-Border Payments and Reporting Plus (CBPR+) messages
• Most of the messages in each of the phases will require the RMA relationship to be set up.
Structure and format of MX messages
67
ISO 20022 / MX Message Identifier
• Current syntax is as following: xxxx.nnn.aaa.bb

– xxxx is an alphabetic code (4!a) in four positions (fixed length) identifying the Business
Process,
– nnn is an alphanumeric code (3!c) in three positions (fixed length) identifying the
Message Functionality,
– aaa is a numeric code (3!n) in three positions (fixed length) identifying a particular variant
of Message Functionality,
– bb is a numeric code (2!n) in two positions (fixed length) identifying the version. The
version number is always incriminated starting from version 01.
• Consider the example:
pacs.008.001.08
– pacs refers to ‘Payment Clearing And Settlement’ – Business area
– 008 refers to ‘FItoFICustomerCreditTransfer’ – Market practice
– 001 refers to the variant – Market process
– 08 refers to the version message format, in this case version 8 of
‘FItoFICustomerCreditTransfer’ type
68
ISO 20022 / MX Message Identifier
• Current syntax is as following: xxxx.nnn.aaa.bb

– xxxx is an alphabetic code (4!a) in four positions (fixed length) identifying the Business
Process,
– nnn is an alphanumeric code (3!c) in three positions (fixed length) identifying the
Message Functionality,
– aaa is a numeric code (3!n) in three positions (fixed length) identifying a particular variant
of Message Functionality,
– bb is a numeric code (2!n) in two positions (fixed length) identifying the version. The
version number is always incriminated starting from version 01.
• Consider the example:
pacs.008.001.08
– pacs refers to ‘Payment Clearing And Settlement’ – Business area
– 008 refers to ‘FItoFICustomerCreditTransfer’ – Market practice
– 001 refers to the variant – Market process
– 08 refers to the version message format, in this case version 8 of
‘FItoFICustomerCreditTransfer’ type
69
SWIFTNet InterAct MX message structure
70
Message Headers
71
Message headers
• Applications use headers to manipulate messages. A header enables an application to

process messages regardless of their content.
• 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 two types of headers but only one is used in a message at any one time:
– The business application header which is ISO 20022 approved
– application header
72
Distinguished Name (DN) based addressing
• SWIFTNet uses addressing DNs to deliver the message to the appropriate SWIFTNet Link.
• Distinguished Name is the logical address of the user.
• Distinguished Names are segmented, with a hierarchical tree structure that is read from right
to left.
73
Distinguished Name (DN) based addressing
• SWIFTNet uses addressing DNs to deliver the message to the appropriate SWIFTNet Link.
• Distinguished Name is the logical address of the user.
• Distinguished Names are segmented, with a hierarchical tree structure that is read from right
to left.
4 3 2 1
74
Application header mapping with MT
75
Mandatory adoption of MX for cross border
payments
77
Module 3 : Mandatory adoption of MX for cross
border payments
• Adoption timelines and major milestones
• Cross Border Payments and Reporting Plus (CBPR+)
• Exception from migration
78
Migration timeline for cross-border payments
79
Adoption of ISO 20022 for cross border
payments
80
Phases of migration from MT to ISO 20022 for cross
border payments
• Cross-border payments and cash reporting messages using SWIFT MT category 1, 2 and 9
messages will be continue to be used after November 2021.
• From the end of 2022 users will have the option to send and receive MT or ISO 20022. ISO 20022
users will also have the choice of FINplus messaging service or APIs.
• From the end of 2022 the MT standard will be supported for backward compatibility purposes only.
New developments will be based on ISO 20022 data only, and will require institutions to implement
structured data capabilities using ISO 20022.
• MT category 1, 2 and 9 for cross-border payments and cash reporting will be deprecated by
November 2025 and CBPR+ ISO 20022 specifications will only be supported.
81
Co-existence phase, transaction
management platform and translation
82
Transaction management platform
• SWIFT has planned to provide a transaction

management platform (TMP) with new
transaction management capabilities which
will enable the users to send and receive ISO
20022 or MT messages.
• It will also have the capability to retrieve ISO
20022 payment transaction data and
consume new services over APIs.
• This will help the users to interact with the
TMP using the format using the format which
they are capable of using.
• SWIFT will provide a roadmap of features
and timelines for testing and go-live in the
2nd half of 2020.
83
Message translation services
• SWIFT will provide a central translation service to ensure community interoperability during
the transition phase.
• The service will be available in-flow (from ISO 20022 to MT only), on-demand via an API
call from bank interface or middleware, and/or as deployed software on bank
premises.
• All three services implement the rules formulated by the CBPR+ market practice group - only
the on-premises package enables the banks to enrich or customise these rules.
• It should be noted that this is under review and may undergo a change later.
84
MT-MX Translation – Points to Note
• In case of any dispute, which message to relied upon, MT or MX?

– MX message would be relied upon – since MX is the signed message.
• In case of in-flow translation, how to control that the same message is not processed
twice?
– The translation (MT) will be marked in the header to indicate that it is a translation and
routed to a back-office system.
– The original (MX) will be safe-stored in the interface and by default automatically
completed to avoid that the same transaction is processed twice.
– Further, original and translation will be linked to each other.
• Can users develop their translation application by themselves?
– Users can develop a translation function themselves or leverage any third party vendor
approved by SWIFT.
85
Issues in Translation process
• To facilitate migration, SWIFT will provide a translation capability for MT to ISO 20022 and
ISO 20022 to MT.
• In general, ISO 20022 messages when used in a full implementation provide more, and more
granular, data structures than their MT equivalents, and there is therefore a risk that some
data will be dropped or truncated in translation from ISO 20022 to MT.
• Full features of ISO20022 can not be exploited:
– It is necessary to constrain ISO 20022 to a like-for-like MT-compatible implementation
where data elements that cannot be found in the equivalent MT are excluded. This
guarantees ‘translatability’ of the ISO 20022 message, but brings the serious
disadvantage that during any coexistence period none of the added value of ISO 20022
can be exploited.
• Imperfect translation may not give complete instruction:
– The translation from ISO 20022 to MT may be inherently imperfect, and therefore an ISO
20022 message may be delivered alongside the MT to represent the definitive record of
86
the instruction.
Truncation/non-mapped elements/Enrichment
• Sometimes, elements in input message can be populated with longer information than the
format specifications allow on target message.
• All the target data that exceeds the maximum field length allowed by the format specification
will be truncated by a sign "+" as last character at the end of the line to indicate that the value
intended to be mapped on the field was too long and will be displayed partially.
• Sometimes, elements in the input might not be mapped due to non-equivalence in the target
message, hence some input data might not be mapped to the target message.
• Enrichment
• New elements in target messages can sometimes have no input equivalence due to the fact
that the input is less rich or that a rule is not triggered. All the target data that is mandatory
and has no equivalent will be filled with a generic value based on the element type, such as
"NOTPROVIDED".
• The result of the mapping might be a technical valid message but not a business valid
message due to missing elements.
87
Impact on ISO 20022 users
• Caution
– Usage of ISO 20022 is not identical across the world, e.g. US
RTP.
– Some of the payment message types are not implemented by
some of the payment systems e.g. SEPA STEP2 usage of E&I
messages.
– For text elements this allows non-Latin characters such as
Chinese or Cyrillic to be used. However, many actors globally will
be unable to read or process non-Latin data, so use of these
capabilities will need to be on a restricted, opt-in basis.
– Cross-border payment flows may originate or terminate in high
value payment systems, so to guarantee end-to-end data
consistency the users will have to ensure that cross-
border/international usage of ISO 20022 is compatible with HVPS.
88
Issues for MT users during coexistence period
• For MT users, data may be dropped between the ISO 20022 message received and the MT
back-office. This risk is mitigated by the existence of clearly defined community translation
rules, which will highlight any data elements that cannot be copied to the MT format, and by
the delivery of the full message, which can be processed manually, by ancillary systems or
by cloud-based services;
• In many jurisdictions, intermediaries are required to pass on all the payment details (FATF
recommendations 15 and 16) they receive. MT users that act as intermediaries in the
payments domain could face difficulties in this respect.
89
Using MX for domestic and cross border
payments
90
Module 4 : Using MX for domestic and cross border
payments
• Understanding mapping of MT 1XX , MT2XX and MT 9XX to MX for payments

• Introduction to pain, pacs, camt and other applicable messages for payments in MX series
• Important message elements/tags of pain.001/002, pacs.008/009/002/004, camt.054/053.
• Use of MX in high value payment systems (e.g. RBI RTGS), small value real time payment systems
(e.g. US RTP) and bulk payment systems (using files e.g. STEP 2 SCT/SDD)
• End to end push transaction flow using MX
– Serial method of payment
– Cover method of payment
• End to end pull transaction flow using MX
• End to end collaborative flow using MX
• Important “R” e.g. Reject/Return messages in ISO 20022
• Exception and investigation management in MX
91
Message sets for payments domain
• The ISO 20022 message catalogue hierarchically begins with

business domain containing various sets of message definitions
which in turn contain a variety of message sets.
• actm : Account Management

• auth : Authorities
• camt : Cash Management
• pacs : Payment Clearing and Settlement
• pain : Payment Initiation
• remt : Remittance Advice
92
Terminology comparison : MT to ISO 20022
Message Specification Parties in the Message

Components ISO
MT
20022
Data
Format Bank Agent
Type
Field Element Ordering

Debtor
Customer
Presence Min Max Beneficiary

Creditor
Customer
Qualifier Code Message Instructing

Sender Agent
Textual Message Instructed

Usage Rule
Rule Receiver Agent
Cross
Network
Element
Validated Rule 93
Rule
ISO 20022 / MX message types for payments
94
95
96
97
98
99
100
101
Summary : Payments important messages
• pain : payment initiation

• pacs: payment clearing and settlement
• camt : cash management
102
Using ISO20022 messages in payment
processing
103
Understanding pacs.008
104
• pacs.008: The Financial Institution To

Financial Institution Customer Credit
Transfer message is sent by the Debtor
Agent to the Creditor Agent, directly or
through other agents and/or a payment
clearing and settlement system. It is used
to move funds from a Debtor account to a
Creditor.
• pacs.008 has two major core elements:
105
pacs.008 : serial method
Creditor
Debtor
A B C D E
pain.001
pacs.008
pain.002
pacs.008
pacs.002
pacs.008
pacs.002
pacs.008
pacs.002
camt.054
pacs.002
• pacs.008: The Financial Institution To Financial Institution Customer Credit Transfer message is sent by the Debtor Agent
to the Creditor Agent, directly or through other agents and/or a payment clearing and settlement system. It is used to
move funds from a Debtor account to a Creditor.
106
pacs.008 : cover method
2a. pacs.008
2b. pacs.002
Creditor
Debtor
A E
1a. pain.001 CSM
1b. pain.002
B C D
1c. camt.054 2c. pacs.009 COV
3a. pacs.009 COV

8. camt.053 2d. pacs.002
3b. pacs.002
4a. pacs.009 COV
2e. camt.054
5. camt.054
4b. pacs.002 6.camt.054
7. camt.053
7. camt.053
8.camt.054
107
Settlement method
• The pacs.008 introduces the SettlementMethod element within the GroupHeader

SettlementInformation, whereby the InstructingAgent (sender of the pacs message)
includes one of the following imbedded codes to indicate how the payment will be settled:
• INDA : ‘Instructed Agent’
• INGA: ‘Instructing Agent’
• COVE : ‘Cover Payment’
• CLRG : ‘Clearing’
• CLRG is not part of CBPR+ specifications but instead used in Market Infrastructure
specification (HVPS+)
• Settlement Method INDA or INGA implies the Instructing Agent has a Nostro/Vostro account
relationship
108
Settlement method
• The pacs.008 introduces the SettlementMethod element within the GroupHeader

SettlementInformation, whereby the InstructingAgent (sender of the pacs message)
includes one of the following imbedded codes to indicate how the payment will be settled:
• INDA : ‘Instructed Agent’
• INGA: ‘Instructing Agent’
• COVE : ‘Cover Payment’
• CLRG : ‘Clearing’
• CLRG is not part of CBPR+ specifications but instead used in Market Infrastructure
specification (HVPS+)
• Settlement Method INDA or INGA implies the Instructing Agent has a Nostro/Vostro account
relationship
109
Reimbursement agents
• The Instructing Reimbursement Agent captures the Agent who will execute a covering
payment (i.e.pacs.009 COV or domestic equivalent) often referred to as the currency
correspondent. This optional element is comparable with the Field 53a “Sender’s
Correspondent” in the legacy FIN message.
• The Instructed Reimbursement Agent captures the Agent who will receive the covering
payment (i.e.pacs.009 COV or domestic equivalent) and credit the account of the pacs.008
FItoFICustomerCreditTransfer Instructed Agent. This optional element is comparable with
the Field 54a “Receiver’s Correspondent” in the legacy FIN message.
• The Third Reimbursement Agent captures an additional Agent who will receive the
covering payment, where this is not the Agent detailed in the Instructed Reimbursement
Agent. This optional element is comparable with the Field 55a in the legacy FIN message.
110
Credit Transfer Transaction Information
111
Major data elements in pacs.008
• Payment identification
• Payment type information
• Currency and amount
• Charge bearer
112
Payment identification
113
Payment identification in pacs.008
• Instruction identification is a point to point reference (MT Field 20) CBPR+ (1..1)
• End-to end reference provided by the Debtor which must be passed unchanged throughout the payment and reported
to the Creditor. CBPR+ (1..1)
• Transaction identification: an end to end reference assigned by the first instructing agent to identify the transaction.
CBPR+ (0..1)
• Unique-End-To-End Transaction Reference Number : may be created by debtor in their payment initiation request
and included in reporting messages. CBPR+ (1..1)
• Clearing system reference : a point to point reference assigned by the market infrastructure. CBPR+ (0..1)
114
Payment type information
115
Payment type information in pacs.008
• InstructionPriority <InstrPrty> : Indicator of the

urgency or order of importance that the instructing
party would like the instructed party to apply to the
processing of the instruction. CBPR+ (0..1)
• ClearingChannel <ClrChanl> Specifies the clearing
channel to be used to process the payment instruction.
CBPR+ (0..1)
• ServiceLevel <SvcLvl> Agreement under which or
rules under which the transaction should be
processed. E.g. G001 gpi tracked customer credit
transfer. CBPR+ (0..3)
• LocalInstrument <LclInstrm> User community
specific instrument e.g. 0002 standing order. CBPR+
(0..1)
• CategoryPurpose <CtgyPurp> Specifies the high
level purpose of the instruction based on a set of pre-
defined categories. E.g. DIVD dividend payment
CBPR+ (0..1)
116
Currency and amount
117
Currency and amount
• InterbankSettlementAmount
<IntrBkSttlmAmt> Amount of money
moved between the instructing agent and
the instructed agent. CBPR+ (1..1)
• InstructedAmount <InstdAmt> Amount
of money to be moved between the debtor
and creditor, before deduction of charges,
expressed in the currency as ordered by
the initiating party. CBPR+ (0..1)
• SettlementPriority <SttlmPrty> Indicator
of the urgency or order of importance that
the instructing party would like the
instructed party to apply to the processing
of the settlement instruction. CBPR+ (0..1)
• SettlementTimeRequest <SttlmTmReq>
Provides information on the requested
settlement time(s) of the payment
instruction. CBPR+ (0..1)
118
Currency and amount
• InterbankSettlementAmount
<IntrBkSttlmAmt> Amount of money
moved between the instructing agent and
the instructed agent. CBPR+ (1..1)
• InstructedAmount <InstdAmt> Amount
of money to be moved between the debtor
and creditor, before deduction of charges,
expressed in the currency as ordered by
the initiating party. CBPR+ (0..1)
• SettlementPriority <SttlmPrty> Indicator
of the urgency or order of importance that
the instructing party would like the
instructed party to apply to the processing
of the settlement instruction. CBPR+ (0..1)
• SettlementTimeRequest <SttlmTmReq>
Provides information on the requested
settlement time(s) of the payment
instruction. CBPR+ (0..1)
119
Charge bearer and charge type
120
Charge bearer and charge type
• ChargeBearer <ChrgBr> Specifies which party/parties will

bear the charges associated with the processing of the
payment transaction. CBPR+ (1..1)
• ChargesInformation <ChrgsInf>Provides information on

the charges to be paid by the charge bearer(s) related to
the payment transaction. CBPR+ (0..*)
121
122
Using pacs.009 in payments
• pacs.009 in ISO20022 can be

used as financial institution credit
transfer message (like MT202) and
also
• as a cover for underlying customer
credit transfer (made using
pacs.008) (like MT202 COV)
• The pacs.009 therefore contain
information of the underlying
Customer Credit Transfer
(pacs.008) for usein the cover
scenario, which is the key attribute
to differentiate between these two
use cases.
123
pacs.009 : financial institution credit transfer
Example of a core pacs.009 message flow
Debtor FI Creditor FI
A B C D E
1. pacs.009 0. camt.057
0. camt.057
2. pacs.009
1a. pacs.002
3. pacs.009
2a. pacs.002
4. camt.054
3a. pacs.002
5. camt.053
• pacs.009: The Financial Institution Credit Transfer message is sent by a Debtor Financial Institution to a Creditor
Financial Institution, directly or through other agents and/or a payment clearing and settlement system. It is used to move
funds from a debtor account to a creditor, where both Debtor and Creditor are Financial Institutions.
124
125
• The pacs.002 FItoFIPaymentStatusReport

uses a number of Original elements in
the TransactionInformationAndStatus
to capture information from the underlying
payment that the PaymentStatusReport
relates to.
• ExternalPaymentTransactionStatus1Code
is used to indicate the status of each
transaction included in the report.
• It is possible to report multiple statuses of
a transaction.
126
• The pacs.002 FItoFIPaymentStatusReport

uses a number of Original elements in
the TransactionInformationAndStatus
to capture information from the underlying
payment that the PaymentStatusReport
relates to.
• ExternalPaymentTransactionStatus1Code
is used to indicate the status of each
transaction included in the report.
• It is possible to report multiple statuses of
a transaction.
127
Logical flow of status codes in pacs.002
RCVD : Received Debtor Agent
ACSC: Accepted Settlement Completed
ACCP : Accepted Customer Profile

Creditor Agent
PDNG
ACTC : Accepted Technical Validation Pending
ACWP : Accepted Without Posting

ACWC : Accepted With Change
ACCC: Accepted Settlement Completed

ACSP : Accepted Settlement In Process
RJCT : Rejected 128

credit transfer - push
129
Case Study #1
Delta Corporation wants to pay Gamma
• Delta Limited is located in New York USA and banks with First Bank, New York.
• Gamma Limited is located in Chicago, USA. Gamma banks with Last Bank,
Chicago.
• Delta wants to pay USD 500,000 to Gamma by RTGS.
• Its assumed that the RTGS uses ISO20022 messages.
• Let’s look at the process on the next slide.
130
Credit transfer : Push - Success
3. pacs.008
2. pacs.008
We accept First Bank Last Bank

pacs.002
+Debit First Bank +USD500,000
USD800,000 USD200,000
Credit Last Bank USD500,000
+ USD300,000 + USD700,000
1. Pay Gamma USD 500,000

pain.001
1. pain.001 4. Recd. from Delta USD 500,000
camt .054/camt.053
2.. pain.002 we accept to pay.

2A . Paid to Gamma USD 500,000
camt .054/camt.053
131
Credit transfer : Push – Alternate (1)
3. pacs.008
4. Reject First Bank Last Bank

pacs.002
USD 80000 USD 30000
Debit Customer Delta

Credit RTGS settlement account
camt .054/camt.053
1. pain.001 2. Reject
pain.002 5. Repay Delta USD 500,000
Debit RTGS settlement account
Credit Customer Delta
camt .054/camt.053
Scenario : Reject before interbank settlement

132
pacs.008 pacs.008
Return
Return First Bank Last Bank
pacs.004
pacs.004
Debit First Bank

Credit Last Bank
Pay Gamma USD 500,000

1. pain.001
camt .054/camt.053
Recd. from Delta USD 500,000
X
Repay Delta USD 500,000
Debit RTGS settlement account
Credit Customer Delta
camt .054/camt.053
Scenario B : Return after interbank settlement 133

8C. Recall successful : pacs.004
Recall failure : camt.029 8A. Recall successful : pacs.004
Recall failure : camt.029
4A. Recall result

pacs.002
4. Recall First Bank Last Bank 6. pacs.008 7. Recall

camt.056 4. pacs.008
camt.056
5 5. Debit First
8B
Bank
Credit Last Bank

camt .054/camt.053
4 6A. Recd. from Delta USD 500,000
1. pain.001 camt.053/camt.054
3. Recall
camt.055 9
2. pain.002 Ack
8. If Recall successful : pacs.004
Debit Customer Gamma
3A. pain.002 recall complete
9. camt.053/camt.054
4B. camt.054/camt.053 Debit for successful recall
9. USD 500,000 re-credited
Scenario C : Recall before interbank settlement Scenario D: Recall after interbank settlement 134
Cross Border Push – Credit Transfer
135
Cross border transactions : Serial and Cover
• Serial method of payment

– In Serial method of payment, the payment instruction is sent through a series of Agents
to reach the creditor agent.
• Cover method of payment
– With the Cover method, the sender sends two message with two different instructions.
– One message instructs the creditor agent to credit the creditor
– Another message informs the creditor agent where it will be reimbursed the funds it has
credited to the creditor.
• Let’s look at a few transactions of ABC Corporation on subsequent slides.
136
Message flow : Cross border Serial Method
1 3 5 7 8 10
2 4 6 9
Debtor Debtor Agent Instructing MI/ Instructed Creditor Agent Creditor
Reimbursement Clearing House Reimbursement
Agent Agent
1. Debtor initiates payment using pain.001 5. Instructing Reimbursement Agent 9. Creditor Agent receives the payment and
(Correspondent) processes the payment accepts to credit the account of creditor. It
2. Debtors Agent accepts to process using and sends pacs.008 to MI sends pacs.002 to Instructed
pain.002. After processing, it may send Reimbursement Agent (Correspondent) to
6. MI processes the payment and sends confirm the acceptance.
camt.054 debit notification to debtor. pacs.002 to Instructing Reimbursement
3. Debtors Agent informs Instructing Agent (Correspondent).
10. Creditor Agent processes the payment
Reimbursement Agent (Sender’s 7. MI settles the payment and sends and credits the account of creditor. It may
Correspondent) using pacs.008 pacs.008 to Instructed Reimbursement also send camt.054 credit notification.
Agent. (Receiver’s Correspondent)
4. Instructing Reimbursement Agent 11.Additionally, the parties sending
(Correspondent) accepts to process the 8. Instructed Reimbursement Agent sends camt.054 may also send camt.053 EOD
payment and intimates using pacs.002. pacs.008 to Creditor Agent. It may also statement to their customers.
After processing, it may send camt.054 send camt.054 credit notification.
debit notification to debtor agent.
137
Message flow : Cross border Cover Method
1 3A 9
3C
2
Debtor Agent 3B
5 7 8
Debtor Creditor Agent Creditor
4
6
Instructing Instructed
MI/
Reimbursement Reimbursement
Clearing House
Agent Agent
1. Debtor initiates payment using pain.001 4. Instructing Reimbursement Agent 7. MI settles the payment and sends
(Correspondent) accepts to process the pacs.009 COVE to Instructed
2. Debtors Agent accepts to process using payment and intimates using pacs.002. Reimbursement Agent. (Receiver’s
pain.002. After processing, it may send After processing, it may send camt.054 Correspondent)
camt.054 debit notification to debtor. debit notification to debtor agent.
8. Instructed Reimbursement Agent sends
3A. Debtors Agent informs Creditors Agent 5. Instructing Reimbursement Agent camt.054 credit notification to Creditor
using pacs.008 using cover method. (Correspondent) processes the payment Agent.
and sends pacs.009 COVE to MI
3B. Debtors Agent informs Instructing 9. Creditor Agent reconciles camt.054 with
Reimbursement Agent (Sender’s 6. MI processes the payment and sends pacs.008 and credits the creditor.
Correspondent) using pacs.009 - COVE pacs.002 to Instructing Reimbursement
Agent (Correspondent). 10.Additionally, the parties sending
3C. Creditor Agent confirms acceptance of camt.054 may also send camt.053 EOD
pacs.008 by issuing pacs.002 statement to their customers. 138
Cross border payment : Cover method
139
Cross Border payment with Serial and Cover
Method Using SWIFT MX/ISO20022 (Invoice 1)
• ABC Corporation (Debtor), New York has received an invoice from DEF Electronics (Creditor)
London, UK
• Invoice number 4562,
• Date: 08 September 2012
• Amount : 10 million JPY
• DEF Electronics bank account number 23683707994215
• ABC Corporation assigns reference ABC/4562/2012-09-08 to the payment.
• Payment transaction charges are shared between ABC Corporation and DEF Electronics.
• ABC Corporation Banks with Debtor Agent Citibank USA (CITIUS33)
• Citibank USA has Mitsui Bank (MTSBJPJT) as its correspondent (Instructing Reimbursement Agent)
in Japan
• Creditor Agent Bank name : HSBC, London (HSBCGB2L).
• HSBC London has HSBC Tokyo (HSBCJPJT) as its correspondent (Instructed Reimbursement
Agent) in Japan
140
• ABC Corporation (Debtor), New York has received an invoice from GHI Semiconductors
(Creditor) Brussels
• Invoice number ABC-13679,
• Date of invoice 15 September 2012
• Amount: 500,000 EUR
• GHI Semiconductors bank account BE30001216371411
• Creditors Bank Gemini Bank, Belgium (GMNBBEBB).
• ABC Corporation assigns reference ABC/ABC-13679/2012-09-15 to the payment.
• The accounts receivable department of GHI Semiconductors needs to be advised when the
funds have been credited on the account on telephone number +32/2/2222222.
• GHI Semiconductors will bear all payment transaction charges.
141
• ABC Corporation (Debtor), New York has received an invoice from their branch, ABC
Corporation, California (Creditor)
• Invoice number 987-AC,
• Invoice dated 27 September 2012,
• Amount of InvoiceL 1 million USD
• Payment to Branch account 4895623 with Citibank, San Francisco (CITIUS66) Creditor
Agent.
• ABC assigns a reference ABC/987-AC/2012-09-27 to the payment. Payment transaction
charges are shared.
142
Cross border payment : Serial method
143
Cross border payment example : Serial Method
• Debtor: ABC Company, Canada Account number 0031234567
• Debtor Agent : Royal Bank of Canada, Toronto
• Instructing Reimbursement Agent : JP Morgan Chase, New York, USA
• Creditor : 123 Suppliers, London UK : Account number GB29NWBK60161331926819
• Creditor Agent : National Westminster Bank PLC, London, UK
• Instructed Reimbursement Agent : State Street Bank and Trust Company, Boston USA
• Currency and amount of transaction USD : 1000000.00
• Charges : Shared
• UETR : 8a562c67-ca16-48ba-b074-65581be6f011
• Market Infrastructure : Fedwire RTGS, USA
144
Royal Bank, Toronto JP Morgan NY State Street National Bank
ABC Canada Debtor Agent 123 London
Reimbursing Boston London
Debtor Creditor
Instructing Reimbursing Creditor Agent
Agent Instructing Agent
pain.001
pacs.008
pain.002
pacs.008
pacs.002
pacs.008
pacs.002
pacs.002 pacs.008
pacs.002 camt.054
145
SWIFT gpi and universal confirmation
for ISO 20022
• SWIFT gpi messaging, products and services will be adapted to ISO 20022.
• ISO 20022 messages will be tracked by the gpi tracker in the same way that MT messages
are tracked.
• All ISO 20022 payment messages include a mandatory, validated Unique End-to-End
Transaction Reference (UETR) that will be populated according to the same rules that
govern UETR in MT.
• With the extension of the ISO 20022 migration deadline by a year, SWIFT has postponed the
availability of the SWIFT XML ISO channel for Universal Confirmations to 2021 (testing will
start in July 2021 and live messages will become available as from November 2021).
• Instead, SWIFT has proposed a single trck.001 XML ISO message for Universal
Confirmations and gpi confirmations, in line with latest feedback from CBPR+ to make the
process even smoother for institutions who want to implement Universal Confirmations using
trck.001 format
146
SWIFT gpi and universal confirmation
for ISO 20022
• SWIFT gpi messaging, products and services will be adapted to ISO 20022.
• ISO 20022 messages will be tracked by the gpi tracker in the same way that MT messages
are tracked.
• All ISO 20022 payment messages include a mandatory, validated Unique End-to-End
Transaction Reference (UETR) that will be populated according to the same rules that
govern UETR in MT.
• With the extension of the ISO 20022 migration deadline by a year, SWIFT has postponed the
availability of the SWIFT XML ISO channel for Universal Confirmations to 2021 (testing will
start in July 2021 and live messages will become available as from November 2021).
• Instead, SWIFT has proposed a single trck.001 XML ISO message for Universal
Confirmations and gpi confirmations, in line with latest feedback from CBPR+ to make the
process even smoother for institutions who want to implement Universal Confirmations using
trck.001 format
147
Instant Payment Using ISO 20022
Real Time Payments (RTP), USA
148
Credit transfer by using US RTP
Jack Jane
3. <pacs.008>
1. <pacs.008> Validated Credit
Credit Transfer 2.
0. <pain.001> Transfer
<pacs.008>
Validation
4. <pacs.002>
Debtor Status Report Creditor Creditor
Debtor Agent MI ACTC/ACWP/RJCT Agent
5. <pacs.002>
5a. <pacs.002> 5. <pacs.002> 4a. <pacs.008>
Status Report
Status Report Status Report
ACTC/ACWP/RJCT
ACTC/ACWP/RJCT ACTC/ACWP/RJCT
149
Request to Pay by using US RTP
Jack Jane
2a. <pain.013> 0. <pain.013>

Request to Pay 2. <pain.013> 1. <pain.013> Request to Pay
Initiation Request to Pay Request to Pay Initiation
3. <pacs.002> 4. <pacs.002> 4a. <pacs.002>

Status Report Status Report Status Report
2b. <pain.014>
Accept/Reject Accept/Reject Accept/Reject
Accept/Reject Debtor Creditor
Debtor Agent Creditor
MI Agent
150
Settlement of request to pay in US RTP
Jack Jane
2a. 3. <pacs.008>
<pain.013> 1. <pacs.008> Validated Credit
from last slide Credit Transfer 2.
<pacs.008> Transfer
Validation
4. <pacs.002>
Debtor Status Report Creditor Creditor
Debtor Agent MI ACTC/ACWP/RJCT Agent
5. <pacs.002>
5a. <pacs.002> 5. <pacs.002> 4a. <pacs.008>
Status Report
Status Report Status Report
ACTC/ACWP/RJCT
ACTC/ACWP/RJCT ACTC/ACWP/RJCT
151
Distributed Clearing
Approach
152
New Payments Platform - Australia
Is payee’s bank member of the scheme?
pacs.008
pacs.002
pacs.009
pacs.002 pacs.002
camt.052 camt.052
153
A brief about SWIFT Alliance Gateway Instant
• SWIFTNet Instant provides a low-latency

messaging solution that is available round the
clock as required for instant payments initiatives.
SWIFTNet Instant requires the use of the Alliance
Gateway Instant (AGI) software that SWIFT
provides.
• Alliance Gateway Instant (AGI) software is used in
the context of the SWIFTNet Instant messaging
solution.
• Alliance Gateway Instant enables the exchange of
ISO 20022 messages over IBM MQ, Alliance
Messaging Hub Instant (using Oracle AQ), or
ActiveMQ.
154
SWIFT gpi Instant : July 2019
• All cross-border payments in the trial, which involved 17 banks across 7 countries,
settled end-to-end within 25 seconds. SWIFT gpi has also now been introduced for
corporates.
• SWIFT has completed a global trial to integrate SWIFT gpi Instant – its cross-border instant
payments service – into Singapore’s domestic instant payment service, known as FAST
(Fast And Secure Transfers).
• SWIFT gpi Instant reuses existing cross-border and domestic payments infrastructure,
minimising implementation costs for users and allowing them to avoid the complexities of
adopting new cross-border infrastructure.
• The latest trial involved 11 banks across six countries – Australia, China, Canada,
Luxembourg, the Netherlands and Thailand – initiating payments into six banks in
Singapore, which processed the payments domestically via the FAST system.
• All cross-border payments in the trial settled end-to-end within 25 seconds. The fastest
settlement was from Australia to Singapore, completed in just 13 seconds.
155
Direct debit - Pull
156
Case Study
Alfa Corporation wants to collect from Beta Limited
• Alfa Corporation (Creditor) is located in London, UK and banks with First Bank, London.
• Beta Limited (Debtor) is located in Berlin, Germany. Beta banks with Last Bank, Berlin.
• Alfa wants to collect EUR 5000 from Beta by using SEPA Direct Debit (SDD).
• Both, First Bank and Last Bank are members of SDD and have their settlement accounts in
TARGET2.
• We will start with mandate placement.
157
Direct debit mandate management
Mandate initiation Mandate initiation

pain.009 pain.009
Creditor
Mandate acceptance Mandate acceptance
Creditor’s Bank
Or rejection Or rejection Debtor’s Bank
pain.012 pain.012
Intimation to debtor : pain.009
Response from debtor : pain.012

Debtor
Message types:
Mandate amendment : pain.010
Mandate cancellation : pain 011
No involvement of Clearing House
158
Pull transaction
159
Direct Debit – Pull (Success)
3. Collection Initiation 3. Collection Initiation
pacs.003 (IDF) pacs.003 (DNF)
3A. Acceptance
pacs.002
4. Settled debits and rejects
7. Settled debits and rejects
pacs.002 (SDF/Rejects)
pacs.002 (SDF/Rejects)
Net Obligation
Settlement
First Last
2. Acceptance 6. Settlement @ TARGET 2

1. pain.002
Collection 5.Debit Advice/EOD Statement
initiation 8. Settled debits and rejects camt.054/camt.053
pain.008 pain.002 (SDF/Rejects)
Pre notification
9. Credit Advice/EOD Statement

Creditor camt.054/camt.053
Debtor 160
Direct Debit – Pull (Pre-settlement - R)
6. Reject
pacs.002 6. Reject
pacs.002
4. Reject
pacs.002

1A. Rejection 2. Acceptance

1.
pain.002 pain.002 5A. Refusal
Collection
initiation pain.002
4A. Rejection 7. Rejection
pain.008
pain.002 pain.002
Pre notification
Creditor
161
Debtor
Direct Debit – Pull (Pre-settlement - R)
8. Cancellation 8. Cancellation
pacs.002 pacs.002
5. Cancellation
pacs.002
7. Request for cancellation
camt.056
4. Request for cancellation
camt.056
1A. Acceptance
pain.002
1.
Collection 2. Revocation/ cancellation
initiation camt.055
pain.008
2A/5A/8A. Revoked/Cancelled
camt.029
Creditor Pre notification

162
Debtor
Direct Debit – Pull
(Post- settlement - R)
3. Reversal 5. Reversal
pacs.007 pacs.007
Net Obligation
Settlement
First Last
1. Reversal
6.Credit Advice/EOD Statement
pain.007 4 camt.054/camt.053
2. Acceptance/rejection/status
pain.002
3A.Debit Advice/EOD Statement

camt.054/camt.053
Creditor
Debtor
163
Direct Debit – Pull
(Post- settlement - R)
6. Return 6A. failure
4. Return 4A. failure camt.029
pacs.004
pacs.004 camt.029
2. Return/Refund
pacs.004 1. Return/Refund
pacs.004
Net Obligation
Settlement
First Last
3.Debit Advice/EOD Statement 7.Credit Advice/EOD Statement

camt.054/camt.053
5 camt.054/camt.053
Creditor 164
Debtor
165
Exceptions and Investigations Management
• In an average payments operations department, two to five per cent of all

payments, made on any particular day, result in an enquiry.
• Management of exceptions and investigations remains one of the most labour-
intensive activities for a financial institution, largely because it blocks increased
automation. The reason for this is the widespread use of free-format messages
combined with a lack of industry rules.
166
Four different types
• Request for cancellation:

– occurs when the instructing party requests cancellation of a payment instruction.
• Request for modification:

– occurs when the instructing party requests modification of a payment instruction.
• Unable to apply:
– occurs when insufficient or incorrect information prevents the processing of a payment instruction, for
example the account number is missing or incorrect, the account is closed, the name and account do not
match or the final agent is missing. Processing of a payment instruction covers both the execution of the
instruction and the reconciliation of the instruction.
• Claim non receipt:

– occurs when a party expecting a payment does not receive it or when an agent is missing the cover for a
received payment instruction. 167
Rules of Exception and Investigations
• Uniqueness of the Case Identification

– The case creator must assign the case identification in such a way that it ensures
uniqueness.
• The 'No By-pass' Rule
– The 'no by-pass' rule specifies that no party involved in the original payment transaction
can be by-passed in the exceptions and investigations workflow.
– It also specifies that all parties involved in an investigation workflow must be kept
informed of the status of the investigation at all times.
• Modifying 'Amount of Money' and 'Currency’
– The Request To Modify Payment message must never be used to increase the amount of
the original payment instruction.
– The Request To Modify Payment message must never be used to modify the currency of
the original payment instruction.
168
Claim Non Receipt Investigation Example
169
Claim Non Receipt Situations
• The claim non receipt case occurs in two situations:

– The creditor is expecting funds from a particular debtor and cannot find the
corresponding credit entry on its account. In this situation, it is understood that the
creditor will contact its debtor, and that the debtor will trigger the ClaimNonReceipt case
on its behalf. A workflow where the creditor directly addresses a ClaimNonReceipt
message to its account servicing institution is not retained.
– An agent in the processing chain cannot find a cover payment corresponding to a
received payment instruction. In this situation, the agent may directly trigger the
investigation by sending a ClaimNonReceipt message to the sender of the original
payment instruction.
• The ClaimNonReceiptmessage covers one and only one payment instruction at a time. If
several expected payment instructions/cover instructions are found missing, then multiple
ClaimNonReceipt messages must be sent.
170
Claim Non Receipt
<camt.027>
Claim non receipt
1
<camt.029> <camt.027>
Resolution of Investigation INFO Claim non receipt
2a 2b
<camt.030> <camt.031>
Notification of case assignment FTHI Reject Investigation
3
4a
<camt.030>
Notification of case assignment MINE
4b
<camt.032>
<camt.029> Cancel case assignment
Resolution of Investigation
5a
5b <camt.033>
Request for duplicate <camt.037>
6a Debit authorization request 8a
<camt.034>
6b Duplicate <camt.036>
<camt.038> Debit authorization response
Case status report request <camt.028>
7a <camt.029> Additional payment information 8b
<camt.039>
Resolution of Investigation INFO 9a
<camt.029> Creditor B
Resolution of Investigation INFO
Case status report response 9b
7b
9c <camt.035>
Proprietary Format Investigation
171
172

ISO 20022 MasterClass January 2021

Uploaded by

Copyright:

Available Formats

You might also like

ISO 20022 MasterClass January 2021

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ISO 20022 MasterClass January 2021

Uploaded by

Copyright:

Available Formats

Masterclass

ISO 20022 and SWIFT MX

MVL Consulting Private Limited

• Overview of SWIFT Standards MX, CPBR+, HVPS+ and RTPG

• Module 01 : Introduction to XML for ISO 20022 XSD

• XML tags have to follow a certain

• XML tags have to follow a certain

• XML Element Types

• The Standards MX-defined

• The Standards MX-defined

• Restrictions are used to define

• Restrictions on XML elements are

• Restrictions are used to define

• Restrictions on XML elements are

Sample Tree Structure

• Functions of an XML schema

• Functions of an XML schema

• Non-Schema extended validation

• Non-Schema extended validation

• Non-Schema extended validation

• The code sets are published in two sets of documents:

• Generic error codes

• Payments Group e.g. CBPR+, HVPS+, RTPG

• Introduction to SWIFTNet InterAct, FileAct, FINplus and SWIFT Instant

• Structure and format of MX message

• Business Application Header and Document

• MX message with SWIFTNet InterAct/SWIFTNet FileAct, FINplus

• Standard MX is a financial messaging standard.

• Standard MX is a financial messaging standard.

• Cross Border Payments and Reporting Plus (CBPR+) working group

• High Value Payment Systems Plus (HVPS+) working group

• Real Time Payments Group

• The Common Global Implementation (CGI) initiative aims to simplify

Domestic Regional Cross border

High value Bulk Instant

Fedwire CHIPS TARGET2 Others… RTP NPP RT1 Others…

CBPR+ HVPS+ RTPG

• There will be a migration from FIN

• Current syntax is as following: xxxx.nnn.aaa.bb

• Current syntax is as following: xxxx.nnn.aaa.bb

• Applications use headers to manipulate messages. A header enables an application to

• Adoption timelines and major milestones

• Cross Border Payments and Reporting Plus (CBPR+)

• Exception from migration

• SWIFT has planned to provide a transaction

• In case of any dispute, which message to relied upon, MT or MX?

• Understanding mapping of MT 1XX , MT2XX and MT 9XX to MX for payments

• The ISO 20022 message catalogue hierarchically begins with

• actm : Account Management

Message Specification Parties in the Message

Field Element Ordering

Presence Min Max Beneficiary

Qualifier Code Message Instructing

Textual Message Instructed

• pain : payment initiation

• pacs.008: The Financial Institution To

3a. pacs.009 COV

• The pacs.008 introduces the SettlementMethod element within the GroupHeader