WO2000077708A1

WO2000077708A1 - Method and apparatus for managing distributed trading

Info

Publication number: WO2000077708A1
Application number: PCT/US2000/016419
Authority: WO
Inventors: Barry J. Gleeson; Ellen J. Reier; Warren P. Reier
Original assignee: C#Minor Software, Inc.
Priority date: 1999-06-14
Filing date: 2000-06-14
Publication date: 2000-12-21
Also published as: AU5333600A

Abstract

A method for managing distributed trading is described that comprises the steps of establishing a cumulative trade limit (301), defining a cumulative trade value accuracy (302, 303, 304, 305), processing a proposed trade request to establish a projected cumulative trade value, and adjusting the cumulative trade value accuracy (302, 303, 304, 305) with a predetermined accuracy function based on the projected cumulative trade value and the cumulative trade limit (301). An apparatus for performing the method of the present invention is also provided.

Description

METHOD AND APPARATUS FOR MANAGING DISTRIBUTED TRADING

BACKGROUND OF THE INVENTION

Field of the Invention

This invention relates generally to a method for managing trading of a given item. More specifically, this invention relates to a method for managing trading of items that are traded at distributed trading locations using a computer network.

Description of Related Art

There are many situations in which it is desirable to manage trading of a particular item, where such trading may include the sale or exchange of a particular good, product or commodity. More particularly, it is desirable to manage such trading when it is conducted at multiple locations and involves more than one item, such as the sale of various products from different sales offices or the movement of inventory of various items between departments or warehouses within a particular company.

For example, a large multi-national bank typically desires to know the total value of its investment portfolio and the total value of each financial instrument in that portfolio. This information is used to assist the bank in making additional investment decisions. However, the trading of each of these financial instruments is usually conducted in many different offices or trading locations around the world where each is trading the same or different financial instruments. Each such office typically has its own trading floor and trade handling system, including software on the trader's desktop systems along with various servers and databases. These systems are usually heterogeneous both within and between offices, such that a single office may use entirely different systems to handle different financial instruments. It is often the case that the various offices have become part of one bank through a sequence of mergers and acquisitions in which case the offices will not only have different systems, but different methods and rules for conducting trading.

To ensure that the bank's investments are commensurate with its investment risk in such a distributed trading situation, a number of techniques are used. Limits are a commonly used mechanism. For example, a bank might decide to keep its total debt denominated in a particular currency to less than a certain amount or that its total exposure to default by a particular company should be limited. Software for managing such limits is available from a number of vendors.

Usually, this software is an integrated part of a trading system provided by that vendor.

Such a software package will impose limits on all the trading operations managed by that particular package. However, in a distributed trading setting, each trading system is isolated and unaware of the activities of the other systems around the world. Yet the bank needs to enforce its limits based on its total position or value with respect to a particular financial instrument on a real-time basis.

Based on the foregoing, there is a need for a method for managing distributed trading of multiple items being traded by and among various locations on a real- time basis.

SUMMARY OF THE INVENTION Accordingly, the present invention provides a method for managing trading of items that are traded at different locations where trading includes literally any exchange of a particular item and the various locations may be offices located around the world or departments within a single company. Specifically, the present invention provides the ability to manage and coordinate such distributed trading of various items in real time based upon desired trading practices and policies. Therefore, the present invention provides a method by which trading of a particular item at distributed locations can be monitored and controlled according to the user's trading procedures and policies.

The present invention may be operated using a computer network that links each local trading location to a central or global coordinating computer or computers. As such the method of the present invention minimizes the latency or time required to authorize trades. In addition, the present invention allows for the integration of new local trading locations with minimal disruption of trading elsewhere in the system. The present invention is also designed to operate 24 hours per day, seven days per week.

The method of the present invention may be beneficially utilized in several situations. For example, a bank or investment company may use the present invention to coordinate trading of various financial instruments by its various local offices. The bank may impose several different limits and trading policies based upon the global or total value or position held by the bank at all of its local offices with respect to each financial instrument.

Other examples in which managing trading would be desirable include such industries as telecommunications, manufacturing, health care and accounting. In the telecommunications industry, the trading of bandwidth could be managed using a distributed trading system. In manufacturing, inventory and supply chains could be managed using a distributed trading system. In the health care industry the allocation of limited supplies of a vaccine or health care staff could be more efficiently managed. Accounting functions could also be managed using a trading system to provide real-time analysis.

These and other benefits are provided by the method of the present invention which comprises the steps of establishing a cumulative trade limit, defining a cumulative trade value accuracy, processing a proposed trade request to establish a projected cumulative trade value, and adjusting the cumulative trade value accuracy with a predetermined accuracy function based on the projected cumulative trade value and the cumulative trade limit. An apparatus for performing the method of the present invention is also provided.

Additional features of the invention will appear from the following description from which the preferred embodiments are set forth in detail in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a diagram of a distributed trading system in accordance with an embodiment of the present invention; FIG. 2 is a distributed trading system in accordance with an embodiment of the present invention;

FIG. 3 shows a cumulative limit structure for a coordinator in accordance with an embodiment of the present invention;

FIG. 4 shows the types of communications that may occur between a coordinator and an interceptor in accordance with an embodiment of the present invention; FIG. 5 is a trade authorization process in accordance with an embodiment of the present invention;

FIG. 6 is a target slack function in accordance with an embodiment of the present invention; FIG. 7 is a slack division process in accordance with an embodiment of the present invention;

FIG. 8 is a slack division readjustment process in accordance with an embodiment of the present invention;

FIG. 9 is a proactive interceptor local trade range adjustment process in accordance with an embodiment of the present invention;

- FIG. 10 is a concurrency diagram illustrating an operation performed in accordance with an embodiment of the present invention;

FIG. 1 1 is another concurrency diagram illustrating an operation performed in accordance with an embodiment of the present invention; FIG. 12 is yet another a concurrency diagram illustrating an operation performed in accordance with an embodiment of the present invention: and

FIG. 13 is still yet another concurrency diagram illustrating an operation performed in accordance with an embodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The present invention is generally directed to management of distributed trading. That is. the invention relates to managing the trading of items conducted at different trading locations. It should be appreciated that "item" refers to and includes anything that is capable of being traded, exchanged, sold, bartered, leased, lent, tracked. counted, disposed of. etc. and may include tangible as well as intangible items. It should further be appreciated that the trading locations need not be in physically different locations, nor does each trading location have to trade each item of interest. Each trading location may trade the same items or may exclusively trade other items.

Trades of items may be further categorized by sorting such trades into "buckets," where each bucket is defined to be a particular type of item, group of items or collection of other buckets. Buckets may be organized in a hierarchical fashion such that a single trade for a given item may impact more than one bucket. For discussion purposes, however, the invention will be described in terms of a single item being traded, and therefore, "bucket" and "item" may be used interchangeably. However, it should be appreciated that the invention encompasses the ability to organize the trading of items in a hierarchical or other organizational fashion to provide a method for managing distributed trading at a more generic level.

Generally, the present invention operates to coordinate or manage trading that occurs at various local trading locations. The coordinating function may be performed at a single, central location, or may be performed cooperatively, with participants in multiple locations.

The coordinator combines information from the local trading locations to assess the overall amount or value of that particular item held by the entire distributed trading system, which is referred to as the cumulative trade value, or global position. It should be appreciated that the amount or value of a particular item may refer to the monetary value or quantity of that item, or to any other numerical attribute of the item or collection of items, and that '"amount", "value" and "position^" may be used interchangeably. It should also be appreciated that a wide variety of methods of combining information from the local trading locations may be used, including (but not limited to) the summation of. any linear combination of. or the product of the amounts held by the set of local trading locations. The amount held by a given local trading location is also referred to as the local trade value.

Further, the amount or value of a particular item may be a precise amount where the exact quantity of the item is known, or it may be an imprecise amount where the amount is only known to be within a particular range. For example, the cumulative trade value for a particular item may be the exact total value in dollars of that item held by the entire trading system (e.g., 100 shares or $2,000).

Alternatively, the cumulative trade value may be an imprecise amount known only to be within a particular range, (e.g., between 90 and 1 10 shares or between $1800 and $2200), referred to as the current global range. There are two aspects to an imprecise amount. First is the magnitude or size of the global range (e.g., 20 shares and $400, respectively), and the second is the actual values associated with the global range or more specifically the bounds of the global range (e.g., 90 and 1 10 shares, and $1800 and $2200, respectively). The magnitude or size of the global range is referred to below as accuracy. Therefore, for example, when discussing the cumulative trade value, if such value is imprecise there is a corresponding global range, having a cumulative trade value accuracy, within which the cumulative trade value is known. It should be appreciated that references to a trade value encompass both precise and imprecise values. Further, it should be appreciated that there is a cumulative trade value accuracy associated with precise values, in which case the accuracy is maximized by setting the size of the global range to zero. Lastly, for purposes of discussion, the accuracy is also referred to as "slack," whereby a slack of zero is the same as an accuracy with a global range size of zero in which case the cumulative trade value is known precisely. Relative to the cumulative trade value, as opposed to the value or position of an item at a local trading location, the slack may be referred to as the global slack.

The coordinator uses a predetermined global or cumulative trade limit for each item of interest being traded. Each cumulative trade limit is established as a predetermined value for a particular item being traded for the entire distributed trading system and is based upon a desire to know when the cumulative trade value of that item crosses this limit. The notion of a limit can be applied to any attribute that can be quantified. For example, a bank^'s board of directors might insist that a particular risk metric be kept within a particular range of values at all times.

When the cumulative trade value crosses this limit, the system may be utilized to simply provide notice of such crossing with no change in trading procedure or to provide a specific response such as blocking any additional trades until authorization has been provided. In addition, a cumulative trade range may be defined that is associated with a particular trading policy or procedure. It should be appreciated that the coordinator may actually have a set of cumulative trade ranges with different trading procedures associated with each cumulative trade range. In this case, when the cumulative trade value crosses from one cumulative trade range into another, a different trading policy may be implemented.

Each local trading location has a local trade range set for it, within which the local trade value or local position resides with respect to a given item. Trading may be executed at a particular local trading location; however, when a proposed trade would be outside of the local trade range, interaction with the coordinator would be required. Such interaction may result in communication between the coordinator and other local trading locations. Further, such interaction may result in a notice to the user that a cumulative limit or a local limit has been crossed. It should be appreciated that the magnitude of the local trade range is essentially a local accuracy or local slack. The structure and function of the present invention and the preferred embodiments can best be understood by reference to the drawings. It should be noted that where the same reference designations appear in multiple locations, the numerals refer to the same or corresponding structure.

FIG. 1 is a diagram of a distributed trading system in accordance with an embodiment of the present invention. A coordinator 102 communicates with each of the local trading locations 1 12. 1 14 and 1 16, which each house an interceptor 108A-108N. The coordinator 104 collects and coordinates the work done by the interceptors 108, and may consist of a server and one or more clients that provide the primary interface to the system. It should be appreciated that the coordinator can be located anywhere and does not need to be physically located at a home or base trading location or office. It should be further appreciated that the coordinator may be comprised of a set of cooperating computers each at a different location.

