WO2001035309A1 - Trading system for processing market data and method for use - Google Patents

Trading system for processing market data and method for use Download PDF

Info

Publication number
WO2001035309A1
WO2001035309A1 PCT/US2000/031172 US0031172W WO0135309A1 WO 2001035309 A1 WO2001035309 A1 WO 2001035309A1 US 0031172 W US0031172 W US 0031172W WO 0135309 A1 WO0135309 A1 WO 0135309A1
Authority
WO
WIPO (PCT)
Prior art keywords
trading system
data
trading
interval
interval data
Prior art date
Application number
PCT/US2000/031172
Other languages
French (fr)
Inventor
Edward L. Moore
Original Assignee
Rzucidlo Eugene C
Moore Edward L
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Rzucidlo Eugene C, Moore Edward L filed Critical Rzucidlo Eugene C
Priority to AU16576/01A priority Critical patent/AU1657601A/en
Publication of WO2001035309A1 publication Critical patent/WO2001035309A1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F17/00—Digital computing or data processing equipment or methods, specially adapted for specific functions
    • G06F17/10—Complex mathematical operations
    • G06F17/18—Complex mathematical operations for evaluating statistical data, e.g. average values, frequency distributions, probability functions, regression analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange

Definitions

  • This invention relates to the monitoring and processing of periodic data having a random arrival time, for the purpose of detecting the possible onset of special situations which could warrant user action; this invention has particular relevance to the monitoring and processing of market data relating to the trading of securities .
  • Stock market securities (which are represented by symbols) are traded all over the world. It is common to apply mathematical formula or other types of logic to market data in order to attempt to predict the future price of a security. The purpose of such attempts is, generally, to determine whether to buy or sell a security. In recent years, many people involved in trading securities have programmed computers to monitor market data and generate buy or sell signals if their own formula or logic would yield such a result.
  • trade will refer to a transaction wherein a specific volume of a particular security is purchased or sold for a given unit price.
  • market event will refer to events related to the bidding for, and trading of securities.
  • a market event can be a bid, an ask or a trade. Every market event relates to a security, and has an associated price and volume.
  • market data will refer to the historic data relating to market events.
  • Raw market data must identify at least the security involved, the time of the event, the type of the event (i.e., bid, ask or trade), and the price and volume.
  • a market event may occur at any time, subject, of course, to any limitations imposed upon trading that security by law or by other rules, such as the rules of an exchange.
  • raw market data reporting that event may be generated and transmitted at any time subsequent to the event. Although it may be desirable to obtain raw market data as close to the time of the event as possible, the raw market data reflecting an event needs to be coded and then transmitted electronically. Once the raw market data is transmitted, a number of factors determine when that data is received. As is well known, network congestion or other factors can delay the receipt of data.
  • trade data will refer to the market data related only to trades, and not to market data related to bids or asks.
  • trading system will refer to a mathematical formula and/or logic that accepts market data as an input and, determines whether to generate a signal, such as a buy signal or a sell signal.
  • trading systems usually accept other inputs, such as, fixed parameters and/or processed market data; the latter could, for example be output from another trading system.
  • Almost all trading systems can output a buy signal and a sell signal; moreover, most trading systems can output a number of other quantities - quantities, for example, that can be used as input to a later execution of the same trading system, or that can be used as input to other trading systems.
  • a trading system could generate a buy signal if the price of a security falls below a set price and generate a sell signal if the price of that security exceeds another price. More often, a trading system relies upon the trade data subset of market data, and most trading systems require more trade data than the price of the last trade of that security.
  • interval data or "unit data.”
  • frequently used interval periods include: minute data, two-minute data, five-minute data, ten-minute data, fifteen-minute data, half-hour data, hour data and daily data .
  • interval data is available from many commercial sources .
  • the aggregator of such information often transmits interval data to its customers on a subscription basis.
  • interval data is computed for all of the transactions that occurred in a specific time period, a number of factors determine when the interval data is actually transmitted and received. For example, any delay in receiving or aggregating the raw market data can cause a corresponding or even disproportionate delay in the transmission of interval data, and often, network congestion can delay its receipt.
  • a trading system analyses data promptly after the relevant market data becomes available. Due to the unpredictable delay involved in receiving market data it is problematic to synchronise the execution of a trading system to the availability of the relevant market data. Accordingly, when needed, trading systems are run continuously. This approach is wasteful of computer resources. Moreover, in an environment where numerous trading systems need to be run, memory and processor resources are rapidly exhausted. Despite the inefficiency, such a procedure is used due to the simplicity of its implementation, but it results in a relatively limited number of trading systems which may be executed on a computer, due primarily to computer resources and economic considerations.
  • a simple trading system TSl that, for a given security, generates a buy signal when the line representing an x day moving average crosses above the line representing a y day moving average, and generates a sell signal when the line representing the x day moving average crosses below the line representing the y day moving average.
  • the parameters to the trading system are x and y. While one person may be interested in the results of TSl for Intel Corporation, with a three day moving average and a seven day moving average, another person may be interested m the results of TSl for Intel Corporation, with a ten day moving average and a 100 day moving average.
  • an apparatus for fulfilling two or more periodic trading system requests each of the trading system requests being associated with a data interval, a trading system, and an identifier representing a security, comprising the steps of : master data server for receiving raw market data and producing interval data therefrom, the master data server being adapted to transmit interval data relating to a security during a given time in response to a request therefore
  • Figure 1 is a schematic representation of an apparatus that may be used for carrying out the present invention.
  • the present invention provides a method and apparatus for implementing multiple trading systems with varying parameter sets to operate on a plurality of securities.
  • a master data server 1 receives data from one or more sources 2, 3, such as stock exchanges.
  • the master data server 1 stores the data or a derivative of the data on storage device 4.
  • the master data server 1 receives at least trade data from the sources 2, 3, and from the trade data, aggregates and stores interval data on a master storage device 4. For each security, the interval data stored on the master storage device 4. Interval data may contain any data related to a security during the interval, and typically includes the minimum price, the maximum price, the opening price, the closing price and the total volume of the trades, (hereafter
  • the basic time interval may be any unit of time, preferably, the basic time interval will be one minute; thus, the interval data will be minute data.
  • the result of storing minute data necessarily limits the remainder of the system, including the trading systems, to operating on data having resolution no f.ner than one minute. While it is believed that minute data is generally acceptable for modern trading systems, it is within the scope of the invention to increase or decrease the basic time interval depending on the needs of the individual trading systems that will require data and the economics of storing and processing the data.
  • the master data server 1 can additionally create MMOCV data for other units.
  • the master data server 1 creates and stores both minute data and daily data for each security. It is also possible, however, to create, for example, 5 -minute data and store such data on the master storage device 4.
  • a client data server 5 is also provided.
  • the client data server 5 may have access to the master storage device 4 (not shown) , however, in a preferred embodiment the master data server 1 sends MMOCV data to the client data server 5, and the client data server stores the received data on a client storage device 6.
  • the master data server 1 sends MMOCV data to the client data server 5 as requested by the client data server 5. There are two main types of requests, a subscription data request, and a historical data request.
  • a client data server 5 may send to the master data server 1 a request for information about a security called a subscription.
  • the master data server 1 will transmit MMOCV data relating to that security to the client data server 5.
  • the master data server 1 will transmit the MMOCV minute data and the MMOCV daily data to the client data server 5 at regular intervals specified by the subscription, after the close of the relevant market.
  • the master data server 1 will provide the subscribed data to the client data server 5 at the subscription interval until the client data server 5 cancels the subscription.
  • a client data server 5 may also send to the master data server 1 a request for information referred to herein as a historical data request.
  • interval data for a security over a given period is requested.
  • a data request may request minute data for a particular security during a particular fifteen minute period earlier the same day.
  • the inventor believes that it is more efficient to provide that the requests are limited to the basic unit of data maintained by the master data sever 1 on the master storage device 4.
  • a trading system scheduler 7 and a plurality of enhanced trading systems 8-10 are also provided.
  • Enhanced trading systems 8-10 each comprise trading systems 8a-10a.
  • Figure 1 shows only three enhanced trading systems 8-10, it is within the scope of the invention to have any number of enhanced trading systems, limited only by computer resources.
  • a trading system is mathematical formula and/or logic that accepts market data, processed market data and/or other parameters as input, and which may generate data representing a buy or sell signal, among other things, as output.
  • a person that is interested in the buy or sell signal of a particular trading system wants the trading system to be run at some given interval, based upon some predetermined parameters, with respect to a particular security.
  • trading system request refers to a request that a particular trading system be run with a particular set of parameters on data having a particular interval.
  • the trading system scheduler 7 maintains a list of the trading system requests that it must schedule, and for each, maintains the last interval for which the trading system request successfully ran. Since multiple customers may make the same trading system request and there is no reasons to run the same trading system request more than once for a given interval, the trading system scheduler 7 maintains the list of customers that are interested in the results of the particular trading system request.
  • Table 1 shows 11 trading system requests received from three different customers, relating to two different trading systems and three different securities. For simplicity, all of the trading system requests relate to daily data.
  • the scheduler 7 Upon receiving these requests, in a preferred embodiment, the scheduler 7 would reorganise the requests and store them in its table of daily trading system requests: # System Parameters Security Last Customer
  • the scheduler 7 maintains separate lists of enhanced trading systems based upon the frequency of operation, e.g., daily. In other words, the scheduler 7 would maintain a list of trading systems that would require invocation every minute, another list of trading systems that would require invocation every 5 minutes, and another for the enhanced trading systems that run daily, etc.
  • the scheduler 7 then invokes each of the enhanced trading systems 8-10, as appropriate to invoke trading systems 8a-10a.
  • the scheduler 7 invokes the enhanced trading system 8-10, it passes to the enhanced trading system 8-10 certain parameters and/or other variables. The invocation of tasks by a scheduler is well know, as is the passing of variables to the tasks invoked.
  • the variables passed by the trading system scheduler 7 to the enhanced trading systems 8-10 including the period for which the trading system 8a- 10a are to run.
  • the period may be passed as a start and end time/date.
  • the end time/date is obtained by adding the interval period to the time/date of the last successful run, which is maintained by the trading system scheduler.
  • the enhanced trading systems 8-10 determines what interval data is required for operation of the trading systems 8a-10a, respectively. The determination is made by reference to the start and end time/date passed thereto by the scheduler 7 and to the trading systems 8a-10a themselves. Once the required interval data is determined, the enhanced trading systems 8-10 request the required interval data.
  • the enhanced trading system 8-10 would determine that the required interval data runs from four days before the start date, through the end date. In the simplest case, where the daily trading system has successfully run on the preceding day, the start date and end date passed to the enhanced trading system 8-10 will be equal, and only the preceding four days data (and the current days data) are required to compute the moving average.
  • the request for the interval data can be made by the enhanced trading systems 8-10 to the trading system scheduler 7; in another embodiment, the request is made by the enhanced trading systems 8-10 directly to the client data server 5.
  • the scheduler then makes the request to the client data server 5. If the client data server 5 can fulfil the request from the data stored on client storage device 6, whether or not some aggregation of data is required, it does so. If the client data server 5 cannot fulfil the request from the data stored on client storage device 6, it makes a data request to the master data server 1. The master data server 1 then fulfils the data request to the client data server 5 as described above.
  • the execution of the enhanced trading system 8-10 is rescheduled for a later time.
  • the execution of the enhanced trading system 8-10 is rescheduled to await the attempted execution of the trading system requests for the same interval class (i.e., minute data) . If there is any way to know when the data is reasonably expected to be available at the client data server, the execution of the enhanced trading system 8-10 can be rescheduled to run at that time.
  • one of the novel features of the present invention is the ability of an enhanced trading system 8-10 to determine the data that is required for the execution of the related trading system 8a-10a.
  • the enhanced trading system 8-10 can determine the time- series data required to execute the trading system 8a- 10a for a present time, as well as for a prior time.
  • the time-series data required to execute the trading system 8a- 10a is dependent on the history "length" that is required by a particular trading system. History
  • length is the number of consecutive intervals backwards in time from a given time that are required in order to calculate the output values for the trading system at the given time.
  • the history "length" can and are determined in several ways .
  • the enhanced trading system 8- 10 automatically analyses the logic of the trading system 8a-10a and determines from such logic the history "length" that is applicable to the trading system 8a- 10a. This determination is made by finding the largest time unit contained in the logic of the trading system 8a-10a (in other words, the distance from the given time to the oldest data point required by the trading system 8a- 10a), and using that as the "length". In another embodiment, the user override the programmed logic and input a value for the "length” .
  • the user can input an expression, in terms of the parameters of the trading system 8a-10a, that is evaluated when the trading system is called and which results in such a user-defined "length” .
  • the enhanced trading system 8-10 analyses the trading system 8a- 10a for such an expression - if it is found, the expression results in the use of a user- defined "length”; if such an expression is not found, the enhanced trading system 8-10 will automatically analyse the logic of the trading system 8a- 10a and determine from such logic the history "length" that is applicable to the trading system 8a-10a.
  • the enhanced trading systems 8-10 determines the data required for the execution of the related trading systems 8a-10a (by determining the history "length"), and that data is made available to the trading systems 8a-10a when the trading systems 8a-10a are executed.
  • a the execution of a trading system 8a-10a may require the re-calculation of data that had already been calculated by an earlier execution of the same trading system 8a- 10a.
  • the execution of the trading system 8a-10a will necessarily calculate the five day and ten day daily moving averages for the given day, and for the prior day.
  • the trading system request is ongoing, each day, a portion of the prior day's calculations are re-done.
  • the results of calculations for recursive data sets is preferably stored. That is, as a general rule, calculations that require recursive data calculations are stored rather than recalculated. Accordingly, in a preferred embodiment, relevant recursive data computations are stored rather than discarded. In this manner, the prior results are available to the next execution of a trading system 8a- 10a requiring them.
  • the trading system scheduler 7 can store the results and pass them to the enhanced trading systems 8-10 when they are invoked.
  • the variables passed by the trading system scheduler 7 to the enhanced trading systems 8-10 including the period for which the trading system 8a-10a is to be run in relation to, no additional modifications are necessary to use the enhanced trading systems 8-10 to back-test a trading system 8a-10a.
  • the enhanced trading system 8-10 receives the required interval data, it will successively call the respective trading system 8a-10a, and supply it with the interval data and the parameters requires for each successive execution. In the simplest case, where there have been no missing executions, the trading system 8a- 10a will only be called for one iteration. Note that the enhanced trading systems 8-10 can be passed any range of dates, and therefore, any enhanced trading system 8-10 according to the present invention can be used for back- testing the respective trading system 8a-10a.
  • the trading system 8a-10a When the trading system 8a-10a is called, it performs its logic to determine whether signal should be generated, or whether no signal should be generated, and the trading system 8a-10a so indicates upon return from each iteration to the enhanced trading system 8-10.
  • the enhanced trading system calls the trading system scheduler 7 with a similar notification.
  • the trading system scheduler 7 then may either immediately deal with providing the signal, or m a preferred embodiment, schedule the signal to get provided shortly and return to control to the enhanced trading system 8-10.
  • the enhanced trading system 8-10 Upon successful completion of the successive process, the enhanced trading system 8-10 returns an indication thereof to the trading system scheduler 7, which updates its records regarding the last successful execution of the trading system request .
  • trading system scheduler 7 When trading system scheduler 7 is notified that a buy or sell signal is to be generated, it must determine which customer or customers to notify. As shown m Table 2, the identify of the customers that created the trading system request are associated with the request. Once the customers are identified, the trading system scheduler will pass this information, along with other relevant information relating to the signal to be generated, to the customer notification module 11. In a preferred embodiment, the customer notification module will have access to the customers preferred method for contact, which may be stored on a customer storage device 12.
  • any method can be used for contacting the customer 14, including, by way of example, without limitation, a text- to-speech voice call, a pager notification, facsimile and/or email.
  • the notification can contain simply the symbol and an indication for buy and sell, or alternatively, can contain any additional information relating to the signal
  • the use of email presents a novel way of notifying customer 14 of buy/sell signals.
  • the email m addition to the relevant stock symbol, and a buy or sell indication, there can be included a textual, or better yet, a graphical representation of the data that led to the signal.
  • the email does not contain the actual graphical representation, but rather just the data necessary for an external program to recreate the graphical representation. Sending the data rather than the graphical representation, for example, saves significant resources.
  • the customer notification module 11 creates an output that is then delivered to an accounting system (not shown) .
  • the output can indicate to the accounting system the customer for whom a signal was generated; m addition, the output can indicate to the accounting system the symbol, the time and date of the signal, a description of the delivery method, and/or, an indication of whether the signal generated was a buy or sell signal.
  • the generation of such an output permits a novel method of billing customers for the execution of trading systems, namely, billing customers based upon the notification to buy or sell. It is also possible to have the price charged depend upon the method or time of delivery.
  • the trading system scheduler 7 can maintain, m addition to the information already discussed, the amount of history required for the execution of the enhanced trading systems 8-10.
  • the trading system scheduler 7 can make the data request to the client data server 5 to insure the availability of the appropriate data.
  • the trading system scheduler 7 would make a data request for 12 days of INTC data prior to executing trading system requests 1 and 2. In the event that the request was not fulfilled by the client data server 5, neither request 1 nor 2 could run, and both would therefore be rescheduled. Similarly, the trading system scheduler 7 would make a data request for
  • the trading system scheduler 7 can pass the appropriate data to the enhanced trading systems 8-10; alternatively, a special data request could be used that merely indicated whether the data was available, and in that case, the trading system scheduler

Abstract

A method of fulfilling two or more periodic trading system requests, in which each of the trading system requests is associated with a data interval, a trading system, and an identifier representing a security is provided. The system includes a master data server (1) which receives data from one or more sources (2) or (3). The master data server (1) stores the data or a derivative of the data on storage device (4). Client data server (5) sends a request to master data server (1) and stores received data on a client data storage device (6). Upon receiving a request, scheduler (7) reorganizes them in a table of daily trading system requests. A trading system initiates a buy or sell signal based upon aggregare interval data. The buy or sell notice is then transmitted to a customer (14).

Description

TRADING SYSTEM FOR PROCESSING MARKET DATA
AND METHOD FOR USE
Field of the Invention This invention relates to the monitoring and processing of periodic data having a random arrival time, for the purpose of detecting the possible onset of special situations which could warrant user action; this invention has particular relevance to the monitoring and processing of market data relating to the trading of securities .
BACKGROUND OF THE INVENTION
Stock market securities (which are represented by symbols) are traded all over the world. It is common to apply mathematical formula or other types of logic to market data in order to attempt to predict the future price of a security. The purpose of such attempts is, generally, to determine whether to buy or sell a security. In recent years, many people involved in trading securities have programmed computers to monitor market data and generate buy or sell signals if their own formula or logic would yield such a result.
The term "trade" as used herein will refer to a transaction wherein a specific volume of a particular security is purchased or sold for a given unit price.
The term "market event" as used herein will refer to events related to the bidding for, and trading of securities. A market event can be a bid, an ask or a trade. Every market event relates to a security, and has an associated price and volume.
The term "market data" as used herein will refer to the historic data relating to market events. Raw market data must identify at least the security involved, the time of the event, the type of the event (i.e., bid, ask or trade), and the price and volume. A market event may occur at any time, subject, of course, to any limitations imposed upon trading that security by law or by other rules, such as the rules of an exchange. Similarly, raw market data reporting that event may be generated and transmitted at any time subsequent to the event. Although it may be desirable to obtain raw market data as close to the time of the event as possible, the raw market data reflecting an event needs to be coded and then transmitted electronically. Once the raw market data is transmitted, a number of factors determine when that data is received. As is well known, network congestion or other factors can delay the receipt of data.
The term "trade data" as used herein will refer to the market data related only to trades, and not to market data related to bids or asks.
The term "trading system" as used herein will refer to a mathematical formula and/or logic that accepts market data as an input and, determines whether to generate a signal, such as a buy signal or a sell signal. In addition to market data, trading systems usually accept other inputs, such as, fixed parameters and/or processed market data; the latter could, for example be output from another trading system. Almost all trading systems can output a buy signal and a sell signal; moreover, most trading systems can output a number of other quantities - quantities, for example, that can be used as input to a later execution of the same trading system, or that can be used as input to other trading systems. In its simplest form, a trading system could generate a buy signal if the price of a security falls below a set price and generate a sell signal if the price of that security exceeds another price. More often, a trading system relies upon the trade data subset of market data, and most trading systems require more trade data than the price of the last trade of that security.
Most trading systems do not use raw market data as input, but instead, require market data aggregated over a unit of time, also referred to herein as "interval data" or "unit data." Although any unit of time could be used, frequently used interval periods include: minute data, two-minute data, five-minute data, ten-minute data, fifteen-minute data, half-hour data, hour data and daily data .
It is well know to collect and aggregate raw market data into interval data. Today, interval data is available from many commercial sources . The aggregator of such information often transmits interval data to its customers on a subscription basis. Although interval data is computed for all of the transactions that occurred in a specific time period, a number of factors determine when the interval data is actually transmitted and received. For example, any delay in receiving or aggregating the raw market data can cause a corresponding or even disproportionate delay in the transmission of interval data, and often, network congestion can delay its receipt.
Ideally, a trading system analyses data promptly after the relevant market data becomes available. Due to the unpredictable delay involved in receiving market data it is problematic to synchronise the execution of a trading system to the availability of the relevant market data. Accordingly, when needed, trading systems are run continuously. This approach is wasteful of computer resources. Moreover, in an environment where numerous trading systems need to be run, memory and processor resources are rapidly exhausted. Despite the inefficiency, such a procedure is used due to the simplicity of its implementation, but it results in a relatively limited number of trading systems which may be executed on a computer, due primarily to computer resources and economic considerations.
Making the problem more complex, many trading systems are run with varying parameters. Take, for example, a simple trading system TSl that, for a given security, generates a buy signal when the line representing an x day moving average crosses above the line representing a y day moving average, and generates a sell signal when the line representing the x day moving average crosses below the line representing the y day moving average. The parameters to the trading system are x and y. While one person may be interested in the results of TSl for Intel Corporation, with a three day moving average and a seven day moving average, another person may be interested m the results of TSl for Intel Corporation, with a ten day moving average and a 100 day moving average.
Accordingly, even with the storage and processing power of today's computers, it is an enormous problem to operate a large number of trading systems, each having numerous parameter sets, on each of a number of securities, at all of the intervals that may be desired.
SUMMARY OF THE INVENTION
It is an object of the present invention to provide a method and apparatus for efficiently operating a plurality of trading systems.
It is another object of the present invention to provide a method of fulfilling two or more periodic trading system requests, each of the trading system requests being associated with a data interval, a trading system, and an identifier representing a security, comprising the steps of: compiling a list of the trading system requests for each data interval contained m any of the two or more trading system requests; scheduling the lists for review after the associated data interval has elapsed; successively selecting the list scheduled for review at the present time having the smallest data interval associated therewith, and for that list, invoking the trading system associated with the trading system requests m connection with the identifier representing a security It is yet another object of the invention to provide an apparatus for fulfilling two or more periodic trading system requests, each of the trading system requests being associated with a data interval, a trading system, and an identifier representing a security, comprising the steps of : master data server for receiving raw market data and producing interval data therefrom, the master data server being adapted to transmit interval data relating to a security during a given time in response to a request therefore; client data server for receiving interval data for a security over a given time from the master data server, and adapted to provide aggregate interval data relating to integer multiples of the time period represented by the interval data; trading system scheduler for invoking enhanced trading systems at predetermined times, the trading system scheduler also for maintaining a last completion time for each of the two or more trading system requests; enhanced trading systems for requesting aggregate interval data necessary to run one of the trading systems associated with the two or more trading system requests, and for providing the aggregate interval data to the trading system; a trading system for initiating a buy or sell signal based upon the aggregate interval data supplied; and a customer notification module for notifying a customer of a buy or sell signal .
It is a further object of the invention to provide a novel method of notifying customers of a buy or sell signal, namely, via email. It is a further object of the invention to provide a novel method of including data leading to the occurrence of a buy or sell signal in the notification of the buy or sell signal sent to the customer.
It is a further object of the invention to provide a method of charging customers for the operation of the customers trading system by billing the customer for each buy and/or sell signal generated by the trading system.
It is yet a further object of the invention to provide a method of charging customers for signals generated in connection with the execution of a trading system request on a security, comprising: scheduling the execution of the trading system at a predetermined time; retrieve the interval data related to the security required for the operation of the trading system at the predetermined time; executing the trading system on the retrieved interval data; determining whether the trading system generated a signal, and if so, notifying the customer; sending an indication that the customer has been notified to an accounting system; using the accounting system, creating a bill for the customer charging the customer for each notification sent to the customer; and sending the bill to the customer.
It is another object of this invention to provide a method of operating a first trading system that requires a first set of interval data and at least one output of a second trading system as input thereto, the second trading system requiring a second set of interval data as input, the method comprising: inspecting the first trading system to determine the first set of intervals for which interval data is required as input to the first trading system; inspecting the second trading system to determine the second set of interval for which interval data is required to operate the second trading system; computing a third set of intervals as the union of the first set of intervals and the second set of intervals; obtaining the interval data corresponding to the third set of intervals and subsequently, passing to the second trading system the interval data corresponding to the second set of intervals, and operating the second trading system; and passing to the first trading system the interval data corresponding to the first set of intervals, and at least one output of the second trading system, and operating the first trading system.
It is another object of this invention to provide a method of operating a trading system which is based upon data corresponding to a first time-series, the trading system requiring for operation at least a portion of the output of the same trading system based upon data corresponding to a second time-series, the method comprising: obtaining the interval data corresponding to the first time-series and the second time-series; running the trading system based upon the interval data corresponding to the second time-series and generating a trading system output; running the trading system based upon the first time-series of data and at least a portion of the trading system output .
It is another object of this invention to provide a method of operating a trading system, the output of which is based upon a first data set, and requires for its operation at least a portion of the output of a plurality of other trading systems, the method comprising: inspecting the first trading system to determine the other trading systems for which output is required for the operation of the first trading system; successively inspecting the other trading systems to determine any additional other trading systems for which output is required for the operation of the other trading systems; determining the data set representing the union of the data sets required for the operation of the first trading system and the other trading systems; obtaining the required data set, and subsequently: operating such other trading systems and retaining the output of such other trading systems as is required for the operation of any of the other trading systems or for the first trading system; and operating the first trading system, and supplying thereto the required output .
It is another object of this invention to provide a method of operating a trading system, the trading system requiring parameters and interval data as an input, the method comprising the steps of: obtaining the parameters required by the trading system; inspecting the trading system and the parameters to determine the minimum set of data required to operate the trading system with according to the parameters; obtaining the minimum set of data; and operating the trading system m connection with the parameters and the obtained minimum set of data. These and other objects, features and advantages of the present invention will become more evident from the following discussion and examples.
BRIEF DESCRIPTION OF THE DRA INS
Figure 1 is a schematic representation of an apparatus that may be used for carrying out the present invention.
DETAILED DESCRIPTION OF THE INVENTION
The present invention provides a method and apparatus for implementing multiple trading systems with varying parameter sets to operate on a plurality of securities.
Turning first to Figure 1, a master data server 1 is provided. The master data server 1 receives data from one or more sources 2, 3, such as stock exchanges. The master data server 1 the stores the data or a derivative of the data on storage device 4.
In a preferred embodiment, the master data server 1 receives at least trade data from the sources 2, 3, and from the trade data, aggregates and stores interval data on a master storage device 4. For each security, the interval data stored on the master storage device 4. Interval data may contain any data related to a security during the interval, and typically includes the minimum price, the maximum price, the opening price, the closing price and the total volume of the trades, (hereafter
"MMOCV data" for Minimum, Maximum, Opening, Closing and
Volume) . For efficiency, m a preferred embodiment, if a security did not trade during the interval, no data is recorded for that interval for that security.
Although the basic time interval may be any unit of time, preferably, the basic time interval will be one minute; thus, the interval data will be minute data. The result of storing minute data, however, necessarily limits the remainder of the system, including the trading systems, to operating on data having resolution no f.ner than one minute. While it is believed that minute data is generally acceptable for modern trading systems, it is within the scope of the invention to increase or decrease the basic time interval depending on the needs of the individual trading systems that will require data and the economics of storing and processing the data.
The master data server 1 can additionally create MMOCV data for other units. Preferably, the master data server 1 creates and stores both minute data and daily data for each security. It is also possible, however, to create, for example, 5 -minute data and store such data on the master storage device 4. Although inventor believes that, m actual operation, it will be more efficient for a generalised system to store only the minute and daily data, and to derive other data units on an ad hoc basis, it is within the scope of the invention to create and store only the interval data for the minimum interval, or to create and store additional MMOCV data; namely, interval data based on an interval other than the basic unit employed by the system. A client data server 5 is also provided. The client data server 5 may have access to the master storage device 4 (not shown) , however, in a preferred embodiment the master data server 1 sends MMOCV data to the client data server 5, and the client data server stores the received data on a client storage device 6. The master data server 1 sends MMOCV data to the client data server 5 as requested by the client data server 5. There are two main types of requests, a subscription data request, and a historical data request.
A client data server 5 may send to the master data server 1 a request for information about a security called a subscription. Once a client data server 5 has sent such a request to the master data server 1, the master data server 1 will transmit MMOCV data relating to that security to the client data server 5. In a preferred embodiment, the master data server 1 will transmit the MMOCV minute data and the MMOCV daily data to the client data server 5 at regular intervals specified by the subscription, after the close of the relevant market. After receiving the data subscription, the master data server 1 will provide the subscribed data to the client data server 5 at the subscription interval until the client data server 5 cancels the subscription.
A client data server 5 may also send to the master data server 1 a request for information referred to herein as a historical data request. In this case interval data for a security over a given period is requested. For example, a data request may request minute data for a particular security during a particular fifteen minute period earlier the same day. Although it is within the scope of the invention to permit the client data server 5 to request, for example five-minute data over the earlier fifteen minute period, the inventor believes that it is more efficient to provide that the requests are limited to the basic unit of data maintained by the master data sever 1 on the master storage device 4.
A trading system scheduler 7 and a plurality of enhanced trading systems 8-10 are also provided. Enhanced trading systems 8-10 each comprise trading systems 8a-10a. Although Figure 1 shows only three enhanced trading systems 8-10, it is within the scope of the invention to have any number of enhanced trading systems, limited only by computer resources.
As discussed above, a trading system is mathematical formula and/or logic that accepts market data, processed market data and/or other parameters as input, and which may generate data representing a buy or sell signal, among other things, as output. A person that is interested in the buy or sell signal of a particular trading system wants the trading system to be run at some given interval, based upon some predetermined parameters, with respect to a particular security. Thus, as used herein "trading system request" refers to a request that a particular trading system be run with a particular set of parameters on data having a particular interval. Accordingly, the trading system scheduler 7 maintains a list of the trading system requests that it must schedule, and for each, maintains the last interval for which the trading system request successfully ran. Since multiple customers may make the same trading system request and there is no reasons to run the same trading system request more than once for a given interval, the trading system scheduler 7 maintains the list of customers that are interested in the results of the particular trading system request.
Consider the following example. Table 1 shows 11 trading system requests received from three different customers, relating to two different trading systems and three different securities. For simplicity, all of the trading system requests relate to daily data.
# Customer System Parameters S Seeccuurriittyy Interval
1 Cl TSl 4, 3 INTC daily
2 Cl TSl 3, 7 INTC daily
3 Cl TSl 4, 3 AMAT daily
4 Cl TS2 4, 6, 8 IBM daily
5 C2 TSl 4, 3 INTC daily
6 C2 TSl 3, 7 INTC daily
7 C2 TS2 4, 7, 9 IBM daily
8 C3 TSl 3, 7 INTC daily
9 C3 TSl 4, 3 AMAT daily
10 C3 TS2 4, 6, 8 AMAT daily
11 C3 TS2 4, 6, 8 IBM daily
TABLE 1 Upon receiving these requests, in a preferred embodiment, the scheduler 7 would reorganise the requests and store them in its table of daily trading system requests: # System Parameters Security Last Customer
1 TSl 4, 3 INTC Cl, C2
2 TSl 3, 7 INTC Cl , C2 , C3 TSl 4, 3 AMAT Cl, C3
TS2 4, 6, 8 IBM Cl, C3
TS2 4, 7, 9 IBM C2
TS2 4, 6, 8 AMAT C3
TABLE 2 While the precise order of the trading system requests in Table 2 is less important, note that the redundant operations of the trading systems, namely where they were running for different customers on the same data, have been eliminated. Although the order is generally unimportant within the records of Table 2, it is important to note that all of the Table 2 trading system requests relate to daily data. In a preferred embodiment, the trading system requests relating to the smallest intervals are given priority over trading system requests for larger intervals. In other words, all trading system requests related to minute data will be performed ahead of any that relate to five minute data; similarly all of the five minute data executions should be completed before dealing with 10 or 20 minute data, or daily data, trading system requests.
In a preferred embodiment, the scheduler 7 maintains separate lists of enhanced trading systems based upon the frequency of operation, e.g., daily. In other words, the scheduler 7 would maintain a list of trading systems that would require invocation every minute, another list of trading systems that would require invocation every 5 minutes, and another for the enhanced trading systems that run daily, etc. The scheduler 7 then invokes each of the enhanced trading systems 8-10, as appropriate to invoke trading systems 8a-10a. When the scheduler 7 invokes the enhanced trading system 8-10, it passes to the enhanced trading system 8-10 certain parameters and/or other variables. The invocation of tasks by a scheduler is well know, as is the passing of variables to the tasks invoked.
In a preferred embodiment, the variables passed by the trading system scheduler 7 to the enhanced trading systems 8-10 including the period for which the trading system 8a- 10a are to run. The period may be passed as a start and end time/date. In a simplified case, the end time/date is obtained by adding the interval period to the time/date of the last successful run, which is maintained by the trading system scheduler.
When called, the enhanced trading systems 8-10 determines what interval data is required for operation of the trading systems 8a-10a, respectively. The determination is made by reference to the start and end time/date passed thereto by the scheduler 7 and to the trading systems 8a-10a themselves. Once the required interval data is determined, the enhanced trading systems 8-10 request the required interval data.
In the case, for example, of a daily trading system 8a-
10a computing a five day moving average, the enhanced trading system 8-10 would determine that the required interval data runs from four days before the start date, through the end date. In the simplest case, where the daily trading system has successfully run on the preceding day, the start date and end date passed to the enhanced trading system 8-10 will be equal, and only the preceding four days data (and the current days data) are required to compute the moving average.
In one embodiment, the request for the interval data can be made by the enhanced trading systems 8-10 to the trading system scheduler 7; in another embodiment, the request is made by the enhanced trading systems 8-10 directly to the client data server 5. In the former case, the scheduler then makes the request to the client data server 5. If the client data server 5 can fulfil the request from the data stored on client storage device 6, whether or not some aggregation of data is required, it does so. If the client data server 5 cannot fulfil the request from the data stored on client storage device 6, it makes a data request to the master data server 1. The master data server 1 then fulfils the data request to the client data server 5 as described above.
In either event, if the required interval data is not available, the execution of the enhanced trading system 8-10 is rescheduled for a later time. In a preferred embodiment, the execution of the enhanced trading system 8-10 is rescheduled to await the attempted execution of the trading system requests for the same interval class (i.e., minute data) . If there is any way to know when the data is reasonably expected to be available at the client data server, the execution of the enhanced trading system 8-10 can be rescheduled to run at that time. As discussed above, one of the novel features of the present invention is the ability of an enhanced trading system 8-10 to determine the data that is required for the execution of the related trading system 8a-10a. The enhanced trading system 8-10 can determine the time- series data required to execute the trading system 8a- 10a for a present time, as well as for a prior time. The time-series data required to execute the trading system 8a- 10a is dependent on the history "length" that is required by a particular trading system. History
"length" is the number of consecutive intervals backwards in time from a given time that are required in order to calculate the output values for the trading system at the given time.
The history "length" can and are determined in several ways .
In a preferred embodiment, the enhanced trading system 8- 10 automatically analyses the logic of the trading system 8a-10a and determines from such logic the history "length" that is applicable to the trading system 8a- 10a. This determination is made by finding the largest time unit contained in the logic of the trading system 8a-10a (in other words, the distance from the given time to the oldest data point required by the trading system 8a- 10a), and using that as the "length". In another embodiment, the user override the programmed logic and input a value for the "length" .
Alternatively, the user can input an expression, in terms of the parameters of the trading system 8a-10a, that is evaluated when the trading system is called and which results in such a user-defined "length" . When using such an alternative, the enhanced trading system 8-10 analyses the trading system 8a- 10a for such an expression - if it is found, the expression results in the use of a user- defined "length"; if such an expression is not found, the enhanced trading system 8-10 will automatically analyse the logic of the trading system 8a- 10a and determine from such logic the history "length" that is applicable to the trading system 8a-10a.
Selecting or determining a history "length" that is too large results in requesting more data than necessary, and may also result in the calculation of each point taking more time than necessary. Selection of a "length" that is too small, however, will result in the an incorrect determination of the trading system output. Accordingly, in a preferred embodiment, where the enhanced trading system 8-10 automatically analyses the logic of the trading system 8a-10a, the determination of the history "length" should be err on the side of an over- inclusive "length," rather than an under- inclusive "length." In other words, in a preferred embodiment, the tendency is to be generous with the calculation of "length."
As an example of the determination of "length," consider a trading system 8a-10a that determines whether a five day daily moving average crosses below a ten day daily moving average for the same security. To calculate a five and a ten day daily moving average requires data for the most recent ten periods, i.e., a history "length" of ten periods. To determine whether the five day line crosses below the ten day line, however, requires, that, the prior daily results are also calculated or retrieved. Accordingly, if the prior daily results are retrieved, the history "length" is ten periods, but if they cannot be retrieved, the history "length" is eleven periods. One of the novel features of the present system is that the enhanced trading systems 8-10 determines the data required for the execution of the related trading systems 8a-10a (by determining the history "length"), and that data is made available to the trading systems 8a-10a when the trading systems 8a-10a are executed.
It is clear from the foregoing that a the execution of a trading system 8a-10a may require the re-calculation of data that had already been calculated by an earlier execution of the same trading system 8a- 10a. Using the example above, and further assuming that the example referred to making the calculation on a given day, the execution of the trading system 8a-10a will necessarily calculate the five day and ten day daily moving averages for the given day, and for the prior day. Thus, assuming that the trading system request is ongoing, each day, a portion of the prior day's calculations are re-done. While this causes re-calculations , it frees the system from the alternatives, namely, storage and retrieval of a large amount of data, or "continuous" running of a trading system 8a-10a. The latter fraught with resource management issues and problems and under the continuous spectre of power loss or system corruption. While according to the present invention it is not necessary to store results from calculations relating to a relatively small amount of time-series data, it is intended that the calculation results based upon larger amounts of time-series data will be stored, preferably by the trading system scheduler 7. The trading system scheduler 7 would pass such stored calculation results to the enhanced trading systems 8-10 or to the trading systems 8a- 10a themselves. The amount of data required for a calculation that would be considered large enough to store the calculation results will be implementation dependent, and relatively easy to determine for any given implementation.
Although the recalculation of results is appropriate for some finite data sets, the results of calculations for recursive data sets is preferably stored. That is, as a general rule, calculations that require recursive data calculations are stored rather than recalculated. Accordingly, in a preferred embodiment, relevant recursive data computations are stored rather than discarded. In this manner, the prior results are available to the next execution of a trading system 8a- 10a requiring them. The trading system scheduler 7 can store the results and pass them to the enhanced trading systems 8-10 when they are invoked.
Note that some recursive calculations may result in a tail of ageing data that becomes increasingly irrelevant to the trading system 8a-10a calculation as it occurs further in the past, while other recursive calculations may cause very old data to be significant to the trading system 8a- 10a. Although it can vary from implementation to implementation, it would be desirable in implementing the present invention to discard the former, while storing and maintaining the latter.
As also discussed above, the variables passed by the trading system scheduler 7 to the enhanced trading systems 8-10 including the period for which the trading system 8a-10a is to be run in relation to, no additional modifications are necessary to use the enhanced trading systems 8-10 to back-test a trading system 8a-10a.
Once the enhanced trading system 8-10 receives the required interval data, it will successively call the respective trading system 8a-10a, and supply it with the interval data and the parameters requires for each successive execution. In the simplest case, where there have been no missing executions, the trading system 8a- 10a will only be called for one iteration. Note that the enhanced trading systems 8-10 can be passed any range of dates, and therefore, any enhanced trading system 8-10 according to the present invention can be used for back- testing the respective trading system 8a-10a.
When the trading system 8a-10a is called, it performs its logic to determine whether signal should be generated, or whether no signal should be generated, and the trading system 8a-10a so indicates upon return from each iteration to the enhanced trading system 8-10. In a preferred embodiment, where a trading system 8a- 10a indicates to the respective enhanced trading system 8-10 that a buy or sell signal should be generated, the enhanced trading system calls the trading system scheduler 7 with a similar notification. The trading system scheduler 7 then may either immediately deal with providing the signal, or m a preferred embodiment, schedule the signal to get provided shortly and return to control to the enhanced trading system 8-10.
Upon successful completion of the successive process, the enhanced trading system 8-10 returns an indication thereof to the trading system scheduler 7, which updates its records regarding the last successful execution of the trading system request .
When trading system scheduler 7 is notified that a buy or sell signal is to be generated, it must determine which customer or customers to notify. As shown m Table 2, the identify of the customers that created the trading system request are associated with the request. Once the customers are identified, the trading system scheduler will pass this information, along with other relevant information relating to the signal to be generated, to the customer notification module 11. In a preferred embodiment, the customer notification module will have access to the customers preferred method for contact, which may be stored on a customer storage device 12.
Any method can be used for contacting the customer 14, including, by way of example, without limitation, a text- to-speech voice call, a pager notification, facsimile and/or email. Moreover, the notification can contain simply the symbol and an indication for buy and sell, or alternatively, can contain any additional information relating to the signal For example, the use of email presents a novel way of notifying customer 14 of buy/sell signals. In the email, m addition to the relevant stock symbol, and a buy or sell indication, there can be included a textual, or better yet, a graphical representation of the data that led to the signal. In a preferred embodiment, the email does not contain the actual graphical representation, but rather just the data necessary for an external program to recreate the graphical representation. Sending the data rather than the graphical representation, for example, saves significant resources.
Furthermore, m a preferred embodiment, the customer notification module 11 creates an output that is then delivered to an accounting system (not shown) . The output can indicate to the accounting system the customer for whom a signal was generated; m addition, the output can indicate to the accounting system the symbol, the time and date of the signal, a description of the delivery method, and/or, an indication of whether the signal generated was a buy or sell signal. The generation of such an output permits a novel method of billing customers for the execution of trading systems, namely, billing customers based upon the notification to buy or sell. It is also possible to have the price charged depend upon the method or time of delivery.
In order to streamline the execution of the enhanced trading system 8-10, m a preferred embodiment, the trading system scheduler 7 can maintain, m addition to the information already discussed, the amount of history required for the execution of the enhanced trading systems 8-10.
# System Parameters Security Last Hist Customer
1 TSl 4, 3 INTC 10 Cl, C2
2 TSl 3, 7 INTC 12 Cl, C2, C3
3 TSl 4, 3 AMAT 13 Cl, C3
4 TS2 4, 6, 8 IBM 5 Cl, C3
5 TS2 4, 7, 9 IBM 19 C2
6 TS2 4, 6, 8 AMAT 22 C3
TABLE 3
Where the trading system scheduler 7 maintains this information, the trading system scheduler 7, itself, can make the data request to the client data server 5 to insure the availability of the appropriate data. In other words, using the sample daily trading system requests set out in Table 3, the trading system scheduler 7 would make a data request for 12 days of INTC data prior to executing trading system requests 1 and 2. In the event that the request was not fulfilled by the client data server 5, neither request 1 nor 2 could run, and both would therefore be rescheduled. Similarly, the trading system scheduler 7 would make a data request for
22 days of AMAT data and 19 days of IBM data prior to executing trading system requests 3 and 6, and 4 and 5, respectively. Where the data requests are fulfilled by the client data server 5, the trading system scheduler 7 can pass the appropriate data to the enhanced trading systems 8-10; alternatively, a special data request could be used that merely indicated whether the data was available, and in that case, the trading system scheduler
7 would be relieved of having to retrieve and manage the interval data. While the trading systems are described herein in terms of requiring market data related only to a single security, it is within the scope of the invention, and will be apparent to a person of skill in the art, to schedule trading systems that require market data relating to multiple securities as input.
While the foregoing describes and illustrates the preferred embodiment of the present invention and suggests certain modifications thereto, those of ordinary skill in the art will recognize that still further changes and modifications may be made therein without departing from the spirit and scope of the invention. Accordingly, the above description should be construed as illustrative and not in a limiting sense, the scope of the invention being defined by the following claims.

Claims

What is claimed is:
1. A method of fulfilling two or more periodic trading system requests, each of the trading system requests being associated with a data interval, a trading system, and an identifier representing a security, comprising the steps of: compiling a list of the trading system requests for each data interval contained in any of the two or more trading system requests; scheduling the lists for review after the associated data interval has elapsed; successively selecting the list scheduled for review at the present time having the smallest data interval associated therewith, and for that list, invoking the trading system associated with the trading system requests in connection with the identifier representing a security.
2. An apparatus for fulfilling two or more periodic trading system requests, each of the trading system requests being associated with a data interval, a trading system, and an identifier representing a security, comprising the steps of: master data server for receiving raw market data and producing interval data therefrom, the master data server being adapted to transmit interval data relating to a security during a given time in response to a request therefore; client data server for receiving interval data for a security over a given time from the master data server, and adapted to provide aggregate interval data relating to integer multiples of the time period represented by the interval data; trading system scheduler for invoking enhanced trading systems at predetermined times, the trading system scheduler also for maintaining a last completion time for each of the two or more trading system requests; enhanced trading systems for requesting aggregate interval data necessary to run one of the trading systems associated with the two or more trading system requests, and for providing the aggregate interval data to the trading system; a trading system for initiating a buy or sell signal based upon the aggregate interval data supplied; and a customer notification module for notifying a customer of a buy or sell signal.
3. A method of charging customers for signals generated by the execution of a trading system request on a security, comprising: scheduling the execution of the trading system at a predetermined time; retrieve the interval data related to the security required for the operation of the trading system at the predetermined time; executing the trading system on the retrieved interval data; determining whether the trading system generated a signal, and if so, notifying the customer; sending an indication that the customer has been notified to an accounting system; using the accounting system, creating a bill for the customer charging the customer for each notification sent to the customer; and sending the bill to the customer.
4. The method claimed in claim 3 , wherein the signal is a buy signal, and the step of notifying the customer includes notifying the customer that a buy signal was generated.
5. The method claimed in claim 3 , wherein the signal is a sell signal, and the step of notifying the customer includes notifying the customer that a sell signal was generated.
6. A method of operating a first trading system that requires a first set of interval data and at least one output of a second trading system as input thereto, the second trading system requiring a second set of interval data as input, the method comprising: inspecting the first trading system to determine the first set of intervals for which interval data is required as input to the first trading system; inspecting the second trading system to determine the second set of interval for which interval data is required to operate the second trading system; computing a third set of intervals as the union of the first set of intervals and the second set of intervals ; obtaining the interval data corresponding to the third set of intervals and subsequently, passing to the second trading system the interval data corresponding to the second set of intervals, and operating the second trading system; and passing to the first trading system the interval data corresponding to the first set of intervals, and at least one output of the second trading system, and operating the first trading system.
7. The method claimed m claim 4, wherein the first trading system and the second trading system are identical .
8. A method of operating a trading system which is based upon data corresponding to a first time- series, the trading system requiring for operation at least a portion of the output of the same trading system based upon data corresponding to a second time-series, the method comprising: obtaining the interval data corresponding to the first time-series and the second time-series; running the trading system based upon the interval data corresponding to the second time-series and generating a trading system output; running the trading system based upon the first time-series of data and at least a portion of the trading system output .
9. The method claimed m claim 8, wherein running the trading system based upon the second time-series of interval data requires at least a portion of the output of the same trading system for at least one additional time-series of interval data, and wherein the step of obtaining the interval data additionally obtains interval data corresponding to the at least one additional time-series of interval data, further comprising: successively running the trading system based upon the oldest unused additional time-series of interval data and obtaining an additional output, and supplying at least a portion of the additional output to the trading system for operation on the next iteration;
10. A method of operating a trading system, the output of which is based upon a first data set, and requires for its operation at least a portion of the output of a plurality of other trading systems, the method comprising: inspecting the first trading system to determine the other trading systems for which output is required for the operation of the first trading system; successively inspecting the other trading systems to determine any additional other trading systems for which output is required for the operation of the other trading systems; determining the data set representing the union of the data sets required for the operation of the first trading system and the other trading systems; obtaining the required data set, and subsequently : operating such other trading systems and retaining the output of such other trading systems as is required for the operation of any of the other trading systems or for the first trading system; and operating the first trading system, and supplying thereto the required output .
11. A method of operating a trading system, the trading system requiring parameters and interval data as an input, the method comprising the steps of: obtaining the parameters required by the trading system; inspecting the trading system and the parameters to determine the minimum set of data required to operate the trading system with according to the parameters ; obtaining the minimum set of data; and operating the trading system in connection with the parameters and the obtained minimum set of data.
12. The method claimed in claim 11 wherein the data is interval data.
PCT/US2000/031172 1999-11-12 2000-11-13 Trading system for processing market data and method for use WO2001035309A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU16576/01A AU1657601A (en) 1999-11-12 2000-11-13 Trading system for processing market data and method for use

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US43824099A 1999-11-12 1999-11-12
US09/438,240 1999-11-12

Publications (1)

Publication Number Publication Date
WO2001035309A1 true WO2001035309A1 (en) 2001-05-17

Family

ID=23739831

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/031172 WO2001035309A1 (en) 1999-11-12 2000-11-13 Trading system for processing market data and method for use

Country Status (2)

Country Link
AU (1) AU1657601A (en)
WO (1) WO2001035309A1 (en)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6012042A (en) * 1995-08-16 2000-01-04 Window On Wallstreet Inc Security analysis system
US6014643A (en) * 1996-06-28 2000-01-11 Minton; Vernon F. Interactive securities trading system
US6134535A (en) * 1994-03-23 2000-10-17 Belzberg Financial Markets & News International Inc. Computerized stock exchange trading system automatically formatting orders from a spreadsheet to an order entry system

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6134535A (en) * 1994-03-23 2000-10-17 Belzberg Financial Markets & News International Inc. Computerized stock exchange trading system automatically formatting orders from a spreadsheet to an order entry system
US6012042A (en) * 1995-08-16 2000-01-04 Window On Wallstreet Inc Security analysis system
US6014643A (en) * 1996-06-28 2000-01-11 Minton; Vernon F. Interactive securities trading system

Also Published As

Publication number Publication date
AU1657601A (en) 2001-06-06

Similar Documents

Publication Publication Date Title
JP6878512B2 (en) Rolling resource credits for scheduling virtual computer resources
CN109345377B (en) Data real-time processing system and data real-time processing method
KR101667697B1 (en) Synchronized Processing of Data By Networked Computing Resources
CN107534584B (en) Coordinated processing of data through networked computing resources
US11526485B2 (en) System and method for improved data consistency in data systems including dependent algorithms
EP1812863B1 (en) Reporting of abnormal computer resource utilization data
US20110314477A1 (en) Fair share scheduling based on an individual user's resource usage and the tracking of that usage
US8856071B2 (en) Minimizing staleness in real-time data warehouses
US20050177414A1 (en) Method and apparatus for automatically and continuously pruning prediction models in real time based on data mining
CN101911047A (en) Distribute according to service level agreement prediction and management resource
CN110716800B (en) Task scheduling method and device, storage medium and electronic equipment
US20210232479A1 (en) Predictive reserved instance for hyperscaler management
CA3143827A1 (en) Fund data processing method, apparatus, computer device and storage medium
CN111179080B (en) Order processing method and order processing device
US6349320B1 (en) Computer executable workflow management and control system
CN114661476A (en) Task processing method, device, equipment and storage medium
CN110321364B (en) Transaction data query method, device and terminal of credit card management system
CN114140252A (en) Resource allocation method of target object and related device
CN106530084B (en) Information processing method and server
WO2001035309A1 (en) Trading system for processing market data and method for use
CN115578105A (en) Method and device for processing transaction data
CN109035023A (en) A kind of stock intelligent Trade method, system and device based on cloud
CN114283007A (en) Method and device for solving payment hotspot account problem and electronic equipment
CN113537937A (en) Task arrangement method, device and equipment based on topological sorting and storage medium
CN111367680A (en) Job task allocation method, device, server, system and storage medium

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP