From Fractions To Decimals: ACI Worldwide Plays Role In Stock Exchange Industry’s Conversion
As if Year 2000 bug issues weren’t enough for information system departments to contend with, the stock exchange industry will begin converting the reporting of security prices from fractions to decimals next year.
Since the inception of the New York Stock & Exchange Board in 1817, U.S. securities have been traded using fractional prices such as 1/2 and 5/8. As the necessity to trade in smaller denominations arose, smaller increments have been used. The New York Stock Exchange, the American Stock Exchange and the Nasdaq Stock Market have traded securities in 16ths since 1997. This decision was made as a step toward quoting securities prices in decimals, part of a global effort to standardize how markets trade securities and options. Today, there are stocks that trade in 64ths, 128ths and even 256ths.
After the conversion to decimal trading is made, trading securities and options in fractions will be phased out in favor of their decimal equivalents. This means that every brokerage firm, stock exchange, regulating agency and software provider that deals with securities prices (from quote providers to home-finance software) must determine how they store, use and display prices in their systems.
U.S. stock exchanges are voluntarily making the switch from fractions to decimals, but have delayed implementation of the system until 2000 so they can deal with more-pressing Year 2000 issues, according to Duncan King, an SEC spokesman.
“In a way, the conversion to decimals is inevitable,” King says. “Almost all other markets in the world use a decimal system.”
There are many ways to display prices. Some screens might simply display fractions such as “3/4.” Others, to save space, might use a representation of a fractional value. For example, a system might display a price such as “10 3A” and require users to remember that A equals 4ths, B equals 8ths and C equals 16ths. This saves screen space, which is vital in a display panel design.
If a price is stored in character format on files, the program must convert it to a numerical format for calculations to be performed. It’s likely the system’s programmers devised a way to represent to prices to optimize performance. Alternatively, prices can be stored numerically, allowing calculations to be easily performed. Another possibility is a space-saving method that requires special conversion routines.
So, just as there are many ways screen-managing programs can on display prices, there are many ways price-handling programs can store them.
Rounding Up Or Down
Another concern is that decimal prices do not always correspond with fractional prices precisely. While 1/2 equals .50 and 1/4 equals .25, it gets more complicated when 7/8 equals .875 and 15/16 equals .9375.
After the conversion to decimal trading, prices will be based upon whole cents. On the day a security is converted to decimal trading, all prices in the system for that security must be converted to its proper equivalent. (The rules of conversion have not yet been established by the SEC. It has not been determined, for example, if 7/8 (.875) will be converted to .87 or .88 — another concern for program developers.)
One proposed method to migrate prices from fractions to decimals is to convert a subset of them at a time. Starting on a Monday, for example, all securities whose symbols start with the letter A will be traded in decimal format. If that is successful, all symbols that start with B will be converted on Tuesday, and so on. This approach requires developers to devise a method to convert symbols individually or in groups at a time.
Decimals And Fractions Together
While the financial industry undergoes this conversion, and some securities are traded in decimals while others are traded in fractions, another issue must be addressed. Screens displaying prices of multiple symbols must be able to display prices in either format on the same screen. This requires programs that can determine which symbols have been converted and which have not. Another complicating factor is that some records in the system are stated in fractions while others are in decimals for the same security.
This requires instructions within the software to determine the difference between a price expressed in decimal format and a price in fractional format, even within a single symbol. When sizing the conversion project, the manner in which prices are stored, used and displayed in a computer system must be studied carefully to determine the best way to handle multiple formats of prices simultaneously.
Contingency Plans
Another consideration for developers is the possible need for decimals to revert to fractions. If, for example, a security is converted to decimal trading and problems occur, the SEC might decide to revert to fractional trading for that symbol. Or, what if 1,000 symbols have been converted in a week, and the SEC decides to revert one or more of them to fractional trading?
Fallback scenarios for situations such as these must be devised.
In designing a fallback process, these questions must be answered: Must the entire system be shut down for conversion routines to be run? If so, what happens to business? What happens if the conversion routines don’t work properly or abort? Are the conversion routines changing live production files, or are there backup files? How long do the conversion and reversion processes take?
Before the conversion plan is developed, there must be a plan to remove fraction-handling code before the conversion to the decimal format. If modules are changed blindly to accommodate decimals, it cannot be properly maintained or run at peak performance when fractional formats no longer exist.
Regardless of the methods currently used to store, use and display prices, it is necessary to investigate every module to determine how the prices are converted from one representation to another. Many tools developed to search through programming code for date manipulation routines during the Year 2000 effort might also be used for the fraction-to-decimal conversion. In both cases, all code must be searched for occurrences of a particular type of field and each case must be considered and addressed.
But the fraction-to-decimal conversion has some requirements, including the following, that don’t apply to the Year 2000 issue:
- a method of handling prices in both formats simultaneously, both internally and on displays
- a system for isolating a single security or a group of securities to be converted at different times
- a reasonable conversion procedure with little affect on business during the interim period
- a method to handle fallback procedures
- an effort after the conversion to clean out obsolete fractional processing
ACI Worldwide’s Role In The Conversion
A handful of companies, such as the Pacific Exchange and Chicago Board Options Exchange, have already started the fraction-to-decimal conversion with the efforts of ACI Worldwide. Pacific Exchange hired ACI to perform the entire project, which consisted of all online trading processes on Stratus computers and the interfaces on OS/2 Workstation computers used by personnel working on the floor.
The work consisted of a detailed proposal written after a preliminary study of the system. Tools developed by ACI during its numerous Y2K projects were used to determine the size of the project.
Engineers then examined every program in the extensive system, which consists of hundreds of modules to chart transaction flows and document the exact changes necessary for the project. The engineers worked closely with Pacific Exchange technical staff to study and address issues surrounding the conversion.
A document was produced that describes the new processes necessary in addition to the changes to the current modules, including implementation plans and procedures for converting prices during the interim period. An entire conversion subsystem was designed that does the following:
- allows floor personnel to view the trading status (fraction or decimal) of every securities symbol and lets them mark those symbols to be converted to the decimal format for the next day’s trading
- converts the chosen security during the post-trading day batch file procedures reports changes
- converts any or all symbols back to fractional format if necessary.
After the analysis was completed and approved, ACI performed the development phase of the project by coding the necessary changes to the Pacific Exchange’s current system, building the conversion subsystem described above using programs written from scratch and previously developed Y2K instruments. A complete version of the Pacific Exchange trading system was duplicated on a separate, local Stratus computer and OS/2 Workstation so it could be thoroughly tested. Changes were then retrofitted into the current production system base code.
The product was delivered to the Pacific Exchange, on time and on budget. Complete and thorough quality assurance testing support is available as well as support during initial implementation and the first day of the interim period. In the meantime, ACI is ready to repeat the process on Pacific Exchange’s options trading system.
The Pacific Exchange project has proven that ACI can deliver the technology and know-how to leverage its Year 2000 expertise to other types of projects.
