The following specifications accompany the Board's proposed rule change (see "Board to Proceed with Customer Transaction Reporting Program: Rule G-14" in this issue of MSRB Reports.) The Board expects to publish a User's Manual for Customer Transaction Reporting, which will include these specifications, during the test period (July to December, 1997).
Table 1 presents the data items required to report, amend or cancel a single customer transaction. Each item is briefly defined. Fuller definitions are found in the Notice of the proposed rule change.
DATA ITEM DEFINITIONS
ITEM NAME DEFINITION | DEFINITION |
CUSIP Number | Number assigned by the CUSIP Service Bureau. |
Trade Date | The date the trade was executed. |
Time of Trade | The time of day, to the nearest minute, at Execution which the trade was executed. Eastern time shall be reported. |
Dealer Identifier | NASD executing broker symbol of executing dealer. |
Buy/Sell Indicator | Executing dealer's capacity as buyer or seller. |
Par Value Traded | Par value (quantity) traded, in dollars. (If zero coupon security, report maturity value.) |
Dollar Price | The price of the security, in dollars per hundred dollars par value. Report the price exclusive of any commission. If settlement date is unknown and other required items are reported, dollar price is not required. |
Yield | Yield of transaction, in per cent, as on trade confirmation. May be omitted for certain securities, e.g., variable-rate securities. |
Dealer's Capacity | Dealer's capacity as agent for the customer or as principal. |
Commission | Commission, in dollars per hundred dollars par value. Required for agency trades. |
Settlement Date | Mandatory input from dealer if settlement date is known. If the settlement date for an issue in when-issued" status is not known at the time the trade information is reported, this item may be reported as "zero" or left blank. The system will estimate it as 20 business days after the first trade in the issue, until the actual settlement date for the issue is determined. |
Dealer's Transaction Control Number | An identifier, assigned by the executing dealer, sufficient to identify information about the securities 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. |
Cancel/Amend Code | Indicator of whether the dealer is reporting an update to data previously reported about a transaction. |
Previous Record Reference | Dealer's control number of transaction to be canceled or amended. |
FILE SPECIFICATIONS (V.0.3.1)
Three types of file are currently specified: (1) Submissions of customer transaction data, sent by dealers to the Customer Transaction Reporting Subsystem (CTRS); (2) Receipt and error message files, sent to dealers by CTRS; and (3) Test files, which may be sent in either direction.
Each file has a header and detail records. The header identifies the submitter, the submission date and time, the version, and the file (detail record) type. The header includes a count of the following detail records. All records in the file must be of the same type (transaction, receipt and error message, or test). A transaction file may contain records for several dealers, and it may include both "first reports" of trades and corrections to or cancellations of previously reported trades. A receipt/error message file will always include at least one receipt for a submission file; if no errors are detected in the submission, there will be no error records. Test files will be defined before the test period.
All data submitted by dial-in connection to the CTRS will be coded as ASCII. Each record will end with a carriage-return/line feed (CR/LF) symbol. Data submitted through NSCC will be coded according to NSCC specifications.
The header identifies the format version being used. Thus, if MSRB changes the version, both the old and new formats could be used by different dealers during a transition period. The version number applies to all the record types; a change in any record format will require a new version number.
HEADER RECORD FORMAT
Data Item | Type | Length | Start Position | Notes |
Submitter ID | A/N | 4 | 1 | Identifier of dealer,clearing dealer, or service bureau submitting file. Identifier to be assigned by the MSRB. |
Submission site | N | 2 | 5 | Location from which submitted. Site code to be assigned by the MSRB. |
Submission date | N | 8 | 7 | Date the file was transmitted. Format: CCYYMMDD |
Submission time | N | 4 | 15 | Time the file was transmitted. Format: HHMM, military format,Eastern time. |
File sequential number | N | 4 | 19 | Sequential number of number this file from this submitter on this date. |
Version ID | A/N | 5 | 23 | Version of MSRB's file format being used for submission, e.g., 00010. |
File Type | A/N | 1 | 28 | S=submission of trades to MSRB R=receipt/error message to submitter T=test |
Length | N | 5 | 29 | Number of records in this file. |
TOTAL LENGTH | 33 |
The transaction record format applies to records of trades submitted to the Customer Transaction Reporting Subsystem. A record may be the "first report" of a trade to CTRS or a "cancel/amend" record relating to a previously reported trade.
Dealers should submit "amend" records only when there has been a change in the transaction data items required for customer transaction reporting. Rebills that change account number, etc., should not be reported to MSRB.
The meaning of each data item is described in Table 1 above. Items that may be omitted for a particular trade may be reported as zeroes or left blank.
TRANSACTION RECORD FORMAT
Data Item | Type | Length | Start Position | Notes |
CUSIP number | A/N | 9 | 1 | |
Trade date | N | 8 | 10 | CCYYMMDD |
Time of trade execution | N | 4 | 18 | HHMM, Military format. trade execution |
Dealer identifier | A | 4 | 22 | Required item. |
Buy/sell indicator | A | 1 | 26 | B=Dealer is buyer indicator S=Dealer is seller |
Par value traded | N | 9 | 27 | Integer, no commas or traded decimal point. |
Dollar price | A/N | 10 | 36 | Includes explicit decimal price point. Position of decimal may vary. All of the following are valid: 100.123456 89.1234567 099.500000 Not required in certain cases (see Table 1). |
Yeild | A/N | 9 | 46 | Includes explicit decimal point, zero-filled at left. Position of decimal may vary, e.g. 03.45678 or 3.45678. Units are percent, e.g., 03.5 denotes 3.5%. |
Dealer's capacity | A | 1 | 55 | A=Agent for customer capacity P=Principal |
Commission | A/N | 8 | 56 | Includes explicit decimal point, zero-filled at left. E.g.: 000.0500 Units are dollars per hundred dollars par value. Required only if capacity is "agent," otherwise may be zeroes or blank. |
Settlement date | N | 8 | 64 | CCYYMMDD. If settlement date date is unknown, this field may be zeroes or blank. |
Cancel/amend code | A | 1 | 72 | F=First report of this trade to the MSRB C=Cancel the record of the trade identified by the following control number. All other fields of the current record may be zeroes or may contain the values being canceled. A=Amend the record of the trade identified by the following control number. New attributes of this trade are in the current record. V=Verify that a transaction(identified by the control number in the following field) previously noted as questionable, is correct. |
Dealer's transaction control number | A/N | 20 | 73 | An identifier of the transaction sufficient to associate all its data in the system. (See note below.) Format of control number is determined by dealer. |
Previous record reference | A/N | 20 | 93 | Control number of transaction being cancelled or amended by present record, if not shown in previous field. Optional if the transaction being updated is identified by the "dealer's transaction control number" field. (See below.) Blank or zeroes if cancel/amend code is "F." |
TOTAL LENGTH | 112 |
All records pertaining to a transaction must share the same dealer-assigned control number. This allows the Transaction Reporting System to update the records of a transaction based on dealer input.
When the dealer submits a cancel/amend record (C/A record), it is recommended that the "dealer's transaction control number" field contain the same number as the record that first reported the trade to the system. In such a case, the "previous record reference" field is optional. However, to allow for different dealer practices - such as dealer systems that assign unique numbers to each record - the C/A record may contain a "new" control number, i.e., one not previously reported. In such a case, the "previous record reference" field must contain the control number of the record that first reported the trade. The table below shows valid and invalid input patterns.
VALID PATTERNS FOR REPORTING TRANSACTION CONTROL NUMBER
FORMATS |
Data Reported by Executing Dealer |
||
Cancel/ Amend Code | Dealer's Transaction Control Number | Previous Record Reference | |
RECOMMENDED INPUT FORMAT First report of transaction F 12345 Amend data about transaction | F A or C |
12345 12345 |
|
ALTERNATIVE VALID FORMATS First report of transaction F 12345 Amend data about transaction | F A or C |
12345 99887 |
12345 |
First report of transaction Amend data about transaction |
F A or C |
12345 |
12345 |
INVALID INPUT FORMATS
(UNMATCHED CONTROL NUMBERS) First report of transaction Amend data about transaction |
F A or C |
12345 99887 |
|
First report of transaction Amend data about transaction |
F A or C |
12345 |
99887 |
First report of transaction | F | 12345 |
The receipt/error message file is generated by CTRS after a file is received and processed. Normally one receipt record is generated per input file. It is preceded by a file header that indicates the file type is "receipt."
CTRS sends receipt/error message information by fax to the submitter, and in addition makes a receipt/error message file available for downloading to the submitter's computer, at the submitter's option.
The receipt/error message file has three record types. Type 1 is a fixed-length record identifying the input file and stating that the file was or was not received satisfactorily. Type 2 is a variable-length record containing text that describes an error. Type 3 is a fixed-length record containing a copy of the input record in which the error was found. A file of receipt/error messages contains: one header; one type 1 (receipt) record; and a pair of type 2 (text) and type 3 (transaction) records corresponding to each input transaction record that contains an error.
Data Item | Type | Length | Start Position | Notes |
Logical record type | A | 1 | 1 | Always "R" (receipt) |
Receipt type | A | 1 | 2 | S=Successful receipt of file U=Apparently unsuccessful receipt of file (E.g., upload interrupted, damaged file received) |
Date and time file received | N | 12 | 3 | Time the file was received by MSRB. Format: CCYYMMDDHHMM |
Date and time file sent | N | 12 | 15 | Time the receipt was sent by MSRB to submitter. Format: CCYYMMDDHHMM |
Number of error records | N | 4 | 27 | Number of records in remainder of file. |
TOTAL LENGTH | 30 |
TABLE 6
RECEIPT/ERROR RECORD TYPE 2: DESCRIPTION OF ERROR
Data Item | Type | Length | Start Position | Notes |
Error record number | N | 4 | 1 | Sequential number of this record in this file. |
Logical record type | A | 1 | 5 | Always "D" (description record of error) |
Error code | A/N | 5 | 6 | Error codes will be listed in the User's Manual. |
Error message text | A/N | 1 to 240 | 11 | Describes error found in message following input transaction record. See error message list. |
TOTAL LENGTH | 11 to 250 |
TABLE 7
RECEIPT/ERROR RECORD TYPE 3: COPY OF TRANSACTION RECORD RECEIVED
Data Item | Type | Length | Start Position | Notes |
Error record number | N | 4 | 1 | Sequential number of this record in this file. |
Logical record type | A | 1 | 5 | Always "T" (transaction record received from dealer.) |
Error code | A/N | 5 | 6 | Same value as preceding error message. |
TRANSACTION RECORD | A/N | 112 | 11 | Contains all the values of the input transaction record, in the same format as the input. |
TOTAL LENGTH | 122 |
Dealers may submit customer trade information to the MSRB in either of two ways: by uploading customer trade files to National Securities Clearing Corporation (NSCC) or by dialing in to the Customer Transaction Reporting Subsystem of the MSRB's Transaction Reporting System. NSCC will forward customer transaction files to the CTRS without making any change to the file contents. Procedures for uploading files to NSCC will be found in NSCC documentation.
Dealers with lower volumes of customer trades that choose to dial-in to the CTRS must use software provided, free of charge, by the MSRB for this purpose. The hardware/software requirements for the dealer's facility are:
- Software: Any version of Microsoft Windows that is supported by Microsoft Corporation.1
- Hardware: A personal computer2 capable of running the above software; a modem (9600 baud or faster) and an analog telephone line.
The MSRB-provided software will include programs to make remote procedure calls with a minimum of dealer staff involvement. In ordinary operations the dealer staff will simply initiate the upload process and check that the process is successfully completed. Dealers will dial-in and transmit files using the Remote Procedure Call (RPC) features of Windows. RPC running on the dealer's computer and the CTRS will use standard protocols to communicate with one another.
The CTRS will send the receipt and any error messages to the submitting dealer by facsimile. Dealers wishing to download the receipt and error messages electronically will have the option to do so, using the MSRB-provided software.
August 29, 1996.
1 As of August 1996, Microsoft supports Windows 3.1.1, Windows 95, and Windows NT. Shortly after Microsoft discontinues support for an older product, the MSRB may discontinue use of that product for customer data submission.
2 Windows NT runs on workstations and other platforms that are not "personal computers." These are also suitable for file submission.
Top of page
Back to cover page
MSRB Home Page
Copyright 2000 Municipal Securities Rulemaking Board. All Rights Reserved. Terms and Conditions of Use.