ISO 20022 Programme

Quality data, quality payments

Awareness Webinar – Payments Deep Dive

What is ISO 20022?

ISO 20022 Programme - Awareness Webinar – ISO Overview 2

What is ISO 20022?

ISO 20022 Governance Responsibility

Payments
Treasury & Trade Securities only
1984
Securities only • Approval of the international standard
1973 1999 2000 2004
• Selection of the Registration Authority and
Proprietary
ISO 7775 ISO 15022 ISO 20022
set-up of the http://www.iso20022.org
•
MT
Creation of Registration Management
Group (RMG)
• Creation of Standards Evaluation Groups
• Paper-based • Reference standard (SEG)
• Proprietary syntax • Electronic
• Point-to-point • Open, neutral syntax • Registration and publication of first ‘ISO
• One size fits all • End-to-end transaction
• SWIFT only • Market practice 20022 messages’
• SWIFT + other organisations
• Approval of a new edition of the international
standard in 2013
FIN MT:
Computer-processable
versions of telexes

ISO 20022 Programme - Quality data, quality payments 3

What is ISO 20022? Published on www.iso20022.org
Maintenance process –
built on strict business
justifications and review
process - leading to new
‘versions’ of the ISO 20022 message
messages catalogue
MyStandards

More than 20 submitting More than 320

organisations, besides messages, covering
SWIFT payments, securities,
trade services, FX, cards.
23 Business Areas – examples :
‘PAIN’ = Payment Initiation = used in Corporate-to-bank
‘PACS’ = Payment Clearing and Settlement = used in Payments
‘SESE’ = Securities settlement = used in Securities
‘SEMT’ = Securities management = used in Securities
‘SEEV’ = Securities events = used in Securities
‘CAMT’ = Cash Management + used in Payment Reporting
ISO 20022 Programme - Quality data, quality payments 4
A community agreement

In 2018, the global All FI to FI All players need to

The move to ISO
financial community payments and cash start preparing for
20022 will begin in
agreed to migrate reporting messages the migration now to
November 2022 and
from the MT (FIN) will move to ISO 20022 be ready for
coexistence with MT
payment message November 2022
(FIN) will run until
standard
November 2025
to ISO 20022

ISO 20022 Programme - Quality data, quality payments 5

Why is the Industry Adopting ISO 20022?

Enabling a hyper-connected payment world

Payments are rapidly transforming, with new players world-wide, transforming
Payments
to meet the customer requirements and improving the customer experience.
revolution ISO payment and report formats are a key element of this transformation

Domestic Real time payments are quickly becoming the consumer payment method of
modernization choice and will quickly be an international payment option 24/7. ISO systems

Global payments SWIFT gpi is driving unprecedented change –

innovation delivering fast, transparent and trackable cross-border payments

Through global harmonization of payment formats we are prepared for a future

A hyper-connected
where complex and data rich payments move through any domestic and/or cross-
payment world border payment system, and are credited to beneficiaries – Instantly.

Regulatory
! requirements
Facilitates complying with ever changing and broader regulatory requirements.

ISO 20022 Programme - Awareness Webinar – ISO Overview 6

The changing language of payments

ISO 20022 Programme - Quality data, quality payments 7

What is changing?

Field names

ISO 20022 Programme - Quality data, quality payments 8

SWIFT MT versus ISO 20022: Key Concepts Legend: MT ISO 20022

Message
Field Element Usage Rule Textual Rule
specification
components
Format DataType Network Validated Rule CrossElementComplexRule

Presence Min Max

Qualifiers / Codes CodeSet

Parties in a
Bank Agent Message Sender Instructing Agent
message

Ordering Customer Debtor Message Receiver Instructed Agent

Beneficiary Customer Creditor

ISO 20022 Programme - Quality data, quality payments 9

New Parties Legend:

New parties
ISO 20022

:XX FIN MT format

introduced in equivalent
ISO 20022

Payment Originator Payments Clearing & Settlement (pacs) Payment Beneficiary

:70:/INST/ :50C/L :72:/INS/ :53a :54a :55a :56a :72:/INT/ :70:/ULTB/

Ultimate Forwarding Previous Instructing Reimbursement Intermediary

Debtor Agents Agents Agents Ultimate
Agent
Creditor
1 2 3 1 2 3 1 2 3

Debtor Initiating Debtor Instructing Instructed Creditor Creditor

Party Agent Agent Agent Agent

:50a :50C/L :52a Sender Receiver :57a :59a

ISO 20022 PROGRAMME - QUALITY DATA, QUALITY PAYMENTS 10

MT 103 Customer Credit Transfer serial message flow The MT key concepts

A MT 103 B MT 103 C MT 103 D

Party MT

Ordering Customer

Ordering Institution

Intermediary Institution

Intermediary Institution

Account with
Institution
ISO 20022 Programme - Quality data, quality payments 11
Beneficiary
pacs.008 FI To FI Customer Credit Transfer serial message flow The ISO 20022 key concepts

A B C D

pacs.008 Party pacs.008

pacs.008
Debtor
pacs.008

Debtor’s Agent

Intermediary Agent 1

Intermediary Agent 2

Creditor’s Agent

ISO 20022 Programme - Quality data, quality payments 12

Creditor
What is changing?

Character sets

ISO 20022 Programme - Quality data, quality payments 13

 U
Character Set

All SWIFT ISO MX Special characters are Currencies in the payments Translation of any special
message elements (fields) additionally allowed in: should be expressed in ISO character:
which are defined (by data Currency Codes only (3-
Type) as text are restricted • All party (agents and Characters, e.g. EUR) !#&%*=^_’{|}~";@[\]$ ><
to FIN X Characters: non-agents) Name and
Address elements into MT messages will be
a-z A-Z 0-9 / - ? : ( ) . , ' + . • The Related Remittance represented by a . (Full
Information elements Stop)
• The Remittance
Information (structured
& unstructured)
elements

List of special characters:

!#&%*=^_’{|}~";@[\] $ ! \ %

Additionally special < # ] *

characters $ and > < signs
are enabled for the Email
> & [ =
Address elements
ISO 20022 Programme - Quality data, quality payments Note: While ISO 20022 base standards support non-Latin characters, CBPR+ will 14
only support Latin characters in Phase 1 and Phase 2
What is changing?

Message Structure

ISO 20022 Programme - Quality data, quality payments 15

ISO 20022 XML message identifier

4!a . 3!c . 3!n . 2!n Example

pacs.008.001.08
Version
Version 8

Variant Variant 1

Message identifier/functionality FI To FI Customer

Credit Transfer

Business area Payments Clearing and

Settlement

ISO 20022 Programme - Quality data, quality payments 16

How is an MT structure different from an MX structure?

MT ISO 20022 (MX)

<AppHdr> ISO 20022

… Business
</AppHdr> Application Header
<Document> Business
ISO 20022
Message
…
Message
ISO 20022 Programme - Quality data, quality payments </Document> 17
Structured data becomes the new norm

ISO 20022 Debtor data element example Customer data record example MT – free format option
Debtor Name JOHN HECTOR :50K:/BE3000121637141
JOSEPH SMITH -
JOHN HECTOR JOSEPH SMITH –
MASTERSONS
MASTERSONS HOOGSTRAAT 6 BRUSSELS
Postal Department
Address 1000 BELGIUM ID:1111111111
Sub
Department
Street Name HOOGSTRAAT
Richness of Building 6
Number
ISO 20022 MT – structured option with risk of potential truncation & loss of info
Post Code 1000
allows more :50F:/BE3000121637141
Town Name
granular data BRUSSELS
1/JOHN HECTOR JOSEPH SMITH -
structure Country BE 1/MASTERSONS
Identification Private
2/HOOGSTRAAT 6
1111111111
Identification
– Other
3/BE/BRUSSELS 1000 Passport
Identification
number is lost!
Debtor Identification IBAN BE3000121637141
Account

ISO 20022 Programme - Quality data, quality payments 18

What is changing?

Message types

ISO 20022 Programme - Quality data, quality payments 19

 U
CBPR+ Phase 1 usage guidelines and planned translation rules Updated April 2020

Existing FIN MTs ISO 20022 equivalent Usage guidelines Translation rules planned
MT 103 / 102 pacs.008.001.0x Published on MyStandards

MT 200 / 201 / 202 / 202 COV / 203 / 205 pacs.009.001.0x Published on MyStandards

MT 103 RETURN / MT 202 RETURN pacs.004.001.0x Published on MyStandards

Published on MyStandards
MX to MT only
MT 103 REJECT / MT 202 REJECT Negative pacs.002.001.0x SWIFT to Investigate Field 72 option or MT
199
No Equivalent Positive pacs.002.001.0x No translation planned

MT 210 camt.057.001.0x MX to MT - Single

MT 900 / 910 camt.054.001.0x Published on MyStandards

MT 941 / 942 camt.052.001.0x Published on MyStandards No translation planned

MT 940 / 950 camt.053.001.0x Not required – Guidance in UHB

MT 920 camt.060.001.0x No translation planned

Published with each request

head.001.001.0x – v2 N/A
type

ISO 20022 Programme - Quality data, quality payments 20

CBPR+ Phase 1 usage guidelines and planned translation rules
Existing FIN MTs ISO 20022 equivalent Usage guidelines Translation rules planned
MT 103 STP Pacs.008 STP Guideline Under development No translation planned
MT 103 STP EU Pacs.008 EEA Guidelines To be planned No translation planned
MT 204 Pacs.010 Under Development From MX to MT only
MT 104 Pacs.003 Out of scope Out of scope

Published with each request

head.001.001.0x – v2 N/A
type

CBPR+ Phase 2 usage guidelines and planned translation rules

Usage Guideline
available on
Existing FIN MTs ISO 20022 equivalent Translation rules planned
Mystandards &
Readiness Portal
camt.056.001.0x - Cancellation
192/292 (Cancellation Request)
Request
Camt.026 – Unable to Apply
In collaboration with gpi
Camt.027 – Claim Non Receipt To be confirmed
expert group
Camt.087 – Request to Modify
camt.029.001.0x - Resolution of
296/199/299/112 (Query/Answer)
Investigation
MT 101 Pain.001 Wait for CGI deliverable To be confirmed
Start development during
MT 110/MT 111/MT 112 New Cheques Messages To be confirmed
June 2020 Workshop
Start development during
MT n90 / MT n91 New Fee Messages To be confirmed
June 2020 Workshop
21
ISO 20022 Programme - Quality data, quality payments
Overview of usage guidelines

ISO 20022 Programme - Quality data, quality payments 22

 U
Payment, Clearing and Settlement (pacs) messages

Messages index

pacs.008 - Financial Institution to Financial Institution Customer Credit Transfer

pacs.009 (core) - Financial Institution Credit Transfer
pacs.009 (cov) - Financial Institution ‘Cover’ Credit Transfer
pacs.002 – FI To FI Payment Status Report
pacs.004 – Payment Return

ISO 20022 Programme - Quality data, quality payments 23

pacs.008

Financial Institution to Financial Institution

Customer Credit Transfer

ISO 20022 Programme - Quality data, quality payments 24

pacs.008 FI to FI Customer Credit Transfer

The pacs.008 has two core sets of nested

element:
pacs.008
Group Header which contain a set of
characteristics that relate to all individual
transactions
Credit Transfer Transaction Information
which contains elements providing information
specific to the individual credit transfer
Group Header
transaction.

A typical payment message in a many-to-many payment

would be considered as a single transaction.
The Industry CBPR+ committeee has decided that the
Credit Transfer pacs.008 will carry a single transaction as a best practice.
Transaction Information It is however possible, where bilateral agreed, to include
re-occurring Credit Transfer Transaction Information i.e.
multiple payments, perhaps more associated with an
early leg in the payment lifecycle, where upon these
ISO 20022 Programme - Quality data, quality payments
multiple transaction would typically be split into individual 25
payment transactions.
 MT 103 Customer Credit Transfer The MT way
High Level Serial message flow

Payment Initiation Payment Reporting

MT101 MT9XX
PAIN001 via FileAct MT 103 MT 103 camt 5X via FileAct
MT 103
Proprietary
A MT 900
B MT 900
C MT 900
D Proprietary

Originator Originating Bank Sending Bank Receiving Bank Beneficiary Bank Beneficiary

Current serial MT 103 payment flow as the payment moves across the payment bank chain.

MT 900s are generally used to confirm transaction execution to originating banks

ISO 20022 Programme - Quality data, quality payments 26

pacs.008 FI to FI Customer Credit Transfer The ISO 20022 way
High Level serial message flow

Payment Initiation Payment Reporting

MT101
PAIN001 via FileAct
pacs.008 pacs.008 pacs.008 MT9XX
camt 5X via FileAct

pacs.002 pacs.002 pacs.002

Proprietary
A B camt.054 C D Proprietary
camt.054 camt.054
Debtor Debtor Agent Instructing Agent Instructed Agent Creditor Agent Creditor

The new party names are shown in this ISO pacs 008 payment message flow,

When the customer credit transfer migrates to the pacs 008, there is an option to provide payment status
messages utilizing the pacs 002 message.

The pacs 002 is a point to point status message and does not carry full comprehensive status information
like the gpi tacker service

The pacs 002 or the camt.054 can be used to confirm transaction execution to originating banks.

ISO 20022 Programme - Quality data, quality payments 27

pacs.008 FI to FI Customer Credit Transfer The ISO 20022 way
High Level Use Case settled over a Payment Market Infrastructure

1 2 3 4 5 6
pacs.008 pacs.008 pacs.008 pacs.008
A pacs.002 B pacs.002 C pacs.002 D

Each MI will determine their method of confirmation but the 002 is the standard ISO message.
Settlement
Complete

1 3 5
Debtor initiates a payment Agent B processes the payment Agent C processes the payment
instruction to the Debtor Agent on Agent C, via the Payment on Agent D
Market Infrastructure.

2
Debtor Agent (A) initiates a 4 6
serial payment towards the Payment Market Infrastructure, Agent D credits the account of the
Creditor Agent (D) using settles the payment between Agent Creditor, and may optionally
Agents B & C as B and Agent C as direct provide a notification e.g.
intermediaries, who are direct participants of the Market notification of credit in addition to
participant of the Payment Infrastructure, and provides a an account statement (camt.053)
Market Infrastructure settlement confirmation to Agent B
ISO 20022 Programme - Quality data, quality payments 28
pacs.009 (core) & pacs.009 (cov)

Financial Institution
Credit Transfer

ISO 20022 Programme - Quality data, quality payments 29

pacs.009 core versus cov

The pacs.009 has two main use cases:

pacs.009 (core) pacs.009 (cov) • as a core Financial Institution to Financial
Institution Credit Transfer message, and
• As a cov where it is used as cover of (to settle)
a pacs.008.
Group Header Group Header
The pacs.009 therefore contain information of the
underlying Customer Credit Transfer (pacs.008)
for use in the cover scenario, which is the key
attribute to differentiate between these two use
Credit Transfer Credit Transfer cases.
Transaction Transaction
Information Information

Underlying
Customer Credit
Transfer

ISO 20022 Programme - Quality data, quality payments 30

MT 202 FI to FI Credit Transfer The MT way
High Level message flow
Originating FI Sending FI Receiving FI Beneficiary FI

A B C D

MT 202

MT 900
MT 202

MT 900 MT 202

MT 900

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.
ISO 20022 Programme - Quality data, quality payments 31
pacs.009 FI to FI Credit Transfer The ISO 20022 way
High Level message flow
Debtor FI Instructing FI Instructed FI Creditor FI

A B C D

pacs.009

pacs.002
pacs.009
camt.054
pacs.009
pacs.002

camt.054 pacs.002
camt.054

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.
ISO 20022 Programme - Quality data, quality payments 32
 The MT way
MT 103 Customer Credit Transfer
High Level message flow settled using the MT 202 cover method

Payment Initiation
MT101
PAIN001 via FileAct Payment Reporting
Sending Bank Receiving Bank MT9XX
camt 5X via FileAct

Proprietary
A MT 103
D
Originating Bank Proprietary
Originator Beneficiary Bank
Beneficiary

B MT 202 cov C
Sending Bank Receiving Bank

ISO 20022 Programme - Quality data, quality payments

Note: For example purposes, this slide shows V-shape payment market 33
infrastructure flows. Y-shape flows will be different.
 pacs.009 cov FI to FI Credit Transfer The ISO 20022 way

High Level message flow demonstrating the change in party roles between messages

Payment Initiation
MT101 A B C D
Debtor PAIN001 via FileAct Creditor

Proprietary pacs.008
pacs.002

pacs.009 cov

pacs.002
pacs.009 cov
Payment Reporting
pacs.002 pacs.009 cov MT9XX
Party pacs.008 pacs.009 cov camt 5X via FileAct
pacs.002
Proprietary
Debtor Underlying Debtor
The Financial Institution Credit Transfer cover message is sent by a Debtor
Financial Institution to a Creditor Financial Institution, directly or through other
Debtor Agent Debtor agents and/or a payment clearing and settlement system. It is important to
recognize that some roles change between these parallel messages.
Creditor Agent Creditor The correspondent banking cover payment method utilises both the pacs.008
and pacs.009 cov. The UETR element within these messages contain the
same UETR which effectively interlink the messages.
Creditor Underlying Creditor As an interlinked message it is important to understand the way certain parties
change their role in the pacs.009 cov This is demonstrated in the example
ISO 20022 Programme - Quality data, quality payments 34
 The MT way
MT 103 Customer Credit Transfer
High Level message flow settled using the MT 202 cover method Via MI

Payment Initiation
MT101
PAIN001 via FileAct Sending Bank Payment Reporting
Receiving Bank MT9XX
camt 5X via FileAct

Proprietary
A MT 103
D
Originator Originating Bank Beneficiary Bank Proprietary
Beneficiary

MI COV
B MI COV C
MI Confirm
Sending Bank Receiving Bank

ISO 20022 Programme - Quality data, quality payments

Note: For example purposes, this slide shows V-shape payment market 35
infrastructure flows. Y-shape flows will be different.
 pacs.008 FI to FI Customer Credit Transfer The ISO 20022 way

High Level Use Case settled using pacs.009 COV over a Payment Market Infrastructure

1 2a 7
pacs.008
Payment Initiation Payment Reporting
MT101 A pacs.002 D MT9XX
PAIN001 via FileAct camt 05X via FileAct
Proprietary 2b Proprietary

6
1 3 4 5
Debtor initiates a payment
instruction to the Debtor Agent
pacs.009 cov pacs.009 cov 6
Agent C produces an end of day
B pacs.002 C account statement report. An
optional real time notifications e.g.
2a 4 advice of credit may have also been
Debtor Agent (A) initiates a Settlement Payment Market Infrastructure, created at the time of the credit
payment using the cover method Complete settles the payment between Agent posting
to the Creditor Agent (D) B and Agent C as direct
participants of the Market
Infrastructure, and provides a 7
2b In parallel the Debtor Agent (A) 3 settlement confirmation to Agent B Agent D reconciles the covering
initiates a covering payment to Agent B processes the payment funds and credits the account of the
credit the account of Agent (D) on Agent C, via the Payment 5 Creditor, and may optionally
with their correspondent (Agent Market Infrastructure. Agent C receives the payment and
provide a notification e.g.
C) credits the account of Agent D
notification of credit.

ISO 20022 Programme - Quality data, quality payments Market Infrastructure will either conform to HVPS+ guidelines or establish their own usage guidelines based on the ISO 20022 standard. 36
pacs.002

Status Information

ISO 20022 Programme - Quality data, quality payments 37

pacs.002 Status Information

The Financial Institution To Financial

Institution Payment Status Report
pacs.002
message is sent by an instructed agent
to the previous party in the payment
chain. It is used to inform this party
about the positive or negative status of
an instruction (either single or file). It is
also used to report on a pending
instruction
Group Header

Transaction Information
And Status

ISO 20022 Programme - Quality data, quality payments 38

pacs.002 Payment Status Information
High Level Use Case of multiple Payment Transaction Status updates
An agent may provide multiple Payment Status Information updates (with different Transaction Status codes),
where bilaterally agreed, throughout the payment processing lifecycle i.e. from receipt through to onward
processing.

1 2 5
pacs.008 pacs.008 pacs.008
A B C pacs.002
D
pacs.002
pacs.002 3
pacs.002 4
1 camt.054
Debtor initiates a payment
instruction to the Debtor Agent 3 4 Agent B provides a further status
5
Agent B provides a status update Agent B processes the payment
ACTC (accepted technical update ACSP (accepted
on Agent C. Status Messages
2 validations are successful) to settlement in progress) to Agent
can follow
Debtor Agent (A) initiates a Agent A, based upon a bilateral A, based upon a bilateral
serial payment towards the agreement. agreement. pacs 002 or
Creditor Agent (D) using camt.054 for final confirmation.
Agents B & C as intermediaries

CBPR+ restricted the

The code list representing the Payment
pacs.002 to a single
Transaction Status is part of the ISO 20022 transaction
external code list
ISO 20022 Programme - Quality data, quality payments 39
Payment Transaction Status
Code definitions
Code Name ISO Definition pacs High Level Use Case
ACCC AcceptedSettlementCompleted Settlement on the creditor's account has been completed. Sent by Credit Agent to confirm the settlement on the creditor’s account

ACCP AcceptedCustomerProfile Preceding check of technical validation was successful. Sent by any Agent in the payment chain to confirm acceptance prior to
Customer profile check was also successful. technical validation.

ACSC AcceptedSettlementCompleted Settlement on the debtor's account has been completed. Sent by the Debtor Agent to confirm settlement on the debtor account
prior to payment execution.

ACSP AcceptedSettlementInProcess All preceding checks such as technical validation and Sent by any Agent to the to confirm the payment is accepted following
customer profile were successful and therefore the payment technical validations being successfully completed.
initiation has been accepted for execution.

ACTC AcceptedTechnicalValidation Authentication and syntactical and semantical validation are Sent by any Agent in the payment chain to the previous Agent to confirm
successful the payment is accepted following technical validations being successfully
completed.

ACWC AcceptedWithChange Instruction is accepted but a change will be made, such as Sent by any Agent in the payment chain to the previous Agent to confirm
date or remittance not sent. the payment is accepted following amendments being made.

ACWP AcceptedWithoutPosting Payment instruction included in the credit transfer is accepted Sent by Credit Agent to the previous Agent to confirm the acceptance of
without being posted to the creditor customer’s account. payment without settlement on the creditor’s account,

PDNG Pending Payment initiation or individual transaction included in the Sent by any Agent in the payment chain to the previous Agent as an
payment initiation is pending. Further checks and status interim status whilst other validations are performed.
update will be performed.

RCVD Received Payment initiation has been received by the receiving agent. Sent by Any Agent to the previous Agent as confirmation that their
Customer Credit Transfer initiation request has been received by the
payment engine.

RJCT Rejected Payment initiation or individual transaction included in the Sent by Any Agent to inform the previous Agent that their Customer Credit
payment initiation has been rejected. Transfer has been rejected.

ISO 20022 Programme - Quality data, quality payments 40

pacs.004

Payment Return

ISO 20022 Programme - Quality data, quality payments 41

 U
pacs.004 Payment Return

In a similar structure to the pacs.009 (cov)

underlying Customer Credit Transfer, the
pacs.008 pacs.009 cov pacs.004
pacs.004 Return Payment message has amongst
other elements Original Group Information which
captures original information such as the Original
UETR and Original Interbank Settlement Amount
Group Header Group Header Group Header etc. and an Original Transaction Reference which
contain the key elements of the original payment
e.g. Debtor, Creditor etc.
Credit Transfer Credit Transfer Transaction
Transaction Transaction Information
Information Information

Underlying
Customer Original Group
Credit Information

Original
Transaction
Reference

ISO 20022 Programme - Quality data, quality payments 42

pacs.002 Payment Reject and pacs.004 Return Flow
The Payment Return message is sent by an
High Level Use Case and key considerations. agent to the previous agent in the payment
chain to undo a payment previously
settled.

pacs.008 pacs.008 pacs.008

A pacs.004 B pacs.004
C pacs.002 D

+ Return + Return + Reject

Reason Reason Reason

Within the pacs.004 Return Payment

• the Original Group Information element is used to refers to original message for which the return relates to. e.g. based upon the above
example pacs.008 as the original message would be included in the pacs.004
• the Transaction Information > Original UETR element would include UETR of the message received. i.e. the same UETR is used on the
Return Payment.
• the Original Transaction Reference element includes detail from the original message. e.g. the Debtor of the original pacs.008.
• the Return Chain element includes the parties in return payment chain, noting the parties reverse (i.e. change role) from the original
payment whereby the Debtor of the original payment becomes the Creditor in the Return Chain.
• A reason code is added to the Return message to inform the agent of the reason for the return (e.g. AC04 Account closed)
The code list representing the Return Reason is
part of the ISO 20022 external code list

ISO 20022 Programme - Quality data, quality payments 43

 Payment Return (pacs.004) of a complete Customer Credit Transfer (pacs.008) Use Case p.4.1.2

1 2 3 4 5
pacs.008 pacs.008 pacs.008

A pacs.004 B pacs.004 C pacs.004 D

8 7 6
+ Return + Return + Return
Reason Reason Reason

1 3 7
Debtor initiates a payment Agent B processes the payment Creditor determines that they wish Agent C return funds to Agent B, together
instruction to the Debtor Agent on Agent C to return the payment e.g. they are with the reason code for return.
unable to apply, and instructs their
bank (Agent D) to return the
4 payment together with the reason. 8
2 Agent C processes the payment Agent B return funds to Agent A,
Debtor Agent (A) initiates a on Agent D together with the reason code for return.
serial payment towards the
Creditor Agent (D) using 6
Agent D returns the payment to
Agents B & C as intermediaries 5 Agent C using a Payment Return
Agent D credits the account of
the Creditor, and may optionally message (pacs.004) also
provide a notification e.g. including the return reason code.
notification of credit in addition . The code list representing the Return
Reason is part of the ISO 20022
to an account statement external code list
(camt.054)
ISO 20022 Programme - Quality data, quality payments
Payment Transaction Return Reason
Code definitions examples (74 total)

Code Name Definition

AC01 IncorrectAccountNumber Format of the account number specified is not correct

AC03 InvalidCreditorAccountNumber Wrong IBAN in SCT

AC04 ClosedAccountNumber Account number specified has been closed on the bank of account's books

AC06 BlockedAccount Account specified is blocked, prohibiting posting of transactions against it.

AC13 InvalidDebtorAccountType Debtor account type is missing or invalid

AC14 InvalidAgent An agent in the payment chain is invalid.

AC15 AccountDetailsChanged Account details have changed.

AC16 AccountInSequestration Account is in sequestration.
AC17 AccountInLiquidation Account is in liquidation.
AG01 TransactionForbidden Transaction forbidden on this type of account (formerly NoAgreement)

AG02 InvalidBankOperationCode Bank Operation code specified in the message is not valid for receiver

AM01 ZeroAmount Specified message amount is equal to zero Rejected by Network

AM02 NotAllowedAmount Specific transaction/message amount is greater than allowed maximum

AM03 NotAllowedCurrency Specified message amount is an non processable currency outside of existing agreement

AM04 InsufficientFunds Amount of funds available to cover specified message amount is insufficient.

AM05 Duplication Duplication

ISO 20022 Programme - Quality data, quality payments 45

Cross Border Payments & Reporting (CBPR+)
Working Group

ISO 20022 Programme - Quality data, quality payments 46

CBPR+ : A group of your peer banks advising SWIFT on how ISO 20022 should be used

Create global ISO 20022 Market Practice and Usage Guidelines

for selected messages from the SWIFT MT Category 1, 2 & 9 set of
Objective messages, which will be validated on the SWIFT network in the many
to many space.

With the approach of

 Benefiting from ISO 20022 features, and not alike for like adoption from SWIFT MT
 Interoperable with high value payment system (HVPS+) guidelines*, while differences should be
justified and documented
 Incorporating gpi requirements, such as UETR
 Incorporating securities requirements, for the cash-leg of a securities transactions
 Including new messages & functionalities where required, e.g. Return & Status messages
 Validated on the SWIFT network
 Maintained on a yearly basis
 Develop Translation Rules
HVPS+: A working group of payment marketing infrastructure operators advising SWIFT on how ISO 20022 should
be used for high value payment systems. HVPS+ has established usage guidelines for this purpose
ISO 20022 Programme - Quality data, quality payments 47
MT 103/MX pacs 008 Customer Credit Transfer – Correspondent Bank
High Level Serial message flow Translation Flow

Payment Initiation Payment Reporting

MT101 MT9XX
PAIN001 via FileAct camt 5X via FileAct

A MT 103 B MX pacs 008

C
Proprietary Proprietary
Sending Bank (MX) Receiving Bank (MX) Beneficiary
Originator Originating Bank (MT) (Instructed Bank) (Instructed Bank) (Creditor)
(Debtor) (Debtor Agent)
T

In the early days of the ISO migration Coexistence Period there will be payment scenarios where translation will be required
for a payment to be completed to the Beneficiary/Creditor

When the originating Bank sends an MT format, the process will be very straight forward as there
will be no excess data due to new fields or field length mismatches.

ISO 20022 Programme - Quality data, quality payments - BBH - March 2021 - Restricted 48
 MX pacs 008/MT 103 FI to FI Customer Credit Transfer-Correspondent Bank
High Level serial message flow Embedded MT in MX Flow

SWIFT
Payment Initiation Cloud
MT101 Payment Reporting
PAIN001 via FileAct MT9XX
MX pacs.008 camt 5X via FileAct
pacs.008 MT 103
Proprietary
A pacs.002 B C Proprietary
Debtor Creditor
Debtor Agent (MX) Instructing Agent(MX) Instructed Agent (MT)

During the Coexistence Period when the Debtor Agent initiates an MX and a translation to MTs required
there can be payment scenarios where additional fields, and, additional data in those fields,
may result in an excess data condition.

ISO 20022 Programme - Quality data, quality payments - BBH - March 2021 - Restricted 49
Example MX/MT Agent Field Tag (e.g. 56) Type A Format

MX MT

<IntrmyAgt1>
<FinInstnId>
<BICFI>BDLIITGGXXX</BICFI>
<ClrSysMmbId>
<ClrSysId>

<Cd>ITNCC</Cd>
</ClrSysId> :56A:/IT27Z0123401600000000148292
<MmbId>0123401600</MmbId>
</ClrSysMmbId> BDLIITGGXXX
<Nm>Banca dei Lavoratori Italiani</Nm>
</FinInstnId>
</IntrmyAgt1>
<IntrmyAgt1Acct>
<Id>
<IBAN>IT27Z0123401600000000148292</IBAN>
</Id>
</IntrmyAgt1Acct>

ISO 20022 Programme - Quality data, quality payments - BBH - March 2021 - Restricted 50
Example MX/MT Agent Field Tag (e.g.56) Type D Format

MX MT

<IntrmyAgt1>
<FinInstnId>
<ClrSysMmbId>
<ClrSysId> :56D://IT0123401600
<Cd>ITNCC</Cd>
</ClrSysId> Banca dei Lavoratori Italiani
<MmbId>0123401600</MmbId>
</ClrSysMmbId> Via dei Gigli,1,Palazzo Viola,7 Pi+
<Nm>Banca dei Lavoratori Italiani</Nm>
<PstlAdr> IT/Milano,20100,Quartiere Isola,Lom
<StrtNm>Via dei Gigli</StrtNm>
<BldgNb>1</BldgNb>
bardia,Provincia di Milano
<BldgNm>Palazzo Viola</BldgNm>
<Flr>7 Piano</Flr>
<PstCd>20100</PstCd>
<TwnNm>Milano</TwnNm>
<TwnLctnNm>Quartiere Isola</TwnLctnNm>
<DstrctNm>Provincia di Milano</DstrctNm>
<CtrySubDvsn>Lombardia</CtrySubDvsn>
<Ctry>IT</Ctry>
</PstlAdr>
</FinInstnId>
</IntrmyAgt1>

ISO 20022 Programme - Quality data, quality payments - BBH - March 2021 - Restricted 51
Example MX/MT Debtor/Creditor (50,59) Unstructured Name and Address

MX MT

<Dbtr>
<Nm>Hamburgische Hochwertige Landesbank eG</Nm>
<PstlAdr>
<AdrLine>Gebaude 5</AdrLine>
<AdrLine>Hafenstrasse 7</AdrLine>
<AdrLine>22767 Hamburg, DE</AdrLine> :50K:/123
</PstlAdr> Hamburgische Hochwertige Landesban+
<CtryOfRes>DE</CtryOfRes>
</Dbtr>
Gebaude 5
<DbtrAcct> Hafenstrasse 7
<Id> 22767 Hamburg, DE
<Othr>
<Id>123</Id>
</Othr>
</Id>
</DbtrAcct>

ISO 20022 Programme - Quality data, quality payments - BBH - March 2021 - Restricted 52
Example MX/MT Debtor/Creditor (50,59) Structured Name and Address

MX MT

<Dbtr>
<Nm>Mueller Weltweit Handels GmbH</Nm>
<PstlAdr>
<StrtNm>Hafenstrasse</StrtNm>
<BldgNb>7</BldgNb>
<BldgNm>Willy-Brandt Gebaude</BldgNm>
<Flr>3 OG</Flr>
:50F:/DE25390200000004711001
<PstBx>1203</PstBx> 1/Mueller Weltweit Handels GmbH
<Room>C3B</Room>
<PstCd>22767</PstCd> 2/Hafenstrasse,7,Willy-Brandt Geba+
<TwnNm>Hamburg</TwnNm>
<TwnLctnNm>St. Pauli</TwnLctnNm>
3/DE/Hamburg,22767,St. Pauli
<Ctry>DE</Ctry> 6/DE/LEIC/TX1CDTRORGIDLEI67890
</PstlAdr>
<Id>
– <OrgId>
– <LEI>TX1DBTRORGIDLEI67890</LEI>
– </OrgId>
</Id>
<CtryOfRes>DE</CtryOfRes>
</Dbtr>
<DbtrAcct>
<Id>
<IBAN>DE25390200000004711001</IBAN>
</Id>
</DbtrAcct>

ISO 20022 Programme - Quality data, quality payments - BBH - March 2021 - Restricted 53
Remittance Information Mapping - Definition

Logic

The MT Remittance Information is translated When the originating message is MX, the MT remittance
applying prioritizing the information. information is translated with the following identifiers:

Information is likely to be truncated and • /ULTB/ - UltimateCreditor information prioritized as

identified in most cases with the sign “+” at Name/Country [/TownName]. TownName is optional or
the end of the translated information. If a full (Name/OtherId) or Name alone or OtherId alone.
element is not copied an Error Handling • /ULTD/ - UltimateDebtor information prioritized as
mechanism will be defined to report the Name/Country/TownName. TownName is mandatory or
missing information. (Name/OtherId) or Name alone or OtherId alone.
• /PURP/ - purpose of the payment
In all cases, UltimateDebtor and • /ROC/ - EndToEndIdentification when /ROC/ is not present in
UltimateCreditor will have the highest UnstructuredRemittanceInformation and value different from
translation priority in the MT Field 70. “NOTPROVIDED”.
• /URI/ - the MX unstructured remittance information
• /RELID/ - 1 or 2 identifications of the
RelatedRemittanceInformation stored outside the message
• /SRI/+ - means that structured remittance information is present
in the original message but is not translated.

Note: /URI/, /RELID/ and /SRI/+ are mutually exclusive meaning

cannot be present together (even not by pair).

ISO 20022 Programme - Quality data, quality payments - BBH - March 2021 - Restricted 54
Example MX/MT Remittance Information (70)

MX MT

<CdtTrfTxInf>
<PmtId>
<InstrId>INSTRID-TMP001</InstrId>
<EndToEndId>END2ENDID-TMP001</EndToEndId>
<UETR>4f334519-092f-49fa-acf9-ce93c267ac8c</UETR>
</PmtId>
[…]
:70:/ULTB/Sivesh S///ULTD/Tower and Tow
<UltmtDbtr> n Inc.///ROC/END2ENDID-TMP001///URI
<Nm>Tower and Town Inc.</Nm> /BELEG 1301 2019 RG.OPTIK/03/19-20
</UltmtDbtr> V.312589RG.OPTIK/ 02/19-20 V.200619
[…]
<UltmtCdtr>
<Nm>Sivesh S</Nm>
</UltmtCdtr>
<RmtInf>
<Ustrd>BELEG 1301 2019 RG.OPTIK/03/19-20
V.312589RG.OPTIK/ 02/19-20 V.200619</Ustrd>
</RmtInf>
</CdtTrfTxInf>

ISO 20022 Programme - Quality data, quality payments - BBH - March 2021 - Restricted 55
Bank to Bank Information Mapping - Definition

Logic

Depending on the space available and the presence of the Note:

elements in the MX message, the following priorities and order Possible missing (Error Handling
are applied to field 72 Bank to Bank Information: mechanism will be defined to report the
missing information) or truncated
• /INTA/ - IntermediaryAgent 2 & 3* information can apply.
• /SVCLVL/ - PaymentTypeInformation/ServiceLevel
*(excluding 23E code – SDVA and G00n gpi codes)
*means new code words to be used in Field72
• /LOCINS/ - PaymentTypeInformation/LocalInstrument **/FIN54/ with BIC is used in a specific
*(excluding 23B codes) scenario in MT to indicate where the receiver
• /CATPURP/ - PaymentTypeInformation/CategoryPurpose will claim the money. This code word will be
*(excluding 23E codes) present only if a previous MT to MX translation
• /ACC/ - InstructionForCreditorAgent (excluding 23E codes) already occurred.
• /REC/ - InstructionForNextAgent (excluding /FIN54/**)
• /INS/ - PreviousInstructingAgent1,2,3

ISO 20022 Programme - Quality data, quality payments - BBH - March 2021 - Restricted 56
Example MX/MT Bank to Bank Information (72)

MX MT

<PmtTpInf>
<SvcLvl>
<Prtry>Single Euro Payments Area</Prtry>
</SvcLvl>
<LclInstrm>
<Prtry>Cash Concentration Intragroup</Prtry> :72:/INTA/BCITITMMXXX
</LclInstrm>
</PmtTpInf> /INTA/BARCIE22XXX
<IntrmyAgt2> /SVCLVL/Single Euro Payments Area
<FinInstnId>
<BICFI>BCITITMMXXX</BICFI>
/LOCINS/Cash Concentration Intragro
</FinInstnId> //up
</IntrmyAgt2> /REC/Instruction number 1Instructi+
<IntrmyAgt3>
<FinInstnId>
<BICFI>BARCIE22XXX</BICFI>
</FinInstnId>
</IntrmyAgt3>
<InstrForNxtAgt>
<InstrInf>Instruction number 1</InstrInf>
</InstrForNxtAgt>
<InstrForNxtAgt>
<InstrInf>Instruction number 2</InstrInf>
</InstrForNxtAgt>
</CdtTrfTxInf>

ISO 20022 Programme - Quality data, quality payments - BBH - March 2021 - Restricted 57
Example of Regulatory Reporting Information

MX MT
<Cdtr>
<Nm>ABC IMPORTS AND EXPORTS (INDIA) </Nm>
<PstlAdr>
[…]
</PstlAdr>
<Id>
<OrgId>
<LEI>335800HMLW2U4UHRBW65</LEI>
</OrgId>
</Id>
:77B:AAASDASAD/BENEFRES/DE
<CtryOfRes>DE</CtryOfRes>
</Cdtr>
[…]
<RgltryRptg>
<DbtCdtRptgInd>CRED</DbtCdtRptgInd>
<Authrty>
<Nm>Reserve Bank of India</Nm>
<Ctry>IN</Ctry>
</Authrty>
<Dtls>
<Tp>Export Reporting</Tp>
<Dt>2019-01-13</Dt>
<Ctry>IN</Ctry>
<Cd>P0102</Cd>
<Amt Ccy="USD">123456891234567.50</Amt>
<Inf>AAASDASAD</Inf>
</Dtls>
<RgltryRptg>

ISO 20022 Programme - Quality data, quality payments - BBH - March 2021 - Restricted 58
Example of Settlement Time

MX MT

<CdtTrfTxInf>
…
<SttlmTmIndctn>
<DbtDtTm>2018-01-04T15:12:09+09:59</DbtDtTm>
<CdtDtTm>2018-01-04T15:12:09+09:59</CdtDtTm>
:13C:/SNDTIME/1512+0959
</SttlmTmIndctn> :13C:/RNCTIME/1512+0959
<SttlmTmReq> :13C:/CLSTIME/0930+0500
<CLSTm>09:30:47+05:00</CLSTm> :13C:/TILTIME/0930+0500
<TillTm>09:30:47+05:00</TillTm> :13C:/FROTIME/0930+0500
:13C:/REJTIME/0930+0500
<FrTm>09:30:47+05:00</FrTm>
<RjctTm>09:30:47+05:00</RjctTm>
</SttlmTmReq>
…
</CdtTrfTxInf>

Illustration included multiple settlement times. It is unlikely all of the

ISO 20022 Programme - Quality data, quality payments - BBH - March 2021 - Restricted examples used would be included in a transaction at the same time. 59
Usage guidelines

Where can I find more information?

ISO 20022 Programme - Quality data, quality payments 60

MT/ISO 20022 Translation rules – Where to find out more

Q1 2020 User Handbook

iteration will include a full section
describing the Translation
mapping principals.

MT/ISO 20022 Translation

section of the CBPR+ landing
page

https://www2.swift.com/mystandards/#/c/cbpr/landing

ISO 20022 Programme - Quality data, quality payments 61

Where can I get more help?
New resources are available for vendors

Further webinars & work sessions SWIFTSmart Documentation

The SWIFTSmart e-learning training The Updated ISO 20022 for
Join a webinar or work session near you
platform includes an introduction to ISO Dummies e-book is available to
to learn why ISO 20022 adoption is
20022. A formal curriculum will be understand the basics of ISO
necessary, how to make the change and
published by end of the year 20022 and implications for
what support SWIFT will provide
financial messaging

ISO 20022 vendor landing page MyStandards Knowledge Centre

WWW The ISO 20022 vendor landing page The CBPR+ MyStandards page hosts all The Knowledge Centre hosts detailed
provides more information on the usage guidelines, a readiness portal for documentation on SWIFT products
programme, timeline, transition period testing your back office applications and services, including the SWIFTNet
and resources coming soon a mapping sandbox to messaging service that will be the basis
publish translation rules for the new InterAct service to support
CBPR+ compliant flows

Partner Programme Vendor support

Join the Partner Programme to gain Partner Programme member support is
access to further support. The available to help you through ISO 20022
Programme also helps SWIFT migration, get trained, and support your
customers to make well-informed implementation.
purchasing and implementation
decisions, and providers to differentiate
their offerings in a crowded market
place.

ISO 20022 Programme - Quality data, quality payments 62

www.swift.com