FIG. 2 shows a distributed trading system in accordance with an embodiment of the present invention. The distributed trading system in this embodiment is implemented using a network of computers 200. A coordinator computer 202 has conventional components including a central processing unit (CPU) 204 that interacts with a set of executable programs stored in a memory 205. The executable programs stored in memory 205 include a coordinator trade authorization (TA) module 206A that performs a coordinator portion of a trade authorization process; a coordinator target slack function (TSF) module 208 that performs a target slack process; a coordinator phase I slack division (PISD) module 210A that performs a monotonic phase I of the slack division process; a coordinator phase II slack division module (PIISD) 212A that performs a phase II of the slack division process; a coordinator slack arrangement (SA) module 214A that performs a coordinator portion of a slack arrangement process; a coordinator slack readjustment (SR) module 218A that performs a coordinator portion of a slack readjustment process; a coordinator proactive interceptor local trade range adjustment (LTRA) module 220A that performs a coordinator portion of a proactive interceptor local trade range adjustment process; a coordinator band definition (BD) module 222 that is used to define bands or cumulative trade ranges; a coordinator mark-to-market (MTM) module 224A that performs a coordinator portion of mark-to-market determinations; a coordinator new trading location addition (NTLA) module 226A that performs the steps necessary for the coordinator to add a new trading location to the system; and a coordinator synchronization (S) module 228A that performs coordinator-related synchronization functions. It should be appreciated that the coordinator computer 202 may consist of a server and one or more clients that provide the primary interface to the system. Further, it should be appreciated that the coordinator computer can be located anywhere and does not need to be physically located at a home or base trading location or office. In addition, it should be appreciated that the coordinator computer may itself be a network of cooperating computers that may each be in a separate location. The coordinator computer 202 communicates with each of several interceptor computers 203A-203N by a network 201, although it should be appreciated that only one interceptor computer 203 is shown in detail. Each interceptor computer 203 has conventional components including a central processing unit (CPU) 204 that interacts with a set of executable programs stored in a memory 227. It should be appreciated that the interceptor computer 203 may consist of a server and one or more clients that provide the primary interface to the system. Further, it should be appreciated that the interceptor computer can be located anywhere and does not need to be physically located at a home or base trading location or office. In addition, it should be appreciated that the interceptor computer may itself be a network of cooperating computers that may each be in a separate location. Also, it should be appreciated that the interceptor computer and the coordinator computer may utilize the same CPU or set of CPUs.

The executable programs stored in memory 227 include an interceptor trade authorization (TA) module 206B that performs an interceptor portion of a trade authorization process; an interceptor slack arrangement (SA) module 214B that performs an interceptor portion of a slack arrangement process: an interceptor slack readjustment (SR) module 218B that performs an interceptor portion of a slack readjustment process; an interceptor proactive interceptor local trade range adjustment (LTRA) module 220B that performs an interceptor portion of a proactive interceptor local trade range adjustment process; an interceptor mark-to-market (MTM) module 224B that performs an interceptor portion of mark-to-market determinations; an interceptor new trading location addition (NTLA) module 226B that performs the steps necessary to add a new trading location to the system; and an interceptor synchronization (S) module 228A that performs interceptor- related synchronization functions. As will be discussed, the distributed trading system of the present invention when implemented using a network of computers is designed to minimize the latency for authorizing trades.

FIG. 3 shows a cumulative limit structure for a coordinator in accordance with an embodiment of the present invention. It should be appreciated, however, that this structure only represents the limits for one item for one bucket. The precise cumulative trade value is in the vertical direction. A cumulative trade limit 301 is a pre-selected precise cumulative trade value. Other pre-selected precise cumulative trade values 302, 303, 304, and 305 form the boundaries of cumulative trade ranges 306, 307, 308, 309. These cumulative trade ranges are also referred to as "bands." As noted, trading policy may depend on the particular cumulative trade range or band within which the current cumulative trade value resides. For example, band 309 may be configured as "green," indicating that the cumulative trade value is far below the limit. Band 308 may be configured as "yellow." indicating that the cumulative trade value is below the limit but close to it. Band 307 may be configured as "red." indicating that the cumulative trade value is above the limit but not by much. And. band 306 may be configured as "black" indicating that the cumulative trade value is far above the limit Each of these bands may then be associated with different trading policies. For example, when trading within the "green" band 309. no managerial approval is required for a given trade. When trading within the "yellow" band 308. a local trading supervisor^'s approval may be required for the proposed trade. When trading in the "red" band 307, approval from the head office for each trade that would increase the cumulative trade value may be required, while only local supervisor authorization would be required for trades that decrease the cumulative trade value. And. when trading in the "black" band 306, approval from the head office for all trades may be required. When the cumulative trade value crosses from one band into another, a band crossing has occurred. It should be appreciated that a cumulative trade value accuracy or slack may be defined for each band. As such, band crossings can be "precise^" or "imprecise" which also corresponds to whether the cumulative trade value itself is precise or imprecise at the time of crossing. By default, the band crossing corresponding to the cumulative trade limit 301 is a precise band crossing, and all other band crossings are configured to be imprecise. A precise band crossing allows managers and traders to know precisely which side of the band crossing the global position is in at all times, and it allows the particular trade that caused the band crossing to be identified. The "cost" of this precision is increased communication between the interceptors and the coordinator as the band crossing is approached, since the cumulative trade value needs to be known precisely. Therefore, in this case, the accuracy is maximized as it has a range of size zero, i.e., the slack is zero. For example, the yellow to red band crossing may be configured as a precise band crossing, since it may be desirable to know exactly when the cumulative trade value crosses the cumulative trade limit 301. An imprecise band crossing would not provide such information. The transition from green to yellow, or vice versa, is information that traders should know, but the timeliness and the precision regarding this crossing may be less important with respect to the defined trading policies associated with these bands. As a result, the band crossing could be designated "imprecise."and the cumulative trade value would only be known within a certain range. In this case, the coordinator would deem that a band crossing had occurred when the midpoint of this range crosses a band boundary. It should be appreciated that imprecise band crossings do not cause additional messages to be sent between the interceptors and the coordinator.

It should be appreciated that the cumulative trade ranges or bands may be designated as "zero-slack" bands. By designating a band a "zero-slack" band, the accuracy has a range size of zero and the cumulative trade value is precisely known. In this case, the interceptors can be forced to check in with the coordinator on every trade as long as the cumulative trade value stays within that band. Band crossings between a zero-slack band and non-zero-slack band are deemed to be precise. If the boundary between two bands is imprecise, these bands can be merged and viewed as a single band for purposes of operation of the present invention. For example, if the green to yellow crossing is imprecise, and if the black band is a zero-slack band but the red band is not. then this can be treated as three bands consisting of green/yellow, red and black.

In operation, the interceptors and the coordinator work together to ensure that the cumulative trade value is known and that any crossing of a cumulative trade limit can be realized in real time. When the cumulative trade value is far from the limit, the interceptors work autonomously but report their local trade value occasionally to the coordinator. As the cumulative trade value approaches the limit, the interceptors and the coordinator cooperate more closely. This cooperation is structured to minimize the number of communications required, and the associated cost in trading delay and network bandwidth, without compromising the integrity of the limit.

Attention now turns to the cumulative trade value accuracy or global slack, which is the accuracy with which the cumulative trade value or global position has to be known. More precisely, the global position is certain to be within a particular global range of values defined as a current global upper and lower bound, and the coordinator knows at all times that the global position lies between these bounds. The maximum allowed difference between the upper bound and the lower bound or the size of this global range is the cumulative trade value accuracy or global slack. The communication protocols used between interceptors and coordinator ensure that at all times the global position is certain to be within this particular global range of values. Furthermore, the interceptors work with the coordinator to ensure that the size of this global range never exceeds the designated global slack value, although it is possible that actual global range may be less than that global slack value.

It should be appreciated that the global maximum slack value is a predetermined value. That is, the system manager can specify how precisely the global position must be known. The coordinator displays the current global upper and lower bounds (which it knows precisely) at all times. It can also show an approximation to the current position, but the data this approximation is based on trails behind the trading that is occurring autonomously at the offices by a system configurable amount of time.

Clearly, the smaller the global slack requested (i.e.. the greater the accuracy with which the global position must be known and. therefore, the smaller the global range within which the global position resides), the more communication is required between the interceptors and the coordinator for a given set of trades. Alternatively, as will be discussed below, the system may itself choose a default value for the global slack that ensures that the cost of the communication between the interceptors and the coordinator is minimized and the communication efficiency is optimized. The manager is free to override the default global slack value selected by the system at any time. For example, the precise global position can be ascertained at any time by setting the global slack to zero.

As the global position approaches the cumulative trade value limit, the interceptors and the coordinator work together to gradually reduce the global slack in conjunction with a predetermined accuracy function. The closer to the limit the global position comes, the more accurately the global position must be known to check trades against the limit. By the time the limit is actually reached, the global slack has been reduced to zero, and the global position is known precisely.

The coordinator is aware of the accuracy or range of possible values for the global position at all times. The accuracy is managed so that it is always completely above or completely below the limit. The interceptors are kept precisely informed about whether the currently global position is above or below the cumulative trade limit, so that the appropriate trading policies can be applied. They are also informed periodically of the particular cumulative trade range or band within which the global position resides.

In fact, and as will be discussed below, the coordinator actually divides or allocates the global slack amongst the offices that are trading actively. For example, if there are two offices with similar trading activity, and the global slack was set to 2000 units (e.g. $2,000,000), each office's interceptor could, for example, be allocated 1000 units of slack, which may be referred to as local slack. Each interceptor would have a local upper bound and a lower bound that differed by 1000, or, in other words, had a range having a magnitude of 1000 units. As long as the interceptor^'s local trade value remains within its local trade range (i.e. between its current local upper and lower bounds), trades can be made without communicating with the coordinator. If authorization is requested for a trade that would move the local trade value outside the interceptor's local trade range, communication with the coordinator is required. It should be appreciated that all changes to an interceptor's local trade range (i.e., its local upper and lower bounds) are done in cooperation with the coordinator, so that the coordinator knows at all times the range of possible values within which the interceptor^'s local trade value must fall.

