A 4618 --- July 9, 1997
P&S 4195

To : ALL PARTICIPANTS
Attention : MANAGING PARTNER/OFFICER, OPERATIONS PARTNER/OFFICER, MANAGER P & S DEPARTMENT, MANAGER DATA PROCESSING
Subject : THE MSRB'S CUSTOMER TRANSACTION REPORTING PROGRAM FOR MUNICIPAL BOND SECURITIES
MSRB TESTING with NSCC INTERFACE

As noted by a recent information package (dated March 27, 1997) sent by the Municipal Securities Rulemaking Board's (MSRB) and National Securities Clearing Corporation (NSCC) Important Notice A 4571 (P&S 4155) dated April 2, 1997, the MSRB's Transaction Reporting Program is now in the stage of reporting institutional and customer trades. According to the MSRB they will begin their system testing in July 1997. As previously reported, in order to support the industry, NSCC will be providing the capability of accepting customer municipal bond transactions from participants and forwarding them to the MSRB. This effort is in response to a recent MSRB amendment to their rule G-14 mandating that dealers report customer transactions to the MSRB. In addition to the aforementioned documents, details regarding this rule change and the specifications for reporting customer transactions can be found in the MSRB Reports, Vol. 17, No. 1 (January 1997), "Reporting Customer Transactions to the Board: Rule G-14," and in Vol. 16, No.3 (September 1996), "Board to Proceed with Transaction Reporting Program."

This notice only details NSCC's submission requirements for those participants who will be sending their data to NSCC (CPU-to-CPU transmission) for subsequent transmission to the MSRB. These requirements will detail NSCC's Input (Datatrak) and Output (Autoroute) procedures.

The MSRB advises that they will be contacting dealers regarding the content of the actual test.

Note: See the attached documentation from the MSRB for testing details.

INPUT PROCEDURES

As detailed in the earlier notice, these customer transactions have necessitated NSCC to establish two new Datatrak Input SysID's, one for RJE communication protocol and one for Non-RJE (NDM, BDT . . . etc.). Both SysID's will be utilizing multi-batch processing, enabling a single submitter to send multiple files throughout the processing day.

Network Communication Testing

Prior to the actual MSRB test, NSCC will require participants to contact SIAC's Network Operations at (212) 383-5401 to have your firm set up appropriately for one of the following two new SysID's.

Note: THE MSRB HAS ASKED THAT ALL PARTICIPANTS CONTACT THE ABOVE AS SOON AS POSSIBLE PRIOR TO YOUR SCHEDULED TESTING TIME FRAME (1), SO THERE IS AMPLE TIME TO MAKE THE APPROPRIATE DATATRAK SET UP PRIOR TO THE TEST.

(1) According to the MSRB, they will determine the schedule and notify all dealers appropriately (see enclosure).

OUTPUT PROCEDURES

Product ID 02030678 - MSRB Receipt/Error File Output

As previously noted, the MSRB's Customer Transaction Reporting Subsystem (CTRS) will generate a Receipt/Error (R/E) file. One R/E file will be generated for each file submitted by participants, acknowledging the MSRB's receipt and processing of the file along with any rejected transactions. NSCC will also make this file available to participants. This will be made available as a new Autoroute output file for transmission to participants.

Participants who wish to receive this new file must contact their NSCC Participant Services representative (see phone no. below). As noted in the above input procedures, this should be done prior to your scheduled testing time.

PC PLATFORM / PC SOFTWARE

As previously stated, the requirements described above are for those firms who will utilize a CPU-to-CPU transmission to NSCC. According to the MSRB, they will be offering the appropriate software for submitting customer transactions directly to the MSRB for those participants who currently use PC Platform or related PC software. Any questions concerning testing of this software can be directed to the MSRB contact below.

SUBMISSION PROCEDURES & TIME FRAMES

With multi batch processing participants will be able to send as many files as they want until the designated cut off time. Once the MSRB has determined a participant is ready to test the participant will be able to submit transactions to NSCC, for subsequent transmission to the MSRB. The MSRB has established a 12:00 A.M.(midnight) deadline to receive customer transactions. In order to meet the MSRB's deadline, NSCC is establishing an 11:45 P.M. cut off time for all submissions directly to NSCC.

