Standards MX Message Implementation Guide and Rule · PDF filePayment Initiation and Account Reporting . ... • Standards MX Message Implementation Guide and Rule Book, ... SEB ,

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

2 Standards MX Message Implementation Guide (Dec 2011)

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 6.2 Comparison MT 941 to camt.052 .............................................................................. 58 6.3 Comparison MT 940 to camt.053 .............................................................................. 60 6.4 Comparison MT 950 to camt.053 .............................................................................. 62 6.5 Comparison MT 900 to camt.054 .............................................................................. 64 6.6 Comparison MT 910 to camt.054 .............................................................................. 66

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 :

a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + 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:

https://www2.swift.com/uhbonline/books/protected/en_uk/mxgi_20110429/index.htm?subpage=b34.htm�

https://www2.swift.com/uhbonline/books/protected/en_uk/mxgi_20110429/b19.htm�

https://www2.swift.com/uhbonline/books/protected/en_uk/mxgi_20110429/b19.htm�

http://www.swift.com/corporates/resource.htm�

https://www.swiftcommunity.net/cgi�

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

http://www.iso20022.org/�



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 guidelines. Please consult these documents for full information.

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


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.

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.


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 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 code

NTRF

Subfield 7 16x – reference for the account owner

Field 86 may be used in a structured form as an 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 institution reference

Reference attributed by the account servicer

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 text.

KREF means ‘generic customer reference’. Is the same code as for the ‘trigger’ in subfield 7 of field 61.

This means this is a reference that is meaningfull for the account owner. In case the account servicer can provide several ‘untyped’ references back, it should separate the references by double slash and continue on the next line.



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

Line 1 /EREF/ followed by max 35 text.

/EREF/ identies the End to End id.

This code is used to identify the End to End ID. Guideline : it is mandatory to provide back the End to End ID in case of a single booking.

Continuation (from line 1)

/IREF/ followed by max 35 text.

/IREF/ identifies the Instruction ID.

Guideline : If the Instruction ID is included in the payment initiation, it is recommended to also provide back the Instruction ID.

Continuation /PREF/followed by max 35 text.

/PREF/ identifies the Payment Info ID.

Guideline : If the Instruction ID is not included in the payment initiation, but a Payment Info ID is provided, it is recommended to provide back the 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 text.

KREF means ‘generic customer reference’. Is the same code as for the ‘trigger’ in subfield 7 of field 61.

This means this is a reference that is meaningfull for the account owner (depending on how batch booking has been agreed).

B. account servicer can provide ‘reference type’

Line 1 /PREF/followed by max 35 text.

/PREF/ identifies the Payment Info ID.

This code is used to identify the Payment Info ID included in the payment initiation. Guideline : as it is recommended in this 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

Message item Occurrence Type

Group Header [1..1] Component

Message Identification [1..1] Max35Text Point-to-point element, so not transported in interbank chain

Creation DateTime [1..1] ISODateTime Point-to-point element, so not transported in interbank chain

Authorisation [0..2] Max128Text Point-to-point element, so not transported in interbank chain

Number of Transactions [1..1] Max15NumericText Point-to-point element, so not transported in interbank chain

Control Sum [0..1] DecimalNumber Point-to-point element, so not transported in 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 Identification [1..1] Max35Text

Point-to-point element, so not transported in interbank chain

Payment Method [1..1] Code

Point-to-point element, so not transported in interbank chain. CHK will result in issuance of cheque, TRF may result in a.o. actual creation of MT 103.

BatchBooking [0..1] Indicator Point-to-point element, so not transported in interbank chain

Number of Transactions [0..1] Max15NumericText Point-to-point element, so not transported in interbank chain



Control Sum [0..1] DecimalNumber Point-to-point element, so not transported in interbank chain

Payment Type Information [0..1] Component

Instruction priority [0..1] Code Point-to-point element, so not transported in 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

Code or [1..1] Code

Codes CORT and INTC will be mapped to 23E of MT 103: Instruction Code CORT and INTC. Other codes will not be mapped.


Requested Execution Date [1..1] ISODate Not mapped – but used to determine subfield 1 of 32A ( the interbank settlement date)

