The MSRB Real-Time Transaction Reporting System (RTRS) serves the dual purposes of price transparency and market surveillance.  Because a comprehensive database of transactions is needed for the surveillance function of RTRS, MSRB Rule G-14, on transaction reporting, with limited exceptions, requires dealers to report all of their purchase-sale transactions to RTRS within fifteen minutes.  All reported transactions are entered into the RTRS surveillance database used by market regulators and enforcement agencies. However, the special nature of some transactions effects their value for price transparency and the ability of dealers to meet the fifteen minute reporting deadline. To address these issues, RTRS was designed so that a dealer can code a specific transaction report with a “special condition indicator” to designate the transaction as being subject to a special condition.[1]

TRANSACTIONS EXECUTED WITH SPECIAL PRICING CONDITIONS

Three trading scenarios recently have generated questions from dealers and users of the MSRB price transparency products.  Each of the three trading scenarios described below represents situations where the transaction executed is not a typical arms-length transaction negotiated in the secondary market and thus may be a misleading indicator of the market value of a security.  To clarify transaction reporting requirements and to prevent publication of a potentially misleading price, dealers are required to report these transactions with the M9c0 special condition indicator.[2] Transactions reported with this special condition indicator are entered into the surveillance database but suppressed from price dissemination to ensure that transparency products do not include prices that might be confusing or misleading.

Customer Repurchase Agreement Transactions

Some dealers have programs allowing customers to finance municipal securities positions with repurchase agreements (“repos”). Typically, a bona fide repo consists of two transactions whereby a dealer will sell securities to a customer and agree to repurchase the securities on a future date at a pre-determined price that will produce an agreed-upon rate of return. Both the sale and purchase transactions resulting from a customer repo do not represent typical arms-length transactions negotiated in the secondary market and are therefore required to be reported with the M9c0 special condition indicator.

UIT-Related Transactions

Dealers sponsoring Unit Investment Trusts (“UIT”) or similar programs sometimes purchase securities through several transactions and deposit such securities into an “accumulation” account. After the accumulation account contains the necessary securities for the UIT, the dealer transfers the securities from the accumulation account into the UIT. Purchases of securities for an accumulation account are presumably done at market value and are required to be reported normally. The transfer of securities out of the accumulation account and into the UIT, however, does not represent a typical arms-length transaction negotiated in the secondary market. Dealers are required to report the subsequent transfer of securities from the accumulation account to the UIT with the M9c0 special condition indicator.

TOB Program-Related Transactions

Dealers sponsoring tender option bond programs (“TOB Programs”) for customers sometimes transfer securities previously sold to a customer into a derivative trust from which derivative products are created. If the customer sells the securities held in the derivative trust, the trust is liquidated and the securities are reconstituted from the derivative products and transferred back to the customer. The transfer of securities into the derivative trust and the transfer of securities back to the customer upon liquidation of the trust do not represent typical arms-length transactions negotiated in the secondary market. Such transactions are required to be reported using the M9c0 special condition indicator.[3]

INTER-DEALER TRANSACTIONS REPORTED “LATE”

Inter-dealer transaction reporting is accomplished by both the purchasing and selling dealers submitting the trade to the Depository Trust and Clearing Corporation’s (DTCC) automated comparison system (RTTM) following DTCC’s procedures. RTTM forwards information about the transaction to RTRS.  The inter-dealer trade processing situations described below are the subject of dealer questions and currently result in dealers being charged with “late” reporting or reporting of a trade date and time that differs from the date and time of trade execution.  To allow dealers to report these types of transactions without receiving a late error and to allow enforcement agencies to identify these trades as reported under special circumstances, the MSRB has added two new special condition indicators.[4] New special condition indicator Mc40 is used to identify certain inter-dealer transactions that are ineligible for comparison on trade date, and new special condition indicator Mc50 is used to identify resubmissions of certain uncompared inter-dealer transactions that have been cancelled by RTTM. Described below are the procedures for reporting transactions arising in three inter-dealer transaction reporting scenarios using the new special condition indicators.

Inter-Dealer Ineligible on Trade Date

Certain inter-dealer transactions are not able to be submitted to RTTM on trade date or with the accurate trade date either because all information necessary for comparison is not available or because the trade date is not a “valid” trade date in RTTM. The two inter-dealer trading scenarios described below are required to be reported using the new Mc40 special condition indicator.

VRDO Ineligible on Trade Date

