Programming Specifications for Trade Reporting to the FINRA Trade Reporting and Compliance Engine (TRACE) via the NSCC RTTM System

Transcription

1 Programming Specifications for Trade Reporting to the FINRA Trade Reporting and Compliance Engine (TRACE) via the NSCC RTTM System Version 2.4 January 20,

2 Revision History Date Published Version Updates January 20, Updated to clarify the definition of primary market trades that are reportable T+1 versus primary market trades that are reportable within 15 minutes of execution. October 10, Updated to reflect the modifications to TRACE (effective March 1, 2010) to accept trade reports of agency debt transactions, and trade reports of agency debt and over-the-counter corporate bond transactions executed in the primary market. December 1, Updated to reflect changes to Yield reporting requirement that went into effect November July 1, Updated to reflect changes to TRACE to support reporting of equity-linked notes that trade in shares as units (see Quantity of Securities {CONF} field in section 3.2). September 12, Updated to reflect new corporate name (from NASD to FINRA). May 16, Updated the TRACE Reject Codes list in Appendix B with the following new codes: T021, T024, T050, T068, T082, T083, T136, T137, T504, T505, T506, T510, T515, T540. Please see the list for error text descriptions of the new codes. March 23, Removed reject reference numbers (TRRF) being generated and included on MT509s for rejects of Reversals, Cancels, Modifies and DKs (see sections 1.4 and 4.2). Amended specification on MT509 20C Reference (RELA) to include the value NONREF on reports submitted via RTTM Web (see section 4.2). Corrected examples of TRACE Control Numbers (TRRF) in the MT509 20C Reference field specification (see section 4.2). February 3, First published version 2

3 OVERVIEW Interactive Messaging for Real-Time Reporting of OTC Corporate Bond and Agency Debt Transactions This document updates the RTTM TRACE interface as TRACE is expanding its processing to include Agency Debt. NSCC recommends that firms report Agency Debt directly to TRACE, away from the RTTM TRACE interface. However, this document describes to what degree the NSCC TRACE interface will support agency debt in relation to RTTM and TRACE processing. Also included in this document are instructions on how to designate trades as Primary transactions in the RTTM TRACE interface to meet future new FINRA requirements. This document provides an overview of interactive messaging for reporting over-the-counter (OTC) corporate bond trades to the Financial Industry Regulatory Authority (FINRA) using the National Securities Clearing Corporation s (NSCC) RTTM system. Note: Effective March 1, 2010, TRACE will be expanded to accept trade reports of corporate bond trades executed in the primary market, as well as agency debt trades executed in both the secondary and primary markets. NSCC has implemented Real-Time Trade Matching (RTTM) using a set of formats that allows their members to report fixed income trades executed by themselves or their correspondents for both settlement and regulatory reporting. RTTM is a real-time matching system that uses interactive messaging and RTTM Web for trade input and output. In order to bring reporting of corporate bond transactions into the fold, FINRA and NSCC have worked together to interface FINRA s Trade Reporting and Compliance Engine (TRACE) and RTTM. The TRACE/RTTM interface supports the reporting of over the counter corporate bond trades and agency debt, with limitations as noted below. Scope The Corporate Bond service offered to NSCC participants includes the ability to not only submit messages on Interdealer transactions to facilitate matching and settlement, but also to direct those messages to the FINRA via TRACE. Participants can submit one message for the purpose of Real-Time Trade Matching and regulatory price reporting of Interdealer trades. In addition, the RTTM interface supports the ability for participants to have their Customer trade reports passed on to TRACE for regulatory purposes. Agency debt trade submission via the NSCC TRACE interface will be accepted for Trade Reporting only. Agency debt should not be submitted for trade matching at NSCC. In addition, agency debt submission will only be accepted by NSCC via messaging in the MQ interface. Firms using RTTM Web for NSCC Corporate Bond trade input must use TRACE Web or TRACE CTCI to submit agency debt. 3

4 Reversals, Modifies, and Cancel functionality are not processed in the TRACE/RTTM interface. Audience This document was written for systems and development personnel, including managers, analysts and programmers. It is intended for NSCC members ( dealers ) that effect transactions in over the counter (OTC) corporate bonds and agency debt and for other parties that submit transaction data for reporting purposes. Dealers are categorized as participants of NSCC ( participants ), dealers that are not NSCC participants ( nonparticipants ), and vendors that support dealers. The document presumes readers are familiar with technical concepts and terms, and have a basic understanding of NSCC fixed income products and services as well as FINRA requirements and the difference in processing for each of the systems. This document will focus on the messages TRACE will accept from and return to RTTM, the conversion of certain fields from RTTM format into TRACE format, and valid TRACE regulatory data. In addition, examples will be provided of certain conditional trade reports normally submitted direct to TRACE, and how they should be submitted using RTTM format. It should be noted that as inter-dealer trade reports are submitted to RTTM for both trade-matching and regulatory purposes, participants are urged to refer to the FICC s Interactive Messaging: NSCC Participant Specifications for Matching Input and Output, Version 1.0 for full and detailed directions in completing the Interdealer trade report messages. The FICC specifications provide the data formats for regulatory use, and govern the requirements for automated comparison. The reader of this document should be familiar with, and rely on the FICC Specifications. Related Materials SWIFT The specifications for interactive messages supporting trade matching are based on ISO15022 SWIFT messages. Readers are strongly urged to refer to SWIFT user documentation to obtain a complete and comprehensive understanding of these message standards. Resources include: the "SWIFT User Handbook", "Standards Release Guide 2002 (September 2002)", and "Category 5 Securities Markets Message Usage Guidelines (September 2000)". SWIFT information (including message formats) can also be found on the Internet at RTTM For additional information regarding Real-Time Trade Matching, readers can refer to the various documentation such as specifications, message samples, updates and important messages published by the NSCC on the following website: 4

