WO2002091650A2

WO2002091650A2 - A low-bandwidth distribution system and method for option quotes, theoretical prices, and derivatives

Info

Publication number: WO2002091650A2
Application number: PCT/US2002/014422
Authority: WO
Inventors: Edwin P. Chen; David W. Walthour
Original assignee: Stafford Trading, Inc.
Priority date: 2001-05-08
Filing date: 2002-05-08
Publication date: 2002-11-14
Also published as: WO2002091650A3; AU2002305432A1

Abstract

A low bandwidth mechanism for distribution of quotes (16, 30, 70) , theoretical prices, and derivatives to remote clients (32) is achieved by decomposing the description of these values into their fundamental components (e.g., parameters (156) of the option pricing model, market data such as dividends and interest rates, contract data such as expiration date, and the price of the underlying instrument), transmitting these to the remote client, and utilizing a mirror of the software on both the local and remote sites in order to reconstruct the same values on both sides. Significant reductions in bandwidth usage are achieved by sending updates (234, 236) to the fundamental components only when their state has changed and by limiting the data being sent in the update message to only the specific values that have changed state.

Description

TITLE OF THE INVENTION

A LOW-BANDWIDTH DISTRIBUTION SYSTEM

AND METHOD FOR OPTION QUOTES, THEORETICAL PRICES, AND DERIVATIVES

FIELD OF THE INVENTION

The present invention relates to a system and method for the low-bandwidth distribution of data representing option quotes, theoretical prices, and derivatives.

More particularly, the invention relates to a system and method for reducing the data necessary to completely distribute accurate option quotes, theoretical prices, and derivatives.

BACKGROUND OF THE INVENTION A stock option contract is the right to purchase or sell a specified amount of the underlying stock or security at a specified time and a specified price. The value of the stock option contract, also commonly referred to as an option, fluctuates depending on numerous underlying factors, in particular the present value of the underlying stock or security. Additional factors include factors intrinsic to the contract, such as the date the option expires, as well as factors extrinsic to the contract, such as a standard market interest rate. As is evident, the value of the stock option contract may potentially change numerous times throughout a particular trading day.

The value of a stock option contract for a specified underlying stock on a particular day may be determined by a computer model that may take into account one or more of the underlying intrinsic and extrinsic factors that can affect the value of a stock option contract. That is, a computer model may have as its input the value of the underlying stock or security as well as other factors to generate a value for a stock option contract. All such computer models use the underlying price as a factor but may use any combination of the other factors as well. Regarding the underlying stock or security, changes in the value of that stock or security are easily computed based on what traders may wish to pay or accept for the purchase or sale of the stock or security. Changes in the value of a stock option contract, however, are not always readily apparent from changes in the value of the underlying stock. It may be that some simple models provide stock option contract values that generally approximate changes in the value of the underlying stock or security. But other simple and more complicated models often calculate values for stock option contracts that do not approximate the changes in the value of the underlying security. This results from the fact that the various models utilize varying different underlying factors in producing a value for a stock option contract.

In order to accurately predict changes in the value of a stock option contract resulting from a change in the value of the underlying security or other factors, the computer models may generate indicators that will predict the change of the value of the stock option contract resulting from changes in the price of the underlying stock or security or other factors of the model. These indicators are generally referred to as the "Greeks," and include such financial modeling derivatives such as delta, gamma, vega, rho, and theta. Thus, for every stock option contract considered by the computer model, the computer model generates various numbers that must be communicated to a trader dealing in the stock option contracts in question, including the value of the stock option contract as well as each of the derivatives associated with that value generated from that particular model.

Additionally, a given stock or security may have hundreds of different stock option contracts associated with it. The reason for the large number of potential stock option contracts for a given security is that there may be different specified expiration dates and specified prices. The computer model, then, must generate an enormous amount of data corresponding to each of the stocks or securities in question, the data includes the value of the various stock option contracts as well as corresponding indicators (or Greeks) for each such contract.

There are many standard models for generating values of stock option contracts. There are also many proprietary, trade secret models that are used in the industry. Computer systems that apply these various models are widely used in the option trading community.

