(Volume 16, Number 1) JANUARY 1996
This document provides technical information to supplement the December 27, 1995 Notice on the Municipal Securities Rulemaking Board's Transaction Reporting Program, and requests additional comment on the technical standards for transmittal of transaction information to the Customer Transaction Reporting (CTR) Subsystem.
Comments should be submitted no later than May 1, 1996, and may be directed to Larry M. Lawrence, Policy and Technology Advisor. written comments will be available for public inspection.
In its December 27, 1995 Notice, the Board described its plans to develop a central Customer Transaction Reporting Subsystem (CTR Subsystem) as part of the Transaction Reporting System currently operated by the Board. Dealers will report all customer transactions to this Subsystem. This document provides supplemental technical information about data items required in records submitted to the Subsystem, definitions of record types, and proposed standards for file format and telecommunications methods. The Board is requesting comment on these specifications.
Following are descriptions of the proposed data items that will be required in customer transaction records submitted to the CTR Subsystem:
CUSIP Number. The CTR Subsystem will validate the CUSIP number of the security being traded by ensuring the CUSIP number is on the system's updated master list of municipal security CUSIPs. This item is needed for transparency and surveillance purposes.[1] Format: 9 alphanumeric characters.
Trade Date (if Not Date of Submission). "Late" submissions, i.e., those submissions made after trade date, will be coded as "late" and will include the trade date.[2] This item is needed for transparency and surveillance purposes and to determine compliance with the Board's rule G-14 requiring that the trade be reported on trade date. Format:
LATE: "Y" or "N" TRADE DATE: CCYYMMDD (e.g., "19980831")
Par Value Traded. This is the par value, in dollars, of the securities in the transaction. The maturity value of zero coupon securities will be given if it differs from the par value. Par value is needed for transparency and surveillance purposes. Format: 9 digit integer.
Dollar Price. This is the price of the security, in dollars per hundred dollars par value. Dollar price will be reported to the CTR Subsystem excluding any commission; the CTR Subsystem will include the commission (a separate item, described below) in the dollar prices as shown in the daily public reports. Dollar price is needed for transparency and surveillance purposes and to help validate the consistency of yield. Format: up to 8 characters, with an explicit decimal point, e.g., 123.4567.
Yield. This is the yield of the transaction, as reported on the confirmation. Yield will not be required on transactions in municipal variable-rate or collateralized mortgage obligations. Yield will be used to validate dollar price. Format: up to 8 characters, with an explicit decimal point, e.g., 003.4567.
Dealer Identifier. This is an alphabetic symbol that denotes the executing dealer. It is proposed that each dealer identify its transactions by means of the four-character alphabetic over-the-counter (OTC) executing broker symbol. The dealer identity is needed for surveillance purposes. Format: 4 alphanumeric characters.
Buy/Sell Indicator. This item indicates the dealer's role in the transaction, and is needed for surveillance purposes. Format: "B" or "S".
Time of Trade Execution. The time of day, stated as Eastern time in hours and minutes, at which the trade was executed. This item is needed for surveillance purposes. Format: HHMM, where HH is between 00 and 23 and MM is between 00 and 59.
Dealer's Capacity and, if Agent, Commission Charged. The dealer's capacity indicates whether the dealer acted as agent or principal. It is needed for surveillance purposes. Commission will be stated as dollars per hundred dollars par value, and is needed for computing the net price including commission. Format:
CAPACITY: "A" or "P" COMMISSION: Up to 8 characters with an explicit decimal point.
Settlement Date, if not Regular-Way. If the settlement date is not given, it will be assumed to be the third day after trade date (T+3). The settlement date for new-issue securities, not traded regular-way, must be provided if it is known. If the settlement date is not known to the dealer at the time the trade information is submitted to the CTR Subsystem, the dealer will provide an assumed or estimated date, together with an indication that the date is not yet known. This item will be used in computations to validate the consistency of dollar price and yield as submitted. Format:
SETTLEMENT DATE ESTIMATED: "Y" or "N" SETTLEMENT DATE: CCYYMMDD .
Dealer's Control Number for Transaction. This is an executing dealer-assigned number sufficient to identify the transaction from among the dealer's other transactions. Dealers may use any coding method, provided that no two transactions done by a dealer within a three-year period have the same control number. This item is needed for surveillance purposes (so that submissions can be associated with entries in the dealer's record-keeping system) and for data management (so that a dealer may revise a submission, if necessary, after it is sent to the CTR Subsystem). Format: Free form, up to 12 alphanumeric characters.
On the day of trade execution, the dealer or intermediary will submit original records of customer transactions. Later, the dealer or intermediary may submit records amending or cancelling those previously submitted, to ensure an accurate record in the surveillance database. The amending or cancelling record must identify the original record by providing the dealer's own control number for the transaction (described above), and must be coded to show whether it is amending or cancelling the transaction record. To amend a record, a new complete record with all required data items will be submitted. The dealer will select a code from a list to specify the reason for the amendment, e.g., "Correcting Par," "Correcting Yield," etc.
Files of transaction data submitted to the CTR Subsystem will begin with a header record which will contain:
Identity of organization submitting the file. This may be a dealer reporting for itself or an intermediary reporting for a dealer.
Time and date of submission. Eastern time will be given.
Sequence number of file in the day (001 = first file transmitted this day, etc.).
Logical detail records will follow the header. Each logical record will represent a transaction being submitted to the CTR Subsystem or a change to a previous record (described above). Records may be in any order.
Submitters of transaction records will be able to dial-up the CTR Subsystem to report transactions. In cases where it is justified by transaction volume, a dedicated telephone connection may be used by either a single dealer or an intermediary acting on behalf of a number of dealers. Telecommunications charges will be borne by the party submitting the information.
The Board wishes to employ telecommunication methods (protocols) that are "open" to the greatest extent possible, i.e., methods that are least restrictive about the submitter's system configuration. The Board is considering such commonly used protocols as the following for transmitting customer trade data. For those facilities now using other protocols, a variety of commercial products are available to adapt existing equipment to use those listed here.
Asynchronous Personal computers with: Zmodem DOS (recommended) Windows Kermit OS/2 Xmodem, Ymodem
Binary Synchronous IBM and compatible Remote Job Entry (BSC) mainframes (RJE) 2780/3780 Other mainframes with 3780 software
Transmission Control Unix-based computers File Transfer Protocol/ Internet or any Protocol(FTP) Protocol computer/workstation (TCP/IP) with TCP/IP softwear
It is assumed that submitters will use the RJE protocol for EBCDIC-encoded data (Extended Binary Coded Decimal Interchange Code) and will use the other protocols for ASCII-encoded data (American Standard Code for Information Interchange). The BSC and TCP/IP protocols function over both dial-up and dedicated connections.
Comments are requested on features that would maximize the "openness" of the CTR system's interface with users. Comments may address, but need not be limited to, the following topics:
Should the data items within a record be placed in fixed physical positions, e.g., CUSIP number in positions 1-9, trade date in positions 10-17, etc., or should data items be tagged in a standard manner and separated by spaces or other delimiters in a variable-length record, e.g., CUSIP: 123456AB1; TRDT: 01021997 ; PAR: 100000 ; etc.
Is there an important class of dealer/vendor systems that can generate records of only a certain maximum length, e.g., 80 bytes?[3] Is there a maximum record size that cannot be exceeded?
In addition to the telecommunications protocols listed, are there others that should be considered because they are in widespread industry use or expected to be in widespread use by late 1997, or for other reasons?
Would it be unreasonably costly to convert certain dealer facilities to use the listed protocols? Are dealers now using local area networks (LANs) that are incompatible with these protocols?
To what extent is submission of transactions to the Board via the Internet a desirable option for 1998 and later?
December 27, 1995
[1] Items needed for transparency purposes will appear on the daily report. Items needed for surveillance purposes will be stored in the Board's surveillance database and used by the enforcement agencies for audit trail construction and other enforcement purposes.
[2] "As-of" transactions reported to the CTR Subsystem will be classed as "late."
[3] The data items defined above have a total of 82 characters, and future revisions may add additional characters.
Top of page
Back
MSRB Home Page
Copyright 2005 Municipal Securities Rulemaking Board. All Rights Reserved. Terms and Conditions of Use.