5 TRACE The Trade Reporting and Compliance Engine is the FINRA developed vehicle that facilitates the mandatory reporting of over the counter market transactions in eligible fixed income securities. More information regarding TRACE can be found at: CONTACTS TRACE Related Issues FINRA Operations at (866) TRACE/RTTM Message Specifications and other TRACE Issues Orlando Cortes at (212) FINRA Product Management at (866) FICC Message Specifications Melanie Sterman at (212) FICC Business Issues Ed Fanning at (212) Sean Delap at (212) FICC Testing Matters Aileen Rose at (212) DTCC Relationship Services (800) , option 5 5

6 TABLE OF CONTENTS 1. INTRODUCTION RTTM Role in Regulatory Reporting Submission Rules to Facilitate Regulatory Reporting FINRA TRACE Reporting TRACE Accepted Messages and Responses INTERACTIVE MESSAGE GUIDELINES MT515 Message Type MT509 Message Status TRACE/RTTM Message Flows Message Format Guidelines MT515 MESSAGE MT515 Message Specification MT515 Message Layout MT515 Field Specifications MT509 MESSAGE MT509 Message Specification MT509 Message Layout MT509 Field Specifications APPENDIX A: TRACE MESSAGE SAMPLES APPENDIX B: TRACE APPLICABLE CODES

