Implementing Your Project 2011 Standards MX Message Implementation Guide

Solutions
SWIFT for Corporates
Standards MX Message Implementation

Guide and Rule Book
Payment Initiation and Account Reporting
This document describes and references a set of rules and guidelines you must follow when you
implement, send or receive ISO 20022 payment initiation and account reporting messages using FileAct
in SCORE (Standardised Corporate Environment)
01 December 2011
Preface
Table of Contents
1 Message Rules and Guidelines.......................................................................................... 5
1.1 Key Rules .................................................................................................................... 5
1.2 Rule and Guideline Conventions ................................................................................ 6
2 Payment Initiation ............................................................................................................... 9

2.1 Overview ..................................................................................................................... 9
2.2 Customer Credit Transfer Initiation ........................................................................... 10
2.3 Payment Status Report ............................................................................................. 17
2.4 Customer Direct Debit Initiation ................................................................................ 25
3 Account Reporting ............................................................................................................ 28

3.1 Overview ................................................................................................................... 28
3.2 Account Reporting Messages ................................................................................... 29
4 Common Message Components...................................................................................... 42
5 Mapping Guidelines MX - MT ........................................................................................... 47

5.1 Mapping from pain.001 to MT 940 ............................................................................ 47
5.2 Mapping from pain.001 to MT 103 ............................................................................ 48
6 Comparison MT - MX......................................................................................................... 55
6.1 Comparison MT 942 to camt.052 .............................................................................. 56
2 Standards MX Message Implementation Guide (Dec 2011)

Preface
Preface
Purpose of this document
SWIFT has designed this document to promote an industry implementation standard for :
• Payment Initiation - customer initiated credit transfers, direct debits, and reporting back on
the status of these transfers, using the ISO 20022 Customer Credit Transfer Initiation, the
ISO 20022 Customer Direct Debit Initiation and ISO 20022 Payment Status Report
messages.
• Account Reporting - bank-to-customer reporting of account activity information, using the
ISO 20022 Bank-to-Customer Account Report, the ISO 20022 Bank-to-Customer
Statement, and the ISO 20022 Bank-to-Customer Debit/Credit Notification messages.
By using these messages on SWIFTNet, each user agrees to abide by the minimum rules and
guidelines applicable to them, as specified in the sections that follow and in the referenced CGI
implementation templates.
For the avoidance of any doubt, nothing in these documents shall be binding upon SWIFT nor
construed as constituting an obligation, representation, or warranty on the part of SWIFT.
The scope of these guidelines

In summary, the aim of developing these guidelines is to facilitate automation by :
• ensuring common interpretation and understanding of data elements included in the
messages, and
• ensuring common implementation of functionalities covered through the messages.
Document Release Management

This document represents a significant update to the previous version:
Standards MX Message Implementation Guide and Rule Book, Payment Initiation and
Account Reporting, 17 June 2009
Summary of differences:
• ISO 20022 Message Updates – adoption of later ISO 20022 message versions:
- camt.052.001.02 BankToCustomerAccountReportV02
- camt.053.001.02 BankToCustomerStatementV02
- camt.054.001.02 BankToCustomerDebitCreditNotificationV02
- pain.001.001.03 CustomerCreditTransferInitiationV03
- pain.002.001.03 CustomerPaymentStatusReportV03
- pain.008.001.02 CustomerDirectDebitInitiationV02
• CGI Message Implementation Templates – adoption of CGI message implementation
templates as the base implementation reference source for payment intitiation and cash
management messages in SCORE:
- ISO 20022 Credit Transfer V3 Message Implementation Guide 13 June 2011
- ISO 20022 Payment Status Report V3 Message Implementation Guide 13 June 2011
- ISO 20022 Direct Debit V2 Message Implementation Guide 28 July 2011
- ISO 20022 Cash Management V2 Message Implementation Guide 28 July 2011

Preface
In order to faciliate the migration from the previous version of the guidelines to the latest
version, SCORE supports both the latest version of the implementation guide and the prior
version, namely:
• Standards MX Message Implementation Guide, Payment Initiation and Account Reporting,
17 June 2009
• Standards MX Message Implementation Guide and Rule Book, Payment Initiation and
Account Reporting,18 November 2011
Acknowledgements
SWIFT acknowledges the contribution of the participants in the Common Global
Implementation (CGI) initiative.
The aim of CGI is to provide a forum for financial institutions (banks and bank associations) and
non-financial institutions (corporates, corporate associations, vendors and market
infrastructures) to progress various bank-to-corporate implementation topics on the use of ISO
20022 message and to other related activities.This is achieved through consultation,
collaboration and agreement on common implementation templates for relevant ISO 20022
financial messages, leading to their subsequent publication and promotion in order to attain
widespread recognition and adoption.
CGI is structured as an ad hoc, voluntary, non-legal forum that is open to financial and non-
financial institutions having a common interest in collaboration, promotion and adoption of the
ISO 20022 XML financial message set. SWIFT is both a contributor and the support
organisation for the CGI initiative.
Contributors to the CGI include:
• Financial Institutions : Bank of America Merrill Lynch, Barclays, BBVA, BSK, Citibank,
Danish Bankers Association, Danske Bank, Deutsche Bank, DnB NOR, HSBC, ING Bank,
J.P.Morgan, Nordea Bank, Royal Bank of Scotland, Santander, SEB , Standard Chartered
Bank, Sydbank A/S, UK Payments Administration, UniCredit Bank.
• Non-financial institutions : Bottomline Technologies, CBI Consortium, General Electric,
GXS, Nets, Sungard, UTSIT, XMLdation, SAP AG.
Document structure
This guide is structured as follows:
• Section 1 covers the Key Rules and specific Implementation Rules and Guidelines
• Section 2 covers the payment initiation messsages
• Section 3 covers the account reporting messages
• Section 4 covers the common message components
• Section 5 provides a set of mapping guidelines for the ISO 20022 payment initiation
messages to the subsequent MT messages
• Section 6 provides a comparison of the account reporting MT messages with the
corresponding ISO 20022 messages.

Message Rules and Guidelines
1 Message Rules and Guidelines

1.1 Key Rules
Support of ISO 20022 Messages
For Payment Initiation and Account Reporting the following ISO 20022 Messages are
applicable:
camt.052.001.02 BankToCustomerAccountReportV02
camt.053.001.02 BankToCustomerStatementV02
camt.054.001.02 BankToCustomerDebitCreditNotificationV02
pain.001.001.03 CustomerCreditTransferInitiationV03
pain.002.001.03 CustomerPaymentStatusReportV03
pain.008.001.02 CustomerDirectDebitInitiationV02
SCORE requires for Payment Initiation that users support the Customer Credit Transfer
Initiation (pain.001) message to initiate electronic transfers and the Payment Status Report
(pain.002) message to provide ‘positive’ and ‘negative’ status information on the operational
status of the transfer. For the other messages, support is dependant on the services that the
bank offers.
Provision needs to be made that allows for future updates to the associated Message Definition
Report, to this Implementation Guide and Rule Book and to the referenced CGI implementation
templates.
Compliance
Users using the messages on SWIFTNet commit to comply with the standards as described in
the ISO 20022 Message Definition Report (which contains the same message specifications as
the SWIFTStandards MX Message Reference Guide) and when published, the corresponding
Message Usage Guide.
This means that :
• all mandatory data in the schema should be provided, logic embedded in the schema should
be respected, and rules and guidelines defined for the generic ISO 20022 messages should
also be adhered to.
• values not supported by the schema should not be present (ie an XML instance containing
an element not present in the schema, would cause an error when the instance is validated
against the schema).
Note : If an instance contains such a schema mistake, it is up to the recipient to decide how
to react (ie either accept and process, or reject).
In addition, users must also comply with the minimum implementation rules as outlined in the
sections below.
Technical implementation rules
Instances (ie actual messages exchanged) should not contain ‘empty tags’ – ie should not
contain elements which do not contain ‘content’.
Operational rules
Optional elements, which are included in the schema, but which are not considered to be key
for transactions in scope and which are however present in the message instance (included in
the instance by the Sender) may be ignored (i.e. not used for processing and not passed on) by
the Receiver (i.e. would not be a cause for rejecting the message).

Where the recipient may not actually require this ‘surplus’ information, it will be viewed as ‘data
overpopulation’ and will be ignored. This applies for both corporate to bank and bank to
corporate messages. Under CGI, this concept of data overpopulation provides the core
foundation to establishing a single generic harmonised template.
Character set
• All banks subscribing to the SCORE service will support the following characters :
abcdefghijklmnopqrstuvwxyz
ABCDEFGHIJKLMNOPQRSTUVWXYZ
0123456789
/ - ? : ( ) . , ' + Space
• Banks can support additional characters/character sets as part of their service offering.
• The EndToEndIdentification should always be expressed in the character set referred to
under the first bullet above.
• Depending on supported character sets in the interbank clearing and settlement channels,
banks may have to convert the characters contained in text-based elements received in the
payment initiation messages.
• For guidance on how to represent ‘disallowed characters in XML content’, please refer to
the section SWIFTStandards Supported Character Sets, under SWIFTStandards XML for
Standards MX Messages in the User Handbook.
1.2 Rule and Guideline Conventions

The ISO 20022 Message Definition Report contains full standard specifications and rules that
must be adhered to. When published, a corresponding Message Usage Guide would contain a
series of topics illustrating these standard specifications and rules.
As the messages enable various degrees of complexity and flexibility in implementation, some
additional usage rules and guidelines have been defined and referenced in the context of this
document.
The rules and guidelines adopted by SCORE are defined in the respective CGI Message
Implementation Templates and associated Appendices, as developed and approved by the
CGI. These globally agreed templates are designed to provide clear guidance, in terms of
which XML fields are required, optional, bilaterally determined or not used from both a core
message and local country rules perspective.
An overview of the templates can be found below. The specific template references are
indicated in the individual message descriptions in the sections that follow. These message
descriptions also depict the schema structures, components and elements. While a limited
number of usage rules and guidelines are replicated in the message descriptions, the CGI
Message Implementation Templates should serve as the definitive reference.
Message components that are common to a number of messages are shown in section 4.
CGI Implementation Templates