As is evident, the amount of data generated by a single model for the numerous stock -option contracts available for a single underlying security is substantial, the amount of data generated for a large number of securities is correspondingly greater. To properly assess the risks involved in buying and selling stock option contracts and subsequently making the actual sale or purchase of stock option contracts requires that a trader have access to all of this data. Where the trader has direct interface with the computer system running the computer model, such access is readily available. However, where a trader does not have such direct interface, a system must be devised to convey this substantial amount of data to the trader for the trader to accurately assess the risks in purchasing and selling stock option contracts for a given underlying security or stock. Any standard technology for transmitting and receiving information may be utilized in this regard. The problem however arises from the substantial amount of data that must be transmitted. Transmission of this substantial amount of data must be repeated every time the values of the stock option contracts change which results from a change in the value of the underlying stock and changes in other factors. This constant need to transmit large quantities of data will rapidly overwhelm any system for transmitting and receiving the information required by the option trader.

SUMMARY OF THE INVENTION

It is therefore an object of the invention to provide a system and method of transmitting to a remote trader the data necessary for the trader to properly assess the risks involved in buying and selling stock option contracts.

It is a further object of the invention to provide a system and method of reducing the data that must be transmitted to the trader to avoid overwhelming the transmission system utilized.

It is still a further object of the invention to provide a system and method that will generate the value for a stock option contract and its corresponding derivatives at both a local site and a remote site so that the trader at the remote site will have access to real-time accurate information just as if the trader were at the local site.

A low bandwidth mechanism for distribution of option quotes, theoretical prices, and derivatives to remote clients is achieved by decomposing the description of these values into their fundamental components (e.g., parameters of the option pricing model, market data such as dividends and interest rates, contract data such as expiration date, and the price of the underlying instrument), transmitting these to the remote client, and utilizing a mirror of the software on both the local and remote sites in order to reconstruct the same values on both sides. Significant reductions in bandwidth usage are achieved by sending updates to the fundamental components only when their state has changed and by limiting the data being sent in the update message to only the specific values that have changed state. Using this method, only one value, the price of the underlying instrument, is sent to the remote site at a high frequency (as often as once every few seconds). All other parameters may need updating at rates ranging from minutes to hours, or may not change at all throughout the course of a trading day. The components comprising this system include option pricing models for producing the theoretical prices and derivatives, a universal model interface for these pricing models that allows for alternate or custom models in this system, and a quoting engine for translating theoretical prices into bids and offers on the options. The functions of the quoting engine may be similarly decomposed so that only those portions of the quoting control parameters that are modified must be transmitted to the remote client modifying the remote client to mirror the quoting control parameters of the local client.

DESCRIPTION OF THE DRAWINGS

Figure 1 is a block diagram of a system that must transmit substantial amounts of data to keep a remote client synchronized with a local client.

Figure 2 is a block diagram showing three examples of the local portion of the system of Figure 1. Figure 3 is a block diagram that shows a mirrored option quoting system. Figure 4 is a block diagram showing the specific components of the local portion of the mirrored option quoting system of Figure 3.

Figure 5 shows is a block diagram showing the typical inputs for a quoting engine.

Figure 6 is a block diagram of a mirrored quoting engine system.

Figure 7 is a block diagram showing the details of the formula transport of Fig 6. ^' DETAILED DESCRIPTION OF THE INVENTION

Figure 1 is a block diagram of a system that must transmit substantial amounts of data to keep a remote client synchronized with a local client. In this system 10, the local system 12 usually contains an option pricing model 14 along with a model for producing option quotes or quoting engine 16 derived from the theoretical price 18. The underlying instrument price 20 is passed to this model 14 along with other model parameters 22 and the model 14 returns the theoretical values 18 and all the associated derivatives of this theoretical value 18. The quoting engine 16 then combines quoting parameters 24, such as user preferences and exchange specific rules, to produce valid quotes 26 for the option. The resulting quotes 26 are then available to the local client 28, but consume a considerable amount of bandwidth 30 if they need to be transmitted to a remote client 32. Furthermore, because the underlying instrument price 20 is a fundamental input to the very first step of this process, rapid fluctuations in this underlying instrument price 20 result in the need for this large set of quotes to be resent. Typically, the underlying instrument price 20 must also be made available to the remote client 32 which would further burden the transmission system between the local system 12 and the remote client 32.