7 1. INTRODUCTION 1.1 RTTM Role in Regulatory Reporting RTTM serves as a single conduit for participants to submit their fixed income trades for both trade matching and regulatory reporting. Participants therefore submit a single trade message to RTTM for both matching and real-time reporting of their street-side municipal bond trades to the MSRB and their over-the-counter (OTC) corporate bond trades to FINRA to comply with applicable price transparency requirements. Street-side agency debt trades can be submitted for real-time regulatory reporting to FINRA via the RTTM CMU system, but will not be subject to matching. While Customer information is not accepted into the RTTM matching application, interactive messages of customer trade activity received from participants will be forwarded to the appropriate regulator as specified by the participant. The MT515 layout supports input requirements for RTTM as well as for MSRB and FINRA customer and inter-dealer transactions; specific fields have been allocated for regulatory reporting. While RTTM will validate all matching-related fields, it will not validate that regulatory fields are populated, or that they are populated with the correct information. RTTM will, however, validate regulatory fields for correct format, to the extent that SWIFT messages can be created for the regulators based on participant supplied information, where applicable. Each regulatory body will be responsible for ensuring required information is submitted accurately by its members. 1.2 Submission Rules to Facilitate Regulatory Reporting The MT515 interactive message layout used by NSCC enables participants to submit one record for Corporate Bond trades that will facilitate matching and settlement as well as regulatory reporting. Participants will be able, via the MT515, to indicate whether the record should be sent to RTTM and/or the FINRA s TRACE system. Firms can use RTTM to report agency debt trades via messaging, but just for regulatory reporting only, not for trade matching. The header of the MT515 enables a participant to designate in the Receiver field whether the record should go to RTTM and, where applicable, the FINRA (NSCCTRRS), or whether the record should go to the FINRA only (NSCCREGO). In addition, the Transaction Processing narrative field (:70E::TPRO//) in the Confirmation Details block (CONFDET) contains a repeating field that is required to further tell the RTTM router where a record should be directed. Participants must indicate whether they want their trades to go to: 1. RTTM only (/DEST01) 2. FINRA only (/DEST03) This designation should be used for all agency debt trades. 3. RTTM and FINRA (/DEST01/DEST03) 7

8 These options should use the following Recipient in the message header: RTTM/Regulator Destination Header-Receiver (:70::TPRO//) 1 RTTM only /DEST01 NSCCTRRS 2 FINRA only /DEST03 NSCCREGO 3 RTTM and FINRA /DEST01/DEST03 NSCCTRRS It should be noted that where a Recipient in the message header does not agree with the Destinations reflected in the :70E::TPRO// field, the message will be rejected by RTTM for Inconsistent Recipient Information. Where an unknown value is found in the receiver field, the message will be rejected by RTTM for Unknown Target Application. It should be noted that if RTTM rejects a message for any reason, the message will not be forwarded to TRACE, therefore submitters must resend a message with an indication that the message should be forwarded for regulatory reporting. Note: Trades on Agency debt securities must always be submitted as /DEST03 only and NSCCREGO. 1.3 FINRA TRACE Reporting RTTM Interface NSCC reports utilize the SWIFT MT515 message format. This single message format will be used for both Interdealer and Customer trade reports. New trade reports are accepted for T- Date and T+N executions. TRACE will generate a reject or acceptance acknowledgment; the message format is the SWIFT MT509 message format. The MT509 accommodates both rejects and acceptances, allowing acceptances to contain the TRACE Control Number and rejects to contain TRACE reject codes as well as a TRACE Reject Reference Number. (Please note: certain rejected trade reports may be repaired via the TRACE Web application. Please refer to the TRACE User Web Guide found in for guidance on reject scan and repair functionality). Any trade rejected by TRACE should be corrected and resubmitted to TRACE as soon as possible by the reporting member in order to remain compliant. Please note: all trade reports and resubmission of rejected trade reports are validated for compliance with the reporting requirements outlined in NASD Rule 6200 Series. Time of execution will be validated against the time the report is received by TRACE. Echoes of the originally submitted trade report will not be contained in either a reject or acceptance MT509, as the MT509 format does not support this. MT509s will be generated and returned to NSCC, which will forward on to the originating submitter (see Section 4 of this document for the layout and field specifications of the TRACE generated MT509). In their interface with MSRB, NSCC sends both the initial trade report (Instruct Event Message) as well as the matched trade report to MSRB. In order to ensure timely dissemination of reports, TRACE will only accept the initial trade reports. TRACE will not 8

9 accept matched or other event messages generated by RTTM, and therefore will not generate any response (MT509) to such messages. In addition, TRACE will not accept reversals, cancels, modifies or DK s of previously submitted trade reports, however TRACE will reject and generate MT509s for such messages. RTTM will forward all records to TRACE as directed by NSCC participants. Trades submitted through the RTTM Interface will be subject to normal TRACE validations e.g., Price, CUSIP, Dates, etc. (please refer to the Trade Management section of the TRACE User Guide for further information on field validations). Trades submitted through RTTM will also continue to be eligible for dissemination as well as TRACE statistical calculations. Only those regulatory fields that are currently supported will be passed to FINRA. Where a participant submits regulatory-only fields on a trade record, not all of these fields will necessarily be applicable to FINRA. FINRA members will also continue to have the ability to submit their trades for reporting (including all adjustments) directly to the FINRA TRACE system. Member firms are reminded that they must report transactions to TRACE in securities that are "TRACE-eligible securities," such as unlisted convertible debt, unlisted equity-linked notes and similar debt securities. FINRA also reminds firms that only unlisted convertible debt and unlisted equity-linked notes are treated as debt for purposes of trade reporting; convertible debt and equity-linked notes that are listed on a national securities exchange must be reported to the appropriate equity trade reporting facility. FINRA will accept trades of unlisted convertible debt and unlisted equity-linked notes via the RTTM/TRACE Interface. Note: effective March 1, 2010, TRACE will accept trade reports of OTC corporate bond trades executed in the primary market. TRACE will also accept trade reports of OTC agency debt trades executed in both the primary and secondary markets. Certain primary market trades List or Fixed Offering Price or Takedown transactions are reportable by close of business of the following business day of the execution (T+1). Primary market trades executed at a market price are subject to 15-minute reporting. Refer to Regulatory Notice ( for more guidance. The TRACE/RTTM interface will support these changes to a limited degree - Interdealer trades, submitted with a MT 515, must be coded with a Destination Code of 03 (Reporting Only). These trades are not eligible for matching in the Corporate, Municipal, UIT (CMU) RTTM system (nor should this impact agency trades that firms are currently submitting to the Government Securities Division (GSD) of FICC. Firms currently submitting trades in agency debt to GSD should continue to do so for matching and clearance purposes. The NSCC RTTM TRACE interface may only be used to REPORT agency trades to TRACE and is not to be used for trade matching in NSCC s RTTM system.) RTTM Web does not support Regulatory Only submissions of interdealer trades. Therefore, firms utilizing RTTM Web to submit their Corporate Bonds to TRACE must submit their agency debt trades directly to TRACE. A Contra participant number must be submitted on all CMU RTTM Interdealer trades. For Agency trades where the Contra Clearing firm may not be an NSCC member, firms can enter 9999 and the trade will be passed to TRACE. FINRA utilizes the firm s MPID and 9

10 will ignore the Contra Clearing #. If you do not enter a Contra Clearing # the trade will be rejected by the RTTM pipeline. Only Final Money trades should be submitted via the CMU RTTM TRACE interface. In a very rare situation where Final Money cannot be calculated (possibly on a WI security), you will need to report that trade directly to TRACE. 10

11 1.4 TRACE Accepted Messages and Responses The following matrix illustrates the types of MT515s TRACE will receive via the RTTM Interface and the resulting action for each message: TRACE receives the following MT515: Participant generated Interdealer or Customer INSTRUCT Participant generated Interdealer or Customer INSTRUCT Reversal Participant generated Interdealer or Customer MODIFY Participant generated Interdealer or Customer CANCEL If the trade report passes TRACE validations: TRACE will return an MT509 with the following: :25D::AFFM//AFFI :20C::TRRF// containing the TRACE Control Number NOT APPLICABLE NOT APPLICABLE NOT APPLICABLE If the trade report fails TRACE validations: TRACE will return an MT509 with the following: :25D::AFFM//NAFI :20C::TRRF// containing the TRACE Reject Reference Number :24B::NAFI/ containing the TRACE Reject Code :70D::REAS/ containing the Regulatory Status Code and Reject Error Text TRACE will return an MT509 with the following: :25D::AFFM//NAFI :24B::NAFI containing the TRACE Error Code T546 :70D::REAS containing the Regulatory Status Code UNSA and Reject Error Text of FUNCTION NOT AVAILABLE PLEASE USE TRACE WEBSITE. TRACE will return an MT509 with the following: :25D::AFFM//NAFI :24B::NAFI containing the TRACE Error Code T546 :70D::REAS containing the Regulatory Status Code UNSA and Reject Error Text of FUNCTION NOT AVAILABLE PLEASE USE TRACE WEBSITE. TRACE will return an MT509 with the following: :25D::AFFM//NAFI :24B::NAFI containing the TRACE Error Code T546 :70D::REAS containing the Regulatory Status Code UNSA and Reject Error Text of FUNCTION NOT AVAILABLE PLEASE USE TRACE WEBSITE. Participant generated DK NOT APPLICABLE TRACE will return an MT509 with the following: :25D::AFFM//NAFI :24B::NAFI containing the TRACE Error Code T547 :70D::REAS containing the Regulatory Status Code UNSA and Reject Error Text of FUNCTION NOT AVAILABLE. Rejects of Reversals, Modifies, Cancels and DKs will not generate a TRACE Reject Reference Number and the corresponding MT509s will not contain a :20C::TRRF field. FINRA requires all new trade reports of secondary market transactions to be reported within a timeframe immediately after execution of the trade. Currently, this timeframe is set to 15 minutes (possible future reductions in the reporting timeframe may occur, subject to SEC approval. Such 11

12 reductions would be announced in Trade Reporting Notices published on the FINRA website). Trades received by TRACE after the required timeframe can be accepted by TRACE, pending successful trade detail validations, and the submitter will be advised that the report was identified as a late report (.SLD in TRACE terminology). Primary market transactions that are List or Fixed Offering Price or Takedown transactions must be reported no later than TRACE system close (6:30pm ET) of the following business day after the security is established for trade reporting (i.e. TRACE Trade Report Effective Date), or T+1. Primary market trades executed at market prices must be reported within 15 minutes of execution. In addition, trades can be executed and reported after market hours. The after market hours period typically starts at 5:15pm ET on a normal business day, or earlier on early market closes, and ends at 6:30pm ET (TRACE system close). Trades received by TRACE during the after market hours period can be accepted by TRACE, pending successful trade detail validations, and the submitter will be advised that the report was identified as an after market hours report (.A in TRACE terminology). On a Participant Generated Interdealer or Customer Instruct that passes TRACE validations but is: Received late Received after market hours Received late during after market hours TRACE will accept the trade report but will generate an MT509 containing the following: :25D::AFFM//NAFI :20C::TRRF containing the TRACE Control Number :24B::NAFI containing the TRACE Error Code N01S :70D::REAS containing the Regulatory Status Code QUES and Error Text of TRADE REPORTED LATE. :25D::AFFM//NAFI :20C::TRRF containing the TRACE Control Number :24B::NAFI containing the TRACE Error Code Q01A :70D::REAS containing the Regulatory Status Code QUES and Error Text of TRADE REPORTED AFTER MARKET HOURS. :25D::AFFM//NAFI :20C::TRRF containing the TRACE Control Number :24B::NAFI containing the TRACE Error Code N02S :70D::REAS containing the Regulatory Status Code QUES and Error Text of TRADE REPORTED LATE AND AFTER MARKET HOURS. Although TRACE will assign a regulatory status (RSTA) of questionable (QUES), accepted late and after market hour trade reports do not require resubmission. All messages submitted by participants that are forwarded to TRACE will be processed and TRACE will generate and return a response back to the submitter. All RTTM system generated event messages forwarded to TRACE will not be subject to normal TRACE processing, and responses will not be generated for those messages. Trade reports rejected by TRACE should be resubmitted with the corrected information as soon as possible in order to remain compliant with the FINRA required reporting timeframe. Care should be taken to ensure the proper destination of DEST03 (FINRA only) on the resubmission if your trade report was rejected by TRACE only. 12

13 Certain rejected trade reports may also be repaired using the TRACE Website. Rejects of MT515 message types not supported by TRACE (i.e., Modifies, Cancels and Reversals) cannot be repaired using the Reject Repair function. Instead, these messages can be resubmitted in its entirety using the TRACE Website Trade Report function. DKs are not accepted by TRACE. Please consult the TRACE User Guide for additional information on these processes. 13

14 2. INTERACTIVE MESSAGE GUIDELINES For a better understanding of the message formats as they apply to the MT515 and MT509, please refer to the NSCC Participant Specifications for Matching Input and Output Version 1.0 ). This section provides an overview of the MT515 and MT509 as it relates to TRACE in the RTTM Interface. 2.1 MT515 Message Type Dealers and service bureaus can use the SWIFT ISO MT515 message to submit trades to TRACE via RTTM. Field 22F PROC in the Confirmation Details (CONFDET) block will enable the submitter to indicate to RTTM the type of record being sent. TRACE will only accept new trade report MT515 messages. TRACE will support the following MT515 message type: Message Type 1. Instruct Message (:22F::PROC/GSCC/INST) Usage Used to submit trade details for trades executed by participants or approved Locked-in submitters, and to report trades with customers effected by dealers. This message will support: 1) all fields required to effect trade matching on Interdealer trades; 2) certain other SWIFT mandatory fields; and 3) all required regulatory reporting fields. TRACE will NOT support Cancel, Modify or DK functionality, and will reject such messages forwarded to TRACE. {Please refer to section 1.4 of this document for TRACE responses to inbound MT515s.} 2.2 MT509 Message Status The SWIFT MT509 Message is specified as a Trade Status Message and will be used by FINRA to convey the status of certain input messages that have been submitted to TRACE. The MT509 message does not contain full trade details, but rather provides the trade status along with the full set of reference numbers to enable the participant to identify the trade or record submitted. TRACE will support the following MT509 trade statuses: St 1. Trade Input Affirmed (Accepted) (:25D::AFFM//AFFI) 2. Trade Input Not Affirmed (Rejected) (:25D::AFFM//NAFI) Sent to the trade submitter to acknowledge that its trade has been validated and accepted by TRACE. Sent to the trade submitter to indicate that its trade has been rejected by TRACE as part of the validation process. The reason for the rejection will also be indicated on the message (:24B::NAFI in the Reason 14

15 (REAS) Block). Important Note: Trades reported late and/or during after market hours and passing TRACE validation will receive the AFFM//NAFI trade status on the resulting MT509, however these trades are not considered to be rejected trades and therefore the submitter is not required to take further action. Status Message Usage For a full list of applicable TRACE reject codes and reasons, please refer to Appendix B of this document. 2.3 TRACE/RTTM Message Flows A typical message flow for an Interdealer trade accepted by TRACE via RTTM is depicted below. NSCC Participant ABCD Step 1 NSCC will validate for SWIFT compliance and RTTM application validation. If message passes validation, it will be forwarded to TRACE. Step 2 MT515 Instruct (DEST01/DEST03) MT509 Acknowledgement NSCC/RTTM NSCC will forward the MT509 to the participant MT515 (NSCC will add timestamp and RTTM Reference Number [TID]) MT509 AFFM//AFFI Acceptance will contain TRACE Control Number Step 3 The incoming MT515 message is converted into CTCI format and processed through TRACE for normal trade report validations. TRACE The trade passes validation and an acceptance message is created in MT509 format. Step 5 Step 4 Message Flow Explanation: Step 1: NSCC Participant ABCD submits an MT515 to NSCC, advising report should be forwarded to FINRA (DEST01/DEST03) for a Corporate Bond trade (agency debt would always be coded with Dest 03). Step 2: NSCC (RTTM) validates for SWIFT compliance as well as RTTM application validations before forwarding the MT515 to TRACE, adding date/time of receipt and their reference number (TID). If RTTM rejects an MT515 for non-swift compliance, it will not be forwarded to FINRA for processing. Step 3: The MT515 is received and converted into TRACE-readable format, where it is further subjected to normal TRACE validations. If the trade passes validation, a TRACE Control number is assigned. 15