The CGI message implementation templates provide the opportunity to establish generic
harmonised multi-banking ISO 20022 XML messages. It should also be noted that this may not
be the only implementation that banks will support. Some banks may be able to offer value
added solutions that are over and above the core CGI message implementation template.
For futher information see the SWIFT for Corporates Resource Centre and
SwiftCommunitiy.Net
CGI publishes their guidance in the form of:

Message Rules and Guidelines
Document Type Description

Core Template This represents the core CGI implementation guidance for the use
of the designated ISO 20022 message.
For corporate-to-bank flows it defines all the elements that are
mandated by the schema or CGI required, that will be accepted by
all CGI supporting banks.
For bank-to-corporate flows it defines all the elements that are
mandated by the schema or CGI required, that will be provided by
all CGI supporting banks.
Each template may further qualify the content, for example by
payment instrument type.
Appendices Additional implementation information to support message use in a
particular context (e,g. country/region specific requirements) or to
provide reference information (e,g. local instrument codes).
Appendix are created, when appropriate, based on the business
requirements of a specific message and may be subject to a more
frequent revision cycle.
In the CGI Implementation Templates, specific usage of a data element is designated with one
of the following codes. Additional detail is provided in the template “Rules” column, including
recommendations and best practice that must be followed whenever possible.
CGI Implementation Template Attributes

Codes Term Definitions
R Required Standard element for CGI; Required either by schema or
CGI
C Conditional Standard element for CGI; Dependent upon a certain
condition.
BD Bilaterally Determined Standard element for CGI. Contents are bilaterally
determined between client and bank
XOR eXclusive Or Standard element for CGI. Contents are XOR either by
the schema or CGI usage.
NU Not Used Not Specified by CGI
Schema Diagram Conventions: In the sections that follow a number of schema diagrams are
provided to illustrate the relevant components and elements of the individual messages. The
symbols denote the following:
Box with a full line is a mandatory message element (also

expressed in text as ‘1..1’)
Box with a dotted line is an optional message element (also

expressed in text as ‘0..1’)

The component can contain a number of mandatory and optional elements. The
elements must appear in the sequence mentioned
The component contains a number of elements. Only one of the possible elements
may be present (choice).

Payment Initiation
2 Payment Initiation
2.1 Overview
The implementation rules and guidelines included in this chapter relate to the following ISO
20022 Payment Initiation messages :
• Customer Credit Transfer Initiation Version 3 (pain.001.001.03)
• Customer Direct Debit Initiation Version 2 (pain.008.001.02)
• Payment Status Report Version 3 (pain.002.001.03)
Further Customer-to-Bank Payment Initiation messages may be added in a later phase.

Chapter 3 deals with the Bank-to-Customer Account Reporting messages.
Maintenance
The current version of this document is based on version 2/3 of the above pain messages.
Publication of new versions of these messages on www.iso20022.org may require the
document to be revised at a future date, in concert with the approval and publication of the
associated CGI Message Implementation Templates.
Documentation
The standards covered by this document are fully described in :
• ISO 20022 Message Definition Report – Payment Initiation (www.iso20022.org). This
report contains the full description of the standards (scope, format specifications, definitions
for all elements, rules and guidelines defined for the generic standards). It contains

descriptions for the ‘full’ ISO 20022 Payment Initiation portfolio, ie, it also included other
‘payment initation’ messages.
• ISO 20022 Message schema’s and samples (pain.001.001.03, pain.002.001.03 and
pain.008.001.02) (www.iso20022.org)
• ISO 20022 Customer to Bank Message Usage Guide – Customer Credit Transfer
Initiation, Customer Direct Debit Initiation and Payment Status Report (www.iso20022.org).
When published, the ISO Message Usage Guide (‘MUG’) will provide generic illustrations
and explanations about the standard. It is designed to complement the ISO Message
Definition Report.
• SWIFTStandards MX Message Reference Guide –
(www.swift.com/corporates/resource.htm) contains the same information as the ISO 20022
Message Definition Report, but includes the cash reporting messages and is also available
in HTML format.
• CGI Message Implementation Template – (www.swiftcommunity.net/cgi) contains the
specific rules and implementation guidance.
The documentation referred to above contains the full standard specifications and rules that
must be adhered to. This document contains further explanatory notes and additional usage
rules and guidelines to facilitate common implementation and usage of these standards using
FileAct in SCORE (Standardised Corporate Environment).
2.2 Customer Credit Transfer Initiation

Scope
The Customer Credit Transfer Initiation message is sent by the initiating party to the forwarding
agent or debtor agent.
It is used to request movement of funds from the debtor account to a creditor.
Standard Specifications
The ISO 20022 Message Definition Report and when published/updated the ISO 20022
Customer-to-Bank Message Usage Guide serve as the main documents describing the
standards. Please consult these documents for full information.
CGI Message Implementation Templates
The following CGI Message Implementation Templates provide the specific usage rules and
guidelines. Please consult these documents for full information.
Template Name Date
ISO 20022 Credit Transfer V3 Message Implementation Guide 13 June 2011

Appendix A – Payment System References Latest version
Appendix B – Country Specific Requirements Latest version
Message Schema Components

The Customer Credit Transfer Initiation message is composed of the structures that follow.

Payment Initiation
Customer Credit Transfer Initiation (pain.001.001.03)

Message Level

Customer Credit Transfer Initiation (pain.001.001.03)

Transaction Level

Payment Initiation
Specific Rules and Guidelines

In the framework of this document, where additional SCORE specific rules and guidelines have
been defined these are notated below as “SCORE Rule” or SCORE Guideline”. Where an
earlier SCORE Rule has been superseded by a CGI Rule these are noted as “CGI Rule” or
“CGI Guideline” and have been retained for consistency reasons in this version of the guide.
File
SCORE Rule Per FileACT file, include only 1 pain message
Payment Type Information

2.6 / 2.31 (Payment Information/Payment Type Information and Credit Transfer Transaction
Information/ Payment Type Information) (0..1)
CGI Rule Required at either Payment or Transaction Level, but should not be
present at both levels. Recommended usage is at Payment level.
Charge Bearer
2.24 / 2.51 (Payment Information/Charge Bearer and Credit Transfer Transaction
Information/Charge Bearer) (0..1)
CGI Rule Conditional based on payment transaction. Should be used exclusively
at the payment or transaction level.
Ultimate Debtor
2.23 / 2.70 (Payment Information/Ultimate Debtor and Credit Transfer Transaction Information/
Ultimate Debtor) (0..1)
CGI Rule Conditional based on business need and payment transaction.
Batch Booking
2.3 (Payment Information/BatchBooking) (0..1)
SCORE Guideline 1 Batch Booking can be populated as an optional element but is not
required.
SCORE Guideline 2 If Batch Booking is not present, pre-agreed client-bank conditions will
apply.
SCORE Guideline 3 The Batch Booking element is a request, not an order. If batch booking
is requested, banks will respect this request on a ‘best effort’ basis : ie,
the logical organization of the message expresses how the corporate
intends batch booking to be actioned. Banks will try to book as such.
Banks will pre-agree with their customer criteria for batching
(depending on payment type, etc).