On occasion, inter-dealer secondary market transactions are effected in variable rate demand obligations (VRDOs) in which the interest rate reset date occurs between trade date and the time of settlement. Since dealers in this scenario cannot calculate accrued interest or final money on trade date, they cannot process the trade through RTTM until the interest rate reset has occurred. To report such transactions, both dealers that are party to the transaction are required to report the transaction by the end of the day that the interest rate reset occurs, including the trade date and time that the original trade was executed. Both dealers are required to include the new Mc40 special condition indicator that causes RTRS not to score either dealer late. Transactions reported using this procedure are disseminated without a special condition indicator and the trade reports reflect the original trade date and time.

Invalid RTTM Trade Dates

Dealers sometimes execute inter-dealer transactions on weekends and on certain holidays that are not valid RTTM trade dates. Such trades cannot be reported to RTRS using the actual trade date if they occur on a weekend or holiday. To accomplish automated comparison and transaction reporting of such transactions, dealers are required to submit these inter-dealer transactions to RTTM no later than fifteen minutes after the start of the next RTRS Business Day and to include a trade date and time that represents the next earliest “valid” values that can be submitted.[5] Dealers also are required to include the new Mc40 special condition indicator that allows RTRS to identify these transactions so that enforcement agencies can be alerted to the fact that the trade reports were made under special circumstances using a special trade date and time. RTRS disseminates these trade reports without a special condition indicator and the trade report includes the trade date and time reflecting the next earliest “valid” values that can be submitted.[6]

Resubmission of an RTTM Cancel

A dealer may submit an inter-dealer trade to RTTM and find that the contra-party fails to report its side of the trade.  Such “uncompared” trades are not disseminated by RTRS on price transparency products.  After two days, RTTM removes the uncompared trade report from its system and the dealer originally submitting the trade must resubmit the transaction in a second attempt to obtain a comparison with its contra-party, which currently results in RTRS scoring the resubmitted trade report “late.”

The dealer that originally submitted information to RTTM is required to resubmit identical information about the transaction in the second attempt to compare and report the trade by the end of the day after RTTM cancels the trade. The resubmitting dealer also is required to include the new Mc50 special condition indicator that causes RTRS to not score the resubmitting dealer late. The indicator may only be used by a dealer resubmitting the exact same trade information for the same trade.[7] For example, the contra-party that failed to submit its side to the trade accurately, thus preventing comparison of the transaction, is not allowed to use the indicator. RTRS disseminates trade reports made under this procedure without a special condition indicator once RTTM compares the trade and the trade report reflects the original trade date and time.

[1] See Specifications for Real-Time Reporting of Municipal Securities Transactions Section 4.3.2.

[2] In addition to the special trading situations identified in this notice, the M9c0 special condition indicator, “away from market – other reason,” is required to be included on a trade report if the transaction price differs substantially from the market price for multiple reasons or for a reason not covered by another special condition indicator.

[3] In some cases, the transfer of securities into the derivative trust and the transfer of securities back to the customer upon liquidation of the trust do not represent purchase-sale transactions due to the terms of the trust agreement.  MSRB rules on transaction reporting do not require a dealer to report a transfer of securities to RTRS that is not a purchase-sale transaction in municipal securities.

[4] See MSRB Notice 2007-25 (August 13, 2007).

[5] The MSRB previously provided an example of a trade date and time that would be included on a trade report using this procedure.  See “Reporting of Inter-Dealer Transactions That Occur Outside of RTRS Business Day Hours or on Invalid RTTM Trade Dates,” MSRB Notice 2007-12 (March 23, 2007).

[6] Using this procedure will result in transactions reported with a trade date and time that differs from what is recorded in a dealer’s books and records.  Dealers are reminded that books and records are required to reflect the date and time of trade execution.

[7] The resubmitting dealer would not be required to resubmit the same reference number or preparation time on the resubmitted transaction; however, other information about the transaction, such as price, quantity, trade date and time, would be required to be identical to information included in the original trade submission.

Purchase of new issue from issuer. This is in response to your letter in which you ask whether Board rule G-17, on fair dealing, or any other rule, regulation or federal law, requires an underwriter to purchase a bond issue from a municipal securities issuer at a “fair price.”