16 Step 4: TRACE will generate and send an acknowledgment in MT509 format to the NSCC, containing the TRACE Control Number and the status code AFFM//AFFI on accepted trade reports. Step 5: NSCC will look to update the trade record and forward the MT509 to Participant ABCD. 16

17 A typical message flow for a Customer TRACE only trade accepted by TRACE via RTTM is depicted below. NSCC Participant ABCD Step 1 NSCC will validate for SWIFT compliance. If message passes validation, Step 2 it will be forwarded to TRACE. MT515 Instruct (DEST03) MT509 Acknowledgement NSCC/RTTM NSCC will forward the MT509 to the participant MT515 (NSCC will add timestamp) MT509 AFFM//AFFI Acceptance will contain TRACE Control Number Step 3 The incoming MT515 message is converted into CTCI format and processed through TRACE for normal trade report validations. TRACE The trade passes validation and an acceptance message is created in MT509 format. Step 5 Step 4 Message Flow Explanation: Step 1: NSCC Participant ABCD submits an MT515 to NSCC, advising report should be forwarded to FINRA (/DEST03) Step 2: NSCC (RTTM) validates for SWIFT compliance only before forwarding the MT515 to TRACE. If RTTM rejects an MT515 for non-swift compliance, it will not be forwarded to FINRA for processing. Step 3: The MT515 is received and converted into TRACE-readable format, where it is further subjected to normal TRACE validations. If the trade passes validation, a TRACE Control number is assigned. Step 4: TRACE will generate and send an acknowledgment in MT509 format to the NSCC, containing the TRACE Control Number and the status code AFFM//AFFI on accepted trade reports. Step 5: NSCC will look to update the trade record and forward the MT509 to Participant ABCD. 17