Typical models that can be used as the option pricing model 14 include the Black-Scholes Model, the Merton Jump Diffusion Model, and the Jarrow-Rudd Approximation. A person skilled in the art can adapt the formulas of these models into a computer software such that a computer can readily receive the information required by the particular model, apply the algorithms of that model, and yield a theoretical option price and accompanying derivatives for a particular underlying stock or security. Each of the model examples mentioned above requires information specifically related to the contract, market factors, the underlying stock, as well as the volatility of the underlying stock. For example, the Black-Scholes

Model requires as inputs the following five pieces of information: the current price of the underlying stock, the strike price of the option contract, the risk-free interest rate, time until option expiration, and the volatility of the underlying stock or security. With these inputs, the Black-Scholes Model seeks to predict the probability of the various potential gains on the contract expiration date and assigns a value to the option contract based on that probability. As is readily understood, the more accurate the volatility can be modeled, the more accurate will be the prediction of the probability of the various potential gains and thus the more likely that a given model will assign an accurate value to the option contract. The Merton Jump Diffusion Model is based on the Black-Scholes Model and includes additional operations in an attempt to more accurately model the volatility and thus the probability of the various potential gains on the contract expiration date. The Merton Jump Diffusion Model requires two additional inputs, called the jump probability and the jump size. Similarly, the Jarrow-Rudd Approximation attempts to more accurately model the volatility by modifying the Black-Scholes

Model with different inputs, called the skew and kurtosis.

The data used in these models is generated by an upstream application. Thus, in order for the particular model to correctly recognize the information received it must be coded with the format of the upstream application in mind. The theoretical quote prices and derivatives generated from the models are not the final option quote prices that can be used. The theoretical quote prices must be conformed to the rules of the exchange on which the options are traded as well as to a trader's preferences. Experienced traders may take the theoretical prices and by virtue of their extensive experience be able to mentally estimate appropriate final option quotes. Option quotes, however, may be generated by the quoting engine 16. The quoting engine 16 is programmed to take the theoretical quote 18 derived from the model 14 and apply the exchange rules, such as the minimum quote multiple (tick size) and the maximum quoting spread, and the trader's preferences to arrive at appropriate option values 26. Programmers may typically program their various models to output the theoretical option quote in a standard format so that they may use a single quoting engine 16 with each of the various models utilized. If the model software outputs the theoretical quote in an improper format, the quoting engine 16 may not recognize the inconsistency and may generate option quotes based on a correct theoretical price but in an incorrect format that may yield inaccurate option quotes.

Figure 2 shows the system of Figure 1 adapted to implement each of the three models identified above, i.e. the Black-Scholes Model, the Merton Jump Diffusion Model, and the Jarrow-Rudd Approximation. The first example relates to the Black-Scholes Model and begins with the Black-Sholes Model upstream application 40. The Black-Scholes Model upstream application 40 generates the data 42 that are necessary inputs for the Black-Scholes Model 44 the Black-Scholes data 42 corresponds to the underlying instrument price 20 and model parameters 22 of Figure 1 and the Black-Scholes Model 44 corresponds to the option pricing model 14 of Figure 1. With the receipt of the Black-Scholes data 42 the Black-Scholes Model 44 can generate its output of theoretical price and corresponding Greeks 46.

The second example relates to the Merton Jump Diffusion Model. The

Merton Jump Diffusion Model upstream application 50 generates the Merton Jump

Diffusion Model data 52 which can then be fed to the Merton Jump Diffusion Model

54. As discussed above, the Merton Jump Diffusion Model adds additional data parameters in order to more closely model the volatility of the underlying stock or security. Those additional parameters are the jump rate, jump size, and jump volatility. However, because the Black-Scholes Model does not utilize those same data parameters, the Merton Jump Diffusion Model upstream application 50 must be different from the Black-Scholes Model upstream application 40 in order to generate these additional data parameters. Finally, the Merton Jump Diffusion Model generates its output of theoretical price and corresponding Greeks 56.