The operation of the present invention is based upon several principles. First, each interceptor is the ultimate authority as to its current position, and may trade autonomously within its currently agreed range without consultation with the coordinator. Second, the coordinator is the ultimate authority on the current global range, such that no interceptor may take an action that might change the current global range (e.g. authorize a trade that would move the local position outside the current local trade range, without consultation with the coordinator. Third, the cumulative trade value accuracy or global slack must never exceed a maximum accuracy or maximum global slack. G. as specified by the system manager. However, the actual accuracy or global slack may be smaller than G. Fourth, the cumulative trade value is always completely contained within a single band, including those bands that have been merged, such as the green/yellow band described above. It should be appreciated that for imprecise cumulative trade values, the entire global range for the cumulative trade value may span or include an imprecise band boundary. However, the global range may not contain a precise band boundary, such as the yellow to red crossing point described above. It should be recognized that for purposes of the following discussion, all band boundaries are deemed to be precise.

In addition, operation of the present invention requires that for each bucket or item, an interceptor i (i = l ..n) maintains that interceptor^'s current position or local trade value, p-, its currently assigned local trade range, [a*, b,] and a current band identifier. Furthermore, the interceptor maintains invariant the condition that p* e [a b*], i.e. the interceptor's current position is always within its current range. The interceptor is informed periodically of the current global range. This information will always accurately reflect the current band within which the cumulative trade value resides. If the coordinator performs a band crossing, all interceptors will be notified in real time. If a change in the global range does not involve a band crossing, however, the coordinator may defer the process of informing all interceptors.

Operation of the present invention also requires that for each bucket, the coordinator maintains the current global range [A, B], the current list of k bands where any merged bands are considered as one and where Band* = [1*, h,], i = 1..k. currently assigned ranges [a-, b,] for each interceptor i, i = l..n, and the system manager specified maximum global slack G. Furthermore, the coordinator maintains the following invariants:

Σ-..Σ*. ^ [A, B]

B-A ≤ G

Bαnd_i for some i.

FIG. 4 shows the types of communications that may occur between a coordinator 102 and an interceptor 108 in accordance with an embodiment of the present invention. Two pairs of messages are used by the interceptors and coordinator to maintain the invariants specified above. First, an AM_BLOCKED message 402 is sent by an interceptor when authorizing a particular trade request would cause the interceptor^'s current position or local trade value to fall outside its current local trade range. This message contains the interceptor^'s current position p,, the size of the trade request needing authorization, δ, and the interceptor's current trading parameters λ,. μ, and σ,, where λ,. is the arrival rate of trade requests at an interceptor i in the form of a Poisson process having requested trade value mean of μ, and a standard deviation of σ,. which describe that interceptor^'s trading behavior. It is the responsibility of the interceptors to estimate λ,. μ, and σ,. The values of these parameters are carried with all messages from an interceptor to the coordinator; however, the coordinator may also request them from the interceptor. An interceptor should consider all available information when providing these parameters. For example, if the local trading location in which the interceptor is located is just opening for the day, the interceptor is free to report values for these parameters based on trading behavior just after opening time in the past, even though this day's trading has not yet started.

The coordinator responds to the AM BLOCKED message 402 with a AB_REPLY message 404 providing the interceptor with a new current local trade range. Trading that affects the bucket or item in question is suspended or blocked by the interceptor until the coordinator replies. The AB REPLY message 404 contains the band within which the resulting global position resides, the band immediately before execution of the requested trade for purpose of comparison, a new upper and lower bound defining the local trade range for the interceptor to use and a sequence number that uniquely identifies the interceptor's new local trade range. Second, a GLOBAL_ADJUST message 406 is sent by the coordinator to an interceptor whenever the coordinator wants to adjust the size of an interceptor's current local trade range. Since the coordinator does not know the interceptor^'s current position or local trade value, this message re-allocates a portion of the global slack to the interceptor and defines constraints within which the interceptor may choose a new local trade range. The interceptor replies with a GA_REPLY message 408, which specifies the new local trade range the interceptor selected.

The constraints in the GLOBAL_ADJUST message 406 are sent in the form of a new local slack value and a bounding box which is a range within which the interceptor must choose its new local upper and lower bounds for its new local trade range. This bounding box must always include the interceptor's current local trade range. If the bounding box did not include all possible values of the interceptor^'s current position or local trade value, the interceptor might be unable to comply with the GLOBAL_ADJUST directive. It should be appreciated that while it is waiting for a GA_REPLY message 408. the coordinator knows that the interceptor^'s current position is constrained to be within the bounding box at all times.

In fact, the new slack, or local slack, specified in the GLOBAL_ADJUST message 406 is also a constraint, not a specification. That is. the interceptor is free to choose a local trade range smaller than the value in the message. For example, if the interceptor is actually blocked awaiting a reply to an AIV._BLOCK.ED 402 message when it gets the GLOBAL ADJUST message 406, it should select a local trade range of size zero containing its current position and report that range in the GA_REPLY 408 message. This ensures that regardless of the order in which the coordinator processes the messages it receives, it has the best possible information about the interceptor^'s current position.

This set of messages provides the interceptors and coordinator with tools that are sufficient to maintain the invariants above. In order to minimize the trade authorization latency, however, it is advantageous to have the interceptor begin negotiations to move its current range before it actually blocks. Therefore, when an interceptor believes that blocking is imminent, it can send an IN_GUARD_BAND message 410 to the coordinator, and the coordinator replies with an IGB R-EPLY message 412. These messages are discussed in more detail below.

In general, however, messages may be initiated by either the interceptor or the coordinator. In each case, the initiator indicates that a change is needed and specifies constraints that must be met by the recipient. The recipient examines the constraints, and any other data it has in its possession, and replies with a range that meets the specified constraints.

Interceptor-initiated messages include AM BLOCKED and IN_GUARD_BAND. With respect to the A _BLOCKED message, the interceptor specifies that it needs a new local trade range that contains a specified value, p,+δ, where p, represents that interceptor's current local trade value and δ represents the change in that value based upon the proposed trade request. The coordinator then replies with a local trade range that includes this value. With respect to the IN_GUARD_BAND message, and as will be discussed below, the interceptor specifies that it needs a new range that contains a specified, smaller local trade range, the guard band [g, h]. The coordinator replies with a range that includes this smaller local trade range. The coordinator-initiated message is the GLOBAL_ADJUST message. The coordinator specifies the maximum allowable size of the new local trade range and a bounding box which must completely contain the new local trade range. The interceptor replies with a local trade range that is no larger than the specified maximum and which is entirely contained within the bounding box. Usually the interceptor will choose a range of the maximum size allowed. However, during proactive range adjustment, discussed below, or if the interceptor is blocked, the local trade range chosen by the interceptor may be smaller than the maximum.

In addition to the various messages described above, each interceptor periodically sends a 'heart-beat^" message 414 to the coordinator. Heart beat messages are used to detect failures of network connections and system components. These messages can also be used to carry low priority information from the interceptors to the coordinator and vice versa, such as position and trading parameter (μ, σ and λ) information. However, when there are many buckets, all of this information should not be sent in every heartbeat message.

Each interceptor should keep a circular buffer of information to be sent with the next heart beat message. Each bucket should keep a count, such that every n (e.g., 20) trades against a bucket results in an entry being put into the circular buffer. Each entry must include a bucket update sequence number, so that old information can be discarded. When it is time to send the heartbeat message, the contents of the circular buffer should be sent as well. When this message arrives at the coordinator, it should update its position and trade parameter information for each entry in the buffer. If there are multiple entries for a bucket, the sequence numbers will allow the coordinator to discard all but one of them. it should be appreciated that all requests to modify a bucket are considered to be events. Events include trade authorization requests, system manager requested slack changes, band definition changes, the addition of new local trading systems or locations, and the commit of mark-to-market changes to the current position, the latter of which is discussed in more detail below. Events and messages may arrive in any order and from multiple physical locations. The system ensures these events do not appear to happen concurrently: for any two events or messages one is always designated to have come first. For example, a trade authorization request always occurs in the context of a particular set of band definitions, i.e. it occurs either before or after a change in those definitions. FIG. 5 shows a trade authorization process in accordance with an embodiment of the present invention. As previously indicated, the trade authorization process is implemented with executable instructions resident within modules 206A and 206B. In the step 502. the trade authorization process is performed when an interceptor receives a proposed trade request that would take the local trade value outside of the local trade range. At this point, the interceptor is blocked from authorizing the proposed trade request. It should be appreciated that the use of the term "blocked^" does not necessarily mean that the actual trade cannot actually be executed or processed; however, it would be possible to provide such a result. It should be appreciated that a proactive interceptor local trade range adjustment process, described below in connection with FIG. 9. may be utilized prior to the trade authorization process. In fact, the proactive interceptor local trade range adjustment process is intended to minimize the frequency with which the trade authorization process is utilized. Regardless, at some point, an interceptor may receive such a proposed trade request to process. In step 504, the interceptor, which has been blocked from authorizing the proposed trade request, sends an AM BLOCKED message to the coordinator. In the step 506. the coordinator determines an after range and compares it to the current set of bands or cumulative trade ranges.

More specifically, whenever the coordinator receives an AM_BLOCKED message from an interceptor j, for example, the range of possible values of the global position is given by:

PX∑^a,>PX∑ ;= ^b> ςz Band_q 1

because the coordinator knows the position of interceptor j precisely - it is contained in the AM_BLOCKED message - and further trading is blocked until the coordinator replies. By construction, this range is contained completely in some particular band. band_q.

The AM_BLOCKED message also contains the size of the proposed trade that the interceptor is trying to authorize, δ. Therefore, the range of possible values for the global position if this trade is authorized is given by:

_PX^{δ +}Σ^a PX > +∑b,

^■=ι

This range is referred to as the after range. When the after range is compared to the bands, either the after range is completely contained within the current band. band_q, the after range intersects more than one band or the after range is completely contained within another band. band-. It should be appreciated that the determination of the after range is one embodiment of establishing a projected cumulative trade value.

For the case where the after range is completely within the current band, the coordinator knows that the trade which provoked the AM_BLOCK.ED message cannot cause a band crossing. Therefore, the step 508 is performed which determines a target slack and is one embodiment of adjusting the cumulative trade value accuracy.

FIG. 6 shows a target slack function in accordance with an embodiment of the present invention. A target slack function 602 is one embodiment of a predetermined accuracy function that is the amount of slack considered appropriate for a corresponding current global position, and as such is one method to define the cumulative trade value accuracy. Conceptually, the coordinator maintains a graph of the target slack function 602 that shows how the target slack should be set based on the global position. Therefore, once the coordinator knows the after range, it uses the target slack function to determine what should be the global slack For example, suppose the current band is the band below 2000, and the after range is [1750,1850]. From the target slack function 602, the new target slack would be 150. Specifically, the minimum value of the target slack function over the after range interval is reached at the top of the interval which is 1850. The value of the target slack at 1850 is 150. It should be appreciated that while the target slack function 602 is one type of predetermined function, any function or type of function may be used. This determination of the target slack is referred to as a target slack process and is implemented, as indicated above, with executable instructions resident within module 208.

Once the target slack is determined, the step 510 is performed. In the step 510. the coordinator invokes a monotonic slack division process (i.e.. phase I of a slack division process described below) and a slack arrangement process to compute a new local trade range for the interceptor to use based on a target slack computed from the after range. The phase I slack division process is implemented with executable instructions resident within modules 210A and 210B, and the slack arrangement process is implemented with executable instructions resident within modules 214A and 214B.

Before describing the slack division process, however, it is necessary to describe the slack arrangement process. Generally, there are situations that occur in both an interceptor and the coordinator where there is a position, some slack and the freedom to choose how the slack is arranged around the position, (i.e., freedom to determine what should be the bounds of the local trade range). This can be accomplished based on the following function which estimates the expected number of trades until the position is outside of the interval [a. b] for an interceptor. This function is based on the theory of stochastic processes. When μ* and σ,. are non-zero and is given by E T_ab as follows:

^_e-^X -e ²^^σ ) + a(e ^2μblσ -e^"2μϊ/σ2 ) x c ExTab — [e ^2≠lσ~ -e ²^"^3' ] μ

where:

X(t) is a Brownian motion random variable that represents the interceptor's position at trade number t; 10 x is the value of the random variable X at time 0. i.e. at the point in time where the slack arrangement algorithm is invoked;

[a, b] defines an interval or range and where a < x < b; μ is the mean of the Brownian motion X(t); σ is the standard deviation of the Brownian motion X(t); and 15 T_ab is the number of trades when X(T_ab) first reaches a or b.

The objective is to maximize E_xT_ab. subject to the constraint that b-a is equal to the slack s, which itself must be non-zero. This is equivalent to setting a=0 and b=s. and then determining the value of x that will maximize E_xT_ab. That value of x (designated x_opt) 20 and the corresponding value of E_xT_ab are given by the following formulae:

σ ^" ks

25 \ - e^'h

Xop, - — ln( w) k

3 Thus, if we know the current position p, the allowable slack s, the mean μ and the standard deviation σ. and σ, μ and s are all non-zero, the interceptor^'s new local trade range should be set to [p - x_opt. p + (s - x_opt)]. If s = 0. the interceptor^'s new local trade range must be set to [p, p]. If μ = 0. the interceptor's new local trade range should be set to [p - s/2, p + s/2]. If σ = 0 and μ is positive, the interceptor's new local trade range should be set to [p, p + s].

-⁵5 If σ = 0 and μ is negative, the interceptor's new local trade range should be set to [p - s, p]. FIG. 7 shows a slack division process in accordance with an embodiment of the present invention. Generally, the interceptors and coordinator are repeatedly faced with decisions as to how to divide the slack among interceptors and how to arrange the slack assigned to an interceptor around its current position or. in some circumstances, around its currently agreed-upon local trade range. It should be appreciated that the present invention is designed to minimize the average trade authorization latency. To do this, the global slack is divided and arranged to maximize the number of trades that can be authorized by the interceptors without the coordinator^'s help. This also minimizes the total amount of communication required between the interceptors and coordinator. It should be appreciated that the slack division process is also referred to as the allocation of slack and, in conjunction with the slack arrangement process, is one embodiment of resetting or adjusting a local trade range.

Of course, the sequence and size of trades that will be presented to each interceptor in the future cannot be predicted. Instead, the trades that have been presented to each interceptor in the past are examined, and it is assumed that past behavior in like circumstances is the best predictor of future trading behavior. Furthermore, it is assumed that flow of trades forms a discrete Brownian Motion, and that it is reasonable to approximate that discrete Brownian Motion by a continuous one. Specifically, it is assumed that trades arriving at interceptor i form a Poisson process with arrival rate λ„ and that the trade sizes are normally distributed with a mean μ, and a standard deviation of σ,. The coordinator must divide the global slack amongst the various interceptors in a sensible way. For example, interceptors that are trading actively should get a larger amount of slack than interceptors that are idle. Therefore, a cost function is defined and a numerical algorithm is used to determine the division of slack that minimizes the total cost. Specifically, it is assumed that each round trip message from interceptor i to the coordinator and back has a constant cost c,. Note that the cost c, can be thought of as an input parameter indicating how important it is to avoid communication between the coordinator and interceptor i.

There are two phases of the slack division process: phase I which is monotonic in the global slack, which is used in the trade authorization process, and phase II which is not monotonic. which provides a better division of slack. The monotonicity means that if the global slack is increased, every interceptor^'s portion of the slack either increases or stays the same. Conversely, if the global slack is decreased, every interceptor^'s portion either decreases or stays the same. It is assumed that a round trip message from interceptor i to the coordinator has a cost c,. It should be appreciated, however, that the system manager can assign this cost arbitrarily.

The cost function is given by:

c- Σ , = ₀ xTab

where E_xT_ab is as given above in connection with the slack arrangement process.

It should be appreciated, that the function for E_xT_ab needs to be reasonable and defined even when any of σ. μ and s are all zero. This function must be continuous and strictly monotonically increasing in s. It should also be continuous in μ and σ. Therefore, the function used is:

E(s. μ.σ ) = 1 + — (w- 1 - ln( ')) kμ when s, μ and σ are all non-zero, and where k and w are defined as above:

σ " ks w -

^■ e ^~h

If s = 0. E(0 μ, σ ) is defined as = 1.

If σ ≠ 0 and μ = 0, E(s. μ, 0 ) is defined as:

If μ ≠ 0 and σ = 0, E(s, μ, 0 ) is defined as:

If μ = 0 and σ = 0, but s ≠ 0, E(s, 0, 0 ) is defined as infinite, i.e., the interceptor^'s position never changes. Clearly, in the case where μ = 0 and σ = 0 the function E is discontinuous in s at s = 0. The slack division process needs to handle this discontinuity cleanly. In the step 702 the coordinator divides the target slack determined in the step 508 into a predetermined number of units or pieces, for example. 1000 units each of size target slack/1000. In the step 704. the coordinator determines the total cost function above for the cases where s = 0. In the step 706. the coordinator defines the interceptors to be considered by selecting all interceptors with λ, > λ_mιn > 0. where λ_mm is a predetermined value selected by the system manager. Interceptors with a trading rate smaller than the rate of heartbeat messages, for example, could be assigned a slack of zero. In the step 708 the coordinator divides the slack amongst the interceptors. More specifically, for each unit of slack, the coordinator computes the reduction in the total cost that would be achieved by increasing the slack for each interceptor selected in the step 706 by one unit. For the interceptor that reduces the total cost the most, this unit of slack is assigned or allocated to that interceptor. The step 708 is repeated for each unit of slack until all of the slack has been allocated.

Note that this phase I works reasonably despite the discontinuity in the function E defined above. That is, interceptors with μ = 0 and σ = 0 will be assigned at most one unit of slack. It is easy to see that phase I is monotonic in the slack.

Phase II of the algorithm is optional and should, in fact, only be invoked at times when monotonicity is not required. In phase II, selected interceptors may have the slack assigned to them in phase I re-assigned. When the amount of slack assigned to an interceptor by phase I is smaller than the minimum likely trade size, each and every trade will cause an AM BLOCKED message, despite the slack. Therefore, it is more efficient to re-assign the slack to another interceptor that may be able to use it. For this reason, however, the system manager may assign a threshold slack value for each interceptor such that if a given minimum amount of slack for a particular interceptor cannot be assigned, then a slack of zero should be assigned.

In the step 710, the interceptor whose assigned slack is the smallest percentage of its threshold slack as assigned by the system manager is selected by the coordinator. In the step 712, the selected interceptor^'s slack is de-allocated if its assigned slack is less than its threshold. This interceptor is then removed from the set of interceptors selected in the step 706. The step 708 is then repeated until the selected interceptor's slack has all been completely re-allocated. The steps 710. 712 and 708 are then repeated until there are no more interceptors to be considered. If phase II terminates with an empty set of interceptors to consider, then the slack is too small to be useful. Setting the slack for all interceptors to zero is reasonable in this case. As indicated above, phase I of the slack division process is implemented with executable instructions resident within modules 210A and 21 OB. Phase II of the slack division process is implemented with executable instructions resident within modules 212A and 212B. It should be appreciated that this slack division process is also used to divide the maximum global slack G as defined by the system manager at any time. Communication of the resulting allocation of slack, based on G or otherwise, to the interceptors is handled in a fashion described below.

Referring back to FIG. 5. as noted, for the case where the after range is completely within the current band, only phase I of the slack division process is performed in the step 510. This results in the determination of slack s for the interceptor which sent the original AM_BLOCKED message. Now, the slack arrangement process described above is performed using slack s to determine the actual local trade range for this interceptor. The coordinator then sends an AB_REPLY message to the interceptor which effectively resets the local trade range for that interceptor. In the step 512. the interceptor is now able to authorize the execution of the original proposed trade request.

In the step 51 1, the coordinator sends a AB_REPLY message to the interceptor containing this new local trade range. No GLOBAL_ADJUST messages are required or sent. To understand why the GLOBAL_ADJUST messages are not required, it is enough to show that (a) the global range that results from the AB_REPLY message above is completely contained in the current band (Band_q). and (b) the new global range is no larger than the system manager specified maximum value G. In fact, the new global range size is between the target slack size and the size of the old global range.

The first point (a) follows from the shape of the target slack graph. Because the two sloped portions of the graph have slopes of -1 and 1. the target slack cannot be larger than the shortest distance from the after range to the boundary of the band. In the "worst" case, the target slack in fact equals the shortest distance from the after range to the boundary, the after range has a size of zero (no other interceptors have any slack), the slack division process allocates all of the target slack to the interceptor making the request, and the slack arrangement process arranges the slack completely on the boundary side of the interceptor's current position. In this case, the resulting global range would include the boundary of the band, but would not overflow into the adjacent band.

The second point (b) follows from the monotonicity of the slack division process. For example, let g be the size of the global range before this bucket operation, and let g' be the size afterwards. Let T be the target slack. Let s, = b,-a, be the size of the range at interceptor i, so that:

-99- * - Σ ι = l ^* and let s, be the new slack assigned by the monotonic slack division process for interceptor i. Then, if the coordinator is processing a request from interceptor j:

g'= s X∑ s , . anά ι = l

T = ∑ s, ' ι = l

It is known that both g < G and T < G. but it must be shown that g' < G. Suppose T > g. Then, by the monotonicity of the slack division algorithm, s,' > s, for all i. Hence.

T > g' > g. which implies that G > g'. Similarly, if T < g, then s,' < s, for all i, so that T < g' < g < G, as required.

Referring back to FIG. 5, where the step 506 is performed and it is determined that the after range intersects more than one band, it is not immediately clear whether the trade being processed will cause a band crossing or not. In this case, the step 514 is performed. Specifically, the coordinator sets the target slack to zero and sends a GLOBAL_ADJUST message to each interceptor. In the step 516. each interceptor will respond by sending a GA REPLY message to the coordinator. Each GA REPLY message received by the coordinator will report the precise position for the interceptor sending that message. In the step 518. as each GA_REPLY message is received, the coordinator recalculates the after range, which will be smaller than the previous after range, and compares it to the bands. When all of the GA_REPLY messages have been received, the size of the after range will have shrunk to zero.

As noted, the coordinator recalculates the after range as it receives the GA REPLY messages and compares it to the current bands. When the after range has decreased to the point where it is contained in a single band, the coordinator can determine whether such single band is the current band or whether a band crossing has occurred. If the after range is within the current band, then the steps 508, 510, 51 1 and 512 are performed as described above. If the after range is contained within another band then the steps 522, 524 and 526 are performed as described below. It should be noted that there is

-22 no need to perform the steps 528 and 530 by sending what would be a "second^" GLOBAL_ADJUST message. Since the ranges at all the other interceptors are of size zero based on the performance of the step 514. each interceptor will be forced to send an AM_BLOCKED message on its next trade. The resulting AB_REPLY message will inform each interceptor that the global position has changed bands and provide each with a new local trade range.

In the step 520, the other interceptors are forced to send AM BLOCKED messages, since the ranges at all of the other interceptors are now of size zero based on the previously sent GA REPLY messages. It should be appreciated that if the coordinator replies to the originating interceptor before all of the GAJR.EPLY messages have been received, it should keep track of the interceptors from which messages are still expected. Further coordinator actions on this bucket should be delayed until all expected GA REPLY messages have been received.

Referring back to FIG. 5, where the step 506 is performed and it is determined that the after range is completely contained in a band other than the current band, the coordinator knows that the trade being processed will definitely cause a band or limit crossing to occur. This fact needs to be communicated to all interceptors as efficiently as possible.

The step 522 is performed in which the coordinator uses the after range to determine the appropriate target slack as described in connection with the step 508. In the step 524. the coordinator performs the slack division process and the slack arrangement process as described above to determine the new local trade range for the interceptor originally sending the AM BLOCKED message. It should be appreciated that only phase I of the slack division process is performed as described in connection with the step 510. In the step 526, the coordinator sends this interceptor its new local trade range in an AB_REPLY message, effectively resetting the local trade range for this interceptor.

In the step 528 the coordinator sends a GLOBAL_ADJUST message to all other interceptors. This message informs all of the other interceptors of the change in band and gives each interceptor a new local trade range based on the results of the step 524. It should be appreciated that there is a minor subtlety in the construction of these GLOBAL ADJUST messages with respect to the bounding box. In the case where the interceptor's new slack is smaller than its old slack, the bounding box is set to the interceptor^'s current range. However, when the new slack is larger than the old slack, the coordinator should invoke the slack arrangement process using the interceptor's last known position, then adjust the resulting range to ensure that it completely contains the interceptor^'s current range. This adjusted range should be the bounding box used in the GLOBAL_ADJUST message.

It should also be appreciated that the steps 526 and 528 should be performed concurrently. However, in the interests of synchronization, the coordinator should not process any further actions on this bucket until the resulting GA_REPLY messages have all been received in the step 530.

It should be appreciated that the trade authorization process described above is based upon several observations. If the after range is completely contained within the current band (Band_q). and the target slack is determined from a function of the same form as the graph above, it is unnecessary, as described above, to proactively adjust the slack at the other interceptors based on the monotonicity of phase I of the slack division process. Furthermore, when GLOBAL_ADJUST messages are sent to multiple interceptors in order to set the global range to zero, the replies do not all arrive at the same time. Each GA REPLY message shrinks the possible after range. Therefore, it may not be necessary to wait for all the GA_REPLY messages to determine unambiguously which band contains the after range. Lastly, when the after range is completely contained in a band other than the current band (Band_q), all the interceptors need to be informed immediately of the band crossing. However, it is not necessary to set each interceptor's current slack to zero.

FIG. 8 shows a slack division readjustment process in accordance with an embodiment of the present invention. As indicated above, the slack division readjustment process is implemented with executable instructions resident within modules 218A and 218B.

It should be appreciated that over time, the trading parameters (μ. σ and λ) for each interceptor will change. This, in turn, will have an affect on the ideal division of slack which should be re-calculated. As such, a readjustment of the division of slack should occur periodically (e.g., every five minutes), when the system configuration changes (e.g., when a local trading location or office opens or closes), when the system manager changes the maximum global slack G and upon request from the system manager. Upon the occurrence of any of these functions, the step 802 is performed wherein the coordinator ensures itself that it has up-to-date values for μ, σ and λ for all active interceptors, which may result in the coordinator requesting such information from the interceptors. The step 804 is then performed in which both phases of the division of slack process are performed to compute a new allocation of the global slack. The step 806 is then performed in which the coordinator sends GLOBAL_ADJUST messages to all interceptors whose slack was reduced in the step 804. In the step 808, the interceptors send GA REPLY messages. In the step 810. the coordinator sends the new slack and local trade range to each interceptor whose slack was reduced in the step 804 in the next communication sent by the coordinator to that interceptor.

No other coordinator operations should be allowed on the bucket during the steps 806 and 808. If another operation is invoked on the bucket concurrent with steps 802 and 804, that operation should rely on the division of slack computed previously.

A simple and efficient way to provide both the optimal and monotonic variants of the slack division algorithm is as follows. First, at the slack division readjustment time, execute the slack division readjustment process. During the execution of the slack division process in the step 804. record the sequence of assignment of units of slack to interceptors. Correct this record as needed in the performance of phase II of the slack division process. Maintain this record for later use. Second, when a new division of slack is required by the trade authorization process, use the record made above to add or remove units of slack as required. If we are removing units of slack, and a particular interceptor's slack falls below the threshold of usefulness, simply set that interceptor^'s slack to zero.

This technique allows the compute intensive portion of the work in the slack division process to be done infrequently, and the results can be reused when needed. It should be appreciated that the creation of the record noted above is infrequent, expensive, optimal and non-monotonic, while the use of the record in later slack division process operations is frequent, inexpensive and monotonic.

As noted above, it may be appropriate for the system of the present invention to recommend a default value for the global slack. This may be performed under the same circumstances as the slack division readjustment process above. The default value is calculated by using the slack division process and allocating sufficient slack to each active interceptor to bring its expected communication costs (defined above) down to a predefined level, which could be directly related to the expected cost of heart-beat periodic communication. It may be useful to display expected communication costs versus allocated slack in graphical form. Standard numeric algorithms known to one of skill in the art may be used here, and estimates of reasonable slack values from which to start these algorithms may be calculated by examining the figures obtained if μ or σ are arbitrarily set to zero.

FIG. 9 shows a proactive interceptor local trade range adjustment process in accordance with an embodiment of the present invention. The proactive interceptor local trade range adjustment process is implemented, as indicated above, with executable instructions resident within modules 220A and 220B. When the authorization of a particular proposed trade request requires communication between the interceptor and the coordinator, the total latency (i.e., time to authorize) is substantially longer than when the interceptor is able to authorize a trade autonomously. The probability that an authorization operation will need to wait for communication with the coordinator can be reduced by proactively adjusting the interceptor^'s range if the interceptor's local trade value or position moves too close to either end of its current local trade range. As such the proactive interceptor trade local trade range adjustment process is essentially a process for adjusting the local trade range for a given interceptor based upon its trade activity reaching a predetermined level. This process is also referred to below as proactive range adjustment. Proactive range adjustment is not used at all times. In some circumstances many messages might be generated for little improvement in latency, and in these cases proactive range adjustment is simply not used or enabled.

When proactive range adjustment is enabled, the interceptor establishes a guard band at each end of its current local trade range. Each guard band is essentially a range within the current local trade range. Within each guard band there is a trigger point. In the step 902 the interceptor's current position crosses the trigger point in either guard band, and in the step 904 an IN_GUARD_BAND message is sent to the coordinator. This message contains the upper and lower bounds of the guard band containing the trigger that was crossed, the sequence number of the interceptor's current range which contains the guard band, an update of the interceptor^'s current position p, for display purposes, and an update of the interceptor's current trading parameters λ„ μ, and σ,.

The interceptor keeps a note of the fact that it has sent an IN_GUARD_BAND message. While it is waiting for a response to this message, it can continue to authorize trades in the normal manner, as long as the current position remains inside the guard band. If a trade authorization request would take the interceptor's current position outside the guard band, the interceptor should send the usual AM BLOCKED message. In this case, the interceptor has sent two messages to the coordinator, and it is possible to optimize the process so that trading can be resumed in many cases on receipt of the first of the two possible replies from the coordinator. This optimization is described below. To enable this optimization, however, the interceptor should add to the AM_BLOCKED message the information that the reply to the last IN GUARD BAND request has not yet been processed.

Assume that the coordinator is idle - in particular, that there are no GLOBAL_ADJUST messages being sent concurrently with the operations being describing here. It will also be assumed that the IN_GUARD_BAND and AM_BLOCKED messages sent from the interceptor to the coordinator arrive in the order they were sent. In the step 906, the coordinator replies to the IN_GUARD_BAND message with a IGB_REPLY message using essentially the same trade authorization process that would be used to handle an AM_BLOCKED message. Suppose that the guard band reported in the IN_GUARD_BAND message from interceptor j is the interval [g, h]. Then the current global range when the ^■*-> coordinator receives this message is given by:

g + bι c Bandq

10 where Band- is the global current band. The situation is now similar to band crossing case where the after range is completely contained in the current band. The range above can be used to determine a new target slack, and the slack division algorithm can be used to determine a new slack value for interceptor j. The coordinator's choice of range for the

15 IGB_REPLY reply to interceptor j is more constrained than it would be in the case of an AM_BLOCKED message, since the range returned to interceptor j must completely contain the guard band [g, h]. Where the new target slack for interceptor j is smaller than the guard band, the coordinator should send an IGB REPLY message to interceptor j specifying that its new local trade range is the guard band [g, h]. Where the new target slack for

20 interceptor j is strictly larger than the guard band, the coordinator should use the interceptor's most recently reported position to compute the best arrangement of slack around that position using the slack arrangement process and then adjust the local trade range to ensure that it includes the guard band [g, h]. This new local trade range should then be sent to interceptor j in an IGB REPLY message.

25 If the coordinator is not idle, then it is possible that the interceptor has been asked to handle one or more GLOBAL ADJUST messages while waiting for the response to the IN_GUARD_BAND message. In this case, the interceptor should reply to the coordinator with an GA_REPLY message that accurately reflects the range in which the interceptor will trade going forward. That is, if the interceptor is actually blocked waiting for a reply to an

30 AM BLOCKED message, the range reported should be [p_J5 p . If the maximum slack specified in the GLOBAL_ADJUST message is larger than the guard band, the range reported should be the guard band itself. If the maximum slack specified is smaller than the guard band, the interceptor should select the best possible range of that size and report it. In this case, the GA_REPLY message should also indicate that the IN_GUARD_BAND message

35 should be discarded. When the coordinator processes the IN_GUARD_BAND message, it should check the sequence number contained in the message against the last sequence number it sent in a GLOBAL_ADJUST or AB_REPLY message. If the coordinator^'s sequence number is larger than the one contained in the message, then the coordinator has received information that supercedes that in the IN_GUARD_BAND message. This more recent information should be substituted for the range [g, h].

The interceptor might send a IN_GUARD_BAND message followed shortly by an AM_BLOCKED message. It is possible that the AM_BLOCKED message might arrive at the coordinator before the IN_GUARD_BAND message. Alternatively, if the coordinator is busy at the time the IN_GUARD_BAND message arrives, the AM_BLOCKED message may arrive before the coordinator processes the IN_GUARD_BAND message. In either case, it would be advantageous to process the AM BLOCKED message and disregard the IN_GUARD_BAND message as the AM_BLOCKED message contains more recent and precise information about the interceptor's position, and therefore, allows the coordinator to do a better job of arranging the slack.

The "out-of-order" case can be detected using message sequence numbers. The presence of an AM_BL0CKED message can be checked for using a non-blocking poll operation as the processing for the IN_GUARD_BAND message begins. In either case, the IGB_REPLY message sent in response should indicate that it is the response to the AM BLOCKED message, so that the interceptor realizes that it should not expect a reply to the IN GUARD BAND message it sent earlier. It should be appreciated, and as will be described below, that all coordinator to interceptor messages contain coordinator generated range sequence numbers, and must be processed at the interceptor in the order specified by those sequence numbers. Messages in the interceptor to coordinator direction, on the other hand, are essentially prioritized by message type. GA REPLY messages are awaited, and given priority over all other message types. The other message types can be processed in any order.

The interceptor determines the size for a guard band at each end of its range as described in more detail below. The guard band size is chosen to ensure that there is a better than 95% probability that the coordinator will be able to reply to a IN_GUARD_BAND message before the interceptor needs to send an AM_BLOCKED message. The trigger points are located within the guard bands using the slack arrangement process above. For example, suppose the interceptor indicates that it needs a guard band size of 25 units and that the slack arrangement process indicates that the best arrangement of 25 units of slack is 5 units on the lower side (i.e.. down) and 20 units on the upper side (i.e., up). Suppose further that the current range is 1000 to 1200. Then the two guard bands would be 1000 to 1025 at the bottom, with a trigger point at 1005. and 1175 to 1200 at the top. with a trigger point at 1 180.

Proactive range adjustment should be enabled when the slack available to the interceptor is at least twice the size of the guard band. If the top and bottom guard bands overlap, proactive slack adjustment should be disabled, because the coordinator will be unable to move the range far enough to prevent an immediate reprise. The size of the guard band and the location of the trigger points should be re-evaluated on a regular basis, or whenever it is known that the trading behavior or network behavior have changed. There are two situations where an interceptor should be un-blocked before it receives the reply to an AM_BLOCKED message: (a) a GLOBAL_ADJUST message may provide an interceptor with sufficient new slack that it should, in fact, be able to resume trading immediately, and (b) an IGB REPLY message sent in response to a IN GUARD BAND message may arrive after an interceptor was forced to send an AM_BLOCKED message and may contain sufficient slack to allow trading to resume immediately. In each case, the coordinator needs to recognize that a particular AM BLOCKED message is now superfluous, and discard it. It should be appreciated that these optimizations do not conflict with or require change to the message ordering rules described in the previous section. In each case, the interceptor and the coordinator share common knowledge that it was unnecessary to send a AB REPLY message.

In order to handle the first case, the GA_REPLY message sent by the interceptor should include whether or not the interceptor was waiting for a reply to an AM_BLOCKED message and if so, whether or not the interceptor's blocking state was resolved by the slack provided in the GLOBAL_ADJUST message, and the range sequence number associated with this GLOBAL_ADJUST operation. It should be appreciated that the range sequence number is actually implicit as the coordinator knows it already.

The GA_REPLY message must be processed by the coordinator before it processes any further requests from this interceptor. In particular, if the interceptor was waiting for a reply to an AM BLOCKED message, then it must be the case that the coordinator initiated the GLOBAL ADJUST message before it received the AM BLOCKED message. As a result, the GA REPLY message is sure to be handled by the coordinator before the AM_BLOCKED message processing begins.

Thus, when the GA_REPLY message indicates that it resolved a blocking situation, the coordinator now knows that any AM_BLOCKED message it subsequently receives with a range sequence number smaller than that of the GLOBAL ADJUST operation is old - and can be discarded. The GA_REPLY message the coordinator processed first contained information that supercedes the information in the AM_BLOCKED message that the coordinator processed later.

For the second case, the coordinator should keep a copy of the last IN_GUARD_BAND/IGB_REPLY message pair last processed. If an AM_BLOCKED message makes it past the sequence number test above, the AM_BLOCKED message indicates that an IN_GUARD_BAND message was pending when it was sent, the coordinator has processed an IN_GUARD_BAND message previously, the range sequence number in the AM BLOCKED message is the same as that in the last IN_GUARD_BAND message, and the range provided in the associated IGB_REPLY message would allow the trade in question to be authorized, then the AM BLOCKED message can be discarded. Checking whether the range sequence number in the AM_BLOCKED message is the same as that in the last IN_GUARD_BAND message ensures that the IN_GUARD_BAND message referred to by the AM_BLOCKED message is in fact the one last processed by the coordinator. On the interceptor side, the operation awaiting a response to the

AM_BLOCKED message is awoken when the requisite slack becomes available, and both the coordinator and the interceptor know that no response to the AM_BLOCKED message is expected.

As noted the interceptor determines the guard band size. The size is determined to ensure that there is a better than 95% probability that the coordinator will be able to reply to a IN GUARD BAND message before the interceptor needs to send an AM_BLOCKED message. It should be appreciated that the 95% number may be adjusted as experience is gained with the performance of the system. If this number is increased, the guard bands will become larger, and as a result, proactive range adjustment will be disabled sooner during a precise band crossing.

There are three distributions of interest: the distribution of message round- trip times from this interceptor to the coordinator, the distribution of trade inter-arrival times, and the distribution of T_ab, i.e. the number of trades before an AM BLOCKED message is required. It will be assumed that these three random variables are independent. and for the sake of simplicity, that the variation in message round trip time is negligible. Therefore, the distribution of message round-trip times from this interceptor to the coordinator can be approximated by a constant t_r.

It is assumed that trades arrive according to a Poisson process. The number of trades that occur in the period [0,t] is denoted by Z(t). Then, the probability that exactly k trades occur in between time 0 and t is given by: Pr{Z<,) = *} = <^

If the trading rate λ is not large (e.g. less than one trade every two seconds on average) and the round trip time is in the range expected for a Tl link (e.g. less than 100ms), then there is a high probability that no trades will occur during a round trip. Using the example numbers, Pr{Z(100ms)=0} > 95%. While this is a special case, it is a common one. It suggests a minimum guard band size: the guard band must be large enough to allow for one trade (with 95% probability), regardless of the trading rate. This minimum guard band size can be computed as follows. Let x be the trigger point, and let x' be the position after one trade starting from the trigger point. Then x' is normally distributed with mean x + μ and standard deviation σ. Hence, there is a 95% probability that x' is in the interval [x + μ - 1.96σ. x + μ + 1.96σ]. using the 2.5% and 97.5% percentage points of the normal distribution. By definition, the guard band must contain the trigger point: the interceptor must provide the coordinator with a range containing its current position in the IN_GUARD_BAND message, and it is quite likely that the current position will not change during the round trip message time. If x is contained in the interval above (which it will be if |μ| < 1.96σ), then we are done: the minimum guard band size is 3.92σ. and the trigger point should be placed (1.96 σ - μ) from the bottom of the guard band.

If x is not contained in the interval above i.e. |μ| > 1.96σ, then the guard band should be of the form [x, b] for μ > 0 or [a, x] for μ < 0. Note that this essentially disables the guard band at one end of the interceptor's current range. If μ > 1.96σ > 0. we disable the guard band at the bottom of the current range. Similarly, if μ < -1.96σ < 0. we disable the guard band at the top of the current range.

The argument when μ > 0 and when μ < 0 case is identical. Without loss of generality, set x = 0. The probability that x' < 0 can be computed using the normal distribution which is denoted by . Because μ > 1.96σ, < 2.5%. β is defined such that α+β=5%. The inverse normal distribution with mean μ and standard deviation σ can now be used to choose b so that the probability that x' > b is β. Then b is the required minimum guard band size.

To this point a minimum guard band size has been computed to accommodate a single trade occurring while we are waiting for an IGB_REPLY, and the trading rate has been ignored. From the theory of continuous Brownian motion with drift. an approximation to the probability that the k^,h trade will still be in a guard band of size s can be computed, given a start at the trigger point. This approximation is denoted by Pr( T_ab > k} . From this, the probability that an AM_BLOCKED message needs to be sent before time t can be determined. It is given by one minus the probabili that the local trade value is still in the guard band at time t:

= l -∑Pr{Z(/) = ι}Pr{-T_£Λ > ι} ι=0

In fact, in the discussion above, only the first two terms of this series: the term for zero trades (i=0). and the term for a single trade (i=l ) have been considered. Clearly, Pr{T_ab > 0} is one: the normal distribution was used above to choose the guard band size so that Pr{T_ab > l } = 95%.

It should be appreciated that the method used above to calculate Pr{T_ab > 1 } is, in fact, better than the continuous Brownian motion based approximation mentioned above, since it does not make the continuous assumption. In particular, if the continuous Brownian motion X(t) exits the interval [a, b] and then returns within the time interval [0, 1], the continuous approximation will consider this path to contribute to Pr{T_ab < 1 }, whereas the discrete algorithm used above will not count this path towards Pr{T_ab < 1 }. Hence, the continuous approximation always over-estimates the value of Pr{T_ab < 1 }.

Based on the above, it can be determined whether the minimum guard band size is sufficient. Basically, when P < 5%, or equivalently when the sum above is larger than 95%, the minimum guard band size is sufficient. Since each term in the series is positive, if the sum of the first two terms exceeds 95%. then so will the sum of the entire series. Writing the first two terms explicitly, and using the fact that Pr{Tab > 0} = 1 and Pr{Tab > 1 } = 95% for the chosen minimum guard band size:

^■0.95λ e^_λ/ ≥ 0.95

This inequality can be solved numerically for λt. It is true whenever λt < 0.3078. This gives a bound on the trading rate. If λt < 0.3078. the second, third, fourth etc. trades that might occur during a round trip message time to the coordinator can be ignored, and the minimum guard band size calculated above can be used.

Note that this bound will, in reality, cover most cases. Even if t_r is 750ms. a trade can be processed every three seconds on average using a guard band of the minimum size. If t_r is 100ms, three trades a second can be managed without needing to resort to computing further terms of the series above. Turning to the case where λt > 0.3078. an approximation to Pr (T_ab > ij . for i > 1 is needed. A standard stochastic processes theorem described in S. Karlin and H. Taylor. "A First Course in Stochastic Processes^", Second Edition. Chapter 7. Theorem 5.3., herein incorporated by reference, allows the probability density function (pdf) of the time to first passage T₇ for a single barrier z > X(0) = 0 to be computed when μ > 0. It is given by:

Note that t is the number of trades, as we are approximating the discrete case where trades occur at t*=l, t=2, and so forth by the continuous random variable X(t). In this approximation, trading goes on continuously, with infinitely small trades occurring infinitely often. Clearly, the same density function can be used when μ < 0 and z < 0; simply replace μ and z by their absolute values. It is not so obvious that this same density function can be used when μ and z are of opposite signs i.e. in the cases (μ < 0, z > 0) and (μ > 0. z < 0). In the first case, the density function can be used as it stands; in the second, replace both μ and z by their negations. It should be noted that the density function is not then a well formed probability density function. The integral with respect to t from zero to infinity is less than one. In other words, the probability of exiting in finite time is less than one.

Using this density function, the probability that the time to first passage is greater than k. i.e., the local trade value is still in the pseudo-guard band (-∞, z] or [z, ∞) after k trades can be determined by evaluating the definite integral:

Pr{T_: > k} = ]f(t;z)dt

The problem is more complex than this, because we have two barriers: a below and b above. In theory, one cannot simply compute the probability of exit above, the probability of exit below, and add them together. This double counts paths that cross both barriers before the "time' t =• k. Fortunately, it can be shown that these paths have low probability for the parameters of interest, and a simple upper bound on that probability can be estimated.

The upper bound on the probability that a path crosses both barriers can be computed by using the renewal property of Brownian motion, as the history leading up to a particular value X(t) has no bearing on the future values of X(t). Brownian motion is also translation invariant: if X(t) = a and X'(t) = b are two different paths of the same Brownian motion, then the distributions of X(t') - a and X'(t') - b. for t' > t are identical. At every instant in time, the Brownian motion essentially "starts afresh.^" using its current value as the starting point. From these two properties, it can be observed that the probability that a path ends at the upper barrier b before time t, and that it crossed the lower barrier a before reaching the upper barrier b. must be less than (the probability of crossing the lower barrier in the time interval [0, t]) multiplied by (the probability of crossing the upper barrier b starting from the lower boundary a in the time interval [0, t].) Basically, X(t) must travel from a to b in the time remaining after it first hits a; this is less likely than managing to travel from a to b in the whole time interval. Both quantities in this estimate are definite integrals of the form above - one which already needs to be calculated, and the other which is strictly smaller than something that already needs to be calculated. The identical argument can be made for paths that end at the lower barrier, having crossed the upper barrier first. When performing the calculation for the passage against the drift, i.e., if μ > 0, the passage from b to a. it may be useful to note that the probability of reaching a at any point t > 0 is given by:

which is the value of the integral above evaluated from t = 0 to ∞. when z and μ are of opposite signs.

The error in truncating the series at a particular term can be bounded above by noting that:

These facts can easily be used to bound P above and below. ^{• an}"

PrJT" > k) ≥ 0 is ^a strictly decreasing function of k.

The computation of the correct guard band size can be done by binary search. The largest useful guard band size is half of the largest slack that could be assigned to this interceptor, based on the system manager specified global slack G. If P for this size guard band is larger than 5%, proactive range adjustment will be disabled. The actual size of an appropriate guard band is then irrelevant.

The guard band size can also be bounded from below. It must be larger than (a) the minimum guard band size calculated above and (b) λt|μ| - the expected number of trades during time t, times the expected size of each trade.

There are various other aspects of the invention discussed below. These include changing the band or cumulative trade range definitions, adding new local trade locations to the system, mark to market features and synchronization.

It should be appreciated that the bands, or cumulative trade ranges, can be changed by the system manager. For example, the system manager might increase or decrease the number of bands or change the names and meanings of the bands completely. As indicated, the cumulative trade ranges or bands may be defined or changed with executable instructions resident in module 222.

To allow for both continuous and discontinuous change, the system manager must define the correspondence (if any) between the old (merged) bands and the new (merged) bands. For example, if the old bands were designated [Green. Yellow] and [Red, Black], and the new bands are designated [Scissors, Pencils] and [Paper], the system manager could indicate that there was no correspondence between them. Alternatively, the system manager might specify that [Green, Yellow] corresponds to [Scissors, Pencils] and that [Red, Black] corresponds to [Paper].

The coordinator must compare the current global range to the new band definitions and execute any required adjustments. The process for doing this is essentially the same as the trade authorization process described above, with some modifications.

Since the band changes are by the system manager and not a trader or interceptor, there is no trade or AM_BLOCKED message involved. Hence, there is no notion of after range.

Instead, the current global range should be used in place of the after range. The three possible outcomes when a band is changed, which correspond to the three possible scenarios in the trade authorization process (i.e.. the after range is within the current band, the after range intersects more than one band and the after range is within another band), include the current global range contained completely within the new band that corresponds to the current band, the current global range intersects multiple new bands and the current global range is completely contained within a new band that does not correspond to the current band.

In the case where the current global range is contained completely within the new band that corresponds to the current band, no additional communication between the coordinator and the interceptors is required. The new band information will propagate to the various interceptors on the next communication. This means that new names for bands will not be propagated to the interceptors immediately. In the other two cases, all interceptors will be contacted immediately.

It should be appreciated that new local trading locations may be added to the system. In fact, the set of trading systems that is participating in the distributed trading system will be changing constantly. When the system is first installed, each and every trading system in each and every office will need to be added to the system. Thereafter, mergers, acquisitions, the establishment of new offices and the adoption of new trading software will all create a need to add new trading systems to the set of participants incrementally. As indicated, a new trading location may be added or removed from the system with executable instructions resident in modules 226A and 226B.

Generally, such new local trade locations can be added by installing an interceptor at the new location, configuring and testing the interceptor and coordinator and bringing the new location on-line. Suppose that k interceptors have already been installed and integrated, so that the k trading systems represented by those interceptors share a common set of global bucket definitions and a common set of band definitions for those buckets. Our objective is to add the k+l^st interceptor to the system without halting trading in any of the original k systems and with minimal disruption to the k+l^sl system. The design of the k+l^st trading system determines how small the disruption can possibly be. For some systems, there may be no disruption; for others, it may be necessary to shut down and restart the trader's desktop applications.

The integration of the k+l^st trading system will, in almost all cases, involve modification of the band definitions currently in use by the existing k trading systems. For example, if the k existing trading systems currently share a limit for some bucket of 100.000 units, and the k+l^sl trading system currently has a limit of 5.000 units for the same bucket, then the integrated system with all k+1 trading systems should probably share a limit of 105,000 units for the single, combined global bucket.

The specific steps that may be taken to add a new location include the following. First, install an interceptor in the k+1 ^s! system. Once installed, this interceptor simply passes the trades on to the local limit service, if one exists. Trading can now resume and continue concurrent with the rest of the process. From the trader^'s perspective, the interceptor is not yet functional. Second, add a set of "test^" buckets at the coordinator - one for each global bucket in use by the existing k interceptors. These new buckets will be used to configure and test the new interceptor. Third, set the bands for the test buckets so that all the band crossings are imprecise and such that there are no zero slack bands. Let the coordinator choose the global slack for each bucket. Fourth, ensure that individual trades are correctly mapped to the appropriate global buckets for the k+l^st trading system, connecting the new interceptor to the test buckets at the coordinator. At this point, the system is set up so that the system manager can observe trades and positions at the k+1 ^sl trading system using the interceptor and the coordinator, but the new system is not yet integrated from a bucket, band and limit sharing perspective.

Fifth, the system should now be observed to ensure that the trade attribute to bucket mapping is appropriate and consistent with the mappings in use by the existing k interceptors. If not, the mapping can be iteratively adjusted until it is satisfactory. Sixth, develop appropriate single trading system band definitions for the k+l^st trading system, based on the global bucket definitions and the mappings created in the fifth step. If appropriate, begin to enforce these band definitions using the coordinator and the test buckets. Seventh, determine the band definitions desired once the k+l^st system has been integrated. Eighth, decide the date and time the integration is to take place. Inform all interested parties of the impending event and the band definitions that will be in place from that time forward. Lastly, at the specified time and date, the coordinator will consolidate each test bucket with the corresponding actual bucket, remove the test bucket and execute the change of band definition algorithm on the resulting combined bucket. It should be appreciated that these operations can be executed atomically. From the trader's perspective, they will all occur at once, between two trades.

It should be appreciated that in the present invention provides the capability to perform mark-to-market (MTM) activities (i.e. re- valuing the components of a portfolio based on current market data) whereby trading can continue concurrent with marking the

»- portfolio to market. Such MTM activities may be implemented with executable instructions resident within modules 224 A and 224B.

First, trading systems are grouped, for example, by time zone. Next, for each bucket, the coordinator maintains a "delta^" bucket for the purposes of MTM. Trading then continues at all trading systems, and the coordinator continues to update the production buckets as it receives AM_BLOCKED and other interceptor generated messages. Then all trading systems in a particular group suspend trading and perform their MTM calculations at approximately the same time. Trading continues via all other trading systems. Next, the interceptor at each trading system in the group forwards the MTM generated updates to the coordinator which stores them in the delta buckets. Note that what is stored is a change in position, not a position. Once the MTM updates have been computed and forwarded for all trading systems in the group, the system manager can view and analyze the results of the MTM operation, but the production system continues to use the pre-MTM values. Lastly, the delta buckets can now be combined with the production buckets atomically on command, at any time.

Using this approach, the system manager has control of the point in time when the results of the MTM calculations performed by a group of trading systems become visible to the ongoing trading operations occurring e.g. in other time zones. The MTM operation appears to the traders to be an event that occurs between two trades. To the system manager, the MTM operation essentially occurs off-line, providing time to analyze the results before they affect ongoing trading operations. For example, if the MTM operation resulted in one or more new limit violations, the analysis period would allow the system manager time to trace the violation back to the events that precipitated it. During the analysis period, the coordinator provides the ability to view the global position 'before' and 'after' the MTM operation, and to determine how each trading system contributed to the change.

The following discussion focuses on synchronization issues related to the messages being sent between the coordinator and the interceptors. The coordinator must keep the following synchronization related variables: a C_Bucket Lock per set of related buckets and a C Range Lock per set of related buckets. In addition, for each interceptor the coordinator must keep the following: a sequencer which is used to dispense "range sequence numbers," a Discard Before variable which holds the range sequence number associated with the last range operation that caused a blocked to unblocked transition in the interceptor, and a copy of the last IGB_REPLY message. The C Bucket Lock is a mutual exclusion lock that is held for the duration of each bucket operation. Bucket operations include handling an AM_BLOCKED or IN_GUARD_BAND message, handling a request from the system manager to change the global slack, changing band definitions, etc. It is intended to ensure that each bucket operation completes before the next one is initiated. In particular, the C Bucket Lock can be held across messaging operations.

The C Range Lock is a mutual exclusion lock that is used to protect the coordinator^'s bucket related data structures. It is intended to ensure that multiple threads can work together to execute a particular bucket operation. For example, the C_Range_Lock must be held by the thread that updates the After Range when the reply to a GLOBAL_ADJUST message is received. The C Range Lock is not held across messaging operations, and therefore does not influence the global sequencing of bucket operations. These two locks are arranged in a locking hierarchy, so that if both locks are required for an operation, the C Bucket Lock must be obtained before the C Range Lock. All coordinator to interceptor messages (AB_REPLY. IGB_REPLY,

GLOBAL_ADJUST) carry a range sequence number, which identifies the new range that results from the message. The range sequence number is incremented by one each time the interceptor's range changes. All interceptor to coordinator messages (AM_BLOCKED, IN_GUARD_BAND, GA_REPLY) carry the range sequence number identifying the range in effect when the message was sent. In the AM_BLOCKED and IN GUARD BAND cases, this is the interceptor's current range sequence number; in the GA REPLY case, it is the range sequence number associated with the new range that the GLOBAL_ADJUST message caused to be selected.