18 A typical message flow for an Interdealer trade rejected by TRACE via RTTM is depicted below. NSCC Participant ABCD Step 1 NSCC will validate for SWIFT compliance and RTTM application validation. If message passes validation, it will be forwarded to TRACE. Step 2 MT515 Instruct (DEST01/DEST03) MT509 Reject Acknowledgment NSCC/RTTM NSCC will forward the MT509 to the participant MT515 (NSCC will add timestamp and RTTM Reference Number [TID]) Step 3 The incoming MT515 message is converted into CTCI format and processed through TRACE for normal trade report validations. TRACE The trade fails validation and a reject message is created in MT509 AFFM//NAFI MT509 format. Reject will contain TRACE Reject Reference Number Step 5 Step 4 Message Flow Explanation: Step 1: NSCC Participant ABCD submits an MT515 to NSCC, advising report should be forwarded to FINRA (DEST01/DEST03) for a Corporate Bond trade (agency debt would always be coded Dest 03). Step 2: NSCC (RTTM) validates for SWIFT compliance as well as RTTM application validations before forwarding the MT515 to TRACE, adding date/time of receipt and their reference number (TID). If RTTM rejects an MT515 for non-swift compliance, it will not be forwarded to FINRA for processing. Step 3: The MT515 is received and converted into TRACE-readable format, where it is further subjected to normal TRACE validations. If the trade fails validation, a TRACE Reject Reference Number is assigned. Step 4: TRACE will generate and send a reject acknowledgment in MT509 format to the NSCC, containing the TRACE Reject Reference Number and the status code AFFM//NAFI on rejected trade reports. Step 5: NSCC will look to update the trade record and forward the MT509 to Participant ABCD. 18

19 A typical message flow for a Customer TRACE only trade rejected by TRACE via RTTM is depicted below. NSCC Participant ABCD Step 1 NSCC will validate for SWIFT compliance. If message passes validation, Step 2 it will be forwarded to TRACE. MT515 Instruct (DEST03) MT509 Reject Acknowledgment NSCC/RTTM NSCC will forward the MT509 to the participant MT515 (NSCC will add timestamp) Step 3 The incoming MT515 message is converted into CTCI format and processed through TRACE for normal trade report validations. TRACE The trade fails validation and a reject message is created in MT509 AFFM//NAFI MT509 format. Reject will contain TRACE Reject Reference Number Step 5 Step 4 Message Flow Explanation: Step 1: NSCC Participant ABCD submits an MT515 to NSCC, advising report should be forwarded to FINRA (/DEST03). Step 2: NSCC (RTTM) validates for SWIFT compliance only before forwarding the MT515 to TRACE. If RTTM rejects an MT515 for non-swift compliance, it will not be forwarded to FINRA for processing. Step 3: The MT515 is received and converted into TRACE-readable format, where it is further subjected to normal TRACE validations. If the trade fails validation, a TRACE Reject Reference Number is assigned. Step 4: TRACE will generate and send a reject acknowledgment in MT509 format to the NSCC, containing the TRACE Reject Reference Number and the status code AFFM//NAFI on rejected trade reports. Step 5: NSCC will look to update the trade record and forward the MT509 to Participant ABCD. 19

20 For Participants that have authorization to access the FINRA TRACE web application: Accepted trade reports can be viewed from the Trade Scan function in TRACE. Rejected trade reports can be viewed and repaired, in certain cases, from the Reject Review function (please refer to the TRACE User Guide for details). Reports can be identified by either their assigned Control Number or Reject Reference Number. Accepted trade reports may be eligible for real-time dissemination. TRACE will not utilize MT518 messaging to advise contra parties reported on MT515s. Contra parties may be notified of trades alleged against them via TRACE proprietary messaging. Agency trades cannot be submitted to TRACE via RTTM web. 2.4 Message Format Guidelines For formatting rules and conventions pertaining to the NSCC MT515 and MT509 messages, please refer to the NSCC Participant Specifications for Matching Input and Output Version 1.0. Customer trade reports should also follow the formatting rules outlined in the NSCC Specifications. TRACE will support the formatting for inbound MT515s and outbound MT509s as specified in that document. Chapter 4 of this document will detail the fields applicable to TRACE reporting for inbound MT515s as well as the layout FINRA will employ for TRACE generated MT509s. 20