The third example relates to the Jarrow-Rudd Model. Generating the data necessary for this model is the Jarrow-Rudd Model upstream application 60. Although the Jarrow-Rudd Model is based on the Black-Scholes Model, it includes additional data inputs just as the Merton Jump Diffusion Model does. The Jarrow- Rudd Model data 62 includes all of the Black-Scholes Model data 42 plus the additional parameters of skew and kurtosis. This data can then be input to the Jarrow-Rudd Model 64. The Jarrow-Rudd Model may then generate its output of theoretical price and Greeks 66.

As can be seen, because each model utilizes different input data, there is no possibility to use a common upstream application. Each of the three models, the Black-Scholes Model 44, the Merton Jump Diffusion Model 54 and the Jarrow- Rudd Model 64 can be programmed to provide their respective outputs of the theoretical price and Greeks 46, 56, 66 in the identical format such that regardless of which model is being run, the same quoting engine 70 may be used to generate the option quotes 72.

The system of Figure 1 in the examples of Figure 2 may be adequate to provide a local client 28 (Fig. 1) with current option quotes 26, 72. However, in order to provide a remote client 32 (Fig. 1) with current information, the system of

Figure 1 and the examples of Figure 2 generate three potential data sets that may be communicated to a remote client 32. The first such data set is the theoretical option prices 18 (Fig. 1) and the respective theoretical price and Greeks 46, 56, and 66 (Fig. 2). The second data set that can be transferred to the remote client include the option quotes that correspond to the wide-band width 30 of Figure 1 and the option quotes 72 of the examples of Figure 2. As noted above, the problem with sending the option quotes 72 is that an extraordinary amount of band- width 30 (Fig. 1) is necessary. Substantially the same amount of band- width is necessary to send the theoretical option prices 18 (Fig. 1), 46, 56, 66 (Fig. 2). An alternative data set to transfer to the remote client may include the underlying instrument price 20 and model parameters 22 of the system 10 of Figure 1 or data sets 42, 52, and 62 of the examples depicted in Figure 2. Although sending these data sets 20 and 22, 42, 52, 62 would require substantially less band- width 30 in (Fig. 1) than sending the option quotes 72 or theoretical price and

Greeks 18 (Fig. 1), 46, 56, 66, it is still necessary to repeatedly send all of the data and also ensure that the remote client has the appropriate model loaded on its system that corresponds to the particular upstream application loaded at the local system.

The present invention may provide an appropriate interface between the model and the upstream application and quoting engine to eliminate any detrimental effects that either the upstream application or quoting engine may have on the model. That is, the interface of the preferred embodiment of the present invention permits the use a properly encoded model without regard to the characteristics of the upstream application or the quoting engine. Figure 3 is a block diagram that shows the preferred mirrored option quoting system 90 of the present invention. The option quoting system 90 includes a local system 92 and a remote system 94. As will be further explained, in the preferred embodiment, the components of the remote system 94 are substantially identical to the components of the local system 92. The main components of the local system 92 are the standardized option pricing model 96 universal model interface 98 and the quoting engine 100. The local system 92 provides option quotes 102 to local client 104. The option quotes 102 are generated by first inputting or otherwise deriving the upstream application data 106. The upstream application data 106 will include all of the data necessary for the option pricing model 96 to run. This information will typically include the current price of the underlying stock, the strike price of the option contract, the risk-free interest rate, time until option expiration, the volatility of the underlying stock or security, any modifiers to the volatility component (such as the jump factors of the Merton Jump Model), and any other factors needed by the model (such as the holiday calendar that enables the model to account for non-trading dates).

The system 90 of the present invention contemplates utilizing standardized and well known option pricing models. Accordingly, those skilled in the art will readily understand and recognize which factors must be input for a particular option pricing model. Further, the system 90 of the present invention contemplates the use of proprietary or trade secret option pricing models. A user may thus create its own option pricing model defining the various factors that are necessary and must be input for the option pricing model to properly generate accurate option quotes. Thus, the examples provided for the upstream application data 106 are not intended to be exhaustive and persons skilled in the art can readily identify the additional factors that must be input for the particular option pricing model to be used.