Rule G-17 states that, in the conduct of its municipal securities business, each broker, dealer and municipal securities dealer shall deal fairly with all persons and shall not engage in any deceptive, dishonest, or unfair practice. Thus, the rule requires dealers to deal fairly with issuers in connection with the underwriting of their municipal securities.  Whether or not an underwriter has dealt fairly with an issuer is dependent upon the facts and circumstances of an underwriting and cannot be addressed simply by virtue of the price of the issue. For example, in a competitive underwriting where an issuer reserves the right to reject all bids, a dealer submits a bid at a net interest cost it believes will enable it to successfully market the issue to investors. One could not view a dealer as having violated rule G-17 just because it did not submit a bid that the issuer considers fair. On the other hand, when a dealer is negotiating the underwriting of municipal securities, a dealer has an obligation to negotiate in good faith with the issuer. If the dealer represents to the issuer that it is providing the best market price available on this issue, and this is not the case, the dealer may violate rule G-17. Also, if the dealer knows the issuer is unsophisticated or otherwise depending on the dealer as its sole source of market information, the dealer’s duty under rule G-17 is to ensure that the issuer is treated fairly, specifically in light of the relationship of reliance that exists between the issuer and the underwriter. MSRB interpretation of December 1, 1997.

MSRB TRANSACTION REPORTING PROGRAM

QUESTIONS AND ANSWERS

October 1997

Most of these questions and answers were included in an MSRB mailing sent to each broker, dealer and municipal securities dealer on March 31, 1997. Questions numbered 60 and higher have been added since that mailing.

These questions and answers touch upon the following topics:

GENERAL QUESTIONS

CUSTOMER TRANSACTION REPORTING

• Preparing for Customer Transaction Reporting
• Completing the Customer Transaction Reporting Form
• Price and Yield
• Settlement Date
• Agency and Principal Transactions
• Control Numbers
• Records Amending and Cancelling Trades
• Submission of Files
• File Forwarding by NSCC
• Transaction Reporting to MSRB Using MSRB's Dial-Up Facility
• Testing Customer Transaction Reporting with the MSRB
• Record and File Format Questions
• Other Questions

 

INTER-DEALER TRANSACTION REPORTING

• Accrued Interest
• Executing Broker Symbol
• Time of Trade
• Problems in Inter-Dealer Transaction Reporting

 

QUESTIONS ADDED AFTER MARCH 1997

• Yield
• Commission
• File Format

 

GENERAL QUESTIONS

1. Q: What is the purpose of the requirement in MSRB rule G-14 to report each municipal securities transaction to the MSRB?

A: One purpose of the requirement is to make transaction information (e.g., prices and volumes) available to market participants. This is generally known as the "transparency" function of the MSRB Transaction Reporting Program. It is being accomplished at this time through a daily report that shows information such as the high, low and average prices of municipal securities that were traded four or more times on the previous day. A second, equally important, function of the program is market surveillance. Each transaction reported is entered into a database that essentially is an audit trail of transactions. This database is available only to the SEC, the NASD and other regulators charged with surveillance of the market. Transparency and surveillance functions have long been in existence in other major U.S. securities markets. The MSRB is responsible to bring these functions to full implementation in the municipal securities market.

2. Q: Have the requirements of G-14 been approved by the Securities and Exchange Commission?

A: Yes. The Commission approved the transaction reporting requirements described here on November 29, 1996 (Securities and Exchange Act Release No. 37998; see also MSRB Reports, Vol. 17, No. 1 [January 1997] at 3-8).

3. Q: When does compliance with these functions have to take place?

A: Inter-dealer transaction reporting began on January 23, 1995, with an amendment to rule G-14. (See MSRB Reports, Vol. 14, No. 5 [December 1994] at 3-6.) Each dealer should now be well aware of the specific requirements of reporting inter-dealer transactions. A number of notices have appeared in MSRB Reports indicating areas where attention is specifically needed to improve reporting. (See, e.g., MSRB Reports, Vol. 16, No. 2 [June 1996] at 9-12.) Customer transaction reporting begins with mandatory testing in July 1997 and full program operations are planned for early 1998.

4. Q: How does a dealer report municipal securities transactions to the MSRB?

A: The answer to the question differs depending upon whether the transaction is with another dealer ("inter-dealer transaction") or with an entity that is not a dealer ("customer transaction"). Inter-dealer transactions are reported by submitting the required transaction information, in proper form, to the automated comparison system for municipal securities. Dealers achieve both the automated comparison function and the transaction reporting function by submitting a single file to the comparison system. For customer transactions, dealers must produce a computer-readable file specifically for the MSRB and transmit that file to the MSRB each night.