The Discard_Before variable is used to detect interceptor to coordinator messages (AM_BLOCKED, IN_GUARD_BAND) that are no longer relevant. It is updated whenever an AB_REPLY message is sent in response to an AM_BLOCKED message. The AM_BLOCKED message indicates that the interceptor is blocked; the AB REPLY message will unblock it. Discard_Before is set to the range sequence number of the range sent in the AB_REPLY message. Any interceptor messages that were sent in the context of an earlier range sequence number (e.g. a IN GUARD BAND message) can now be discarded. It is also updated whenever an GA_REPLY message indicates that the interceptor became unblocked as a result of the GLOBAL ADJUST message. Discard Before is set to the Range Sequence Number of the range that resulted from the GLOBAL_ADJUST message. Any interceptor messages that were sent in the context of an earlier range sequence number (e.g. IN_GUARD_BAND or AM_BLOCKED messages) can now be discarded. Lastly, it is updated whenever the coordinator detects that an interceptor unblocked as a result of a IGB REPLY message sent in response to a IN_GUARD_BAND request. The coordinator determines this while processing an AM BLOCKED message by examining the last such IGB_REPLY message sent to this interceptor. Discard Before is set to the range sequence number sent in the last IGB REPLY message. It should be appreciated that the copy of the last IGB_REPLY message sent in response to a IN_GUARD_BAND message is used in the situations where an interceptor is unblocked before it receives a reply to an AM BLOCKED message.

