Home Page | Back 

CHANGES TO FILE SPECIFICATIONS

Since the publication of the specifications for reporting customer transactions to the MSRB, the following changes and clarifications have been made.

GENERAL

Developers should understand that there are two versions of the file specifications. They are identical logically but differ physically, that is, in the location of fields within records. Dealers submitting customer trade data to MSRB through NSCC must use NSCC's specifications as described in NSCC Notice A4618 dated April 2, 1997. Dealers submitting data directly to the MSRB using a personal computer (PC) must use the MSRB standard specification, originally described in MSRB Reports of September 1996 and revised since.

The revisions described here apply to both formats, except as noted.

CLARIFICATION: "RECORD COUNT" IN APPLICATION HEADER (Added Sept. 7, 1997)

Both the NSCC and MSRB specification require a "record count" in the application header, which is the second physical record in the file. This field should contain the number of transactions, rather than the number of records. Omit the headers and end record from the count. If using the NSCC RJE format, the number of transactions is one-half the number of physical transaction records, since there are two physical records per transaction.

REUSE OF TRANSACTION CONTROL NUMBER (Revised Sept. 30, 1997)

The September 1996 specification provided that "no two transactions done by a dealer within a three-year period may have the same [transaction] control number." This has been modified to provide that a dealer may cancel a transaction bearing a given control number and may then submit a "first report" ("F" record) with the same control number but different details. For example, the following records are acceptable, if they are submitted to CTRS in the order shown:

SIMPLIFIED "CANCEL" AND "VERIFY" FORMAT (Revised July 9, 1997)

The specification for the "cancel/amend code" regarding "Cancel" has been changed to make it clearer that the "Cancel" and "Verify" records need only contain the cancel/amend code, the dealer identifier, and the control number of the record being canceled or verified.

The specification has been changed as follows:

VERIFICATION OF DOLLAR PRICE AND YIELD (Revised July 9, 1997)

At the outset of the dealer test period, the CTRS will not verify the dollar price and yield, as reported by the dealer, for consistency with one another and with information about the security being traded. The fact that there are no error messages sent to the dealer regarding price/yield inconsistencies should not be interpreted to mean that the CTRS has found them consistent. When this verification step is added to the CTRS, dealers that opt to receive faxed receipts will be notified of the change by fax.

ERROR MESSAGE 240, "DOLLAR PRICE IS REQUIRED..." (December 12, 1997)

This error has been classified as a "major error." This means that, if a dealer receives this message, he or she must respond by sending an A, C or V record to CTRS.

CHANGES TO ERROR MESSAGES (January 20, 1998)

PROHIBITION AGAINST BINARY DATA IN TRANSACTION FILE (Clarified October 10, 1997)

The original specification stated: "All data submitted by dial-in connectino to the CTRS will be coded as ASCII. . . . Data submitted through NSCC will be coded according to NSCC specifications. "This is clarified by adding: "No binary data may be included in the application header record or the transaction records."

REVISED FORMAT FOR ERROR RECORDS IN RECEIPT/ERROR MESSAGE FILE

(Revised July 9, 1997)

The specification for the "Receipt/Error Message Format" has been revised to provide that up to four errors in a single transaction will be described in the accompanying error-description record. The description record will have up to four error codes and short messages. If a transaction has more than four errors, the fourth error message will state that additional errors are present. In that case, the dealer should analyze all fields of the transaction record and correct all the errors.

To implement the above, the specification has been changed as follows: 

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 fixed-length record that describes an errors in the following transaction record. Type 3 is a fixed-length record containing a copy of the input record in which the error(s) was were 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(s).

This paragraph and table apply only to the MSRB standard file specification. Record Type 2: Description of Error" shown in Table 6 of the MSRB standard file specification stated that the "error message text" field would be a description of one error, using an "error message text" field of up to 240 bytes. This has been revised as follows.

TABLE 6

RECEIPT/ERROR RECORD TYPE 2: DESCRIPTION OF ERROR

HANDLING OF ERRORS IN FILE HEADER (Revised July 9, 1997)

The header record in transaction files (described in Table 2 of the specification) contains information that CTRS uses to determine that the file comes to CTRS from a known submitter, that the file is received on time or late, etc. CTRS will handle errors in the header record as follows:

• If the error makes it impossible for CTRS to process the file -- for example, if the submitter ID is unknown to CTRS, i.e., not present in the CTRS master file of submitters, then CTRS will reject the file. MSRB staff will contact the organization that seems the most likely submitter, by fax or telephone. The submitter must resubmit the file with a known submitter ID.
• If the error is less grave -- for example, the "file type" is neither "S" (submission of trades) nor "T" (test) -- then CTRS will handle this as though it were an error in a transaction record. That is, the first pair of records in the receipt/error message file will consist of a description of the header error(s) followed by a copy of the header record that was submitted to CTRS. Depending on the nature of the error, the submitter may be asked to resubmit the file.

ADDITIONAL RECORD TYPES FOR FILES WITHOUT ERRORS (Revised Sept. 30, 1997)

The original specification provides (Tables 6 and 7) that the receipt and error message file contains records of type "D" (description of error) and record type "T" (copy of the transaction record containing the error). The specification stated, Aif no errors are detected in the submission, there will be no error records."

This has been changed to provide that, if there are no errors in the submitted file, the receipt record will be followed by one type "G" record with error code 001, "FYI: No errors were found," and a type "H" record with an error record number, logical record type, and error code, but blank in positions 11 through 122. This change is made so that the file will contain the same information as the fax, and so that the file structure is uniform to facilitate its automated processing by the submitter.

REVISIONS TO CERTAIN FIELD TYPES AND LENGTHS (Revised July 9, 1997)

In the header record specification (Table 2), the "File sequential number" is a numeric (N) data type, not alphabetic (A) as originally shown.

This paragraph applies only to the MSRB standard file specification. In the receipt/error record type 3 (copy of transaction record received), the field devoted to the transaction record is 112 bytes long, not 111 as originally shown. The total record length of the type 3 record is 122 bytes, not 121 as originally shown. (If the header record submitted to CTRS is copied into the type 3 record, the type 3 record will be right-filled with spaces to keep the overall record length as 122 bytes.)

CHANGES 3 MONTHS AFTER THE TRADE (Revised January 19, 1998)

Background: The current rule is that the dealer may amend a trade for three months after trade date, except in case of trade whose settlement date is unknown on trade date, where the dealer has three months after the actual settlement date.

Revision: The dealer may amend the trade for 90 calendar days after the actual settlement date. Trade date is not taken into account for any trade.

CHANGES TO INFORMATION NOT SUBJECT TO REPORTING REQUIREMENTS (April 17, 1998)

Dealers should report to the MSRB only changes relevant to the Board's transaction reporting purposes, for example, a change in the price or par value of a trade. Dealers should not report a change if it does not involve a required data item. For example, a change in a customer account number should not result in a second report of the trade to the MSRB.

©2008 Municipal Securities Rulemaking Board. All Rights Reserved. Terms and Conditions of Use.