|
MSRB NOTICE 2003-39 (September 23, 2003)
|
|
The MSRB has published Version 1.1 of the Specifications for Real-time Reporting of Municipal Securities Transactions. This is a minor revision of Version 1.0, which appeared in June 2003. Click here to access Version 1.1.
DESCRIPTION OF CHANGES Directing customer and IDRO trade messages to RTTM and RTRS To provide information on RTTM Web to NSCC participants about the regulatory status of all reported trades, RTTM will store information on customer and IDRO trades reported to it by participants, as well as inter-dealer trades. A participant may store on RTTM and RTRS both its own and its correspondent’s trades by directing the trades to both the NSCC and the MSRB (/DEST01/DEST02). It is the participant’s option whether to direct customer and IDRO trade messages to RTTM for storage and display on RTTM Web. However, if a customer or IDRO trade is initially reported to RTRS, later modifications may be made to these trades only via RTRS, and RTTM will not reflect the trades. If a customer or IDRO trade is initially reported to RTTM as well as to RTRS and later modified or canceled, only changes made via RTTM by the participant will be reflected on RTTM. It should be understood that if the participant modifies a customer or IDRO trade by input directly into RTRS, the regulatory data reflected on RTTM may not correspond to the modification depicted in RTRS. (Participants may make input directly into RTRS either by sending a message to RTRS only (DEST02), or by input to the RTRS Web Interface.) A similar caution applies to trades changed by a non-participant via the RTRS Web Interface: the regulatory status reflected on RTTM to the participant will not reflect changes made by the non-participant in RTRS. Section 1.6 of the RTRS Specification, “How Trade Messages Can be Distinguished,” therefore now reads: Customer Trade
Directing changes to street trades that affect only regulatory data Reports of inter-dealer (street) trades will be entered into RTTM by the NSCC participant and forwarded by RTTM to RTRS. If changes are made only to the regulatory data elements – for example, to capacity or time of trade – the same logic just described for customer and IDRO trades will apply to the street trade record: Only changes made via RTTM will be reflected on RTTM RTTM will reject changes to trades it does not know If a trade was not initially reported to RTTM or if it has been purged from RTTM (see below), RTTM will reject any Modification or Cancel message directed to RTTM. RTTM will reject such messages if they have either of the following values:
A message rejected by RTTM will not be processed by RTRS. If the trade is not in RTTM, a Modification or Cancel message intended for RTRS must be directed to RTRS (DEST 02) only. RTTM will notify participants when their trades are purged from RTTM To help participants know where to direct changes to trades that were originally sent to RTTM, RTTM will send deletion messages to participants when trades have been or will be “purged” from the RTTM database. For matched inter-dealer trades, RTTM will send an MT518 settlement disposition record that includes the delivery date and RTTM will purge the trade record at end-of-day on the delivery date. For customer and IDRO trades, RTTM will send an MT509 “delete uncompared” record on the purge date. For purge dates of unmatched inter-dealer trades, see Appendix C of NSCC’s May 30, 2003 New Service Bulletin, “NSCC Real-Time Matching for Corporates, Municipals and UITs” (on www.ficc.com/cmu/other.docs/cmu_new_svc_bulletin.pdf). Retention time in RTTM for customer and IDRO trades If the settlement date is known for a customer or IDRO trade, RTTM will purge it from its database on the later of the settlement date or submission date plus 3. If the settlement date is unknown or extended for a when-issued customer or IDRO trade, RTTM will purge the trade 20 business days after it was submitted. Report literal “IDRO” on IDRO trades The trade reporting procedure for inter-dealer regulatory-only (IDRO) trades is changed. An IDRO is a report that a correspondent has sold from or bought into its clearing broker’s principal account. In Version 1.0, the procedure was: “The clearing broker enters its participant identifier in both “Participant” fields. The same participant is thus shown as clearing on both the sell and buy sides.” The revised procedure is this: On its own side of the trade report – e.g., the sell side if bonds are being sold from its account – the clearing broker enters its participant number and its four character NASD assigned symbol. On the other side, the clearing broker enters the literal “IDRO” and the correspondent’s four character NASD assigned symbol. For example, assume participant 1563 has NASD symbol FRSD and that the participant has a correspondent, DEFR. If bonds are sold from the principal account of participant 1563 to its correspondent DEFR (because DEFR is effecting a separately reported sale as agent for a customer), then enter data as follows.
Note that there is no change to the Version 1.0 requirement regarding the Effecting Dealer field on either side. IDRO reports are accessible only by participants The clearing broker (participant) must enter an IDRO report on behalf of itself and its correspondent. Only the clearing broker may modify or cancel the IDRO report. Changes to error messages The following error messages have been dropped from the Specification (Section 2.9 and Appendix B):
N914 LATE Trade canceled more than 15 minutes after time of trade N915 LATE Trade modified more than 15 minutes after time of trade X92A UNSAT RTTM error E-mail option for effecting broker / acknowledgements of error free reports E-mails that correspond to MT509 messages will be optionally available to participants and non-participants. In the Specification Version 1.0 it is stated that RTRS will not send an e-mail for an inter-dealer trade, already acknowledged by RTTM, in which RTRS finds no errors (including lateness). This has been changed to state that e-mails sent optionally will include RTRS acknowledgement of error-free and timely inter-dealer trade reports, as well as description of regulatory errors. Sender of RTRS MT509 messages In the message header, the Sender of MT509 messages that originate in RTRS will be “MSRBRTRS” (Specification p. 62). Sender and Participant Party of MT515 messages The reference in the Specification (Version 1.0, page 56) to the use of NASD effecting broker symbol in the Sender field of customer and IDRO messages has been deleted. The Sender field should always contain a valid NSCC participant number. The Party value is used in customer trade messages for processing purposes and does not indicate that an organization was a party to the trade. The Party (participant) field on the dealer’s side of a customer trade message should always contain a valid participant number. Do not include “DEAL” in a customer trade message (Version 1.0, page 59 has been changed). Detailed changes Version 1.0, on page 64, the Status Code example :25D::IPRC//PACK has been changed to:25D::AFFM//AFFI and Reason Code example :24B::REJT/GSCC/U52B is now :24B::NAFI/GSCC/U52B.
REDLINE FILE A Microsoft Word “redline” file that shows each change made to Version 1.0 is available on www.msrb.org. Click here to access the redline file. FURTHER INFORMATION Questions about the Specifications may be addressed to Larry M. Lawrence, Policy and Technology Advisor, or to other MSRB staff listed on page v of the Specifications, all at (703) 797-6600. September 23, 2003 |
||||||||||||||||||||||||||||
|
©2005 Municipal Securities Rulemaking Board. All Rights Reserved. Terms and Conditions of Use. |
||||||||||||||||||||||||||||