Each interceptor must keep the following synchronization related variables: an I_ Bucket Lock per set of related buckets, an I_ Range Lock per set of related buckets and the range sequence number of the range it is currently operating within. The I Bucket Lock is a mutual exclusion lock that is held for the duration of each trade authorization. It is intended to ensure that each bucket trade authorization completes before the next one is initiated. In particular, the I_Bucket Lock can be held across messaging operations. The I_Range Lock is a mutual exclusion lock that is used to protect the interceptor's bucket related data structures. It is intended to ensure that multiple threads can work together during the execution of a particular trade authorization. The I Range Lock is not held across messaging operations; it does not affect the global sequencing of bucket operations. All coordinator to interceptor messages (GLOBAL ADJUST, AB REPLY, IGB_REPLY) messages must be processed in the order indicated by the range sequence number they contain. This is accomplished via an event count synchronization variable. All interceptor to coordinator messages (AM_BLOCKED, IN_GUARD_BAND, GA REPLY) carry the range sequence number identifying the range in effect when the message was sent. In the AM_BLOCKED and IN GUARD BAND cases, this is the interceptor's current range sequence number; in the GA_REPLY case, it is the range sequence number associated with the new range that the GLOBAL ADJUST message caused to be selected.

These three synchronization variables are organized into a locking hierarchy: the I_Bucket Lock must be obtained first; the Event Count must be awaited second, and the I_Range Lock must be acquired last. Clearly, an interceptor might send an AM_BLOCKED message concurrent with the coordinator sending a GLOBAL_ADJUST message. If both entities block waiting for a reply before proceeding, the system would be deadlocked. This deadlock is avoided by requiring that the interceptor reply to the GLOBAL_ADJUST message whether or not trading is blocked. The GA_REPLY message sent by the interceptor to the coordinator should be based on the interceptor's position before the trade which caused the block. In essence, the processing of the trade is delayed until the GLOBAL_ADJUST message has been handled. The coordinator determines the order in which changes are made to the interceptor^'s current range: the sequence numbers sent in the AB_REPLY and GLOBAL ADJUST messages explicitly define that order. In fact, all coordinator to interceptor messages contain coordinator-generated sequence numbers, and must be processed at the interceptor in the order specified by those sequence numbers. Messages in the interceptor to coordinator direction, on the other hand, are essentially prioritized by message type: GA REPLY messages are awaited, and given priority over all other message types. Other message types can be processed in any order. An additional aspect of synchronization is related to the size of the trades.