The purpose of the universal model interface 98 is to standardize all of the information flowing into and out of the universal model interface 98 such that it is compatible with a standardized option pricing model 96 and quoting engine 100. In its preferred embodiment, the universal model interface 98 accomplishes this by subdividing all information flowing into and out of the universal model interface 98 into five types: instantaneous data 120 (such as the present stock price and date), contract data 122 (such as expiration dates and striking prices), market data 124 (such as interest rates and stock dividends), model parameters 126 (such as volatility), and the resulting theoretical option prices and derivatives of the options 130. The instantaneous data 120, contract data 122, market data 124, and model parameters 126 are all inputs to the universal model interface 98 while the theoretical option prices and derivatives 130 are an output to the quoting engine 100. For each of these types of information, the universal model interface 98 provides an appropriate interface specific to the type of data. For the contract data, the interface expects that most of this data will be sent only once at startup, but is built to allow individual updates to this data which may arrive throughout the day. The market data is also expected to arrive once during startup and not often updated throughout the trading day, but is differentiated in that, if it is updated the entire set of data will typically be replaced rather than having data added to it. Of course, the instantaneous data will be updated very frequently.

Unlike the contract data 122 and market data 124, the model parameters 126 are usually unique to a given pricing model 96. The universal model interface 98 supports this uniqueness by reducing all parameters to basic data types (for example, integers, floating-point numbers, Booleans, strings, or date-time representations). The universal model interface 98 assigns a unique enumeration to each basic parameter in a given model support. Model parameters are then updated by indicating that a particular enumerated parameter take on a new value, or by passing in a vector of such parameters to update more than one at a time. The option pricing model itself 96 is responsible for returning, upon request, the entire vector of enumerated parameters that describe its state.

The remote system 94 is a mirror image of the local system 92. That is, the remote system 94 includes all of the components and applications possessed by the local system 92 in order to complete the same calculations and provide the same option quotes and derivatives as the local system 92. In particular, and just like the local system 92, the remote system includes a remote standardized option pricing model 140 a remote universal model interface 142 and a remote quoting engine 144. The remote universal model interface 142 receives information from universal model interface 98 by any means of transmission. The means depicted in Figure 3 is the internet 150. The discussion above related to the processing of the upstream application data 106 with respect to the local system 92 is equally applicable to the remote system 94 and results in option quotes and corresponding derivates 152 to the remote client 154. As will be further discussed below, the operation of the quoting engine 100 can be similarly decomposed such that only the quoting parameters 156 must be transmitted to the remote quoting engine 144 in order to synchronize the remote quoting engine 144 with the quoting engine 100.

Regarding the data 158 that must be transmitted from the local system to the remote system, only those data types with changed values need be transmitted. For example, if only the underlying price (S) and interest rate (r) change value the universal model interface 98 need transmit as data 158 to the remote universal model interface 142 the two data types instantaneous data 120 and market data 124. This substantially reduces the amount of data 158 that must be transmitted from the local system 92 to the remote system 94 in comparison to the information that must be transmitted in the system of Figure 1 or the examples of Figure 2.