CUSTOMER TRANSACTION REPORTING

Preparing for Customer Transaction Reporting

5. Q: What should dealers be doing now to prepare for customer transaction reporting?

A: After becoming familiar with the G-14 requirements, dealers should either be making changes to their computer systems necessary to produce and transmit customer transaction files, or making arrangements with clearing brokers or service bureaus who will do this on their behalf. Although the mandatory testing period does not begin until summer 1997, preparations should be made now.

6. Q: Is there anything else that a dealer can do now to prepare?

A: Each dealer should complete and return a Customer Transaction Reporting Form.

Completing the Customer Transaction Reporting Form

7. Q: In completing the information form for customer transaction reporting, whom should I identify as the "primary contact with the MSRB for purposes of customer transaction reporting"? Should I name our Municipal Securities Department Director or our Compliance Officer?

A: The primary contact should be the individual who will be ultimately responsible for ensuring that MSRB mailings and other communications (e.g., phone calls) on this subject will reach the appropriate persons in the firm. The primary contact will be the MSRB's initial contact regarding tests of customer transaction reporting.

8. Q: Who should be identified as the "point-of-contact regarding technical matters"?

A: The MSRB will contact this person on computer-related matters such as the firm's telecommunications and methods for transmitting files, how many characters each field should have in the record of a trade, what headers must be included in the files, etc.

9. Q: How do the above topics differ from the person designated for questions about the "correctness of trade details"?

A: A question about trade details might arise, for example, if MSRB calculates a yield that differs substantially from the dealer-reported yield for the same trade. MSRB staff may ask the dealer what it used to derive yield from dollar price to account for the difference. In general, the contact for "correctness of trade details" will be the person called if the question is about the substantive information being provided about a transaction.

10. Q: In response to the question on page one of the form, my firm does not effect municipal securities transactions, does not intend to do so and does not intend to submit transactions to the MSRB for other dealers. I will check the appropriate box and return the form. What should I do if my firm's plans later change?

A: Since all transactions in municipal securities will have to be reported to the MSRB, if a firm decides to begin effecting transactions or to submit transaction data, it should immediately contact the MSRB to obtain and complete this form.

11. Q: What is the "dial-up transmission facility" referred to in the form?

A: Most dealers will send customer trade data to the MSRB through National Securities Clearing Corporation (NSCC), but some low-volume transmissions may be done by dialing the MSRB's computer directly using a personal computer and telephone modem. By checking the appropriate box on the form, you may request more information about the dial-up facility from the MSRB. In response, the MSRB will mail information before testing begins that describes how the dial-up facility can be installed and used to report customer trades. (More detailed questions and answers about the dial-up facility are found below.)

12. Q: Where can I find a description of the data elements that must be included in transaction records?

A: The MSRB document entitled "File and Record Specifications for Reporting Customer Transactions" defines the data elements and provides format specifications for transaction records and files.

Price and Yield

13. Q: Both price and yield are required to be included for transactions on which the settlement date is known. Why is that?

A: One of the most difficult problems in collecting and disseminating accurate information on municipal securities transactions is that there are approximately 1.3 million different municipal securities. Typographical errors in trade input, for example, are always possible, and since there is generally not a stream of transaction data coming in on a specific issue, it is difficult for the system collecting the information to mechanically check reported information to ensure that it is not a likely input error. This is particularly important when it is recognized that the price information collected will be disseminated and reviewed by market participants on the next day and may be used as part of trading or investment decisions. Requiring both yield and price, along with the CUSIP number of the issue being reported, will allow the MSRB to mechanically perform mathematical checks that will help to ensure that the information being reported makes sense, given the coupon, maturity date and call features of the security. Other means of checking data accuracy also will be employed. For example, the CUSIP check digit is required to guard against typographical errors in the entry of CUSIP numbers. (More questions and answers about error correction are found below.)

14. Q: What if a yield cannot not be computed for a transaction done on a dollar price basis, for example, because the trade is in a variable rate security or in a defaulted security?

A: The trade may be submitted using a dollar price only in these cases. Note, however, that if the security is not known to the MSRB system as one which is a variable rate instrument or in default, the MSRB may contact you to ensure that its information about the security is correct and so that subsequent transaction input in the security will not be questioned in the future.

See also questions 60 and 61.

Settlement Date