According the MSRB, the above time frames will be used for their testing period as well as production once it is implemented by the MSRB.

Any questions regarding the MSRB's reporting requirements or testing details can be directed to Larry M. Lawrence of the MSRB at (202) 223-9347.

Questions regarding this Important Notice can be directed to NSCC Participant Services in New York at (212) 412-8432 or the undersigned at (212) 412-8594.

Martin R. Simoneau
Senior Business Systems Analyst

MUNICIPAL SECURITIES RULEMAKING BOARD
CUSTOMER TRANSACTION REPORTING: TEST PLAN

INTRODUCTION

On March 27, 1997 the Municipal Securities Rulemaking Board sent information regarding the Customer Transaction Reporting System (CTRS) for municipal securities to all brokers, dealers and municipal securities dealers (collectively "dealers"). This memorandum is addressed to dealers in municipal securities that are also NSCC participants. It provides an overview of the MSRB's plan for testing the CTRS with dealers.

Your firm should have received the March 27 mailing, which included a four-page Dealer Information Form, and should have returned that form to us. Please contact us at 202 223-9347 if you have not returned the form. Note that MSRB rule G-14 requires dealers to provide information on the form to us by July 1, 1997 (2).

BACKGROUND

Under MSRB rule G-14 on transaction reporting, dealers effecting transactions in municipal securities with customers will be required to produce a file with records of those transactions each day. The file must be submitted to the MSRB by midnight each night. The dealer effecting the transaction with a customer is responsible for producing a record of the transaction and identifying itself as the dealer involved. Dealers that use service bureaus or clearing brokers for executing and back-office processing of their municipal securities transactions may wish to arrange with the service bureau or clearing broker to produce the required files; however, the dealer effecting the transaction (i.e., the dealer that the customer knows) is ultimately responsible to ensure that the record is produced and is correct.

Once a file with the correct records is produced, a dealer must ensure that the file is successfully transmitted to the MSRB before midnight. The Board expects that most dealers will use NSCC as the conduit through which such files are transmitted. (Transmission of customer trade data through NSCC is not related to the FITS automated comparison system, but is rather a separate file and transmission format. The FITS system is used exclusively for inter-dealer transaction data, while the CTRS is used exclusively for transactions between dealers and customers.) For dealers with a low volume of municipal securities transactions (e.g., generally no more than three such transactions per day), and for dealers that currently use NSCC's PC dial-in link as their exclusive connection to NSCC, the MSRB will provide a PC dial-up link in August 1997.

TESTING OVERVIEW

Dealer preparation. CTRS testing will begin in July 1997 and extend through December. As a first step, firms that will submit customer transaction files through NSCC (for themselves or for others) should begin now to set up input and output procedures with NSCC. For more information, see the NSCC Important Notice A4618, P&S4195, dated July 9, 1997 (attached).

Scheduling. MSRB staff will notify you of your scheduled testing date at least three weeks in advance. From July through mid-September, we will test with dealers that have the highest volume of customer transactions. This will include both dealers that submit their own customer transaction data as well as dealers and service bureaus that submit data for others. During late September and October we will test with the remaining dealers, including those submitting data directly to the MSRB via personal computer. We plan to contact each dealer by October to schedule specific testing dates (3). Please contact us if you have not been scheduled by October 15. You may volunteer to begin testing ahead of schedule, but, if so, you must contact us to set the date. (Contact information is at the end of this notice.)

PC dial-in method. Certain dealers indicated on the dealer information form that they would like more information on submitting transaction files by dialing up to the MSRB directly. We plan to provide PC software and instructions to those dealers beginning in mid-August 1997.

TEST PROCEDURE

During the test, you will submit records of all your customer trades each business day for five successive days. As described below, you will receive CTRS outputs to inform you of errors detected during processing. You should correct as many errors as possible, as soon as possible, by submitting "Amend" or "Cancel" records along with a subsequent day's transactions.