Figure 4 provides an example of the systems 92, 94 of Figure 3. The upstream application 170 generates all of the data necessary for any model utilized by the system 92, 94 (Fig. 3) the data is forwarded to the universal model interface 172 which includes an application processing interface (API) 174. The API 174 processes and organizes the incoming data from the upstream application 170 into its various types such as instantaneous data 176 contract data 178, market data 180 and model parameters 182. As can be seen in Figure 4, the instantaneous data 176 includes the underlying price (S) and the simulation time (t). The contract data 178 includes the strike price (K) and the expiration time (T). The market data 180 includes the interest rate (r). The model parameters 182 include all of the parameters that may be called for by any model loaded into the standardized option pricing model 96 of Figure 3. In this way, regardless of which model is to be used, the model parameters 182 will include all of the values necessary to run that model. Regarding the model parameters 182 as is reflected in Figure 4 these parameters are provided in keyed pairs so that only those parameters required by a particular model are actually accessed by that model. Of course, the particular model must be programmed such that the parameters it will access coincide with the keyed pair in the model parameter data set 182. All of these data sets 176, 178, 180, 182 are then made available to the standardized option pricing model that will be generating the theoretical price and Greeks. In the example of Figure 4, three separate option pricing models are considered: the Black-Scholes Model 190, the Merton Jump Diffusion Model 192 and the Jarrow-Rudd Model 194. As can be seen from Figure 4, each of these models 190, 192, 194 utilize all of the instantaneous data 176, the contract data 178 and the market data 180. Each model 190, 192, 194, however will access different parameters of the model parameters 182. For example, the Black-Scholes Model 190 is coded in such a way that it will only access keyed pair number 1 which represents the volatility. Similarly, the Merton Jump Diffusion Model 192 will only access keyed pairs 1, 2, 3, and 4 which correspond to the volatility, jump rate, jump size, and jump volatility, respectively. Finally, the Jarrow-Rudd Model 194 will access only keyed pairs 1, 5 and 6 which correspond to the volatility, skew, and kurtosis, respectively.

As evident, regardless of which model is sought to be used, the system can accommodate the model because of the format in which the model is coded to receive model parameter data. In this way, each of the models is coded to recognize a standardized keyed set of model parameters and will only access those model parameters that are identified by the appropriate key in the model parameter data set 182. Each of the models is also coded to output theoretical price (c) and Greeks

200 in the identical format so that any downstream use of the information is not dependent on which model is actually utilized. The theoretical price and Greeks 200 are then returned to the universal model interface 172 as the results set 202 and then forwarded to the quoting engine 204 for the generation of the final option quotes 206. The theoretical price and Greeks 200 are passed through the universal model interface 172 to ensure that they are in the appropriate format for the quoting engine 204. Of course, the theoretical price and Greeks 200 can be sent directly to the quoting engine 204.

This same processing of input data occurs at both the local system 92 (Fig. 3) and the remote system 94. The only difference is that the remote universal model interface 142 will only receive those data sets 120, 122, 124, 126 that have changed values. That is, universal model interface 98 need only transmit those data sets with changed values, thus reducing the bandwidth necessary to maintain the remote system 94 synchronized with the local system 92. Turning now to the quoting engine 110 (Fig. 3), financial instruments are traded using bid and ask prices. The bid is the price at which the instrument may be bought by an entity. The ask price is the price at which the instrument may be sold. The bid price is always slightly lower than the ask price. The markup between the two prices, called the spread, represents a profit margin for the entity that distributes the instrument. The quoting engine produces these bid and ask prices for a single or set of financial instruments. A very efficient mechanism has been developed to allow the dissemination of these quotes by describing them through a set of rules and requirements run by the quoting engine 100. The inputs to the quoting engine 100 are efficiently disseminated through a quote transport layer.

Bandwidth usage by the transport layer is fairly minimal under normal circumstances and always less than traditional approaches involving the raw broadcast of quotes.

Figure 5 shows is a block diagram showing the typical inputs for a quoting engine 210. The quoting engine 210 requires the following inputs:

-Theoretical Price 212: this input is the fair price of the instrument being quoted. The quoting engine 210 includes the ability to adjust the theoretical price 212 before it is used. It eventually represents a target price at which the quoting spread will attempt to center. -Formula 214: the quoting formula 214 is a set of mathematical operations on available market, user-supplied, or calculated parameters. Examples of such operations include, but are not limited to, basic arithmetic, trigonometric, logarithmic, and conditional/logical operators. Underlying prices, constants, and financial modeling derivatives such as the Greeks described above (i.e. , delta, gamma, vega, rho, theta) are examples of parameters. The architecture is extensible enough to later support the addition of variables such as rates, dates, time spans, complex numbers, or other quantifiable item.