21 3. MT515 Message 3.1 MT515 Message Specification MT515 message format supports both Interdealer and Customer trade reports. The MT515 general format specification can be found in the NSCC Participant Specifications for Matching Input and Output. It is important to follow the NSCC specifications for Interdealer trades in order to ensure your trades are successfully processed for trade matching. MT515 Message Layout (Please note TRACE will not employ all the Block/Qualifiers or Sub qualifier/options contained in the following layout. Refer to section 3.2 for the values applicable to TRACE) Tag Block/ Qualifier Sub qualifier/ Options Field Description Data Field Format Message Header Password 12!c Sender 8!c Message Type 3!n/3!n/4!c Receiver 8!c :16R: GENL Mandatory Block Start :20C: :SEME// Sender s Reference for this Msg 16x :23G: NEWM Message Function = New or 4!c CANC Cancel :98C: :PREP// Preparation Date/Time YYYYMMDDHHMMSS :22F: :TRTR/ GSCC/CASH Bilateral Trade Indicator or 4!c GSCC/TRLK Locked-in Trade Indicator or GSCC/TRDC Demand Trade Indicator :16R: LINK Mandatory :20C: :MAST// Master Reference Number (External Reference) :16S: LINK :16R: LINK :20C: :PREV// Previous Reference Number (Previous External Reference) :16S: LINK :16R: LINK :20C: :LIST// RTTM Assigned Reference (TID) 16x :16S: LINK :16R: LINK :20C: :BASK// ABS Turnaround Number 16x 16x 16x 21

22 Tag Block/ Qualifier Sub qualifier/ Options Field Description Data Field Format :16S: LINK :16R: LINK :20C: :TRRF// Regulator Control Number 16x :16S: LINK :16R: LINK :20C: :COMM// Match Control Number 16x :16S: LINK :16S: GENL Block End :16R: CONFDET Mandatory Block Start :98C: :TRAD// Trade Date & Time YYYYMMDDHHMMSS :98A: :SETT// Settlement Date or YYYYMMDD :98B: :SETT// WISS Settlement to be completed when 4!c the security is issued :90A: :DEAL/ /PRCT/ Deal Price Percentage or 15d /YIEL/ Yield :94B: :TRAD/ GSCC/NYCP Place of Trade Market of 4!c Execution NYSE Corporate or GSCC/OTCP Over-the-Counter Corporate or GSCC/OTMU Over-the-Counter Municipal or GSCC/OTUI Over-the-Counter Unit Investment Trust :19A: :SETT/ /USD Settlement Amount 15d :22H: :BUSE/ /BUYI Trade Type Buy or 4!c /SELL Sell :22F: :PRIC/ GSCC/WGTP Type of Price Weighted Price 4!c :22F: :PROC/ GSCC/INST MT515 Record Type Instruct or 4!c GSCC/CANC Cancel or GSCC/MDFC Modify or GSCC/TDDK DK :22F: :TTCO/ GSCC/TSQS Trade Type/Target Indicator 4!c QSR Trade or GSCC/TSAB ABS Trade or GSCC/TTQS Target QSR Trade or GSCC/TTAB Target ABS Trade :22H: :PAYM/ /APMT Against Payment Indicator 4!c :16R: CONFPRTY Mandatory :95R: :BUYR/ GSCC/PART Party = Buyer 34x :20C: :PROC// Buyer (Contra) X-ref 16x :70C: :PACO/ /GSCC Participant Contact Narrative (4*35x) /TDID Buyer (Contra) Trader ID 20c 22

23 Tag Block/ Qualifier Sub qualifier/ Options Field Description /BRCH Branch Sequence Number 3!x4!x :70E: :DECL/ /GSCC Narrative/ Additional Reference (10*35x) Numbers/ Information /CORR Party = Buyer s Correspondent 5c firm /COCO Party = Buyer s Correspondent of 5c the Correspondent :22F: :TRCA/ /AGEN Capacity Indicator Acting as 4!a Agent Indicator or /PRIN Acting as Principal Indicator :16S: CONFPRTY :16R: CONFPRTY Mandatory :95R: :SELL/ GSCC/PART Party = Seller 34x :20C: :PROC// Seller (Contra) X-ref 16x :70C: :PACO/ /GSCC Participant Contact Narrative (4*35x) /TDID Seller (Contra) Trader ID 20c /BRCH Branch Sequence Number 3!x4!x :70E: :DECL/ /GSCC Narrative/ Additional Reference (10*35x) Numbers/ Information /CORR Party = Seller s Correspondent 5c Firm /COCO Party = Seller s Correspondent of 5c the Correspondent :22F: :TRCA/ /AGEN Capacity Indicator Acting as 4!a Agent Indicator or /PRIN Acting as Principal Indicator :16S: CONFPRTY Data Field Format :36B: :CONF/ /FAMT/ Quantity as Face Amount (Par) 15d or /UNIT/ Quantity as Units / Shares :35B: /US/ Security Identifier CUSIP 4 * 35x :70E: :TPRO/ /GSCC Trade Instruction Processing (10*35x) Narrative /DEST Destination Indicator 2!c /ITYP Issue Type 2!c /ORDT Order Time 6!n (HHMMSS) /SDAD Settlement Date Adjustment 4n /RVSL Trade Reversal Indicator 4!c /SPXR Special Price Reason Code 4!c /POVR Price Override Option 4!c /RCTL Reversal Control Number 16x /ATME ATS Identifier 6c 23

