Standards MX Message Implementation Guide and Rule Book

Transcription

1 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 payment initiation and account reporting messages using FileAct in SCORE (Standardised Corporate Environment) 01 December 2011

2 Preface Table of Contents 1 Message Rules and Guidelines Key Rules Rule and Guideline Conventions Payment Initiation Overview Customer Credit Transfer Initiation Payment Status Report Customer Direct Debit Initiation Account Reporting Overview Account Reporting Messages Common Message Components Mapping Guidelines MX - MT Mapping from pain.001 to MT Mapping from pain.001 to MT Comparison MT - MX Comparison MT 942 to camt Comparison MT 941 to camt Comparison MT 940 to camt Comparison MT 950 to camt Comparison MT 900 to camt Comparison MT 910 to camt Standards MX Message Implementation Guide (Dec 2011)

3 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 Customer Credit Transfer Initiation, the ISO Customer Direct Debit Initiation and ISO Payment Status Report messages. Account Reporting - bank-to-customer reporting of account activity information, using the ISO Bank-to-Customer Account Report, the ISO Bank-to-Customer Statement, and the ISO 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 Message Updates adoption of later ISO message versions: - camt BankToCustomerAccountReportV02 - camt BankToCustomerStatementV02 - camt BankToCustomerDebitCreditNotificationV02 - pain CustomerCreditTransferInitiationV03 - pain CustomerPaymentStatusReportV03 - pain 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 Credit Transfer V3 Message Implementation Guide 13 June ISO Payment Status Report V3 Message Implementation Guide 13 June ISO Direct Debit V2 Message Implementation Guide 28 July ISO Cash Management V2 Message Implementation Guide 28 July Standards MX Message Implementation Guide (Dec 2011)

4 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 message and to other related activities.this is achieved through consultation, collaboration and agreement on common implementation templates for relevant ISO 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 nonfinancial institutions having a common interest in collaboration, promotion and adoption of the ISO 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 payment initiation messages to the subsequent MT messages Section 6 provides a comparison of the account reporting MT messages with the corresponding ISO messages. 4 Standards MX Message Implementation Guide (Dec 2011)

5 Message Rules and Guidelines 1 Message Rules and Guidelines 1.1 Key Rules Support of ISO Messages For Payment Initiation and Account Reporting the following ISO Messages are applicable: camt BankToCustomerAccountReportV02 camt camt pain pain pain BankToCustomerStatementV02 BankToCustomerDebitCreditNotificationV02 CustomerCreditTransferInitiationV03 CustomerPaymentStatusReportV03 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 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 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). 5 Standards MX Message Implementation Guide (Dec 2011)

6 SWIFT for Corporates 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 / -? : ( )., ' + 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 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 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: 6 Standards MX Message Implementation Guide (Dec 2011)

7 Message Rules and Guidelines Document Type Core Template Appendices Description This represents the core CGI implementation guidance for the use of the designated ISO 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. 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 ) 7 Standards MX Message Implementation Guide (Dec 2011)

8 SWIFT for Corporates 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). 8 Standards MX Message Implementation Guide (Dec 2011)