Instruction Priority
2.32 (Payment Information/PaymentTypeInformation/Instruction Priority) (0..1)
CGI Rule Based on whether priority processing versus normal processing is
offered by the bank.
SCORE Guideline If not present, following applies : Instruction Priority is an in-bank
processing queue priority where the bank offers the ability to change
the priority for processing of a transaction type. It is only used in these
cases and its absence is read as “normal” processing priority for the
bank’s normal service level for that transaction type and customer.
There is no relationship between instruction priority and category
purpose.
Service Level
2.33 (Payment Information/PaymentTypeInformation/Service level (0..1)
CGI Rule If an instrument or country is not listed on CGI Appendix A (Payment
System References), agreement will be bilateral until included on the
list.
SCORE Guideline If the initiating party would like to request a payment to be processed
as a SEPA payment, it is recommended to provide the code SEPA in
Service Level/Code.
Banks will make best efforts to process as such, i.e. are not bound to
guarantee that the transaction will indeed be processed as SEPA – as
it will depend on certain criteria whether the bank can do so.

Payment Initiation
Local Instrument
2.36 (Payment Information/PaymentTypeInformation/Local instrument) (0..1)
CGI Rule If an instrument or country is not listed on CGI Appendix A (Payment
System References), agreement will be bilateral until included on the
list.
Remittance Identification
2.92 (Payment Information/CreditTransferTransactionInformation/RelatedRemittance
Information/RemittanceIdentification) (0..1)
SCORE Guideline If the Related Remittance Information component is used, and a
Remittance Identification is provided, it is recommended that the
RemittanceIdentification equal the EndToEndIdentification.
References
The message contains a number of mandatory and optional references. The definition of these
references can be found in the ISO 20022 Message Definition Report. The most recent ISO
20022 Customer-to-Bank Message Usage Guide for the Customer Credit Transfer Initiation
message contains a large number of explanatory illustrations and scenarios.
Below find a short extract of the ISO 20022 Customer-to-Bank Message Usage Guide to
provide context around the rules and guidelines.
Point-to-point references :
− 1.1 Message ID (1..1)
− 2.1 Payment Info ID (1..1)

Payment transaction reference :

− 2.29 Instruction ID (0..1)
− 2.30 End to End ID (1..1)
Underlying transaction (remittance) references :
− 2.92 Remittance Identification
− 2.126 Creditor Reference
− 2.107 Referred document number
Mandatory references which are included in the standard are the Message ID, Payment Info ID
and the End-to-End ID. The End to End ID should be carried through the end-to-end payment
chain, and be reported to the Creditor. The End to End ID is a payment reference generated by
the originator. It can form the basis for a beneficiary who wants to investigate the payment
transaction.
Note : The End-to-End ID is intended as a unique identifier exchanged between the debtor and
creditor and is not intended for use by the agents of the interbank chain. They will use
other references as the primary key in tracking and investigating transactions.
Reference Truncation principle

SCORE Rule If references need to be truncated by the Debtor’s Agent (in view of
existing length constraints in legacy applications/interbank clearing and
settlement systems), they will always be truncated from the right.
Duplicate checking
Is an optional service to be agreed on between bank and customer.
Duplicate checking
SCORE Guideline Set of elements to be used :
File level : Group Header/Message ID
Transaction : Credit Transfer Transaction/EndToEnd ID
Unique by sender/customer Id :Other elements identified by bank

Payment Initiation
2.3 Payment Status Report

Scope
The Payment Status Report 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 may also be used to report on a pending instruction.
The ISO 20022 Message Definition Report and the ISO 20022 Customer-to-Bank Message
Usage Guide serve as the main documents describing the standards. Please consult these
documents for full information.
The following CGI Message Implementation Template provides the specific usage rules and
Template Name Date
ISO 20022 Payment Status Report V3 Message Implementation Guide 13 June 2011

The Payment Status Report message is composed of the following structure.

Payment Status Report (pain.002.001.03)

Message Level

Payment Initiation
Payment Status Report (pain.002.001.03)

Transaction Information and Status Level

Payment and Status Flow

The diagrams below from CGI illustrate the potential usage scenarios covered by the Payment
Status Report.

Payment Initiation

Specific SCORE Rules and Guidelines

In the framework of this document, a set of ‘minimum’ usage rules has been defined. All banks
subscribing to the SCORE service agree to comply with these minimum usage rules. Further
status reporting service offering is to be agreed bilaterally between the customer and its bank.
Subscribers to the SCORE service agree to always provide back a Payment Status Report
back to the initiating party after receiving a Customer Credit Transfer Initiation message.
The diagram and the table below illustrate the usage scenarios covered by the Payment Status
Report in the framework of this document.It corresponds to the second scenario above
(Support of Payment and Transaction Status Report message - one or more messages)
The diagram includes the two main ‘checkpoints’ at which a Payment Status Report will/can be
sent
• Banks agree to always send a Payment Status Report at checkpoint 1.
• At checkpoint 2, a Payment Status Report must only be sent if transactions cannot be
executed (as minimum rule in this document).
As stated above, further status reporting service offering is to be agreed between a customer
and its bank.
Payment Status Report at ‘checkpoint’ 1 (illustrated in diagram above)

SCORE Rule 1 1. All transactions included in the Customer Credit Transfer
Initiation are ‘positive’ :
Group Status must be present and contains :
a. ACTC Accepted Technical Validation
Authentication and syntactical and semantical validation are
successful.

Payment Initiation
Or
b. ACCP Accepted Customer Profile
Preceding check of technical validation was successful. Customer
profile check was also successful.
In this scenario, no further information on Transaction level is
provided.
It needs to be pre-agreed between a customer and its bank which
of these values will be provided.
SCORE Rule 2 2. The complete message is rejected – ie the lifecycle of all

instructions included in the initiation message stops.
Group Status must be present and contains ‘RJCT Rejected’.
Status Reason information (in Original Group Information and
Status) can be included to provide further reasons for the reject.
SCORE Rule 3 3. Some transactions included in the initiation are accepted, others
are rejected, pending or accepted with change.
Group Status must be present and contains ‘PART Partially
Accepted’.
Banks will offer a choice (in ‘Transaction Information and Status’
level/Transaction Status) ) between providing:
> only a status for those transactions which are rejected (RJCT)
and/or pending (PDNG)
Or
> a status for each transaction (ACTC Accepted Validation/ACCP
Accepted Customer Profile/ACWC Accepted with Change/PDNG
Pending/RJCT Rejected)
It needs to be pre-agreed between a customer and its bank which

of these 2 modes needs to be provided.
SCORE Rule 4 Minimum set of data when referring to an original individual
transaction in the Payment Status Report :
mandatory to include the End to End ID
optional to include the Instruction ID (when present in the
initiation)
mandatory to include the Payment Info ID (when present in the
initiation)
Inclusion of additional original transaction details in the Payment
Status Report to refer to a particular transaction needs to be pre-
agreed between a customer and its bank.
Payment Status Report at ‘checkpoint’ 2 (illustrated in diagram above)

Is mandatory only if transactions cannot be executed.
SCORE Rule 1 If a first Payment Status Report has been sent with ACTC or
ACCP as Group Status, and, during the further process, all, some
or one of the transactions cannot be processed by the Debtor
Agent, the Debtor Agent must send a Payment Status Report.
Group Status information should not be present and Transaction
Status must contain : Rejected.

Reason Information for the Reject can be included in the Status

Reason information.
In this case, the Payment Status Report will only include those
transactions that are rejected.
The same minimum data set as quoted under Rule 4 should be

included to refer to an individual transaction.

Payment Initiation
2.4 Customer Direct Debit Initiation

Scope
The Customer Direct Debit Initiation message is sent by the initiating party to the forwarding
agent or creditor agent.
It is used to request single or bulk collection(s) of funds from one or various debtor's account(s)
for a creditor.
The ISO 20022 Message Definition Report and when published/updated the ISO 20022
Customer-to-Bank Message Usage Guide serve as the main documents describing the
standards. Please consult these documents for full information.
Template Name Date
ISO 20022 Direct Debit V2 Message Implementation Guide 28 July 2011

The Customer Direct Debit Initiation message is composed of the structures that follow.

Customer Direct Debit Initiation (pain.008.001.02)

Message Level

Payment Initiation
Customer Direct Debit Initiation (pain.008.001.02)

Transaction Level

3 Account Reporting
3.1 Overview
The Cash Management business area contains messages that support the management,
reporting and advising of the cash side of any financial transaction, including liquidity transfers,
limit and reservation management, reporting on cash movements, transactions and balances,
and any exceptions and investigations related to cash transactions.
Bank-to-Customer Account Reporting is one suite of messages within Cash Management and
is represented by the three messages included in these guidelines :
• Bank-to-Customer Account Report Version 2 (camt.052.001.02 )
• Bank-to-Customer Statement Version 2 (camt.053.001.02)
• Bank-to-Customer Debit/Credit Notification Version 2 (camt.054.001.02)
Further Bank-to-Customer Account Reporting messages may be added in a later phase.

Chapter 2 deals with the Customer-to-Bank Payment Initiation messages.
Maintenance
The current version of this document is based on version 2 of the above camt messages.
Publication of new versions of these messages on www.iso20022.org may require the
document to be revised, in concert with the approval and publication of the associated CGI
Message Implementation Templates.

Common Message Components
Documentation
The standards covered by this document are fully described in :
• ISO 20022 Message Definition Report – Bank-to-Customer Cash Management
(www.iso20022.org). This report contains the full description of the standards (scope, format
specifications, definitions for all elements, rules and guidelines defined for the generic
standards) for each of the three messages under ISO 20022 Bank-to-Customer Cash
Management.
• ISO 20022 Message schema’s and samples (camt.052.001.02, camt.053.001.02, and
camt.054.001.02) (www.iso20022.org)
• ISO 20022 Customer to Bank Message Usage Guide – Cash Management. When
published, the ISO Message Usage Guide (‘MUG’) will provide generic illustrations and
explanations about the standard. It complements the ISO Message Definition Report.
• SWIFTStandards MX Message Reference Guide –
(www.swift.com/corporates/resource.htm) contains the same information as the ISO 20022
Message Definition Report, but includes the payment initiation messages and is also
available in HTML format.
• CGI Message Implementation Template – (www.swiftcommunity.net/cgi) contains the
specific rules and implementation guidance.
The documentation referred to above contains the full standard specifications and rules that
must be adhered to. This document contains further explanatory notes and additional usage
rules and guidelines to facilitate common implementation and usage of these standards using
FileAct in SCORE (Standardised Corporate Environment)
3.2 Account Reporting Messages

Scope
The Bank-to-Customer Cash Management messages are sent from the Account Servicer to the
Account Owner, or a party authorised by the Account Owner to receive the account information
(i.e. the Message Recipient).
MX camt.052.001.02 BankToCustomerAccountReport
The Bank-to-Customer Account Report message can be used to inform the account owner, or
authorised party, of the entries reported to the account, and/or to provide the owner with
balance information on the account at a given point in time. It can be used in two different
ways, for intra-day reporting and for ad hoc reporting.
MX camt.053.001.02 BankToCustomerStatement
The Bank-to-Customer Statement message can be used to inform the account owner, or
authorised party, of the entries booked to the account, and to provide the owner with balance
information on the account at a given point in time.It can be used for end of cycle statement
reporting, such as for the end-of-day daily statement, the end-of-month monthly statement, and
end-of-year yearly statement.
MX camt.054.001.02 BankToCustomerDebitCreditNotification
The Bank-to-Customer Debit/Credit Notification message can be used to inform the account
owner, or authorised party, of single or multiple debit and/or credit entries reported to the
account. It can be used to report any types of outward and inward payment transactions.
The ISO 20022 Message Definition Report serves as the main document to describe the
standard. Please consult this document for full information on the messages.


Template Name Date
ISO 20022 Cash Management V2 Message Implementation Guide 28 July 2011