As indicated, synchronization functions may be implemented with executable instructions resident in module 228A and 228B. When a bucket^'s position is well away from any band boundary, and there is sufficient slack for proactive range adjustment to be enabled, essentially all trades will be authorized locally, without having to wait for communication with the coordinator. The exceptions will be large trades that the proactive range adjustment algorithm was unable to predict or adjust for in advance. These trades are denoted as 'bumps.'

When a bump occurs, its approval takes longer than usual: the approval process must wait for an AM BLOCKED message to get to the coordinator and be processed. and for the AB_REPLY message to return to the interceptor. This increased latency is both unavoidable and generally acceptable, because this is a larger than usual trade. However, a bump also affects small trades that occur at around the same time as the bump itself. While the interceptor is waiting for the AB_REPLY message, it is blocked - unable to process other trades until it receives a new range to use going forward. This impact on the latency of other trades can be avoided. For each bucket, a threshold size can be defined and incoming trades can be divided into two groups: those smaller than the threshold and those larger. The interceptors and the coordinator then maintain two separate bucket structures, each with its own position and trading range. However, the system knows that these two bucket structures are in fact parts of a single virtual bucket: the global position includes the positions from both bucket structures.

By virtue of the slack division process above, the large trade bucket structure is likely to get a range of size zero. Thus, trades larger than the threshold will require communication with the coordinator to authorize. Trades smaller than the threshold can continue to be authorized while the larger trade awaits a response from the coordinator. FIGS. 10-13 are concurrency diagrams illustrating operations performed in accordance with an embodiment of the present invention. These diagrams show examples of how various messages are processed in time. FIG. 10 begins with an AB_REPLY message and a GLOBAL_ADJUST message being sent from the coordinator to the interceptor in that order. An Event Count and Sequencer mechanism is used to ensure that the messages are processed in that order at the interceptor - even if the network re-orders the messages. If the coordinator is awaiting the results of a GLOBAL ADJUST message, it will ignore other incoming messages (such as an AM_BLOCKED) until it has received and processed the GA_REPLY message as shown in FIG. 1 1. If an AM BLOCKED message and a GLOBAL_ADJUST message are initiated concurrently, the AM_BLOCKED message is held at the coordinator until the results of the GLOBAL_ADJUST message have been received and processed as shown in FIG. 12. Note that, in this case, the AM BLOCKED and the GA REPLY messages provide the coordinator with identical information about the interceptor's current position, because trades that affect this bucket are blocked from the AM BLOCKED message to the AB REPLY message.

