market practice documents_payment working group_payment market practice document - november 2012...

Payments Market Practice Document

ISITC Settlements Working Group

Publication Date: October, 2012 Author(s): ISITC Settlements Working Group

DISCLAIMER This market practice document has been developed by the International Securities Association for Institutional Trade Communication (ISITC) as a statement of professional practices recommended by ISITC. Institutions providing the information recommended in this document will benefit from the efficiencies inherent in a more automated transaction process. Although all institutions are encouraged to act consistently with this document, none are required to do so, and a failure to do so is not, in and of itself, evidence of negligent or inappropriate conduct.

Document History

Change Date Description of Change Author Dec 2008 Initial Release of Payments Market Practice Document Co-chairs Sept 2009 Updated with Generic payment details Co-chairs June 2010 Updated with MT 202 and 210 message details, and appendices

for Cash Collateral and Securities Lending. Co-chairs

December 2010

-Removal of business data elements (Payment Method) as this is a messaging requirement not a business element requirement -Update to Actors/Roles Diagram to highlight different terminology by related security product (Generic/Lending/Bank Loan) -Update to Generic Appendix Section 4.1 to include CASH cash purpose code usage -Update to Generic Appendix 1 Section 4.4 (MT210 field recommendations) fields 52a usage usage and field 56a usage. -Update to Message Sequence diagrams for generic appendix -Update Message Sequence diagrams in Lending Appendix with pacs.009 in place of pain.001. Need to review all messages noted in message diagrams within Lending appendix. Need to update field recommendations and samples with pacs.009 instead of PAIN001 and need to add camt.057 field recommendations and samples. -Addition of Derivatives Appendix with pacs.009 and camt.057 field recommendation and samples to be added. -Addition of Bank Loans Appendix with MP Rules, pacs.009 and camt.057 field recommendation and samples to be added.

January 2011 -Update to Generic Appendix to include field recommendations of camt.057 (embedded document V3) based on updated camt.057 MDR document distributed by SWIFT in Oct. 2010. Also need to include sample message. Note sent to Frank V. 12/20 to provide feedback and a sample. -Update to Generic Appendix Section 4.2 and 4.3 to state pacs.009.001.02 instead of pain.001.001.02. Field recommendation and sample to be updated. -Open question noted on Creditor Agent field within MT202 field recommendations

February 2011

-Updated camt.057 field recommendations incorporated after feedback and review with SWIFT standards -Updated pacs.009 field recommendations incorporated after feedback and review with SWIFT standards -Bank loan appendix updated

February 2011

Update MT202 Matrix when using Fed ID within a Payment Instruction

March 2011

Disclaimer added to document Co-chairs

June 2011 Further updates on camt.057 and pacs.009 messages based on continued discussions with SWIFT standards

Co-chairs

March, 2012 Addition of new cash purpose codewords under Derivatives

Appendix to differentiate initial vs variation margin. J. Brasile

May, 2012 -Update of examples XML on page 30 and 39 -Addition of pacs.009 extension example

J. Brasile

October, 2012

-Clarification of Ordering Institution field recommendations on MT210 message

J. Brasile

Table of Contents Document History ........................................................................................... 2

1.0Introduction ............................................................................................... 61.1 BACKGROUND .................................................................................................................................................................... 61.2 BUSINESS DEFINITION ....................................................................................................................................................... 61.3 APPENDIX .......................................................................................................................................................................... 6

2.0Background ............................................................................................... 82.1 TYPES OF PAYMENT FLOWS ............................................................................................................................................. 82.2 ACTORS AND ROLES ......................................................................................................................................................... 9

3.0Business Definition................................................................................. 103.1 BUSINESS DATA REQUIREMENTS ................................................................................................................................... 103.2 MESSAGE USAGE RULES ................................................................................................................................................ 103.3 CASH PURPOSE CODES .................................................................................................................................................. 113.4.1 PROCESS FLOW FOR MARKET SETTLEMENTS OF PAYMENTS/RECEIPTS ............................................................... 113.4.2 ADDITIONAL PROCESS FLOW INCLUDING ACCOUNTING MESSAGING OF PAYMENTS/RECEIPTS .............................. 12

4.0 Appendix #1 Generic Payment ............................................................. 134.1 ISITC CASH PURPOSE CODEWORDS FOR GENERIC PAYMENTS .................................................................................. 134.2 MESSAGE SEQUENCE DIAGRAMS ................................................................................................................................... 144.3 FIN MT 202 MESSAGE .................................................................................................................................................... 164.4 FIN MT 210 MESSAGE ................................................................................................................................................... 194.5 ISO 20022 MX PACS.009.001.02 MESSAGE .............................................................................................................. 214.7 ISO 20022 MX CAMT.057.001.02 MESSAGE .............................................................................................................. 35

5.0 Appendix #2 Cash Collateral Payment ............................................... 415.1 ISITC CASH PURPOSE CODEWORDS SPECIFIC TO CASH COLLATERAL PAYMENTS ..................................................... 415.2 ACTORS AND ROLES ....................................................................................................................................................... 425.4 MESSAGE STRUCTURE AND REQUIREMENTS ................................................................................................................. 425.5 SAMPLE MX PACS.009.001.02 MESSAGE TO BE UPDATED. BELOW IS A PAIN001 ................................................. 43

6.0 Appendix #3 Securities Lending Payments ....................................... 446.1 ISITC CASH PURPOSE CODEWORDS SPECIFIC TO SECURITIES LENDING PAYMENTS ................................................. 446.2 ACTORS AND ROLES ....................................................................................................................................................... 456.3 MESSAGE SEQUENCE DIAGRAMS ................................................................................................................................... 466.4 MESSAGE STRUCTURE AND REQUIREMENTS ................................................................................................................. 516.5 SAMPLE MX PACS.009.001.02 MESSAGE .................................................................................................................... 52

7.0 Appendix #4 Derivatives Payments .................................................... 53Scope .................................................................................................................................................................................. 537.1 Definitions .................................................................................................................................................................... 537.2 Actors and Roles .......................................................................................................................................................... 537.3 Message Sequence Diagram ........................................................................................................................................ 537.4 Message Usage Rules ................................................................................................................................................... 537.5 Message Structure and Field Requirements/Recommendations .................................................................................. 54

7.6 Notification to Receive Field recommendations: ......................................................................................................... 547.7 Notification to Receive Field samples .......................................................................................................................... 557.8 Payment Instruction Field recommendations: ............................................................................................................. 567.8 Payment Instruction Field sample ............................................................................................................................... 57

8.0Appendix #5 Bank Loan Payments ...................................................... 58Scope .................................................................................................................................................................................. 588.1 Definitions .................................................................................................................................................................... 588.2 Actors and Roles .......................................................................................................................................................... 608.3 Message Sequence Diagram ........................................................................................................................................ 618.4 Message Usage Rules: ................................................................................................................................................. 618.5 Message Structure and Field Requirements/Recommendations .................................................................................. 628.6 Notification to Receive Field recommendations: ......................................................................................................... 628.7 Notification to Receive Field samples .......................................................................................................................... 628.8 Payment Instruction Field recommendations: ............................................................................................................. 628.8 Payment Instruction Field sample ............................................................................................................................... 62

Disclaimer: MX Messaging Market Practice Recommendations The existing Payment MX messaging formats do not fully support the payment needs of the Securities Industry. ISITC has submitted a business justification and is working with Payment Seg and Security Seg to identify proper messaging attributes need in support of Securities Industry payment flows. Our business justification is currently being reviewed by the Security Seg and Payment Seg and a solution has not yet been determined. The MX messaging flows are a work in process and items highlighted within this document have not been fully vetted.

6