Pooling Adjustment Date [0..1] ISODate Point-to-point element, so not transported in interbank chain

Debtor [1..1] Component + Field 50 – Ordering Customer. Please see translation rules PACS 008– MT 103.

Debtor Account [1..1] Component Field 50 – Ordering Customer Please see translation rules PACS 008 – MT 103.

Id [1..1] Component + Field 50 – Ordering Customer 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

Debtor Agent [1..1] Component + Mapped to field 52 Ordering Institution 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

Charge Bearer [0..1] Code

Field 71A Charge Bearer : - DEBT > OUR - SHAR > SHA - CRED > BEN - SLEV > SHA

Charges Account [0..1] Component + Point-to-point element, not transported in interbank chain

Charges Account Agent [0..1] Component + Point-to-point element, not transported in interbank chain

Credit Transfer Transaction [1..n] Component



Information

Payment Identification [1..1] Component

Instruction ID [0..1] Max35Text Point-to-point element, not transported in interbank chain

End-to-end ID [1..1] Max35Text

Field 70 : /ROC/ (depending on presence of Remittance Identification in Related Remittance Information). See the detailed translation rules for more information.

Payment Type Information [0..1] Component +

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 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 Point-to-point element, not transported in interbank chain

Charge Bearer [0..1] Code

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 above.

Cheque instruction [0..1] Component +

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 generate an MT 103

Ultimate Debtor [0..1] Component + Cannot be mapped

Intermediary Agent 1 [0..1] Component +

Receiver of MT 103 (if receiver of the pain.001 message respects/has to respect the route set by the initiating party of the pain.001)

Intermediary Agent 1 Account [0..1] Component +

Not mapped (unless intermediary agent has multiple accounts at the Sender, and the Sender indicates in the MT 103 which account has been used for reimbursement (in field 53B).


Field 56a Intermediary (if no intermediary agent 3 is present) See comment below for Intermediary agent 3.

Intermediary Agent 2 Account [0..1] Component +

Field 56a Intermediary, optional party identifier line. Only Account ID will be mapped. 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).

Intermediary Agent 3 Account [0..1] Component + See comment for Intermediary agent 3.



Creditor Agent [0..1] Component + Mapped to field 57a Account With Institution (when different from the Receiver of MT 103)

Creditor Agent Account [0..1] Component +

Mapped to field 57a Account With Institution (optional account number line). Only Account ID will be mapped.

Creditor [0..1] Component +

Mapped to field 59a Beneficiary Customer. Please see translation rules PACS 008.001.01 – MT 103.

Creditor Account [0..1] Component +

Mapped to field 59a Beneficiary Customer (account number line). Only the account ID will be mapped.