It is possible that the GLOBAL_ADJUST message is increasing the slack provided to the interceptor; this new slack may be sufficient to allow the interceptor to resume trading. The interaction would then appear as in FIG. 13. The interceptor decides it can resume trading based on the new range it chooses when processing the GLOBAL ADJUST. The coordinator is informed of this decision in the GA_REPLY message; it can then use the range sequence number included in the AM_BLOCKED message to determine that the AM BLOCKED message can be discarded. In this example, the range sequence number starts at 1 , and the AM_BLOCKED message is sent while range number 1 is in force. The GLOBAL_ADJUST operation allows the choice of a new range - range number 2. When the AM_BLOCKED message arrives, the coordinator knows it was sent when range 1 was active, but that it has already seen the results of the step to range 2, sent in the GA_REPLY message.

Claims

What is claimed is:

1. A method of managing distributed trading, said method comprising the steps of: establishing a cumulative trade limit; defining a cumulative trade value accuracy; processing a proposed trade request to establish a projected cumulative trade value; and adjusting said cumulative trade value accuracy with a predetermined accuracy function based on said projected cumulative trade value and said cumulative trade limit.

2. The method of claim 1 wherein said establishing step includes the step of establishing a set of cumulative trade ranges.

3. The method of claim 2 wherein said defining step includes the step of identifying said cumulative trade range associated with a cumulative trade value.

