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)