1.0 Introduction This purpose of this document is to provide guidelines and market practice recommendations for the use of messaging in support of payments related processing. These guidelines are for payment messages as used within the Securities segment of the financial services industry within the United States. It should be noted that while there may be some overlap around usage, these market practice recommendations are separate from the Payments segment of the banking service industry. This document focuses on the data flow between two parties, and provides recommendations on how different industry standard messaging can be used in support of several business models. This Market Practice document is a working document and will continue to be enhanced to provide additional guidelines and market practices as needed by our constituency within ISITC. New guidelines will be added throughout time as requested by the ISITC membership. This market practice document itself is structured with three separate sections: 1.1 Background This section provides high level information with respect to payments processing and the introduction of messaging in support of that processing. It will introduce the concept of payment instructions, payment instruction cancellations, payments status, payment confirmation, and lastly reversal of payment instructions. Further it will introduce the basic parties that are the intended audience of this document; Investment Managers and Global Custodians. 1.2 Business Definition This section introduces some basic concepts and definitions that are used throughout the use of payments messaging. A basic, or generic, payments message is introduced to identify and define the common data elements that are typically found (and therefore are recommended) in most payments messages. Also within this section, Cash Purpose code words as identified by the industry are introduced, defined, and recommendation for use of code words is explained. 1.3 Appendix There are multiple business processes within the industry and within individual organizations for which payments related data flow is required. These business processes in many cases can be unique, but will also have similarities to other processes that are outlined. This document will contain multiple appendices, each to be used to provide details and recommendations of market practice use for payment messaging. The recommendations can be specific to a particular business process, or separately may be specific to the use of certain message format /syntax (csv files, industry messages etc.)

7

Each appendix will provide market practice recommendations for the use of messaging in support of the business process identified within it. Included in the appendix will be an explanation of the business process, identification of parties involved and their role in the process, and an outline of the data flow among those parties. The final section of the appendix will be the detailed technical recommendation on how to construct and use the messages in support of the business process. Following is a list of Appendices included in this document:

Appendix #

Name Description Link

#1 Generic Payment Baseline business and data requirements for securities related payment messages. Provide detail mapping for MT and MX messages.

Appendix #1

#2 Cash Collateral Payment Specific field recommendations for Cash Collateral payments associated with derivatives, margin, repo and lending transactions.

Appendix#2

#3 Securities Lending Payment

Specific field recommendations for Securities Lending related payments between the lending agent and borrowing broker.

Appendix #3

#4 Derivatives Specific recommendations for OTC Swap payments

Appendix #4

#5 Bank Loans Specific recommendations for Bank Loan initial and final contract related payments

Appendix #5

8

2.0 Background

This section provides high level information with respect to payments processing and the introduction of messaging in support of that processing. It will introduce the concept of payment instructions, payment instruction cancellations, payments status, payment confirmation, and lastly, reversal of payment instructions. The appendices in this document are included to provide details of individual work flows that leverage payment messaging. Details of each appendix will include the scope, identification of the actors involved, a process flow, message usage rules, message structure recommendations, and a sample message. 2.1 Types of Payment Flows

Flow General Description Instruction Message from a client that requests an account servicer to

initiate/receive a payment to/from another party. Status Message from an account servicer to a client indicating the

current (at the time the message is sent) status of that payment.

Confirmation of instruction Message from an account servicer to a client confirming that a payment has been made.

Instruction cancellation Message from a client that requests an account servicer to cancel a previously sent instruction.

Cancellation Status/Confirmation

Message from an account servicer to a client indicating the current status of a previously sent instruction cancellation.

Reversal Message from a client requesting an account servicer to recall a previously made payment Or Message from an account servicer to a client confirming that a previously made payment had been reversed.

9

2.2 Actors and Roles A brief note regarding Actors and Roles, and terms used within the document. The term Actor is used to identify a type of organization that is involved in a certain flow or process being described. The term Role is used to identify the task or purpose of that Actor involved in a certain flow or process. The organization will be indicated by its Actor name and described by the Role it plays. The following Actors have been identified and are referenced throughout this document:

Roles Account Owner Account Servicer

Cash Clearing

Depository

Local Clearing Agent

Counterparty

Actors

Underlying Client

Investment Manager

3rd Party Middle Office Provider

Global Custodian

Accounting Agent

Clients Custodian

Cash Clearing Depository

Sub-Custodian

Clearing Bank

Executing Broker

Lending Agent

Brokers Custodian

Prime Broker

Lending Agents

Custodian

Lending Brokers Custodian

Borrowing Broker

Lender (Account/Fund investing in loan)

Investment Manager

Bank Loan Agent

Lenders

Custodian

Loan Agent

Executing Broker

10

3.0 Business Definition

This section introduces the generic payment message and baseline business data requirements for all securities related payment messages. Although the different business flows are defined within their own appendices, in practice most of the payments messages will include the same business elements as the generic payment message, and will be differentiated only by the use of certain other data points. 3.1 Business Data Requirements This section identifies the common business elements that are the foundation of payment instructions.

Business Element Comments Message Identification Reference number to unambiguously identify the

message. Debtor (Account Owner) Party that owes an amount of money to the ultimate

creditor** Requested Execution Date/Settlement Date Date on which the debtors account is debited. End-to-end Identification Unique identification assigned by initiating party to

unambiguously identify the payment. This id is passed on, unchanged, throughout the entire end-to-end chain, which all parties in the chain can use to identify this particular payment

Currency of Payment Currency Instructed Amount of Payment Amount of money to be moved between the debtor and

creditor, expressed in currency as ordered by initiating party.

Cash Purpose Code Underlying reason for the payment transaction. (see ISITC Cash Purpose Codeword List for list of approved ISITC purpose codes).

Intermediary Agent The agent between the debtor agent and creditor agent. Optional to be used (or not used) as required for payment chain.

Creditor agent Financial institution servicing an account for the creditor Creditor Party to which an amount of money is due.

**The amount of detail required may vary in accordance with OFAC and/or other regulatory requirements. As this needs to be determined on a case by case basis by individual institution(s), it is therefore not included in the market practice. 3.2 Message Usage Rules This initial version of the market practice supports the use of a single message for a single payment, i.e. funds will de debited from a single account at the debtor agent and will be credited to a single account at the creditor agent.

11

3.3 Cash Purpose Codes This section introduces the concept of Cash Purpose Code words. Within the release of the MX Payment messages, the use of a Cash Purpose Code word is recommended as a manner in which the purpose of the payment can be specified. Although the Payments Industry already has a list of published code words, the ISITC membership concluded that the list was not sufficient to support payment message needs for the Securities Industry. ISITC has created a list of standard code words, and recommends that any payment message utilizes one of the ISITC code words to ensure the efficient and automated processing of that message. The content of the ISITC Cash Purpose Codeword List is controlled by the ISITC Payments Market Practice working group, and the list itself is maintained by the ISITC Reference Data Working Group. Requests to add, remove, or modify code words in this list must be submitted to the Payments Working group via business case and will be reviewed and approved accordingly. A complete list is available on the ISITC web-site. 3.4.1 Process Flow for Market Settlements of Payments/Receipts This is the generic payment process workflow on which this market practice is based. It identifies the primary roles of the participants in the workflow.

12

13.4.2 Additional Process Flow including Accounting Messaging of Payments/Receipts

Account Servicer (e.g. Custodian)

------------------Fund accountant

Postings

Account Owner (e.g. IM) MT 202 or MT 210

Cash Instruction MT 202MT 210

Account Servicer Cash

Correspondant Account Servicer a/c

Custody MT910/900 Confirmation of debit/credit and MT950/MT940 Statement

Accounting Security TradeFPML/MT54X with RPTO (contract)

Accounting MT950/MT940 Statement

Fund accountantPostings

Accounting Security TradeFPML/MT54X with RPTO

MT 202/MT 210 or fax

1 Source documents were obtained SWIFT documentation

13

4.0 Appendix #1 Generic Payment This section provides the specific field recommendations for generic payments associated with non-specific security trades. 4.1 ISITC Cash Purpose Codewords for Generic Payments This is a subset of the ISITC Classification Code list located on the Reference Data Working Group web-page.

Business Element

Codeword Definition

Generic Cash Purpose codeword