If the test shows that substantial correction is needed in your company's computer system or trade reporting procedures, we will schedule a second round of testing approximately four to six weeks after the first test.

CTRS RECEIPTS AND ERROR MESSAGES

For every file we receive, the CTRS system will produce a receipt which includes messages describing apparent errors in the file. This will be available in two forms:

• By fax: The fax will acknowledge receipt of your file by showing the date and time MSRB received the file. If the file was error-free, the receipt will state, "No errors were found." If, however, the CTRS system detected errors in the header record or in any transaction records, those records will be printed in full, along with the applicable error codes. A legend at the bottom of the fax will interpret the codes. See Attachment C for a list of error messages.
  
• By download: CTRS will produce a file that will contain the same information as the fax. NSCC will download the file to firms with which it has telecommunications connections.

Output options. If you submit transaction files via the NSCC, you have the option to receive the fax, the file, or both. If you opt for the fax, we will automatically send it. NSCC will send the receipt file to you if you request it from NSCC during the NSCC set-up procedure.

If you submit transaction files through an intermediary that has a telecommunications link with NSCC, the fax may be sent to you, to the intermediary, or both. If you submit files directly to MSRB by PC, you will receive the fax, and you may use the MSRB-provided software to download the receipt file to your PC.

Timing. Once the CTRS system goes into operation in 1998, the receipt will be sent the morning after you submit a file to us -- typically, before 6:00 am. However, during the test period we will be examining the test results manually, which is a slower process. Thus, the receipt during the test period may state, "More information will follow." We will follow up with a second receipt with more specific information within one to two days after you submit the file.

PRELIMINARY STEPS BEFORE TESTING

MSRB staff will contact you by telephone or mail at least three weeks in advance to schedule your firm for testing. You will be asked to identify a person to contact for testing and to specify whether you will submit transaction data through NSCC, through an intermediary dealer or service bureau, or by dialing in to the MSRB with a PC.

Firms submitting files through NSCC (for themselves or for others). It is important for firms that will submit customer transaction data through NSCC to begin now to set up input and output procedures with NSCC (SIAC). This set-up is the standard process used by NSCC for any new type of data submission. You should complete the set-up well in advance of your actual testing. For more information, see the NSCC Important Notice dated July 9, 1997, (attached).

On the scheduled date, and for five business days thereafter, you will submit actual customer transaction data to the CTRS. The receipt will notify you of any errors detected, and you should correct such errors by submitting "Amend" or "Cancel" records in a subsequent file.

Firms submitting files through an intermediary. Most dealers that submit customer trade data through an intermediary -- that is, through another dealer or a service bureau -- will go through testing as part of their intermediary's testing. If you wish to receive the fax receipt, you must provide a fax number to the MSRB either through your intermediary or by notifying us.

Firms that do not effect more than one or two customer trades during the intermediary's test period should work with the intermediary to ensure that the reporting process will go smoothly for the actual types of trading that will be experienced throughout the year. MSRB will provide you with a test file to supplement your actual trades if you wish (see below).

Firms submitting files via the PC dial-in method. The MSRB-provided PC software will run under Windows 95 or Windows NT. As noted above, if you indicated you would like more information on this software and the dial-in method you will receive a separate mailing on the subject in July. MSRB plans to provide PC software to you at least two weeks before your testing begins. We will release this software in mid-August. The software will install itself on your PC.

TEST FILES

To simulate customer trade reporting, you may request the MSRB to mail you a diskette containing a test data file. You would transmit the file to CTRS and would receive the receipt in return. The file contains examples of correct and erroneous transactions, which the receipt/error message will describe.

In requesting the test file, please specify your submission method (directly to NSCC, through an intermediary to NSCC, or via PC). Also provide us with a point of contact, telephone numbers for voice and fax communication, and your mailing address. Test files will be available around August 1.

INTERPRETING TEST RESULTS