9 Payment Initiation 2 Payment Initiation 2.1 Overview The implementation rules and guidelines included in this chapter relate to the following ISO Payment Initiation messages : Customer Credit Transfer Initiation Version 3 (pain ) Customer Direct Debit Initiation Version 2 (pain ) Payment Status Report Version 3 (pain ) 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 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 Message Definition Report Payment Initiation ( 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 9 Standards MX Message Implementation Guide (Dec 2011)

10 SWIFT for Corporates descriptions for the full ISO Payment Initiation portfolio, ie, it also included other payment initation messages. ISO Message schema s and samples (pain , pain and pain ) ( ISO Customer to Bank Message Usage Guide Customer Credit Transfer Initiation, Customer Direct Debit Initiation and Payment Status Report ( 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 ( contains the same information as the ISO Message Definition Report, but includes the cash reporting messages and is also available in HTML format. CGI Message Implementation Template ( 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 Message Definition Report and when published/updated the ISO 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 Credit Transfer V3 Message Implementation Guide 13 June 2011 Appendix A Payment System References Appendix B Country Specific Requirements Latest version Latest version Message Schema Components The Customer Credit Transfer Initiation message is composed of the structures that follow. 10 Standards MX Message Implementation Guide (Dec 2011)

11 Payment Initiation Customer Credit Transfer Initiation (pain ) Message Level 11 Standards MX Message Implementation Guide (Dec 2011)

12 SWIFT for Corporates Customer Credit Transfer Initiation (pain ) Transaction Level 12 Standards MX Message Implementation Guide (Dec 2011)

13 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 SCORE Guideline 3 If Batch Booking is not present, pre-agreed client-bank conditions will apply. 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). 13 Standards MX Message Implementation Guide (Dec 2011)

14 SWIFT for Corporates Instruction Priority 2.32 (Payment Information/PaymentTypeInformation/Instruction Priority) (0..1) CGI Rule SCORE Guideline Based on whether priority processing versus normal processing is offered by the bank. 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. 14 Standards MX Message Implementation Guide (Dec 2011)

15 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 Message Definition Report. The most recent ISO 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 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) 15 Standards MX Message Implementation Guide (Dec 2011)

16 SWIFT for Corporates Payment transaction reference : 2.29 Instruction ID (0..1) 2.30 End to End ID (1..1) Underlying transaction (remittance) references : Remittance Identification Creditor Reference 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 16 Standards MX Message Implementation Guide (Dec 2011)

17 2.3 Payment Status Report Scope Payment Initiation 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 Message Definition Report and the ISO 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 Payment Status Report V3 Message Implementation Guide 13 June 2011 Message Schema Components The Payment Status Report message is composed of the following structure. 17 Standards MX Message Implementation Guide (Dec 2011)

18 SWIFT for Corporates Payment Status Report (pain ) Message Level 18 Standards MX Message Implementation Guide (Dec 2011)

19 Payment Initiation Payment Status Report (pain ) Transaction Information and Status Level 19 Standards MX Message Implementation Guide (Dec 2011)

20 SWIFT for Corporates Payment and Status Flow The diagrams below from CGI illustrate the potential usage scenarios covered by the Payment Status Report. 20 Standards MX Message Implementation Guide (Dec 2011)

21 Payment Initiation 21 Standards MX Message Implementation Guide (Dec 2011)

22 SWIFT for Corporates 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. 22 Standards MX Message Implementation Guide (Dec 2011)

23 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 preagreed 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. 23 Standards MX Message Implementation Guide (Dec 2011)

24 SWIFT for Corporates 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. 24 Standards MX Message Implementation Guide (Dec 2011)

25 2.4 Customer Direct Debit Initiation Scope Payment Initiation 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 Message Definition Report and when published/updated the ISO 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 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. 25 Standards MX Message Implementation Guide (Dec 2011)

26 SWIFT for Corporates Customer Direct Debit Initiation (pain ) Message Level 26 Standards MX Message Implementation Guide (Dec 2011)

27 Payment Initiation Customer Direct Debit Initiation (pain ) Transaction Level 27 Standards MX Message Implementation Guide (Dec 2011)

28 SWIFT for Corporates 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 ) Bank-to-Customer Statement Version 2 (camt ) Bank-to-Customer Debit/Credit Notification Version 2 (camt ) 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 may require the document to be revised, in concert with the approval and publication of the associated CGI Message Implementation Templates. 28 Standards MX Message Implementation Guide (Dec 2011)

29 Common Message Components Documentation The standards covered by this document are fully described in : ISO Message Definition Report Bank-to-Customer Cash Management ( 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 Bank-to-Customer Cash Management. ISO Message schema s and samples (camt , camt , and camt ) ( ISO 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 ( contains the same information as the ISO Message Definition Report, but includes the payment initiation messages and is also available in HTML format. CGI Message Implementation Template ( 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 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 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 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 Message Definition Report serves as the main document to describe the standard. Please consult this document for full information on the messages. 29 Standards MX Message Implementation Guide (Dec 2011)

30 SWIFT for Corporates 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 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 SCORE Guideline 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 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. camt.054 (BankToCustomerDebitCredit Notification) can be used to report any types of outward and inward payment transactions. The type of notification is bilaterally determined. 30 Standards MX Message Implementation Guide (Dec 2011)

31 Common Message Components 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. 31 Standards MX Message Implementation Guide (Dec 2011)

32 SWIFT for Corporates 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) 32 Standards MX Message Implementation Guide (Dec 2011)

33 Common Message Components 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 33 Standards MX Message Implementation Guide (Dec 2011)

34 SWIFT for Corporates 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) 34 Standards MX Message Implementation Guide (Dec 2011)

35 Common Message Components 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. 35 Standards MX Message Implementation Guide (Dec 2011)

36 SWIFT for Corporates Entry Details Level camt.052 / (Report/Entry/EntryDetails (0..n) camt.053 / (Statement/ Entry/EntryDetails (0..n) camt 054 / (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. 36 Standards MX Message Implementation Guide (Dec 2011)

37 Common Message Components Transaction Details Level camt.052 / (Report/Entry/EntryDetails/TransactionDetails (0..n) camt.053 / (Statement/ Entry/EntryDetails/TransactionDetails (0..n) camt 054 / (Notification/ Entry/EntryDetails/TransactionDetails (0..n) 37 Standards MX Message Implementation Guide (Dec 2011)

38 SWIFT for Corporates References camt.052 / (Report/Entry/EntryDetails/TransactionDetails/References) (0..1) camt.053 / (Statement/Entry/ EntryDetails/TransactionDetails/References) (0..1) camt 054 / (Notification/Entry/ EntryDetails/TransactionDetails/References) (0..1) SCORE Guideline CGI Rule For debit entries, when known all references as assigned in the original payment instruction should be reported. The EndToEndIdentification must be reported when it is known by the reporting bank. For SEPA the EndToEndIdentification can be 'NOTPROVIDED'. Amount Details camt.052 / (Report/Entry/EntryDetails/TransactionDetails/AmountDetails) (0..1) camt.053 / (Statement/Entry/EntryDetails/TransactionDetails/AmountDetails) (0..1) camt.054 / (Notification/Entry/EntryDetails/TransactionDetails/AmountDetails) (0..1) CGI Rule CGI Guideline CGI Guideline 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. 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. TransactionAmount EPC Mandated for SEPA payments. 38 Standards MX Message Implementation Guide (Dec 2011)

39 Common Message Components 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 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. ProprietaryAmount This value can be used by the bank for additional amount reporting on community or bank-specific purposes. 39 Standards MX Message Implementation Guide (Dec 2011)

40 SWIFT for Corporates Related Parties camt.052 / (Report/Entry/EntryDetails/TransactionDetails/RelatedParties) (0..1) camt.053 / (Statement/Entry/EntryDetails/TransactionDetails/RelatedParties) (0..1) camt 054 / (Notification/Entry/EntryDetails/TransactionDetails/RelatedParties) (0..1) CGI Rule CGI Rule 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. 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. 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 40 Standards MX Message Implementation Guide (Dec 2011)

41 Common Message Components the original entry. CGI Rule 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. 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. 41 Standards MX Message Implementation Guide (Dec 2011)

42 SWIFT for Corporates 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. 42 Standards MX Message Implementation Guide (Dec 2011)

43 Common Message Components 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. 43 Standards MX Message Implementation Guide (Dec 2011)

44 SWIFT for Corporates FinancialInstitution Score Guideline Provide the BIC where possible, else Clearing System Member ID, else If other, agree with your bank CGI Rule CGI Guideline Note : for SEPA payments, BIC is required. For the payment initiation messages, country of DebitorAgent and CreditorAgent must be provided. 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 44 Standards MX Message Implementation Guide (Dec 2011)

45 Common Message Components 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. 45 Standards MX Message Implementation Guide (Dec 2011)

46 SWIFT for Corporates RemittanceInformation CGI Guideline CGI Guideline SCORE 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. Structured. Best practice for minimum usage: Populate invoice number and remitted amount or credit note amount with currency or Creditor's Reference Information. 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 (Structured creditor reference to remittance information), the Issuer should be specified with the text ISO (without the quote marks). 46 Standards MX Message Implementation Guide (Dec 2011)

47 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 Subfield 7 Subfield 8 1!a3!c Transaction Type Id code 16x reference for the account owner [/16x] Account servicing institution reference NTRF 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. 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. Reference attributed by the account servicer 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. 47 Standards MX Message Implementation Guide (Dec 2011)

48 SWIFT for Corporates B. account servicer can provide reference type (ie granular reference) : Line 1 /EREF/ followed by max 35 text. Continuation (from line 1) Continuation /EREF/ identies the End to End id. /IREF/ followed by max 35 text. /IREF/ identifies the Instruction ID. /PREF/followed by max 35 text. /PREF/ identifies the Payment Info ID. 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. 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 End to End ID. Guideline : it is mandatory to provide back the End to End ID in case of a single booking. Guideline : If the Instruction ID is included in the payment initiation, it is recommended to also provide back the Instruction 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. This means this is a reference that is meaningfull for the account owner (depending on how batch booking has been agreed). 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. 48 Standards MX Message Implementation Guide (Dec 2011)

49 Mapping Guidelines MX - MT For detailed translation information, please consult the pacs to MT 103 (and vice versa), and the pain 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 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. Message item pain MT 103 Occur rence Type Group Header [1..1] Component Message Identification [1..1] Max35Text Creation DateTime [1..1] ISODateTime Authorisation [0..2] Max128Text Point-to-point element, so not transported in interbank chain Point-to-point element, so not transported in interbank chain Point-to-point element, so not transported in interbank chain Number of Transactions [1..1] Max15NumericText Control Sum [0..1] DecimalNumber Point-to-point element, so not transported in interbank chain 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 Payment Method [1..1] Code BatchBooking [0..1] Indicator Number of Transactions [0..1] Max15NumericText Point-to-point element, so not transported in interbank chain 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. Point-to-point element, so not transported in interbank chain Point-to-point element, so not transported in interbank chain 49 Standards MX Message Implementation Guide (Dec 2011)

50 SWIFT for Corporates 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 Pooling Adjustment Date [0..1] ISODate Debtor [1..1] Component + Debtor Account [1..1] Component Id [1..1] Component + Not mapped but used to determine subfield 1 of 32A ( the interbank settlement date) Point-to-point element, so not transported in interbank chain Field 50 Ordering Customer. Please see translation rules PACS 008 MT 103. Field 50 Ordering Customer Please see translation rules PACS 008 MT 103. 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 Charges Account [0..1] Component + Charges Account Agent [0..1] Component + Field 71A Charge Bearer : - DEBT > OUR - SHAR > SHA - CRED > BEN - SLEV > SHA Point-to-point element, not transported in interbank chain Point-to-point element, not transported in interbank chain Credit Transfer Transaction [1..n] Component 50 Standards MX Message Implementation Guide (Dec 2011)

51 Mapping Guidelines MX - MT Information Payment Identification [1..1] Component Instruction ID [0..1] Max35Text End-to-end ID [1..1] Max35Text Payment Type Information [0..1] Component + Amount [1..1] Choice component Point-to-point element, not transported in interbank chain Field 70 : /ROC/ (depending on presence of Remittance Identification in Related Remittance Information). See the detailed translation rules for more information. Should not be present on this level according to the Rules set out in this document. Can only be present on Payment Information level. For proposed mapping, see Payment Type Information component above. 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 Charge Bearer [0..1] Code Cheque instruction [0..1] Component + Ultimate Debtor [0..1] Component + Cannot be mapped Intermediary Agent 1 [0..1] Component + Intermediary Agent 1 Account [0..1] Component + Intermediary Agent 2 [0..1] Component + Intermediary Agent 2 Account [0..1] Component + Intermediary Agent 3 [0..1] Component + Point-to-point element, not transported in interbank chain Should not be present on this level according to the Rules set out in this Document, but can only be present on Payment Information level. For proposed mapping, see Charge Bearer element above. The entire component of Cheque Instruction is not mapped to the MT 103 : if cheque needs to be issued by debtor agent, the debtor agent will not generate an MT 103 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) 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. 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 Standards MX Message Implementation Guide (Dec 2011)

52 SWIFT for Corporates Creditor Agent [0..1] Component + Creditor Agent Account [0..1] Component + Creditor [0..1] Component + Creditor Account [0..1] Component + ID [1..1] Component 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 Instruction Information [0..1] Max140Text Instruction for Debtor Agent [0..1] Max140Text Mapped to field 57a Account With Institution (when different from the Receiver of MT 103) Mapped to field 57a Account With Institution (optional account number line). Only Account ID will be mapped. Mapped to field 59a Beneficiary Customer. Please see translation rules PACS MT 103. Mapped to field 59a Beneficiary Customer (account number line). Only the account ID will be mapped. Mapped to field 59a Beneficiary Customer (account number line) 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 Purpose [0..1] Component Cannot be mapped Code or [1..1] Max3Text Cannot be mapped Proprietary [1..1] Max140Text Cannot be mapped Field 23E Instruction Code/Additional information For details, please see mapping PACS 008 MT 103 Point-to-point element, so not transported in interbank chain 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 Tax [0..1] Component Cannot be mapped Map to 3 lines of field 77B Regulatory reporting. For details, please see mappng PACS 008 MT Standards MX Message Implementation Guide (Dec 2011)

53 Mapping Guidelines MX - MT Creditor [0..1] Component Cannot be mapped Tax Id [0..1] Max35Text Cannot be mapped RegistrationId [0..1] Max35Text Cannot be mapped Tax Type [0..1] Max35Text Cannot be mapped Debtor [0..1] Component Cannot be mapped Tax Id [0..1] Max35Text Cannot be mapped RegistrationId [0..1] Max35Text Cannot be mapped Tax Type [0..1] Max35Text Cannot be mapped Authorisation [0..1] Component Cannot be mapped AdministrationZone [0..1] Max35Text Cannot be mapped ReferenceNumber [0..1] Max140Text Cannot be mapped Method [0..1] Max35Text Cannot be mapped Cannot be mapped Total Taxable Base Amount [0..1] CurrencyAndAmount Total Tax Amount [0..1] CurrencyAndAmount Cannot be mapped Date [0..1] ISODate Cannot be mapped SequenceNumber [0..1] Number Cannot be mapped Record [0..n] Component Cannot be mapped Related Remittance Information [0..10] Component Remittance Id [0..1] Max35Text Remittance Location Method [0..1] Code Cannot be mapped Remittance Location Electronic Adress [0..1] Max2048Text Remittance Location Postal Address [0..1] Component Map to Field 70, /ROC/, check detailed translation rules PACS 008 MT 103 Cannot be mapped Cannot be mapped Name [1..1] Max140Text Cannot be mapped Address [1..1] Component Remittance Information [0..1] Choice component Unstructured [0..n] Max140Text Cannot be mapped 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 Referred Document Information [0..n] Component detailed translation rules PACS 008- MT 103 Type [0..1] Component 53 Standards MX Message Implementation Guide (Dec 2011)

54 SWIFT for Corporates CodeOrProprietary Code or [1..1] Code Proprietary [1..1] Max35Text Issuer [0..1] Max35Text Number [0..1] Max35Text Related Date [0..1] ISODate Referred Document Amt [0..1] Choice Component Due Payable Amt or [0..1] Currency And Amount Discount Applied Amt or [0..1] Currency And Amount Credit Note Amt or [0..1] Currency And Amount Tax Amount [0..1] CurrencyAndAmount AdjustmentAmountAndReas on [0..n] Component RemittedAmount [0..1] CurrencyAndAmount Creditor Reference Info [0..1] Component Type [0..1] Component CodeOrProprietary [1..1] ChoiceComponent Code or [1..1] Code Proprietary [1..1] Max35Text Issuer [0..1] Max35Text Reference [0..1] Max35Text Invoicer [0..1] Component Invoicee [0..1] Component Additional Remittance Info [0..3] Max140Text 54 Standards MX Message Implementation Guide (Dec 2011)

55 Comparison MT MX 6 Comparison MT - MX This section contains a comparison of the SWIFT category 9 messages with the ISO 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 - MT 942 Interim Transaction Report - MT 941 Balance Report - combination of MT 942 and MT MT 940 Customer Statement - MT 950 Statement - MT 900 Confirmation of Debit - MT 910 Confirmation of Credit - combination of MT 900 and MT 910 MX Message Types camt.052 (Bank-to-Customer Account Report) camt.053 (Bank-to-Customer Statement) 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. 55 Standards MX Message Implementation Guide (Dec 2011)

56 SWIFT for Corporates 6.1 Comparison MT 942 to camt.052 The comparison below provides an analysis on the level of correspondence between MT 942 (Interim Transaction Report ) and the MX camt.052 (Bank-to-Customer Account Report). It does not represent the additional information that can be included in the MX message. Points of difference are highlighted in yellow. The target camt.052 fields designated in the Standards Translation Rules are highlighted in blue. MT 942 MX camt.052 Status Tag Field Name Mult. Message Item Index M 20 Transaction Reference Number 1..1 Report/Identification 2.1 O 21 Related Reference Not included (used to answer to a request for Statement message) M 25 Account Identification 1..1 Report/Account 2.10 M 28C Statement Number/Sequence 0..1 Report/ElectronicSequenceNumber 2.2 Number 0..1 Report/LegalSequenceNumber 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 0..1 Report/Entry/AdditionalEntryInformation or Report/Entry/EntryDetails/Batch or Report/Entry/EntryDetails/TransactionDetails according to a predefined structure, the information may be mapped to elements in the Report/Entry/Batch or Report/Entry/TransactionDetails component, as appropriate. For example in field 86 using codes /EREF/ with End to End ID, /IREF/ with Instruction ID, /PREF/ with Payment Info ID, /KREF/ with generic customer reference. O 90D Number and Sum of Entries 0..1 Report/TransactionsSummary/TotalDebitEntrie 2.52 s O 90C Number and Sum of Entries 0..1 Report/TransactionsSummary/TotalCreditEntri 2.49 es O 86 Information to Account Owner 0..1 Report/AdditionalReportInformation Standards MX Message Implementation Guide (Dec 2011)

57 Comparison MT MX Field 61 Statement line Entry component (2.65 and following) Status Field Name Mult. Message Item Index M Value Date (YYMMDD) 0..1 Entry/ValueDate 2.83 O Entry Date (MMDD) 0..1 Entry/BookingDate 2.82 M Debit/Credit Mark : 1..1 Entry/CreditDebitIndicator 2.79 Debit/Credit/ 0..1 Entry/ReversalIndicator 2.80 Reversal of Credit(debit entry)/ 0..1 Entry/Status (booked/pending) 2.81 Reversal of Debit (credit entry)/ Expected Debit/Expected Credit O Funds Code (3rd character of the Not required currency code, if needed) M Amount 1..1 Entry/Amount 2.78 M Transaction Type Identification Code 1..1 Entry/BankTransactionCode 2.91 M* Reference for the Account Owner 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. O Account Servicing Institution's Reference 0..1* Entry/EntryDetails/Batch/ (when batch or aggregate booking): Message ID and/or PaymentInfoID 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 Entry/EntryDetails/TransactionDetails/RelatedRe mittanceinformation/remittanceidentification Entry/EntryDetails/TransactionDetails/Remittance Information/Structured/CreditorReferenceInforma tion/creditorreference 0..1 Entry/AccountServicerReference O Supplementary Details 0..1 Entry/AdditionalEntryInformation and/or Entry/EntryDetails/TransactionDetails/Additional TransactionInformation * Reference for Account Owner : even though all references in the MX message are optional, a rule in the Bank-to-Customer Cash Management Message Definition Report states that at least one reference must be present. 57 Standards MX Message Implementation Guide (Dec 2011)

58 SWIFT for Corporates 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 : Not included (used to answer to a request for Statement message) M 25 Account Identification 1..1 Report/Account 2.10 M 28 Statement Number/Sequence 0..1 Report/ElectronicSequenceNumber 2.2 Number 0..1 Report/LegalSequenceNumber 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 2.49 s M 62F Closing Balance (Booked 0..1 Report/Balance (see below) 2.23 Funds) O 64 Closing Available Balance 0..1 Report/Balance (see below) 2.23 (Available Balance) O 65 Forward Available Balance 0..n Report/Balance (see below) 2.23 O 86 Information to Account Owner 0..1 Report/AdditionalReportInformation Balance information in MT Balance information in MX (Report/Balance/BalanceDetails (repetitive (2.28)) Status Field Name Mult. Message Item Index O Opening Balance Opening Booked Balance 2.25 (option F) *** (translation default balance type code PRCD ) M Closing Balance (Booked Funds) Closing Booked Balance 2.25 (option F) *** (translation default balance type code ITBD ) O Closing Available Balance Closing Available Balance 2.25 (translation default balance type code CLAV ) O Forward Available Balance Forward Available Balance 2.25 (repetitive) (translation default balance type code FWAV ) Balance subfields in MT Balance subfields in MX Balance Debit/Credit Mark 1..1 CreditDebit Indicator Standards MX Message Implementation Guide (Dec 2011)

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

60 SWIFT for Corporates 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 Not included (used to answer to a request for Statement message) M 25 Account Identification 1..1 Statement/Account 2.10 M 28C Statement Number/Sequence 0..1 Statement/ElectronicSequenceNumber 2.2 Number 0..1 Statement/LegalSequenceNumber GroupHeader/MessagePagination 1.4 M 60a Opening Balance 1..1 Statement/Balance 2.23 (option F or M) * (translation default balance type code PRCD ) O 61 Statement Line (see below) 0..n Statement/Entry (see below) 2.76 O 86 Information to Account Owner Note: If field 86 is formatted 0..1 Report/Entry/AdditionalEntryInformation or Report/Entry/EntryDetails/Batch or Report/Entry/EntryDetails/TransactionDetails according to a predefined structure, the information may be mapped to elements in the Report/Entry/Batch or Report/Entry/TransactionDetails component, as appropriate. For example in field 86 using codes /EREF/ with End to End ID, /IREF/ with Instruction ID, /PREF/ with Payment Info ID, /KREF/ with generic customer reference. M 62a Closing Balance 1..1 Statement/Balance 2.23 (option F or M) * (translation default balance type code CLBD ) O 64 Closing Available Balance 0..1 Statement/Balance 2.23 (translation default balance type code CLAV ) O 65 Forward Available Balance (rep) 0..n Statement/Balance 2.23 (translation default balance type code FWAV ) O 86 Information to Account Owner 0..1 Statement/AdditionalStatementInformation Standards MX Message Implementation Guide (Dec 2011)

61 Comparison MT MX Field 61 Statement line Entry component (2.65 and following) Status Field Name Mult. Message Item Index M Value Date (YYMMDD) 0..1 Entry/ValueDate 2.83 O Entry Date (MMDD) 0..1 Entry/BookingDate 2.82 M Debit/Credit Mark : 1..1 Entry/CreditDebitIndicator 2.79 Debit/Credit/ 0..1 Entry/ReversalIndicator 2.80 Reversal of Credit(debit entry)/ Reversal of Debit (credit entry)/ Expected Debit/Expected Credit O Funds Code (3rd character of the Not required currency code, if needed) M Amount 1..1 Entry/Amount 2.78 M Transaction Type Identification Code 1..1 Entry/BankTransactionCode 2.91 M** Reference for the Account Owner Note: Field 86 may be used in a structured form as an extension to field 61. For 0..1** Entry/Batch/ (when batch or aggregate booking): Message ID and/or PaymentInfoID example in field 61 using code KREF to indicate that the associated reference(s) are specified in field 86. 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 Entry/TransactionDetails/RelatedRemittanceInfor mation/remittanceidentification Entry/TransactionDetails/RemittanceInformation/ Structured/CreditorReferenceInformation/Credito rreference O Account Servicing Institution's Reference 0..1 Entry/AccountServicerReference 2.84 O Supplementary Details 0..1 Entry/AdditionalEntryInformation and Entry/TransactionDetails/AdditionalTransaction Information * For a further breakdown of the balance component, please refer to the comparison included with the MT 941 Balance Report, section 5.2. ** Reference for Account Owner : even though all references in the MX message are optional, a rule in the Bank-to-Customer Cash Management Message Definition Report states that at least one reference must be present.. 61 Standards MX Message Implementation Guide (Dec 2011)

62 SWIFT for Corporates 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 0..1 Statement/ElectronicSequenceNumber 2.2 Number 0..1 Statement/LegalSequenceNumber GroupHeader/MessagePagination 1.4 M 60a Opening Balance 1..1 Statement/Balance 2.23 (option F or M) * (translation default balance type code PRCD ) O 61 Statement Line (see below) 0..n Statement/Entry (see below) 2.76 M 62a Closing Balance 1..1 Statement/Balance 2.23 (option F or M) * (translation default balance type code CLBD ) O 64 Closing Available Balance 0..1 Statement/Balance (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 : 1..1 Entry/CreditDebitIndicator 2.79 Debit/Credit/ 0..1 Entry/ReversalIndicator 2.80 Reversal of Credit(debit entry)/ Reversal of Debit (credit entry)/ Expected Debit/Expected Credit O Funds Code (3rd character of the Not required currency code, if needed) M Amount 1..1 Entry/Amount 2.78 M Transaction Type Identification Code 1..1 Entry/BankTransactionCode 2.91 M** Reference for the Account Owner 0..1** Entry/EntryDetails/Batch/ (when batch or aggregate booking): Message ID and/or PaymentInfoID Entry/TransactionDetails/References (when booking for single transaction : Instruction ID and/or Transaction ID and/or Standards MX Message Implementation Guide (Dec 2011)

63 Comparison MT MX O Account Servicing Institution's Reference EndToEndID and/or MandateID and/or ClearingSystemReference and/or ChequeNumber and/or Proprietary Entry/TransactionDetails/RelatedRemittanceInfor mation/remittanceidentification Entry/TransactionDetails/RemittanceInformation/ Structured/CreditorReferenceInformation/Credito rreference 0..1 Entry/AccountServicerReference 2.84 O Supplementary Details 0..1 Entry/AdditionalEntryInformation and Entry/EntryDetails/TransactionDetails/Additional TransactionInformation * For a further breakdown of the balance component, please refer to the comparison included with the MT 941 Balance Report, section 5.2. ** Reference for Account Owner : even though all references in the MX message are optional, a rule in the Bank-to-Customer Cash Management Message Definition Report states that at least one reference must be present. 63 Standards MX Message Implementation Guide (Dec 2011)

64 SWIFT for Corporates 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 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 Notification/Entry/EntryDetails/TransactionDetails /RelatedRemittanceInformation/RemittanceIdent ification Notification/Entry/EntryDetails/TransactionDetails /RemittanceInformation/Structured/CreditorRefer enceinformation/creditorreference 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 Standards MX Message Implementation Guide (Dec 2011)

65 Comparison MT MX days Notification/ Entry/Amount 2.58 O 52a Ordering Institution 0..1 Notification/Entry/EntryDetails/TransactionDetails (MT 900 has only Ordering /RelatedParties/Debtor Institution, not Ordering Customer, as in MT 910) (in the case where the debit was initiated by the account owner) 0..1 Notification/Entry/EntryDetails/TransactionDetails /RelatedAgents/DebtorAgent (in case where the debit was initiated by the account servicing institution) 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) O 72 Sender to Receiver Information 0..1 Notification/AdditionalNotificationInformation Mandatory elements present in MX camt.054 that are not present in MT GroupHeader/MessageIdentification ** GroupHeader/CreationDateTime ** Notification /Entry/CreditDebitIndicator *** (translation default DBIT ) 1..1 Notification /Entry /Status (translation default BOOK ) 1..1 Notification /Entry /BankTransactionCode (translation default UNKNOWN ) * A rule in the MX message states that at least one reference must be present. ** these differences are due to difference in structure of the MX : MX message can contain multiple notifications *** this difference is due to the fact that the MX message can be used for Debit and/or Credit notifications 65 Standards MX Message Implementation Guide (Dec 2011)

66 SWIFT for Corporates 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 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 Notification/Entry/EntryDetails/TransactionDetails /RelatedRemittanceInformation/RemittanceIdent ification Notification/Entry/EntryDetails/TransactionDetails /RemittanceInformation/Structured/CreditorRefer enceinformation/creditorreference 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 Standards MX Message Implementation Guide (Dec 2011)

67 Comparison MT MX 1..1 Notification/ Entry/Amount 2.58 O 50a Ordering Customer 0..1 Notification//Entry/EntryDetails/TransactionDetail s/relatedparties/debtor DebtorAccount O 52a Ordering Institution 0..1 Notification/Entry/EntryDetails/TransactionDetails /RelatedParties/Debtor O 56a Intermediary 0..1 Notification/Entry/EntryDetails/TransactionDetails /RelatedParties/IntermediaryAgent1 O 72 Sender to Receiver Information 0..1 Notification/EntryDetails/AdditionalTransactionI nformation Mandatory elements present in MX camt.054 that are not present in MT GroupHeader/MessageIdentification ** GroupHeader/CreationDateTime ** Notification /Entry/CreditDebitIndicator *** (translation default CRDT ) 1..1 Notification /Entry /Status (translation default BOOK ) 1..1 Notification /Entry /BankTransactionCode (translation default UNKNOWN ) * A rule in the MX message states that at least one reference must be present. ** these differences are due to difference in structure of the MX : MX message can contain multiple notifications *** this difference is due to the fact that the MX message can be used for Debit and/or Credit notifications 67 Standards MX Message Implementation Guide (Dec 2011)

68 SWIFT for Corporates Legal Notices Copyright SWIFT 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 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. 68 Standards MX Message Implementation Guide (Dec 2011)