CASH Any cash payment not otherwise already identified with a specific cash purpose related type. Transaction is a general cash management instruction.

14

4.2 Message Sequence Diagrams

Ordering Account 1 Account 1 Account 2 Account 2 Beneficiary Customer Ordering Sender Receiver Account w/ Customer

Institution Custodian Custodian Institution

PACS CAMT

PACS 009.001.02 Customer CAMT057.001.01 Credit Transfer Initiation Message Notice to Receive Message Msg. to deliver/pay funds Msg. to expect payment receipt to beneficiary customer.

PACS PACS

PACS.008.001.01 PACS.003.001.01 Instruction to deliver/ Instruction to expect pay funds to beneficiary a payment receipt

PACS PACS Payment Status Report Payment Status Report PACS.002.001.03 PACS.002.001.03

Status Msg to sender Status Msg. to receiver

PACS CAMT Payment Status Report Payment Status Report PACS 002.001.03 CAMT059.001.01 Status Msg to deliverer of Status Msg. to receiver of payment payment

CAMT CAMT Confirmation Confirmation of payment of receipt

CAMT 054.001.01 CAMT 054.001.01

CAMT CAMT

Confirmation Confirmation of payment of receipt CAMT 054.001.01 CAMT 054.001.01

15

Account 1 Account 1 Account 2 Account 2 Beneficiary Ordering Sender Receiver Account w/ Customer

Institution Custodian Custodian Institution

CAMT CAMT

CAMT 055.001.01Customer CAMT058.001.01 Credit Transfer Cancellation Message Notice to Receive Cancellation Msg. to cancel deliver/pay funds Msg. to cancel expected payment receipt.

PACS PACS

PACS.056.001.01 PACS.056.001.01 Cancellation of deliver/ Cancellation of pay funds instruction expected payment receipt instruction

CAMT029.001.003

Resolution of Investigation CAMT029.001.03 Status Msg on cancellation

Request for delivery of payment

CAMT Resolution of Investigation CAMT029.001.03 No message sent to Status Msg on cancellation notify on status of Request for delivery of cancellation of receipt of payment

16

4.3 FIN MT 202 message This section provides the detailed technical recommendation for usage of the FIN MT 202 message for a generic or basic payment with one debtor and one creditor. Since this market practice is specific to the securities industry, this appendix makes the additional assumption that there is a direct account relationship between the sender (e.g. investment manager on behalf of their client, or mutual fund client) of the MT 202 and the receiver of the MT 202 (e.g. global custodian, or prime broker).

Business Element Field Name Definition Usage Rule/ Comment Tag Example

Message Identification Transaction Reference Number

This field specifies the reference assigned by the Sender to unambiguously identify the message.

20 :20:123456789

Cash Purpose Code Related Reference This field contains a reference to the related transaction.

ISITC recommends populating this tag with an ISITC approved Cash Purpose Code, available on the ISITC Classification Code list on the Reference Data Working Group web-page. ISITC understands the MT 202 has been utilized by the security industry for a number of years, and that organizations have already hard coded this field with other formats. Therefore, the market practice includes the following commonly used alternative formats:

- Cash Purpose Code/Reference Number - Reference Number transaction. - NONREF

21

:21: MARG Or :21: MARG/Ref Number Or :21: Ref Number Or :21: NONREF

Payment Method This business element is not applicable to the MT 202 Message

1) Requested Execution Date / Settlement Date 2) Currency of Payment 3) Instructed Amount

1) Value Date 2) Currency Code 3) Amount

This field specifies the value date, currency and amount to be transferred.

32A :32A:090203GBP150000,

Debtor (Account Owner) Senders Correspondent

This field specifies the account or branch of the Sender or another financial institution through which the Sender will reimburse the Receiver.

ISITC recommends the use of this field be mandatory; it specifies the debtors account number that will be debited by the account servicer (normally the receiver of the MT 202 instruction) in order to make the payment.

53a :53B:/47896325


Intermediary Agent Intermediary

This field specifies the financial institution through which the transaction must pass to reach the account with institution.

ISITC recommends using option A with BIC address. The field should be populated with the local market clearing id; otherwise populate the BIC code.

56a :56A:FIBAUS33XXX Or :56D://FW021000ABA

17


For three levels of clearing, tags 56, 57, and 58 should be populated.

For two levels of clearing, tags 57 and 58 should be populated.

Creditor agent Account With Institution

This field identifies the financial institution which will pay or credit the beneficiary institution.

ISITC recommends the use of this field as mandatory and using option A. Where it is the first level of clearing, ISITC

recommends populating the local market clearing id; otherwise populate the BIC code.

Where it is the second level of clearing, ISITC recommends populating both the BIC code and the creditor agents account number with the Intermediary Agent in tag 56a.