15. Q: What if settlement for a transaction is not known because the transaction is in a new issue and settlement date has not been set?

A: The transaction should be reported with a yield or a dollar price and without a settlement date.

16. Q: If the settlement date for the transaction is determined after a submission is made without a settlement date, should the dealer report revised trade information to the MSRB?

A: No. If the only change in the transaction information is the settlement date on a new issue, the dealer should not send an amended transaction report. Once the settlement date for the new issue becomes known to the MSRB, that settlement date will be included in the transaction data automatically.

Agency and Principal Transactions

17. Q: When reporting dollar prices on agency transactions, should the effect of commissions be included in the dollar price submitted?

A: No. There is a separate field for submitting the commission amount on agency transactions. The MSRB will include the effect of the commission in the dollar price when aggregating principal and agency transactions and reporting price information on the daily report. There should be no "commissions" on principal transactions so that the dollar price given on principal transactions should be the net transaction dollar price to the customer.

18. Q: How should commissions be reported?

A: Commission is reported in dollars per $100 par value.

See also questions 62 and 63.

Control Numbers

19. Q: The file format requires each transaction submitted by a dealer to have a unique "control number" (unique for the dealer) that is no longer than 20 characters and that may be composed of alpha and/or numeric characters. Why is this necessary?

A: The control number given by the dealer is the mechanism by which the dealer identifies a specific transaction to the Transaction Reporting System. The dealer chooses its own numbering system; however, the control number for a transaction must be unique for the dealer within a three-year period. For example, if a dealer submits two different transactions with the same control number, the system may reject the second transaction. Use of the control number is critical so that the dealer may correct information submitted in error to the system. The MSRB also will use the dealer's control number to report back information to the dealer about the transaction.

Records Amending and Cancelling Trades

20. Q: Under what circumstances would a dealer need to correct information about a transaction submitted to the system?

A: An example might be a dealer who has made an input error resulting in the wrong price or yield being submitted for a transaction. Note that it is important for these errors to be corrected as soon as possible so that the audit trail and surveillance database is correct. Note also that it is important for errors like these to be minimized since the prices reported on trade date will be used for the daily reports appearing on the next business day.

21. Q: What will the MSRB do if it discovers a probable input error that has resulted in submitted transaction information?

A: As part of the daily process of collecting transaction information from dealers, the MSRB will send to each dealer that submitted transaction information a receipt with messages identifying errors in transactions that failed to meet acceptance testing, together with a copy of all such input records.

22 Q: What should happen next?

A: If the dealer finds that the record should be amended -- for example, because of a typographical error in the price -- he or she will submit an "Amend" record as soon as possible (i.e., a record with "A" as the "Cancel/Amend Code"). The "Amend" record must include the same dealer control number as the first report of the trade and must include all of the correct information about the trade. If the dealer finds that the questioned record was correct -- as might happen if the dealer knows features about the bond that affect the price/yield calculation and that are not in the MSRB's database -- a "Verify" record should be submitted, including the original dealer control number, to indicate that it is correct.

23. Q: What happens if I try to amend a transaction with a control number that I have not previously reported?

A: If a transaction is submitted with a "Cancel/Amend Code" of "A" and there is not an existing transaction in the database with that control number, the transaction information will be rejected -- that is, returned to the dealer for correction.

24. Q: Can I amend any information about a trade that I have previously reported?

A: No. The following fields cannot be amended: dealer identity, CUSIP number, and transaction control number. If you report a trade with an error in one of these fields, you should cancel the transaction report, as described below, and then report the trade using a new control number.

25. Q: Under what circumstances would a transaction be "cancelled" in the system and how is that done?

A: There may be limited numbers of instances in which customer transactions are reported, but the transactions later must be cancelled with customers due to circumstances beyond the dealer's control (for example, a new issue is cancelled). In this case, the dealer must submit a record with the control number of the transaction and with the "Cancel/Amend Code" set to "C" for "Cancel." Doing so will allow MSRB to indicate the transaction as cancelled in the surveillance database so that the database is accurate.

26. Q: For how long after initial submission is it possible for dealers to amend or cancel transactions that have been entered into the system?

A: This can be done for a period of three months after initial submission. However, for new issues for which there is no settlement date, it will be possible to submit cancellations until three months after the settlement date of the issue. Note that, while some numbers of cancellations and corrections are inevitable, it is important for dealers to minimize the need for these types of corrections by making sure that procedures are in place for reporting necessary information correctly in the initial submission.

