May 15, 2000

Mr. Jonathan Katz
Securities and Exchange Commission
450 Fifth Street N.W.
Washington, DC

Reference File No. 4-430

Dear Mr. Katz,

The Financial Information Forum is pleased to offer comments in response to the above referenced notice relating to the securities industry conversion from fractional to decimal pricing. FIF is an industry organization that focuses on issues that impact brokerage information systems. Our participants include broker/dealers, exchanges, market data vendors, computer service bureaus and others.

Market data vendors have been working on expansion of their systems and appear ready for the increased traffic. Further, the traditional flexibility of their systems would permit the handling of some securities in fractions and some in decimals. However, the order systems of service bureaus were built on the assumption of price increment uniformity that is characteristic of today's markets. The Dual Price scenario described in the SEC document is a significant change from the original conversion plan and presents a significant challenge to these systems which necessitates a major amount of development work.

1. Is it feasible to begin Dual Pricing by September 4, 2000? If it is feasible, should trading in all exchange-listed securities be in nickel or penny increments? If it is not feasible to begin Dual Pricing by September 4, 2000, why not?

It is not feasible to begin Dual Pricing by September 4, 2000. Brokerage systems that receive, route and process investors orders assume a high degree of uniformity in price formats. These systems perform a number of edits on the front end when orders are received by customers. Such edits are necessary to minimize the possibility that these orders will not be rejected when routed to subsequent execution points. Since the vast majority of listed and Nasdaq securities are priced in sixteenths today, these systems assume sixteenths pricing as the default price denominator. When the conversion to decimalization is completed, the systems will use a new, decimal format (most likely one cent) as the default parameter.

The most difficult part of the decimal conversion occurs when some securities are priced in decimals while other continue in fractions. To address the conversion process, brokerage order systems are being developed to include a temporary exception table that will identify the specific securities trading in decimals. When the system identifies an order as related to a decimal security, editing for that specific order will be done on an exception basis. For this reason, it is essential that the number of decimal securities be kept small in order to minimize the amount of exception processing. The systems development work done by brokerage firms and service bureaus to prepare for decimalization has generally been based on the assumption the number of decimal-priced securities prior to full conversion will be small and exception routines have been written to handle decimal-priced orders.

2. What, if any, system changes or other steps would be necessary to implement Dual Pricing by this September 4, 2000 deadline? What type of changes would need to be made to the systems of securities firms, investment companies and vendors? What would be the impact on systems capacity? In light of your answers to the foregoing questions, what changes would need to be made to the current decimals testing schedule?

Dual Pricing would create a new and extensive requirement for brokerage order systems. Systems would need to incorporate a front-end database for the thousands of securities that would be decimal-priced during the conversion process. It would not be possible to design, develop and implement such data bases prior to September 4, 2000. Further, the processing needed to differentiate securities pricing for thousands of securities in the Dual Pricing scenario creates a new function step in order processing that increases capacity requirements and adds to order processing time.

While our comments have been focused on order systems, it should be noted that the same implementation issue would apply to any system that uses real-time market data. While market data vendors typically can accommodate a mix of fractional and decimal data, it is not known how user applications might be impacted by the need to differentiate pricing for thousands of securities.

Dual Pricing was not a part of the decimal conversion plan and it would be impossible to implement a Dual Price approach on order systems without extending the conversion schedule by at least six months.

3. Is the risk of customer confusion because of Dual Pricing significant, and if so, how should it be addressed?

The potential for customer confusion is great. We do not believe that most customers can readily identify a security as listed on an exchange or traded on Nasdaq. Further, the time available to educate customers prior to September 4, 2000, is extremely short. Given a high degree of investor confusion and the lack of appropriate order system edits, the numbers of order errors and order rejections will increase. If the quality of customer order handing decreases, then investor confidence in the markets will also be negatively impacted. Dual Pricing is a high-risk step that should not be a part of the conversion plan.

4. If commenters believe that implementing Dual Pricing by September 4, 2000, is not feasible, what date(s) is(are) feasible to implement Dual Pricing? Commenters should include a discussion of the systems changes and testing schedules that would be needed for their alternative implementation date(s).

The system changes to accommodate Dual Pricing on order systems would take at least six months to implement. Given that Dual Pricing would be a temporary situation and such changes would be eventually discarded, such an approach is not practical.

5. In addition, if commenters believe that implementing dual pricing by September 4, 2000 is not feasible, is the alternative Decimals Pilot feasible or preferable? If commenters believe that the Decimals Pilot is feasible, what, if any, systems changes or other steps would be necessary to facilitate this schedule? In particular, what changes would need to be made to the current decimals testing schedule? What type of changes would need to be made to the systems of securities firms, investment companies and vendors? What would be the impact on systems capacity? Is there a risk of customers confusion, and if so, how should it be addressed?

The Decimals Pilot approach, in contrast to the Dual Pricing approach, generally conforms to the approach originally proposed for the decimal conversion. Therefore, systems development work done to date would be usable and the timeframe for implementation would be shorter.

The most important consideration in planning the decimal conversion is that it should not introduce unnecessary risks to the investment industry. From the computer systems perspective, the process should focus on the essential price field changes and should not introduce new functional requirements. Systems in the decimalization era should function as they do now except for price fields. Introducing new complexities increases the risk of problems in the conversion process. Simplicity minimizes systemic risk and the potential for confusion on the part of all parties. For this purpose the essential characteristics of the plan should be:

Given the above criteria, the plan can be made only when it is determined when the Nasdaq system will be ready for full implementation.

6. If commenters believe that the Decimal Pilot is not feasible, what alternative would expedite the implementation of decimal pricing in exchange-listed and Nasdaq securities? Commenters should include a discussion of the systems changes and testing schedules that would be needed for their alternative, including implementation date(s).

See answer to Question 5.

7.Commenters are requested to offer specific views on the optimal schedule for implementing decimal pricing in options based on exchange-listed and Nasdaq stocks subject to decimal pricing.

Options should covert to decimal pricing concurrent with the conversion of the underlying stocks.

We call attention to the fact that the growth of financial markets along with other industry events are creating huge increases in computer systems message traffic. This impact is most pronounced in market data traffic but growth in order and trade messages is also increasing at an unprecedented rate. Decimalization, when it occurs, will cause further increases in peak message traffic. The Commission must recognize that industry systems are being expanded to meet capacity requirements that are growing beyond all reasonable projections. While, decimal conversion is supported by the industry, the timing of the conversion events must pay particular attention of the readiness of industry systems to handle the resulting systems traffic. This includes proper assessments as we move through the various phases.


W. Leo McBlain

Thomas J. Jordan
Executive Director