If Counterparty BIC address is not available the preferred method is to identify the Bank using option D (including name and address in the party field

57a

First level: :57D://FW021000ABA Or :57A:FIBAUS33XXX Second Level: :57A:/1234556 FIBADEFFXXX Third Level: 57D: //AC123456 Paying Agent XYZ

Creditor Beneficiary Institution

This field specifies the financial institution which has been designated by the ordering institution as the ultimate recipient of the funds being transferred.

ISITC recommends the use of this field as mandatory and using option A. It should be populated with both the creditors BIC code and their account number with the creditors agent in tag 57a.

If Counterparty BIC address is not available the preferred method is to identify the Beneficiary using option D (including name and address in the party field

58a

:58A:/456789 FIBADEFFXXX

58D:/ACCT123 BeneficiaryName

18

MT 202 Examples: USD Payment via Fed Wire with two levels of clearing 20 : 109800190352 21 : MARG 32A: 090203USD150000, 53B: /47896325 57D: //FW021000ABA 58A: /456789 FIBADEFFXXX USD Payment via Fed Wire with three levels of clearing 20 : 109800190352 21 : MARG/412568 32A: 090203USD150000, 53B: /47896325 56D: //FW021000ABA 57A: /123456 FIBAUS33XXX 58A: /456789 FIBADEFFXXX

19

4.4 FIN MT 210 Message This section provides the detailed technical recommendation for usage of the FIN MT 210 message instruction of advice to receive funds. This message is sent from an account owner to one of its account servicing institutions. Since this market practice is specific to the securities industry, this appendix makes the additional assumption that there is a direct account relationship between the sender (e.g. investment manager on behalf of their client, or mutual fund client) of the MT 210 and the receiver of the MT 210 (e.g. global custodian, or prime broker).

Business Element Field Name Definition Usage Rule/Comment Tag Format

Message Identification

Transaction Reference Number

This field specifies the reference assigned by the Sender to unambiguously identify the message.

20

:20:123456789

Credit Account

Account Identification This field identifies the account to be credited with the incoming funds

ISITC recommends the use of this field be mandatory; it specifies the creditors account number that will be credited by the account servicer (normally the receiver of the MT 210 notification).

25 25:1234567

Value Date Value Date This field contains the value date of all incoming funds specified in this message 30 :30:091015

Cash Purpose Code Related Reference

This field contains a related transaction reference Number, or other common reference,

ISITC recommends populating this field with an ISITC approved Cash Purpose Code.** ISITC recognizes that the MT 210 has been utilized by the security industry for a number of years, and that many organizations have already hard coded other formats. Therefore, the market practice also includes the following commonly used alternative formats:

- Cash Purpose Code/Reference Number

- Reference Number transaction. - NONREF

**Please see the ISITC Classification Code list on the Reference Data Working Group web-page.

21

:21: MARG Or :21: MARG/Ref Number Or :21: Ref Number Or :21: NONREF

Requested Receipt Currency and Amount

Currency Code, Amount

This field specifies the currency and amount to be received. 32B :32B:USD1200

20

Ordering Institution Ordering Institution BIC Address

This field specifies the party which owns the funds and is ordering their account to be debited to make the payment

After discussions with SWIFT Standards it was clarified that the ordering institution is the party who owns the money and is ordering the money to be debited from their account in order to make the payment. Example: If IM ABC is ordering account servicer DEF to debit their (ABCs) account and make a payment to counterparty 123, then IM ABC should be populated in field 52a of the MT210.

52a 52A: GOLDJPJX

Intermediary Intermediary Institution BIC

This field specifies the financial institution from which the Receiver is to receive the funds. Identifier Code must be a registered BIC.

ISITC recommends the use of this field be mandatory. If an intermediary party is not applicable to the receipt of funds, the ordering institution clearing agent should be populated.

56a :56A: BKTRUS33

MT 210 Examples: USD ADVICE TO RECEIVE :20: CU123456789 :25: 2233707 :30: 091016 :21: FEES :32B: USD1200 :52A: GOLDJPJX :56A: BKTRUS33 - USD ADVICE TO RECEIVE FED Funds 20 : 011405000287501 25 : 2345678 30 : 090905 21 : FEES/456123 32B: USD200218,80 52A : SBSIUS33 56D : //FW021000021

21

4.5 ISO 20022 MX PACS.009. message This section provides the detailed technical recommendation for usage of the ISO 20022 MX pacs.009 message for a generic or basic payment with one debtor and one creditor. This provides the baseline business and data requirements for all securities related payment messages. Scope: The FinancialInstitutionCreditTransfer message is sent by a debtor financial institution to a creditor financial institution, directly or through other agents and/or a payment clearing and settlement system. It is used to move funds from a debtor account to a creditor, where both debtor and creditor are financial institutions. Usage: The FinancialInstitutionCreditTransfer message is exchanged between agents and can contain one or more credit transfer instructions where debtor and creditor are both financial institutions. **Note on PACS 009 field usage table and sample message: ISITC continues to work with SWIFT to determine the proper field usage for the PACS 009 payment message in support of securities industry requirements. The Usage Rules/Comments column is being used to track the running discussion points in order to maintain the context that will lead to final decisions. Please ensure you review the discussion points and open questions as you evaluate the content of this table.

22

This section provides the detailed technical recommendation for usage of the ISO 20022 MX PACS 009.001 message for a generic or basic payment with one debtor and one creditor. This provides the baseline business and data requirements for all securities related payment messages.

Index Message Item Definition Mult. ISITC Mult.

Type / Representation Usage Rule / Comments XML Example

1.0 Group Header Set of characteristics shared by all individual transactions included in the message.

[1..1] [1..1]

1.1 Message Identification

Point to point reference assigned by the account servicing institution and sent to the account owner to unambiguously identify the message.

[1..1] [1..1]

Max35Text US ISITC Market Practice Recommendation (here after referred to as ISITC) is to follow stated usage. The instructing party has to ensure that Message Identification is unique per instructed party for a pre-agreed period.

123456789

1.2 Creation Date Time Date and time at which the message was created. [1..1] [1..1]

ISO Date Time ISITC recommends following stated usage.

2009-02-02T11:03:00-00:00

1.4 Number Of Transactions Number of individual transactions contained in the message. [1..1] [1..1]

Max15Numeric Text

ISITC recommends following stated usage.

1

1.8 Settlement Information

Specifies the details on how the settlement of the transaction(s) between the instructing agent and the instructed agent is completed.

[1..1] [1..1]

1.9 Settlement Method Method used to settle the (batch of) payment instructions. [1..1] [1..1]

Code INDA - InstructedAgent - Settlement is done by the agent instructed to execute a payment instruction.

INDA



2.0

Credit Transfer Transaction Information

Set of elements providing information specific to the individual credit transfer(s).

[1..n] [1..n]

2.1 Payment Identification

Set of elements used to reference a payment instruction. [1..1] [1..1]

Need example to see how multiple Ids are populated on PACS009. Is the entire sequence repeated or can the multiple Ids be populated within one occurrence of the PmtID sequence? SWIFT: not sure what is meant, but maybe below comments clarify

23



2.20 Instruction Identification

Unique identification, as assigned by an instructing party for an instructed party, to unambiguously identify the instruction.

[0..1] [1..1]

Max35Text Optional field. Need to determine within ISITC if should be recommended? SWIFT: this is the instructing agents (the senders) reference. This is a point-to-point reference that will change for each leg of the payment transaction.

123456

2.30 End To End Identification

Unique identification assigned by the initiating party to unambiguously identify the transaction. This identification is passed on, unchanged, throughout the entire end-to-end chain.

[1..1] [1..1]

Max35Text ISITC to discuss how field should be used since it is mandatory in PACS009. Usage discussion should include similar field within CAMT057 as well which is listed as optional. Discuss with SWIFT Standards why inconsistent mandatory vs. optional between CAMT057 and PACS009 SWIFT: not necessarily the sender of the message (ie the creditor) will know what reference will be assigned by the creditor who will initiate the payment order. In a payment initiation the use of the element is forced upon the payment initiator. As for an implementation guideline of the message, I would strongly recommend usage of the element to state for example the deal reference. MDR Usage: The end-to-end identification can be used for reconciliation or to link tasks relating to the transaction. It can be included in several messages related to the transaction. MDR Usage: In case there are technical limitations to pass on multiple references, the end-to-end identification must be passed on throughout the entire end-to-end chain.

987654

24



2.4 Transaction Identification

Unique identification, as assigned by the first instructing agent, to unambiguously identify the transaction that is passed on, unchanged, throughout the entire interbank chain.

[1..1] [1..1]

Max35Text ISITC to discuss how field should be used since it is mandatory in the PACS009. Discuss with SWIFT Standards as well. SWIFT: this is a stable interbank reference for tracking reasons. It should be the same as the instruction id used in the first leg of the payment transaction MDR Usage: The transaction identification can be used for reconciliation, tracking or to link tasks relating to the transaction on the interbank level. MDR Usage: The instructing agent has to make sure that the transaction identification is unique for a pre-agreed period.

2.6

Payment Type Information

Set of elements used to further specify the type of transaction. [0..1] [1..1]

Composed of PaymentType Information19 element

Fields to be added as per ISO change request approved in 2010. To be confirmed when fields will be added?

TBD Category Purpose

Specifies the high level purpose of instruction based on set of pre-defined categories. Usage: Used by the initiating party to provide information concerning the processing of the payment. May trigger special processing by any agent involved in the payment chain.

[0..1] [1..1]

Cash Purpose code is not yet incorporated in the pacs.009 schema awaiting approval for 2012

TBD Code Underlying reason for the payment transaction, as published in an external purpose code list.

[0..1] [1..1]

maxLength: 4 Cash Purpose code is not yet incorporated in the pacs.009 schema awaiting approval for 2012

CASH

TBD Proprietary Category purpose, in a proprietary form. [0..1] [1..1]

Max35Text Cash Purpose code is not yet incorporated in the pacs.009 schema awaiting approval for 2012

CASH

25



2.15

Interbank Settlement Amount

Amount of money moved between the instructing agent and the instructed agent.

[1..1] [1..1]

fractionDigits: 5 minInclusive: 0 totalDigits: 18

Active Currency Usage: The currency code must be a valid active currency code, not yet withdrawn on the day the message containing the currency is exchanged. Valid active currency codes are registered with the ISO 4217 Maintenance Agency, consist of three (3) contiguous letters, and are not yet withdrawn on the day the message containing the Currency is exchanged. Active Amount Usage: The number of fractional digits (or minor unit of currency) must comply with ISO 4217. Note: The decimal separator is a dot.

2.16 Interbank Settlement Date

Date on which the amount of money ceases to be available to the agent that owes it and when the amount of money becomes available to the agent to which it is due.

[0..1] [1..1]

ISO Date Need to confirm with SWIFT Standards usage is the same as the Requested execution date field within PAIN001. SWIFT: In the pain message requested execution date is when the account of the debtor was to be debited; interbank this is when settlement will occur between instructing and instructed agent. Recommendation previously stated by ISITC for the PAIN001 Req. Execution Date was: ISITC recommends following stated usage. This date represents the date on which the debtor's account is to be debited. This is the equivalent of the payment value date. Need to validate wording still applies?

26



2.28 Instructing Agent

Agent that instructs the next party in the chain to carry out the (set of) instruction(s).

[0..1] [0..1]

Field allowed at header and within lower level sequence. Need to confirm usage with SWIFT Standards? Also need clarity on how this party differs from the Debtor Agent field? SWIFT: See 1.29 Instructing Party

Financial Institution Identification

Unique and unambiguous identification of a financial institution, as assigned under an internationally recognised or proprietary identification scheme.

[1..1] [1..1]

Need to discuss within ISITC on recommendation to populate as this is an optional field. . SWIFT: See 1.29 Instructing Party

FinInstnID BIC

ABCUS33

2.29 Instructed Agent

Agent that is instructed by the previous party in the chain to carry out the (set of) instruction(s).

[0..1] [0..1]

Field allowed at header and within lower level sequence. Need to confirm usage with SWIFT Standards? SWIFT: See 1.29 Instructing Party



[1..1] [1..1]

Open question for SWIFT standards on MT202 regarding the Creditor Agent will determine if this field should be recommended or not. SWIFT: See 1.29 Instructing Party

FinInstnID BIC

ABCUS33

2.30 Intermediary Agent1

Agent between the debtor's agent and the creditor's agent. [0..1] [1..1]

Comprised of BranchAnd Financia lInstitution Identification4 element

ISITC recommends the following usage. This field should be populated with a BIC or a local market clearing id (e.g. Sort Code). SWIFT MDR Usage Clarification: Usage: If more than one intermediary agent is present, then IntermediaryAgent1 identifies the agent between the DebtorAgent and the IntermediaryAgent2.

CCSTGB2L

27



2.31 Intermediary Agent1 Account

Unambiguous identification of the account of the intermediary agent 1 at its servicing agent in the payment chain.

[0..1] ??

ISITC to discuss as this was not previously a recommended field within the PAIN001. Is there a need within US or globally to ever populate the Intermed. Account?

2.32 2.35

Intermediary Agent 2 and 3 and Intermediary Agent Account 2 and 3

[0..1] ??

Fields available, but there was not a need to include a recommendation of usage within our PAIN001 review. Need to discuss within ISITC and globally if we should clarify usage of additional intermediary parties within this MP?

2.36 Ultimate Debtor

Ultimate financial institution that owes an amount of money to the (ultimate) institutional creditor.

[0..1] ??

SWIFT Standards to clarify how and when this may differ from the debtor field noted below? SWIFT: this is an optional element and its usage will depend on the scenario. It could be for example that the debtor, head office makes a payment on behalf of its branch. The branch is then the Ultimate Debtor This field was present within the PAIN001 and ISITC had not recommended using.

2.37 Debtor

Financial institution that owes an amount of money to the (ultimate) financial institutional creditor.

[1..1] [1..1] Party Identification Element 32.

>



[1..1] [1..1]

ISITC recommends the use of the Fund Name. Note: Additional detail may be required to satisfy OFAC and/or other regulatory requirements. As this needs to be determined on a case by case basis by individual institution(s), it is therefore only the fields where this information can be provided are clarified within this MP.

Fund Name

28



Postal Address

[0..1] [0..1]

Need to confirm with SWIFT standards if Account Name and Address need to be split out into separate AcctOwner Party Sequences? Example to highlight usage. SWIFT: do you refer to the party with account or to the account number. In any case, name and address should be split. If the account references the account number, then DebtorAccount element must be used.

Address Line

[0..1] [0..1]

ISITC US MP recommends usage of of this field if required for OFAC requirements. Need to confirm level of identifiers that should be the recommendation withn the PstlAdr block? Is AdrLine the ideal free format usage or use structured fields within Address? SWIFT: although possible, the advice is to not mix AddressLine (unstructured address information) with structured address information

Address

2.38 Debtor Account

Unambiguous identification of the account of the debtor to which a debit entry will be made as a result of the transaction.

[0..1] [1..1]

Related to CashAccont16 element

ISITC recommends using the debtors fund account number at the account servicer/custodian.

47896325

2.39 Debtor Agent

Financial institution servicing an account for the debtor. [1..1] [1..1]

Comprised of BranchAnd Financia lInstitution Identification4 element

ISITC recommends populating the debtors account servicer/ custodian, and should be identified by a BIC code. Discuss with ISITC and SWIFT Standards how this field is used compared with the Instructing Agent field within the header and the CreditTransferTransactionInformation block? SWIFT: See 1.29 Instructing Party

CCSTUS6S

2.40 Debtor Agent Account

Unambiguous identification of the account of the debtor agent at its servicing agent in the payment chain.

[0..1] ??

ISITC to discuss usage? This field was present within PAIN001 and no recommendation was made to use.

29



2.41 Creditor Agent

Financial institution servicing an account for the creditor. [0..1] [1..1]

Comprised of BranchAnd inancial Institution Identification4 element

ISITC recommends the following usage. This field should be populated with a BIC code.

FIBAGB2L

2.42 Creditor Agent Account

Unambiguous identification of the account of the creditor agent at its servicing agent to which a credit entry will be made as a result of the payment transaction.

[0..1] ??


2.43 Creditor Party to which an amount of money is due. [1..1] [1..1]

Comprised of Party Identification32 element

ISITC recommends the following usage. This field should be populated with a BIC code.

FIBADEFF

2.44 Creditor Account

Unambiguous identification of the account of the creditor to which a credit entry will be posted as a result of the payment transaction.

[0..1] ??


2.45 Ultimate Creditor Ultimate financial institution to which an amount of money is due. [0..1] ??


2.54

Underlying Customer Credit Transfer

Set of elements used to provide information on the underlying customer credit transfer for which cover is provided.

[0..1] ??

Optional Underlying Customer Credit Transfer block for cover payments Available. Need to discuss if ISITC will make a recommendation on usage. SWIFT: component should not be used if not related to a cover payment. This is where the information of an underlying pacs.008 or MT 103 that was sent with cover method will be copied for screening purposes. My assumption would be that you can ignore this component.

30

4.6 Sample MX pacs.009 Message (corresponding to above matrix) ACCTOWNERREF1234 2001-12-17T09:30:47.0Z 1 INDA

a a a

a

Cash Purpose code is not yet incorporated in the pacs.009 schema awaiting approval for 2012

0 1967-08-13 AAAAAA20 AAAAAA20 AAAAAA20 a AAAAAA20

31

a

a

a a a AAAAAA20 a AAAAAA20 a AAAAAA20 a AAAAAA20

32

4.7 Sample MX pacs.009 Message (with Allocation Extension)

- - ACCTOWNERREF1234 2001-12-17T09:30:47.0Z 1 - INDA

- - a a a

- - a

6000000 1967-08-13 - - AAAAAA20

- - AAAAAA20

- - AAAAAA20

- a

- - AAAAAA20

-

33

- a

- - - a a a

- a

- - AAAAAA20

- a

- - AAAAAA20

- a

- - AAAAAA20

- a

- - AAAAAA20

- - -

34

- alloc-1 - a1 Account a1

- 1000000

COLR


- 2000000

COLR


- 3000000

COLR

35

5.0 ISO 20022 MX CAMT.057 message This section provides the detailed technical recommendation for usage of the ISO 20022 MX camt.057.001.02 message for a generic or basic payment with one debtor and one creditor. This provides the baseline business and data requirements for all securities related payment messages. Scope The NotificationToReceive message is sent by an account owner or by a party acting on the account owner's behalf to one of the account owner's account servicers. It is an advance notice that the account servicer will receive an amount of money to be credited to the account of the account owner. Usage The NotificationToReceive message is used to advise the account servicer of an amount of money that the account owner expects to have credited to its account.

36

This section provides the detailed technical recommendation for usage of the ISO 20022 MX CAMT.057 message for a generic or basic payment with one debtor and one creditor. This provides the baseline business and data requirements for all securities related payment messages. Notification to Receive CAMT057

Index Message Item Definition ISO Mult.

ISITC Mult. Type /

Representation Usage Rule / Comments XML Example

1.0 Group Header Set of characteristics shared by all individual transactions included in the message.

[1..1] [1..1]

1.1 MessageIdentification

Point to point reference assigned by the account servicing institution and sent to the account owner to unambiguously identify the message.

[1..1] [1..1]

Max35Text US ISITC Market Practice recommendation is to follow stated usage. The instructing party has to make sure that Message Identification is unique per instructed party for a pre-agreed period.

123456789

1.2 CreationDateTime Date and time at which the message was created. [1..1] [1..1]

ISODateTime US ISITC Market Practice recommendation is to follow stated usage.

2006-11-14T22:30:47.0Z

Index Message Item Definition ISO Mult.

ISITC Mult. Type /

Representation Usage Rule / Comments XML Example

2.0 Notification

[1..1] [1..1]

2.1

Identification

Unique identification, as assigned by the account owner, to unambiguously identify the account notification.

[1..1] [1..1]

Max35Text US ISITC MP recommendation is to populate this ID as the ID that follows the transaction through its lifecycle. Since the ISITC recommendation is to use the CAMT057 for single net/bulk instructions, the Identification in field 2.1, should be the same as field 2.16

ACCOWNERREF12345

37

2.2 Account

Identifies the account to be credited with the incoming amount of money. [1..1] [1..1]

Identification

Unique and unambiguous identification for the account between the account owner and the account servicer.

[1..1] [1..1]

Other

Unique identification of an account, as assigned by the account servicer, using an identification scheme.

[1..1] [1..1]

Identification

Identification assigned by an institution. [1..1] [1..1]

Max34Text ISITC US MP recommendation is to populate Account ID. Name is not required at this level. OFAC requirement for account name and address to be stated in the account owner party field 2.3

558748

2.3 Account Owner

Party that legally owns the account. [0..1] [0..1]

Party

[0..1] [0..1]

ISITC US MP recommends usage of Name and Address of legal account owner when required for OFAC requirements.

Account Name

Postal Address

[0..1] [0..1]

This field allows for the ability to state the Name and Address in a structured field format. Ex: Street Name Building Number Town Name Country

Address

Address Line

[0..1] [0..1]

This field allows for the ability to state the Name and Address in a free format text line of 70 characters. WG to discuss if Postal Address structured field or Address line free format to be recommendation

Address

Usage of Total Amount (2.8), Expected Value Date (2.9), Debtor (2.10-2.12), Debtor Agent (2.13) and Intermediary Agent (2.14) within the Notification block are not recommended to be used. Although these fields were added as part of Version 2 of the CAMT057 at the request of ISITC, the decision to create a new ISO message for accounting bulk/net allocation information to link to the CAMT057 will replace this usage. Fields will be requested to be removed from CAMT057 in 2011 as a CR to ISO.

38

2.15 Item

Set of elements used to provide details of the expected amount on the account serviced by the receiver of the message.

[1..n] [1..n]

2.16 Identification Unique identification, as assigned by the account owner, to unambiguously identify the expected credit entry.

[1..1] [1..1]

Max35Text US ISITC MP recommendation is to populate this ID as the ID that follows the transaction through its lifecycle. Since the ISITC recommendation is to use the CAMT057 for single net/bulk instructions, the Identification in field 2.16, should be the same as field 2.1

ACCOWNERREF12345

2.24 Amount Amount of money expected to be credited to the account. [1..1] [1..1]

.Active Or Historic Currency AndAmount

US ISITC Market Practice recommendation is to follow stated usage.

500000

2.25 Expected Value Date Value date on which the account is expected to be credited. [1..1] [1..1] ISODate US ISITC Market Practice

recommendation is to follow stated usage.

2009-02-13

2.26 Debtor Party that owes an amount of money to the (ultimate) creditor. [1..1] [1..1]

Party Identification Element 32. Refer to Page 882 of MDR

This is the equivalent field within the MX of the Ordering Institution on the MT210. This field should be populated with the counterparty who is instructing their account servicers to transfer funds to the account owner (creditor) receiving these funds.

ABCDUS33

2.29 DebtorAgent Financial institution servicing an account for the debtor. [0..1]

[1..1]

Comprised of BranchAnd Financia lInstitution Identification4 element on Page 611

If the debtor agent is paying the funds to the creditors agent/intermediary (e.g. subscutodian) , then this field will be populated with that agent. If InternediaryAgent is paying the funds to the creditors agent, the recommendation is that both fields are populated.

ABCDUS33

2.30 IntermediaryAgent gent between the debtor agent and the count servicing institution.

[0..1]

[0..1]

Comprised of BranchAnd Financia lInstitution Identification4 element on Page 611

If InternediaryAgent is paying the funds to the creditors agent, the recommendation is that both fields are populated. Add clarifying comments to ISITC MP recommendation. Usage: This is the agent from which the account servicing institution will get the amount of money. If there is more than one intermediary agent, then IntermediaryAgent identifies the agent closest to the account servicing institution.

ABCDUS33

39

2.31 Purpose

Specifies the high level purpose of instruction based on set of pre-defined categories. Useage: Used by the initiating party to provide information concerning the processing of the payment. May trigger special processing by any agent involved in the payment chain.

[0..1] [1..1]

2.32 Code Underlying reason for the payment transaction, as published in an external purpose code list.

[0..1] [1..1]

maxLength: 4 ISITC recommends this field be mandatory to identify purpose of transaction. Data Type List: ExternalPurpose1Code is an ISO registered list of codewords. ISITC to submit list of cash purpose codewords maintained by Reference Data WG to ISO to have added to this list.

CASH

2.33 Proprietary Category purpose, in a proprietary form. [0..1] [1..1]

Max35Text ISITC recommends usage of this field for the cash purpose codeword only until a code has been added to the ISO External Purpose1 Code list.

CASH

40

4.8 Sample MX camt.057.001.02 Message (corresponding to above matrix) a 2001-12-17T09:30:47.0Z ACCOUNTREFERENCE123

CUSTODIAN ACCOUNT ID ACCOUNT FULL NAME a a ACCOUNTREFERENCE123 500000 2011-08-13 CNTPUS33 AAAAAA20 AAAAAA20 CASH

41

5.0 Appendix #2 Cash Collateral Payment This section provides the specific field recommendations for Cash Collateral payments associated with derivatives, margin, repo and lending transactions. 5.1 ISITC Cash Purpose Codewords specific to Cash Collateral Payments This is a subset of the ISITC Classification Code list located on the Reference Data Working Group web-page.

Business Element

Codeword Definition

Option Broker Owned Cash Collateral

OPBC Any cash payment related to the collateral for an OTC option, which is segregated, and not available for use by the client.

Option Client Owned Cash Collateral

OPCC Any cash payment related to the collateral for an OTC option, which is owned by the client and is available for use by the client when it is returned to them

Forwards Broker Owned Cash Collateral

FWBC Any cash payment related to the collateral for a Master Agreement forward, which is segregated, and not available for use by the client. Example master agreement forwards include TBA, repo and Bond Forwards.

Forwards Client Owned Cash Collateral

FWCC Any cash payment related to the collateral for a Master agreement forward, which is owned by the client and is available for use by the client when it is returned to them. Example master agreement forwards include TBA, repo and Bond Forwards.

Margin Client Owned Cash Collateral

MGCC Any cash payment related to the collateral for initial futures margin, which is owned by the client and is available for use by the client when it is returned to them.

Swaps Broker Owned Cash Collateral

SWBC Any cash payment related to the collateral for Swap margin , which is segregated, and not available for use by the client. This includes any collateral identified in a CFA agreement such as Swap or FX Forward collateral.

Swaps Client Owned Cash Collateral

SWCC Any cash payment related to the collateral for Swap margin, which is segregated, and not available for use by the client. This includes any collateral identified in a CFA agreement such as Swap or FX Forward collateral.

CCP Collateral CCPC Collateral that is covering the initial margin requirements for OTC trades clearing through a CCP.

42

5.2 Actors and Roles

Account Owner Account Servicer Cash Clearing Depository

Local Clearing Agent

Counterparty

Underlying Client Investment Manager

3rd Party middle office

outsourcer/vendor

Global Custodian Accounting Agent

Prime Broker Lending Agent


Sub-Custodian Executing Broker

5.4 Message Structure and Requirements Cash Collateral related payment messages utilize the same message structure as the Generic Payment message. The only difference is the Cash Collateral specific subset of ISITC Cash Purpose codewords used in the Proprietary field (Index # 2.41) of the Category Purpose composite.


Type / Representati

on Usage Rule / Comments XML Example

2.39 Category Purpose

Specifies the high level purpose of instruction based on set of pre-defined categories. Usage: Used by the initiating party to provide information concerning the processing of the payment. May trigger special processing by any agent involved in the payment chain.

[0..1] [1..1]


Max35Text ISITC recommends the use of this field be mandatory to identify purpose of transaction. It should be populated with one of the ISITC Approved Cash Purpose Codewords as referenced within the Market Practice.

SWCC

43

5.5 Sample MX pacs.009.001.02 Message To be updated. Below is a PAIN001 123456789 2009-02-02T11:03:00-00:00 1 AMAGGB22 ABC TRF 2009-02-03 Sky Limited 47896325 CCSTUS6S 987654 SWCC 150000 CCSTUS2L FIBAUS2L FIBADEFF

44

6.0 Appendix #3 Securities Lending Payments This section provides the specific field recommendations for Securities Lending related payments between the lending agent and borrowing broker. 6.1 ISITC Cash Purpose Codewords specific to Securities Lending Payments This is a subset of the ISITC Classification Code list located on the Reference Data Working Group web-page

Business Element Codeword Definition Trade Collateral LCOL It is common for the currency of the lent security to differ from the currency

of the cash collateral. The securities trade free of payment. The cash collateral is paid from the borrower to the lending agent separately from the security settlement, representing the first leg of the loan of securities. When the borrowers return the shares to the lender's account, the lending agent makes a collateral payment to the borrower as the last activity to close out the loan.

Mark to Market LMRK Cash payment for Mark-to-markets of a portfolio of Loans of Securities. Asset classes of the securities on loan are not specified.

Mark to Market LMEQ Cash payment for Mark-to-markets of a portfolio of Loans of Equity Securities.

Mark to Market LMFI Cash payment for Mark-to-markets of a portfolio of Loans of Fixed Income Securities.

Billing LREB Each loan carries a percentage "rebate rate". Cash collateral is invested by the lending agent. At agreed intervals, the lending agent pays to the borrower a portion of investment earnings. This is known as a rebate payment.

Billing LFEE There are circumstances when either the borrower or lending agent make lending-related fee payments that are not "rebates". Examples are exclusive fees, transaction fees, custodial fees, or minimum balance fees.

Billing LREV There are circumstances when the lending agent makes payments to the underlying client of the revenue generated by the lending activity.

Investment Manager Sells

LSFL If an investment manager (IM) sells a position and the outstanding loan position leaves insufficient shares available for the custodian to make delivery on settlement date, the fund is denied use of the proceeds of the sell. The IM will issue a claim to the lending agent for use of funds -- a "Sell fail claim". The lending agent will pass the claim along to the

45

borrower, requiring a borrower-to-lending agent payment. Investment Manager Sells

LBIN If an IM sell fails for an extended period of time, the buying broker or the depository may "buy-in" the trade. The IM notifies the lending agent of the buy-in, who in turn notifies the borrower that the borrower now owns the shares in the loan. The lending agent seizes the collateral to pay to the IM. It is unlikely that the IM's foregone sell proceeds match the seized collateral value, so the borrower and lending agent will have to exchange a payment for remittance to or from the IM.

Substitute Payment LCOR Corporate Action entitlements will be paid to the borrower for securities on loan. This requires the borrower to then remit payment to the lending client's account. These "substitute" payments are common for dividends, or other types of actions.

6.2 Actors and Roles

Account Owner Account Servicer Local Clearing Agent

Counterparty

Underlying Client Lending Agent

Borrowing Broker

Clients Custodian Brokers Custodian

Clearing Bank Borrowing Broker

46

6.3 Message Sequence Diagrams 6.3.1 Lending Agent to Borrowing Broker collateral payments

The Lending Agent and borrower agree to exchange payment for one of several categories of payment in the normal course of business:

- Trade Collateral (LCOL) - Mark to Market (LMRK, LMEQ, LMFI) - Billing Payment of rebate(LREB) of fees (LFEE) - Investment Manager Sells (LSFL)

The Lending Agent instructs their Account Servicer (Custodian) via the PAIN Payment Initiation message to expect a payment from the borrowing broker or to initiate a payment to the borrowing broker for the net of all the Mark to Market and Collateral activity. The Account Servicer processes the payment in the local Market. The Borrowing Broker instructs their Account Servicer to initiate a corresponding payment in the Market.

Lending Agent Account Servicer Depository Account Servicer Borrower (Custodian)

Agreement of Credit / Debit Amount CAMT PACS

CAMT 057.001.01 PACS.009.001.02 Notice to Receive Customer Credit Transfer Initiation Instruction to expect a payment Instruction to debit account receipt from the borrowers custodian and credit lenders custodian

PACS PACS

PACS.003.001.01 PACS.008.001.02 Instruction to expect Instruction to debit borrowers a credit from the account and credit the lenders borrowers custodian custodian

PACS PACS PACS.002.001.03 PACS.002.001.03

Payment Status Report Payment Status Report Status message Status message to sender to receiver

PACS PACS PACS.002.001.03 PACS.002.001.03

Payment Status Report Payment Status Report CAMT CAMT

CAMT.054.001.02 CAMT.054.001.02

Payment Confirmation Payment Confirmation of credit of debit

CAMT CAMT

CAMT.054.001.02 CAMT.054.001.02 Payment Confirmation Payment Confirmation of credit of debit

47

6.3.2 Lending Agent to Client (Billing) The Lending Agent owes the client their split of the lending related income. The Lending Agent instructs their Account Servicer (Custodian) via the PAIN Payment Initiation message to initiate a payment to the Clients Account Servicer (Custodian). The clients Account Servicer (Custodian) credits their account.

Lending Agent Account Servicer Account Servicer

(Agents Custodian) (Clients Custodian) PACS

PACS.009.001.02 Customer Debit Transfer Initiation Instruction to debit account and credit clients custodian

PACS

PACS.008.001.02 Instruction to debit Lenders account and credit clients custodian

PACS PACS.002.001.03 Payment Status Report Status message to sender

PACS PACS.002.001.03

Payment Status Report Status message to sender

CAMT CAMT.054.001.02

Payment Confirmation of debit

CAMT

CAMT.054.001.02 Payment Confirmation of debit

2


48

6.3.3 Lending Agent to Fund Manager (Billing) *** A proposed flow, no actual use *** The Lending Agent agrees to pay the Fund Manager for either of these categories of payment in the normal course of business:

- Billing Payment of fees (LFEE) - Investment Manager Sells Payment to reimburse the fund manager for the cost of

buy-in (LBIN) The Lending Agent instructs their Account Servicer (Custodian) via the PAIN Payment Initiation message to initiate a payment to the Fund Managers Account Servicer (Custodian). The Fund Managers Account Servicer (Custodian) credits their account.




PACS



PACS PACS.002.001.03




CAMT


3 3 Source documents were obtained SWIFT documentation

49

6.3.4 Lending Agent to Third Party Custodian (Billing) The clients Third Party Custodian bills the Lending Agent for transaction fees imposed for the settlement of lending trades. The Lending Agent instructs their Account Servicer (Custodian) via the PAIN Payment Initiation message to initiate a payment to the clients Account Servicer (Custodian).




PACS



PAIN PAIN.002.001.02




CAMT


4


50

6.3.5 Borrowing Broker to Lending Agent Substitute Payment The Borrowing Broker owes a payment to the client for a Manufactured Income or Substitute Payment representing the Cash Dividend Income the client is due for shares on-loan at the agent over Record Date. In the US market, DTC tracks who is due the dividend when shares are on loan. For non-US or Fed traded assets, the Borrowing Broker and Lending Agent agree on the Cash Dividend Substitute Payment amount due from the Borrower and the Borrower confirms the Value Date of the payment. The Lending Agent instructs their Account Servicer (Custodian) via the PAIN Payment Initiation message to expect a payment from the borrowing broker. The Borrowing Broker instructs their Account Servicer to initiate a corresponding payment in the Market.

Lending Agent Account Servicer Depository Account Servicer Borrower (Custodian)

Agreement of Credit / Debit Amount * PACS PAIN

Customer Credit Transfer Initiation Customer Debit Transfer Initiation PACS.009.001.02 PAIN.008.001.02 Instruction to expect a credit from Instruction to debit account

the borrowers custodian and credit lenders custodian PACS PACS

FI to FI Credit Transfer FI to FI Debit Transfer PACS.008.001.01 PACS.003.001.01 Instruction to expect Instruction to debit borrowers a credit from the account and credit the lenders borrowers custodian custodian

PACS PACS Payment Status Report Payment Status Report PACS.002.001.02 PACS.002.001.02

Status message Status message to sender to sender

PAIN PAIN Payment Status Report Payment Status Report PAIN.002.001.02 PAIN.002.001.02

Status message to sender Status message to sender 5


51

6.4 Message Structure and Requirements Securities Lending related payment messages utilize the same message structure as the Generic Payment message. The only difference is the Securities Lending specific subset of ISITC Cash Purpose codewords used in the Proprietary field (Index # 2.41) of the Category Purpose composite.


Type / Representati

on Usage Rule / Comments XML Example

2.31

Payment Type Information

Set of elements used to further specify the type of transaction. [0..1] [1..1]

Composed of PaymentType Information19 element

2.39 Category Purpose

Specifies the high level purpose of instruction based on set of pre-defined categories. Useage: Used by the initiating party to provide information concerning the processing of the payment. May trigger special processing by any agent involved in the payment chain.

[0..1] [1..1]


Max35Text ISITC recommends the population of this field to be mandatory to identify purpose of transaction. It should be populated with one of the ISITC Approved Cash Purpose Codewords as referenced within the Market Practice.

LMRK

52

6.5 Sample MX pacs.009.001.02 Message

53

7.0 Appendix #4 Derivatives Payments

Scope The derivatives appendix is related to payments associated with swaps and listed derivatives.

7.1 Definitions Business Element Codeword Definition

Fees FEES Fees related to the opening of the trade itself Listed Derivatives Margin MARG Any cash payment related to daily listed derivative margin, which is

not segregated as collateral, and is available for use by the client/recipient. Example: Listed future/option related margin payments and premium payments for listed options that are not covered in the MT54x message

Swap Upfront Payment SWUF Swap related upfront payment Swap Reset Payment SWRS Swap related reset payment Swap Partial Payment SWPP Swap partial payment termination/Novation Swap Final Payment SWFP Swap related final payment Credit Default Event Payment CDEP Credit Default Event Payment Futures Netting FNET Futures Netting Payment CCP Collateral CCPC Collateral that is covering the initial margin requirements for OTC

trades clearing through a CCP. CCP Margin Variation CCPM Margin variation on your OTC derivatives clearing through a CCP.

If the Initial Margin and Variation Margins are netted then the CCPM code word shall still be utilized. The Variation Margin amounts shall be detailed on the Variation Margin Flow report. Therefore the custodians will know the amount of variation margin that was part of the netted variation margin amount.

7.2 Actors and Roles Account Owner Account Servicer Cash Clearing

Depository Local Clearing

Agent Counterparty

Underlying Client Investment Manager

3rd Party middle office

outsourcer/vendor

Global Custodian Accounting Agent

Prime Broker


Sub-Custodian Executing Broker

7.3 Message Sequence Diagram Swap related payments and CDS default event payments will follow the generic messaging flow as documented on the attached. Futures netting flow to be documented in a later version.

7.4 Message Usage Rules

54

The field recommendations within the notification to receive and credit transfer transaction for linking back to the contract, conversation and version Ids of the FpML contract are highlighted within the appropriate message field recommendations template. The below table highlights how these three identifications on the FpML contract may differ and why all three are necessary to be linked to the payment. Examples:

Create Increase (1) Further Increase

Partial Termination

New Correct New Correct New New

Notification message Contract Created

Contract Created

Contract Increased

Contract Increased

Contract Increased

ContractPartial Termination

conversationId CNV001 CNV001 CNV078 CNV078 CNV003 CNV454 Primary contractId IRS001 IRS001 IRS001 IRS001 IRS001 IRS001 version 1 2 3 4 5 6

7.5 Message Structure and Field Requirements/Recommendations Business Element Comments

Swaps related additional elements: Cash Purpose Codeword As outlined in definitions section above Linkage field (3 different references) Link to the Swap Contract ID, Conversation ID and

Version of the FpML Contract required to determine unique Swap Contract

Margin related additional elements: Cash Purpose Codeword As outlined in definitions section above Listed Derivatives related additional elements: Cash Purpose Codeword As outlined in definitions section above Security ID of listed derivative Link to Security ID of the security trade for listed

derivative Linkage field Link to the reference ID of the security trade (listed

derivative)

7.6 Notification to Receive Field recommendations: This section provides the detailed technical recommendation for usage of the ISO 20022 MX camt.057.001.02 message for a derivatives. Embedded document covering camt057

55

recommendations to be updated with new CAMT057 Version 2 fields and incorporated into document.

Z:\ISITC\Conferences\Decemb

7.7 Notification to Receive Field samples

56

7.8 Payment Instruction Field recommendations: This section provides the detailed technical recommendation for usage of the ISO 20022 MX pacs.009.001.02 message for a derivatives related payment with one debtor and one creditor. Recommendations to be updated with PACS009 fields Customer Credit Transfer Initiation PACS009.001.02

57

7.8 Payment Instruction Field sample

58

8.0 Appendix #5 Bank Loan Payments

Scope The bank loan appendix is related to payments associated with the initial setup and maintenance of a structured product/bank loan.

8.1 Definitions Business Element Codeword Definition

Principal Payment BKPP Cash activity related to the principal paydown specific to bank loans.

Interest Payment BKIP Cash activity related to interest specific to bank loans. Types of interest include accrued interest.

Delayed Draw Funding BKDF Certain issuers may utilize delayed draw loans, in which case, the lender is committed to fund cash within a given period of time when it is called on by the issuer. The lender receives a fee for this commitment.

Bank Loan Fund Memo BKFM Net cash movement instruction for loan contract final notification when sent separate from the loan contract final notification instruction. This codeword is used when the account owner will not be sending cash instructions within the loan contract final notification via FpML or ISO15022 54x.

Bank Loan Fees BKFE Cash activity related to fees specific to bank loans. Types of fees included under this generic definition include Upfront fees, Funding fees, Utilization fees, Facility fees, Commitment fees, Letter of Credit associated fees, Amendment fees, Waiver fees, Fronting Fees, Consent fees, Agent/Assignment fees, Delayed Compensation fees, Cost of Carry fees. 1. Upfront A fee paid by the borrower to lenders to increase the return on their portion of the loan. The fee will vary from transaction to transaction and will frequently vary within the

market practice documents_payment working group_payment market practice document - november 2012...

Documents

field recommendations

lending appendix

mt202 field recommendations

updated camt

generic appendix section

swift standards updated

mdr document

creditor agent field