Submission of Files

27. Q: When must a transaction be reported to the MSRB?

A: A transaction record, in the correct format, must reach the MSRB by midnight on trade date.

28. Q: How are these transaction records sent to the MSRB?

A: The records are put into a file with appropriate header information. The resulting file is sent to the MSRB.

29. Q: My firm is a clearing broker and will be submitting a file each day on behalf of many of our correspondents. Is there any special way in which the records in the file should be organized?

A: No. As long as the header information is correct and the information in each record is correct, the records within the file can be in any order. The header identifies the party submitting the file; the records may pertain to any number of executing dealers.

File Forwarding by NSCC

30. Q: My organization processes thousands of customer transactions in municipal transactions each day. How can such a large file be sent to the MSRB?

A: National Securities Clearing Corporation is providing its participants the ability to send the MSRB customer transaction file to NSCC along with other types of files that are sent to NSCC each day. NSCC will forward the MSRB customer transaction file to the MSRB.

31. Q: My firm uses another broker-dealer for clearing and processing municipal securities transactions. The clearing broker submits my inter-dealer transactions to NSCC on my behalf. Can the clearing broker submit my customer transaction reports to NSCC for forwarding on to the MSRB on my behalf?

A: Yes. The clearing broker can submit transaction reports for dealers for which it clears transactions. Note that the dealer effecting transactions is responsible for the clearing broker's performance in this regard. You should talk with your clearing broker now to ensure that it will provide this service.

32. Q: My firm uses a service bureau to submit inter-dealer transaction information to NSCC. Can the service bureau also submit customer transaction files to NSCC for forwarding to the MSRB?

A: Yes. As in the previous answer, the dealer effecting transactions is responsible to report the transactions correctly.

33. Q: Are there any special requirements for formatting the file to NSCC and getting the file to NSCC?

A: Yes. You should review NSCC's April 2, 1997 Important Notice on the interface requirements for customer transaction reporting (Notice No. A-4571 and P&S 4155). Similarly, if a clearing broker or service bureau will be sending your MSRB customer transaction files to NSCC for forwarding to the MSRB, they should ensure that the files can be sent in the correct format.

34. Q: Will customer transaction records submitted to NSCC for forwarding to the MSRB be included in the automated comparison system?

A: No. The MSRB customer transaction file sent to NSCC for forwarding to the MSRB is a totally separate file than the inter-dealer transactions and other files sent to NSCC for clearance and settlement purposes. NSCC will not process data in the MSRB customer transaction files, but will only forward the files to the MSRB. The use of NSCC for this purpose will allow dealers and service bureaus to use existing telecommunication channels set up between dealers and NSCC and between NSCC and the MSRB. Thus, it should provide efficiencies, especially for dealers that have many customer transactions each day. (An additional question on this subject is given below, under "Other Questions.")

Transaction Reporting to MSRB Using MSRB's Dial-Up Facility

35. Q: My firm submits its inter-dealer transactions to NSCC through a dial-up terminal or personal computer. Can I use this method of file transfer to transmit customer transaction files to NSCC for forwarding to the MSRB?

A: No; as noted in NSCC's Important Notice, all dial-up connections will be directly to the MSRB.

36. Q: How will this be done?

A: MSRB will offer a facility whereby dealers may send relatively small files directly to the MSRB by using a personal computer and a standard telephone modem, such as those made by Hayes, U.S. Robotics and others. The MSRB will provide telecommunications software by summer 1997 to dealers who ask for this service. Please note that this software will run only on computers using the Windows 95 or Windows NT operating systems. Also note that dealers using this method of transmitting files directly to the MSRB will still need a means to generate files from their own records that meet MSRB file and record format requirements.

Testing Customer Transaction Reporting with the MSRB

37. Q: What is the purpose of the mandatory testing?

A: The purpose of testing is to ensure each dealer that its own system can produce files containing the required information in the proper format, that it is able to correct erroneous input, and so forth. Testing is mandatory so that all dealers will be ready before the reporting requirement becomes effective in January 1998.

38. Q: What is the date for dealers to test their customer transaction reporting capabilities with the MSRB?

A: Mandatory testing will begin in July 1997. The MSRB plans to schedule the first tests with the dealers that have the greatest volume of customer trades and with service bureaus, followed by the lower-volume dealers. The MSRB will publicize the testing schedule before testing begins.