Appendix A – Use Cases and Samples Latest version

been defined these are notated below as “SCORE Rule” or SCORE Guideline”. Where an
“CGI Guideline” and have been retained for consistency reasons in this version of the guide.
Message Type
CGI Guideline camt.052 (BankToCustomerAccountReport) can be used in two different

ways.
1. INTRA DAY REPORT - This reports all transactions since the previous
End of Period Statement (camt.053) or previous Intra Day Report
(camt.052). 2. AD HOC reporting e.g. Intra Day, Balances, Value Date
transaction
SCORE Guideline camt.053 (BankToCustomerStatement) can be used for end-of-cycle (e.g.
end-of-day, end-of-week, end-of-month) statements. camt.053 should be
used to report account activity over a defined period.
CGI Guideline camt.054 (BankToCustomerDebitCredit Notification) can be used to report
any types of outward and inward payment transactions. The type of
notification is bilaterally determined.

Group Header Level

camt.052 / 1.0 (GroupHeader (1..1)
camt.053 / 1.0 (GroupHeader (1..1)
camt 054 / 1.0 (GroupHeader (1..1)
Message Pagination
1.4 (GroupHeader/MessagePagination) (0..1)
In instances where message size constraints are applicable, message pagination is a
mechanism to allow a large file to be split across multiple smaller files (pages) and for each file
to be sent to the recipient as a separate message. The PageNumber element specifies the page
sequence number for each message in a set of paginated messages.
CGI Rule When message pagination is used, the message must contain only one
report / statement / notification.

Report / Statement / Notification Level

camt.052 / 2.0 (Report (1..n)
camt.053 / 2.0 (Statement (1..n)
camt 054 / 2.0 (Notification (1..n)
Identification
camt.052 / 2.1 (Report/Identification) (1..1)
camt.053 / 2.1 (Statement/Identification) (1..1)

camt 054 / 2.1 (Notification/Identification) (1..1)
CGI Rule Unique per report and account
Balance
camt.053 / 2.23 (Statement/Balance) (1..n)
CGI Rule Required balance types:

OPBD = OpeningBooked with date on which the opening balance was
determined
CLBD = ClosingBooked
Required balance sub type in paginated statement message:

INTM = Intermediate
Used together with OPBD and CLBD balance type codes to indicate
intermediate characteristic of the balance
Bilaterally determined balance types:

PRCD = PreviouslyClosedBooked with date of the previous customer
statement message for the account
CLAV = ClosingAvailable
FWAV= ForwardAvailable

Entry Level
camt.052 / 2.76 (Report/Entry (0..n)
camt.053 / 2.76 (Statement/Entry (0..n)
camt 054 / 2.56 (Notification/Entry (0..n)

Entry
camt.052 / 2.76 (Report/Entry) (0..n)
camt.053 / 2.76 (Statement/ Entry) (0..n)
CGI Rule Can be absent if no movement for the account. For reporting single
transaction or batch or collection of batches.
Account Servicer Reference

camt.052 / 2.84 (Report/Entry/AccountServicerReference) (0..1)
camt.053 / 2.84 (Statement/Entry/AccountServicerReference) (0..1)
camt 054 / 2.64 (Notification/ Entry/AccountServicerReference) (0..1)
CGI Guideline When the same booked entry is reported in both the camt.052 or camt.054,
the Account Service reference should be the same as reported in camt.053.
BankTransactionCode
camt.052 / 2.91 (Report/Entry/ BankTransactionCode) (0..1)
camt.053 / 2.91 (Statement/Entry/BankTransactionCode) (0..1)
camt 054 / 2.71 (Notification/Entry/BankTransactionCode) (0..1)
CGI Rule Bank Transaction Code must be provided at entry level and maybe
provided at transaction detail level. Note: Domain and/or proprietary may
be provided. At least one must be provided.

Entry Details Level

camt.052 / 2.135 (Report/Entry/EntryDetails (0..n)
camt.053 / 2.135 (Statement/ Entry/EntryDetails (0..n)
camt 054 / 2.115 (Notification/ Entry/EntryDetails (0..n)
CGI Rule This provides a breakdown of the transaction details when the entry is
'batched'. If the entry is not batched and transaction details are to be
reported, then transaction details must only occur once.

Transaction Details Level

camt.052 / 2.142 (Report/Entry/EntryDetails/TransactionDetails (0..n)
camt.053 / 2.142 (Statement/ Entry/EntryDetails/TransactionDetails (0..n)
camt 054 / 2.122 (Notification/ Entry/EntryDetails/TransactionDetails (0..n)

References
camt.052 / 2.143 (Report/Entry/EntryDetails/TransactionDetails/References) (0..1)
camt.053 / 2.143 (Statement/Entry/ EntryDetails/TransactionDetails/References) (0..1)
camt 054 / 2.123 (Notification/Entry/ EntryDetails/TransactionDetails/References) (0..1)
SCORE Guideline For debit entries, when known all references as assigned in the original
payment instruction should be reported.
CGI Rule The EndToEndIdentification must be reported when it is known by the
reporting bank. For SEPA the EndToEndIdentification can be
'NOTPROVIDED'.
Amount Details
camt.052 / 2.156 (Report/Entry/EntryDetails/TransactionDetails/AmountDetails) (0..1)
camt.053 / 2.156 (Statement/Entry/EntryDetails/TransactionDetails/AmountDetails) (0..1)
camt.054 / 2.136 (Notification/Entry/EntryDetails/TransactionDetails/AmountDetails) (0..1)
CGI Rule All Amount Details are in all cases given on the Transaction Details level
on single and batch bookings. For consistency purposes Entry/Amount
information is repeated at
TransactionDetails/AmountDetails/TransactionAmount.
CGI Guideline InstructedAmount
Used for original amount in original currency and is the gross value (i.e.
prior to application of charges) in same currency situations. For example
in the inter-bank MT103 message this amount reports the 33B field
contents. Instructed Amount may be omitted in the case when there are
no charges or no FX. In FX cases the booked transaction FX information
can be found with TransactionAmount. When account servicing bank is
receiving a transaction via MT103, it might contain other FX information of
sender bank FX operation. This is only in the situation of original payment
initiation done with Equivalent amount.
CGI Guideline TransactionAmount
EPC Mandated for SEPA payments.

Recommendation: This amount is to be used for matching and

aggregation purpose and it is used in all cases when AmountDetails
structure is used. It is always in the currency of the account reported and
the Entry Amount and populated in all Transaction Details–cases when
AmountDetails structure is used. It is the net amount of the underlying
transaction including charges expressed in the currency of the posting
account. This will apply both Single Bookings and Batch Bookings with
underlying transactions. This amount indicates the value that has been
debited from or credited to reported bank account (booked or posted
amount). Note: this information may be duplicate with Entry/Amount if the
single booking is in the same currency as reported account currency is.
CGI Guideline CounterValueAmount
Counter Value is used for currency conversion reporting. It is used and
available only in currency exchange cases. In Debit entries the
CounterValueAmount reports the result amount converted from the
InstructedAmount with FX information at TransactionAmount. In Credit
entries the CounterValueAmount reports the result amount converted from
the Inter-bank Settlement Amount with FX information at
TransactionAmount. CounterValueAmount does not have the basic FX
information as it is reported only with TransactionAmount.
CGI Guideline ProprietaryAmount
This value can be used by the bank for additional amount reporting on
community or bank-specific purposes.

Related Parties
camt.052 / 2.199 (Report/Entry/EntryDetails/TransactionDetails/RelatedParties) (0..1)
camt.053 / 2.199 (Statement/Entry/EntryDetails/TransactionDetails/RelatedParties) (0..1)
camt 054 / 2.179 (Notification/Entry/EntryDetails/TransactionDetails/RelatedParties) (0..1)
CGI Rule InitiatingParty

Party initiating the payment to an agent. In the payment context, this can
either be the debtor (in a credit transfer), the creditor (in a direct debit), or
a party that initiates the payment on behalf of the debtor or creditor. In the
context of treasury, the party that instructs the trading party to execute a
treasury deal on its behalf.
CGI Rule Debtor
For outward payments, report if different from account owner. For inward
payments, report where available. In instances where the
ReversalIndicator <RvslInd> is TRUE, the Creditor and Debtor must be
the same as the Creditor and Debtor of the original entry. EPC mandated
for SEPA Payment - For SEPA inward payments, it is expected that the
Debtor info would be provided by the Debtor Agent and hence would be
reported.
CGI Rule UltimateDebtor
Ultimate party that owes an amount of money to the (ultimate) creditor.
EPC mandated for SEPA Payment. In instances where the
ReversalIndicator <RvslInd> is TRUE, the Ultimate Creditor and Ultimate
Debtor must be the same as the Ultimate Creditor and Ultimate Debtor of

the original entry.

CGI Rule Creditor
For outward payment, report where available. In instances where the
ReversalIndicator <RvslInd> is TRUE, the Creditor and Debtor must be
the same as the Creditor and Debtor of the original entry. EPC mandated
for SEPA Payment.
CGI Rule UltimateCreditor
Ultimate party to which an amount of money is due. EPC Mandated for
SEPA Payments. In instances where the ReversalIndicator <RvslInd> is
TRUE, the Ultimate Creditor and Ultimate Debtor must be the same as the
Ultimate Creditor and Ultimate Debtor of the original entry.

4 Common Message Components

The following message components are common across multiple Payment Initiation and
Account Reporting messages and are provided to illustrate the respective structures.

been defined these are notated below as “SCORE Rule” or SCORE Guideline”: Where an
“CGI Recommendation” and have been retained for consistency reasons in this version of the
guide.
PartyIdentification
CGI Rule Name must be provided for Debtor and Creditor. When Ultimate Debtor or
Ultimate Creditor is present, Name must be provided. Name is optional for
Initiating Party.

PostalAddress
CGI Guideline Recommendation in order of preference:

1. Use only structured address.
2. When using combination of both structured address and Address Line,
must use structured tags for post code (if applicable), country subdivision (if
applicable), town name and country and only 2 Address Lines (to include
street address).
3. Use only Address Line (up to 7 lines; instrument by instrument
limitations may apply)
Note : PO Box should only appear in Address Line.

FinancialInstitution
Score Guideline Provide the BIC where possible, else

Clearing System Member ID, else
If other, agree with your bank
Note : for SEPA payments, BIC is required.

CGI Rule For the payment initiation messages, country of DebitorAgent and
CreditorAgent must be provided.
CGI Guideline BranchIdentification. Instrument and bank dependent. The branch code
should be explicitly stated here versus being combined with Clearing System
Member ID when it is required by a bank.
ClearingSystemMemberIdentification

CGI Rule If Code is populated, a code from the external code list
ClearingSystemIdentification should be used.
If Proprietary is populated, the condition is based on the need to use a
proprietary code not on the external code list per bilateral agreement.
Account
CGI Rule For the payment initiation messages, the currency of the DebitorAccount
must be provided.

RemittanceInformation
CGI Guideline Remittance information delivered outside of the clearing system will be
conditional on bank services. Amount of remittance information delivered
through the clearing system will be limited by specific clearing system
capabilities.
CGI Guideline Structured. Best practice for minimum usage: Populate invoice number
and remitted amount or credit note amount with currency or Creditor's
Reference Information.
SCORE Guideline For remittance creditor reference information, in instances where the
CreditorReferenceType code is SCOR (Structured Communication
Reference) and the CreditorReference is structured in accordance with
ISO 11649 (Structured creditor reference to remittance information), the
Issuer should be specified with the text ‘ISO’ (without the quote marks).

Mapping Guidelines MX - MT
5 Mapping Guidelines MX - MT
This section contains two sets of mapping guidelines : one set shows how to reflect a booked
Customer Credit Transfer Initiation in the MT 940, Customer Statement message, which is sent
back to the initiating party; the second set shows how the content of a Customer Credit
Transfer Initiation can be mapped to an interbank SWIFT MT 103 Customer Credit Transfer
message.
5.1 Mapping from pain.001 to MT 940
MT 940 – field 61
Subfield 1 6!n – value date Value date applied
Subfield 2 [4!n] – entry date (optional)
Subfield 3 2a – Debit/Credit mark Debit
Subfield 4 [1!a] – Funds code N/A
Subfield 5 15d - Amount Booked amount (batch or single)
Subfield 6 1!a3!c – Transaction Type Id NTRF
code
Subfield 7 16x – reference for the account Field 86 may be used in a structured form as an
owner extension to field 61, subfield 7. This is done by
putting the code ‘KREF’ in this subfield indicating
that the associated reference(s) are specified in
field 86.
Subfield 8 [/16x] – Account servicing Reference attributed by the account servicer
institution reference
Subfield 9 [34x] Supplementary details (optional)
MT 940 – field 86 – 6 lines of 65x
1. In case of individual bookings – two possibilities:
A. account servicer cannot provide ‘reference type’
Line 1 /KREF/ followed by max 35 This means this is a reference that is meaningfull
text. for the account owner. In case the account
servicer can provide several ‘untyped’ references
KREF means ‘generic customer back, it should separate the references by double
reference’. slash and continue on the next line.
Is the same code as for the
‘trigger’ in subfield 7 of field 61.

B. account servicer can provide reference type (ie ‘granular’ reference) :

Line 1 /EREF/ followed by max 35 This code is used to identify the End to End ID.
text. Guideline : it is mandatory to provide back the
End to End ID in case of a single booking.
/EREF/ identies the End to End
id.
Continuation /IREF/ followed by max 35 text. Guideline : If the Instruction ID is included in the
(from line 1) payment initiation, it is recommended to also
/IREF/ identifies the Instruction provide back the Instruction ID.
ID.
Continuation /PREF/followed by max 35 text. Guideline : If the Instruction ID is not included in
the payment initiation, but a Payment Info ID is
/PREF/ identifies the Payment provided, it is recommended to provide back the
Info ID. Payment Info ID.
In case all 3 references (End-to-end ID,
Instruction ID and Payment Info ID) are present
in the payment initiation, it is optional to report
the Payment Info ID back.
2. In case of batch booking, two possibilities:
A. account servicer cannot provide ‘reference type’
Line 1 /KREF/ followed by max 35 This means this is a reference that is meaningfull
text. for the account owner (depending on how batch
booking has been agreed).
KREF means ‘generic customer
reference’.
Is the same code as for the
‘trigger’ in subfield 7 of field 61.
B. account servicer can provide ‘reference type’
Line 1 /PREF/followed by max 35 text. This code is used to identify the Payment Info ID
included in the payment initiation.
/PREF/ identifies the Payment Guideline : as it is recommended in this
Info ID. document to always include the Payment Info ID
in the Customer Credit Transfer Initiation, this id
should be available to be reported back to the
account owner and should be the ‘batch
reference’.
5.2 Mapping from pain.001 to MT 103
The table below contains an overview of how elements from a Customer Credit Transfer
Initiation (pain.001) sent by an initiating party to its bank would be logically mapped to the
subsequent MT 103, which can be the message used by the bank receiving the pain.001 to
transfer the funds to the next bank party in the chain.

For detailed translation information, please consult the pacs.008.001.02 to MT 103 (and vice
versa), and the pain.001.001.03 to MT 101 translation rules available through swift.com
(Support/documentation/UHB on-line). These rules contain exhaustive explanations on how to
translate components, elements and data types from the ISO 20022 messages to and from
their equivalent FIN MT messages.
The mapping below follows the logic followed in these translation rules, but only provides a
high-level view of where ‘Customer Credit Transfer Initiation’ data logically can be included in
the MT 103.
Note : the table below does not include all elements (contained in a complex type) of certain
‘reusable’ components (such as customer identification or financial institution
identification). These components are marked with a “+”. The translation rules for these
elements can be found in the detailed translation information referred to above.
Conventions
If an element is identified as a ‘point-to-point’ element in the table below, it means it does not
have to be mapped to the interbank chain.
If an element is identified as ‘cannot be mapped’, it means the MT 103 does not cater for this
element.
For all other elements, a placeholder in the MT 103 is indicated.
pain.001.001.03 MT 103
Occur
Message item rence Type
Group Header [1..1] Component
Point-to-point element, so not transported in
Message Identification [1..1] Max35Text interbank chain
Creation DateTime [1..1] ISODateTime interbank chain
Authorisation [0..2] Max128Text interbank chain

Number of Transactions [1..1] Max15NumericText interbank chain
Control Sum [0..1] DecimalNumber interbank chain
Initiating Party [1..1] Component + Cannot be mapped

Forwarding Agent [0..1] Component + Cannot be mapped
Payment Information [1..n] Component
Payment Information Point-to-point element, so not transported in
Identification [1..1] Max35Text interbank chain
interbank chain.
CHK will result in issuance of cheque, TRF may
Payment Method [1..1] Code result in a.o. actual creation of MT 103.
BatchBooking [0..1] Indicator interbank chain
Number of Transactions [0..1] Max15NumericText interbank chain


Control Sum [0..1] DecimalNumber interbank chain
Payment Type Information [0..1] Component
Instruction priority [0..1] Code interbank chain
Service Level or [0..1] Choice Component Cannot be mapped
Code or [1..1] Code Cannot be mapped
Proprietary [1..1] Max35Text Cannot be mapped
Local Instrument [0..1] Component Cannot be mapped

Category Purpose [0..1] Choice Component
Codes CORT and INTC will be mapped to 23E of
MT 103: Instruction Code CORT and INTC. Other
Code or [1..1] Code codes will not be mapped.
Not mapped – but used to determine subfield 1 of
Requested Execution Date [1..1] ISODate 32A ( the interbank settlement date)
Pooling Adjustment Date [0..1] ISODate interbank chain
Field 50 – Ordering Customer.
Debtor [1..1] Component + Please see translation rules PACS 008– MT 103.
Field 50 – Ordering Customer
Debtor Account [1..1] Component Please see translation rules PACS 008 – MT 103.
Field 50 – Ordering Customer
Id [1..1] Component + Please see translation rules PACS 008 – MT 103.
Type [0..1] Component Cannot be mapped
Currency [0..1] Currency Code Cannot be mapped
Name [0..1] Max70Text Cannot be mapped
Mapped to field 52 Ordering Institution

Debtor Agent [1..1] Component +
Please see translation rules PACS 008 – MT 103
Debtor Agent Account [0..1] Component + Not used in pain, so not mapped to MT 103
Ultimate Debtor [0..1] Component + Cannot be mapped
Field 71A Charge Bearer :
- DEBT > OUR
- SHAR > SHA
- CRED > BEN
Charge Bearer [0..1] Code - SLEV > SHA
Point-to-point element, not transported in interbank
Charges Account [0..1] Component + chain
Charges Account Agent [0..1] Component + chain
Credit Transfer Transaction [1..n] Component

Information
Payment Identification [1..1] Component

Instruction ID [0..1] Max35Text chain
Field 70 : /ROC/ (depending on presence of
Remittance Identification in Related Remittance
Information).
See the detailed translation rules for more
End-to-end ID [1..1] Max35Text information.
Should not be present on this level according to
the Rules set out in this document. Can only be
present on Payment Information level. For
proposed mapping, see Payment Type Information
Payment Type Information [0..1] Component + component above.
Amount [1..1] Choice component
Instructed Amount or [1..1] Currency and Amount Field 33B Instructed Amount
Equivalent Amount [1..1] Component Field 33B Instructed Amount
Amount [1..1] Currency and Amount Field 33B Instructed Amount
Currency of Transfer [1..1] Currency Code Field 33B Instructed Amount
Exchange Rate Information [0..1] Component
Exchange Rate [0..1] BaseOneRate Field 36 Exchange Rate
Rate Type [0..1] Code Cannot be mapped
Contract Identification [0..1] Max35Text chain
Should not be present on this level according to
the Rules set out in this Document, but can only be
present on Payment Information level. For
proposed mapping, see Charge Bearer element
Charge Bearer [0..1] Code above.
The entire component of Cheque Instruction is not
mapped to the MT 103 : if cheque needs to be
issued by debtor agent, the debtor agent will not
Cheque instruction [0..1] Component + generate an MT 103
Ultimate Debtor [0..1] Component + Cannot be mapped
Receiver of MT 103 (if receiver of the pain.001
message respects/has to respect the route set by
Intermediary Agent 1 [0..1] Component + the initiating party of the pain.001)
Not mapped (unless intermediary agent has
multiple accounts at the Sender, and the Sender
indicates in the MT 103 which account has been
Intermediary Agent 1 Account [0..1] Component + used for reimbursement (in field 53B).
Field 56a Intermediary (if no intermediary agent 3
is present)
Intermediary Agent 2 [0..1] Component + See comment below for Intermediary agent 3.
Field 56a Intermediary, optional party identifier
line. Only Account ID will be mapped.
Intermediary Agent 2 Account [0..1] Component + See comment below for Intermediary agent 3.
If 3 Intermediary agents are included in the ‘pain’
message, the sender of the MT 103 will have to
make a choice which ones to include in the MT
103 (the MT 103 can only contain a receiver and 1
Intermediary Agent 3 [0..1] Component + intermediary).
Intermediary Agent 3 Account [0..1] Component + See comment for Intermediary agent 3.

Mapped to field 57a Account With Institution (when

Creditor Agent [0..1] Component + different from the Receiver of MT 103)
Mapped to field 57a Account With Institution
(optional account number line). Only Account ID
Creditor Agent Account [0..1] Component + will be mapped.
Mapped to field 59a Beneficiary Customer.
Please see translation rules PACS 008.001.01 –
Creditor [0..1] Component + MT 103.
Mapped to field 59a Beneficiary Customer
(account number line).
Creditor Account [0..1] Component + Only the account ID will be mapped.
Mapped to field 59a Beneficiary Customer
ID [1..1] Component (account number line)
Type [0..1] Component Cannot be mapped
Currency [0..1] Currency Code Cannot be mapped
Ultimate Creditor [0..1] Component + Cannot be mapped
Instruction for Creditor Agent [0..n] Component
Field 23E Instruction Code.
CHQB > will be mapped to CHQB.
HOLD > will be mapped to HOLD
PHOB > will be mapped to PHOB.
Code [0..1] Code TELB > will be mapped to TELB
Field 23E Instruction Code/Additional information
For details, please see mapping PACS 008– MT
Instruction Information [0..1] Max140Text 103
Instruction for Debtor Agent [0..1] Max140Text interbank chain
Purpose [0..1] Component Cannot be mapped
Code or [1..1] Max3Text Cannot be mapped
Regulatory Reporting [0..10] Component Field 77B Regulatory Reporting
Debit Credit Reporting Indicator [0..1] Code Cannot be mapped
Authority [0..1] Component Cannot be mapped
Country [0..1] ISOCountryCode Cannot be mapped
Details [0..1] Component Field 77B Regulatory Reporting
Type [0..1] Max35Text
Date [0..1] ISODate Cannot be mapped
Country [0..1] ISOCountryCode Cannot be mapped
Code [0..1] Code Cannot be mapped
Amount [0..1] CurrencyAndAmount Cannot be mapped
Map to 3 lines of field 77B Regulatory reporting.
For details, please see mappng PACS 008 – MT
Information [0..1] Max35Text 103
Tax [0..1] Component Cannot be mapped

Creditor [0..1] Component Cannot be mapped

Tax Id [0..1] Max35Text Cannot be mapped
RegistrationId [0..1] Max35Text Cannot be mapped
Tax Type [0..1] Max35Text Cannot be mapped
Debtor [0..1] Component Cannot be mapped
Tax Id [0..1] Max35Text Cannot be mapped
RegistrationId [0..1] Max35Text Cannot be mapped
Tax Type [0..1] Max35Text Cannot be mapped
Authorisation [0..1] Component Cannot be mapped
AdministrationZone [0..1] Max35Text Cannot be mapped
ReferenceNumber [0..1] Max140Text Cannot be mapped
Method [0..1] Max35Text Cannot be mapped
Cannot be mapped
Total Taxable Base Amount [0..1] CurrencyAndAmount

Total Tax Amount [0..1] CurrencyAndAmount Cannot be mapped
Date [0..1] ISODate Cannot be mapped
SequenceNumber [0..1] Number Cannot be mapped

Record [0..n] Component Cannot be mapped
Related Remittance Information [0..10] Component
Map to Field 70, /ROC/, check detailed translation
Remittance Id [0..1] Max35Text rules PACS 008 – MT 103
Remittance Location Method [0..1] Code Cannot be mapped
Cannot be mapped
Remittance Location Electronic
Adress [0..1] Max2048Text
Remittance Location Postal Cannot be mapped
Address [0..1] Component
Cannot be mapped
Address [1..1] Component
Remittance Information [0..1] Choice component
Mapped to field 70 Remittance Details – see
Unstructured [0..n] Max140Text detailed translation rules PACS 008- MT 103
Structured [0..n] Component Mapped to field 70 Remittance Details – see
detailed translation rules PACS 008- MT 103
Referred Document Information [0..n] Component
Type [0..1] Component

CodeOrProprietary
Code or [1..1] Code
Proprietary [1..1] Max35Text
Issuer [0..1] Max35Text
Number [0..1] Max35Text
Related Date [0..1] ISODate
Referred Document Amt [0..1] Choice Component

Due Payable Amt or [0..1] Currency And Amount
Discount Applied Amt

or [0..1] Currency And Amount
Credit Note Amt or [0..1] Currency And Amount

Tax Amount [0..1] CurrencyAndAmount
AdjustmentAmountAndReas
on [0..n] Component
RemittedAmount [0..1] CurrencyAndAmount
Creditor Reference Info [0..1] Component
Type [0..1] Component
CodeOrProprietary [1..1] ChoiceComponent
Code or [1..1] Code
Proprietary [1..1] Max35Text
Issuer [0..1] Max35Text
Reference [0..1] Max35Text
Invoicer [0..1] Component
Invoicee [0..1] Component

Additional Remittance Info [0..3] Max140Text

Comparison MT – MX
6 Comparison MT - MX
This section contains a comparison of the SWIFT category 9 messages with the ISO 20022
Bank-to-Customer Account Reportingstandards.
This comparison is not intended to provide a detailed mapping, but rather is aimed at facilitating
an understanding of the correspondence between the MT and MX message types.
The following table illustrates the equivalence :
Account Reporting
MT Message Types MX Message Types
- MT 942 Interim Transaction Report camt.052 (Bank-to-Customer Account Report)
- MT 941 Balance Report
- combination of MT 942 and MT 941
- MT 940 Customer Statement camt.053 (Bank-to-Customer Statement)
- MT 950 Statement
- MT 900 Confirmation of Debit camt.054 (Bank-to-Customer Debit/Credit
Notification)
- MT 910 Confirmation of Credit
- combination of MT 900 and MT 910
The following comparisons are detailed :

• comparison of MX camt.052 BankToCustomerAccountReport with :
− MT 942 Interim Transaction Report (section 5.1)
− MT 941 Balance Report (section 5.2)
• comparison of MX camt.053 BankToCustomerStatement with :
− MT 940 Customer Statement (section 5.3)
− MT 950 Statement (section 5.4)
• comparison of MX camt.054 BankToCustomerDebitCreditNotification with :
− MT 900 Notification of Debit (section 5.5)
− MT 910 Notification of Credit (section 5.6)
The specific translation rules for the above message types are published as part of the
Standards User Handbook.

6.1 Comparison MT 942 to camt.052

The comparison below provides an analysis on the level of correspondence between MT 942
(Interim Transaction Report ) and the MX camt.052 (Bank-to-Customer Account Report). It
does not represent the additional information that can be included in the MX message.
Points of difference are highlighted in yellow. The target camt.052 fields designated in the
Standards Translation Rules are highlighted in blue.
MT 942 MX camt.052
Status Tag Field Name Mult. Message Item Index
M 20 Transaction Reference Number 1..1 Report/Identification 2.1
O 21 Related Reference Not included
(used to answer to a request for
Statement message)
M 25 Account Identification 1..1 Report/Account 2.10
M 28C Statement Number/Sequence 0..1 Report/ElectronicSequenceNumber 2.2

Number
0..1 Report/LegalSequenceNumber 2.3
0..1 GroupHeader/MessagePagination 1.4
M 34F Floor Limit Indicator Not required
O 34F Floor Limit Indicator Not required
M 13D Date/Time Indication 1..1 Report/CreationDateTime 2.4
O 61 Statement Line (see below) 0..n Report/Entry (see below) 2.76

O 86 Information to Account Owner 0..1 Report/Entry/AdditionalEntryInformation or 2.314
Report/Entry/EntryDetails/Batch or 2.136
Note: If field 86 is formatted Report/Entry/EntryDetails/TransactionDetails 2.142
according to a predefined
structure, the information may be
mapped to elements in the
Report/Entry/Batch or
Report/Entry/TransactionDetails
component, as appropriate. For
example in field 86 using codes
‘/EREF/’ with End to End ID,
’/IREF/’ with Instruction ID,
’/PREF/’ with Payment Info ID,
‘/KREF/’ with generic customer
reference.
O 90D Number and Sum of Entries 0..1 Report/TransactionsSummary/TotalDebitEntrie 2.52
s
O 90C Number and Sum of Entries 0..1 Report/TransactionsSummary/TotalCreditEntri 2.49
es
O 86 Information to Account Owner 0..1 Report/AdditionalReportInformation 2.315

Field 61 Statement line Entry component (2.65 and following)

Status Field Name Mult. Message Item Index
M Value Date (YYMMDD) 0..1 Entry/ValueDate 2.83
O Entry Date (MMDD) 0..1 Entry/BookingDate 2.82
M Debit/Credit Mark : 1..1 Entry/CreditDebitIndicator 2.79
Debit/Credit/ 0..1 Entry/ReversalIndicator 2.80
Reversal of Credit(debit entry)/ 0..1 Entry/Status (booked/pending) 2.81
Reversal of Debit (credit entry)/
Expected Debit/Expected Credit
O Funds Code (3rd character of the Not required
currency code, if needed)
M Amount 1..1 Entry/Amount 2.78
M Transaction Type Identification Code 1..1 Entry/BankTransactionCode 2.91
M* Reference for the Account Owner 0..1* Entry/EntryDetails/Batch/
(when batch or aggregate booking):
Note: Field 86 may be used in a structured Message ID and/or 2.137
form as an extension to field 61. For PaymentInfoID 2.138
example in field 61 using code ‘KREF’ to Entry/EntryDetails/TransactionDetails/References
indicate that the associated reference(s) (when booking for single transaction :
are specified in field 86. Instruction ID and/or 2.147
Transaction ID and/or 2.149
EndToEndID and/or 2.148
MandateID and/or 2.150
ClearingSystemReference and/or 2.152
ChequeNumber and/or 2.151
Proprietary 2.153
Entry/EntryDetails/TransactionDetails/RelatedRe 2.250
mittanceInformation/RemittanceIdentification
Entry/EntryDetails/TransactionDetails/Remittance 2.277
Information/Structured/CreditorReferenceInforma
tion/CreditorReference
O Account Servicing Institution's 0..1 Entry/AccountServicerReference 2.143
Reference
O Supplementary Details 0..1 Entry/AdditionalEntryInformation and/or 2.314

Entry/EntryDetails/TransactionDetails/Additional 2.313
TransactionInformation
* Reference for Account Owner : even though all references in the MX message are optional, a rule in
the Bank-to-Customer Cash Management Message Definition Report states that at least one
reference must be present.


(Balance Report ) and the MX camt.052 (Bank-to-Customer Account Report). It does not
represent the additional information that can be included in the MX message.
MT 941 MX camt.052
M 20 Transaction Reference Number 1..1 Report/Identification 2.1
O 21 Related Reference : Not included
Statement message)
M 25 Account Identification 1..1 Report/Account 2.10
M 28 Statement Number/Sequence 0..1 Report/ElectronicSequenceNumber 2.2
Number
0..1 Report/LegalSequenceNumber 2.3
O 13D Date/Time indication 1..1 Report/CreationDateTime 2.4
O 60F Opening Balance 0..1 Report/Balance (see below) 2.23
O 90D Number and Sum of Entries 0..1 Report/TransactionsSummary/TotalDebitEntries 2.52
O 90C Number and Sum of Entries 0..1 Report/TransactionsSummary/TotalCreditEntrie 2.49
s
M 62F Closing Balance (Booked 0..1 Report/Balance (see below) 2.23
Funds)
O 64 Closing Available Balance 0..1 Report/Balance (see below) 2.23
(Available Balance)
O 65 Forward Available Balance 0..n Report/Balance (see below) 2.23
O 86 Information to Account Owner 0..1 Report/AdditionalReportInformation 2.330
Balance information in MT Balance information in MX

(Report/Balance/BalanceDetails (repetitive (2.28))
O Opening Balance Opening Booked Balance 2.25
(option F) *** (translation default balance type code “PRCD”)
M Closing Balance (Booked Funds) Closing Booked Balance 2.25
(option F) *** (translation default balance type code “ITBD”)
O Closing Available Balance Closing Available Balance 2.25
(translation default balance type code “CLAV”)
O Forward Available Balance Forward Available Balance 2.25
(repetitive) (translation default balance type code “FWAV”)
Balance subfields in MT Balance subfields in MX
Balance Debit/Credit Mark 1..1 CreditDebit Indicator 2.35

Date 1..1 Date 2.36

Currency 1..1 Amount 2.34
(typed by CurrencyAndAmount)
Amount 1..1 Amount 2.34
(typed by CurrencyAndAmount)
*** in the MT 941, fields 60 and 62 can only be used with option F.
in the MT 940 (see comparison 5.3 below), field 60 and 62 can be used with option F or M.
60F = opening booked balance;
60M = interim opening booked balance;(to be used when there is more than one page belonging to
the statement);
62F = final closing booked balance;
62M = interim closing booked balance. (to be used when there is more than one page belonging to
the statement);


(Customer Statement) and the MX camt.053 (Bank-to-Customer Statement). It does not
represent the additional information that can be included in the MX message.
MT 940 MX camt.053
M 20 Transaction Reference Number 1..1 Statement/Identification 2.1
O 21 Related Reference Not included
Statement message)
M 25 Account Identification 1..1 Statement/Account 2.10
M 28C Statement Number/Sequence 0..1 Statement/ElectronicSequenceNumber 2.2

Number 0..1 Statement/LegalSequenceNumber 2.3
M 60a Opening Balance 1..1 Statement/Balance 2.23
(option F or M) * (translation default balance type code “PRCD”)
O 61 Statement Line (see below) 0..n Statement/Entry (see below) 2.76
O 86 Information to Account Owner 0..1 Report/Entry/AdditionalEntryInformation or 2.329
Report/Entry/EntryDetails/Batch or 2.136
Note: If field 86 is formatted Report/Entry/EntryDetails/TransactionDetails 2.142
according to a predefined
structure, the information may be
mapped to elements in the
Report/Entry/Batch or
Report/Entry/TransactionDetails
component, as appropriate. For
example in field 86 using codes
‘/EREF/’ with End to End ID,
’/IREF/’ with Instruction ID,
’/PREF/’ with Payment Info ID,
‘/KREF/’ with generic customer
reference.
M 62a Closing Balance 1..1 Statement/Balance 2.23
(option F or M) * (translation default balance type code “CLBD”)
O 64 Closing Available Balance 0..1 Statement/Balance 2.23
O 65 Forward Available Balance (rep) 0..n Statement/Balance 2.23
(translation default balance type code “FWAV”)
O 86 Information to Account Owner 0..1 Statement/AdditionalStatementInformation 2.315


Reversal of Credit(debit entry)/
M** Reference for the Account Owner 0..1** Entry/Batch/
Note: Field 86 may be used in a structured Message ID and/or 2.137
form as an extension to field 61. For PaymentInfoID 2.138
example in field 61 using code ‘KREF’ to Entry/TransactionDetails/References
indicate that the associated reference(s) (when booking for single transaction :
are specified in field 86. Instruction ID and/or 2.147
Proprietary 2.153
Entry/TransactionDetails/RelatedRemittanceInfor 2.228
mation/RemittanceIdentification
Entry/TransactionDetails/RemittanceInformation/ 2.256
Structured/CreditorReferenceInformation/Credito
rReference
Reference
O Supplementary Details 0..1 Entry/AdditionalEntryInformation and 2.314

Entry/TransactionDetails/AdditionalTransaction 2.313
Information
* For a further breakdown of the balance component, please refer to the comparison included with the
MT 941 Balance Report, section 5.2.
** Reference for Account Owner : even though all references in the MX message are optional, a rule in
reference must be present..


(Statement) and the MX camt.053 (Bank-to-Customer Statement). It does not represent the
additional information that can be included in the MX message.
MT 950 MX camt.053
M 20 Transaction Reference Number 1..1 Statement/Identification 2.1
M 25 Account Identification 1..1 Statement/Account 2.10
M 28C Statement Number/Sequence 0..1 Statement/ElectronicSequenceNumber 2.2

Number 0..1 Statement/LegalSequenceNumber 2.3
M 60a Opening Balance 1..1 Statement/Balance 2.23
(option F or M) * (translation default balance type code “PRCD”)
O 61 Statement Line (see below) 0..n Statement/Entry (see below) 2.76
M 62a Closing Balance 1..1 Statement/Balance 2.23
(option F or M) * (translation default balance type code “CLBD”)
O 64 Closing Available Balance 0..1 Statement/Balance 2.23

Reversal of Credit(debit entry)/
M** Reference for the Account Owner 0..1** Entry/EntryDetails/Batch/
Message ID and/or 2.137
PaymentInfoID 2.138
Entry/TransactionDetails/References
(when booking for single transaction :
Instruction ID and/or 2.147


Proprietary 2.153
Entry/TransactionDetails/RelatedRemittanceInfor 2.228
mation/RemittanceIdentification
Entry/TransactionDetails/RemittanceInformation/ 2.256
Structured/CreditorReferenceInformation/Credito
rReference
Reference
O Supplementary Details 0..1 Entry/AdditionalEntryInformation and 2.314

Entry/EntryDetails/TransactionDetails/Additional 2.313
TransactionInformation
* For a further breakdown of the balance component, please refer to the comparison included with the
MT 941 Balance Report, section 5.2.
** Reference for Account Owner : even though all references in the MX message are optional, a rule in
reference must be present.


(Confirmation of Debit) and the MX camt.054 (Bank-to-Customer Credit/Debit Notification). It
Note : The MT 900 is not constructed around the principle of ‘statement line’ (making it different
from MT 940/942), but the content of the MT 900 itself is comparable to a small subset of
information included in the statement line of the MT 940/942.
MT 900 MX camt.054
M 20 Transaction Reference Number 1..1 Notification/Identification 2.1
M* 21 Related Reference 0..1 * Notification/Entry/Batch/
(In the MT 900, this field contains (when batch or aggregate booking)
the reference number of the Message ID and/or 2.117
transaction which resulted in this PaymentInfoID 2.118
message, e.g., the field 20 Notification/Entry/EntryDetails/TransactionDetails
Transaction Reference Number of /References
the SWIFT payment instruction.) (when booking for single transaction : 2.127
Instruction ID and/or 2.129
Proprietary
Notification/Entry/EntryDetails/TransactionDetails 2.208
/RelatedRemittanceInformation/RemittanceIdent
ification
/RemittanceInformation/Structured/CreditorRefer
enceInformation/CreditorReference
M 25 Account Identification 1..1 Notification/ Account 2.10
M 32A Value Date, Currency Code, 0..1 Notification/ Entry/ValueDate 2.63
Amount (Note: Usage rule in Message Definition Report
“When entry status is pending, and value date is
present, value date refers to an expected /
requested value date.
For entries which are subject to availability/float
(and for which availability information is present),
value date must not be used, as the availability
component identifies the number of availability

days”.
1..1 Notification/ Entry/Amount 2.58
O 52a Ordering Institution 0..1 Notification/Entry/EntryDetails/TransactionDetails
(MT 900 has only Ordering /RelatedParties/Debtor 2.181
Institution, not Ordering Customer, (in the case where the debit was initiated by the
– as in MT 910) account owner)
0..1 Notification/Entry/EntryDetails/TransactionDetails
/RelatedAgents/DebtorAgent 2.192
(in case where the debit was initiated by the
account servicing institution)
0..1 Notification/Entry/EntryDetails/TransactionDetails
/RelatedParties/Creditor 2.184
(in the case of eg a DirectDebit) or
UltimateCreditor 2.186
(also in the case of a Direct Debit)
O 72 Sender to Receiver Information 0..1 Notification/AdditionalNotificationInformation 2.295
Mandatory elements present in MX camt.054 that are not

present in MT 900
1..1 GroupHeader/MessageIdentification ** 1.1
1..1 GroupHeader/CreationDateTime ** 1.2
1..1 Notification /Entry/CreditDebitIndicator *** 2.59

(translation default “DBIT”)
1..1 Notification /Entry /Status 2.61
(translation default “BOOK”)
1..1 Notification /Entry /BankTransactionCode 2.71
(translation default “UNKNOWN”)
* A rule in the MX message states that at least one reference must be present.
** these differences are due to difference in structure of the MX : MX message can contain multiple
notifications
*** this difference is due to the fact that the MX message can be used for Debit and/or Credit
notifications


(Confirmation of Credit) and the MX camt.054 (Bank-to-Customer Credit/Debit Notification). It
Note : The MT 910 is not constructed around the principle of ‘statement line’ (making it different
from MT 940/942), but the content of the MT 910 itself is comparable to a small subset of
information included in the statement line of the MT 940/942.
MT 910 MX camt.054
M 20 Transaction Reference Number 1..1 Notification/Identification 2.1
M* 21 Related Reference 0..1 * Notification/Entry/EntryDetails/Batch/
(In the MT 910, this field contains (when batch or aggregate booking)
the reference number of the Message ID and/or 2.117
transaction which resulted in this PaymentInfoID 2.118
message, e.g., the field 20 Notification/Entry/EntryDetails/TransactionDetails
Transaction Reference Number of /References
the SWIFT payment instruction, or (when booking for single transaction : 2.127
field 21 of an MT 202.) Instruction ID and/or 2.129
Proprietary
/RelatedRemittanceInformation/RemittanceIdent
ification
/RemittanceInformation/Structured/CreditorRefer
enceInformation/CreditorReference
M 25 Account Identification 1..1 Notification/ Account 2.10
M 32A Value Date, Currency Code, 0..1 Notification/ Entry/ValueDate 2.63
Amount (Note: Usage rule in Message Definition Report
“When entry status is pending, and value date is
present, value date refers to an expected /
requested value date.
For entries which are subject to availability/float
(and for which availability information is present),
value date must not be used, as the availability
component identifies the number of availability
days”.

1..1 Notification/ Entry/Amount 2.58

O 50a Ordering Customer 0..1 Notification//Entry/EntryDetails/TransactionDetail
s/RelatedParties/Debtor 2.181
DebtorAccount 2.182
O 52a Ordering Institution 0..1 Notification/Entry/EntryDetails/TransactionDetails 2.181
/RelatedParties/Debtor
O 56a Intermediary 0..1 Notification/Entry/EntryDetails/TransactionDetails 2.194
/RelatedParties/IntermediaryAgent1
O 72 Sender to Receiver Information 0..1 Notification/EntryDetails/AdditionalTransactionI 2.293
nformation
Mandatory elements present in MX camt.054 that are not

present in MT 910
1..1 GroupHeader/MessageIdentification ** 1.1
1..1 GroupHeader/CreationDateTime ** 1.2
1..1 Notification /Entry/CreditDebitIndicator *** 2.59

(translation default “CRDT”)
1..1 Notification /Entry /Status 2.61
(translation default “BOOK”)
1..1 Notification /Entry /BankTransactionCode 2.71
(translation default “UNKNOWN”)
* A rule in the MX message states that at least one reference must be present.
** these differences are due to difference in structure of the MX : MX message can contain multiple
notifications
*** this difference is due to the fact that the MX message can be used for Debit and/or Credit
notifications

Legal Notices
Copyright
SWIFT © 2011. All rights reserved.
You may copy this publication within your organisation. Any such copy must include these legal notices.
Confidentiality
This publication contains SWIFT or third-party confidential information. Do not disclose this publication
outside your organisation without the prior written consent of SWIFT.
Disclaimer
The information in this publication may change from time to time. You must always refer to the latest
available version on www.swift.com.
Translations
The English version of SWIFT documentation is the only official and binding version.
Trademarks
SWIFT is the trade name of S.W.I.F.T. SCRL. The following are registered trademarks of SWIFT:
SWIFT, the SWIFT logo, the Standards Forum logo, 3SKey, Innotribe, Sibos, SWIFTNet, SWIFTReady,
and Accord. Other product, service, or company names in this publication are trade names, trademarks,
or registered trademarks of their respective owners.

Implementing Your Project 2011 Standards MX Message Implementation Guide

Uploaded by

Document Information

Original Title

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

Implementing Your Project 2011 Standards MX Message Implementation Guide

Uploaded by

Copyright:

Available Formats

Solutions

SWIFT for Corporates

Standards MX Message Implementation

Payment Initiation and Account Reporting

2 Payment Initiation ............................................................................................................... 9

3 Account Reporting ............................................................................................................ 28

4 Common Message Components...................................................................................... 42

5 Mapping Guidelines MX - MT ........................................................................................... 47

2 Standards MX Message Implementation Guide (Dec 2011)

The scope of these guidelines

Document Release Management

3 Standards MX Message Implementation Guide (Dec 2011)

4 Standards MX Message Implementation Guide (Dec 2011)

1 Message Rules and Guidelines

5 Standards MX Message Implementation Guide (Dec 2011)

1.2 Rule and Guideline Conventions

CGI Implementation Templates

6 Standards MX Message Implementation Guide (Dec 2011)

Document Type Description

CGI Implementation Template Attributes

Box with a full line is a mandatory message element (also

Box with a dotted line is an optional message element (also

7 Standards MX Message Implementation Guide (Dec 2011)

8 Standards MX Message Implementation Guide (Dec 2011)

Further Customer-to-Bank Payment Initiation messages may be added in a later phase.

9 Standards MX Message Implementation Guide (Dec 2011)

2.2 Customer Credit Transfer Initiation

Template Name Date

ISO 20022 Credit Transfer V3 Message Implementation Guide 13 June 2011

Message Schema Components

10 Standards MX Message Implementation Guide (Dec 2011)

Customer Credit Transfer Initiation (pain.001.001.03)

11 Standards MX Message Implementation Guide (Dec 2011)

Customer Credit Transfer Initiation (pain.001.001.03)

12 Standards MX Message Implementation Guide (Dec 2011)

Specific Rules and Guidelines

Payment Type Information

13 Standards MX Message Implementation Guide (Dec 2011)

14 Standards MX Message Implementation Guide (Dec 2011)

15 Standards MX Message Implementation Guide (Dec 2011)

Payment transaction reference :

Reference Truncation principle

16 Standards MX Message Implementation Guide (Dec 2011)

2.3 Payment Status Report

Template Name Date

Message Schema Components

17 Standards MX Message Implementation Guide (Dec 2011)

Payment Status Report (pain.002.001.03)

18 Standards MX Message Implementation Guide (Dec 2011)

Payment Status Report (pain.002.001.03)

19 Standards MX Message Implementation Guide (Dec 2011)

Payment and Status Flow

20 Standards MX Message Implementation Guide (Dec 2011)

21 Standards MX Message Implementation Guide (Dec 2011)

Specific SCORE Rules and Guidelines

Payment Status Report at ‘checkpoint’ 1 (illustrated in diagram above)

22 Standards MX Message Implementation Guide (Dec 2011)

SCORE Rule 2 2. The complete message is rejected – ie the lifecycle of all

It needs to be pre-agreed between a customer and its bank which

Payment Status Report at ‘checkpoint’ 2 (illustrated in diagram above)

23 Standards MX Message Implementation Guide (Dec 2011)

Reason Information for the Reject can be included in the Status

The same minimum data set as quoted under Rule 4 should be