4. The method of claim 2 wherein said defining step includes the step of defining a set of cumulative trade value accuracies corresponding to said set of cumulative trade ranges.

5. The method of claim 1 wherein said processing step includes the step of processing a proposed trade request from any of a plurality of distributed trading locations.

6. The method of claim 1 wherein said processing step includes the step of processing a plurality of proposed trade requests for a plurality of financial instruments.

7. The method of claim 1 wherein said method is performed over a network of computers including a coordinator computer and a plurality of distributed local computers, a selected local computer of said plurality of distributed local computers including a local trade value, said method further comprising the steps of: setting a local trade range for said selected local computer; projecting a new local trade value in response to a proposed local trade; and blocking said proposed local trade when said new local trade value is outside of said local trade range.

8. The method of claim 7 further comprising the step of selectively resetting said local trade range in response to said blocking step.

9. The method of claim 7 further comprising the steps of: identifying when said cumulative trade value accuracy is less than a sum of all local trade range sizes for said plurality of distributed local computers; resetting at least one local trade range in response to said identifying step.

10. The method of claim 9, wherein said resetting step includes the step of resetting said at least one local trade range such that said sum of all local trade range sizes is no greater than said cumulative trade value accuracy.

1 1. The method of claim 10 wherein said resetting step is performed using trading behavior of the distributed local computer whose local trade range is being reset.

12. The method of claim 10 wherein said resetting step is based on minimizing communication latency between said coordinator computer and said plurality of distributed local computers.

13. The method of claim 7 further comprising the step of adjusting said local trade range for said selected local computer when trade activity at said selected local computer reaching a predetermined level.

14. The method of claim 13 wherein said adjusting step is performed to reduce the probability of said blocking step.

15. A method of managing distributed trading, said method comprising the steps of: passing a local trade range to each of a plurality of distributed trading locations; receiving a proposed trade request having a proposed trade amount; adjusting said local trade range for at least one of said distributed trading locations in response to said receiving step based upon a cumulative trade value accuracy; and repeating said passing step for said at least one of said distributed trading locations.

16. The method of claim 15, wherein said adjusting step includes the step of adjusting said at least one local trade range such that said sum of all local trade range sizes is no greater than said cumulative trade value accuracy.

17. The method of claim 16 wherein said adjusting step is performed using trading behavior of the distributed local computer whose local trade range is being reset.

18. The method of claim 17 wherein said adjusting step is based on minimizing communication latency between said coordinator computer and said plurality of distributed local computers.

19. A method executed by a network of computers, said network of computers including a coordinator computer and a set of local computers, said method comprising the steps of: establishing a cumulative trade limit at said coordinator computer; defining, at said coordinator computer, a cumulative trade value accuracy for a cumulative trade value; processing, at said coordinator computer, a proposed trade request, said proposed trade request being received from a local computer of said set of local computers to establish a projected cumulative trade value; and adjusting, at said coordinator computer, said cumulative trade value accuracy with a predetermined accuracy function based on said projected cumulative trade value and said cumulative trade limit.

20. The method of claim 19 further comprising the steps of: setting a local trade range for said local computer; projecting a new local trade limit in response to a proposed local trade from said local computer; and blocking said proposed local trade when said new local trade limit exceeds said local trade range.

21. The method of claim 20 further comprising the step of selectively resetting said local trade range in response to said blocking step.

22. The method of claim 21 wherein said resetting step each includes the step of identifying when said cumulative trade value accuracy is less than the sum of local trade ranges for said plurality of distributed local computers; and resetting said local trade range for at least one of said plurality of distributed local computers in response to said identifying step.

23. A computer readable memory to direct a computer to function in a specified manner, comprising: a first module to establish a cumulative trade limit; a second module to define a cumulative trade value accuracy for a cumulative trade value; a third module to process a proposed trade request to establish a projected cumulative trade value; and a fourth module to adjust said cumulative trade value accuracy with a predetermined accuracy function based on said projected cumulative trade value and said cumulative trade limit.

24. The computer readable memory of claim 23 further comprising: a fifth module for setting a local trade range; a sixth module for projecting a new local trade limit in response to a proposed local trade; and a seventh module for blocking said proposed local trade when said new local trade limit exceeds said local trade range.

25. The computer readable memory of claim 24 further comprising an eighth module for selectively resetting said local trade range in response to said blocking step.