39. Q: What will happen during the test?

A: First, the MSRB will contact the designated primary contact person listed on your organization's MSRB Transaction Reporting form. Information will be obtained on how the organization will be submitting data, a fax number for the dealer to receive receipt/error logs from the MSRB, and technical details. Dates will be chosen to run your test. The contact person will arrange to send test files to the MSRB, using either NSCC or the MSRB dial-up facility, to establish that the telecommunications link is working, and that the trade records meet the format specifications.

40. Q: How long will the test last?

A: Each test cycle should take approximately five days. However, it may take more than one test cycle for a dealer to validate its methodology for creating files in the proper formats and for handling trade data corrections.

41. Q: Will there be special formats and test procedures for submission through NSCC?

A: Yes. As part of testing the communications, dealers and service bureaus will go through NSCC's usual procedures for setting up transmission of a new data stream or "SysID" - verifying that the file header meets Datatrak specifications, etc. Details are provided in the NSCC Important Notice previously mentioned (Notice No. A-4571 and P&S 4155).

Record and File Format Questions

42. Q: What is the format for the computer-readable file that must be sent to the MSRB each day to comply with the customer transaction reporting requirement?

A: For files sent directly to the MSRB via the MSRB dial-up facility, the physical formats for transaction records, and for the file header record that must precede them, are specified in the MSRB document entitled "File and Record Specifications for Reporting Customer Transactions." Files sent to NSCC will need to be in the format specified by NSCC. See NSCC's April 1997 Important Notice.

See also questions 64 through 66.

Other Questions

43. Q: Is the customer's identity included anywhere in the information reported?

A: No. The customer's identity is never submitted in reports of customer transactions. Each record must correctly indicate whether the transaction was a sale to a customer or a purchase from a customer, whether it is a principal or agency transaction, and certain other information.

44. Q: Are institutional and retail customer transactions reported in the same way?

A: Yes.

45. Q: How should the "Buy/Sell" code be reported?

A: If the dealer has sold securities to the customer, report this as "S" (sell). If the dealer has purchased securities from the customer, report this as "B" (buy).

46. Q: May I include my inter-dealer trades in the customer trade file I send to the MSRB?

A: No. All files submitted as part of a dealer's customer transaction file must report only customer transactions -- no inter-dealer transactions may be included.

INTER-DEALER TRANSACTION REPORTING

47. Q: How are inter-dealer transactions reported to the MSRB?

A: By submitting the transactions on trade date, to the automated comparison system, in the format and manner required by that system to obtain a comparison on the night of trade date. NSCC provides this information to the MSRB to accomplish transaction reporting for those trades. (Please note that these requirements are currently in effect under MSRB rule G-14.)

48. Q: What items are required by rule G-14, in addition to the items necessary to obtain an automated comparison of an inter-dealer trade on the night of trade date?

A: Specific items that are mandatory, in addition, to the information required for automated comparison, are: (i) accrued interest, on any transaction in which the settlement date is known; (ii) executing broker identity; and (iii) time of trade.

Accrued Interest

49. Q: Why does the MSRB need accrued interest in inter-dealer transaction reports?

A: For most transactions reported through the automated comparison system, dealers report a final money figure in lieu of a dollar price or yield. The MSRB derives a dollar price for these transactions by subtracting the reported accrued interest and dividing the result by the par amount traded. Therefore, if accrued interest is not reported correctly, the resulting dollar price may not be accurate.

Executing Broker Symbol

50. Q: Why does the MSRB need an "executing broker symbol"?

A: This symbol is used for the audit trail function. It identifies the dealer that actually effected the transactions (in contrast to the dealer that submitted the trade to NSCC or who cleared the trade). It is particularly important for dealer identification when one dealer clears for several other dealers. The dealer that actually effected the transaction should be the one identified with this symbol.

51. Q: What symbol should be used for executing broker identity?

A: The four-character symbol of the firm or bank assigned by the NASD, for example, ABCD.

52. Q: Is it permissible for my firm to use our NSCC clearing number (e.g., 1234) instead of this symbol? In our case, this would serve the same purpose since we only clear for ourselves.

A: No. The four-character alphabetic symbol is required, as it is the standard identifier used in the surveillance database. Note that, when the customer reporting phase of the Program becomes operational, this NASD-assigned symbol will be the primary identifier.