-Quote Adjustment Controls 216: under special circumstances, some outputs from the quoting engine 210 need to be further refined. For example, all the derivative quoting widths on a subset of an options chain need to be increased to account for increased uncertainties in the market. The architecture includes a mechanism to do this. It allows for both a description on how to modify the quotes and on which quotes to exercise the modifications. Quote adjustment controls include: leans (a mathematical expression, including constants, by which to offset the theoretical price); width adjustments (an override that affects the output quoting spread); and exchange rules (rules by which the quoting engine should abide). Depending on the exchange, numbers such as the minimum quote multiple (tick size), or the maximum quoting spread need be restricted. When any of these conditions exist, they are specified as exchange-related input parameters to the quoting engine. The width adjustments include the ability to immediately multiply the quotmg width by a specified amount when the market goes into a fast-market condition. It also allows for fine-tuning of the quoting width output from the quoting formula width calculation by an offset amount.

Figure 5 provides an example of how a single quote is produced/reconstructed by the quoting engine 210. Figure 5 shows how a theoretical price 212 of $12.50 is entered into the quoting engine 210. Since a Theoretical Price Lean of 0.125 is specified in the quote adjustment controls 216, the center price becomes $12,375. A predetermined formula, utilizing the underlying bid and ask and the derivative gamma, is calculated giving a quoting width to apply around the center price. After applying a quote width adjustment and checking that the exchange rules are obeyed, an output of a bid and ask are obtained. This process is repeated for as many instruments as needed.

Figure 6 is a block diagram of a mirrored quoting engine system. A local quoting engine 224 is first invoked. It produces an initial set of numbers utilizing in part the theoretical prices 226 obtained from the systems of Figs. 1 or 3 and further refined by the quoting formulas 228 and quoting adjustments 230. Different sets of quote adjustments and/or quoting width formulas are collected into data library messages. These messages are field-labeled for easy transversal and nested for future extensibility. Most of the tuning and library manipulations would typically be done prior to an opening exchange session. Once desired quotes 232 are obtained, all opening parameters are saved and the formula transport 234 takes care of broadcasting them to interested parties, here over a network cloud 236 which could be the internet or any other mode of transmission. Updates to quoting engine parameters such as to the quoting formulas 228 or the quoting adjustments 230 can be made at any time afterwards in the form of update-message packets as described below in connection with Figure 7.

At the remote quoting engine 238, quotes 240 are reconstructed real-time by applying parameter updates as they are received. Any updates are first validated and all inputs to the quoting engine synchronized to reproduce the same set of quotes as the original. The updates are received first by the remote formula transport 242. Changes to formulas are forwarded to the remote quoting formulas 244 which in turn provides the remote quoting engine 238 with the updated formulas. Changes to other parameters are forwarded to the remote quoting adjustments 246 and similarly provided to the remote quoting engine 238. The quoting engine 238 has as its main input the theoretical prices 250 which may be generated by the remote system 94 of Figure 3.

Figure 7 is a block diagram showing the details of the formula transport 234 of Fig. 6. As mentioned above, the formula transport 234 saves all opening parameters and broadcasts those opening parameters to the remote formula transport 242 (Fig. 6). These opening parameters are saved in the formula reference 260 for formulas and the adjustment reference 262 for quoting adjustments. Repeatedly throughout the trading day, the quoting formulas 228 are compared to the formula reference 260 and if there is an update of that information the update is transmitted over the network cloud 236 to the remote formula transport 242 (Fig. 6). Similarly, repeatedly and throughout the day, the quoting adjustments 230 are compared to the adjustment reference 262 and if there is an update of that information, the update is transmitted to the remote formula transport 242 (Fig. 6). In this way, the remote quoting engine 238 (Fig. 6) will continue to be synchronized with the local quoting engine 230 (Fig. 6) so that the resulting remote quotes will be identical to the quotes generated at the local system. While particular embodiments of the invention have been shown, it will be understood that the invention is not limited thereto since modifications may be made by those skilled in the art, particularly in light of the forgoing teaching. It is, therefore, the appended claims which define the true spirit and scope of the invention.

Claims

What is claimed:

1. A low-bandwidth system for distributing option quotes from a local quotmg system to a remote quoting system comprising: an upstream application data source, a local quoting system, a remote quoting system, and a transmission pathway; the local quoting system comprising a local universal model interface that receives data from the upstream data source, and a local standardized option pricing model that receives data from the local universal model interface and generates local theoretical option prices at the local quoting system; the remote quoting system comprising a remote universal model interface that receives data from the local quoting system via the transmission pathway, and a remote standardized option pricing model that receives data from the remote universal model interface and generates remote theoretical option prices at the remote quotmg system.

2. The low-bandwidth system of claim 1 further comprising a local quoting engine that receives the local theoretical option prices generated by the local standardized option pricing model and a remote quoting engine that received the remote theoretical option prices generated by the remote standardized option pricing model.

3. The low-bandwidth system of claim 1 wherein the local universal model interface includes a local application processing interface that manipulates the data received from the upstream application data source into numbered pair data; and the remote universal model interface includes a remote application processing interface that receives the numbered pair data from the local quoting system via the transmission pathway.

4. The low-bandwidth system of claim 2 wherein the local universal model interface includes a local application processing interface that manipulates the data received from the upstream application data source into numbered pair data; and the remote universal model interface includes a remote application processing interface that receives the numbered pair data from the local quoting system via the transmission pathway.

5. The low-bandwidth system of claim 1 wherein the local universal model interface includes a local application processing interface that manipulates the data received from the upstream application data source into numbered pair data with changed values; and the remote universal model interface includes a remote application processing interface that receives the numbered pair data with changed values from the local quoting system via the transmission pathway.

6. The low-bandwidth system of claim 2 wherein the local universal model interface includes a local application processing interface that manipulates the data received from the upstream application data source into numbered pair data with changed values; and the remote universal model interface includes a remote application processing interface that receives the numbered pair data with changed values from the local quoting system via the transmission pathway.

7. The low-bandwidth system of claim 2 wherein the local quoting engine utilizes local quoting formulas and local quoting adjustment and is associated with a local formula transport that isolates changes to the local quotmg formulas and local quoting adjustments; and wherein the remote quoting engine utilizes remote quoting formulas and remote quoting adjustment and is associated with a remote formula transport that receives the isolated changes from the local formula transport via the transmission pathway.

8. A method for low-bandwidth distribution of option quotes from a local quoting system to a remote quoting system comprising: providing data from an upstream application data source to a local universal model interface of a local quoting system; providing the data from the local universal model interface to a local standardized option pricing model; generating local theoretical option prices at the local quoting system; transmitting the data via a transmission pathway to a remote universal model interface of a remote quoting system; providing the data from the remote universal model interface to a remote standardized option pricing model; generating remote theoretical option prices at the remote quoting system.

9. The method of claim 8 further comprising providing the local theoretical option prices generated by the local standardized option pricing model to a local quoting engine; generating local option quotes; providing the remote theoretical option prices generated by the remote standardized option pricing model to a remote quoting engine; generating remote option quotes.

10. The method of claim 8 further comprising manipulating the data received from the upstream application data source into numbered pair data; transmitting the numbered pair data from the local quoting system to the remote quoting system via the transmission pathway.

11. The method of claim 9 further comprising manipulating the data received from the upstream application data source into numbered pair data; transmitting the numbered pair data from the local quoting system to the remote quoting system via the transmission pathway.

12. The method of claim 8 further comprising manipulating the data received from the upstream application data source into numbered pair data with changed values; transmitting the numbered pair data with changed values from the local quoting system to the remote quoting system via the transmission pathway.

13. The low-bandwidth system of claim 9 further comprising manipulating the data received from the upstream application data source into numbered pair data with changed values; transmitting the numbered pair data with changed values from the local quoting system to the remote quoting system via the transmission pathway.

14. The low-bandwidth system of claim 9 further comprising utilizing local quoting formulas and local quoting adjustment in the local quoting engine; isolating changes to local quoting foraiulas and local quoting adjustments in a local formula transport; transmitting the isolated changes from the local formula transport to a remote formula transport via the transmission pathway for use with remote quoting formulas and remote quoting adjustments.