ID [1..1] Component Mapped to field 59a Beneficiary Customer (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

Code [0..1] Code

Field 23E Instruction Code. CHQB > will be mapped to CHQB. HOLD > will be mapped to HOLD PHOB > will be mapped to PHOB. TELB > will be mapped to TELB

Instruction Information [0..1] Max140Text

Field 23E Instruction Code/Additional information For details, please see mapping PACS 008– MT 103

Instruction for Debtor Agent [0..1] Max140Text Point-to-point element, so not transported in 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

Information [0..1] Max35Text

Map to 3 lines of field 77B Regulatory reporting. For details, please see mappng PACS 008 – MT 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

Total Taxable Base Amount [0..1] CurrencyAndAmount

Cannot be mapped

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

Remittance Id [0..1] Max35Text Map to Field 70, /ROC/, check detailed translation rules PACS 008 – MT 103

Remittance Location Method [0..1] Code Cannot be mapped

Remittance Location Electronic Adress [0..1] Max2048Text

Cannot be mapped

Remittance Location Postal Address [0..1] Component

Cannot be mapped


Address [1..1] Component Cannot be mapped

Remittance Information [0..1] Choice component

Unstructured [0..n] Max140Text Mapped to field 70 Remittance Details – see 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

AdjustmentAmountAndReason [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

- MT 941 Balance Report

- combination of MT 942 and MT 941

camt.052 (Bank-to-Customer Account Report)

- MT 940 Customer Statement

- MT 950 Statement

camt.053 (Bank-to-Customer Statement)

- MT 900 Confirmation of Debit

- MT 910 Confirmation of Credit

- combination of MT 900 and MT 910

camt.054 (Bank-to-Customer Debit/Credit Notification)

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

(used to answer to a request for Statement message)

Not included

M 25 Account Identification 1..1 Report/Account 2.10

M 28C Statement Number/Sequence Number

0..1 Report/ElectronicSequenceNumber 2.2

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

Note: If field 86 is formatted 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.

0..1 Report/Entry/AdditionalEntryInformation or Report/Entry/EntryDetails/Batch or Report/Entry/EntryDetails/TransactionDetails

2.314 2.136 2.142

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/TotalCreditEntries

2.49

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 :

Debit/Credit/ Reversal of Credit(debit entry)/ Reversal of Debit (credit entry)/ Expected Debit/Expected Credit

1..1 Entry/CreditDebitIndicator 2.79 0..1 Entry/ReversalIndicator 2.80 0..1 Entry/Status (booked/pending) 2.81

O Funds Code (3rd character of the currency code, if needed)

Not required

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

Note: Field 86 may be used in a structured form as an extension to field 61. For example in field 61 using code ‘KREF’ to indicate that the associated reference(s) are specified in field 86.

0..1* Entry/EntryDetails/Batch/ (when batch or aggregate booking): Message ID and/or PaymentInfoID

2.137 2.138

Entry/EntryDetails/TransactionDetails/References (when booking for single transaction : Instruction ID and/or Transaction ID and/or EndToEndID and/or MandateID and/or ClearingSystemReference and/or ChequeNumber and/or Proprietary

2.147 2.149 2.148 2.150 2.152 2.151 2.153

Entry/EntryDetails/TransactionDetails/RelatedRemittanceInformation/RemittanceIdentification

2.250

Entry/EntryDetails/TransactionDetails/RemittanceInformation/Structured/CreditorReferenceInformation/CreditorReference

2.277

O Account Servicing Institution's Reference

0..1 Entry/AccountServicerReference 2.143

O Supplementary Details 0..1 Entry/AdditionalEntryInformation and/or Entry/EntryDetails/TransactionDetails/AdditionalTransactionInformation

2.314 2.313

* 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.



6.2 Comparison MT 941 to camt.052 The comparison below provides an analysis on the level of correspondence between MT 941 (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

M 25 Account Identification 1..1 Report/Account 2.10 M 28 Statement Number/Sequence

Number 0..1 Report/ElectronicSequenceNumber 2.2

0..1 Report/LegalSequenceNumber 2.3 0..1 GroupHeader/MessagePagination 1.4

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

s 2.49

M 62F Closing Balance (Booked Funds)

0..1 Report/Balance (see below) 2.23

O 64 Closing Available Balance (Available Balance)

0..1 Report/Balance (see below) 2.23

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))

Status Field Name Mult. Message Item Index O Opening Balance

(option F) *** Opening Booked Balance

(translation default balance type code “PRCD”) 2.25

M Closing Balance (Booked Funds) (option F) ***

Closing Booked Balance (translation default balance type code “ITBD”)

2.25

O Closing Available Balance Closing Available Balance (translation default balance type code “CLAV”)

2.25

O Forward Available Balance (repetitive)

Forward Available Balance (translation default balance type code “FWAV”)

2.25

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

(typed by CurrencyAndAmount) 2.34

Amount 1..1 Amount (typed by CurrencyAndAmount)

2.34

*** 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);



6.3 Comparison MT 940 to camt.053 The comparison below provides an analysis on the level of correspondence between MT 940 (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

M 25 Account Identification 1..1 Statement/Account 2.10


0..1 Statement/ElectronicSequenceNumber 2.2 0..1 Statement/LegalSequenceNumber 2.3 0..1 GroupHeader/MessagePagination 1.4

M 60a Opening Balance (option F or M) *

1..1 Statement/Balance (translation default balance type code “PRCD”)

2.23

O 61 Statement Line (see below) 0..n Statement/Entry (see below) 2.76 O 86 Information to Account Owner

Note: If field 86 is formatted 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.

0..1 Report/Entry/AdditionalEntryInformation or Report/Entry/EntryDetails/Batch or Report/Entry/EntryDetails/TransactionDetails

2.329 2.136 2.142

M 62a Closing Balance (option F or M) *

1..1 Statement/Balance (translation default balance type code “CLBD”)

2.23

O 64 Closing Available Balance 0..1 Statement/Balance (translation default balance type code “CLAV”)

2.23

O 65 Forward Available Balance (rep) 0..n Statement/Balance (translation default balance type code “FWAV”)

2.23

O 86 Information to Account Owner 0..1 Statement/AdditionalStatementInformation 2.315






1..1 Entry/CreditDebitIndicator 2.79 0..1 Entry/ReversalIndicator 2.80


Not required

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 Note: Field 86 may be used in a structured form as an extension to field 61. For example in field 61 using code ‘KREF’ to indicate that the associated reference(s) are specified in field 86.

0..1** Entry/Batch/ (when batch or aggregate booking): Message ID and/or PaymentInfoID

2.137 2.138

Entry/TransactionDetails/References (when booking for single transaction : Instruction ID and/or Transaction ID and/or EndToEndID and/or MandateID and/or ClearingSystemReference and/or ChequeNumber and/or Proprietary

2.147 2.149 2.148 2.150 2.152 2.151 2.153

Entry/TransactionDetails/RelatedRemittanceInformation/RemittanceIdentification

2.228

Entry/TransactionDetails/RemittanceInformation/Structured/CreditorReferenceInformation/CreditorReference

2.256



O Supplementary Details 0..1 Entry/AdditionalEntryInformation and Entry/TransactionDetails/AdditionalTransactionInformation

2.314 2.313

* 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 the Bank-to-Customer Cash Management Message Definition Report states that at least one reference must be present..



6.4 Comparison MT 950 to camt.053 The comparison below provides an analysis on the level of correspondence between MT 950 (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


0..1 Statement/ElectronicSequenceNumber 2.2 0..1 Statement/LegalSequenceNumber 2.3 0..1 GroupHeader/MessagePagination 1.4

M 60a Opening Balance (option F or M) *

1..1 Statement/Balance (translation default balance type code “PRCD”)

2.23

O 61 Statement Line (see below) 0..n Statement/Entry (see below) 2.76 M 62a Closing Balance

(option F or M) * 1..1 Statement/Balance

(translation default balance type code “CLBD”) 2.23

O 64 Closing Available Balance 0..1 Statement/Balance (translation default balance type code “CLAV”)

2.23




1..1 Entry/CreditDebitIndicator 2.79 0..1 Entry/ReversalIndicator 2.80


Not required

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): Message ID and/or PaymentInfoID

2.137 2.138

Entry/TransactionDetails/References (when booking for single transaction : Instruction ID and/or Transaction ID and/or

2.147 2.149



EndToEndID and/or MandateID and/or ClearingSystemReference and/or ChequeNumber and/or Proprietary

2.148 2.150 2.152 2.151 2.153

Entry/TransactionDetails/RelatedRemittanceInformation/RemittanceIdentification

2.228

Entry/TransactionDetails/RemittanceInformation/Structured/CreditorReferenceInformation/CreditorReference

2.256



O Supplementary Details 0..1 Entry/AdditionalEntryInformation and Entry/EntryDetails/TransactionDetails/AdditionalTransactionInformation

2.314 2.313

* 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 the Bank-to-Customer Cash Management Message Definition Report states that at least one reference must be present.



6.5 Comparison MT 900 to camt.054 The comparison below provides an analysis on the level of correspondence between MT 900 (Confirmation of Debit) and the MX camt.054 (Bank-to-Customer Credit/Debit Notification). It does not represent the additional information that can be included in the MX message.

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

(In the MT 900, this field contains the reference number of the transaction which resulted in this message, e.g., the field 20 Transaction Reference Number of the SWIFT payment instruction.)

0..1 * Notification/Entry/Batch/ (when batch or aggregate booking) Message ID and/or PaymentInfoID

2.117 2.118

Notification/Entry/EntryDetails/TransactionDetails/References (when booking for single transaction : Instruction ID and/or Transaction ID and/or EndToEndID and/or MandateID and/or ClearingSystemReference and/or ChequeNumber and/or Proprietary

2.127 2.129 2.128 2.130 2.132 2.131 2.133

Notification/Entry/EntryDetails/TransactionDetails/RelatedRemittanceInformation/RemittanceIdentification

2.208

Notification/Entry/EntryDetails/TransactionDetails/RemittanceInformation/Structured/CreditorReferenceInformation/CreditorReference

2.236

M 25 Account Identification 1..1 Notification/ Account 2.10 M 32A Value Date, Currency Code,

Amount 0..1 Notification/ Entry/ValueDate

(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

2.63



days”. 1..1 Notification/ Entry/Amount 2.58

O 52a Ordering Institution (MT 900 has only Ordering Institution, not Ordering Customer, – as in MT 910)

0..1 Notification/Entry/EntryDetails/TransactionDetails/RelatedParties/Debtor (in the case where the debit was initiated by the account owner)

2.181

0..1 Notification/Entry/EntryDetails/TransactionDetails/RelatedAgents/DebtorAgent (in case where the debit was initiated by the account servicing institution)

2.192

0..1 Notification/Entry/EntryDetails/TransactionDetails/RelatedParties/Creditor (in the case of eg a DirectDebit) or UltimateCreditor (also in the case of a Direct Debit)

2.184 2.186

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 ***

(translation default “DBIT”) 2.59

1..1 Notification /Entry /Status (translation default “BOOK”)

2.61

1..1 Notification /Entry /BankTransactionCode (translation default “UNKNOWN”)

2.71

* 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



6.6 Comparison MT 910 to camt.054 The comparison below provides an analysis on the level of correspondence between MT 910 (Confirmation of Credit) and the MX camt.054 (Bank-to-Customer Credit/Debit Notification). It does not represent the additional information that can be included in the MX message.

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

(In the MT 910, this field contains the reference number of the transaction which resulted in this message, e.g., the field 20 Transaction Reference Number of the SWIFT payment instruction, or field 21 of an MT 202.)

0..1 * Notification/Entry/EntryDetails/Batch/ (when batch or aggregate booking) Message ID and/or PaymentInfoID

2.117 2.118

Notification/Entry/EntryDetails/TransactionDetails/References (when booking for single transaction : Instruction ID and/or Transaction ID and/or EndToEndID and/or MandateID and/or ClearingSystemReference and/or ChequeNumber and/or Proprietary

2.127 2.129 2.128 2.130 2.132 2.131 2.133

Notification/Entry/EntryDetails/TransactionDetails/RelatedRemittanceInformation/RemittanceIdentification

2.208

Notification/Entry/EntryDetails/TransactionDetails/RemittanceInformation/Structured/CreditorReferenceInformation/CreditorReference

2.236

M 25 Account Identification 1..1 Notification/ Account 2.10 M 32A Value Date, Currency Code,

Amount 0..1 Notification/ Entry/ValueDate

(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”.

2.63



1..1 Notification/ Entry/Amount 2.58 O 50a Ordering Customer 0..1 Notification//Entry/EntryDetails/TransactionDetail

s/RelatedParties/Debtor DebtorAccount

2.181 2.182

O 52a Ordering Institution 0..1 Notification/Entry/EntryDetails/TransactionDetails/RelatedParties/Debtor

2.181

O 56a Intermediary 0..1 Notification/Entry/EntryDetails/TransactionDetails/RelatedParties/IntermediaryAgent1

2.194

O 72 Sender to Receiver Information 0..1 Notification/EntryDetails/AdditionalTransactionInformation

2.293

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 ***

(translation default “CRDT”) 2.59

1..1 Notification /Entry /Status (translation default “BOOK”)

2.61

1..1 Notification /Entry /BankTransactionCode (translation default “UNKNOWN”)

2.71

* 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.

Documents

Standards MX Message Implementation Guide and Rule · PDF filePayment Initiation and Account Reporting . ... • Standards MX Message Implementation Guide and Rule Book, ... SEB ,