Upload
ngomien
View
427
Download
21
Embed Size (px)
Citation preview
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
3 Standards MX Message Implementation Guide (Dec 2011)
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
4 Standards MX Message Implementation Guide (Dec 2011)
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
5 Standards MX Message Implementation Guide (Dec 2011)
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).
SWIFT for Corporates
6 Standards MX Message Implementation Guide (Dec 2011)
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:
Message Rules and Guidelines
7 Standards MX Message Implementation Guide (Dec 2011)
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’)
SWIFT for Corporates
8 Standards MX Message Implementation Guide (Dec 2011)
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
9 Standards MX Message Implementation Guide (Dec 2011)
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
SWIFT for Corporates
10 Standards MX Message Implementation Guide (Dec 2011)
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
11 Standards MX Message Implementation Guide (Dec 2011)
Customer Credit Transfer Initiation (pain.001.001.03)
Message Level
SWIFT for Corporates
12 Standards MX Message Implementation Guide (Dec 2011)
Customer Credit Transfer Initiation (pain.001.001.03)
Transaction Level
Payment Initiation
13 Standards MX Message Implementation Guide (Dec 2011)
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).
SWIFT for Corporates
14 Standards MX Message Implementation Guide (Dec 2011)
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
15 Standards MX Message Implementation Guide (Dec 2011)
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)
SWIFT for Corporates
16 Standards MX Message Implementation Guide (Dec 2011)
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
17 Standards MX Message Implementation Guide (Dec 2011)
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.
Standard Specifications
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.
CGI Message Implementation Templates
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
Message Schema Components
The Payment Status Report message is composed of the following structure.
SWIFT for Corporates
18 Standards MX Message Implementation Guide (Dec 2011)
Payment Status Report (pain.002.001.03)
Message Level
Payment Initiation
19 Standards MX Message Implementation Guide (Dec 2011)
Payment Status Report (pain.002.001.03)
Transaction Information and Status Level
SWIFT for Corporates
20 Standards MX Message Implementation Guide (Dec 2011)
Payment and Status Flow
The diagrams below from CGI illustrate the potential usage scenarios covered by the Payment Status Report.
SWIFT for Corporates
22 Standards MX Message Implementation Guide (Dec 2011)
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
23 Standards MX Message Implementation Guide (Dec 2011)
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.
SWIFT for Corporates
24 Standards MX Message Implementation Guide (Dec 2011)
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
25 Standards MX Message Implementation Guide (Dec 2011)
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.
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 Direct Debit V2 Message Implementation Guide 28 July 2011
Message Schema Components
The Customer Direct Debit Initiation message is composed of the structures that follow.
SWIFT for Corporates
26 Standards MX Message Implementation Guide (Dec 2011)
Customer Direct Debit Initiation (pain.008.001.02)
Message Level
Payment Initiation
27 Standards MX Message Implementation Guide (Dec 2011)
Customer Direct Debit Initiation (pain.008.001.02)
Transaction Level
SWIFT for Corporates
28 Standards MX Message Implementation Guide (Dec 2011)
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
29 Standards MX Message Implementation Guide (Dec 2011)
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.
Standard Specifications
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.
SWIFT for Corporates
30 Standards MX Message Implementation Guide (Dec 2011)
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 Cash Management V2 Message Implementation Guide 28 July 2011
Appendix A – Use Cases and Samples Latest version
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.
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.
Common Message Components
31 Standards MX Message Implementation Guide (Dec 2011)
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.
SWIFT for Corporates
32 Standards MX Message Implementation Guide (Dec 2011)
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)
Common Message Components
33 Standards MX Message Implementation Guide (Dec 2011)
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
SWIFT for Corporates
34 Standards MX Message Implementation Guide (Dec 2011)
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)
Common Message Components
35 Standards MX Message Implementation Guide (Dec 2011)
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.
SWIFT for Corporates
36 Standards MX Message Implementation Guide (Dec 2011)
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.
Common Message Components
37 Standards MX Message Implementation Guide (Dec 2011)
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)
SWIFT for Corporates
38 Standards MX Message Implementation Guide (Dec 2011)
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.
Common Message Components
39 Standards MX Message Implementation Guide (Dec 2011)
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.
SWIFT for Corporates
40 Standards MX Message Implementation Guide (Dec 2011)
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
Common Message Components
41 Standards MX Message Implementation Guide (Dec 2011)
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.
SWIFT for Corporates
42 Standards MX Message Implementation Guide (Dec 2011)
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.
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 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.
Common Message Components
43 Standards MX Message Implementation Guide (Dec 2011)
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.
SWIFT for Corporates
44 Standards MX Message Implementation Guide (Dec 2011)
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
Common Message Components
45 Standards MX Message Implementation Guide (Dec 2011)
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.
SWIFT for Corporates
46 Standards MX Message Implementation Guide (Dec 2011)
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
47 Standards MX Message Implementation Guide (Dec 2011)
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.
SWIFT for Corporates
48 Standards MX Message Implementation Guide (Dec 2011)
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.
Mapping Guidelines MX - MT
49 Standards MX Message Implementation Guide (Dec 2011)
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
SWIFT for Corporates
50 Standards MX Message Implementation Guide (Dec 2011)
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
Code or [1..1] Code Cannot be mapped
Proprietary [1..1] Max35Text 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.
Proprietary [1..1] Max35Text Cannot 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
Code or [1..1] Code Cannot be mapped
Proprietary [1..1] Max35Text 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
Mapping Guidelines MX - MT
51 Standards MX Message Implementation Guide (Dec 2011)
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).
Intermediary Agent 2 [0..1] Component +
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.
Intermediary Agent 3 [0..1] Component +
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.
SWIFT for Corporates
52 Standards MX Message Implementation Guide (Dec 2011)
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
Code or [1..1] Code Cannot be mapped
Proprietary [1..1] Max35Text Cannot be mapped
Currency [0..1] Currency Code Cannot be mapped
Name [0..1] Max70Text 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
Proprietary [1..1] Max140Text 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
Name [0..1] Max140Text 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
Mapping Guidelines MX - MT
53 Standards MX Message Implementation Guide (Dec 2011)
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
Name [1..1] Max140Text 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
SWIFT for Corporates
54 Standards MX Message Implementation Guide (Dec 2011)
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
55 Standards MX Message Implementation Guide (Dec 2011)
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.
SWIFT for Corporates
56 Standards MX Message Implementation Guide (Dec 2011)
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
Comparison MT – MX
57 Standards MX Message Implementation Guide (Dec 2011)
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.
SWIFT for Corporates
58 Standards MX Message Implementation Guide (Dec 2011)
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.
Points of difference are highlighted in yellow. The target camt.052 fields designated in the Standards Translation Rules are highlighted in blue.
MT 941 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 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
Comparison MT – MX
59 Standards MX Message Implementation Guide (Dec 2011)
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);
SWIFT for Corporates
60 Standards MX Message Implementation Guide (Dec 2011)
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.
Points of difference are highlighted in yellow. The target camt.053 fields designated in the Standards Translation Rules are highlighted in blue.
MT 940 MX camt.053
Status Tag Field Name Mult. Message Item Index
M 20 Transaction Reference Number 1..1 Statement/Identification 2.1 O 21 Related Reference
(used to answer to a request for Statement message)
Not included
M 25 Account Identification 1..1 Statement/Account 2.10
M 28C Statement Number/Sequence Number
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
Comparison MT – MX
61 Standards MX Message Implementation Guide (Dec 2011)
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
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/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 Account Servicing Institution's Reference
0..1 Entry/AccountServicerReference 2.84
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..
SWIFT for Corporates
62 Standards MX Message Implementation Guide (Dec 2011)
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.
Points of difference are highlighted in yellow. The target camt.053 fields designated in the Standards Translation Rules are highlighted in blue.
MT 950 MX camt.053
Status Tag Field Name Mult. Message Item Index
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 Number
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
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
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 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
Comparison MT – MX
63 Standards MX Message Implementation Guide (Dec 2011)
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 Account Servicing Institution's Reference
0..1 Entry/AccountServicerReference 2.84
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.
SWIFT for Corporates
64 Standards MX Message Implementation Guide (Dec 2011)
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.
Points of difference are highlighted in yellow. The target camt.054 fields designated in the Standards Translation Rules are highlighted in blue.
MT 900 MX camt.054
Status Tag Field Name Mult. Message Item Index
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
Comparison MT – MX
65 Standards MX Message Implementation Guide (Dec 2011)
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
SWIFT for Corporates
66 Standards MX Message Implementation Guide (Dec 2011)
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.
Points of difference are highlighted in yellow. The target camt.054 fields designated in the Standards Translation Rules are highlighted in blue.
MT 910 MX camt.054
Status Tag Field Name Mult. Message Item Index
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
Comparison MT – MX
67 Standards MX Message Implementation Guide (Dec 2011)
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
SWIFT for Corporates
68 Standards MX Message Implementation Guide (Dec 2011)
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.