back start next


[start] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [66] [67] [68] [69] [70] [71] [72] [73] [74] [75] [76] [77] [78] [79] [80] [81] [82] [83] [84] [85] [86] [87] [88] [89] [90] [91] [92] [93] [94] [95] [96] [97] [98] [99] [100] [101] [102] [103] [104] [105] [106] [107] [108] [109] [110] [111] [112] [113] [114] [115] [116] [117] [118] [119] [120] [121] [122] [123] [124] [125] [126] [127] [128] [129] [130] [131] [132] [133] [134] [135] [136] [137] [138] [139] [140] [ 141 ] [142] [143] [144] [145] [146] [147] [148] [149] [150]


141

How a Development System Was Chosen

Computer salespersons visited me constantly-IBM, Stratus, Tandem, Data General. They kept saying only a minicomputer could handle a mainframe-oriented BYSNC feed. I decided to give a PC network a try. I was buying PC Limiteds 286 computers for about $2,000 each (memory was dear at the time) and felt that we could get a long way toward the $200,000 to $350,000 a minicomputer would cost.

We had some PS/2s (we wanted to be ready when IBM decided to release the 386 chip), and we bought, Novell netware, on 3Com Ethernet and later Arcnet, when the 3Com drivers were delayed. We bought a dozen PC Limited 286s, now known as Dell Computer.

We had hired Cathy Huang and Belinda Chang to work on the feed problem. Cathy Huang worked on the BYSNC data reception, and Belinda Cheng worked on the protocol by which the feed handlers, data storage servers, backup feed handlers and backup servers would communicate and broadcast their status to each other. Rob Davis was working on the touch screen and character mappings to display fractions. Pat MacCaulley was using the option models to print out trading sheets for Fossett market makers.

The option models came right from the book. The Cox-Ross-Rubenstein book was pretty much incomprehensible. We used McMillian and Bookstaber, which even had BASIC code. Three years later, I was teaching and deriving options models at First Chicago Corp.

Hardware and Software Development headaches

The data reception problem was a much harder challenge than first supposed. Cathy Huang wrote her own drivers in assembler for this purpose. She got it working. Later, an engineer at SIAC explained to me how it was not possible for it to work since there were circuitry design flaws in the PS/2 serial port. We did not know that, but luckily Cathy used different computers to test with and we found it worked on the PC Limited 286.

When using the data storage servers on the live feeds, we quickly ran out of memory under DOS. 640K basic memory, 384K extended and 2MB expanded. We used the expanded memory until we could convert the b-tree program to OS/2.

I kept trying to get 3Com to deliver drivers for their boards under OS/2. They kept delaying. Finally in desperation, I popped out the Ethernet and replaced it with a Standard MicroSystems Arcnet that had a fully functioning OS/2 driver and we segmented the topology into an Arcnet segment and an Ethernet segment. It worked, but it was not elegant. A few months later, I was still on the phone to the developers

the team members, this would be the reason the system avoided big losses during the market break in 1989.



at 3Com trying to get their product shipped. The engineer told me that he could write the driver in one day, but his management had forbidden him to do so, since IBM was in the network business. I called him at home that night, and two days and $200 dollars later, I had the driver.

Encountering a Minor Delay

The data was coming in full speed and the network was handling it. We powered down machines to check the fault recovery. The touch screen was operating, trading screens were being updated with real prices and our theoretical option prices, and the fun was about to start. We were preparing to get a station in the OEX pit. It was the October 1987.

After the initial terror, the introspection, the follies of some participants, and the makings of great stories in years to come, business had changed substantially and our efforts were needed elsewhere. The decision was made to put the project on hold temporarily, to keep improving various components in our spare time, and to move forward with other more timely endeavors. We concentrated our efforts on the quotation system, the risk management system, and the clearing systems.

Rob Davis Jr., our lead programmer, resigned shortly after the October panic. He made some comments about wanting to find an industry that is more stable where he could responsibly raise a family. To me, stability meant boredom, and to Steve Fossetts credit, no one was laid off at Fossett Corporation at the time.

Project Nimble Begins

In March 1988, Steve Fossett expressed his desire to resume the project. He picked one of his best market makers, Jim Sauser to join the team. I picked two new software engineers to join the team, Evan Jones and Dave Lawson. The four of us moved into an office together and we brainstormed day and night. We thought of the name, Nimble, because that is what we would have to be on the floor of the exchange to escape harm. Then we designed the system, as shown in Figure D.l.

The Nimble system would be composed of three major and independent systems: the volatility monitor, the pricer, and the risk manager module. The volatility monitor would listen to the data feeds constantly and back out the implied volatilities for different expiry months and strike prices. It would always keep a current estimate of what the market thinks the volatility is.

The pricer would use the volatility and calculate the house theoretical value for each option, then apply a bias (to be discussed), and then issue the house price given the bids and offers of other firms. This is an important feature. For example, suppose our theoretical value was $1.50 but the best bid was $1.00. We would either bid with them at $ 1 or become best bid at $ 1 , but we would never bid more.



The risk module would keep track of all the options and hedges currently active in inventory. It would keep a live estimate of all the Greek letters. A clerk would sit by the screen and enter futures trades in the early days. Later, that was done from the trading floor.

The risk module would also be the generator of the bias parameters that the pricer would use. The bias would start to kick in to bias the pricer away from long options when our total delta was approaching our set limits and would bias the pricer away from buying options when our vega limits were approached. The delta limits would come down as a hedge was entered. We were looking at managing the gamma and theta limits as well, but early experience showed this was not necessary as they mainly took care of themselves, in such a large options book. However, we did display these values for the human traders to monitor.

Figure D.1 The layout of project nimble.



[start] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [66] [67] [68] [69] [70] [71] [72] [73] [74] [75] [76] [77] [78] [79] [80] [81] [82] [83] [84] [85] [86] [87] [88] [89] [90] [91] [92] [93] [94] [95] [96] [97] [98] [99] [100] [101] [102] [103] [104] [105] [106] [107] [108] [109] [110] [111] [112] [113] [114] [115] [116] [117] [118] [119] [120] [121] [122] [123] [124] [125] [126] [127] [128] [129] [130] [131] [132] [133] [134] [135] [136] [137] [138] [139] [140] [ 141 ] [142] [143] [144] [145] [146] [147] [148] [149] [150]