Date: 8 January 2009 (Message Versions: pain , pain , pain , pain and pain )

Transcription

1 ISO Customer-to-Bank Message Usage Guide Customer Credit Transfer Initiation, Customer Direct Debit Initiation, and Payment Status Report Version 3.0 Date: 8 January 2009 (Message Versions: pain , pain , pain , pain and pain )

2 The Usage Guide Work Group consisted of: Robert J. Blair Robert Bol Susan K. Colles Pekka Jarvinen Jorma Kostia Pascaline Maire Heike Matzner Joo Kim Ong Leonard D. Schwartz Mark Sutton Deborah Canale Andrew Savva Chantal Van Es JPM Chase Consultant Bank of America Nordea Nordea BNP Deutsche Bank Citi ABN AMRO Bank HSBC Wells Fargo JPM Chase SWIFT This document was also distributed for review by a panel of corporate and vendor experts. ABN AMRO N.V. Equens Rabobank Nederland Accenture Euroclear Royal Bank of Canada ACI Worldwide Federal Reserve Bank of Minneapolis Sampo Bank plc ANZ Banking Group Federal Reserve Bank of New York Samsung (Asia) APACS - the UK Pay. Assoc./London Forbis SAP Arcelor Mittal France Telecom SEB Mercant Banking Australia and New Zealand Banking FundTech Shell Group Limited Banco Popular General Electric SIZ GmbH Bank of America GXS Société Générale Bankenes Standardiseringskontor HSBC Holdings plc South African Payments Strategy Association Barclays Bank plc Ikea Standard Chartered Bank BasWare Intel StoraEnso BBVA Itemfield Stuzza BEA Johnson & Johnson Sungard BNP Paribas JP Morgan Chase Svenska Bankforeningen Bottomline LAN SWIFT BPSL Lenovo (Asia) TDI Cargill LogicaCMG The Clearing House CELCO Merck TIBCO Citigroup Microsoft Dynamic TietoEnator Clear2Pay Microsoft Treasury Total Coles Mizuho Corporate Bank Trema (Wall Street Systems Commerzbank AG NATEXIS Banques Populaires TWIST Credit Suisse / Zurich Nokia UBS AG Danish Bankers Association Nordea Bank ISO Registration Authorty Danone OAGi Voca Ltd Deutsche Bank Opus Capita webmethods DnB NOR Bank Oracle Corp Wells Fargo Bank NA If there are questions regarding this document, please forward them to Leonard Schwartz at leonard.schwartz@rbs.com.

3 TABLE OF CONTENTS 1.0 INTRODUCTION PURPOSE AND USE OF THIS GUIDE INTENDED AUDIENCE MESSAGES COVERED IN THIS GUIDE HOW THIS GUIDE WAS CREATED ISO MESSAGE STANDARDS MESSAGE TRANSPORT RELATED DOCUMENTS AND GUIDES HOW TO READ THE SCENARIO TABLES IN THE GUIDE BUSINESS CONTEXT & MESSAGE EXCHANGE BUSINESS PROCESS OVERVIEW MESSAGE CHOREOGRAPHY Customer Credit Transfer Initiation Customer Direct Debit Initiation MESSAGE PURPOSES CUSTOMER CREDIT TRANSFER INITIATION CUSTOMER DIRECT DEBIT INITIATION CUSTOMER PAYMENT REVERSAL PAYMENT CANCELLATION REQUEST PAYMENT STATUS REPORT BANK-TO-CUSTOMER DEBIT/CREDIT NOTIFICATION BANK-TO-CUSTOMER STATEMENT BANK-TO-CUSTOMER ACCOUNT REPORT MESSAGE STRUCTURE MESSAGE STRUCTURE OVERVIEW CUSTOMER CREDIT TRANSFER INITIATION CUSTOMER DIRECT DEBIT INITIATION CUSTOMER PAYMENT REVERSAL PAYMENT CANCELLATION REQUEST PAYMENT STATUS REPORT MESSAGE PARTIES PARTIES INVOLVED IN THE MESSAGE EXCHANGES ANTI-MONEY LAUNDERING REGULATIONS AND IDENTIFICATION OF PARTIES IDENTIFYING CUSTOMER PARTIES IN THE MESSAGE Overview of Scenarios Customer Party Scenarios Examples IDENTIFYING BANKS ( AGENTS ) IN THE MESSAGE Overview of Scenarios Direct Scenario (File/Message Sent to Debit Bank) Forward of Entire File Mixed Files with Individual Transaction Processing Which Elements to Use in the Message INITIATION WITH IDENTIFICATION OF INTERMEDIARIES Overview of Scenarios Identification of 1 Intermediary Agent Identification of 2 Intermediary Agents Identification of 2 Intermediary Agents and the Account Identification of Creditor Agent49

4 5.5.5 Identification of 3 Intermediary Agents Which Elements to Use in the Message INITIATION TO A THIRD PARTY ACCOUNT HELD AT THE BENEFICIARY (BUILDING SOCIETIES AND BROKERS) U.K. Building Society Scenario Broker Scenario HOW TO IDENTIFY AN AGENT GROUPING PAYMENTS OVERVIEW OF GROUPING USING THE GROUPING INDICATOR & STRUCTURING CREDIT INSTRUCTIONS Message Component 1: Group Header Message Component 2: Payment Information GROUPING SCENARIOS Message Containing a Single Payment Instruction Message Containing Multiple Payment Instructions in a Single Group Message Contains Multiple Payment Instructions and is Mixed Message Contains Multiple Payment Instructions in a Mixed Message with Differing Payment Types Message Contains Multiple Payment Instructions Treated As Single Transactions Which Elements to Use in the Message BATCH BOOKING OVERVIEW OF BATCH BOOKING SETTING THE BATCH BOOKING INDICATOR & REFERENCES Batch Booking Indicator Set to True & Batch Reference Batch Booking Indicator Set to FALSE & Transaction Reference Batch Booking Indicator Is Omitted BATCH BOOKING SCENARIOS Message Containing a Single Payment Instruction batch booking is not present Message Containing Multiple Payment Instructions in a Single Group batch booking is set to true Message Contains Multiple Payment Instructions and is Mixed Batch Booking is set to True Message Contains Multiple Payment Instructions in a Mixed Message with Differing Payment Types Batch Booking is set to False Message Contains Multiple Payment Instructions Treated As Single Transactions with No Batch Booking Indicator Message Contains Multiple Payment Instructions Treated As Single Transactions with Batch Booking Indicator set to True Elements Used in the Message PAYMENT INSTRUMENTS OVERVIEW PAYMENT METHOD PAYMENT TYPE INFORMATION (ELECTRONIC TRANSACTIONS) PAYMENT TYPE INFORMATION (CHEQUE PAYMENTS) WHICH ELEMENTS TO USE IN THE MESSAGE Service Level Approach Clearing Channel Approach Cheque Instructions PAYMENT DATES... 97

5 9.1 REQUESTED EXECUTION DATE POOLING ADJUSTMENT DATE CHEQUE MATURITY DATE REQUESTED COLLECTION DATE DATE OF SIGNATURE (OF THE MANDATE) FOREIGN EXCHANGE SCENARIOS No Foreign Exchange Credit Amount and Currency Known Debit Amount, Debit Currency, Credit Amount and Exchange Rate Unknown Debit Amount, Debit Currency and Credit Currency Known But Credit Amount Unknown Credit Amount, Credit Currency and Exchange Rate Known But Debit Amount Unknown Credit Amount, Credit Currency and Exchange Contract Known Which Elements to Use in the Message REFERENCES REFERENCES RELATED TO THE PAYMENT INSTRUCTIONS Message Level The Payment Information Component Transaction Level Remittance Related References STP AND RECONCILIATION USING THE END-TO-END IDENTIFICATION SCENARIOS Customer Credit Transfer Initiation containing one payment transaction All payment transactions have common debit information Customer Credit Transfer Initiation containing several payment transactions Customer Credit Transfer Initiation containing several payment transactions TAX INFORMATION USE OF THE TAX COMPONENT IN THE MESSAGE SCENARIOS WHICH ELEMENTS TO USE IN THE MESSAGE REGULATORY REPORTING STRUCTURE OF REGULATORY REPORTING IN THE MESSAGE SCENARIOS WHICH ELEMENTS TO USE IN THE MESSAGE REMITTANCE INFORMATION STRUCTURED REMITTANCE WITHIN THE PAYMENT UNSTRUCTURED REMITTANCE WITHIN THE CREDIT TRANSFER OR DIRECT DEBIT RELATED REMITTANCE INFORMATION SCENARIOS DIRECT DEBIT MANDATE INFORMATION OVERVIEW SCENARIOS ADDITIONAL INSTRUCTIONS FOR AGENTS CHARGES INFORMATION...143

6 16.2 ADDITIONAL INSTRUCTIONS FOR THE DEBTOR & CREDITOR AGENTS PURPOSE PAYMENT STATUS REPORT OVERVIEW PAYMENT STATUS VALUES STATUS REASON INFORMATION ALLOWED STATUS COMBINATIONS ON GROUP AND TRANSACTION LEVELS SCENARIOS Positive Status reporting on File Level Negative Status Reporting on File Level Positive Status Reporting on Message/Transaction Level PartiallyAccepted Status Reporting on Message Level Negative Status Reporting on Message Level Negative Status Reporting for a Number of Individual Transactions Elements to Use within the Message ELEMENTS NOT TO BE USED IN THE CUSTOMER-TO-BANK PAYMENT STATUS REPORT NATIONAL AND COMMUNITY SPECIFIC IMPLEMENTATIONS

7 1.0 INTRODUCTION 1.1 Purpose and Use of this Guide This guide explains how to use the ISO Customer Credit Transfer Initiation, Customer Direct Debit Initiation, Customer Payment Reversal, Payment Cancellation Request and Payment Status Report messages in the context of the business processes they address. It provides a comprehensive view of how these messages fit within a customer-to-bank business process and the activities of the involved parties. Also included are detailed explanations and examples of the use of the message components to convey specific information related to these processes and activities. This guide acts as a supplement to the Message Definition Report and the XML schemas, which are published on the ISO website ( The guide provides information regarding the application of the included messages in any relevant general context. Additional documents, published by individual user communities, may be available that discuss the application of this standard in a more specific context. Further discussion on this topic can be found in the National and Community Specific Implementations section later in this guide. When national or community specific documents are available: 1. This guide can be used as a global overview of the standard and its general application to all appropriate payment instruments. 2. The reader is encouraged to refer to those community specific documents as well as this guide to better understand both the general implementation of the message as well as community specific requirements It is also hoped that this guide should serve as the general basis for the more specific community implementation guides that are developed. This guide does contain comment boxes throughout which can be used to record comments and conventions specific to financial institutions and/or standards organization, if desired. 1.2 Intended Audience Both business people and message developers can use this guide. It is intended for corporate end users, banks offering this message to their clients, technology firms seeking to embed support for these messaging standards into their applications, and standard organizations that wish to use the ISO 'payment kernel' as part of the messages they offer. 1.3 Messages Covered in this Guide This guide covers the Customer Credit Transfer Initiation, Customer Direct Debit Initiation, Customer Payment Reversal, Payment Cancellation Request and Payment Status Report messages, which are part of the ISO Universal financial industry message scheme, within the Payments business domain. They are sometimes referred to collectively as the Core Payment Kernel in a corporate to bank context. The end-to-end corporate payment transaction flow can be mapped into three sets of messages, as described in the following paragraphs. The Credit Transfer Initiation and Direct Debit Initiation messages cover the messages exchanged between a buyer and its bank and a seller and its bank to collect, manage and monitor payments. The Customer Payment Reversal and Payment Cancellation Request messages, used to reverse or cancel Credit Transfers and Direct Debits, can also be seen as part of this set. Similar existing standards would

8 include: ANSI Accredited Standards Committee X12 (USA), BACS (UK), CLIEOP03 (Netherlands), EDIFACT, MultiCash, and Zengin (Japan). Inter-bank Payment messages cover the messages exchanged between banks to order the movement of funds resulting from the payment initiation. Similar existing standards are CHIPS (USA), FX-YCS (Japan), FedWire, SWIFT MT103 etc. Cash Reporting messages cater for the exchange of Advices and Statements between an account owner/corporate and an account servicer/bank. Similar existing standards are the SWIFT MT 900, 910, and 940, BAI Balance and Transaction Reporting format, ANSI x Transaction Set and EDIFACT FINSTA. As stated above, this guide addresses the following messages: Customer Credit Transfer Initiation version 2 (<pain xsd>) Customer Direct Debit Initiation version 1 (<pain xsd>) Customer Payment Reversal version 1 (<pain xsd>) Payment Cancellation Request version 1 (<pain >) Payment Status Report version 2 (<pain xsd>). A second guide, covering the Bank-to-Customer Cash Reporting messages, is also under development. All of these ISO messages are intended to be used either as-is or in combination with another standard s message set. For example, the Core Payment Kernel has been embedded in a number of other standards; guidance on how to do so is contained in the Final Report of the IST Harmonization Team (see Related Documents and Guides). An example is also provided in the Appendix. 1.4 How this Guide was Created This guide was created through the combined efforts of the CSTP (Corporate STP Bank Group) and the ISTH (International Standards Team Harmonisation) team, SWIFT, and the SWIFT CAG Work Group. A group of corporate and software vendors provided additional review of the content before the guide s release. The ISO Payments Standards Evaluation Group also provided input and approved its publication. 1.5 ISO Message Standards ISO is part of the International Standards Organization (ISO) under Technical Committee 68 (TC68), which is the Financial Services Technical Committee of ISO. Proposals for development of candidate ISO message standards are submitted through the ISO Registration Management Group (RMG) via a Business Justification. When this Business Justification is approved, the RMG assigns the evaluation of the candidate messages to a Standards Evaluation Group (SEG). Messages contained within this guide have been assigned to the Payments Standards Evaluation Group (Payments SEG), which is in charge of customer (corporate) to bank payments. The Payments SEG represents membership from ISO countries as well as Liaison organizations. Acceptance and maintenance of these messages and core schemas are subject to the approval of the Payments SEG. Complete information on the membership of the ISO SEGs, the ISO Financial Repository, and the message maintenance and registration process can be found on For more information on ISO itself, please see

9 1.6 Message Transport ISO messages are designed to be transport protocol independent. The ISO standard does not provide any message transport conventions of its own (including header or trailer). AS2, AS3, SWIFT, FTP, IFX, and Rosetta Net RNIF are typical examples of often used industry or community specific transport protocols and conventions. All these protocols have defined their own conventions for transportation of messages such as ISO An application header will be necessary if the users of the messages (customer, bank, or others) want to use a general transport protocol, which does not define any industry or community specific conventions. Transport protocols, network services, and related conventions for enveloping/addressing message payload is specific to the network or transport standards in use to convey the message and are beyond the coverage of this document. Users of the messages are free to define message transport in accordance with the standards and practice of the network or community implementing the message. For example, should SWIFT FileAct be the means of transport, FileAct compliant headers would be required. 1.7 Related Documents and Guides The complete catalogue of ISO messages, including the Message Definition Reports and XML schemas, is available on the ISO website: Current and historical versions of the schemas are available free of charge. Other useful documentation available from the ISO website includes: ISO Financial Repository - Data Dictionary. Introduction to ISO Universal Financial Industry message scheme. An introductory Powerpoint on the ISO standards family. Additional documentation related to the messages is available from the standards groups (the members of ISTH including IFX, OAGi, SWIFT, and TWIST) which partnered to develop the Core Payment Kernel. This includes: IFX - (reference release 1,6 and up), OAGi - SWIFT SWIFTStandards Handbook for Payment Initiation MX Release 2007 available through standards@swift.com. SWIFTStandards MX General Information volume. Latest version can be found at swiftcommunity.net also contains a standards forum and information about use of ISO standards through SWIFT. TWIST - Final Report of the IST Harmonisation Team. Can be found at and Useful discussions of XML are available from the following sources:

10 An in-depth knowledge of XML can be found at An in-depth knowledge of XML Schema can be found at and Information on XML standards and allowed characters can be found at: How to Read the Scenario Tables in the Guide Various tables are utilized to provide a visual representation of the message content and scenario data content. The following color coding has been used in these representations: Identifies the message type Primary level in the message Secondary level in the message Component in the message Component or Tag that would not be used in the described scenario or Indicates an XOR existence of tag usage + Indicates a component containing multiple tags or components

11 2.0 BUSINESS CONTEXT & MESSAGE EXCHANGE 2.1 Business Process Overview The Customer Credit Transfer Initiation and Customer Direct Debit Initiation messages described in this document can be used for initiating either multiple payment orders or single transfers. Examples of multiple payment orders generated together are businesses generating many commercial payments from their ERP/Accounts Payable system, paying staff expense reimbursements, or making salary payments. Other examples are public organisations that are paying private individuals or other public or commercial organisations. Examples of single payment orders include individual transactions generated from a treasury workstation. Throughout this guide, the terms payment and payment order may be used to collectively refer to both Customer Credit Transfer Initiation and Customer Direct Debit Initiation messages, when the discussion does not require making a distinction between them. Both Customer Credit Tansfer Initiation and Customer Direct Debit Initiation messages may represent payment orders which are domestic, cross-border and/or cross currency. They may instruct the bank to transfer an amount from one account to another or can result in a paper-based payment method (any kind of cheque or draft) created by the ordered bank. Payment orders can be submitted to the bank for immediate execution or execution on a specific date, where the bank is requested to warehouse the payment order until this date. The message also supports dates for drafts, where the draft is only payable from specified dates. The References described in this guide provide for unique identification of a payment order at each level of the message. Status messages should reference the identification at the proper level when reporting on reception (batch), cancellation, rejection or progress. Customer Credit Transfer Initiation messages can be generated by the Debtor to its account servicing bank (further referred to as the ordered bank ), or more complex scenario s may be implemented, involving shared service centres, payment factories, service bureaus, gateway/concentrating banks, payment-on-behalf, and payment to a Creditor who is not the final beneficiary. The structure of the Customer Credit Transfer Initiation message allows grouping of payments with common characteristics including: payer (called a Debtor in the message), debit account, requested execution date, and payment method. The group will specify the common elements of these payments with the specifics of every individual payment repeated an unlimited number of times. A separate indicator can specify if the bank has to report on the bank statement the execution of the group as a whole or report the execution of every individual payment order. A direct debit is a collections instrument. It is originated by a creditor to collect funds from a debtor s account. The Customer Direct Debit Initiation message described in this document can be used for initiating either multiple direct debit orders or single direct debits. Usually direct debits are issued by commercial, governmental or non profit entities in a single currency and as a batch. Examples of multiple direct debit orders generated together are businesses collecting consumer payments such as energy, telephone or insurance premiums. Single direct debits can also be issued. These can be, for example, initiated as part of an on line purchase scheme and for other purposes. Customer Direct Debit Initiation messages are generated by the Creditor to its account servicing bank (further referred to as the creditor bank ), or more complex scenarios may be implemented, involving shared service centres, payment factories, service bureaus or gateway/concentrating banks. Direct debit

12 orders can be submitted to the bank for immediate execution or execution on a specific date, where the bank is requested to warehouse the direct debit until this date. The structure of the Customer Direct Debit Initiation message allows grouping of credits with common characteristics including: payee (called a Creditor in the message), credit account, requested execution date, and payment method. The group will specify the common elements of these direct debit instructions with the specifics of every individual debit repeated an unlimited number of times. A separate indicator can specify if the bank has to report on the bank statement the execution of the group as a whole or report the execution of every individual direct debit order. Usually direct debits are issued in a single currency as a batch. They instruct the receiving bank to debit an individual account and often, but not always, require a debit mandate to be in place. The Customer Direct Debit Initiation message supports delivery of original as well as changed mandate information for systems and schemes in which that is required. The mandate is the authorisation/expression of consent given by the Debtor, allowing a specified Creditor to originate Direct Debit instructions to debit a specified Debtor account in accordance with the relevant Direct Debit Scheme Rules and, if applicable, the mandate details. The Creditor invites the Debtor to submit a Mandate. The Debtor provides its banking information on the Mandate (e.g. - name and account number, financial institution, bank identifier and account number) and signs it (manually or via an electronic signature). The mandate represents the Debtor agreement: to authorise the Creditor to issue Direct Debit instruction(s) to the Debtor account to instruct the Debtor Agent to act upon the Creditor Direct Debit instruction The mandate is not required in every country or for every direct debit scheme. Remittance details, in payments, for closing accounts receivable positions (or otherwise applying funds) by the beneficiary can be invoice details or any reference provided by the beneficiary. Remittance details for the debtor, in a direct debit, can also be provided to allow them to identify the source and purpose of the debit to their account. These details can be: Embedded as text formatted by the originator of the transaction Structured in relevant data elements with the inclusion of details agreed by the ordered bank Sent as a separate remittance advice, where the payment order or direct debit refers to the unique identification of this remittance advice. Upon receipt of the remittance advice and the bank-to-customer advice/transfer, the unique reference enables the beneficiary of a payment or recipient of the direct debit to re-associate the remittance information with the transaction. This separate remittance advice can be generated and sent by the payer, the ordered bank, an independent service provider, or the beneficiary s bank. Parties down the chain must find all relevant data in the payment order to generate this remittance advice or receive the relevant details separately. Most often the source and purpose of the debit will be include with the instruction transmitted to the debtor s bank. A Payment Cancellation Request message is used to request cancellation of a Customer Credit Transfer or a Customer Direct Debit.

13 A Customer Payment Reversal message is specific to the direct debit process and is used to reverse a Customer Direct Debit that has been previously executed and settled. The reversal can be initiated by either the creditor or the debtor. Banks may at their discretion, and by arrangement with their customers, offer certain services which are triggered by optional data elements in the message. Customer to bank service arrangements involving such elements should be established by the two parties at the time of service implementation. These arrangements may, for example, include direct debit mandate information where a system require its transmsission each time a direct debit is initiated. Appearance of optional fields in the standard is not a guarantee that they will be supported by all parties, in all contexts. The message capabilities have been extended by increasing the maximum size of data elements. Banks may have to restrict the capacity of certain fields, as their internal processing systems are not yet adapted to cope with extended sizes. Examples of these increased capabilities are name and address details and identifications. The specifications of the bank will define actual limitations and indicate whether excessive data will be truncated or will be the reason for rejection of the message, the group, or the batch. These details should be exchanged by counterparties during the implementation process. 2.2 Message Choreography Customer Credit Transfer Initiation The complete end-to-end message exchange for a Customer Credit Transfer Initiation consists of the following (the numbers in parentheses are for reference to the corresponding diagrams) : Payment initiation through the Customer Credit Transfer Initiation (1) Reporting of payment transaction status through the Payment Status Report (2) Possible provision to the initiating party of a bank-to-customer Debit Notification (3) Possible delivery to the beneficiary of the payment of a bank-to-customer Credit Notification (5) Bank-to-customer Account Report or Statement (6) (Optionally) Cancellation request through the Payment Cancellation Request message before settlement (C1) -or- Cancellation request through the Payment Cancellation Request message after settlement (C2) In case of cancellation before settlement the message exchange remains the same as above for the first three steps, followed by: Cancellation request through the Payment Cancellation Request message (C1) Reporting of payment transaction status through the Payment Status Report (4) In case of cancellation after settlement the message exchange remains the same as above for the first five steps, followed by: Cancellation request through the Payment Cancellation Request message (C2) Reporting of payment transaction status through the Payment Status Report (7) Possible delivery to the initiating party (of the cancellation request) of a bank-to-customer Credit Notification (8) Possible delivery to the beneficiary of the payment of a bank-to-customer Debit Notification (10) Bank-to-customer Account Report or Statement (11)

14 Customer Credit Transfer Initiation without Cancellation Request: Customer Credit Transfer Initiation with Cancellation Request before settlement:

15 Customer Credit Transfer Initiation with Cancellation Request after settlement: Customer Direct Debit Initiation The complete end-to-end message exchange for a Customer Direct Debit Initiation consists of the following (the numbers in parentheses are for reference to the corresponding diagram): Direct Debit Initiation through the Customer Direct Debit Initiation message (1) Reporting of direct debit transaction status through the Payment Status Report message (2) Possible provision to the initiating party of a bank-to-customer Credit Notification (3) Possible delivery to the Debtor of the direct debit of a bank-to-customer Debit Notification (5) Bank-to-customer Account Report or Statement (6) Possible delivery to the Debtor of the return of the funds via a bank-to-customer Customer Payment Reversal message (7) Possible delivery of the Bank-to-customer Account Report or Statement (6) to reflect the reversal (6) (Optionally) Cancellation request through the Payment Cancellation Request message before settlement (C1). Direct Debit cancellation may not occur after settlement

16 Customer Direct Debit Initiation without Payment Cancellation Request: Customer Direct Debit Initiation with Payment Cancellation Request before settlement:

17 Additionally, remittance advice, i.e. information as to the business purpose of the payment, may be sent by the initiating party (i.e. buyer with credit transfer, seller with direct debit) to the beneficiary (i.e. seller with credit transfer, buyer with direct debit) in a number of ways. Multiple models for communication of remittance are supported by the standard. The particular technique chosen will be influenced by the preferences of the buyer and seller, the abilities of the banks and payment systems to convey remittance information, and other factors. Models for communication of remittance information include: Sent directly between the buyer and seller (conveyed separately from the payment) Sent with the payment using a variety of other models: - From each party through their financial institution to the other party - Through a centralized information service (i.e. delivered through central platform/website). Note: The first agent in the chain, i.e. the Debtor Agent (credit transfer), the Creditor Agent (direct debit) could send an advice to the seller (credit transfer) or buyer (direct debit) to inform him that the payment is in progress, a so-called pre-advise scenario. However, the Customer Credit Transfer Initiation and Customer Direct Debit Initiation messages should not be used to do this. Instead, a dedicated pre-advice message should be used to accomplish this.

18 3.0 MESSAGE PURPOSES 3.1 Customer Credit Transfer Initiation This is message (1) in the Customer Credit Transfer Initiation Message Choreography diagrams, and defined as schema <pain >. 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. The Customer Credit Transfer Initiation message can contain one or more customer credit transfer instructions. It is used to exchange: One or more instances of a credit transfer initiation Payment transactions that result in book transfers at the Debtor agent or payments to another financial institution Payment transactions that result in an electronic cash transfer to the Creditor Account or in the emission of a cheque. The message can be used in a direct or a relay (also referred to as indirect, not on us ) scenario: In a direct scenario, the message is sent directly to the Debtor agent. The Debtor agent is the account servicer of the Debtor. In a relay scenario, the message is sent to a forwarding agent. The forwarding agent acts as a concentrating financial institution. It will forward the Customer Credit Transfer Initiation message to the Debtor agent. The message can also be used by an initiating party that has authority to send the message on behalf of the Debtor. This caters, for example, for the scenario of a payments factory initiating all payments on behalf of a large corporate. The Customer Credit Transfer Initiation message can be used in both domestic and cross-border scenarios. The message has the following main characteristics: Batch or single entry indication: The Initiating Party can indicate whether all transactions present in the message should be booked as one entry or as individual entries on the Debtor's account. Refer to the Batch Booking section for further details. References and Remittance Information: The standard features an end-to-end id field that can be used to reference a unique identification associated to remittance information that was exchanged directly between buyer and seller. The standard also features a comprehensive set of references, which allows reconciliation between the initiating party and its bank, between banks and between Debtor and Creditor. Refer to the References section and Remittance Information section for further details. Financial Institution Specific Comments/Implementation Conventions:

19 3.2 Customer Direct Debit Initiation This is message (1) in the Direct Debit Initiation Message Choreography diagrams and defined as schema <pain >. 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 on or various debtor s account(s) for a creditor. The Customer Direct Debit Initiation message can contain one or more direct debit instructions. It is used to exchange: One or more instances of a direct debit initiation Direct debit instructions that result in book transfers at the Creditor Agent or payments to another financial institution The Customer Direct Debit Initiation message can be used in a direct or a relay (also referred to as indirect, not on us ) scenario: In a direct scenario, the message is sent directly to the creditor agent. The creditor agent is the account servicer of the Creditor. In a relay scenario, the message is sent to a forwarding agent. The forwarding agent acts as a concentrating financial institution. It will forward the Customer Direct Debit Initiation message to the creditor agent. The message can also be used by an initiating party that has authority to send the message on behalf of the Creditor. This caters, for example, for the scenario of a payments factory initiating all direct debits on behalf of a large corporate. The Customer Direct Debit Initiation message can be used in both domestic and cross-border scenarios. The Customer Direct Debit Initiation may or may not contain mandate related information, i.e. extracts from a mandate, such as Mandate Identification or Date of Signature. A mandate is the authorization and expression of consent given by the Debtor to the Creditor to allow such Creditor to initiate Collections for debiting the specified Debtor s account and to allow the Debtor Bank to comply with such instructions. The Customer Direct Debit Initiation message must not be considered as a mandate in itself. The message has the following main characteristics: Batch or single entry indication: The Initiating Party can indicate whether all direct debit transactions present in the message should be booked as one entry or as individual entries on the Creditor's account. Refer to the Batch Booking section for further details. References and Remittance Information: The standard features an end-to-end id field that can be used to reference a unique identification associated to remittance information that was exchanged directly between buyer and seller. The standard also features a comprehensive set of references, which allows reconciliation between the initiating party and its bank, between banks and between Debtor and Creditor. Refer to the References section and Remittance Information section for further details. Financial Institution Specific Comments/Implementation Conventions:

20 3.3 Customer Payment Reversal This is message (7) in the Direct Debit Initiation Message Choreography diagrams and defined as schema <pain >. The Customer Payment Reversal message is sent by the initiating party to the forwarding agent or the Creditor agent. It is used to reverse a direct debit that has been previously executed and settled. The result is a credit to the debtor account. A Customer Payment Reversal message may not be used to reverse a credit transfer. The Customer Payment Reversal message must refer to the original Customer Direct Debit Initiation message by means of references only or by means of references and a set of elements from the original instruction (both on the transaction itself or mandate related information). The Customer Payment Reversal message can contain a reversal on one or more direct debit instructions depending on whether the original instruction contained one or more direct debit instructions. The Customer Payment Reversal message can be used in a direct or a relay (also referred to as indirect, not on us ) scenario: In a direct scenario, the message is sent directly to the creditor agent. The creditor agent is the account servicer of the Creditor. In a relay scenario, the message is sent to a forwarding agent. The forwarding agent acts as a concentrating financial institution. It will forward the Customer Payment Reversal message to the creditor agent. The message can also be used by an initiating party that has authority to send the message on behalf of the Creditor. This caters, for example, for the scenario of a payments factory initiating all direct debits on behalf of a large corporate. The Customer Payment Reversal message can be used in both domestic and cross-border scenarios. Financial Institution Specific Comments/Implementation Conventions:

21 3.4 Payment Cancellation Request This is message (C2) in the Customer Credit Transfer Initiation and (C2) in the Customer Direct Debit Initiation Message Choreography diagrams and defined as schema <pain >. The Payment Cancellation Request is sent by the initiating party to the forwarding agent or the originator s bank (Credit Agent or Debit Agent depending on whether the desired payment to cancel is a Credit Transfer or Direct Debit) prior to the settlement of a transaction. Transaction cancellation is dependent upon the specific capabilities of the originator bank s capabilities and cannot be accomplished once a transaction has been sent to the clearing system. The Payment Cancellation Request message can be used to request the cancellation of single instructions or multiple instructions, from one or multiple files. The Payment Cancellation Request message refers to the original instruction(s) by means of references only or by means of references and a set of elements from the original instruction. The message can also be used by an initiating party that has authority to send the message on behalf of the Creditor. This caters, for example, for the scenario of a payments factory initiating all direct debits on behalf of a large corporate. The Customer Payment Reversal message can be used in both domestic and cross-border scenarios. Financial Institution Specific Comments/Implementation Conventions: 3.5 Payment Status Report This is message (2) in the Message Choreography diagrams and defined as schema <pain >. (Deb-Now that we have multiple diagrams the numbers don t line up so we can t cross-reference them here. Do we really need to? The titles match up, that should make it clear enough.) The Payment Status Report message is sent by the financial institution executing the payment back to the initiating party. It is used to inform this party about the status of one or more payment instructions. Its usage will always be governed by a bilateral agreement between the agent and the non-financial institution customer. The Payment Status Report message can be used to provide information about the status (i.e. rejection, acceptance) of a single Customer Credit Transfer Initiation or Customer Direct Debit Initiation message. It may also reflect the status of a transaction as related to subsequent actions or instructions, such as cancelling the payment through the use of a Payment Cancellation Request. Status can be reported at the Group level, or to individual transactions. Certain Status Codes are only applicable at the Group level, for example Partially Accepted and Received. Other Status Codes apply to both the Group and the Transaction level such as Pending, Rejected, and a set of codes that indicate various degrees of Acceptance. The Payment Status Report message refers to the original instruction(s) by means of references only or by means of references and a set of elements from the original instruction.

22 The Payment Status Report message can be used in domestic and cross-border scenarios. In case of a relay (also known as indirect, not on us ) scenario, the agent executing the payment may send the status information to the forwarding (i.e. concentrating) agent. Financial Institution Specific Comments/Implementation Conventions: 3.6 Bank-To-Customer Debit/Credit Notification These are messages (3) and (5) in the Message Choreography diagram and defined as schema <camt >. Note: Bank-to-Customer Debit/Credit Notification messages are part of the end-to-end message exchange and as such, are included in this guide, but the detailed description and usage of these messages will be addressed in another guide. The Bank-to-Customer Debit/Credit Notification message is sent by the account servicer to an account owner or to a party authorised by the account owner to receive the message. It can be used to inform the account owner, or authorised party, of single or multiple debit and/or credit entries reported to the account. The standard can be used either as debit advice to the initiating party or as credit advice to the beneficiary of the funds. The Bank-to-Customer Debit/Credit Notification message can contain reports for more than one account. It provides Information for cash management and/or reconciliation. It can be used to: report pending and booked items notify one or more debit entries notify one or more credit entries notify a combination of debit and credit entries Payment remittance information can include underlying details of transactions that have been included in the entry, such as references, identification of the creditor, the debtor and their respective accounts, amounts transferred and instructed, etc. The message provides detailed breakdown of different amounts (such as charges, interest and tax) included in the entry amount, as well as information on a currency exchange operation that may have taken place. Financial Institution Specific Comments/Implementation Conventions:

23 3.7 Bank-To-Customer Statement This is messages (6) and (9) in the Message Choreography diagram and defined as schema <camt >. Note: Bank-to-Customer Statement message is part of the end-to-end message exchange and as such, are included in this guide, but the detailed description and usage of this message will be addressed in another guide. The Bank-to-Customer Statement message is sent by the account servicer to an account owner or to a party authorised by the account owner to receive the message. It is 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. The Bank-to-Customer Statement message can contain reports for more than one account. It provides Information for cash management and/or reconciliation. It contains Information on booked entries only, and can include underlying details of transactions that have been included in the entry, such as references, identification of the Creditor, the Debtor and their respective accounts, amounts transferred and instructed, etc. The message is exchanged as defined between the account servicer and the account owner. It provides information on items that have been booked to the account (and therefore are binding ) and also balance information. Depending on services agreed between banks and their customers, binding statements can be generated and exchanged intraday. Depending on legal requirements in local jurisdictions, end-of-day statements may need to be mandatory generated and exchanged. It is possible that the receiver of the message is not the account owner, but a party entitled through arrangement with the account owner to receive the account information (also known as recipient). Financial Institution Specific Comments/Implementation Conventions: 3.8 Bank-To-Customer Account Report This is message (6) in the Message Choreography diagram and defined as schema <camt >. Note: The Bank-to-Customer Account Report message is part of the end-to-end message exchange and as such, is included in this guide, but the detailed description and usage of this message will be addressed in another guide. The Bank-to-Customer Account Report message is sent by the account servicer to an account owner or to a party authorised by the account owner to receive the message. It 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. The Bank-to-Customer Account Report message can contain reports for more than one account. provides information for cash management and/or reconciliation. It can be used to: It

24 report pending and booked items; provide balance information It can include underlying details of transactions that have been included in the entry. It is possible that the receiver of the message is not the account owner, but a party entitled by the account owner to receive the account information (also known as recipient). For a statement that is required due to local legal stipulations, the Bank-to-Customer Account Statement message should be used.

25 4.0 MESSAGE STRUCTURE 4.1 Message Structure Overview The following points apply in general to the message structures discussed below: 1. The term message is used to refer to one (schema) instance of the Customer Credit Transfer Initiation or Customer Direct Debit Initiation (i.e. the combination of building block A-Group Header + building block B-Payment Information + building block C-Credit Transfer Transaction Information or building block C-Direct Debit Transaction Information). 2. The term file, when used, refers to a single physical entity that is exchanged between the parties, which may contain one or more messages as defined above. Some message transport mechanisms are inherently file-based, such as FTP and SWIFT FileAct. The Message Parties section discusses some scenarios that specifically involve file-based transfer and processing. 4.2 Customer Credit Transfer Initiation The diagram below shows the main building blocks of the Customer Credit Transfer Initiation message, which is defined as schema <pain >: Legend: = mandatory, present exactly once 1...n = mandatory, and repetitive. n = unlimited number = optional 0...n = optional, and repetitive. n = unlimited number. Notes on this message structure: 1. A single Group Header (Block A) may have multiple (1 n) Payment Information Components (Block B) within it. Each Payment Information Component may have multiple (1 n) transactions (the Credit Transfer Transaction Information component-block C) within it. 2. The term Payment Instruction is used to refer to the combination of building block B-Payment Information (i.e. the debit side of a payment instruction) + building block C-Credit Transfer Transaction Information (i.e. the credit side of a payment instruction). One Customer Credit Transfer Initiation message can contain one or more Payment Instructions.

26 The table below contains, per building block, the first level of message items: Message item Multiplicity A. Group Header [1...1] MessageIdentification [1...1] CreationDateTime [1...1] Authorisation [0..2] BatchBooking [0...1] NumberOfTransactions [1...1] ControlSum [0...1] Grouping [1...1] + InitiatingParty [1...1] + ForwardingAgent [0...1] B. Payment Information [1...n] PaymentInformationIdentification [0...1] Payment Method [1...1] + PaymentTypeInformation [0...1] RequestedExecutionDate [1...1] PoolingAdjustmentDate [0...1] + Debtor [1...1] + DebtorAccount [1...1] + DebtorAgent [1...1] + DebtorAgentAccount [0...1] + UltimateDebtor [0...1] ChargeBearer [0...1] + ChargesAccount [0...1] + ChargesAccountAgent [0...1] C. CreditTransferTransactionInformation [1...n] + PaymentIdentification [1...1] + PaymentTypeInformation [0...1] + Amount [1...1] + ExchangeRateInformation [0...1] ChargeBearer [0...1] + ChequeInstruction [0...1] + UltimateDebtor [0...1] + IntermediaryAgent1 [0...1] + IntermediaryAgent1Account [0...1] + IntermediaryAgent2 [0...1] + IntermediaryAgent2Account [0...1] + Intermediary Agent3 [0...1] + Intermediary Agent3Account [0...1] + CreditorAgent [0...1] + CreditorAgentAccount [0...1] + Creditor [0...1] + CreditorAccount [0...1] + UltimateCreditor [0...1] + InstructionForCreditorAgent [0...n] + InstructionForDebtorAgent [0...1] + Purpose [0...1] + RegulatoryReporting [0...10] + Tax [0..1] + RelatedRemittance Information [0...10] + RemittanceInformation [0...1] See Batch Booking section See Grouping Payments section See Payment Instruments section See Message Parties section See Foreign Exchange section See Regulatory Reporting section See Tax Information section See Remittance Information section The full message structure and content is available in the Appendix of this document (and in the ISO Message Definition Report available through

27 4.3 Customer Direct Debit Initiation The diagram below shows the main building blocks of Customer Direct Debit Initiation message, which is defined as schema <pain >: Legend: = mandatory, present exactly once 1...n = mandatory, and repetitive. n = unlimited number = optional 0...n = optional, and repetitive. n = unlimited number. Notes on this message structure: 1. A single Group Header (Block A) may have multiple (1 n) Payment Information Components (Block B) within it. Each Payment Information Component may have multiple (1 n) transactions (the Direct Debit Transaction Information component-block C) within it. 2. The term Direct Debit Instruction is used to refer to the combination of building block B-Payment Information (i.e. the credit side of a payment instruction) + building block C-Direct Debit Transaction Information (i.e. the debit side of a payment instruction). One Customer Direct Debit Initiation message can contain one or more Direct Debit Instructions.

28 The table below contains, per building block, the first level of message items: Message item Multiplicity A. Group Header [1...1] MessageIdentification [1...1] CreationDateTime [1...1] Authorisation [0..2] BatchBooking [0...1] NumberOfTransactions [1...1] ControlSum [0...1] Grouping [1...1] + InitiatingParty [1...1] + ForwardingAgent [0...1] B. Payment Information [1...n] PaymentInformationIdentification [0...1] Payment Method [1...1] + PaymentTypeInformation [0...1] RequestedCollectionDate [1...1] PoolingAdjustmentDate [0...1] + Creditor [1...1] + CreditorAccount [1...1] + CreditorAgent [1...1] + CreditorAgentAccount [0...1] + UltimateCreditor [0...1] ChargeBearer [0...1] + ChargesAccount [0...1] + ChargesAccountAgent [0...1] C. Direct Debit Transaction Information [1...n] + PaymentIdentification [1...1] + PaymentTypeInformation [0...1] InstructedAmount [1...1] ChargeBearer [0...1] + DirectDebitInstruction [0...1] + UltimateCreditor [0...1] + DebtorAgent [1...1] + DebtorAgentAccount [0...1] + Debtor [1...1] + DebtorAccount [1...1] + UltimateDebtor [0...1] + InstructionForCreditorAgent [0...1] + Purpose [0...1] + RegulatoryReporting [0...10] + Tax [0..1] + RelatedRemittance Information [0...10] + RemittanceInformation [0...1] See Batch Booking section See Grouping Payments section See Payment Instruments section See Message Parties section See Foreign Exchange section See Regulatory Reporting section See Tax Information section See Remittance Information section The full message structure and content is available in the Appendix of this document (and in the ISO Message Definition Report available through

29 4.4 Customer Payment Reversal The diagram below shows the main building blocks of the Customer Payment Reversal message, which is defined as schema <pain >: A. GROUP HEADER (1..1) B. ORIGINAL GROUP INFORMATION (1..1) A. This building block is mandatory and present once. It contains general elements that apply to the whole message. B. This building block is mandatory and present once. It contains elements, related to the original Customer Direct Debit Initiation message C. TRANSACTION INFORMATION (0..n) C. This building block is optional and repetitive. It contains elements referencing the original instruction and elements relating to the customer payment reversal. Legend: = mandatory, present exactly once 1...n = mandatory, and repetitive. n = unlimited number = optional 0...n = optional, and repetitive. n = unlimited number. Notes on this message structure: 1. A single Group Header (Block A) has only one (1 1) Original Group Information Component (Block B) within it and may have multiple (0 n) transactions (the Credit Transfer Transaction Information component-block C) within it. 2. The term Reversal Instruction is used to refer to the combination of building block B-Original Group Information (i.e. original direct debit initiation information) + building block C-Transaction Information (i.e. references on original instruction and payment reversal itself) or a block B solely. One Customer Payment Reversal message may contain one or more Reversal Instructions.

30 The table below contains, per building block, the first level of message items: Message item Multiplicity A. Group Header [1...1] MessageIdentification [1...1] CreationDateTime [1...1] Authorisation [0..2] BatchBooking [0...1] NumberOfTransactions [1...1] ControlSum [0...1] GroupReversal [0...1] + InitiatingParty [1...1] + ForwardingAgent [0...1] + DebtorAgent [0...1] + CreditorAgent [0...1] B. OriginalGroupInformation [1...1] OriginalMessageIdentification [1...1] OriginalMessageNameIdentification [1...1] OriginalCreationDateTime [0...1] + ReversalReasonInformation [0...n] C. TransactionInformation [0...n] ReversalIdentification [0...1] OriginalPaymentInformationIdentification [0...1] OriginalEndToEndIdentification [0...1] OriginalInstructedAmount [0...1] ReversedInstructedAmount [0...1] ChargeBearer [0...1] + ReversalReasonInformation [0...n] + OriginalTransactionReference [0...1] See Batch Booking section The full message structure and content is available in the Appendix of this document (and in the ISO Message Definition Report available through Payment Cancellation Request The diagram below shows the main building blocks of the Payment Cancellation Request message, which is defined as schema <pain >: A. GROUP HEADER (1..1) B. ORIGINAL GROUP INFORMATION (1..1) A. This building block is mandatory and present once. It contains general elements that apply to the whole message. B. This building block is mandatory and present once. It contains elements, related to the original message C. TRANSACTION INFORMATION (0..n) C. This building block is optional and repetitive. It contains elements referencing the original instruction and elements relating to the payment cancellation request. Legend: = mandatory, present exactly once 1...n = mandatory, and repetitive. n = unlimited number = optional 0...n = optional, and repetitive. n = unlimited number.

31 Notes on this message structure: 1. A single Group Header (Block A) has only one (1 1) Original Group Information Component (Block B) within it and may have multiple (0 n) transactions (the Transaction Information componentblock C) within it. 2. The term Cancellation Instruction is used to refer to the combination of building block B-Original Group Information (i.e. original direct debit initiation information) + building block C-Transaction Information (i.e. references on original instruction and payment cancellation itself) or a block B solely. One Payment Cancellation Request message may contain one or more Cancellation Instructions. The table below contains, per building block, the first level of message items: Message item Multiplicity A. Group Header [1...1] MessageIdentification [1...1] CreationDateTime [1...1] NumberOfTransactions [1...1] ControlSum [0...1] Group Cancellation [0...1] + InitiatingParty [1...1] + ForwardingAgent [0...1] + DebtorAgent [0...1] + CreditorAgent [0...1] + InstructingAgent [0...1] + InstructiedAgent [0...1] B. Original Group Information [1...n] OriginalMessageIdentification [1...1] OriginalMessageNameIdentification [1...1] OriginalCreationDateTime [0...1] + CancellationReasonInformation [0 n] C. TransactionInformation [0...n] CancellationIdentification [0...1] OriginalPaymentInformationIdentification [0...1] OriginalInstructionIdentification [0...1] OriginalEndToEndIdentification [0...1] OriginalTransactionidentification [0...1] OriginalInterbankSettlementAmount [0...1] OriginalInstructedAmount [0...1] + InstructingAgent [0...1] + InstructedAgent [0...1] + CancellationReasonInformation [0 n] + OriginalTransactionReference [0 1] The full message structure and content is available in the Appendix of this document (and in the ISO Message Definition Report available through

32 4.6 Payment Status Report The diagram below shows the main building blocks of the Payment Status Report message, which is defined as schema <pain >: Legend: = mandatory, present exactly once 1...n = mandatory, and repetitive. n = unlimited number = optional 0...n = optional, and repetitive. n = unlimited number. Notes on this message structure: 1. A single Group Header may have a single Original Group Information and Status Component within it. The Original Group Information and Status Component may have zero, one, or multiple (0 n) Transaction Information and Status Components within it.

33 The table below contains, per building block, the first level of message items: Message item Multiplicity A. Group Header [1...1] MessageIdentification [1...1] CreationDateTime [1...1] + InitiatingParty [0...1] + ForwardingAgent [0...1] + DebtorAgent [0...1] + CreditorAgent [0...1] + InstructingAgent [0...1] + InstructedAgent [0...1] B. OriginalGroupInformationAndStatus [1...1] {or OriginalMessageIdentification [1...1] Or} NetworkFileName [1...1] OriginalMessageNameIdentification [1...1] OriginalCreationDateTime [0...1] FileOriginator [0...1] OriginalNumberOfTransactions [0...1] OriginalControlSum [0...1] GroupStatus [0...1] + StatusReasonInformation [0...n] + NumberOfTransactionsPerStatus [0...n] C. TransactionInformationAndStatus [0...n] StatusIdentification [0...1] + OriginalPaymentInformationIdentification [0...1] + OriginalInstructionIdentification [0...1] + OriginalEndToEndIdentification [0...1] OriginalTransactionIdentification [0...1] + TransactionStatus [0...1] + StatusReasonInformation [0...n] + ChargesInformation [0...n] + AcceptanceDateTime [0...1] + InstructingAgent [0...1] + InstructedAgent [0...1] + OriginalTransactionReference [0...1] See Payment Status Report section The full message structure and content is available in the Appendix of this document (and in the ISO Message Definition Report available through

34 5.0 MESSAGE PARTIES 5.1 Parties Involved in the Message Exchanges Several parties can be involved in the exchange of these messages. For the Customer Credit Transfer Initiation these parties include: For the Customer Direct Debit Initiation these parties include: Party Synonyms Description Ultimate ISO Definition: Ultimate party that owes an amount of Debtor money to the (ultimate) Creditor. Debtor Initiating Party Buyer, Originator, Ordering Party Physical originators can be: Debtor, originating party, shared service centres and payment factories Usage: The Ultimate Debtor is the party that owes the cash to the (Ultimate) Creditor, i.e. as a result of receipt of goods or services, gifts, charity payments and is the party which orders the payment. It may be equal to the account owner whose account will be debited by the Debtor Agent to make the payment (i.e. the Debtor), but it can also be different from the Debtor. This is usually the buyer. It should only be specified in case it is different from the Debtor. ISO Definition: Party that owes an amount of money to the (ultimate) Creditor. Usage: Party that owns the debit account that will be used to make the customer payment. It may be equal to or different from the ultimate Debtor. The Debtor must always be present. ISO Definition: Party initiating the payment. This can either be the Debtor, or the party that initiates the payment on behalf of the Debtor. Usage: Is the party initiating the payment to the