24 Tag Block/ Qualifier Sub qualifier/ Options Field Description /YIEL Yield [N]15d :16S: CONFDET Block End :16R: SETDET Optional Block Start :22F: :SETR/ /RPTO Settlement Indicator Reportingonly or GSCC/STRD Settlement Type Indicator Special Trade or GSCC/TAAA GSCC/XINT GSCC/CALL GSCC/BEAR GSCC/REGD GSCC/CPRO Subject to AAA or Ex Interest or Called or Bearer Only or Registered Only or Comparison Only :16R: AMT Optional Block Start Data Field Format :19A: :SPCN/ /USD Special Concessions or [N]USD15d :EXEC/ /USD Executing Broker Commission USD15d :16S: AMT Block End :16R: AMT Optional Block Start :19A: :ACRU/ /USD Accrued Interest Amount USD15d :16S: AMT Block End :16S: SETDET Block End 4!c 4!c :16R: OTHRPRTY Optional Block Start :95Q: :MEOR// Originator of message (if other than the Sender) :16S: OTHRPRTY Block End 6c 3.2 MT515 Field Specifications The following defines the fields of an MT515 Instruct for a Customer trade and how TRACE processes these fields. Where Interdealer trades may differ, it shall be noted below. For a detailed description of all MT515 fields accepted by RTTM please refer to the NSCC Participant Specifications for Matching Input and Output. Message Each Message must contain a message header. All header fields are mandatory fixed Header format with trailing blanks, where required. Password The password assigned by FICC to senders will not be forwarded to TRACE. Sender Participant ID, TRACE will return MT509s to the Sender of an MT515. Message Type The first three characters indicate to the recipient the message type (515); the second three positions reflect the version of the message interface (currently always 24

25 Receiver GENL 20C 23G 98C 22F LINK 20C CONFDET 000). The last 4 characters indicate the issuer code to be used in the message (always GSCC ). NSCCTRRS (NSCC Trade Registration and Reconciliation System) will always be the recipient of the MT515 messages sent to RTTM-only, or sent to both RTTM and a regulator (TRACE). NSCCREGO (NSCC Trade Reporting Regulatory-Only) will be the only recipient of the MT515 (Regulatory-only) messages. All Customer trades should be directed to NSCCREGO. All agency debt trades, both interdealer and customer, should be directed to NSCCREGO. This Mandatory block provides general information regarding the message. It appears only once in a trade contract. Sender Message Reference SEME// This field contains the sender s message reference number. It is mandatory and must contain a unique number to unambiguously identify each message sent to RTTM/TRACE. (This is a communications message number, not a trade number.) It is suggested that participants use a number that includes a date followed by either a timestamp or a sequence number. In this way uniqueness can be ensured. The SEME submitted will be returned on TRACE generated MT509s, returned under the qualifier RELA. e.g., :20C::SEME// Function of the Message NEWM For new trades (Instructs), this is the only option accepted by TRACE. e.g., :23G:NEWM Preparation Date and Time PREP// - This RTTM mandatory field contains the date and time the message sent to RTTM was prepared. e.g., :98C::PREP// Trade Transaction Type Indicator (TRTR) TRACE will only accept the qualifier options CASH (Bilateral) and TRLK (Lockedin). e.g., :22F::TRTR/GSCC/CASH or :22F::TRTR/GSCC/TRLK The LINK Block can be repeated for the various reference qualifiers required on a Trade Contract or report. It is intended to provide the required information to identify the trade. Each reference number must be enclosed within a Start Link Block () and End Link Block (). Each LINK repeating subsequence is within the GENL Block. At least one LINK sequence is required on the MT515 message. Reference The Reference Numbers provided by the participant must contain Upper Case and alphanumeric characters and must not contain symbols or hyphens. As indicated above, each reference number must be enclosed in a LINK Start and End block. The following are the only reference numbers applicable to TRACE Instructs: MAST// Master Reference Number TRACE will apply this reference number into the TRACE User Reference Number (visible on the TRACE web application Trade Scans). e.g., :20C::MAST//PARTREF1 The Mandatory CONFDET (Confirmation Details) block appears only once in a 25

26 98C 98A 98B 90A 94B 19A 22H Trade Contract or report. It contains Trade and Confirming Party Details. Trade Date TRAD// This mandatory field is used on all messages to specify Trade Date and Trade Time. (The C format for this (98) tag indicates a date/time format of YYYYMMDDHHMMSS.) Time of trade should be included to the second. TRACE will only accept T-date and T+n reports of up to 365 days. e.g., :98C::TRAD// Settlement Date This mandatory field is used on all MT515 messages. One of the following options must appear for this field: SETT// - This field is used on all messages to specify settlement date. Required on all regular way Interdealer and Customer trades. SETT//WISS - This field is used on all New Issue trades where the settlement date is not known (when-issued), and no final money is reflected on the trade. (This is the B format of tag (98).) When WISS is submitted, TRACE shall validate that the bond is in a When-Issued state. WISS will only be reported on Customer trade reports of WI bonds. Interdealer trade reports will always report a settlement amount, and will therefore contain a settlement date (98A::SETT//YYYYMMDD) in this field. e.g., :98C::TRAD// Deal Price This field is reflected on all messages. It contains the Execution Price Type and Price. Price is required where no final money is provided (applicable only to NI trades). Only one Tag 90A is allowed per trade contract. The price is in SWIFT Standard format, which is left justified, with commas removed, and a comma used instead of a decimal. The following price types may be specified: DEAL//PRCT/ This qualifier/option is used for dollar prices. For Customer trades, the dollar price should be reflected. Interdealer trades must provide a settlement amount (:19A::SETT//) and should reflect a value of zero 0, in the DEAL//PRCT/ field. DEAL//YIEL/ This qualifier/option is not applicable on trades reported to TRACE. Yield must be reported in the trade instruction processing narrative (:70E::TPRO) field. Note: Effective November , Yield shall only be reported for trades executed prior to November 3, Yield is not required for trades executed on or after November e.g., :90A::DEAL//PRCT/99,625 Place of Trade Market of Execution (TRAD) TRAD/GSCC/OTCP (Over-the-Counter Corporate) - All reportable trades in OTC corporate bonds as well as agency debt securities should contain this qualifier. TRACE will reject any trades marked with any other Market of Execution. e.g., :94B::TRAD/GSCC/OTCP Settlement Amount SETT// - This field is used to specify the settlement amount. It may be omitted on Customer trades, but is required on all regular way Interdealer trades. e.g., :19A::SETT//USD ,5 Trade Type Indicator (BUSE) Required on all MT515 messages. There are two allowable values for the BUSE 26