You will be required to retest your system and procedures if there are substantial deficiencies in the data submitted during the test week. We do not expect your data to be 100 per cent error-free, but if the error rate is high, or it seems that a reporting requirement was misinterpreted, retesting will be necessary. An example of a misunderstood requirement would be the reporting of transaction quantity as numbers of bonds (e.g., par = 50) rather than in dollars (e.g., par = 50,000, which is correct). MSRB staff will be available by telephone to assist if you have problems during the test period.

USER'S MANUAL

A CTRS User's Manual, with additional detailed information, will be available during the summer. The manual will expand on the material in this memorandum and will provide guidelines for certain key areas.

FOR MORE INFORMATION

Should you need more information in order to prepare for testing, write the MSRB at 1150 18th Street, NW, Suite 400, Washington DC 20036, or fax us at 202 872-0347, or call us at 202 223-9347.

(2) See "Reporting Customer Transactions to the Board: Rule G-14," MSRB Reports, Vol. 17 No. 1 (January 1997) at 3-8. See also "Specifications for Reporting Customer Transactions to the MSRB," MSRB Reports, Vol. 16 No. 3 (September 1996) at 10-16, which was distributed with minor revisions in MSRB's March 27, 1997 mailing to dealers.

(3) We will contact only dealers that indicated on the information form that they effect trades in municipal securities with customers.

ATTACHMENTS

A Changes to File Specifications

B How to Determine the Submitter ID, Submitter Site, and Version Number in the Header Record

C Error Codes and Messages

ATTACHMENT A

CHANGES TO FILE SPECIFICATIONS

Since the publication of the specifications for reporting customer transactions to the MSRB (4), the following changes have been made:

"CANCEL" AND "VERIFY" FORMAT

The specification for the "cancel/amend code"regarding "cancel" has been changed to make it clear 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 (5):

C=Cancel the record of the trade identified by the following control number. All other fields of the current record, except the dealer identifier, may be zeroes or blanks or may contain the values being canceled.

V=Verify that a transaction (identified by the control number in the following field) previously noted as questionable, is correct. All other fields of the current record, except the dealer identifier and control number/previous record reference, may be zeroes or blanks, or may contain the values being canceled.

 

VERIFICATION OF DOLLAR PRICE AND YIELD

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.

REVISED FORMAT FOR ERROR RECORDS IN RECEIPT/ERROR MESSAGE FILE

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.

Note that a draft list of error codes and messages is provided as a separate attachment.

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).

Record Type 2: "Description of Error" shown in Table 6 of the 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

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. (Note that a separate attachment describes how to obtain a valid submitter ID from the MSRB.)

• 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 two records in the receipt/error message file will be a pair of records, consisting of a description of the header error(s) followed by a copy of the header record that was submitted to CTRS.

REVISIONS TO CERTAIN FIELD TYPES AND LENGTHS
In the header record specification (Table 2), the "File sequential number" is a numeric (N) data type, not alphabetic (A) as originally shown.

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.)

(4) "Specifications for Reporting Customer Transactions to the MSRB," MSRB Reports, Vol. 16, No. 1 (September 1996) sy 10-16. Also included in MSRB's March 27, 1997 mailing to dealers.

(5) Underscore indicates new text; strikeout indicates deleted text.

ATTACHMENT B

HOW TO DETERMINE THE SUBMITTER ID, SUBMITTER SITE, AND VERSION NUMBER IN THE HEADER RECORD

The header record in files of customer transaction data submitted to the MSRB includes fields called "Submitter ID," "Submitter Site" and "Version Number." (6) The values of these fields are determined as follows.

Submitter ID
The submitter ID is a four-character identifier that may be chosen by the submitter (dealer or service bureau), provided that the submitter informs the MSRB of the ID, and the MSRB determines that it is unique within the CTRS. The submitter will inform the MSRB of the preferred ID by phone or mail during the process of being scheduled for testing.

Submitters typically will choose to use either their NSCC clearing number, their NASD executing broker symbol (MMID), or another symbol that they currently use in identifying files of inter-dealer transaction data to the NSCC (e.g., ABC2). If the submitter's preferred submitter ID is not unique within the CTRS, we will contact the submitter and arrange for a different ID to be used.