53. Q: My organization does not have one of these symbols. Should we just use the symbol of the dealer that we clear through?

A: No, if your organization is a broker, dealer or municipal securities dealer and it is effecting trades in municipal securities (with other dealers or with customers), it must use its own symbol.

54. Q: How does a dealer obtain an NASD-assigned symbol if it does not already have one?

A: Call NASD Subscriber Services at (800) 777-5606 and explain that you need a symbol for reporting municipal securities transactions.

55. Q: Will the NASD assign a symbol, even though my organization is a dealer bank?

A: Yes.

Time of Trade

56. Q: Why does the MSRB need the time of trade?

A: This information is also needed for audit trail purposes. It is not currently used in the transparency component of the program.

57. Q: How is time of trade submitted for inter-dealer transactions?

A: It is submitted in military format (e.g., 1400 for 2:00 p.m.) and in terms of Eastern time.

Problems in Inter-Dealer Transaction Reporting

58. Q: What kind of problems has the MSRB seen in the inter-dealer transaction information submitted under rule G-14?

A: For the daily report generated by the Program, only compared transactions can be used for generating price and volume information. It accordingly is very important for dealers to ensure that their procedures for reporting inter-dealer transactions are designed to submit correct information reliably to the automated comparison system. A significant number of the following types of transaction in the automated comparison system indicates that a dealer is having problems that require a review of its procedures and corrective action: (i) stamped advisories; (ii) "as of" submissions; (iii) "demand-as-of" submissions coming in against the dealer; (iv) compared transactions that are deleted using either the "one-sided delete" function or using the "withhold" function.

59. Q: My firm clears through a clearing broker. When my firm does trades with another firm that also uses that same clearing broker, must that transaction be reported to the MSRB by submitting the trade to the automated comparison system?

A: Yes. Note that the submission to the automated comparison system is also required in this instance by rule G-12(f) on automated comparison.

QUESTIONS ADDED AFTER MARCH 1997

Yield

60. Q: Should I report to the MSRB the transactions's yield to maturity or another yield -- yield to first call, yield to par call, etc.? My system calculates several yields for use in customer confirmations.

A: Report the yield as required by MSRB rule G-15(a) for customer confirmations. Rule G-15(a) in most cases requires the yield to be computed to the lower of call or nominal maturity date. Exception: If the transaction was effected at par, the yield (coupon rate) should be reported on the customer trade record, even though rule G-15(a) allows the yield to be omitted from the confirmation in such a case.

If reporting the yield is not possible because the transaction was done on a dollar price basis and no settlement date has been set for a "when-issued" security, leave the yield blank or enter zero.

61. Q: How should I report negative yield?

A: Enter a negative number in the "yield" field. The minus sign may precede or follow the number, as long as it is inside the defined field area.

Commission

62. Q: Should the effect of the commission be reported in the yield?

A: Yes. You should report as yield the same "net" yield that is reported on customer confirmations. Therefore, the reported yield should include the effect of any commission (see MSRB rule G-15(a)).

63. Q: Should miscellaneous fees such as transaction fees be included in the commission field or elsewhere? If the sales representative receives a portion of the firm's profit, should that portion be reported?

A: No. Neither miscellaneous fees nor sales representatives' portions should be reported.

File format

64. Q: Can I include binary data in the customer transaction file, along with ASCII data?

A: No. Binary data should not be included, even in the unused portions of the record. Including binary data will likely cause errors such as skipped records when MSRB processes the file. 
 

Q: The MSRB file header record requires a "version number." What should be put here?

A: This field identifies the version of the MSRB format specification that applies to the file. Initially, use '0010' here.

65. Q: The header record requires a "record count" field. What should be put here?

A: Put here the count of the number of transactions being reported in this file. Do not count the header record(s). Depending on the format used, the record count is the same as the number of physical transaction records or one-half the number of physical transaction records.

66. Q: If the header record of a transaction file contains errors, how will MSRB inform the submitter of this fact?

A: If the header of a file forwarded by NSCC does not identify a submitter and site known to the MSRB, then MSRB staff will ask NSCC to follow up. (MSRB will not accept any direct submissions by dial-up from unknown parties.) Otherwise, MSRB will send a receipt/error message file or fax to the submitter. The header errors will be identified in the file in the first two records following the receipt record, using the same format as for transaction detail errors.

Copyright 2000 Municipal Securities Rulemaking Board. All Rights Reserved. Terms and Conditions of Use.