27 qualifier: BUSE//BUYI This qualifier/option indicates that the record submitted is a buy from the dealer s perspective, i.e., that the dealer reporting the trade bought securities. 22F 22F 22F BUSE//SELL This qualifier/option indicates that the record submitted is a sell from the dealer s perspective, i.e., that the dealer reporting the trade sold securities. e.g., :22H::BUSE//BUYI Type of Price Weighted Price PRIC/GSCC/WGTP regulatory field Used on the MT515 Instruct message to indicate the price of the trade was based on the weighted average of previous transactions. TRACE will display trades marked as WGTP with the trade modifier.w on TRACE Trade Scans. e.g., :22F::PRIC/GSCC/WGTP Processing Indicator (PROC) PROC/GSCC/INST This qualifier/option indicates that the MT515 is an INSTRUCT record. TRACE will not accept other options submitted. (Please refer to the matrix in section 1.4 for TRACE responses to submissions). e.g., :22F::PROC/GSCC/INST Trade Type / Target Indicator (TTCO) TRACE accepts the following options used to identify QSR trade submission as well as trades targeting QSR trades: TTCO/GSCC/TSQS This qualifier/option indicates that this is a QSR Trade Submission. This option applies to all QSR submitted MT515 messages. TTCO/GSCC/TTQS This qualifier/option indicates that the trade is targeting a QSR trade. This option applies to all Target QSR MT515 messages. 22H 36B TRACE will not accept other Options submitted. e.g., :22F::TTCO/GSCC/TSQS Payment Indicator (PAYM) This Payment Indicator field is mandatory for the MT515 message. All trades must provide the following qualifier: PAYM//APMT Indicates the trade will settle against payment. e.g., :22H::PAYM//APMT Quantity of Securities (CONF) ( Par ) This field is mandatory for all MT515 messages. The quantity of the financial instrument is in SWIFT Standard Format, which is left justified, with commas removed, and a comma used instead of a decimal. Valid options are as follows: CONF//FAMT/ The option FAMT indicates the face amount (par), and should be used on all corporate bond and agency debt trade records. The par amount is entered in dollars. The SWIFT standard requires the use of a comma instead of a decimal, with no punctuation between groups of three digits. For example, par of one million dollars is entered as ,. Effective August 4, 2008, TRACE will allow trades of equity-linked notes that trade in shares as units. For such ELNs that trade in shares rather than par value of 1000, 27

28 35B 70E the face amount reported should reflect the total number of shares traded, for example a trade of 250 shares would be reported with as CONF//FAMT/250, The Settlement Amount reported should reflect the executed dollar price per share. e.g., :36B::CONF//FAMT/ , Identification of Security This field is mandatory. The security involved is identified in the US by specifying the ISO country identifier ( /US/ ), followed by the CUSIP number. e.g., :35B:/US/549463AD9 Trade Instruction Processing Narrative (TPRO) TPRO//GSCC Denotes narrative trade instruction processing information related to RTTM. The following options are applicable to TRACE: /DEST Used to specify the destination of the message as RTTM (01), and/or FINRA (03). Specify /DEST01/DEST03 for all MT515 Instructs requiring matching/processing by RTTM as well as forwarding to FINRA for regulatory purposes. Specify /DEST03 to indicate that the Instruct is not subject to matching and should be forwarded to the FINRA. Please note: All agency debt trades reported to TRACE should be marked DEST03 only as the NSCC CMU system does not match/settle agency debt trades. /SPXR regulatory field The Special Price Reason Code field is used for trades executed at a price different from the prevailing market price. In addition, identification of Primary market trades subject to T+1 reporting (as defined in Sections 1.3 and 1.4 of this document) is performed by using the designated Special Price Reason Code. Please see Appendix B for a table of Special Price Reason Codes accepted by TRACE. /POVR regulatory field The Price Override Option is used for resubmission of a previously rejected regulator trade to indicate that the entered price is valid although it may fall outside the reasonability check. Resubmitted trades should be directed to TRACE only (/DEST03). /YIEL regulatory field This sub qualifier should be used on all Customer and Interdealer trade reports in order to report the yield. Effective November 3, 2008, yield is no longer required on trades executed on or after November Firms reporting As-Of trades where the execution was prior to November are required to report yield unless the reported bond was traded flat or is a Pay In Kind ( PIK ), Perpetual, Floating Rate Note, Index-Linked bond, or any other security type identified by FINRA that has unknown variables. For trades executed prior to November , the reportable yield would be the lower of Yield To Call (YTC) or Yield To Maturity (YTM), and should be reported to at least three decimal places of accuracy. For trade reports that were executed on or after November , TRACE will calculate and disseminate yield. CONFPRTY Note: Submission of /RVSL forwarded to FINRA will be rejected by TRACE as TRACE does not support submission of Reversals. TRACE will not process any other options submitted in this field. e.g.:70e::tpro//gscc/dest03/spxrr004/povr/yiel3,5 The Mandatory Confirming Party Block must be repeated for each party to a trade. Each party specified must be enclosed within a Start Party block 28