Submitter Site
The submitter site is a two-digit number. By default, the submitter site will be "01." If you are a submitter and you plan to use more than one type of computer to submit data to the CTRS, or to submit data to the CTRS from more than one physical location, please inform the MSRB of this fact. MSRB will assign higher submitter site codes to the additional computers or locations.

Version ID
The version ID identifies the version of MSRB's file format that the submitter is using. The version ID will be 00010 until the MSRB publishes and implements a later file format.

(6) Table 2 in "Specifications for Reporting Customer Transactions to the MSRB," MSRB Reports, Vol. 16, NO. 1 (September 1996) at 10-16. Also included in MSRB's March 27, 1997 mailing to dealers.

ATTACHMENT C

ERROR CODES AND MESSAGES

Following is a draft list of error codes and messages. The error codes are those that will appear in the faxed receipts and in the receipt/error message files. An updated list of error codes and messages will appear in the CTRS User's Manual, to be distributed during summer 1997.

Messages that appear on receipt/error message files by CTRS may be more tersely worded than those that appear on receipt/error message lists sent by fax, e.g., "Dealers capacity invalid - must be 'A' or 'P' " may be shortened to "Dealers capacity not 'A' or 'P'.

HEADER ERRORS

001 All records were successfully processed (no errors were found)

090 There were no records in this file
091 Header Record is missing. Validation process terminated

100 Submitter identifier missing
101 Invalid submitter identifier

110 Invalid submitter site

120 Invalid submission date
121 Submission date missing

130 Submission time missing
131 Invalid submission time

140 Invalid sequential file number

150 Invalid version identifier

160 File type missing
161 Invalid file type - must be "S", "R" or "T"

170 Record count received does not agree with header record count
171 Record count is not numeric
172 Record count is zero

Note: Header errors are described on the faxed receipt/error message report. If the header has a valid submitter and site number, CTRS creates a receipt/error message file which describes header errors in the same format as transaction errors. In this file immediately after the receipt record is an error description record with header error messages. The next record is an "error transaction record" containing a copy of the header data.

TRANSACTION ERRORS

180 CUSIP number missing
181 6 digit CUSIP is not a Municipal Issuer
182 9 digit CUSIP is not a valid Municipal Issue
183 Invalid CUSIP check digit

190 Trade Date missing
191 Trade Date invalid
192 Trade Date in the future

200 Time of trade missing
201 Time of trade invalid

210 Dealer identifier missing

220 Buy/sell indicator missing
221 Buy/sell indicator is not "B" or "S"

230 Par value missing
231 Par value is less than $1,000
232 Par value is not a multiple of $1,000
233 Par value is not numeric
234 Par value should be less than $20 million

240 Dollar price missing for RW trade
241 Dollar price and yield missing
242 Dollar price is less than $1.00
243 Dollar price is not numeric
244 Dollar price greater than $200.00
245 Dollar price and calculated dollar price do not agree
246 Dollar price must have decimal point

250 Yield missing for RW trade

251 Yield is less than 1% or greater than 30%
252 Yield is not numeric
253 Yield and calculated Yield do not agree
254 Yield must have decimal point

260 Dealers capacity missing
261 Dealers capacity invalid - must be "A" or "P"
262 Dealers identifier is all numeric
263 Dealers identifier is not alphabetic
264 Invalid dealer symbol

270 Commission missing for an agency trade
271 Commission is present for a principal trade
272 Commission is greater than 10%
273 Commission is not numeric
274 Commission must have decimal point

280 Settlement date is more than two years from current date
281 Settlement date is earlier than trade date
282 Settlement date is invalid

290 Cancel/amend code missing
291 Cancel/amend invalid must be "F", "C", "A" or "V"
292 No matching transaction for a cancel/amend or verify record

300 Possible duplicate inter-dealer trade
301 Duplicate trade

310 Previous transaction control number missing for cancel/amend or verify record

400 Additional errors are present - please analyze entire record